Trust Anchor Key (TAK): transición de claves seguras en RPKI
26/02/2025
Por Carlos Martinez Cagnazzo, Gerente de Tecnología de LACNIC
La rotación de claves seguras en RPKI era uno tópico que nunca hasta ahora había suscitado un interés suficiente como para elevar la discusión a otro nivel. Es en sí un problema que nos afecta a los operadores de Trust Anchor, una comunidad de cinco personas que pertenecemos a los cinco RIRs.
Tiempo atrás, nos pusimos a conversar y encontramos una preocupación operativa común. El siguiente paso fue preparar en conjunto con George G. Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein y quien suscribe el RFC “A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs)”, documento que ya fue publicado y que introduce un nuevo objeto llamado Trust Anchor Key (TAK) dentro de RPKI. Previamente a ello, al ser este un problema que atañe a una comunidad pequeña, tuvimos que demostrar al grupo de trabajo del IETF de que ésta efectivamente era una dificultad.
¿Por qué nos enfrentamos frente a esta necesidad en RPKI? Los algoritmos de cifrado tienen vida útil, que se puede medir en algunos casos en décadas, en algunos casos en menos tiempo. Básicamente siempre es recomendable cambiarlos por una cuestión de seguridad, pero más allá de eso, atacar este tipo de algoritmos es incluso un ejercicio que se hace académicamente de forma constante.
De manera que cuando alguien tiene que custodiar información cifrada debe tener en cuenta que en algún momento va a tener que cambiar de algoritmo de cifrado. Ocurre que cuando se cambia el algoritmo de cifrado, necesariamente hay que cambiar de clave, porque inicialmente las claves son de otro tamaño, por lo que generar otra clave es imprescindible.
¿Dónde está el problema? La dificultad emerge porque en RPKI las RPs utilizan una lista especial llamada TAL (Trust Anchor Locator) para encontrar y verificar los certificados de autoridad confiables. Sin embargo, hasta ahora, no había una forma automática de avisar a las RPs cuando el TAL se actualiza. Esto significa que los operadores de Trust Anchor no podíamos estar seguros de que las RPs se enteraran de los cambios importantes, como la actualización de claves de seguridad.
El propósito del RFC es introducir un objeto que ayude a registrar y comunicar la ubicación del certificado del Trust Anchor y su clave pública actual. Además, también documenta la clave pública futura que reemplazará a la actual y la ubicación de su certificado. Básicamente, este objeto permite que los RPs reciban automáticamente actualizaciones sobre estos cambios y que los Trust Anchor puedan planificar la transición a una nueva clave sin riesgo de invalidar el árbol RPKI.
¿Cómo opera? Un RP, antes de procesar otros datos, primero verificará si existe un objeto TAK. Si el TAK solo menciona la clave pública actual, el RP seguirá funcionando como de costumbre. pero Si el TAK incluye una clave pública futura, el RP iniciará un período de espera de 30 días antes de aceptarla, pero mientras tanto continuará con el proceso normal de validación usando la clave actual.
Con la publicación del RFC ya en marcha, lo que resta es la implementación de esa funcionalidad para los operadores de Trust Anchor, que estimamos estará lista entre lo que resta de este año y el próximo.
La ocasión es pertinente para resaltar que siempre es recomendable mantener los validadores actualizados, caso contrario, corren el riesgo de continuar usando claves obsoletas, lo que podría llevar a que los certificados de las TAs sean rechazados, invalidando rutas legítimas y causando interrupciones en la conectividad de la red. Si los validadores no se actualizan, podrían asimismo volverse vulnerables a ataques como suplantación de identidad o uso de claves comprometidas. Asimismo, un validador desactualizado obligaría a los operadores de red a realizar actualizaciones manuales, lo que aumenta la carga operativa y el riesgo de errores humanos. Por último, podría no ser compatible con nuevas prácticas y estándares, dejando la red expuesta a problemas de interoperabilidad y pérdida de confianza en la infraestructura de seguridad del enrutamiento.
En definitiva, las organizaciones y operadores de red que dependen de RPKI deben seguir las mejores prácticas para garantizar la resiliencia y seguridad de su infraestructura. Mantener los validadores actualizados es parte fundamental de esta estrategia.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.