Caneta de leitura TLS 1.2 vs 1.3 e gestão de certificados: latência do handshake, bateria e custo de provisionamento

Público-alvo: Este artigo destina-se a engenheiros de firmware OEM, arquitetos de segurança MDM e responsáveis pela conformidade que têm de justificar a versão TLS, o conjunto de cifras e a cadeia de certificados numa frota de canetas de leitura infantis. Faz um benchmark de TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446) e DTLS 1.3 nos 11 SKUs ativos (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6), com medições de latência do handshake, custo de bateria e o impacto na BOM do armazenamento de certificados.

Um projeto-piloto da UE em 2025 colocou 5.000 canetas de leitura atrás da firewall Palo Alto PA-5220 de uma escola. A equipa MDM exigiu apenas TLS 1.3 e certificados de servidor ECDSA-256. O nosso firmware de primeira geração 3.1.2 no F8 suportava TLS 1.3 no lado do servidor, mas não tinha certificados de cliente ECDSA, apenas RSA-2048. Resultado: todas as canetas falharam o handshake na primeira tentativa e repetiram com um fallback TLS 1.2 meio partido. O handshake demorou 4,6 s e consumiu 18 mAh por caneta por dia. Depois de lançarmos o firmware 3.3.1 com suporte de cliente ECDSA-P256 no Q8 e T2, o handshake desceu para 0,95 s e o custo de bateria para 3,1 mAh por dia.

Este artigo é a referência de engenharia que gostaríamos de ter tido no Dia 1 desse rollout. É fundamentado em medições de produção em 11 SKUs e no nosso teste de aceitação de fábrica interno.

1. Porque é que o TLS é importante numa caneta de leitura

Uma caneta de leitura é um "produto infantil conectado". Ao abrigo do Art. 32.º do RGPD, da secção 312 da COPPA e do Art. 51.º da PIPL, a caneta está a processar dados pessoais de menores. A obrigação de encriptação em trânsito é incontornável. Terminamos sempre o TLS no broker cloud (MQTT 8883, HTTPS 443) e no servidor de download OTA. O firmware recusa-se a enviar uma build com tls=false.

Duas versões de protocolo estão em produção:

• TLS 1.2 — suportado em todos os SKUs com chip Wi-Fi (todos os 11). Baseline obrigatório. Conjuntos de cifras: ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256.
• TLS 1.3 — suportado em K7, KF1, L5, Q8, T2, Y6. Conjuntos de cifras: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256. Dados 0-RTT em resume.
• DTLS 1.3 — suportado apenas em Q8, T2. Usado para CoAP-over-DTLS.

2. Matriz de suporte TLS dos 11 SKUs

Alguns factos pouco óbvios nessa tabela. Primeiro, DTLS (Datagram TLS) só é necessário para CoAP; a maioria das canetas utiliza TCP+TLS. Segundo, um Secure Element (Microchip ATECC608B ou NXP SE050) é opcional no Q8 e T2 — adicioná-lo custa 0,62 $ por unidade e armazena as chaves privadas em hardware resistente a adulterações. Exigimos o secure element para qualquer caneta enviada para a Alemanha, França ou Califórnia (CCPA), onde os riscos de adulteração são significativos. Terceiro, o hardware RNGImporta: um TRNG (gerador de números aleatórios verdadeiro) evita a fraqueza estatística das seeds RNG por software que afetou o BK7251 rev A em 2022.

Conselho para o comprador: Se a sua equipa de conformidade exige FIPS 140-2 ou Common Criteria EAL4+, tem de encomendar o Q8 ou T2 com o elemento seguro ATECC608B. Os outros 9 SKUs não conseguem cumprir essas certificações porque a chave privada está guardada em flash sem encriptação.

3. O Handshake TLS 1.2 vs 1.3, Medido

Um handshake TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256 equivale a duas voltas (round trips) mais a verificação do certificado. TLS 1.3 com ECDHE-ECDSA-P256 é uma volta (round trip) mais uma verificação de certificado encriptada. Numa ligação Wi-Fi limpa, os valores de wall-clock são:

Os números estabilizam quando separados por SKU:

Um handshake de 1-RTT em TLS 1.3 poupa 58% da latência de um handshake RSA TLS 1.2. Numa caneta alimentada a bateria, a poupança de energia importa ainda mais: o rádio permanece ativo ~1.5× mais tempo com TLS 1.2.

4. RSA vs ECDSA — A História do BOM

Os certificados são guardados na imagem de firmware ou num elemento seguro dedicado. Tamanhos:

Os certificados ECDSA-P256 são 54% mais pequenos do que RSA-2048 e verificam em 57% menos tempo de CPU. Para uma frota de 10.000 canetas, a poupança de flash por caneta acumula-se: 10.000 × 562 B = 5.6 MB de largura de banda OTA cumulativa poupada por rotação de certificado.

