Autoridades certificadoras e cadeias de confiança

A criptografia assimétrica só é útil se você puder confiar que uma key pública realmente pertence à pessoa que imagina. Sem um mecanismo de trust, um invasor pode interceptar sua solicitação pela key pública de alguém e substituí-la pela própria — um ataque clássico de man-in-the-middle. A Public Key Infrastructure (PKI) resolve esse problema de trust introduzindo uma Certification Authority (CA) — uma terceira parte confiável que assina digitalmente certificates vinculando keys públicas a identidades verificadas. Se você confia na CA, pode confiar em qualquer pessoa que ela tenha certificado.

Uma Certification Authority (CA) é uma organização que emite certificates digitais após verificar a identidade do solicitante do certificate. A CA assina cada certificate com sua própria key privada, permitindo que qualquer pessoa que confie na CA verifique a autenticidade do certificate usando a key pública da CA. Existem dois tipos: Public CAs (como DigiCert, GlobalSign e Let's Encrypt), cujos certificates raiz vêm pré-instalados em sistemas operacionais e navegadores; e Private (Internal) CAs, que as organizações administram para a emissão interna de certificates (VPNs, Services internos e certificates de dispositivos).

Uma Root CA é a autoridade máxima em uma hierarquia de PKI. Os certificates de Root CA são autoassinados — não existe uma autoridade superior para validá-los. Em vez disso, os certificates raiz são considerados confiáveis porque os fornecedores de sistemas operacionais (Microsoft, Apple e Mozilla) avaliam as Root CAs por meio de processos rigorosos de auditoria e pré-instalam seus certificates nos repositórios de certificates confiáveis. Há aproximadamente 130 a 150 Root CAs confiáveis no repositório de trust de um navegador típico. Se uma Root CA for comprometida, todos os certificates que ela já emitiu se tornam suspeitos — por isso as keys privadas das Root CAs são armazenadas em módulos de segurança de hardware (HSMs) offline e isolados de redes.

As Root CAs raramente emitem certificates diretamente para entidades finais. Em vez disso, elas criam Intermediate CAs (também chamadas de CAs subordinadas) emitindo certificates para operadores de CAs intermediárias. As Intermediate CAs então emitem certificates para entidades finais (como certificates de servidores HTTPS). Essa hierarquia de delegação atende a vários objetivos: protege as keys privadas das Root CAs mantendo-as offline (se uma CA intermediária for comprometida, somente sua cadeia de certificates será revogada, não toda a raiz); permite CAs especializadas para diferentes usos (assinatura de código em vez de TLS); e possibilita uma hierarquia organizacional dentro de uma PKI privada.

Uma cadeia de certificates (ou cadeia de trust) é a sequência de certificates desde o certificate da entidade final até a Root CA confiável. Para um site HTTPS típico, a cadeia é: certificate da entidade final (por exemplo, *.google.com) → certificate da CA intermediária (por exemplo, Google Trust Services WR2) → certificate da Root CA (por exemplo, Google Trust Services LLC). Quando seu navegador acessa um site, ele valida toda essa cadeia — verificando se a assinatura de cada certificate foi feita pelo nível imediatamente superior e se a raiz está no repositório de trust. Qualquer interrupção nessa cadeia causa um erro de certificate.

Quando duas hierarquias de PKI separadas precisam estabelecer trust mútuo, elas usam cross-certification. Cada CA emite um certificate para a raiz da outra, estabelecendo trust nos dois sentidos. Uma Bridge CA é uma CA central que faz cross-certification com várias CAs de domínio, criando uma rede de trust entre diferentes organizações ou agências governamentais. A US Federal Bridge CA conecta vários sistemas de PKI do governo federal dos US. A cross-certification é complexa de administrar, mas necessária ao unir organizações ou estabelecer trust entre agências sem fundi-las em uma única hierarquia.

Uma Registration Authority (RA) é uma entidade que realiza a verificação de identidade em nome de uma CA, mas não emite certificates por conta própria. A RA recebe solicitações de certificates, verifica a identidade do solicitante (por meio da conferência de documentos, validação de domínio ou verificação presencial, dependendo do tipo de certificate) e encaminha as solicitações aprovadas à CA para assinatura. Essa delegação permite que as CAs ampliem sua emissão sem realizar toda a verificação por conta própria. Em uma PKI empresarial, a RA pode ser o departamento de RH ou a central de suporte de IT que valida as solicitações de certificates dos funcionários.

As CAs oferecem certificates em diferentes níveis de validação, refletindo o grau de profundidade com que a identidade do solicitante foi verificada. Domain Validation (DV): a CA verifica apenas se o solicitante controla o domínio (automatizada, leva minutos e é usada pela Let's Encrypt). Organization Validation (OV): a CA verifica a existência legal da organização (de 1 a 3 dias úteis). Extended Validation (EV): verificação mais completa — identidade legal, endereço físico e existência operacional (de 1 a 2 semanas, usada para exibir o nome da empresa em verde na barra de endereços do navegador). DV é suficiente para criptografia básica; EV é apropriada para alvos de alto valor, como sites bancários.

A fixação de certificates é uma técnica na qual um aplicativo é programado para confiar somente em um certificate ou CA específico, em vez de aceitar qualquer certificate de qualquer Root CA confiável. Isso impede ataques MITM mesmo que um invasor obtenha um certificate fraudulento de uma CA confiável. Aplicativos móveis e aplicativos sensíveis à segurança usam fixação para garantir que aceitem somente os certificates de seus próprios servidores. A desvantagem é que, se o certificate fixado expirar ou for substituído, o aplicativo deixará de funcionar até ser atualizado. O HPKP (HTTP Public Key Pinning) era um mecanismo de fixação baseado em navegador que foi descontinuado devido aos riscos de implantação incorreta.

As organizações administram sua própria CA privada para necessidades internas de certificates — autenticar clientes VPN, emitir certificates para Services HTTPS internos, assinar código e autenticar dispositivos. O Microsoft Active Directory Certificate Services (AD CS) é a CA privada empresarial mais comum. Os certificates de CAs internas devem ser distribuídos a todos os dispositivos e navegadores que precisam confiar nos certificates emitidos internamente, normalmente por meio da Política de Grupo. As CAs privadas não podem emitir certificates confiáveis na internet pública — seu uso é limitado aos dispositivos da organização que têm a raiz da CA privada instalada.

O comprometimento da DigiNotar (2011) é o incidente de CA mais importante que os candidatos ao Security+ devem conhecer. A CA holandesa DigiNotar foi invadida por atacantes que emitiram certificates fraudulentos para domínios do Google, da Mozilla e do governo. Eles foram usados no Irã para realizar ataques man-in-the-middle contra cidadãos. Como resultado, todos os principais fornecedores de navegadores e sistemas operacionais removeram imediatamente a DigiNotar de seus repositórios de Root confiáveis, invalidando todos os certificates que a DigiNotar já havia emitido. A DigiNotar faliu em poucas semanas. Esse incidente demonstrou que o comprometimento de uma CA é catastrófico e explicou por que registros CAA DNS, Certificate Transparency e autenticação multifator para sistemas de CA agora são obrigatórios.

Avalie sua compreensão dos conceitos de CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que: as Autoridades de Certificação vinculam chaves públicas a identidades verificadas; a cadeia de confiança vai da entidade final, passando pelas CAs intermediárias, até uma raiz autoassinada; as Root CAs são mantidas offline em HSMs e têm confiança pré-estabelecida pelos sistemas operacionais; e o comprometimento de uma CA (DigiNotar) pode invalidar milhões de certificados. A seguir, exploraremos a Estrutura de Certificate X.509.