Limiting the Power of RPKI Authorities

Unfortunately though, the deployment of these security measures has been slow and, as such, they have not yet delivered widespread security improvements. DNSSEC and RPKI rely on cryptographic signatures and, while the private keys should be held by the owners of domains and Internet name resource owners, in practice, they are outsourced to centralised authorities. In the case of RPKI, it relies on a weak threat model that can be exploited by nation-state actors.

In this post, I am going to share a joint project that my colleague, Haya Shulman, and I presented at ANRW ’20, where we propose a change to RPKI that will strengthen the threat model and prevent unilateral takedown of IP prefixes by Regional Internet Registries (RIRs).

Our design, which relies on threshold signatures — an instance of secure multiparty computation (MPC) — to distribute trust, is automated and can facilitate the deployment of RPKI while reducing or eliminating errors due to manual configurations. Our work prevents takedowns instead of detecting them after the fact. We also do not require any changes at relying parties, which makes it easier to deploy our solution.

RPKI and RIRs

RPKI secures interdomain routing against prefix and sub-prefix hijacks. It binds the IP address blocks with its Autonomous Systems (ASes) via cryptographic signatures, stored in Route Origin Authorizations (ROAs). ASes then apply Route Origin Validation (ROV) to identify and discard Border Gateway Protocol (BGP) announcements that contradict the information in ROAs. ASes that perform ROV filter misconfigured as well as malicious announcements attempting to hijack prefixes.

Although RPKI is beneficial to routing security, it creates a new vulnerability by which IP prefixes can be ‘taken down’ by RIRs, whether intentionally or through compromise of this new attack vector. Changes to RPKI can cause a prefix of the affected AS to become unreachable for ASes that enforce ROV, and RIRs have the power to revoke and change any certificate they have issued, thus, invalidating BGP routes to the affected AS.

The Threat Model of RPKI

RPKI uses hierarchical and centralised authorities who are assumed to be trusted. The threat model does not consider attacks on RPKI authorities, malfunction or the malicious intent of RPKI authorities and coercion by Law Enforcement Agencies. This weak threat model creates a power imbalance between RIRs and their members.

RIR members are in numerous economies while the RIRs are bound by the law of the jurisdiction they are based in. The members have little recourse if they are affected by a mistake or an attack.

Distributing Trust

We focus our work on the hosted RPKI setting, where the RIRs host a Certificate Authority (CA) for its members to issue ROAs. This makes it easier for their members to use RPKI without the overhead of managing a CA.

We strengthen the threat model where the RIRs are not entirely trusted. In other words, we distribute trust such that a threshold number of RIRs need to collaborate to be able to make changes to the RPKI. A mistake at one RIR will not cause damage as the other RIRs can detect the mistake.

While RIRs continue to play a significant role in securing interdomain routing, they are not in a position to unilaterally takedown prefixes.

Figure 1: Distributed RPKI

In our system, each RIR has a threshold signature module and a CA. Whenever a signature is required, the threshold signature module is used. Each RIR’s module communicates with each other to generate threshold signatures with each RIR generating a share of the private key, meaning none of them has the entire private key. Using only the shares, the RIRs can collaboratively sign ROAs and Certificate Revocation Lists (CRLs). Although RIRs need to communicate with each other, there is no additional burden on the relying parties. The verification of threshold signatures is the same as that of traditional digital signatures.

Three important properties of our system are:

• Most of the cryptographic overhead is moved to the offline phase and the online phase requires one round of communication and little computation. An efficient online phase limits the overhead that cryptography adds to our system.

• Our system is automated. It requires the consent of the members before any change can be made, which is sent to and checked by all the RIRs automatically. Automation reduces the possibility of human errors.

• Our system uses a distributed key generation algorithm wherein the public key at each RIR is the same. RIRs add this public key to their trust anchor locator (TAL) as the subjectPublicKeyInfo. This approach comes with an added advantage that each RIR has the same trust anchor while not having access to the private key. If one of the RIRs is not accessible, it becomes possible for relying parties to obtain the TAL from the other RIRs.

You can watch our ANRW talk here.

We welcome your feedback on our proposal in the comments below.