A rotação de chaves seguras no RPKI era um assunto que, até agora, nunca havia despertado interesse suficiente para levar a discussão a outro nível. Trata-se de um problema que afeta os operadores de Trust Anchor, uma comunidade de cinco pessoas pertencentes aos cinco RIRs.
Há algum tempo, começamos a conversar e identificamos uma preocupaçãooperacional em comum. O passo seguinte foi preparar, em conjunto com George G. Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein e quem subscreve o RFC “A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)”. Esse documento já foi publicado e introduz um novo objeto chamado Trust Anchor Key (TAK) dentro do RPKI.
Antes disso, por se tratar de um problema que tange a uma comunidade pequena, tivemos que demonstrar ao grupo de trabalho do IETF que essa era, de fato, uma dificuldade relevante.
(Acesso livre, não requer assinatura)
Por que nos deparamos com essa necessidade no RPKI? Os algoritmos de criptografia têm um tempo de vida útil, que em alguns casos pode ser medido em décadas e, em outros, em um período menor. Basicamente, é sempre recomendável substituí-los por uma questão de segurança. Além disso, atacar esse tipo de algoritmo é um exercício que é constantemente realizado no meio acadêmico.
Dessa forma, quem precisar custodiar informações criptografadas deve levar em consideração que, em algum momento, será necessário trocar o algoritmo de criptografia. Quando isso acontece, a troca da chave também se torna indispensável, pois as chaves originais possuem um tamanho diferente, fazendo com seja imprescindível a geração de uma nova chave.
Onde está o problema? A dificuldade surge porque, no RPKI, as RPs utilizam uma lista especial chamada TAL (Trust Anchor Locator) para localizar e verificar os certificados de autoridade confiáveis. No entanto, até agora, não existia um mecanismo automático para informar as RPs quando o TAL era atualizado. Isso significa que os operadores de Trust Anchor não podiam ter certeza de que as RPs seriam notificadas sobre mudanças importantes, como a atualização das chaves de segurança.
Por que nos deparamos com essa necessidade no RPKI? Os algoritmos de criptografia têm um tempo de vida útil, que em alguns casos pode ser medido em décadas e, em outros, em um período menor. Basicamente, é sempre recomendável substituí-los por uma questão de segurança. Além disso, atacar esse tipo de algoritmo é um exercício que é constantemente realizado no meio acadêmico.
Dessa forma, quem precisar custodiar informações criptografadas deve levar em consideração que, em algum momento, será necessário trocar o algoritmo de criptografia. Quando isso acontece, a troca da chave também se torna indispensável, pois as chaves originais possuem um tamanho diferente, fazendo com seja imprescindível a geração de uma nova chave.
Onde está o problema? A dificuldade surge porque, no RPKI, as RPs utilizam uma lista especial chamada TAL (Trust Anchor Locator) para localizar e verificar os certificados de autoridade confiáveis. No entanto, até agora, não existia um mecanismo automático para informar as RPs quando o TAL era atualizado. Isso significa que os operadores de Trust Anchor não podiam ter certeza de que as RPs seriam notificadas sobre mudanças importantes, como a atualização das chaves de segurança.
O propósito do RFC é introduzir um objeto que ajude a registrar e comunicar a localização do certificado do Trust Anchor e sua chave pública atual. Além disso, também documenta a futura chave pública que substituirá a atual e a localização de seu certificado. Basicamente, esse objeto permite que os RPs recebam automaticamente atualizações sobre essas mudanças e que os Trust Anchor possam planejar a transição para uma nova chave sem o risco de invalidar a árvore RPKI.
Como opera? Um RP, antes de processar outros dados, primeiro verificará se existe um objeto TAK. Se o TAK mencionar apenas a chave pública atual, o RP continuará operando normalmente. Mas, se o TAK incluir uma chave pública futura, o RP iniciará um período de espera de 30 dias antes de aceitá-la, enquanto isso, continuará com o processo normal de validação usando a chave atual.
Com a publicação do RFC já em andamento, o que resta é a implementação dessa funcionalidade para os operadores de Trust Anchor, que estimamos estar pronta entre o restante deste ano e o próximo.
A ocasião é oportuna para destacar que é sempre recomendável manter os validadores atualizados. Caso contrário, corre-se o risco de continuar usando chaves obsoletas, o que pode levar à rejeição dos certificados das TAs, invalidando rotas legítimas e causando interrupções na conectividade da rede. Se os validadores não forem atualizados, também poderão se tornar vulneráveis a ataques, como a falsificação de identidade ou o uso de chaves comprometidas. Além disso, um validador desatualizado obrigaria os operadores de rede a realizarem atualizações manuais, aumentando a carga operacional e o risco de erros humanos. Por fim, ele pode se tornar incompatível com novas práticas e padrões, expondo a rede a problemas de interoperabilidade e comprometendo a confiança na infraestrutura de segurança do roteamento.
Em resumo, as organizações e os operadores de rede que dependem do RPKI devem seguir as melhores práticas para garantir a resiliência e a segurança de sua infraestrutura. Manter os validadores atualizados é uma parte fundamental dessa estratégia.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
