A Resource Public Key Infrastructure (RPKI, em português, infraestrutura de chaves públicas de recursos), também conhecida como Resource Certification, é uma infraestrutura de chaves públicas destinada a melhorar a segurança do roteamento na Internet. Seus certificados digitais X.509 vinculam recursos de numeração, como blocos de endereços IP e números de sistemas autônomos, a chaves públicas. Sua arquitetura é descrita na RFC 6480, publicada pela Internet Engineering Task Force (IETF) em 2012.
Uma de suas aplicações é a publicação de autorizações de origem de rota, ou ROAs, pelas quais o detentor de um bloco de endereços autoriza um sistema autônomo a originar anúncios de determinados prefixos no Border Gateway Protocol (BGP). Esses dados permitem realizar a validação de origem de rota, conhecida pela sigla ROV, e aplicar políticas de rejeição de anúncios não autorizados. A medida ajuda a mitigar sequestros de BGP e erros de configuração, mas não verifica, por si só, todo o caminho percorrido pelo anúncio.
A estrutura de certificação da RPKI acompanha a distribuição dos recursos de numeração da Internet, cuja alocação global aos registros regionais é coordenada pela Autoridade para Atribuição de Números da Internet (IANA). Os certificados podem formar cadeias que passam por registros regionais, nacionais e locais até chegar aos titulares dos recursos, conforme a organização de cada alocação.
Na implantação operacional, os cinco registros regionais de Internet mantêm âncoras de confiança próprias: AfriNIC, APNIC, ARIN, LACNIC e RIPE NCC. A validação parte dessas âncoras, sem exigir que os certificados dos registros regionais sejam subordinados a um certificado da IANA. Os registros nacionais, como o Registro.br no Brasil, os registros locais e os demais titulares podem participar dos níveis subordinados dessa estrutura.
Cada âncora pode ser identificada por um Trust Anchor Locator (TAL), um arquivo com um ou mais endereços para obtenção do certificado da âncora e a chave pública esperada. O validador usa essa chave para verificar o certificado autoassinado obtido. A RFC 8630 define esse formato e substitui a RFC 7730.
Os certificados de recursos utilizam X.509 versão 3 com extensões definidas na RFC 3779. Essas extensões associam ao titular do certificado intervalos de endereços IPv4 e IPv6 ou identificadores de sistemas autônomos. Os certificados de autoridades certificadoras permitem a emissão de certificados subordinados, enquanto os certificados de entidade final são usados na validação de objetos assinados e não funcionam como autoridades certificadoras. A certificação atesta a alocação dos recursos, sem funcionar como comprovante da identidade civil ou jurídica de seu titular.
Os certificados, as listas de revogação, os manifestos e os objetos assinados são publicados em repositórios distribuídos. Os validadores consultam esses pontos de publicação e mantêm cópias locais dos dados necessários à verificação. Os repositórios podem ser mantidos pelos registros de Internet ou por outras organizações participantes da infraestrutura. A obtenção dos dados utiliza mecanismos como:
Uma autorização de origem de rota, ou ROA, é um objeto assinado digitalmente pelo qual o detentor de recursos de endereçamento autoriza um sistema autônomo a originar rotas para um ou mais prefixos. Seu formato é definido na RFC 9582, de maio de 2024, que substituiu a RFC 6482. O objeto utiliza a estrutura de assinatura da RPKI baseada em Cryptographic Message Syntax (CMS).
Cada ROA identifica um único número de sistema autônomo autorizado, ou ASN, e uma lista de prefixos. Para cada prefixo, pode incluir um limite de comprimento:
192.0.2.0/24./24 com maxLength igual a 25 permite anúncios desse prefixo e de seus subprefixos /25. Quando o campo é omitido, a autorização vale apenas para o prefixo indicado.A RFC 9319, integrante da BCP 185, recomenda limitar as autorizações aos prefixos efetivamente anunciados, sempre que possível. Um maxLength excessivamente amplo pode autorizar subprefixos que não são anunciados legitimamente e ampliar a exposição a ataques que falsificam o ASN de origem. Como o encaminhamento favorece o prefixo mais específico, um anúncio desse tipo pode desviar tráfego mesmo quando passa pela validação de origem. Prefixos adicionais podem ser enumerados em um mesmo ROA, sem a obrigação de criar um objeto separado para cada um. A recomendação admite exceções operacionais e não constitui uma proibição absoluta do campo.
A validação de origem de rota, ou ROV, compara os anúncios BGP com os dados obtidos de ROAs validados. Ela atua sobre as informações de roteamento usadas pelo roteador para selecionar caminhos. A RFC 6811 define o procedimento de classificação, e a RFC 8481 esclarece aspectos de sua aplicação e da política configurada pelo operador.
A verificação das cadeias de certificados e dos objetos assinados pode ser realizada por servidores validadores, que fornecem aos roteadores os resultados necessários à validação de origem. Essa separação evita que cada roteador precise executar todo o processo de obtenção e verificação criptográfica dos repositórios.
Os validadores partem das âncoras de confiança configuradas, obtêm os objetos publicados e verificam certificados, assinaturas, manifestos e listas de revogação. De cada ROA aceito são extraídos registros com prefixo, comprimento máximo e ASN autorizado, chamados Validated ROA Payloads (VRPs). Um ROA com vários prefixos pode produzir vários VRPs.
Entre os programas usados nesse processo estão:
O protocolo RPKI-to-Router (RTR) permite que um roteador receba os dados de um cache confiável e acompanhe suas atualizações. A versão 1 é especificada na RFC 8210, que atualiza a RFC 6810, referente à versão 0. A distribuição pode ser feita pelo próprio programa validador ou por um servidor separado, conforme a implantação.
Para cada rota submetida à validação, o roteador compara o prefixo e o ASN de origem com a base de VRPs disponível. Um VRP cobre uma rota quando seu prefixo é igual ou menos específico e contém integralmente o prefixo anunciado. O resultado é um dos seguintes estados:
Se houver vários VRPs cobrindo a mesma rota, basta que um deles a autorize para que o resultado seja Valid. Um anúncio Invalid também pode decorrer de um erro de configuração, e não necessariamente de um ataque.
A rejeição de rotas inválidas é recomendada nas orientações operacionais da RFC 7115, mas depende da política configurada na rede. A RFC 8481 determina que ações baseadas no estado de validação não sejam aplicadas implicitamente, sem configuração do operador. A ausência de um VRP, expressa por NotFound, não equivale à constatação de que o anúncio é ilegítimo. A iniciativa MANRS também inclui o uso da RPKI entre as técnicas de filtragem de anúncios BGP apresentadas em seu guia para operadores de rede.
Em fevereiro de 2026, 60,3% das rotas IPv4 e 60,9% das rotas IPv6 observadas em um levantamento global publicado pelo APNIC eram classificadas como válidas pela validação de origem baseada em RPKI. A cobertura por ROAs e a aplicação de filtros são medidas distintas: a existência de uma autorização não garante que todas as redes rejeitem os anúncios inválidos. O monitor do NIST acompanha a implantação por meio da classificação de pares de prefixo e ASN de origem observados em dados de roteamento BGP, com análises separadas para IPv4 e IPv6.
No Brasil, o Registro.br, serviço do NIC.br, disponibilizou a RPKI aos titulares de recursos de numeração em dezembro de 2019. A implantação utiliza o modelo delegado, no qual a organização opera uma autoridade certificadora, por exemplo com o programa Krill, e pode utilizar o serviço de publicação do Registro.br para disponibilizar seus objetos.
Em fevereiro de 2019, o IX.br ativou filtros em seus servidores de rotas de São Paulo para descartar anúncios classificados como inválidos pela RPKI. Essa filtragem incide sobre os anúncios tratados por esses servidores e está sujeita às limitações da validação de origem, que não autentica todo o caminho de sistemas autônomos.
A validação de origem verifica a autorização para o ASN que aparece como origem da rota, mas não autentica os demais sistemas autônomos do atributo AS_PATH. Um atacante que insira o ASN autorizado como origem de um caminho forjado pode produzir um anúncio classificado como Valid, desde que o prefixo e seu comprimento também sejam autorizados. Vazamentos de rotas que preservam uma origem autorizada podem igualmente passar pela ROV.
Os mecanismos propostos ou especificados para ampliar a proteção do caminho incluem:
BGPsec_PATH para verificar a autorização da propagação de um anúncio ao longo do caminho. A inclusão das assinaturas aumenta o volume de dados dos anúncios e exige processamento criptográfico para sua geração e verificação. Os custos dependem da implementação e da carga de roteamento, incluindo situações de recuperação de sessões.