Uma infraestrutura de chaves públicas (Public Key Infrastructure, PKI) é uma estrutura que serve para relacionar chaves públicas a um determinado recurso, ou recursos. Por “estrutura” entendemos que uma PKI consiste em regras, procedimentos, políticas, e o conceito engloba também todo hardware e software envolvidos. Uma PKI envolve entidades emitindo e assinando certificados criptográficos, que são os documentos digitais que carregam as chaves públicas e informações dos recursos relacionados a elas. Essas entidades são organizadas em uma hierarquia, de forma que é possível realizar a validação das informações.
No caso do RPKI, em particular, os recursos vinculados às chaves criptográficas, ou certificados, são os blocos de endereços IP (IPv6 e IPv4) e os ASN.
Vamos procurar a seguir desvendar o vocabulário e entender importantes conceitos aplicados a infraestruturas de chaves públicas em geral e ao RPKI (Resource Public Key Infrastructure), em particular:
A técnica de criptografia utilizada em infraestrutura de chaves públicas (PKI) é chamada de criptografia assimétrica. A criptografia assimétrica envolve a criação de um par de chaves, uma pública, outra privada. Essas chaves são simplesmente números com propriedades matemáticas especiais. A chave pública, como o próprio nome deixa claro, pode e deve ser divulgada publicamente. A chave privada deve ser mantida em segredo.
A chave privada pode ser utilizada para assinar digitalmente documentos, ou criptografar os mesmos. A assinatura pode ser então verificada por terceiros, ou o documento pode ser descriptografado, usando a chave pública.
O inverso também é possível, um documento pode ser assinado ou criptografado com a chave pública, podendo então a assinatura ser verificada, ou o mesmo descriptografado, com a chave privada.
Em uma infraestrutura de chaves públicas, estas (as chaves públicas) justamente têm um papel especial, o que deveria ser óbvio, visto que dão o nome para a estrutura. As chaves públicas são divulgadas em documentos chamados certificados, que são por sua vez assinados por chaves privadas e organizados em uma estrutura hierárquica. O certificado “pai”, na cadeia de validação, ou mais especificamente a chave pública que está contida nele, é usada para validar a assinatura do certificado “filho” (que foi assinado pela chave privada do “pai”). Dessa forma é possível seguir uma cadeia de confiança para a validação de um determinado recurso, vinculado a um certificado.
Um certificado criptográfico, em uma estrutura de chaves públicas, é basicamente um documento eletrônico, ou arquivo, que:
O X.509 é um padrão definido pela ITU-T para certificados criptográficos. A RFC 5280 especifica como utilizar o X.509 na Internet. E, mais especificamente, a RFC 3779 define extensões para os certificados X.509 para que eles sejam capazes de relacionar uma lista de blocos de endereços IP, ou seja, de prefixos, ou uma lista de ASN, ao certificado. As RFCs 6487 e 7318 detalham a forma de usar os certificados X.509 para representar blocos de endereços IP ou ASN na Internet.
Os certificados X.509 v.3 são utilizados no RPKI. Eles também são utilizados em muitos outros protocolos na Internet, por exemplo, no TLS/SSL, que é a base para o HTTPS, o protocolo seguro usado na Web. Eles são usados ainda em uma série de aplicações fora da Internet, por exemplo, para assinatura eletrônica de documentos.
Os certificados X.509 utilizados no RPKI são chamados genericamente de Resource Certificates (RC), ou Certificados de Recursos. Uma característica particular do RPKI, que é interessante destacar, é que os certificados não trazem informações sobre a entidade que os emite. Ou seja, um certificado emitido por um ISP vinculado aos seus blocos de endereço IP não contém o nome do ISP ou outras informações que possam identificá-lo.
A Autoridade de Certificação (Certification Authority, CA) é a entidade que assina os certificados, em uma infraestrutura de chaves públicas (PKI).
No RPKI, cada Regional Internet Registry (RIR) é uma Autoridade de Certificação (CA). Uma organização qualquer que obtem recursos de numeração (IPv6, IPv4, ASN) do RIR gera para si própria um par de chaves e um certificado vinculado a tais recursos (RC). Esse certificado é assinado pelo RIR, que fazendo isso atua no papel CA.
Essa mesma organização que obteve os recursos e teve o certificado assinado pelo RIR, pode atuar também como CA, assinando certificados gerados por seus clientes, vinculados aos recursos dos mesmos, ou assinando certificados chamados de End Entities (EE) que estão relacionados a utilização dos recursos vinculados aos mesmos e serão explicados mais à frente.
Em uma infraestrutura de chaves públicas, a Trust Anchor (TA) é o topo da cadeia de certificação ou, dito de outra forma, a raiz da cadeia de certificação. Ou seja, é um certificado autoassinado que é considerado, por definição, confiável. Sua chave pública é bem conhecida e considerada confiável em toda a cadeia de certificação.
Normalmente um certificado TA tem uma longa validade, de até vários anos, e a chave privada desse certificado é armazenada offline, sendo usada apenas para reassiná-lo quando necessário. Esse certificado pode ser trocado de tempos em tempos, de forma programada, para aumentar a confiabilidade do sistema, ou pode ser trocado emergencialmente, se houver comprometimento (vazamento) da chave privada.
No RPKI optou-se por não haver uma raiz única. Esta não é uma limitação técnica, mas uma escolha operacional, de governança da Internet, baseada em diversos critérios. Ou seja, na infraestrutura provida pelo RPKI não existe uma raiz única na cadeia de certificação, mas 5 certificados raiz diferentes, 5 TA diferentes, pertencentes respectivamente ao AFRINIC, ARIN, APNIC, LACNIC e RIPE.
Em uma infraestrutura de chaves públicas, a organização responsável por receber a requisição para a assinatura de um certificado, autenticando a entidade requisitante, verificando as informações necessárias, e autorizando a certificação, é chamada de Autoridade de Registro (Registration Authority, RA).
No RPKI os RIRs e NIRs assumem também a função de Autoridade de Registro. Isso é natural, visto que as organizações que têm os recursos alocados já tem acesso a um sistema onde os gerenciam, e nesse sistema já há as funções de autenticação e autorização.
Por sua vez, as organizações que têm recursos alocados pelos RIRs ou NIRs diretamente, podem também emitir e assinar certificados para si próprias ou para seus clientes, sendo responsáveis também pela autenticação e autorização nesses casos, operando como Autoridades de Registro.
No RPKI, pois, as funções de Autoridade de Certificação (Certification Authority, CA) e Autoridade de Registro (Registration Authority, RA):
O RIR ou NIR, no papel de Autoridade de Registro (RA), é quem recebe as requisições, verifica a identidade de quem está fazendo a solicitação e se ela é válida. Por exemplo, autentica o usuário do ISP em seu sistema e verifica se os blocos IP vinculados ao certificado estão realmente alocados para o mesmo. Estando tudo certo, autoriza a assinatura ou emissão do certificado. Então o próprio RIR ou NIR, agora no papel de Autoridade de Certificação (CA), assina ou emite o certificado, usando sua chave privada. A organização responsável (o LACNIC, ou o NIC.br, por exemplo) é a mesma, mas executando papéis distintos, funções distintas.