O AES-GCM pode proteger a confidencialidade de uma mensagem e detetar alterações não autorizadas. Por si só, não informa o destinatário se uma mensagem que é válida nos restantes aspetos já foi processada.
É fácil confundir três requisitos: pares chave/nonce únicos para encriptação, autenticação da mensagem e do seu contexto e tratamento de repetições ao nível do protocolo. O HKDF pode ajudar a derivar chaves, mas não satisfaz automaticamente os três.
Reutilizar um nonce e repetir uma mensagem são eventos diferentes
| Evento | O que acontece | Proteção necessária |
|---|---|---|
| Reutilização de nonce durante a encriptação | Textos simples diferentes são encriptados com a mesma chave GCM e nonce | Uma estratégia fiável de atribuição de chave/nonce |
| Adulteração | O texto cifrado ou o contexto autenticado é alterado | Desencriptação autenticada e rejeição em caso de falha |
| Repetição | Uma mensagem encriptada anteriormente válida é entregue novamente | Estado e regras da aplicação que reconheçam duplicados ou mensagens desatualizadas |
| Reordenação | Mensagens válidas chegam numa ordem diferente | Ordenação definida pelo protocolo e tratamento limitado de mensagens fora de ordem |
Um texto cifrado repetido pode continuar a ter uma etiqueta de autenticação válida. Nada foi alterado. Por isso, é incorreto dizer que todos os duplicados falham automaticamente a autenticação AES-GCM. O RFC 5116 separa explicitamente a interface AEAD dos serviços de proteção contra repetição.
Porque o par chave e nonce não pode repetir-se
O nonce do GCM não precisa de ser secreto, mas tem de cumprir os requisitos de unicidade do esquema para uma dada chave. Um nonce de 96 bits, ou 12 bytes, é comum; escolher esse comprimento não garante uma geração correta.
Reutilizar a mesma chave e nonce para textos simples diferentes reutiliza o fluxo de encriptação, expondo relações entre os textos simples. Também pode comprometer a autenticidade e permitir falsificações. O impacto é grave, mas não deve ser descrito como revelando automaticamente todas as chaves antigas ou todas as mensagens de uma conta. O âmbito afetado depende da chave reutilizada e do protocolo.
O NIST SP 800-38D define o GCM e os seus requisitos. As implementações devem seguir os limites de invocação aplicáveis e as regras de geração de nonces, não uma regra simplista de «seguro até este número de mensagens».
O contributo do HKDF
O HKDF, especificado no RFC 5869, deriva material de chave a partir de material secreto de entrada, através de fases de extração e expansão. Os protocolos podem usar etiquetas de contexto e entradas distintas para separar chaves destinadas a finalidades diferentes.
O HKDF é determinístico. Se um cliente que falhou ou regressou a um estado anterior repetir o mesmo estado e as mesmas entradas, pode derivar novamente a mesma saída. Adicionar HKDF a um projeto não torna, portanto, impossível reutilizar nonces.
As chaves por mensagem podem reduzir a quantidade de conteúdo protegida por uma única chave, mas o avanço seguro do estado, a separação de chaves e a eliminação continuam a ser importantes. O mesmo valor de nonce com chaves genuinamente diferentes não constitui a mesma falha que repetir um par chave/nonce; o protocolo deve garantir que as chaves são realmente diferentes.
A proteção contra repetição pertence ao protocolo
Um destinatário pode acompanhar identificadores de mensagens, posições na sequência, épocas de sessão ou chaves de ratchet já consumidas. Os campos relevantes têm de ser autenticados para impedir que um atacante volte a identificar uma mensagem antiga como nova.
A aplicação tem depois de decidir o significado de um duplicado. Mostrar um balão de conversa duplicado é inconveniente; executar a mesma ação duas vezes pode ser mais grave. As novas tentativas de rede são normais, pelo que o processamento idempotente é frequentemente necessário juntamente com as verificações criptográficas.
Não exija que todas as mensagens válidas cheguem estritamente por ordem, a menos que o protocolo especifique esse comportamento. Os clientes móveis voltam regularmente a ligar-se, repetem tentativas e recebem mensagens atrasadas. O tratamento seguro distingue uma mensagem legitimamente tardia de uma mensagem já consumida ou com contexto incorreto.
O que testar antes de afirmar que existe proteção
- Reinicie depois de atribuir um nonce, mas antes de registar o envio: a atribuição pode repetir-se?
- Restaure uma captura de estado mais antiga: as chaves, os contadores ou os registos de repetição podem retroceder?
- Envie simultaneamente a partir de dois processos de trabalho ou dispositivos: os seus domínios chave/nonce estão separados?
- Entregue a mesma mensagem válida duas vezes: a ação da aplicação é executada uma vez?
- Altere um identificador de sessão ou cabeçalho: o contexto está vinculado criptograficamente?
- Entregue mensagens válidas fora de ordem: os atrasos suportados são tratados sem aceitar estado desatualizado?
As APIs de desencriptação autenticada só devem devolver texto simples à aplicação após uma verificação bem-sucedida. É um requisito da interface; não é a afirmação de que nenhuma implementação calcula alguma vez internamente um buffer temporário de texto simples.
Interpretar corretamente as afirmações da Livara
A documentação de segurança da Livara menciona AES-256-GCM, cadeias por mensagem e contexto LVR1/LGS1. Estas primitivas não provam, por si só, uma recuperação correta após falhas, a atribuição correta de nonces ou a rejeição de repetições. Tais afirmações exigem detalhes do protocolo identificados por versão e provas de testes.
Um projeto sólido atribui explicitamente cada tarefa: a derivação de chaves cria as chaves pretendidas, o AEAD autentica o conteúdo e o contexto, e a lógica de protocolo com estado decide se uma mensagem válida é aceitável agora.
