Trust Anchor Key (TAK): Secure Key Rotation in RPKI

26/02/2025

By  Carlos Martinez Cagnazzo, Chief Technical Officer at LACNIC

The rotation of secure keys in RPKI has historically been a topic that had not generated enough interest to elevate the discussion to a higher level.  This issue primarily affects Trust Anchor operators—a small community of five individuals representing the five Regional Internet Registries (RIRs).

Some time ago, we started discussing this matter and identified a shared operational concern. As a next step, we collaborated with George G. Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein and myself to draft the RFC “A Profile for Resource Public Key Infrastructure (RPKI) Trust Anchor Keys (TAKs).” This document, which has now been published, introduces a new object within RPKI called the Trust Anchor Key (TAK). Previously, given that this issue affects a relatively small community, we first had to demonstrate to the IETF working group that it was indeed a significant challenge.

Why did we face this need at RPKI? Encryption algorithms have a limited lifespan—sometimes measured in decades, while in other cases, it can be much shorter. Basically, it is always advisable to change them for security reasons. Beyond that, attacking this type of algorithms is a common academic exercise, continuously studied and tested.

As a result, anyone responsible for safeguarding encrypted information must anticipate the need to switch encryption algorithms at some point. When an encryption algorithm is changed, the key must also be replaced. This is because different algorithms typically require keys of varying lengths, making the generation of a new key essential.

What’s the challenge? The difficulty arises because, in RPKI, Relying Parties (RPs) use a special list called TAL (Trust Anchor Locator) to find and verify trusted authority certificates. However, until now, there has been no automatic mechanism to notify RPs when the TAL is updated.  This means that Trust Anchor operators had no way to ensure that RPs would be aware of critical changes, such as security key updates.

The purpose of the RFC is to introduce an object that facilitates the registration and communication of the Trust Anchor certificate’s location along with its current public key. In addition, it also documents the future public key that will replace the current one and the location of its certificate. This object enables RPs to automatically receive updates on these changes, allowing Trust Anchors to plan the transition to a new key without the risk of invalidating the RPKI tree.

How does it work? Before processing any other data, an RP first checks for the presence of a Trust Anchor Key (TAK) object. If the TAK only references the current public key, the RP will continue to operate as usual. If the TAK includes a future public key, the RP initiates a 30-day waiting period before accepting it. During this time, the RP continues the normal validation process using the existing key.

With the RFC now published, the next step is implementing this functionality for Trust Anchor operators, which we estimate will be ready between the end of this year and the next.

This is a good opportunity to emphasize the importance of keeping validators up to date. Otherwise, they run the risk of continuing to use outdated keys, which could lead to Trust Anchor certificates being rejected, invalidating legitimate routes, and causing network connectivity disruptions.

Additionally, if validators are not updated, they could become vulnerable to attacks such as identity spoofing or the use of compromised keys. Moreover, an outdated validator would force network operators to perform manual updates, increasing operational workload and the risk of human error. Finally, it may not be compatible with new practices and standards, leaving the network exposed to interoperability issues and loss of confidence in the routing security infrastructure.

In short, organizations and network operators relying on RPKI should follow best practices to ensure the resilience and security of their infrastructure. Keeping validators up to date is a fundamental part of this strategy.