Protocolo Station-to-Station (STS)

O protocolo Station-to-Station (STS) (Diffie, van Oorschot, Wiener, 1992) foi projetado para fornecer acordo de chaves autenticado sem uma terceira parte confiável. A troca de chaves Diffie-Hellman pura não é autenticada — um intermediário pode substituir os próprios valores DH, estabelecendo sessões separadas com cada parte, que acredita compartilhar uma chave com a outra. O STS combina DH com assinaturas digitais e certificados de chave pública para fornecer autenticação mútua. As partes se autenticam assinando a transcrição DH, vinculando a chave de sessão às suas identidades. O STS influenciou diretamente o projeto do IKE (Internet Key Exchange para IPsec) e do SSH.

O protocolo STS prossegue da seguinte forma. Alice e Bob concordam sobre um grupo DH (primo p, gerador g). (1) Alice envia g^a mod p para Bob. (2) Bob envia g^b mod p, Cert_B, Sig_B{g^b, g^a} para Alice. Bob assina a concatenação dos dois valores DH usando sua chave privada. (3) Alice verifica o certificado e a assinatura de Bob e então envia Cert_A, Sig_A{g^a, g^b} criptografados com a chave de sessão K = (g^ab mod p). A identidade e a assinatura de Alice são criptografadas, fornecendo proteção à identidade de Alice — observadores passivos não podem associar Alice a esta sessão. Ambas as partes calculam K = g^ab mod p e são autenticadas mutuamente por meio das assinaturas.

Comparar o STS com o DH não autenticado ilustra o que a autenticação acrescenta. No DH simples, Mallory intercepta g^a e g^b, substitui-os por g^m para Alice e g^m para Bob, estabelecendo K1 = g^am e K2 = g^bm. Mallory descriptografa todo o tráfego. No STS, Bob assina {g^b, g^a} — essa assinatura cobre exatamente os valores DH desta sessão. Mesmo que Mallory substitua g^b por g^m, não pode forjar uma assinatura válida usando a chave do certificado de Bob. Alice rejeita a sessão. A ideia principal: a autenticação na troca de chaves deve abranger a transcrição DH, não apenas declarações de identidade.

O STS alcança sigilo de encaminhamento perfeito (PFS) porque a chave de sessão é derivada de valores DH efêmeros (g^a, g^b), que são descartados após a sessão. Mesmo que a chave de assinatura de longo prazo de Bob seja comprometida posteriormente, sessões STS registradas anteriormente não podem ser descriptografadas — o invasor precisa dos expoentes DH efêmeros a e b, que nunca foram armazenados. Esta é a mesma propriedade valorizada no TLS com conjuntos de cifras ECDHE. Sem DH efêmero (por exemplo, usando transporte de chaves RSA, em que a chave de sessão é criptografada com a chave RSA estática do servidor), o comprometimento da chave de longo prazo descriptografa todas as sessões anteriores.

O STS criptografa o certificado e a assinatura de Alice na etapa 3, fornecendo proteção à identidade do respondente contra observadores passivos. Um observador passivo vê apenas o valor DH de Alice e o certificado de Bob (que Bob envia em texto aberto na etapa 2). A identidade de Alice fica oculta contra a observação passiva. Invasores ativos que montam um MITM são detectados pela falha na verificação da assinatura. Essa assimetria (a identidade da iniciadora é revelada ao invasor ativo, enquanto a identidade do respondente é protegida contra o observador passivo) é uma decisão de projeto deliberada — a proteção completa da identidade de ambas as partes contra invasores ativos exige complexidade adicional no protocolo (pré-compartilhamento de valores DH ou uso de elementos de grupo anônimos).

O IKE (Internet Key Exchange), protocolo de gerenciamento de chaves para IPsec, deriva diretamente do STS. O IKEv1 (RFC 2409) implementou autenticação por assinatura no estilo STS em seu Modo Principal. O IKEv2 (RFC 7296) é uma reformulação mais simples, com quatro fluxos de mensagens: IKE_SA_INIT (troca DH, nonces), IKE_AUTH (identidade, certificado, assinatura sobre a transcrição do IKE_SA_INIT). O formato da assinatura é AUTH = PRF(SK_pi, transcript) para PSK ou uma assinatura digital sobre os octetos do IKE_SA_INIT para autenticação por certificado. O IKEv2 também oferece suporte ao Protocolo de Autenticação Extensível (EAP) para autenticação legada baseada em senha, de modo análogo ao suporte do STS a vários métodos de autenticação.

