Parte III · 1 — Confiança e PKI
As primitivas garantem que uma mensagem veio de quem detém uma certa chave. Mas como saber que aquela chave é mesmo do seu banco, e não de um impostor? Esse é o problema da confiança — o que os protocolos resolvem antes de qualquer byte trafegar.
1.1 O problema que falta resolver
A Parte II mostrou como dois estranhos combinam um segredo (ECDHE) e provam autoria (assinaturas). Mas há um buraco: quando Alice recebe uma chave pública dizendo "sou o banco", nada na matemática garante que é verdade. Um atacante no meio (man-in-the-middle) pode entregar a própria chave.
Trocar chaves com segurança é resolvido; vincular uma chave a uma identidade é o que falta. Há duas respostas históricas:
- Hierárquica (PKI) — autoridades confiáveis atestam quem é dono de qual
chave. É o modelo da web.
- Teia de confiança (web of trust) — os próprios usuários assinam as chaves
uns dos outros (PGP). Mais descentralizado, mas difícil de escalar.
1.2 Forward secrecy: por que chaves efêmeras
Antes da identidade, uma propriedade do próprio acordo de chaves: a troca deve usar chaves efêmeras (ECDHE — o "E" final), descartadas após a sessão.
A razão é o forward secrecy: se a chave privada de longo prazo do servidor vazar amanhã, todo o tráfego gravado no passado continua ilegível — porque a chave de sessão que o cifrou já não existe e não pode ser rederivada. Sem efemeridade (o velho RSA key-transport), um vazamento futuro abre todo o histórico. É por isso que o TLS 1.3 só admite troca efêmera.
1.3 Certificados: identidade assinada
Um certificado é um documento que diz "esta chave pública pertence a koder.dev" — assinado pela chave privada de uma autoridade. É só uma assinatura digital (Parte II) aplicada a (identidade + chave pública +
validade).
Se você confia na chave pública da autoridade, pode verificar a assinatura e então confiar no vínculo. A confiança se delega.
1.4 A cadeia de confiança
Ninguém confia em uma única autoridade para tudo. A PKI forma uma cadeia:
- Root CA — uma autoridade-raiz cujo certificado é auto-assinado e vem
pré-instalado no sistema operacional / navegador (o trust store). É a âncora.
- CA intermediária — assinada pela raiz; é quem realmente emite no dia a
dia (a raiz fica offline, protegida).
- Certificado folha — o do site (
koder.dev), assinado pela intermediária.
Ao conectar, o servidor envia folha + intermediária; o cliente valida a cadeia até uma raiz em que confia, checando assinatura, validade, revogação e se o nome bate (SAN). Quebra em qualquer elo ⇒ o cadeado não fecha.
Onde a Koder se encaixa: a Koder opera DNS e emissão próprios (Koder Herald) e o plano de identidade (Koder ID). Toda comunicação é só HTTPS com redirect 301 (
policies/security.kmd) — a cadeia de confiança da web é pré-requisito, não opcional.
1.5 Revogação: quando a confiança expira cedo
Certificados têm validade, mas às vezes uma chave vaza antes de expirar. Mecanismos de revogação:
- CRL (Certificate Revocation List) — listas de revogados; pesadas.
- OCSP — consulta online do status; com stapling, o servidor anexa a prova
fresca, evitando vazar ao validador qual site você visita.
- Validade curta — a tendência moderna (certificados de ~90 dias, ACME/
Let's Encrypt) torna a revogação quase desnecessária: o problema expira logo.
Referência densa: a cadeia de validação, OCSP/CRL e o histórico de CAs comprometidas estão em
07-protocolos. A seguir: TLS — onde a troca de chaves, a cifra simétrica, a assinatura e a PKI se juntam num único handshake.