Optimization of a Public Key Infrastructure Anders Fongen Norwegian Defence Research Establishment Norway
[email protected]
Abstract—The traffic patterns related to operation of a Public Key Infrastructure (PKI) can be modeled and optimized. Even though PKI has been around for three decades, relatively few results have been presented on this matter. The contribution of this paper is a PKI traffic model based on observation of familiar use cases together with hypotheses from scale free graph theory. Based on a set of estimated parameters, an optimized organization of a PKI is proposed. One key element has been to avoid costly revocation mechanisms. The proposed solution includes the use of short lived certificates which do not need a revocation mechanism, and the use of cached validation proofs to save protocol round trips. PKI also presents special challenges during operation in tactical wireless networks. Reduced bandwidth and connectivity requirements are commonly considered as essential properties for a successful tactical application. The paper also proposes an organization of a PKI for a mixed tactical/strategic network. Keywords-Public Key Cryptography, Scalability, Optimization
I. I NTRODUCTION A Public Key Infrastructure (PKI) offers services for key and certificate generation, deployment and revocation. Revocation is necessary in those cases where the use of a key should be prematurely terminated (before its certificate expires). The revocation status of all certificates is made available to relying parties as revocation lists or online status providers within a deadline called the revocation latency after the revocation decision has been made. The possibility that certificates may be revoked creates the need for certificate validation as a part of a signature verification or before a message can be encrypted with the recipient’s public key. Certificate validation poses some ugly problems related to connectivity requirements, bandwidth requirements, trust transitions and service semantics. The problem exacerbates in a cross-domain configuration, since the revocation information must be accessible across domains. Concerns have been raised for decades [1] over the revocation problem and researchers have been looking for alternative validation schemes with equivalent security guarantees. One reason for the initial enthusiasm over public key cryptography was the opportunity for secure communication without prior key agreements and without the need for online session key servers. A PKI arrangement which makes all participants dependent upon online services for every validation operation has spilled this advantage and offers little
convenience over a cheap and well-understood symmetric key distribution scheme.[2, p.416] A PKI arrangement without a revocation mechanism offers great advantages for the validation of End Entity (EE) certificates. For the validation of Certificate Authority (CA) certificates the situation is somewhat different, and the use of a “proof-of-validity” document is suggested. The remainder of the paper is organized as follows: In the next section, a general introduction of the PKI architecture will be given. Section III will discuss general optimization opportunities for a PKI. Section IV introduces the scale free model and other analytical tools that will be used in the subsequent traffic analysis. Section V presents a comparative analysis of the traffic patterns for multi-tiered PKIs in different configurations. Section VI concludes with short lived certificates as the best choice for a multi-tiered PKI and outlines the organization of a PKI based on that conclusion. Section VII provides a summary and conclusions. II. T HE PKI
OPERATIONS
The protocol operations related to a PKI are shown in Figure 1. The use case of the figure is a signed purchase order involving the following actors: • A Certificate Authority (CA) which issues certificates and revocation lists • A Registration Authority (RA) which establishes identity before certification • A Validation Authority (VA) responding to client requests for revocation status of certificates • A signer who signs the message with a signature made with his private key • A relying party who verifies the signature and checks the revocation status of the signer’s certificate. The protocol operations (numbered 1-4) related to the use case of Figure 1 are 1) Key and certificate generation. The RA establishes (verifies) the identity of the key holder and passes this information to the CA together with the public key for certification. The key pair can be generated by the key owner or by the CA, in the latter case the private key must be safely transported to the key holder. A typical lifetime for a certificate is 12 months, after which a new certificate is issued.
TABLE I F REQUENCY AND SIZE OF PROTOCOL OPERATIONS 1 2 3
Every 12 months Every 4 hours 300/day
4
300/day*#users
Size of certificate is 1200-1500 bytes Size of list is 700 bytes + 36 bytes * #entries A signature (including a certificate) adds 3000-12000 bytes to the message size, depending on the application The size of the PDUs to invoke a status provision service is approximately 3 kilobytes
2) Revocation list generation. All revoked, non-expired certificates are listed, the lists are signed by the CA and sent to the VA. Alternatively, the lists are sent directly to relying parties so that validation can be done without an online status provider. A typical issuing interval for revocation lists is 4 hours. 3) Signature generation. The key holder signs a message and includes the signature data and his public key certificate in the message. Alternatively, the relying party could obtain the certificate from elsewhere if needed. The frequency of signed messages can be any number, but for the purpose of the forthcoming calculations a number of 300 messages per day (by each active user) has been chosen. 4) Certificate validation. The relying party should check the revocation status of the signer’s certificate. It does so by querying the VA or by checking the most recent available revocation list. The frequency of validation operations is the total frequency of received messages (from all users) by the relying party. Again, please recall that the purpose of revocation checking is to guarantee a maximum latency from the time of a revocation decision until its full effect. Other arrangements, like certificates issued with short lifetime, can provide the same guarantees without revocation checking. III. PKI
OPTIMIZATION OPPORTUNITIES
The protocol operations shown in Figure 1 may be optimized so that they require less connectivity, less bandwidth and less protocol round-trips. There are also distribution technologies which may serve the same goals, like the use of messaging systems, distribution and caching networks etc. The identified optimization opportunities differ in their ability to integrate into existing application software (called COTS - Commercial Off The Shelf). COTS application may have established methods for key deployment, signature verification, certificate validation and revocation list processing with leave little flexibility for other ideas. The following discussion will identify how COTS software allow operation on optimized protocols. The following list numbers refers to the number symbols in Figure 1 and the data in Table I. 1) Key and certificate generation are unlikely candidates for optimization. For every user, this operation happens (under the estimated parameters) once per year,
Figure 1. The different actors and the protocol operations of a Public Key Infrastructure. The operations are indicated by numbers which are explained in the text.
and the transport of a few kilobytes each time is insignificant from a scalability perspective. 2) The distribution of revocation lists can be significantly reduced through the use of delta revocation lists, which only lists the certificates revoked since the most recent base revocation list was issued. Under a realistic revocation rate the delta lists are much smaller and offer substantial savings in network bandwidth demands. The cost of this variant is the time it takes for a newborn node to get updated on revocation information. None of the COTS software which has been evaluated supports the use for delta lists. A commonly found variation to this PKI operation is to offer the revocation lists directly to relying parties, often through a web server from which each relying party fetches its own copy with the HTTP protocol. This is wasteful from several reasons: (a) As a revocation list expire, all subscribers will fetch a new list within a short period of time, creating a high traffic peak in and around the list server. (b) The distribution of identical copies to many neighboring clients is wasting bandwidth. They should employ a multicast scheme instead. [3], [4] 3) Most COTS software include the signer’s certificate in the signed message, which is convenient for the relying party who does not need to cache certificates. On the other hand, a series of messages from the same sender will contain redundant data in every message except the first one. The relying party can make the
TABLE II C HOSEN PARAMETER VALUES FOR THE TRAFFIC ANALYSIS Number of users: Number of certificates (N): Revocation latency (te ): Messages per day (λtot ): Revocation rate:
1000 10000 4 hours 300 10 % per year
decision to fetch the certificate from a repository when needed, in order to reduce this redundancy. Again, this option is not seen supported in COTS software. 4) The validation operation in COTS software may use either revocation lists or an online revocation status provider. In the latter case, an opportunity for optimization is to cache responses for a while, since the responses for one particular certificate may be unchanged until a new revocation list has been issued. The choice of a non-zero issuing interval for revocation lists indicates our willingness to accept a non-zero risk for a revoked certificate to operate for a while. We choose to call this accepted time interval the revocation latency. Accordingly, responses from a status provider could be cached for a while as long as the revocation latency does not increase. IV. T RAFFIC ESTIMATES Based on the PKI arrangement shown in Figure 1 and the numbers in Table I the traffic volumes can be calculated, but some estimates regarding the properties of the use case must be made. The rate of messages exchanged between clients, the number of certificates in the system, the size of messages, the revocation rate and the probability distribution of senders/recipients must be estimated on the basis of a sound and realistic use case. The numbers presented in Table II have been chosen to emulate the situation in a wireless tactical network. Probability distribution of message addresses will be discussed later in this section. A. Scale free distribution For the probability distribution of senders/recipients of messages, a scale free distribution has been chosen. Scale free distribution [5] successfully describes the properties of social interactions like telephone calls and e-mails as well as network topologies (e.g. flight connections) and word frequencies in human languages. Scale free distribution is therefore considered as a justified model for the exchange of tactical messages. Scale free distribution implies that senders of messages to a given recipient can be ranked according to their message frequency. The sender of rank r sends twice as many messages as sender 2r and three times as many as the sender with rank 3r. In the following paragraphs, the certificate of rank r, denoted Cr , is assumed to be attached to messages
from the sender of rank r. The relative frequency of Cr is the fraction of messages received from this sender. The distribution is an inverse function which can be expressed as follows: The relative frequency f of Cr is: a (1) f (Cr ) = r where the value of a is determined so that N
a
∑ r =1
(2)
r=1
The value N is the size of the certificate population (number of distinct certificates). a is simply a scaling factor. B. Freshness cache Based on a scale free distribution and the traffic estimates shown in Tables I and II we can calculate the “cache miss” rate for a receiver cache with “freshness” requirements, e.g. with elements that expire and are removed from the cache. This analysis can be useful in two of the situations mentioned earlier: (1) If the certificates are excluded from the message, how often must a receiver retrieve certificates from a repository? (2) If the client holds a cache of responses from a status provider service, how often must it still invoke the status provider during certificate validation? The formal analysis of a “freshness cache” where the message address distribution is given by a scale free distribution was presented in MILCOM 2010 [6]. The cache-miss probability at the reception of message number b was found to be expressed by the following formula: N
a/r (a/r)λ tot te + 1 r=1
P(b) = P1 (b) + (1 − P1(b)) ∑ where
N
P1 (b) =
a
a
∑ (1 − x )b−1 · x
(3)
(4)
x=1
In this expression, the symbol te denotes the lifetime of a cache entry, and λtot denotes the total rate of received messages. N is the size of the certificate population. Figure 2 shows a plot of Equation 3 with the parameter values shown in Table II. It shows that the effect of the caching arrangement under these circumstances is quite limited (high miss rate). For the investigation of scaling techniques we need an expression for the cache effectiveness under different expiration times and certificate population. The expression is defined as follows: pmiss (te , N) = p1 (1000)
(5)
for the given values of te and N. The choice of b = 1000 means the effectiveness after 1000 received signatures,
1
rrev (k) = 1 −
0.98
(8)
Under the chosen parameters, the revoked fraction is 0.0509. We can now estimate the size of the revocation lists based on numbers in Tables I and II:
0.96 Cache miss probability
(1 − p0)k − 1 k ln(1 − p0)
0.94
10000 certificates ∗ 0.0509 ∗ 36 + 700 = 19024 bytes (9) 0.92
0.9
0.88
0.86 0
100
200
300
400
500
600
700
800
900
1000
No. of received certificates
Figure 2. Plot showing the performance of a freshness cache in a certificate validation scenario. The result from an online validation operation will be cached for te time. During this period, messages received from the same source (same certificate) will be validation based on the cached response. In case the cache entry does not exist or has expired, and online validation operation is necessary. The plot shows the probability for an online operation as a function of number of received messages.
which is equivalent to 3-4 days of operation. Here are some values of special interest for the rest of the paper: pmiss (4 pmiss (6 pmiss (4 pmiss (2 pmiss (6
hours, 10000) months, 10000) hours, 10) hours, 10) months, 10)
= 0.86 = 0.47 = 0.15 = 0.25 ≈0
C. Size of revocation lists Another necessary calculation is the estimated size of revocation lists. A typical revocation rate is expressed as “percent per year”. NIST statistics [7] estimates the revocation rate for US Government certificates to be 10 % per year. On the condition that revocations are independent events at a constant rate we find that the probability for a certificate not 2 to be revoked during √ one year is 0.9, after two years 0.9 and after six months 0.9. If the initial revocation probability is expressed as the value pair (t0 , p0 ), being (1 year, 0.1) from the NIST estimates, the probability for being revoked over a time tx is tx prev (tx ) = 1 − (1 − p0) t0 (6) Assuming a constant rate of key and certificate generation, the age distribution of the certificate population is uniform. The fraction of the certificate population (of maximum age k) which has been revoked at any time instant is therefore the finite integral of the probability distribution above: k Z (1 − p0)t t=0 1 k prev (t)dt = 1 − (7) rrev (k) = k 0 k ln(1 − p0)
Delta revocation lists represents the revoked certificates since the last Base revocation list was issued. The clients need the most recent base list and delta list in order to validate certificates. Two downloads are needed for newborn clients, which complicates the client configuration, and the support for delta lists are seldom found in COTS products. The traffic volume is greatly reduced, since a majority of the issued lists only represents revocation from the last few hours. The size of a delta revocation list can be calculated with Equation 8. The size of a delta revocation list increases for each issue and is “reset” by the base revocation list issue. Using our chosen parameter values, the sizes of delta lists are negligible. If, e.g., three out of four list issues are delta lists, the delta lists holds revocations from the last 4-12 hours, whereas the base revocation list holds revocation from the last 12 months. This arrangement roughly reduces the list volume with 75 %. More detailed calculations are given in [6]. D. The revocation latency As mentioned earlier in the paper, there is a latency from a revocation decision is made until the certificate is refused by all relying parties. In practice, a latency of 1-4 hours is acceptable in most applications. The revocation latency allows the system to exploit caching of validation information for a while, which may reduce bandwidth and connectivity demands. In this perspective, three approaches to validation will be investigated later in the paper: Revocation lists, caching of online status responses, and the use of short-lived certificates. V. T RAFFIC PATTERNS OF
MULTI - TIERED
PKI S
In a multi-tiered PKI structure the root CA (and the trust anchor) does not issue certificates directly to end entities (EE), but indirectly through a chain of subordinate CAs. They all have their certificates issued from the parent CA (except the root CA, who usually present a self signed certificate). The relying party who needs to validate an EE certificate must therefore validate the entire chain of certificates up to the trust anchor. Figure 3 outlines a multi-tiered PKI with three levels of CAs. When COTS software is used, certificate validation involves either revocation lists or online VA invocations. Different validation arrangements will now be analyzed from the perspective of client side traffic. The traffic between
servers, e.g., the Certificate Authority (CA), the Certificate Store (CS) and the Validation Authority (VA) is disregarded. COTS software products are consistently observed to include the entire certificate chain in the signature structure, which is subsequently called “COTS compliant”. Alternatively, the relying party could look up certificates in a certificate store (CS) when necessary. In this case the certificates are not included in the signature, which is denoted “COTS non-compliant”.
CS
Root CA
Sub CA
VA
4 5
Sub CA
4
A. Validation based on revocation lists 3
Two different variants will be investigated, both sends revocation lists directly to relying parties (as opposed to what Figure 1 indicates). Each CA will issue revocation lists regarding their subordinate certificates. The list issued by the “leaf” CA (labeled (3) in Figure 3) will represent EE certificates and could be rather large. In Section IV-C the size was estimated to be 19 kilobytes under the chosen conditions. The lists issued by upper CAs (labeled (4) in the same figure) will only represent subordinate CAs and be small, e.g. 1 kilobytes. The lists are fetched through independent HTTP operation and 500 bytes of protocol overhead are added in the calculations. Over a revocation latency period (4 hours), the relying party will receive 19.5kB + 1.5kB + 1.5kB = 23kB of data as revocation lists. 1) COTS compliant operation: COTS programs include the certificate chain in the signature operation, which means that the relying party receives 3 certificates (EE + 2 CA) with each signature, labeled (2) in Figure 3. Sizes of these varies due to encoding, they are here estimated to 6 kilobytes (3*1500 bytes in BASE64 coding). Over a 4 hours period the relying party receives 50 messages (300 per day according to Table II). The comparative volume of data received by the relying party is 6kB ∗ 50 + 23kB = 323kB. 2) COTS non-compliant operation: The certificates can be excluded from the signature (replaced by a reference of insignificant size) in order to eliminate the redundancy. The relying party will fetch the certificates on demand from a certificate store (CS) (labeled (5) in Figure 3) and cache them locally for the duration of their remaining lifetime (on average 6 months). The miss rate for the local cache indicates the frequency of retrieval operations from the CS. For EE certificates, the miss rate is pmiss (6 months,10000) = 0.47 and for CA certificates pmiss (6 months,10) = 0. This means that for 47 % of the received signatures, the EE certificate will need to be fetched from the CS. This retrieval operation takes 2 kilobytes of network capacity. The comparative volume of data received by the relying party is 2kB ∗ 0.47 ∗ 50 + 23kB = 70kB.
1 2
Signer
Relying party
Figure 3. A multi-tiered PKI with the client-oriented data flows indicated with arrows. Numbers are used for references in the text.
B. Validation based on status providers Status providers are also called Validation Authorities (VA), since relying parties trust their reports on revocation status for certificates (labeled (5) in Figure 3). They eliminate the need for distribution of revocation lists to relying parties. The responses from a VA can be cached for a while. In the case where the VA itself has access to absolutely fresh revocation information (like online access to the CA’s data base) the response can be cached for the duration of the revocation latency. If the VA is fed with the CA’s revocation lists, the response can be cached for the remaining lifetime of the revocation list1 , on average half the revocation latency. The choice in this analysis is to cache the responses for the duration of the revocation latency (4 hours). For responses regarding the EE certificates the effectiveness is given by pmiss (4 hours,10000) = 0.86 which means that 86 % of the validation operations will need to query the VA for revocation status. For CA certificates the expression pmiss (4 hours,10) = 0.15 indicates that CA certificates must be checked online in 15 % of received signatures. An invocation of a VA (an OCSP transaction) has been measured to generate approximately 3 kilobytes of network traffic. The relying party receives 50 signed messages over a 4 hour period and validation of each one involves the status checking of 1 EE and 2 CA certificates. Based on the cache miss rates given above, the traffic related to validation is: 50 ∗ 3kB ∗ (0.86 + 0.15 + 0.15) = 174kB. To be precise, only the positive status responses need to expire from the cache. The responses on revoked certificates 1 The OCSP protocol used by the VA can indicate the remaining lifetime of a status response.
will never change and may therefore be cached until the certificates expire. The hit rate will increase a little if this is taken into account, but it will also complicate the analysis and only result in marginal differences. 1) COTS compliant: Certificates can be included in the signature, which is the same situation as for validation based on revocation lists. The comparative volume of data received by the relying party is 6kB ∗ 50 + 174kB = 474kB. 2) COTS non-compliant: As for revocation lists, the certificates can be demanded from a CS on demand. The comparative volume of data received by the relying party is 2kB ∗ 0.47 ∗ 50 + 174kB = 221kB. C. The Proof of Validity A data structure closely related to a status provider response is the Proof of Validity (PoV). The PoV is a timestamped document attesting the validity status of a given certificate, and is signed by the CA (not the VA) The PoV is well suited for caching and distribution, even in a cross domain environment. In order to validate a certificate, a relying party need the certificate and its corresponding PoV, both non-expired. Revocation lists are not necessary. The PoV is quite compact, e.g., 1 kilobytes and has a lifetime equivalent to the revocation latency (4 hours). A retrieval operation using the HTTP protocol may generate 1.5 kilobytes of network traffic. PoVs can be distributed by a Certificate Store (CS), since the signature of a VA is not longer necessary. D. Short lived certificates The revocation latency guarantee can be obtained by the use of short lived certificates. They need not be checked for revocation if they are issued with the same lifetime as the revocation latency. The certificate becomes its own PoV. New keys are not generated, but the existing key pair is re-certified. The traffic related to revocation list distribution is now eliminated, but replaced with traffic related to certificate distribution (labeled (1) in Figure 3). New certificates will be generated by the CA at a high rate (e.g. every 4 hours), but not necessarily distributed to clients. Some clients may not want to create a signature within the validity period of the certificate. Therefore, certificates should be distributed in an on-demand manner. The relying party will need a copy of the certificate in order to verify a signature, which can be included with the signature or fetched from a Certificate Store (CS). The study of these two alternatives is the same as what was shown in Section V-A2. This analysis clearly shows that the EE certificate (short lived, large population) should be included in the certificate, whereas CA certificates (long lived, small population) should be fetched from a CS.
The traffic related to certificate distribution is (from the client perspective) 2 kilobytes for every revocation latency period. The relying party receives the EE certificate with every signature (2 kilobytes) and need to obtain CA certificates and CA PoVs from a CS with probabilities given by the pmiss function. As found in Section V-A2, caching of long lived CA certificates effectively eliminates the retrieval traffic. Caching of (short lived) PoVs for their remaining lifetime (2 hours on average) gives a miss rate of pmiss (2 hours, 10) = 0.25. The traffic related to retrieval of PoV for 2 CA certificates (1.5 kilobytes each) for each of 50 received signature during a 4 hour period is 50 ∗ 2 ∗ 1.5kB ∗ 0.25 = 38kB The comparative volume of data received by the relying party is 2kB + 50 ∗ 2kB + 38kB = 140kB. E. Server side traffic patterns The focus of the traffic calculations are on the client side of the network connections since clients are likely to be on the “disadvantaged” part of the network. However, with a large client population it is reasonable also to pay some attention to the traffic at the server side. We assume the values given in Table II where the number of active clients are 1000. This number of clients will retrieve revocation lists and their own certificates, and will invoke the VA services. 1) Distribution of revocation lists: Unless a distribution network is in place, in the form of a distributed cache or a messaging system, each of the 1000 clients will retrieve the revcocation lists from the CA separately. The list issued by the leaf CA is 19 kilobytes, which is retrieved over a HTTP connection (500 bytes extra), which becomes 19,5 megabytes during the issuing interval. The distribution of this traffic is highly uneven, since the clients will retrieve new lists during a short time interval. A large traffic peak must be expected in the CA list servers [3]. 2) Validation based on status providers: The client side traffic between the VA and one client was found to be 174 kilobytes over the revocation latency period. If the same VA serves all active clients, the server side traffic will be 174 megabytes over the same period. 3) Short lived certificates: The client side traffic between the CS and one client was found to be 38 kilobytes. If the same CS serves all clients, the server side traffic will be 38 megabytes. Related to distribution of issued certificates, the traffic is assumed to be 2 megabytes over the revocation latency period. Please observe the importance of multicast support in some of these operations: Revocation lists and PoVs are excellent candidates for distribution over a cooperative cache or a messaging system. This is not the case for VA based validation, since the responses are signed by the VA during service invocation.
F. Cross domain operation Cross domain operation means validating a signature from a different PKI domain. The certificate of the signature is issued by a different CA and does not have a certificate path of issuing CAs up to the trust anchor of the relying party. A cross certificate issued by one root CA to another connects the dots and solves this problem. A cross certificate is an expression of trust or acknowledgment in the other PKI’s identification and key management procedures. The relying party needs revocation info from the other PKI, which normally translates into a subscription to its revocation lists. Cross certification aggravates the existing problems related to scalability of revocation list distribution. Two aspects of the proposed short lived certificates facilitate cross certification: The absence of revocation information for End Entity (EE) certificates, and the single retrieval point (CS) for PoV signed by a CA. The relying party contacts the CS service point in the foreign PKI, obtains CA certificates and PoVs in order to validate the EE certificate path. The absence of CS signature also allows the CS to be easily replicated so that relying parties can have a short and effective network path to the stored data. The content of a CS could even be proactively replicated into other domains so that cross domain service invocation from relying parties is not necessary during validation. VI. O PTIMIZATION OF A MULTI - TIERED PKI Given the analysis and the calculations given the previous section we can consider the configuration which generates the least traffic. There are important considerations not covered in the analysis though, like: • How much traffic, on average and in peaks, is generated on the servers’ side? • To what extent depend the relying parties on connectivity to central servers? • How does the traffic scale with growing certificate population? • How well does the architecture support cross domain operation? The calculation of revocation list size in Section IV-C shows that its size grows linearly with the certificate population. On the other hand, VA-oriented validation as shown in Section V-B exhibits a traffic volume insensitive to certificate population. The distribution of new revocation lists to all relying parties almost at the same time creates high server load and high traffic peaks, which are generally unwelcome, particularly in disadvantaged networks. VA-oriented validation need frequent access to central servers, which is a disadvantage in tactical networks. The small population of CA PoVs lends itself better to prefetching than EE certificates, so this dependency may be mitigated in the case of short lived certificates.
CS
Root CA 3
1
Sub CA
3
Sub CA Caching network
5 2 4
Signer
Relying party
Figure 4. Optimal organization of a multi-tiered PKI. Arrows indicate the necessary flows of certificates and PoVs. Numbers are used for references in the text.
The existence of a VA also raises some security concern, since this is a trust anchor. It is accessible from anywhere in the domain (even other domains) and yet contains the private key of unlimited trust. The elimination of a VA reduces this vulnerability. Section V-F demonstrated the attractive cross domain properties of short lived certificates and PoVs. From this discussion, the conclusion of the analysis is that short lived certificates is the optimal choice for a multi-tiered PKI for the the following reasons: • • • • • •
Scalability (immune to growth of certificate population) Low traffic rates, second lowest of the analyzed alternatives Even traffic rates with no predictable peaks. Low dependency on connectivity (possibly through prefetching of CA PoVs Reduced number of trust anchors (eliminates the VA) Improved facilities for cross domain operation
On the basis of this conclusion, a proposed architecture for a multi-tiered PKI is shown in Figure 4. The content of the figure will now be explained. The arrows labeled (1) indicates the certificate structure, the arrow labeled (2) indicates how the subordinate CA issues EE certificates with the delegated authority given by the superior CA and represented by its CA certificate. The arrow labeled (3) indicates how the CAs issues proof of validity (PoV) to a Certificate Store (CS), which in turn will hand out these data objects to relying parties upon request. The CS also keeps a store of CA certificates (long lived) for retrieval operation from relying parties.
The arrow labeled (4) shows the signed message from the signer to the relying party. The signature structure must include the sender’s short-lived certificate, but must not include any CA certificates or PoVs, since they are retrieved by the relying party from the CS on demand. The arrow labeled (5) represents the retrieval operations for certificates and PoVs from the relying parties. CA certificates are fetched by each relying party at most once during their lifetime, which can be several years. PoVs are fetched once during the revocation latency interval (e.g. 4 hours) from every active client. Certificates and PoVs are cached for subsequent requests during their remaining lifetimes. The numbers of CAs are modest and expected to be less than 10 in even large enterprises. All validation operations will need to access the certificates and PoVs for a few of them, making a caching arrangement very effective with a high hit rate. Each relying party will at most fetch PoV for each CA once every revocation latency period (4 hours in our examples) and their certificates once every few years. The number of retrieval operations to the CS from a high number of relying parties can still be substantial, but since the number of data objects are low they lend themselves well to a distributed caching arrangement, which is indicated in Figure 4. A CS service which does not sign PoVs itself (like a VA would do) is easy to replicate. A potential reduction of CS invocations could be obtained if a CA issued one single PoV in common for all its subordinate CAs, so they would not need to be retrieved independently by relying parties. Please observe that the arrangement in Figure 4 does not exclude traditional PKI configuration based on e.g. revocation lists. A CA can issue long lived EE certificates which are used in communication with relying parties who validate the certificates based on revocation lists. This property facilitates a single PKI used for strategic communication, where the use of COTS software prevails, as well as for tactical communication, where efficient protocol operations are essential. VII. S UMMARY
AND
C ONCLUSION
The proposed architecture for an optimized PKI is based on well known principles from distributed systems research, on modern graph and networking theory and on experiences with current large scale PKI systems. The presented proposal relieves a PKI from maintaining and distributing revocation lists, which leaves us with a simpler system with smaller bandwidth and connectivity requirements and which is better prepared for cross domain operations. The distribution of revocation lists are replaced with short lived certificates which are issued every few hours but distributed only to its owner, not to everyone else. The dissemination of the certificates to relying parties happens through inclusion in the signature structure. On the client
side, the distribution of EE certificates consumes 2 kilobytes over the revocation latency period (e.g. 4 hours). In a multi-tiered PKI structure, the certificates of intermediate CAs should not be short-lived, but have lifetimes in the magnitude of years. A separate data objects called “Proof of Validity” (PoV) is issued by the parent CA with a validity of a few hours and sent to a Certificate Store (CS) and disseminated to relying parties through a distribution network. The size of a PoV may be as small as 1 kilobyte and the CAs are few (10 is sufficient for even large organizations). This arrangement is not compatible with the COTS software products which have been evaluated (Thunderbird, Firefox, Adobe Acrobat, MS Word etc.), so custom programmed clients are needed. Parts of the findings in this paper is based on a comprehensive study of PKI systems which is published in separate technical reports [8] and [9]. The reports describe the analysis and the laboratory observations to greater level of detail. R EFERENCES [1] R. L. Rivest, “Can we eliminate certificate revocations lists?” in Financial Cryptography, 1998, pp. 178–183. [Online]. Available: citeseer.ist.psu.edu/rivest98can.html [2] A. S. Tanenbaum, Computer Networks.
Prentice-Hall, 1981.
[3] D. A. Cooper, “A model of certificate revocation,” in Proceedings of the 15th Annual Computer Security Conference, December 1999. [4] A. Aarnes, M. Just, S. J. Knapskog, S. Lloyd, and H. Meijer, “Selecting revocation solutions for PKI,” in Proceedings of NORDSEC 2000 Fifth Nordic Workshop on Secure IT Systems, Reykjavik, Iceland, 2000. [5] A.-L. Barabasi, Linked: How Everything Is Connected to Everything Else and What It Means for Business, Science, and Everyday Life. Plume Books, April 2003. [6] A. Fongen, “Scalability analysis of selected certificate validation scenarios,” in IEEE MILCOM, San Diego, CA, USA, Nov. 2010, pp. 1–7. [7] S. Berkovits, S. Chokhani, J. Furlong, J. Geiter, and J. Guild, “Public key infrastructure study: Final report,” Produced by MITRE Corporation for NIST, April 1995. [8] A. Fongen, “Optimization of protocol operations in a public key infrastructure,” Norwegian Defence Research Establishment, Tech. Rep. 2010/02499, 2010. [Online]. Available: http://rapporter.ffi.no/rapporter/2010/02499.pdf [9] E. Winjum and A. Fongen, “Model and specification for analyzing the scalability of a public key infrastructure,” Norwegian Defence Research Establishment, Tech. Rep. 2009/01546, 2009. [Online]. Available: http://rapporter.ffi.no/rapporter/2009/01546.pdf
