01 - Cifragem Dupla (Host e Server Key)

A Cifragem e Assinatura na Troca de Chaves do SSH (frequentemente chamada de "Cifragem Dupla" em nível conceitual) é o mecanismo que une o sigilo da troca Diffie-Hellman à autenticidade da identidade do servidor. Padronizada na RFC 4253, esta fase do handshake garante que o cliente não apenas gerou um segredo compartilhado (K) com um computador qualquer, mas sim com o servidor real e legítimo. É nesta orquestra técnica que o segredo matemático encontra o certificado de identidade da máquina, blindando a conexão contra ataques de personificação (Impersonation).

1. A Geração do Hash de Troca (Exchange Hash - H)

Antes do servidor responder ao cliente, ambas as pontas devem concordar sobre um resumo (Hash) de tudo o que foi conversado até aquele momento. Este hash é o resumo criptográfico do estado completo do handshake até a fase de KEX.

• Payload do Hash: O hash H é calculado a partir das strings de versão (V_C, V_S), das mensagens KEXINIT (I_C, I_S), da Chave Pública do Servidor (K_S) e dos valores públicos do Diffie-Hellman (e, f). A fórmula exata está na seção 8 da RFC 4253.
• Algoritmos de Hash Utilizados: SHA-1 (legado, em desuso), SHA-256 (padrão moderno), SHA-512 (em algoritmos mais fortes como curve25519-sha256).
• Session ID: O valor do primeiro hash H gerado em uma conexão torna-se o Session ID permanente. Ele é o "identificador digital" único daquela sessão específica e não muda mesmo se a conexão for re-keyed (renegociada posteriormente por motivos de longevidade ou segurança).

2. A Assinatura de Host do Servidor

Para provar que o servidor é o dono da Host Key que ele enviou, ele deve assinar o Hash H. Esta assinatura é o coração da autenticação de servidor no SSH.

• Operação de Assinatura: O servidor utiliza sua Chave Privada de Host (armazenada em /etc/ssh/ssh_host_*_key) para assinar digitalmente o valor de H. A assinatura é gerada com o algoritmo correspondente ao tipo de Host Key (RSA-PSS, ECDSA ou Ed25519).
• Envio ao Cliente: O servidor transmite sua chave pública (K_S), seu valor público do DH (f) e a Assinatura Digital gerada, em uma única mensagem do tipo SSH_MSG_KEXDH_REPLY (ou equivalente para ECDH).
• Validação pelo Cliente: O cliente recebe os dados, recalcula o hash H por conta própria e utiliza a chave pública (K_S) para verificar se a assinatura enviada pelo servidor é válida. Se a verificação for bem-sucedida, o servidor provou que possui a chave privada associada e que o canal de KEX é autêntico.
• Derivação de Chaves: A partir de K e H, ambas as pontas derivam as chaves simétricas de sessão (cifra, MAC, IV) usando funções de derivação HKDF-like definidas na RFC 4253 seção 7.2.

3. O Conceito de "Cifragem Dupla"

O termo "Cifragem Dupla" refere-se à sobreposição de duas camadas de proteção criptográfica no estabelecimento da sessão:

1. Sigilo Matemático (Confidencialidade): O Diffie-Hellman (ou ECDH) garante que o segredo compartilhado K nunca é transmitido pela rede, mesmo com um atacante escutando passivamente. Apenas as contribuições públicas (e, f) transitam, mas não K.
2. Autenticidade (Integridade de Identidade): A assinatura digital sobre H, feita com a chave privada de host do servidor, garante que o servidor é quem afirma ser, prevenindo ataques de Man-in-the-Middle.

Juntas, essas duas camadas formam o que é tecnicamente conhecido como Authenticated Key Exchange (AKE), um padrão fundamental em protocolos modernos como TLS 1.3, IKEv2 e Signal Protocol.

4. Perspectiva de Cyber Security e Prevenção de Ataques

Para o analista de segurança, esta fase é a defesa primária contra ataques de repetição e interceptação.

Proteção contra Replay Attacks

Como o Hash H inclui valores efêmeros gerados aleatoriamente em cada conexão, a assinatura do servidor nunca será igual entre duas sessões.

• Risco: Sem o hash de troca, um atacante poderia capturar uma assinatura antiga do servidor e tentar enviá-la novamente para se passar pela máquina legítima. A inclusão de (e, f) e do Session ID no hash torna esta tática técnica impossível.
• Nonces Criptográficos: Cada lado contribui com entropia própria (e do cliente, f do servidor), garantindo que mesmo repetindo a mesma senha de host, a assinatura resultante será sempre única.

Segurança da Host Key

Este estágio ressalta por que a Chave Privada do servidor deve ser mantida com permissões rigorosas (600). Se um atacante obtiver a chave privada, ele poderá assinar qualquer Hash H, permitindo-lhe realizar ataques de Man-in-the-Middle (MitM) perfeitos, onde o cliente validará a assinatura e acreditará estar falando com o servidor real da empresa.

Defesa contra Ataques de Downgrade

A lista KEXINIT contém todos os algoritmos suportados em ordem de preferência. Se a lista não estiver protegida, um MitM poderia forçar a negociação dos algoritmos mais fracos. Para mitigar isto:

• A RFC 4253 obriga a assinatura a cobrir também I_C e I_S, impossibilitando downgrade sem invalidar H.
• Configurações modernas do sshd_config removem explicitamente algoritmos fracos: KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256.

5. Fluxo Detalhado do Handshake

Cliente                                   Servidor
  |                                          |
  |--- TCP SYN ----------------------------->|
  |<-- TCP SYN/ACK --------------------------|
  |--- SSH-2.0-OpenSSH_9.6 ---------------->| (version string)
  |<-- SSH-2.0-OpenSSH_9.6 ------------------|
  |--- KEXINIT (I_C, algoritmos) ----------->|
  |<-- KEXINIT (I_S, algoritmos) ------------|
  |--- DH valor público (e) ---------------->|
  |<-- KEXDH_REPLY (K_S, f, SIG(H)) --------| (assinatura)
  |     [cliente recalcula H, valida SIG]    |
  |--- NEWKEYS ----------------------------->|
  |<-- NEWKEYS ------------------------------|
  |     [tráfego cifrado a partir daqui]     |

Após o NEWKEYS, todas as mensagens subsequentes são cifradas com a chave simétrica derivada. Não há mais texto plano transitando pela rede.

6. Auditoria Técnica e Diagnóstico de Assinatura

Verificar se o servidor está utilizando uma assinatura de host forte exige a depuração do handshake:

# Verificando qual tipo de chave de host (HostKey) foi selecionado e validado (-vv)
ssh -vv user@alvo.com 2>&1 | grep "Host key"

# Validando manualmente o fingerprint da assinatura recebida contra o known_hosts
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

# Removendo uma entrada desatualizada de known_hosts para forçar revalidação
ssh-keygen -R alvo.com

# Capturando o handshake completo para análise forense
tcpdump -ni any host alvo.com and port 22 -w handshake.pcap

7. Resumo Técnico

8. Conclusão: O Selo da Autenticidade

A Assinatura do Hash de Troca é o selo de cera digital que garante a integridade do processo SSH. Ela amarra o segredo matemático da sessão à identidade física do servidor. Dominar a lógica da geração do Session ID, entender a importância de proteger as chaves privadas de host e auditar as assinaturas recebidas para garantir que o seu túnel administrativo seja uma construção de confiança absoluta no cenário dinâmico da web globalizada.