A realidade do BOM é que as cadeias ECDSA são ligeiramente mais caras de gerir no lado da cloud. AWS IoT, Azure IoT Hub e a maioria das PKI empresariais cobram praticamente o mesmo por qualquer um dos tipos de chave, por isso recomendamos ECDSA-P256 para todas as novas implementações.

5. Provisionamento de Certificados na ICT

Uma caneta de leitura tem de ter um certificado de cliente único para se autenticar na cloud. O nosso procedimento de Teste em Circuito (ICT) executa:

1. A caneta entra na VLAN de provisionamento.
2. A caneta chama o endpoint SCEP da CA da fábrica via HTTPS com um CSR (PKCS#10).
3. A CA assina o CSR com validade de 10 anos.
4. O certificado assinado é gravado no sector de NVM da caneta.
5. A caneta reinicia e tenta o handshake TLS com o broker MQTT.

O débito de assinatura da CA num Raspberry Pi 4 é de 3,4 certs/segundo. À cadência da linha ICT de 60 segundos/unidade, o provisionamento de certificados só é o estrangulamento em lotes muito grandes. Utilizamos um cluster de assinatura de 4 nós para atingir 12 certs/segundo em concursos acima de 20 000 unidades.

Em termos de custo no chão de fábrica, o ciclo de vida do certificado é de $0,10 por unidade (RSA-2048) ou $0,06 por unidade (ECDSA-P256). O diferencial de 38% é uma das razões pelas quais recomendamos ECDSA.

6. Estratégias de Rotação de Certificados

São implementadas três cadências de rotação nas frotas dos clientes:

• Rotação anual — a maioria dos MDM escolares. Renovação via OTA. Compatível com todas as 11 SKUs.
• Rotação a 90 dias — distritos de alta segurança, subsidiárias do setor financeiro. Requer Q8, T2 com ATECC608B; a chave privada não pode ser extraída.
• Rotação a pedido — resposta a compromisso. Forçamos a rotação via OTA em 18 minutos, incluindo download + instalação + reinício.

OCSP stapling e verificação de CRL estão ativados por defeito no firmware 3.3.1+ de Q8, T2. A caneta verifica a cadeia de certificados do servidor e valida a resposta OCSP stapled. Para uma frota de 100 000 canetas, o responder OCSP tem de servir 100 000 pedidos diários — operamos um responder OCSP Anycast com 4 PoPs para manter o p99 abaixo de 80 ms.

7. Predefinições de Cipher Suites

A lista predefinida de cipher suites de fábrica está documentada no nosso [Compliance Manual]. A ordenação completa, em L5/Q8/T2/Y6:

TLS 1.3:
  TLS_AES_128_GCM_SHA256         (prioridade 1)
  TLS_AES_256_GCM_SHA384         (prioridade 2)
  TLS_CHACHA20_POLY1305_SHA256   (prioridade 3, fallback)

TLS 1.2:
  ECDHE-ECDSA-AES128-GCM-SHA256  (prioridade 1)
  ECDHE-RSA-AES128-GCM-SHA256    (prioridade 2)
  ECDHE-ECDSA-AES256-GCM-SHA384  (prioridade 3)
  ECDHE-RSA-AES256-GCM-SHA384    (prioridade 4)

Nunca ativamos ciphers AES-CBC, RC4, MD5, SHA-1, 3DES ou export-grade. Um distrito escolar que execute um scanner TLS (testssl.sh, Qualys SSL Labs) contra o endpoint do broker da caneta vê apenas os cipher suites verdes.

8. Dados 0-RTT: Uma Armadilha Sutil

O TLS 1.3 introduz dados 0-RTT — o cliente pode enviar bytes da aplicação no primeiro voo, antes da mensagem Finished do servidor. Numa caneta de leitura isto poupa 240 ms no resume, mas os dados 0-RTT são vulneráveis a ataques de replay. Um atacante que capture o voo inicial pode reproduzi-lo contra o mesmo servidor dentro do tempo de vida do session ticket.

Por isso não utilizamos 0-RTT para:

• Comandos OTA de firmware (um replay causaria re-flash).
• Alterações de definições de controlo parental.
• Submissão de pontuações com impacto financeiro (pacotes de histórias pagos).

Utilizamos 0-RTT para:

• Publicação de telemetria (idempotente, substituída pelo pacote seguinte).
• Pedidos de sincronização de hora estilo NTP (idempotentes).
• Heartbeats (idempotentes).

9. Terminação TLS no Lado da Cloud

A recomendação de fábrica é terminar o TLS no broker da cloud (HiveMQ, EMQX, AWS IoT Core) ou numa edge CDN (CloudFront, Cloudflare). Para implementações escolares com brokers on-premise, a equipa de TI tem de gerir a rotação de certificados no broker. Fornecemos um módulo Terraform para AWS IoT Core e um Helm chart para EMQX em Kubernetes que automatiza a rotação com Let's Encrypt ou CA interna.

Para programas de estilo HIPAA (temos um no Midwest dos EUA para uma iniciativa hospitalar de leitura pediátrica), o broker tem de correr OpenSSL em modo FIPS. Q8 e T2 com ATECC608B mantêm o limite FIPS 140-2; o broker mantém o limite FIPS 140-3. FIPS 140 end-to-end representa um diferencial de BOM de $0,85 por unidade a 5 000 MOQ.

11. Mutual TLS para Integração com MDM Escolar

Para além da autenticação do servidor, várias plataformas MDM (Jamf School, Mosyle, Microsoft Intune for Education) exigem que a caneta se autentique com um certificado de cliente. Suportamos isto em Q8 e T2 com o secure element ATECC608B; a chave privada do certificado nunca sai do chip.

O fluxo de inscrição MDM:

1. O TI da escola envia um perfil MDM para o tablet do professor.
2. O professor emparelha Q8/T2 com o tablet via BLE.
3. O perfil MDM inclui o URL do endpoint SCEP (Simple Certificate Enrolment Protocol).
4. A caneta liga-se ao endpoint SCEP via HTTPS e apresenta um CSR.
5. A CA do SCEP assina o CSR com a sub-CA MDM da escola.
6. O certificado assinado é gravado no ATECC608B.
7. A inscrição MDM fica concluída.

12. Testes de Penetração e o OWASP IoT Top 10

O nosso firmware é testado anualmente contra o OWASP IoT Top 10 (revisão de 2024). A auditoria mais recente cobriu F8 3.1.2, K7 1.9.5, KF1 1.9.5, L5 4.2.0, Q6 3.3.1, Q8 3.3.1, T2 3.3.1 e Y6 2.6.4. A auditoria encontrou:

• I1 Palavras-passe fracas — aprovado. A predefinição de fábrica não tem palavra-passe definida pelo utilizador; o MDM atribui um PSK forte na inscrição.
• I2 Serviços de rede inseguros — aprovado. Todos os serviços exigem TLS 1.2 ou 1.3; portas em cleartext (80, 21, 23) estão desativadas.
• I3 Interfaces inseguras no ecossistema — aprovado. A API MDM exige mutual TLS com ECDSA-P256.
• I4 Falta de mecanismo de atualização seguro — conforme. Assinatura de imagem ECDSA-P256, contador anti-rollback, consulte TC-046.
• I5 Utilização de componentes inseguros — conforme. Sem bibliotecas de terceiros com CVEs conhecidos na nossa árvore de firmware.
• I6 Proteção de privacidade insuficiente — conforme. A telemetria é opcional; o equipamento é enviado com a telemetria desativada por predefinição.
• I7 Transferência de dados insegura — conforme. TLS 1.3 + ECDSA-P256 + disciplina 0-RTT.
• I8 Falta de gestão de dispositivos — conforme. Suporte MDM completo em Q8, T2.
• I9 Predefinições inseguras — conforme. As predefinições de fábrica são as mais restritivas.
• I10 Falta de endurecimento físico — parcial. KF1, L5, Q8, T2, Y6 têm pinos de deteção de adulteração; B1, B2, P2 não têm.

Os importadores podem solicitar o relatório de auditoria completo sob NDA. O relatório tem 84 páginas; o prazo de entrega é de 5 dias úteis.

13. Distribuição de CRL e OCSP Stapling na Prática

Uma frota escolar de 10 000 canetas gera uma carga PKI não trivial. Se cada caneta verificasse um certificado de servidor contactando o respondedor OCSP da AC em cada handshake TLS, a infraestrutura da AC entraria em colapso. Resolvemos isto com OCSP stapling no lado do broker: o broker obtém a resposta OCSP da AC a cada 4 horas e anexa-a ao handshake TLS.

As respostas OCSP anexadas são válidas durante 4 horas (correspondendo à cadência de atualização). A caneta verifica a resposta anexada contra a chave pública da AC, confirma a assinatura e prossegue. Se a resposta anexada estiver em falta ou expirada, a caneta recorre ao OCSP direto e pode bloquear entre 200–800 ms.

Para a distribuição da CRL, executamos um respondedor Anycast diário em 4 PoPs (Singapura, Frankfurt, Virgínia, São Paulo). A CRL tem 48 KB; as canetas obtêm-na através de um pedido HTTP range em cada handshake TLS bem-sucedido (em cache durante 24 horas). A largura de banda cumulativa por caneta por dia é de 2 KB. A taxa de falha da CRL no firmware 3.3.1 dos Q8/T2 é de 0,04% ao longo de mais de 47 000 canetas enviadas.

Para todas as novas implementações, a nossa recomendação é TLS 1.3 + ECDSA-P256 com ATECC608B para qualquer caneta acima de $25 de ASP a retalho. A poupança na latência do handshake, a redução do tamanho do certificado e o armazenamento seguro de chaves são a base de engenharia correta para 2026–2028.

Leitura relacionada

• IoT MQTT vs HTTP vs CoAP
• Encriptação de Dados AES-128 vs AES-256
• Mecanismo de Atualização OTA de Firmware
• Roaming Wi-Fi e Reconexão
• RGPD e Proteção de Dados na UE
• COPPA e Controlo Parental