A autenticação por chave do SSH usa um mecanismo semelhante à etapa 3 do STS. Após a troca de chaves DH (SSH_MSG_KEXDH_REPLY contém a chave pública do servidor, o valor DH e uma assinatura sobre o resumo da troca), o cliente verifica a chave do servidor. Para a autenticação do cliente (SSH_MSG_USERAUTH_REQUEST com o método publickey), o cliente assina {session_id, username, service, method, key_algo, public_key} usando sua chave privada. O session_id é derivado da transcrição DH, vinculando a autenticação a esta sessão específica — o que impede a falsificação entre sessões que afetava o NS. O SSH não usa certificados por padrão, mas oferece suporte a eles por meio de ssh-keygen -s (assinatura de certificados) em implantações de grande porte.

O STS é membro da família SIGMA (SIGn-and-MAc) de protocolos de troca de chaves autenticada (AKE), formalizada por Hugo Krawczyk. O SIGMA acrescenta um MAC ao STS: cada parte assina a transcrição e calcula um MAC de sua identidade usando a chave de sessão: MAC(K, identity). O MAC vincula a identidade à chave de sessão, impedindo um ataque específico no qual um adversário pode associar assinaturas de sessões diferentes. SIGMA-I (identidade da iniciadora protegida), SIGMA-R (identidade do respondente protegida) e SIGMA-0 (sem proteção de identidade) são variantes. O IKEv2 e o X3DH do Signal são protocolos da família SIGMA. O formalismo SIGMA fornece uma prova rigorosa de segurança para projetos semelhantes ao STS.

O STS é vulnerável à Impersonação após comprometimento de chave (KCI): se a chave de longo prazo de Alice for comprometida, um invasor poderá se passar por qualquer parte perante Alice em uma nova sessão (porque pode forjar a assinatura de Alice sobre qualquer transcrição). Isso significa que o comprometimento da chave de uma parte permite que um adversário se passe por outras partes perante ela. O KCI é inerente aos protocolos AKE baseados em assinaturas — para se defender contra ele, é necessário que a chave de sessão dependa das contribuições de ambas as partes de uma maneira que impeça a parte comprometida de substituí-las. HMQV (Hashed Menezes-Qu-Vanstone) e NAXOS oferecem resistência a KCI ao custo de complexidade adicional.

O STS fornece não repúdio: as assinaturas provam quem disse o quê, com certeza criptográfica. Isso às vezes é indesejável — em conversas privadas, os participantes podem não querer que provas criptográficas de suas declarações possam ser apresentadas em um tribunal. As mensagens Off-the-Record (OTR) e o Double Ratchet do Signal fornecem negabilidade: em vez de assinar mensagens, usam chaves MAC que ficam tanto com o remetente quanto com o destinatário. Depois da conversa, ambas as partes podem alegar que a outra forjou as mensagens, pois cada uma possui a chave necessária para produzir os MACs. O compromisso é o seguinte: a negabilidade sacrifica o não repúdio. Projetos semelhantes ao STS são apropriados quando é necessário responsabilização; OTR/Signal, quando a negabilidade é valorizada.

A segurança do STS foi analisada informalmente no artigo original, mas foi provada formalmente por Bellare e Rogaway (1993, 1994) em seu marco sobre o modelo de segurança AKE. Eles definiram o que significa uma troca de chaves ser segura: indistinguibilidade das chaves de sessão em relação a valores aleatórios, mesmo quando o adversário pode registrar partes, revelar chaves de sessão, revelar chaves de longo prazo (exceto as da sessão-alvo) e controlar a rede. Esse modelo de segurança baseado em simulação, ampliado por Canetti-Krawczyk e posteriormente por UC (Composição Universal), é hoje padrão para provar protocolos AKE. TLS 1.3, Signal e Noise possuem provas formais em variantes desse modelo.

Por que o STS exige que ambos os valores DH (g^a e g^b) sejam incluídos na transcrição assinada?

O STS combina a troca de chaves DH efêmeras com assinaturas digitais para fornecer um acordo de chaves autenticado sem uma TTP. Ambas as partes assinam a transcrição DH, vinculando a autenticação à sessão. O STS proporciona sigilo de encaminhamento (DH efêmero), autenticação mútua (assinaturas) e proteção da identidade do respondente (os dados de Alice são criptografados antes do envio). O STS influenciou diretamente a autenticação de chaves do IKEv2 e do SSH. O SIGMA formaliza o STS com MACs de identidade e provas de segurança. O KCI é uma vulnerabilidade inerente ao STS, mitigada pelo HMQV/NAXOS. A negabilidade, como no Signal, exige substituir assinaturas por códigos de autenticação de mensagens para obter autenticidade no nível da mensagem.