Senhas únicas, autenticação e gestão segura de credenciais
A provisão mais conhecida determina que senhas universais padrão não sejam usadas. Um fabricante não deve enviar dez mil câmeras com `admin/admin`. Quando uma senha existe, ela precisa ser única por dispositivo ou definida pelo usuário durante a configuração. Alternativas sem senha também podem atender, como pareamento autenticado, certificados ou tokens. O mecanismo precisa resistir a tentativas automatizadas conforme o risco. A norma trata credenciais como ativos. Elas devem ser armazenadas com proteção, transmitidas por canais adequados e não codificadas de forma recuperável no firmware. Chaves privadas por dispositivo não devem ser compartilhadas em toda a linha. Interfaces de recuperação precisam de segurança. Um reset de senha não pode ser disparado por informação pública. Em casa inteligente, o aplicativo, a cloud, o hub e o dispositivo podem ter credenciais distintas. O fabricante precisa mapear. O usuário não deve ser obrigado a criar uma senha fraca por limite de 8 caracteres. O produto pode incentivar gestores de senha e MFA para contas cloud. A norma é orientada a resultados e não impõe um único algoritmo. A implementação precisa seguir boas práticas. Senhas armazenadas no servidor usam derivação como Argon2id ou PBKDF2 com parâmetros adequados. Dispositivos podem usar certificados. O onboarding precisa evitar código impresso reutilizável que qualquer visitante fotografa. Matter usa códigos e processo próprio, mas o fabricante ainda precisa proteger a conta e a atualização. Credenciais de serviço, debug e fabricação também entram. Uma porta serial com senha fixa é vulnerabilidade. A remoção de interfaces desnecessárias e o bloqueio de debug em produção são necessários. A conformidade deve considerar o ciclo de vida, inclusive reparo. O técnico autorizado precisa de mecanismo rastreável, não senha mestre publicada.
Política de vulnerabilidades e atualização segura de software
O fabricante precisa oferecer meio público para receber relatórios de vulnerabilidade, informar política e agir. Um endereço de contato, processo de triagem e prazo são necessários. ISO/IEC 29147 e 30111 podem orientar divulgação e tratamento. A empresa deve monitorar componentes e dependências. Um CVE em biblioteca TLS usada por câmera precisa ser avaliado. O produto deve manter software atualizado de forma segura. A atualização precisa verificar autenticidade e integridade, normalmente por assinatura digital. O canal deve ser protegido quando necessário. Rollback precisa ser controlado. Uma imagem antiga vulnerável não deve ser aceita sem política. O mecanismo deve ser simples ao usuário. Atualização automática pode reduzir exposição, mas precisa de janela, recuperação e transparência. O fabricante deve informar o período de suporte. A EN 303 645 estabelece que o usuário seja informado sobre a duração mínima de atualizações de segurança. A redação e o esquema regulatório aplicável precisam ser consultados. Em 2024, a ETSI publicou orientações adicionais e desenvolve evolução para requisitos europeus. O prazo deve ser concreto, como “até dezembro de 2030”, não “por tempo razoável”. O produto deve permanecer seguro durante falha de energia. Atualização A/B, partição de recuperação e bootloader protegido ajudam. Uma atualização não pode apagar configuração sem aviso. O processo de assinatura precisa proteger chaves em HSM e limitar acesso. Se a chave de assinatura vaza, rotação e revogação são necessárias. A norma não define HSM específico, mas o risco exige. Produtos sem capacidade de atualização precisam justificar e ter risco reduzido, o que é difícil para dispositivos conectados de longa vida.
Proteção de dados, comunicação e minimização da superfície de ataque
Dados pessoais devem ser protegidos em trânsito e armazenamento, de acordo com sensibilidade. Vídeo, áudio, presença, localização e registros de fechadura são altamente sensíveis. TLS atualizado, autenticação de servidor e validação de certificado são esperados. Criptografia sem verificação de identidade não basta. Chaves precisam ser geridas. O dispositivo deve se comunicar de forma segura. Protocolos legados em LAN, como HTTP sem TLS, Telnet e FTP, devem ser desativados ou justificados. Serviços, portas e funções não usados devem ser removidos. Princípio do menor privilégio se aplica. Um processo de câmera não precisa escrever no bootloader. O firmware deve separar. Inputs precisam de validação. APIs não devem confiar no app. O backend autoriza cada dispositivo e usuário. A norma também aborda integridade do software e segurança de dados. Logs não devem expor segredos. A coleta deve ser minimizada. O usuário precisa de meios para excluir dados quando aplicável e entender o uso. Telemetria de diagnóstico não deve capturar áudio sem necessidade. O produto deve facilitar configuração e manutenção seguras. Defaults precisam ser seguros. UPnP que abre porta automaticamente pode aumentar superfície. Acesso remoto deve usar conexão de saída ou mecanismo autenticado. O manual precisa explicar. A interface local não deve expor chave Wi‑Fi em texto. Em Bluetooth, o pareamento precisa evitar Just Works para funções críticas quando possível. Em Zigbee, chaves globais conhecidas representam risco; o processo deve usar instalação segura. Matter possui commissioning e certificados, mas implementações e cloud ainda precisam. A EN 303 645 não certifica o protocolo isolado. Ela avalia o produto e os serviços associados.
Resiliência, telemetria de segurança e exclusão simples de dados
O produto deve continuar resiliente diante de indisponibilidade de rede, ataques básicos e falhas. Uma lâmpada deve manter controle local ou estado seguro quando a cloud cai, conforme função. Uma fechadura precisa de comportamento claramente definido. Dependência de DNS ou NTP não deve causar abertura. Watchdogs, limites de recursos, rate limiting e recuperação ajudam. O sistema deve examinar dados de telemetria de segurança quando apropriado. Falhas repetidas de login, reinícios e integridade podem ser registradas. A coleta precisa respeitar privacidade. O usuário deve ter maneira simples de apagar dados pessoais do dispositivo, especialmente antes de venda ou descarte. O reset de fábrica precisa remover credenciais, tokens e vínculos. Apenas apagar a interface não basta se chaves permanecem. O backend deve desvincular. O produto precisa tornar instalação e manutenção fáceis. Instruções de atualização, suporte e configuração devem ser acessíveis. A validação de dados de entrada reduz injeção e corrupção. Interfaces críticas precisam de proteção contra brute force. O dispositivo deve minimizar dados. Cada campo coletado deve ter finalidade. A segurança precisa ser verificável. A ETSI TS 103 701 fornece uma especificação de avaliação de conformidade com testes e evidências para a EN 303 645. Isso melhora comparabilidade. Ainda assim, diferentes esquemas de certificação podem ter profundidades distintas. Um autodeclarado e um ensaio de laboratório não são equivalentes. O comprador precisa ver escopo, versão e organismo. A norma é baseline. Produtos críticos, como fechaduras e câmeras, podem exigir controles adicionais. Regulamentos europeus, como RED e Cyber Resilience Act, acrescentam obrigações em evolução. A conformidade deve ser atualizada.