Princípios de Design de Protocolos Seguros

O projeto de protocolos seguros pressupõe um adversário que controla completamente a rede. O modelo de Dolev-Yao (1983) especifica que o adversário pode interceptar, ler, atrasar, repetir, excluir e modificar qualquer mensagem em trânsito. O adversário pode gerar mensagens indistinguíveis das mensagens das partes honestas. Ele pode compor novas mensagens a partir de componentes de mensagens conhecidos. O adversário não pode quebrar primitivas criptográficas (descriptografar sem a chave ou forjar assinaturas). É fundamental que o adversário seja limitado computacionalmente — execute em tempo polinomial —, mas controle todos os canais de comunicação. A segurança do protocolo significa alcançar objetivos de autenticação e sigilo mesmo contra esse adversário poderoso, confiando apenas na dificuldade computacional das primitivas subjacentes.

Abadi e Needham (1994) condensaram lições práticas de projeto de protocolos em um conjunto de princípios. (1) Toda mensagem deve indicar o que significa: a interpretação de uma mensagem deve ser autossuficiente, não depender do contexto. (2) As condições para uma entidade executar uma ação devem ser declaradas explicitamente no protocolo. (3) Se a identidade de uma entidade for importante, ela deverá ser declarada explicitamente na mensagem. (4) Seja claro sobre o motivo do uso da criptografia: a criptografia fornece confidencialidade, enquanto a assinatura fornece autenticação — não use criptografia como substituto da assinatura. (5) Uma mensagem deve ser criptografada na camada do protocolo em que seu sigilo é necessário. Esses princípios impediram muitas falhas do tipo NS.

Ataques de repetição estão entre as vulnerabilidades mais comuns dos protocolos. Mecanismos de frescor garantem que uma mensagem recebida foi gerada recentemente, e não repetida a partir de uma sessão antiga. Há duas abordagens: (1) Valores de uso único (número usado ONCE) — um desafio-resposta no qual o receptor envia um valor aleatório e espera que ele seja repetido na resposta. A resposta deve conter o valor de uso único criptografado ou assinado, impedindo que uma gravação antiga satisfaça o desafio. (2) Carimbos de data e hora — ambas as partes incluem a hora atual; uma mensagem com um carimbo desatualizado é rejeitada. Os carimbos exigem relógios sincronizados (o Kerberos permite um desvio de cinco minutos). Os valores de uso único são preferíveis quando a sincronização de relógios não está disponível; os carimbos simplificam a verificação sem estado.

Usar a mesma chave criptográfica para várias finalidades cria interações perigosas. Se uma chave K for usada tanto para criptografia quanto para autenticação, um adversário poderá fornecer textos cifrados manipulados ao mecanismo de autenticação para extrair informações. O TLS 1.3 evita isso rigorosamente por meio de HKDF-Expand-Label, usando rótulos distintos para cada chave derivada: "c hs traffic" (negociação do cliente), "s hs traffic" (negociação do servidor), "c ap traffic" (aplicação do cliente). Mesmo que a chave da negociação seja comprometida, as chaves da aplicação derivadas de um ramo HKDF diferente permanecem seguras. Os projetos de protocolos devem auditar cada chave quanto a riscos de uso múltiplo e derivar chaves separadas para finalidades separadas.

As credenciais de autenticação devem estar vinculadas à sessão específica em que são usadas. Sem essa vinculação, uma credencial obtida em uma sessão pode ser reproduzida em outra. Técnicas: (1) incluir identificadores de sessão nos dados assinados ou protegidos por MAC; (2) incluir a transcrição DH na assinatura (abordagem STS); (3) usar a chave de sessão derivada por HKDF para calcular um MAC sobre a identidade (abordagem SIGMA). A mensagem de finalização do TLS 1.3: MAC(server_finished_key, transcript_hash) — o MAC abrange a transcrição completa, portanto reproduzir uma mensagem de finalização de outra sessão falha. É essa vinculação que impede os ataques entre sessões encontrados nas primeiras variantes do Kerberos e do NS.

Os protocolos devem divulgar somente as informações mínimas necessárias à sua função. Revele as identidades apenas a quem precisa delas. Não inclua números de série de certificados nem identificadores que permitam vincular sessões a identidades, salvo quando isso for necessário. O TLS 1.3 criptografa o certificado do servidor (ao contrário do TLS 1.2, no qual ele é transmitido em texto simples), reduzindo as informações disponíveis para um observador passivo. O ESNI (SNI criptografado, atualmente ECH — ClientHello criptografado) criptografa a indicação do nome do servidor para ocultar a qual servidor o cliente está se conectando. A divulgação mínima de informações também é um princípio do projeto de tokens: as declarações de JWT devem conter apenas o necessário para a autorização, não registros completos de identidade.

