Trust Anchor Key (TAK): transición de claves seguras en RPKI

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.