Segurança Digital
HMAC
HMAC cobre integridade e autenticação de mensagens, mas não confidencialidade: o conteúdo continua legível. Definido pela RFC 2104 e padronizado também no FIPS 198‑1, combina uma chave secreta com hashes internos e externos; HMAC‑SHA‑256 produz 256 bits antes de truncamento. Em uma casa inteligente, pode assinar webhooks, comandos MQTT e tokens internos. A consequência prática é detectar alteração e origem não autorizada, desde que a chave seja única, protegida e a verificação inclua nonce ou timestamp para impedir replay.
🛡 Níveis de Segurança
Recomendado
HMAC-SHA-256 com chave aleatória
HMAC é um Message Authentication Code baseado em hash. Ele usa uma chave secreta K e uma função hash H em duas camadas com pads distintos: `H((K' xor opad) || H((K' xor ipad) || text))`. Essa construção evita problemas de simplesmente concatenar chave e mensagem, como length extension em hashes Merkle–Damgård. HMAC-SHA-256 é uma escolha ampla. A saída completa tem 32 bytes. O protocolo pode truncar, mas precisa definir tamanho. Para webhooks e comandos, 128 bits de tag costuma oferecer margem, mas usar a saída completa simplifica. A chave deve ser gerada por CSPRNG com pelo menos a força desejada, por exemplo 32 bytes. Não usar senha humana diretamente. Se a origem é senha, derivar por Argon2/PBKDF2 ou usar segredo aleatório. Cada integração deve ter chave própria. Uma chave global em todos os hubs transforma vazamento de um em comprometimento geral. O emissor calcula sobre uma representação canônica da mensagem e envia tag, timestamp, nonce e identificador. O receptor reconstrói exatamente e verifica em tempo constante. Só depois processa. Se o corpo JSON é parseado e reserializado, espaços e ordem podem mudar. É melhor assinar bytes recebidos ou um formato canônico definido. O cabeçalho deve indicar versão e algoritmo sem permitir downgrade. O receptor possui lista explícita. Nunca aceitar `alg=none`. HMAC autentica quem conhece a chave; não prova qual das duas partes assinou, porque ambas podem gerar. Para não repúdio ou múltiplos verificadores sem compartilhar segredo, usar assinatura digital.
Operacional
HMAC com anti-replay
Uma tag válida pode ser capturada e repetida. HMAC sozinho não sabe se a mensagem é nova. Protocolos devem incluir timestamp, contador ou nonce no material autenticado. Um webhook pode assinar `timestamp + '.' + body` e o receptor aceitar apenas janela de 5 minutos, usando relógio NTP. Para evitar repetição dentro da janela, guardar event ID ou nonce. O emissor gera UUID. O receptor usa cache com TTL. Em dispositivos offline, contadores monotônicos são melhores, mas precisam persistir em flash sem desgaste. Uma janela de sequência tolera perda. A mensagem inclui device ID, destination, command, parameters, sequence e expiry. Tudo é autenticado. Não assinar apenas o corpo e deixar rota, método ou destino fora. Um ataque pode mover. APIs podem assinar método HTTP, path, query canônica, host, content hash e timestamp. Esquemas como AWS SigV4 mostram o conceito, mas a implementação deve seguir uma especificação, não improvisar. Em MQTT, a camada TLS autentica o broker, mas HMAC no payload pode fornecer autenticidade fim a fim entre dispositivo e serviço quando brokers são intermediários. As chaves precisam ser provisionadas. O broker não precisa saber. Isso melhora. Porém, rotação e revogação ficam complexas. Um HMAC inválido deve ser rejeitado e registrado sem incluir chave ou payload sensível. Rate limit evita CPU e logs.
Componente
HMAC em KDFs e tokens
HMAC é usado como componente em PBKDF2, HKDF, TLS, IPsec, JWT com algoritmos HS256/384/512, TOTP e muitos protocolos. O uso interno não significa que o desenvolvedor deve chamar HMAC diretamente. HKDF define extract e expand com domínio e segurança. PBKDF2 define iterações. JWT HS256 usa HMAC-SHA-256 sobre header e payload codificados. A chave precisa ter entropia de pelo menos o nível do algoritmo. Uma senha curta como `secret` é inadequada. Em arquitetura com muitos serviços, HS256 exige que todos os verificadores conheçam a chave e possam emitir tokens. Isso aumenta risco. RS256 ou EdDSA permitem que serviços apenas verifiquem com chave pública. O critério é confiança. HMAC é eficiente e simples quando emissor e verificador são o mesmo serviço ou um conjunto pequeno igualmente confiável. Para webhooks de uma plataforma para um cliente, é adequado. Para identidade federada com dezenas de APIs, assinatura assimétrica costuma ser melhor. TOTP usa HMAC com contador de tempo, mas é uma especificação completa. Não criar OTP apenas truncando HMAC arbitrariamente. Interoperabilidade exige algoritmo, truncamento, codificação e janela definidos.
Risco
Chave compartilhada sem rotação
O risco principal de HMAC é a chave. Se embutida no firmware de todos os dispositivos, extraí-la de um permite falsificar qualquer dispositivo. Chaves por unidade e armazenamento em secure element reduzem. Se a mesma chave autentica dois contextos, uma mensagem de um pode ser reutilizada no outro. Incluir label de domínio ou derivar subchaves por HKDF: `info='webhook-v1'`, `info='mqtt-command-v1'`. Não usar a chave HMAC como chave AES. A rotação deve permitir duas versões por período: emissor usa nova, receptor aceita nova e antiga até expiração. Um key ID seleciona. O ID não é secreto. A chave antiga é revogada. Em hubs offline, a rotação precisa de entrega segura. Chaves nunca ficam em logs, URL, código público ou backup sem cifra. Variáveis de ambiente têm riscos, mas são melhores que repositório; secret manager é preferível. Comparação com `==` pode vazar timing em serviços remotos, embora exploração dependa de ruído; usar função constante. Não verificar tag depois de executar. Não retornar detalhes diferentes para tag incorreta versus key ID desconhecido se isso ajuda enumeração.
🖥 Aplicações em Hardware
🔒
Gateway local
Assinatura de comandos entre serviços
Um gateway recebe comandos de um motor de automação por fila. Cada mensagem contém device ID, action, value, sequence, expires e HMAC-SHA-256. A chave entre os dois serviços é derivada de segredo mestre com HKDF e label. O gateway verifica, checa tempo e sequência e executa. A fila não conhece a chave. Respostas também. O segredo fica em TPM ou arquivo restrito. Rotação por key ID. Essa camada não substitui mTLS, mas reduz risco do broker. O gateway limita. Comandos de fechadura exigem autorização do usuário antes de serem assinados. A assinatura não decide. Logs incluem ID e resultado, não tag completa.
🔒
Cloud
Webhook de eventos para Home Assistant ou parceiro
A plataforma gera um segredo aleatório de 32 bytes por endpoint. O cliente o vê uma vez. Para cada evento, calcula HMAC sobre timestamp e corpo. Envia versão, key ID, timestamp e tag em hex/base64. O receptor aceita 300 s, guarda event ID por 24 h e verifica. Retries usam o mesmo ID e podem ser tratados idempotentemente. O segredo pode ser rotacionado com dois ativos. A URL também deve ser aleatória e HTTPS, mas não é o segredo principal. O endpoint limita tamanho. A documentação fornece exemplos em Python, Node e Go e vetores. Isso reduz erros.
🔒
Firmware
Autenticação de mensagens em barramento restrito
Um microcontrolador pode usar HMAC-SHA-256 para autenticar pacotes quando criptografia completa não é possível, desde que exista chave única e anti-replay. A tag pode ser truncada a 16 bytes para reduzir overhead, com especificação. O pacote inclui contador persistente e device ID. A verificação ocorre antes de alterar relé. A chave fica em secure element ou flash protegida. Um atacante com acesso físico pode extrair se não. O contador precisa sobreviver sem desgastar; usar journal. Para redes de rádio, confidencialidade pode ser necessária, então AEAD é melhor. HMAC isolado não oculta. Não implementar SHA do zero; usar biblioteca auditada e aceleração quando disponível.
🔒
Identidade
JWT HS256 em serviço único
Um serviço monolítico pode emitir e verificar JWT com HS256 usando chave de 32 bytes ou mais. O verificador fixa algoritmo, valida `iss`, `aud`, `exp`, `nbf` e tipo. Não usa a mesma chave de webhook. A chave é rotacionada por `kid`. Quando múltiplas APIs de equipes diferentes precisam verificar, HS256 distribui poder de emissão a todas; então preferir assinatura assimétrica. O token não deve carregar dados sensíveis porque é apenas assinado. HTTPS. A sessão pode ser revogada por expiração curta e lista. HMAC é componente; seguir RFC 8725.