A negociação de versões é uma superfície de ataque comum: um adversário remove ou modifica o ClientHello para forçar ambas as partes a usar uma versão mais antiga e mais fraca do protocolo. Defesas: (1) negociação autenticada de versões — inclua a versão negociada na transcrição assinada (a mensagem de finalização do TLS abrange o ClientHello, incluindo a versão); (2) sentinelas de rebaixamento — o TLS 1.3 define bytes mágicos em ServerHello.Random ao rebaixar para o TLS 1.2, permitindo que o cliente detecte o rebaixamento; (3) prevenção da intolerância a versões — os servidores devem rejeitar ClientHellos malformados sem recuar silenciosamente para uma versão anterior; (4) SCSV — TLS_FALLBACK_SCSV sinaliza ao servidor que o cliente está tentando novamente com uma versão inferior, permitindo que o servidor rejeite recuos ilegítimos.

As mensagens do protocolo devem estar comprometidas desde a primeira troca. Não maleabilidade significa que um adversário não pode modificar um texto cifrado ou uma assinatura e fazer com que ela seja validada em um contexto diferente. O AEAD fornece não maleabilidade ao texto cifrado — qualquer modificação invalida a tag de autenticação. No nível do protocolo, o cálculo do hash da transcrição garante que a troca de finalização ao fim do handshake inclua um compromisso com todas as mensagens enviadas. Isso impede ataques de recortar e colar: intercalar mensagens de duas sessões diferentes não pode produzir um valor de finalização válido para nenhuma delas. Esquemas de compromisso (compromissos baseados em hash) estendem essa propriedade a fluxos de protocolo que exigem um pré-compromisso antes da revelação.

Protocolos complexos frequentemente falham nas fronteiras entre estados. Se uma transição de estado for ambígua — o que acontece se a mensagem 3 chegar antes da mensagem 2? e se chegar um tipo de mensagem inesperado? — as implementações poderão divergir, criando inconsistências que um adversário pode explorar. As especificações de protocolos devem definir: a máquina de estados completa (todos os estados e transições válidas), o comportamento diante de entradas inesperadas (rejeitar com um erro específico ou ignorar silenciosamente), os tempos limite e os limites de retransmissão, além da limpeza da sessão. O SSL/TLS historicamente sofreu com divergências de implementação nas máquinas de estados — o CVE-2014-0160 (Heartbleed) foi essencialmente uma falha de máquina de estados na qual uma solicitação de pulsação foi processada em um estado em que a memória não tinha limites adequados.

Protocolos criptográficos raramente são usados isoladamente. Um protocolo AKE estabelece uma chave de sessão, que depois é usada por um protocolo da camada de aplicação. Se o AKE e o protocolo da aplicação forem projetados de forma independente, sem considerar a componibilidade, as interações poderão comprometer a segurança. A estrutura de Componibilidade Universal (UC) (Canetti, 2001) fornece um modelo rigoroso para a composição de protocolos: um protocolo é seguro no modelo UC se continuar seguro quando composto arbitrariamente com outros protocolos seguros no modelo UC. TLS 1.3, Signal e Noise buscam oferecer segurança componível. Na prática: use a vinculação de canal (exporte o hash da transcrição) para vincular a sessão AKE à autenticação posterior da aplicação, impedindo o encaminhamento de credenciais entre sessões estabelecidas pelo mesmo protocolo AKE.

Projetistas de protocolos repetidamente cometem as mesmas categorias de erros. (1) Criar a própria criptografia: implementar cifras de bloco, códigos MAC ou derivação de chaves personalizados sem revisão por pares. (2) Confiança implícita: presumir a origem de uma mensagem com base no contexto da rede, em vez de uma prova criptográfica. (3) Segurança opcional: tornar a criptografia ou a autenticação configurável, o que inevitavelmente leva a rebaixamentos. (4) Tokens de longa duração sem revogação: emitir JWTs ou chaves de sessão com longos períodos de validade e sem um mecanismo de revogação. (5) Ignorar o canal de erros: não autenticar mensagens de erro permite que um adversário injete erros para influenciar o comportamento do protocolo. (6) Usar criptografia para autenticação: criptografar dados não autentica sua origem sem um MAC ou uma assinatura.

O projeto seguro de protocolos aplica princípios consolidados: o modelo de adversário de Dolev-Yao (um adversário que controla a rede), os princípios de Abadi-Needham (identidade explícita e mensagens autossuficientes), a novidade garantida por valores de uso único ou marcas de tempo, a separação de chaves por meio de HKDF com rótulos distintos, a vinculação das credenciais de autenticação à sessão, a divulgação mínima de informações, a prevenção de rebaixamentos por meio da autenticação da transcrição, a não maleabilidade por meio de AEAD e do cálculo do hash da transcrição, máquinas de estados claras com tratamento de erros definido e a componibilidade por meio de provas de segurança no modelo UC. As violações desses princípios estão na origem de quase todas as vulnerabilidades criptográficas conhecidas no nível do protocolo.