Privacy Preserving and Resilient RPKI
PPrivacy Preserving and Resilient RPKI
Kris Shrishak
Technical University Darmstadt
Darmstadt, Germany
Haya Shulman
Fraunhofer SIT
Darmstadt, Germany
Abstract —Resource Public Key Infrastructure (RPKI) is vitalto the security of inter-domain routing. However, RPKI enablesRegional Internet Registries (RIRs) to unilaterally takedown IPprefixes - indeed, such attacks have been launched by nation-state adversaries. The threat of IP prefix takedowns is one of thefactors hindering RPKI adoption.In this work, we propose the first distributed RPKI system,based on threshold signatures, that requires the coordination ofa number of RIRs to make changes to RPKI objects; hence,preventing unilateral prefix takedown. We perform extensiveevaluations using our implementation demonstrating the prac-ticality of our solution. Furthermore, we show that our systemis scalable and remains efficient even when RPKI is widelydeployed.
I. I
NTRODUCTION
Resource Public Key Infrastructure (RPKI) [30] is a crypto-graphic method to secure inter-domain routing against prefixand sub-prefix hijacks. It is also a prerequisite for BorderGateway Protocol Security (BGPsec) [31]. In RPKI, RegionalInternet Registries (RIRs) allocate IP prefixes and authorizespecific autonomous systems (ASes) to be the origin of routes.This information is stored in route origin authorization (ROA).Routers use the ROAs to distinguish legitimate routes fromleaked or hijacked routes. This is known as route originvalidation (ROV).The insecurity of inter-domain routing and the ability ofRPKI to address the insecurity has not transpired into wide-scale deployment of RPKI [18], [24]. One of the reasons is thepossibility of RIRs to unilaterally takedown IP prefixes, eitherdeliberately or accidentally, that will result in the prefix of theaffected ASes being unreachable when ROV is performed [11].The hierarchical structure of RPKI gives RIRs the power torevoke and invalidate any objects that it has issued.As centralized authorities are easy targets for legal surveil-lance and coercion, is it possible to prevent a state-sponsoredattacker from imposing its demands on RIRs without drasti-cally changing the structure of RPKI? The RIRs are bound bythe law of the country they are based in. Their members whoare based in different countries do not have a recourse whentheir prefix is taken down.In the past, there have been situations where these problemshave taken practical relevance. In 2011, RIPE NCC took thestate of Netherlands to court when the Dutch police orderedto it to lock registration of four IP address blocks [38], [42].Nevertheless, it was forced to lock down the registrations.More recently, RIPE NCC mistakenly deleted 2669 ROAs on 1April 2020 and were reinstated on 2 April [39]. This meant that the announcement for these resources were ‘unknown’. On theday when these ROAs were missing, RosTelecom had a routeleak [35]. While the two events seem independent, accordingto RIPE NCC, 12 prefixes whose ROAs were deleted wereaffected by the route leak. Furthermore, RIPE NCC transferredan IP prefix block from a member to another entity based ona German court order transferred to them through a Dutchcourt [40]. As a matter of procedure, they will do the same ifsimilar situations arises in the future. In the context of RPKI,this means RIPE NCC will “revoke any certificates generatedby the RIPE NCC” [41].In this work we address these issues that are prevalent inthe deployed RPKI system by constructing a distributed RPKIsystem that relies on threshold signatures, a specific instance ofsecure multiparty computation (MPC). Our solution, withoutrequiring significant changes to BGP and RPKI, restrictsthe power of RIRs and only allows revocation of allocatedresources in legitimate cases with the cooperation of a numberof RIRs.
A. Significance of the threat model
BGP without RPKI operates in a default-accept mode whereany autonomous system (AS) can announce a BGP route forany IP prefix and the other ASes will accept the route bydefault. The default-accept mode has made BGP vulnerable toprefix hijacks, where a malicious AS announces a route for IPprefixes it does not own such that the traffic for those prefixesare sent to it, and sub-prefix hijacks, where a malicious ASannounces a more specific IP prefix than the one that has beenallocated [2], [7], [13], [26].RPKI entrusts hierarchical and centralized authorities tobe honest. Malfunctions or coercion by law enforcementauthorities is not incorporated into the threat model. Such aweak threat model creates an imbalance of power betweenthe RIRs and its members. Moreover, the power imbalancewith RPKI is greater than with Web PKI. In RPKI, there is nooption to request certificates from different authorities. Hence,the reliance on specific RIRs is greater.Members are further weakened when the authority is basedin a different country than their own. The manipulations atthe level of BGP is more coarse-grained than domain nameseizures as BGP granularity is limited to / , i.e., 256 IPv4addresses [11]. The RIRs are bound by the law of the countrythey are based in. If members are affected, they may need totake the issue up in another country. The slow process mayresult in a loss of business.1 a r X i v : . [ c s . CR ] F e b . Threshold signatures for RPKI We propose a distributed RPKI system based on thresholdsignatures. Threshold signatures is a cryptographic techniquewhere a threshold of t + 1 parties out of a set of n partiesare required to jointly compute a signature on a message.Although the signing process is distributed, the verificationscheme remains unchanged. Threshold signatures are morerobust to adversarial attacks in settings where signatures areto be generated in a system where individual parties cannotbe entirely trusted.Threshold signatures provide a method to distribute trust andthey are practical in settings where the number of participatingparties is small. One of the deployment method of RPKI is hosted RPKI. There are five RIRs and threshold signatureprotocols are practical when there are only five participatingparties. Hence, our system requires a threshold of them toagree before making changes to RPKI objects. This preventsany RIR from unilaterally making changes.Our solution can be described as follows: threshold signa-tures use shares of the private key, where each of the fiveRIRs will have a share of the private key while none ofthem have the entire private key. Using only the shares, theRIRs can collaboratively sign ROAs and CRLs. However,they cannot unilaterally perform any of these actions. Ourmechanism prevents them from acting maliciously unilaterally.Most importantly, threshold signatures support a strongerthreat model where corrupted RPKI authorities are not entirelytrusted and yet play a significant role in making BGP secure.
Contributions.
A summary of our contributions: • We construct a distributed RPKI system based on thresh-old signatures that addresses three issues: (1) preventingunilateral IP prefix takedowns, (2) limiting the scope andimplications of attacks on RIRs, and (3) enabling validationin case of missing trust anchor. • We propose two deployment models of our solution anddiscuss the trade-offs in these models. • We show the performance of our distributed RPKI systembased on four threshold signature protocols, all of which havea stronger threat model than the existing RPKI system. • We perform extensive evaluation of our system and showthat our system is not only efficient for today’s requirements,it can also meet future demands.
Outline.
We provide preliminaries in Section II. We elab-orate on the system and threat model and describe our dis-tributed RPKI system in Section III. Then we discuss theperformance of our distributed RPKI system in Section IV.In Section V, we analyse historical RPKI data to understandthe number of ROAs issued/revoked over time and show thatour system satisfies the requirements. Finally, we discuss therelated works in Section VI and we conclude in Section VII.II. P
RELIMINARIES
A. RPKI
RPKI architecture includes CA certificates, end-entity (EE)certificates and trust anchor. A resource holder needs a CA certificate to sub-allocate resources and to issue resource cer-tificates. EE certificates verify signed objects (e.g., ROAs andmanifests). The private key corresponding to the public keyin an EE certificate cannot be used to sign other certificates.There is a one-to-one mapping between EE certificate andsigned objects. If the EE certificate is revoked, then thecorresponding signed object is automatically revoked. CAcertificate is used to sign EE certificate. A trust anchor isa self-signed X.509 CA certificate in RPKI that is at thehead of the chain and it is assumed to be trusted. In X. 509architecture, the chain of trust is derived from this authoritativecertificate. The trust anchor contains a public key in the subjectPublicKeyInfo field along with the associateddata that are used by the relying parties to validate a signatureon a certificate or signed objects, such as ROAs [27], [36]ROAs are digitally signed objects, X.509 certificates [32],[12], that provide a method to verify that an IP address blockholder (RIR) has authorized an AS to originate routes tospecific prefixes within that address block. Note that eachROA includes exactly one ASN. However, multiple ASNsmay be authorized, but each one requires a separate ROA.Moreover, issuance of subordinate certificates corresponds tosub-allocation of IP-addresses. A Certificate Revocation List(CRL) is a list of resource certificates that have been revoked,and should not be relied upon by the relying parties. A CRLis always issued by the same CA that issues the correspondingcertificates.There are two RPKI models: delegated RPKI and hostedRPKI. In the delegated RPKI model, AS runs a CA as a childof RIR (or NIR or LIR), generates its own certificate, gets itsigned by the parent CA. This model allows the AS to operateindependent of the parent RIR. For large operators of a globalnetwork, this model is suitable so that they do not need tomaintain ROAs through the different web interfaces of theRIRs. However, this model is not suitable for all as it requiresrunning a CA and maintaining the ROAs.In the hosted-RPKI model, RIRs host the CA, that is, thesame entity that allocates IP resources also runs the CA tovalidate the ROAs. Thus, in this model, they are trust anchors.In a way, this is meaningful as the RIRs already know theowner of the address space. Existing RPKI systems are tied-up with the login credentials of the ASes at the RIR. Signingand key rollover is automatic. It is easy for the owners ofthe address space to begin using hosted RPKI than delegatedRPKI as the CA functionality is taken care of by the RIR.This model is convenient for most ASes. It is easier to use andit is especially useful for members with a small network andwith limited resources. Even large providers such as Cloudflaremake use of hosted RPKI . Furthermore, the RIR assumesresponsibility to publish the signed objects. However, thisconvenience comes at the cost of further centralization ofpower as the RIRs also handle the private keys used to signROAs. https://ripe77 . ripe . net/presentations/156-RPKI-deployment-at-scale-RIPE-1 . pdf . ECDSA The scheme is parameterized by a curve point G of primeorder p , and we write Z p for the field of order p . We use H to denote a function mapping arbitrary length messages untoelements of Z p . Key Generation . KGen (1 λ )
1) Sample at random sk ← Z p as the signing key.2) Compute pk = sk · G as the public verification key.3) Output ( sk , pk ) . Signing . Sig ( sk , M )
1) Sample at random an instance key k ← Z p .2) Compute R = ( r x , r y ) = k · G . If r x ≡ p ) , goback to step 1.3) Compute s = k − ( H ( M ) + sk · r x ) where H is a hashfunction.4) Output σ = ( r x , s ) . Verification . Vf ( pk , M, σ )
1) Let ( r (cid:48) x , r (cid:48) y ) = s − ( H ( M ) · G + r x · pk ) .2) Output r (cid:48) x = r x . Correctness . We have s − ( H ( M ) · G + r x · pk ) (1) = k ( H ( M ) + sk · r x ) − ( H ( M ) · G + r x · pk ) (2) = k · G · (( H ( M ) + sk · r x ) − ( H ( M ) + sk · r x )) (3) = k · G = ( r x , r y ) , (4)which shows that valid signatures verify. C. MPC and threshold signatures
In our work, we use threshold signature protocols that arebased on secret sharing. Specifically, we use additive sharingand Shamir sharing schemes. We use the notation [ a ] to denotea value a that is secret-shared, that is, no single party canaccess it. For a ∈ Z p , the shares [ a ] are also elementsof Z p . We use the command Open to reconstruct from thesecret shared values such that a ← Open ([ a ]) For malicioussecurity, we use message authentication code (MAC) schemeof SPDZ [15], [16].In SPDZ, a value a is represented as [ a ] =(( a , . . . , a N ) , ( γ ( a ) i , . . . , γ ( a ) N )) where a i is a share of a and γ ( a ) i is the MAC share authenticating a under a globalkey α ∈ Z p such that a = (cid:80) i a i and α · a = γ ( a ) = (cid:80) i γ ( a ) i .Each party i holds the pair ( a i , γ ( a ) i ) . The execution of Open in SPDZ involves the broadcast of the shares a i byeach party and computing (cid:80) i a i . Then the MAC is checkedto confirm that a is correct. For this check, each partycomputes γ i ( a ) − α i a , broadcasts the commitment and checksif (cid:80) i = γ i ( a ) − α i a .Secure computing of ECDSA signatures does not onlyrequire the secret key sk to remain secret from all the partiesbut also the instance key k . The computation of k − shouldalso be performed securely so that information about k is notrevealed. This is also the the most computationally expensivepart of securely computing ECDSA signatures. III. D ISTRIBUTED
RPKI
A. Threat Model
In our distributed RPKI system, we consider a strongerthreat model than the existing RPKI system. The existingthreat model of RPKI includes external adversaries, but not theparticipating entities, such as RIRs, to be a possible attacker. Inthis work, in addition to the threats considered in the existingsystem, we do not consider the RIRs to be entirely trustworthy.Our threat model accounts for mistakes by the RIR as thehosted CA, the RIR under attack from an external adversaryincluding legal coercion to modify, revoke or to inject RPKIdata. All these scenarios require access to the signing keyfor the attack to work. We can capture these scenarios in oursystem by incorporating RIRs in the threat model. Note thatattacks on the publication point, such as deletion of RPKI data,are beyond the scope of this work.Standard MPC terminology provides us with a tool kit todiscuss threat models that not only includes external adver-saries but also the participating parties. Thus, we introducestandard MPC terminology to describe threat models in adistributed setting. We consider adversary power, that is,whether an adversary is passive or active. Then, we describethe guarantees that can be achieved when the threshold ofhonest parties varies. Finally, we describe which guaranteesour solution supports and how it translates to the threatsagainst RPKI. a) Honest-but-curious vs. malicious security.:
MPC pro-tocols can be classified in terms of the power of the adversary.An adversary can be honest-but-curious or malicious . Anhonest-but-curious adversary follows the protocol while amalicious adversary does not follow the protocol and mightactively disrupt the protocol. Security against honest-but-curious adversary is sufficient in many real life scenarios.If the RIRs trust each other not to act maliciously andinstead consider each other to be a necessary check on eachother’s operation, a protocol secure against honest-but-curiousadversary is sufficient. Such a protocol keeps the signing keyaway from any internal adversaries and curious employeesat the RIRs. On the one hand, a malicious adversary hasfull control over the RIRs and can disrupt the protocol. Forinstance, it can send wrong values or delay the sending ofvalues. On the other hand, honest-but-curious adversaries areassumed to provide the correct inputs during the protocol sothat no checks on the correctness of the inputs needs to beperformed. As might be obvious, a protocol against maliciousadversaries provides stronger security guarantees. b) Honest vs. dishonest majority.: Let n be the numberof RIRs participating in the distributed RPKI system. Duringthe execution of a threshold signature protocol, a threshold t number of RIRs need to be available for the protocol tobe successfully executed. When a majority of the RIRs arehonest, a threshold t ≤ (cid:98) ( n − / (cid:99) of parties are neededto sign, then it is called honest majority . When a minorityof the RIRs are honest, that is, t < n , the protocol is saidto be secure for a dishonest majority . In the case of honest3 rust Anchor Hosted CAThreshold SignatureModuleRPKIDB
Hosted RPKI
RIR CAThreshold SignatureModuleRPKIDB reposreposFig. 1. System setupHosted CAThreshold SignatureModuleRPKIDB
RIPE NCCARINLACNIC AFRINICAPNIC reposreposMPCFig. 2. Distributed RPKI architecture majority protocols, as long as three-out-of-five RIRs do notcollude, the key is not disclosed to anyone. As the RIRsoften do not converge on the same policies, this may not bea strong assumption [33]. However, there are situations wherea dishonest majority protocol might be needed as it providesstronger security such that the adversary needs to corrupt allthe parties to be able to access the signing key. A dishonestmajority protocol might also be required when the signatureshould only be created when there is unanimity among theRIRs.
B. System setup
We present the system architecture in this section. Thesetup at each RIR is shown in Figure 1 and the distributedRPKI architecture is shown in Figure 2. Each RIR has twocomponents: Trust anchor and Hosted RPKI. Each of them hasa CA, a threshold signature module and access to a local RPKIdatabase. All the certificates and the signed objects issuedby the two CAs are published in public access repositories,through rsync or RRDP [6].Our system incorporates all parts of the RPKI that requiresgenerating signatures, which includes the creation of signedobjects, ROAs, as well as signing of the resource certificatesof children and the issuance of CRLs. We distribute the taskof creating signed objects among multiple RIRs. As there arefive RIRs, we use n = 5 in our system.We focus on the key generation and the signing operationin a distributed RPKI system, such that no RIR has access tothe signing key. RIRs create their shares of the secret key andhave access only to these share and not to the secret key. Forcommunication between the RIRs, we assume the existence of Key generation
KGen (1 λ )
1) Each RIR takes a security parameter λ as theinput and generates a signing key share for the j th member by randomly sampling [ sk j ] ← Z p .2) Each RIR locally converts [ sk j ] to [ sk j ] · G .3) RIRs compute the public key pk j = Open ([ sk j ] · G )) = sk j · G .4) Output the secret key shares and the public key ([ sk j ] , pk j ) . Fig. 3. Key generation protocol a synchronous communication network and that the protocolsare run on a point-to-point network [9], [28]. We also assumethat the RIRs use a secure and authenticated communicationchannel, e.g. using TLS.
C. DRPKI protocol phases
In our system, each RIR has a share of a private key foreach member, uses this share to collaboratively issue signedobjects and does not have access to the entire private key. Theprotocols we use in this paper are in the security-with-abortmodel. In this model, the protocol aborts if the participantsare not available. We note that threshold signature protocolsthat give guarantees on availability are possible.The interactive protocols in our system are run betweenthe All phases instigated by a Hosted CA and the interactiontakes place between the Threshold Signature modules. Dueto the computation and communication overhead, we need anefficient threshold signing protocol. This means, that whenthe signature is to be generated, there needs to be as littleoverhead as possible in comparison to traditional signatures.This is possible with protocols that move most of the cryp-tography to the preprocessing phase and requiring minimumprocessing in the online phase, when the message to be signedis available. Furthermore, we consider the efficiency in lightof the threat models we discussed in Section III-A. Based onthese requirements, we adapt the threshold signature protocolof Dalskov et. al. [14] for our purpose (Figures 3–6).
1) Key generation:
In the key generation phase, new keysare generated such that each RIR generates a signing key share [ sk j ] for each member and runs the key generation protocol. Atthe end of this phase, each RIR has the public key pk j and theirshare of the signing key [ sk j ] . The key generation protocolneeds to be run every time keys are to be generated. The keysdo not need to be stored in a HSM. The complete signingkey is not exposed unless a threshold number (depending onthe protocol being honest majority or dishonest majority ) ofRIRs have been compromised. Figure 3 describes the protocoldetails.
2) Signing:
The threshold signing protocol we use hastwo preprocessing phases and one online phase. The firstpreprocessing phase is independent of the member for whom4 ember independent preprocessing
For each signature to be generated,1) RIRs generate tuples of secret shared values of theform ([ a ] , [ b ] , [ c ]) such that a, b, c ∈ Z p where c = ab .2) They open the share [ c ] by running c ← Open ([ c ]) .3) Let [ k − ] = [ a ] .4) Each RIR locally generates (cid:104) k (cid:105) = ([ b ] · G ) · c − .5) Output the initial preprocessing tuple ( (cid:104) k (cid:105) , [ k − ]) . Fig. 4. Member Independent preprocessing
Member dependent preprocessing
1) RIRs input the generated signing key shares [ sk j ] and the initial preprocessing tuple ( (cid:104) k (cid:105) , [ k − ]) .2) They compute [ sk (cid:48) j ] = [ sk j /k ] by generating anadditional tuple and Beaver’s rerandomization tech-nique [3].3) Output the final preprocessing tuple ( (cid:104) k (cid:105) , [ k − ] , [ sk (cid:48) j ]) . Fig. 5. Member Dependent preprocessing the signature is to be generated. More specifically, this phase isindependent of the signing key to be used. This property allowsus to amortize this phase. This phase can be run betweenthe RIRs before the member’s request to generate a signaturearrives. Only an estimation of the number of signatures thatwould be required in a certain amount of time is required torun this phase. At the end of this phase, the desired numberof initial preprocessing tuples are generated and stored at eachRIR. Figure 4 describes the protocol details.The second preprocessing phase is dependent on the mem-ber for whom the signature is to be generated. The thresholdsignature modules at the RIRs use the one unused initialpreprocessing tuple. It is security critical that the initialpreprocessing tuples are not reused as it is equivalent to thereuse of the instance key k . At the end of this phase, thedesired number of final preprocessing tuples are generated andstored at each RIR. Figure 5 describes the protocol details.In the final signing phase, the member gives consent to thechanges that can be made through a standalone application.This consent is sent to all the RIRs. When a signature isto be generated, the message to be signed is sent by theRIR that initiates the signing protocol to the other RIRs.The message is checked, similar to the checks each RIRperforms in the existing RPKI system, where they check themessage locally for the message before they individually sign.However, in our case, the check is performed by all the RIRsfor all the messages that need to be signed. Furthermore, theconsent of the member is checked. The RIRs check whether Final signing phase
1) The member uses a standalone application to giveconsent, e.g., to transfer IP-space to another AS.The consent is sent to all the RIRs.2) Input the message to be signed M and the finalpreprocessed tuple ( (cid:104) k (cid:105) , [ k − ] , [ sk (cid:48) j ]) .3) The RIR initiating the protocol sends the message M to the other RIRs.4) The RIRs check the contents of M and the consentby the member before proceeding. If the check fails,they abort ⊥ . Else, they continue.5) Then the RIRs compute R ← Open ( (cid:104) k (cid:105) ) = ( bc − ) · G = a − · G = k · G .6) Let ( r x , r y ) ← R .7) Locally compute the share of the signature [ s ] = H ( M ) · [ k − ] + r x · [ sk (cid:48) j ] .8) Finally compute the signature s ← Open ([ s ]) andoutput σ = ( r x , s ) or σ = ⊥ . Fig. 6. Final signing phase the consent has been given for the specific change, e.g., thetransfer of IP space to another AS. Note that a transfer ofIP-space requires consent for a CRL for the existing EEcertificate associated with the ROA and to create a new signedROA. These checks prevent RIRs to unilaterally take decisionsto revoke certificates. If a threshold number (depending onthe protocol being honest majority or dishonest majority ) ofRIRs agree, then the RIRs locally compute their share of thesignature before jointly computing the final signature. Figure 6describes the protocol details. With regards to the format of themessages, we do not make any change to the form and fieldscompared to the existing RPKI system. The certificates takethe form of X. 509 certificates [25] while the signed objectsconform to RFC 6788 [29]. The RIRs check the contents ofthe message out-of-band.
3) Automation:
Our system is fully automated and does notneed manual intervention in its regular operation. Step 4 inFigure 6 checks the message before it is signed. This check,performed by all RIRs, verifies whether a consent has beenreceived from the INR holder in Step 1. If a threshold numberof RIRs have not received the consent, then the check failsand the automated signing protocol aborts.
4) Legitimate revocation without consent?:
So far, we haveassumed that revocation of allocated IP resources requires theconsent of the INR holder. What about cases where thereis a legitimate reason to revoke allocation? Let us take acase where ARIN was fraudulently induced to issue IPv4addresses [1]. After the fraud was detected and ARIN wona legal case, ARIN was able to take back the addresses. Usingour automated system with enforced consent, revocation ofthe IP address space in such a scenario will not be possible.However, we are able to accommodate legitimate revocationwith a minor change to the system.5ur automated system aborts the protocol if the check forconsent fails at Step 4 in Figure 6. Instead of aborting theprotocol, we can flag it with the requirement for manualintervention if the protocol is to be completed. Note that such amanual intervention will not require a large human effort as, inpractice, most organizations obtain IP address space from theirRIRs in good faith and there are only a few bad apples [43].We will require the RIRs to communicate off band beforethe protocol is completed. This mechanism also allows forlegitimate law enforcement requests to be processed by theRIRs, only when a threshold of other RIRs also agree. Notethat although technically possible, processing law enforcementmechanisms in this manner is akin to private regulation, whichwill require legal and policy changes for it to be realistic.
D. Deployment scenarios
We propose two different deployment models. We beginwith a na¨ıve deployment model and explain the reasons for itsfailure to solve the problem. Then, we present two solutionswith their associated trade-offs among the stake holders. Weemphasise that the trade-offs are not with respect to thesecurity, but with respect to the responsibilities of the differentstake holders.
Na¨ıve solution:
In a na¨ıve solution, our threshold signingmodule can be used for Hosted CAs. This solution allows forthe existence of the delegated CAs, which are beneficial toISPs who sub-allocate resources. This solution allows for IP-space owners to run their own CAs as well, that is, delegatedCA system can continue to function in parallel with hosted CAsystem, as it does in the current system. So the ISPs whichhave their own CA can delegate IP-space and sign the ROAs.However, only change is that the signing keys in the hosted CAsetup are not in the possession of the individual RIRs. The trustanchor from the existing RPKI exists and the RIR CA which ishigher in the hierarchy can still revoke certificates unilaterallyas it is not distributed. And, the threat model remains weakand unchanged.
Our solutions:
As the na¨ıve deployment scenario does notsolve the problem, we propose two deployment solutions. Ourfirst solution prevents unilateral takedown by the RIRs whileour second solution also prevents LIRs from unilaterally takingdown prefixes. Both our solutions distribute the trust anchor.Before discussing our solutions, we give an intuition behindour choice to distribute RPKI trust anchor. The notion of atrust anchor requires all child nodes to unconditionally trustan entity. In RPKI, there are five trust anchors, one at eachRIR, which the relying parties use to verify RPKI signatures.The concentration of power at trust anchors in the internetinfrastructure extends beyond RPKI and is also observable inDNS(SEC) and Web PKI. Although many of the problems andvulnerabilities are similar [4], [5], [45], [46], unlike DNS andWeb PKI, there are already five trust anchors in RPKI thatallows for a smooth transition to a distributed trust anchor.Furthermore, the existing system of five trust anchors has hadits issues. As the policies of each RIR with regards to trustanchor is different, some relying parties do not use the trust anchor of ARIN and ROAs issued under ARIN’s trust anchorlocator fall to the status of ‘Not Found’ [47]. This meansthat even when RPKI is implemented, a significant portionof the networks do not validate routes originating from NorthAmerica due to policy decisions and legal barriers [48]. Thus,in practise large parts of the world are prevented from havingbetter routing security. These issues can be prevented if thetrust anchor is not located at individual RIRs with their ownpolicies and is instead distributed across them.
Hierarchical deployment:
In our first solution, we proposea two-layered tree deployment that maintains the hierarchicalstructure of RPKI. In both layers, the RIRs use our thresholdsignature module. The upper layer generates a distributedtrust anchor to the five RIRs, while the lower layer usesthe threshold signing module for the Hosted CAs. In theupper layer, a distributed trust anchor is established usingour key generation protocol in Figure 3. Each RIR generatestheir signing key share and participates in the key generationprotocol to obtain the public key. Once the public key isobtained, each RIR adds the public key to their TAL as the subjectPublicKeyInfo [12]. Each RIR has a TA thathas the same public key in the TAL. As no RIR has the privatekey associated with this certificate, the RIR CAs do not need tobe kept offline. Thus, the RIRs do not need a subordinate CAto issue child certificates. Furthermore, as each RIR has thesame public key as part of the trust anchor and they have thesame subjectPublicKeyInfo in their TAL, access to theTAL from one RIR is sufficient for relying parties to validateroutes originating from any part of the world that has deployedRPKI. Note that to generate the child certificates, RIRs run thesignature generation protocol described in Section III-C2.In the lower layer, our threshold signing module is usedby the Hosted CAs to generate signed objects such as ROAs.We are able to support delegated CAs as the distributed trustanchor at the RIR CAs is used to generate child certificates.Furthermore, this solution allows for incremental deploymentas the LIRs who have already deployed their own CAs cancontinue to use them to serve their child nodes while thosewho have not deployed their own CAs can start using hostedCA. Note that the concerns regarding some LIRs being coercedby their country of registration remains.
Flat deployment:
In our second solution, instead of havingthe RIRs run two CAs, RIR CA and the Hosted CA, wecombine the two so that the RIRs only need to run one CA.Furthermore, we do not need a trust anchor as we replacethe top-down architecture with a flat deployment architecture.Not only do we eliminate the hierarchical structure of ex-isting RPKI, we also distribute trust. Moreover, this solutionaccounts for a stronger threat model where none of the CAsneed to be completely trusted. However, we do not supportdelegated CAs in this solution. The CAs only generate end-entity certificates and signed objects; they do not generate anyCA certificate that will allow child nodes to generate theirown signed objects. This also means that child nodes willneed the RIRs to generate signed objects for their child nodes.Nevertheless, we prevent any single entity to be all powerful6 (cid:104)(cid:104)(cid:104)(cid:104)(cid:104)(cid:104)(cid:104)(cid:104)(cid:104)(cid:104)
Majority Adversary power Honest-but-curious MaliciousHonest Shamir Mal. ShamirDishonest Semi. OT MASCOTTABLE IF
OUR
MPC
PROTOCOLS and require the participation of a threshold number of RIRsfor a signed object to be generated and ejected.IV. I
MPLEMENTATION AND EVALUATION
We have implemented our system in C++ and have usedMP-SPDZ [17] for the threshold ECDSA MPC protocols. MP-SPDZ includes threshold ECDSA protocol implementationsfor all the security models that we are concerned with: honest-but-curious and malicious as well as honest and dishonestmajority protocols. In particular, we use four protocols—Shamir, Mal. Shamir, Semi OT and MASCOT—that are shownin Table I. The former two are based on Shamir secret sharingwhile the latter two are based on additive secret sharing. Weuse all four protocols to implement the system described inSection III-C.
A. Deployment Setups
For performance evaluation, two deployments were set up.For each node, we used an Amazon AWS c5.2xlarge instancewith a 64-bit Intel Xeon CPU with 3 GHz and 16 GBRAM. We run all the evaluations on a single thread. To makeour evaluations as realistic as possible, we chose to run theexperiments based on the location of the RIRs. The five RIRsare in different continents of the world. So, in the first setting,we run experiments on five Amazon AWS instances that areplaced around the world such that they are representative ofthe location of the RIRs. Specifically, we use the instances atFrankfurt, N.Virginia, Sydney, Sao Paolo and Mumbai whilethe RIRs are based in Amsterdam, Virginia, Brisbane, SaoPaolo, Mauritius, respectively. The latency and the bandwidthbetween the instances is shown in Figure 7. Furthermore,we also consider the setting where the RIRs could, in thefuture, have virtual servers located close to other RIRs. Forthis purpose, we also run our experiments on the LAN inFrankfurt.
Frankfurt SydneySao Paolo MumbaiN. Virginia 114.9 | |
142 228.3 | | |
99 301.0 | | |
56 283.2 | | | Bandwidth between regions, where latency is in millisecondsand bandwidth is in Mbits/s
B. Experimental evaluations
Key generation.
We benchmark the 5-party key generationprotocol in both the settings. The total key generation time iscomposed of the timings for generating secret key and publickey. Secret key generation involves generating a field element [ sk ] ] while public key generation involves a local conversionof the field element into an elliptic curve point of order beforebeing opened. The timings shown in Table II are the mean andstandard deviation over 10 executions of the protocols wherethe value taken for each execution is the time noted when thelast party completes the protocol. While the honest majorityprotocols (Shamir and Mal. Shamir) only require one round ofcommunication for secret key generation, dishonest majorityprotocols (Semi OT and MASCOT) are costlier, especially inWAN setting. Signing.
We benchmark the preprocessing time (memberdependent and independent) to generates tuples and the onlinesigning time per signature in Table III. For preprocessing, wepresent the time taken to generate one tuple when 1000 tuplesare generated in an amortized manner. As the preprocessingdoes not depend on the message to be signed, thousands ofpreprocessed tuples can be generated and stored. They can beused when a new message is to be signed. Note that the onlinephase does not involve any elliptic curve operation and, hence,is computationally cheap.Although dishonest majority protocols are generally costlierthan honest majority protocols, Semi OT has the highestpreprocessing throughput in LAN setting (Table IV). SemiOT protocol uses additive sharing which is cheaper thanelliptic curve operations, which is the predominant cost duringpreprocessing. In the WAN setting communication becomesmore predominant than local operations. We also observe thatthe cost of malicious security in the case of honest majorityprotocol is very small. This is especially true in the WANsetting as the extra checks for Mal. Shamir are local operationswhile communication becomes the predominant cost.In Table V, we show the communication per party for thefour protocols. We note that the communication is asymmetricfor Mal. Shamir and Shamir. Hence, we present the mean ofthe communication over all the parties. We notice that the pre-processing communication per tuple as well as online signingis significantly higher for dishonest majority protocols thanhonest majority protocols. In comparison, the communicationoverhead per party is marginal for malicious security overhonest-but-curious protocols.V. A
NALYSIS
For the deployment of our distributed RPKI system, it needsto be efficient enough. In the previous section we discussedthe efficiency in terms of the runtime of our protocols. In thissection, we discuss whether they are efficient enough in termsof the number of signatures required by the RIRs. As oursystem involves all the five RIRs, we take into account thecumulative of the requirements of all of them. a) RPKI data:
We accessed the publicly available his-torical RPKI data maintained by RIPE NCC that includes the7
AN WANSecret Public
KGen
Secret Public
KGen
MASCOT . ± .
04 2 . ± .
02 9 . ± .
03 4490 ± .
74 1147 ± .
27 5637 ± . Semi OT . ± .
04 0 . ± .
02 1 . ± .
03 851 ± .
53 486 ± .
93 1337 ± . Mal. Shamir . ± .
00 1 . ± .
03 1 . ± .
02 198 ± .
23 487 ± .
61 685 ± . Shamir . ± .
04 1 . ± .
08 1 . ± .
06 284 ± .
38 382 ± .
48 666 ± . TABLE IIB
REAKDOWN OF KEY GENERATION TIMINGS IN MILLISECONDS FOR [ sk ] SHARING , AND pk . LAN WANPreprocessing Online
Sig
Preprocessing Online
Sig
MASCOT . ± .
01 1 . ± .
02 6 . ± .
02 50 . ± .
86 1055 ± .
23 1106 ± . Semi OT . ± .
01 1 . ± .
01 2 . ± .
01 9 . ± .
90 487 ± .
40 496 ± . Mal. Shamir . ± .
00 1 . ± .
02 2 . ± .
01 10 . ± .
68 283 ± .
06 294 ± . Shamir . ± .
00 1 . ± .
02 2 . ± .
01 3 . ± .
00 282 ± .
18 286 ± . TABLE IIIB
REAKDOWN OF SIGNING TIMINGS IN MILLISECONDS FOR PREPROCESSING AND ONLINE PHASES PER SIGNATURE . P
REPROCESSING TIMES ARE BASEDON AMORTIZED GENERATION OF
TUPLES .LAN WANPreprocessing Online Preprocessing OnlineMASCOT
209 529 20 0 . Semi OT . Mal. Shamir
699 714 91 3 . Shamir . TABLE IVB
REAKDOWN OF THROUGHPUT FOR PREPROCESSING ( TUPLES / SEC ) ANDONLINE PHASES ( SIGNATURES / SEC ). KGen
Preprocessing (per tuple) Online SigningMASCOT .
482 624 0 . Semi OT .
113 99 . . Mal. Shamir .
271 1 .
345 0 . Shamir .
206 0 .
437 0 . TABLE VC
OMMUNICATION PER PARTY (KB
YTE ) daily archive of the repositories of all the five RIRs from 2011onwards . We use the historical data from 11 March 2015 till10 August 2020. b) ROA analysis: We use the RPKI data to analyse thenumber of ROAs that have been added and removed per dayin a certain time period. We estimate the number of signaturesrequired based on this information. Figure 8 shows the changeon average day (mean taken over a month) in ROAs for thefive RIRs. On average, we need about signatures per day.However, there are days when the load is greater. This occurson days when many ROAs are re-issued. Figure 9 shows themaximum number of changes per month. Note the scale ony-axis: There is a twenty times difference from Figure 8.We observe from Table IV that for our slowest protocolMASCOT, we are able to produce . signatures/sec or signatures/day in the WAN setting. For our fastest https://ftp . ripe . net/rpki/ protocol, we are able to produce . signatures/sec or signatures/day in the WAN setting. Even our slowest protocolcan produce 10x more signatures than is required on anaverage day. All our other protocols are fast enough evenon days with peaks in Figure 9. In the LAN setting, all ourprotocols are fast and have the capacity to produce three ordersof magnitude more signatures. The efficiency of our systemmakes it possible to scale it as the adoption of RPKI increases.VI. R ELATED W ORK
Threshold Signatures for Internet Infrastructure.
Threshold signatures for DNSSEC have been considered inthe past. Cachin and Sanar [8] proposed a distributed DNSto avoid single point of failure, while Cifuentes et. al [10]use threshold signatures to emulate a HSM at an authoritativename server. Dalskov et. al [14] use threshold signaturesto secure DNSSEC signing keys when the zone and keymanagement is outsourced to DNS operators. Integration ofnew algorithms into DNSSEC can be done with ciphersuitenegotiation mechanisms and similar ideas can be applied forRPKI [23], [21], [22]. Finally, Shrishak and Shulman [44]initiated the research direction of using threshold signatures forRPKI. We extend that work further by developing and settingup a complete system in the Internet along with extensiveperformance evaluations.
Limiting the power of RIRs.
There have been two ap-proaches in the prior works to limit the power of RIRs inRPKI. One approach has been to add transparency logs and .dead objects to RPKI to note the consent of the InternetNumber Resource (INR) owner for revocation [20]. Heilmanet. al [20] detect when a ROA has downgraded from valid toinvalid or valid to unknown state and check whether a .dead object is present. This approach requires relying parties toperform ROVs, if it is to be effective. ROV deploymentmonitor , a monitoring platform [37] shows that only a few https://rov . rpki . net Dates R O A s a dd e d AFRINICAPNIC ARINLACNIC RIPENCC
Dates R O A s r e m o v e d AFRINICAPNIC ARINLACNIC RIPENCC
Fig. 8. Number of ROAs added and removed on average per day from March 2015 to August 2020
Dates R O A s a dd e d AFRINICAPNIC ARINLACNIC RIPENCC
Dates R O A s r e m o v e d AFRINICAPNIC ARINLACNIC RIPENCC
Fig. 9. Maximum per month of ROAs added and removed from March 2015 to August 2020 relying parties, 124 ASes, perform ROV, while there are 67599ASes as of 10 August 2020 . Furthermore, this approach failsin the hosted RPKI setting as the .dead objects that are usedto signify consent from the child can be signed by the parentnode allowing the parent to impersonate the child.The second approach replaces the existing RPKI systemwith blockchain [19]. In this approach, the role of RIRs islimited to providing new resources and they cannot revokealready allocated resources. In addition to the large-scalechanges that this approach requires, blockchain has otherdeployment issues such as consensus algorithm and the lackof incentive for the nodes to run the blockchain. While [34]suggested to use proof-of-stake as the consensus algorithm, ithas the possibility to create another form of power imbalancewhere the nodes with a larger stake such as large ISPs willbecome powerful players.VII. C ONCLUSION
RPKI offers security benefits to BP and yet, it is not widelydeployed. One reason is that it opens up the possibility forunilateral IP-prefix takedown. In this work, we make a smallchange to RPKI and propose a distributed RPKI that relies onprevention rather than detection of takedowns. As our solutionrequires communication between the RIRs, we hope that itwill re-instigate discussions between the RIRs on the need . caida . org/data/as-relationships/ for further collaboration. We propose two deployment models,the second of which eliminates the hierarchical structure ofthe existing RPKI and flattens the power relations. Both ourdeployment models distribute the trust anchor and prevent thescenario where validation fails due to the unavailability of atrust anchor. We perform extensive evaluation to assess theefficiency of our solution based on four threshold signatureprotocols and show that our solution scales when the deploy-ment of RPKI increases.A CKNOWLEDGMENT
This work has been co-funded by: the German FederalMinistry of Education and Research and the Hessen StateMinistry for Higher Education, Research and Arts within theirjoint support of the National Research Center for Applied Cy-bersecurity ATHENE; the Deutsche Forschungsgemeinschaft(DFG, German Research Foundation): GRK 2050/251805230and SFB 1119/236615297.R . arin . net/vault/about us/media/releases/20190513 . html.[2] Hitesh Ballani, Paul Francis, and Xinyang Zhang. A study of prefixhijacking and interception in the internet. In SIGCOMM , pages 265–276. ACM, 2007.[3] Donald Beaver. Efficient multiparty protocols using circuit randomiza-tion. In
CRYPTO , volume 576 of
Lecture Notes in Computer Science ,pages 420–432. Springer, 1991.
4] Henry Birge-Lee, Yixin Sun, Anne Edmundson, Jennifer Rexford, andPrateek Mittal. Bamboozling certificate authorities with { BGP } . In { USENIX } Security Symposium ( { USENIX } Security 18) , pages833–849, 2018.[5] Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, and MichaelWaidner. Domain validation++ for mitm-resilient pki. In
Proceedings ofthe 2018 ACM SIGSAC Conference on Computer and CommunicationsSecurity , pages 2060–2076, 2018.[6] Tim Bruijnzeels, Oleg Muravskiy, Bryan Weber, and Rob Austein. TheRPKI repository delta protocol (RRDP).
RFC , 8182:1–24, 2017.[7] Kevin R. B. Butler, Toni R. Farley, Patrick D. McDaniel, and JenniferRexford. A survey of BGP security issues and solutions.
Proceedingsof the IEEE , 98(1):100–122, 2010.[8] Christian Cachin and Asad Samar. Secure distributed DNS. In
International Conference on Dependable Systems and Networks, 2004 ,pages 423–432. IEEE, 2004.[9] Ran Canetti. Universally composable security: A new paradigm forcryptographic protocols. In
FOCS , pages 136–145. IEEE ComputerSociety, 2001.[10] Francisco Cifuentes, Alejandro Hevia, Francisco Montoto, Tom´as Bar-ros, Victor Ramiro, and Javier Bustos-Jim´enez. Poor man’s hard-ware security module (pmhsm): A threshold cryptographic backend forDNSSEC. In
LANC , pages 59–64. ACM, 2016.[11] Danny Cooper, Ethan Heilman, Kyle Brogle, Leonid Reyzin, and SharonGoldberg. On the risk of misbehaving RPKI authorities. In
HotNets ,pages 16:1–16:7. ACM, 2013.[12] David Cooper, Stefan Santesson, Stephen Farrell, Sharon Boeyen,Russell Housley, and W. Timothy Polk. Internet X.509 public keyinfrastructure certificate and certificate revocation list (CRL) profile.
RFC , 5280:1–151, 2008.[13] Jim Cowie. China’s 18-minute mystery, 18 November 2010.https://web . archive . org/web/20200109211935/https://dyn . com/blog/chinas-18-minute-mystery/.[14] Anders P. K. Dalskov, Claudio Orlandi, Marcel Keller, Kris Shrishak,and Haya Shulman. Securing DNSSEC keys via threshold ECDSAfrom generic MPC. In ESORICS (2) , volume 12309 of
Lecture Notesin Computer Science , pages 654–673. Springer, 2020.[15] Ivan Damg˚ard, Marcel Keller, Enrique Larraia, Valerio Pastro, PeterScholl, and Nigel P. Smart. Practical covertly secure mpc for dishonestmajority – or: Breaking the spdz limits. Cryptology ePrint Archive,Report 2012/642, 2012. https://eprint . iacr . org/2012/642.[16] Ivan Damg˚ard, Valerio Pastro, Nigel P. Smart, and Sarah Zakarias.Multiparty computation from somewhat homomorphic encryption. In CRYPTO , volume 7417 of
Lecture Notes in Computer Science , pages643–662. Springer, 2012.[17] Data61. MP-SPDZ - Versatile framework for multi-party computation,7 June 2019. https://github . com/data61/MP-SPDZ.[18] Yossi Gilad, Avichai Cohen, Amir Herzberg, Michael Schapira, andHaya Shulman. Are We There Yet? On RPKI’s Deployment andSecurity. In NDSS , 2017.[19] Adiseshu Hari and T. V. Lakshman. The internet blockchain: Adistributed, tamper-resistant transaction framework for the internet. In
HotNets , pages 204–210. ACM, 2016.[20] Ethan Heilman, Danny Cooper, Leonid Reyzin, and Sharon Goldberg.From the consent of the routed: improving the transparency of the RPKI.In
SIGCOMM , pages 51–62. ACM, 2014.[21] Amir Herzberg and Haya Shulman. Negotiating dnssec algorithms overlegacy proxies. In
International Conference on Cryptology and NetworkSecurity , pages 111–126. Springer, 2014.[22] Amir Herzberg and Haya Shulman. Cipher-suite negotiation for dnssec:Hop-by-hop or end-to-end?
IEEE Internet Computing , 19(1):80–84,2015.[23] Amir Herzberg, Haya Shulman, and Bruno Crispo. Less is more:cipher-suite negotiation for dnssec. In
Proceedings of the 30th AnnualComputer Security Applications Conference , pages 346–355, 2014.[24] Tomas Hlavacek, Amir Herzberg, Haya Shulman, and Michael Waidner.Practical experience: Methodologies for measuring route origin valida-tion. In
DSN , pages 634–641. IEEE Computer Society, 2018.[25] Geoff Huston, George Michaelson, and Robert Loomans. A profile forX.509 PKIX resource certificates.
RFC , 6487:1–32, 2012. [26] Geoff Huston, Mattia Rossi, and Grenville J. Armitage. Securing BGP- A literature survey.
IEEE Communications Surveys and Tutorials ,13(2):199–222, 2011.[27] Geoff Huston, Samuel Weiler, George Michaelson, Stephen T. Kent, andTim Bruijnzeels. Resource public key infrastructure (RPKI) trust anchorlocator.
RFC , 8630:1–11, 2019.[28] Jonathan Katz, Ueli Maurer, Bj¨orn Tackmann, and Vassilis Zikas.Universally composable synchronous computation. In
TCC , volume7785 of
Lecture Notes in Computer Science , pages 477–498. Springer,2013.[29] Matt Lepinski, Andrew Chi, and Stephen T. Kent. Signed object templatefor the resource public key infrastructure (RPKI).
RFC , 6488:1–13,2012.[30] Matt Lepinski and Stephen T. Kent. An infrastructure to support secureinternet routing.
RFC , 6480:1–24, 2012.[31] Matt Lepinski and Kotikalapudi Sriram. BGPsec protocol specification.
RFC , 8205:1–45, 2017.[32] Charles Lynn, Stephen T. Kent, and Karen Seo. X.509 extensions forIP addresses and AS identifiers.
RFC . internetgovernance . org/2011/11/23/in-important-case-ripe-ncc-seeks-legal-clarity-on-how-it-responds-to-foreign-court-orders/.[34] Jordi Paillisse, Miquel Ferriol, Eric Garcia, Hamid Latif, CarlosPiris, Albert Lopez-Bresco, Brenden Kuerbis, Alberto Rodr´ıguez-Natal, Vina Ermagan, Fabio Maino, and Albert Cabellos. IPchain:securing IP prefix allocation and delegation with blockchain. In iThings/GreenCom/CPSCom/SmartData , pages 1236–1243. IEEE, 2018.[35] Qrator Labs. This is how you deal with route leaks, 2 April 2020.https://habr . com/en/company/qrator/blog/495260/.[36] Raksha Reddy and Carl Wallace. Trust anchor management require-ments. RFC , 6024:1–14, 2010.[37] Andreas Reuter, Randy Bush, ´Italo Cunha, Ethan Katz-Bassett,Thomas C. Schmidt, and Matthias W¨ahlisch. Towards a RigorousMethodology for Measuring Adoption of RPKI Route Validation and Fil-tering.
ACM SIGCOMM Computer Communication Review . ripe . . ripe . net/support/service-announcements/accidental-roa-deletion.[40] RIPE NCC. A First for the RIPE NCC: Seizure of the “Right toRegistration of IPv4 Addresses” for the Recovery of Money, 2 October2020. https://labs . ripe . . ripe . . ripe . net/publications/news/about-ripe-ncc-and-ripe/ripe-ncc-blocks-registration-in-ripe-registry-following-order-from-dutch-police.[43] Stephen M. Ryan and Sam C. Neel. Taking a hard line on fraud, 13 May2019. https://teamarin . net/2019/05/13/taking-a-hard-line-on-fraud/.[44] Kris Shrishak and Haya Shulman. Limiting the power of RPKIauthorities. In ANRW , pages 12–18. ACM, 2020.[45] Haya Shulman and Michael Waidner. Towards security of internet nam-ing infrastructure. In
European Symposium on Research in ComputerSecurity , pages 3–22. Springer, 2015.[46] Haya Shulman and Michael Waidner. One key to sign them allconsidered vulnerable: Evaluation of { DNSSEC } in the internet. In { USENIX } Symposium on Networked Systems Design and Imple-mentation ( { NSDI } . mail-archive . com/apops@apops . net/msg00796 . html.[48] Christopher S Yoo and David A Wishnick. Lowering legal barriers torpki adoption. U of Penn Law School, Public Law Research Paper ,(19-02), 2019.,(19-02), 2019.