A comparison between traditional public key infrastructures and identity-based cryptography

Abstract
With the recent acceleration in research into identity-based public key cryptography (ID-PKC), we consider this to be an opportune moment to compare and contrast ID-PKC with more traditional public key infrastructures (PKI). Because of the similarity in the nature of both approaches, we aim to identify the distinguishing features of each approach. In doing so, we highlight the important questions to be asked when weighing up the benefits and drawbacks of the two technologies. Keywords: public key infrastructure; identity-based cryptography; asymmetric cryptography; digital signatures; certificates; non-repudiation security practitioner’s armoury. However, we wish to tackle the notion that is prevalent in many existing discussions about the extent to which ID-PKC avoids trust problems encountered in certificatebased PKIs. While ID-PKC certainly does provide a new technological means of managing trust, it does not avoid the problems that are inherent in this difficult task. The remainder of this paper is organised as follows. In Section 2 we provide an overview of the two technologies. In Section 3 we discuss some of the issues that are relevant to the design of a security architecture using either mechanism. The main focus of this paper is on how the keys and the associated rights are managed under these mechanisms; these are covered in Sections 4 and 5, respectively. In Section 6 we discuss emergent hybrid mechanisms that have the potential to overcome some of the drawbacks of ID-PKC in certain scenarios. We conclude in Section 7 with a discussion of the main issues raised throughout the paper. Kenneth G. Paterson1 Geraint Price Information Security Group, Mathematics Department, Royal Holloway, University of London, Egham, Surrey, TW20 0EX. kenny.paterson@rhul.ac.uk geraint.price@rhul.ac.uk

1 Introduction
With the recent increase in research focused on identity-based (or identifierbased) public key cryptography (ID-PKC), we set out to compare these systems to more traditional public key infrastructure (PKI) systems using certificates. Our work is focused on architectural, key management and associated issues; we do not consider implementation details in any great depth. The main goal of this article is to ask the question ‘What are the differences between these systems from a practical viewpoint?’. The main technical difference between the two systems is in the binding between the public and private keys and the means of verifying those keys. In a traditional PKI, this is achieved through the use of a certificate. In an ID-PKC system, the binding between the private key and the authenticity data is managed by a trusted authority (TA) at the point of request, while the binding between the public key and that data can be done by anyone at any point. We identify the technology behind ID-PKC as being a useful addition to the

2 Technological overview
In this section we provide a brief technical overview of traditional PKIs and ID-PKC. Both technologies are variants of asymmetric cryptography, a concept introduced by Diffie and Hellman [1] in the mid-1970s. Until their groundbreaking paper, all cryptosystems had relied on symmetric cryptography, where both communicating parties shared a copy of the same key. In the model of [1], a related pair of keys is generated. The user retains one half of the key for private use, while allowing the other half to be made public. The private key can then be used to either decrypt a document that has been encrypted under the corresponding public

1 Supported by the Nuffield
Foundation NUF-NAL02.

1363-4127/03/© 2003, Elsevier Ltd

57

Because of the inherent public nature of the encryption or verification keys. there is a requirement for a certificate to bind the public key to its particular use. Public key infrastructures Public key infrastructures (PKIs) are currently the primary means of deploying asymmetric cryptography. such as RSA [2]. Software: For the certificates to be of use. responsible for ensuring that the correct key is bound to the certificate. The choice of mechanism will largely be dictated by the security policy of the system. 8. the core components of a PKI are: Certificate authority (CA): The CA is the entity that generates the certificates. We expand our review of PKI and IDPKC in Subsections 2. The certificate policy (CP) and certification practice statements (CPS) define the how the certificates are generated and managed. then it is better that the key is generated by the client. The PKI is the infrastructure that supports the management of keys and certificates. Vol. which underpin most PKI products on the market today. The functionality of the CA and RA is sometimes carried out by a single entity. If a signature key is likely to be used to support nonrepudiation. when discussing PKIs we are referring to infrastructures that support the deployment of traditional asymmetric cryptographic algorithms. a strong requirement for ensuring that the mechanisms are used correctly. 3 . For example.1. In the case of a decryption key that is used to keep company information confidential. the software that is going to use the certificates needs to be aware of what the certificate content represents within the scope of the system security policy.1 and 2. In contrast. We conclude our technological overview in Subsection 2.3 with a discussion of how the security policies that make use of these keys can reflect the underlying technology. Policies and procedures: Although the core of a PKI is mainly technical.PKI re-visited – current issues and future trends key or to sign a message which can then be verified with the public key. As well as the keys and certificates. Certificate storage: In most systems. there is. No. as well as ensuring the certificate content. The keys can either be generated by the CA for the client or the client can generate the keys for itself and provide a copy of the public key to the CA to certify. In a traditional PKI. The main difference between the two variants of asymmetric cryptography that we focus on here is in the generation of the keys. the key pair in an ID-PKC environment is generated explicitly from data that is of relevance to the usage of the key.2. by necessity. it might be prudent to have the CA generate (or have access to) the key so that there is always a means of recovering encrypted information. As such. the integrity of the public keys is usually protected with a certificate. a user’s encryption and decryption keys may be derived from their identity within the system in which they are to be used. It is 58 Information Security Technical Report. 2. Registration authority (RA): The RA is responsible for ensuring that the user who receives the certificate is a legitimate user within the system. In this paper. the key pair is generated from random information that is unrelated to the method identifying that key pair within the system. one can choose where the key pair is generated. They also define the role of the certificates within the broader security architecture. respectively. It will also be influenced by the key usage. certificates (as well as update information such as certificate revocation lists) are stored in a CA-managed database. In traditional asymmetric mechanisms.

whereas in an ID-PKC the TA is directly responsible for generating and distributing all keying material within the system. • Because of the mathematics that underpin the algorithms. Shamir [3] was the first to propose such a scheme in which the key itself is generated from some publicly identifiable information. In a PKI. it does not come without consequences. This forces a change in the role of the trusted third party within the system. The core difference between an ID-PKC and a traditional asymmetric algorithm is the means of generating the keys. the CA is concerned with validating the authenticity of the information that is present in the certificate. the TA may not have validated the authenticity of the information relating to Information Security Technical Report. Identity/identifier-based public key cryptography One of the difficulties inherent in running a PKI is in the management of the certificate and associated key. the creation of the private key requires the knowledge of a master secret that is held by the trusted authority (TA). information such as the client’s position within an organisation and the validity period for the keys etc can be included in the data that is used to derive the key pair. It is only recently that an efficient identity-based encryption system was proposed by Boneh and Franklin [4]. For example. because a private key may be generated after the public key. We will return to revocation issues in Subsection 4. There is also the requirement that the TA and client are able to set up an independent secure channel for the distribution of private key material. in both the signature and encryption variants. Recently.2. cryptography was created as a means to overcome this problem.3. This channel needs to protect both the authenticity and confidentiality of the private key. This results in the broader concept of identifier-based public key cryptography. If we take revocation as an example. If we include validity dates. In a PKI. then a push toward broader use of identifying information leads naturally to identifier-based cryptography. there is an inherent escrow facility in the system. Because the TA is directly responsible for the generation of the private key in an IDPKC mechanism. No. The two main issues that will influence the discussion in the remainder of this paper are as follows: • Coping with the practicalities of implementation are not insignificant. it has been recognised that an identity does not need to be the only determinant of a client’s public key. His original scheme provided a signature algorithm. This may or may not be desirable. Vol. and subsequently identifier–based. 3 59 . This allows a client A to generate the public key of another client B without having to do a search in a directory or ask B for a copy of their key. In ID-PKC. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography 2. • The authenticity of the information that is used as the identity or identifier is now crucial to the security of the system. 8. the public keys are generated from publicly identifiable information. The difference is manifested in two ways: • As mentioned above. because we cannot revoke a person’s identity there is a requirement for additional input to the key generation process. which is the analogue of the CA in a PKI. the certificate is supposed to demonstrate the authenticity of identifying information. but could not be used for encryption.Kenneth G. Although the idea of using a client’s identity as the base for their key pair is very appealing. key usage etc. such as a person’s e-mail address. Identity.

In this section we briefly look at the way in which this might affect the choices that are made when deciding between the two as a security architecture. This has led to a difference in the way the two proposed mechanisms are architected. there appears to be a potential for ID-PKC to develop more lightweight implementations at the client end. identification and keying information. where knowing the identity of the other contact point in an interaction could be enough to generate keying information on the fly. it would seem sensible to use a PKI either in a widely distributed environment or in an environment where the individual policy of each client plays a significant role in the policy of the system as a whole. The ability of clients to generate their own key pairs to be certified by a CA that need not be directly in their security domains could provide benefits in some scenarios. • It would appear that a PKI would be the implementation of choice in a widely distributed system. 60 Information Security Technical Report. While neither of these design principles is strict — we could. it would seem more natural to implement an ID-PKC for short-term keys where the policy at the TA might change regularly. Expanding on the example given above. there doesn’t seem to be a great deal of difference between PKI and ID-PKC. 3 Architectural issues ID-PKC was introduced as a means of circumventing the difficulties associated with certificate management within PKIs. Vol. • Within systems where the security is heavily centralised (i. the use of third-party CAs to certify SSL server keys would be difficult to replace using ID-PKC. but it is generally left up to the client encrypting the information to verify the certificate content in the light of its own security policy. In the case of the CA in a PKI. The choice of which mechanism to implement is likely to 2. 3 . 8. For example. A might use information it thinks is valid to generate a public key for B.PKI re-visited – current issues and future trends the key pair prior to the public key’s use. Conversely. This is due to the lack of a requirement for storing separate certification.3.e. This is: how do the security policies of the communicating parties interact with those of either the CA or the TA? As mentioned previously. we outline the architectural issues as we see them: • On first inspection. Policy interaction In closing the discussion in this section we will outline what we see as one of the main questions to be answered when deciding whether a system should use PKI or ID-PKC as its cryptographic mechanism. it can verify its security policy each time it hands out a new private key to a client. where all users must trust the CA/TA explicitly anyway). The key escrow facility inherent in ID-PKC would probably not sit well with a corporation that wishes to secure its Internet gateway using an SSL-enabled server. but the information A uses could either relate to the wrong B or be completely invalid in the eyes of the TA. For example. Provided that the authenticity of such information could be verified. mimic the requirement to always fetch a new key from a TA within a PKI — the way in which the information flows through the system is an important consideration when deciding which mechanism to use. In the following list. No. because the TA is explicitly in charge of the generation of the private keys in an ID-PKC system. for example. this could be useful for scenarios such as mobile systems. the policy is verified at the time of certification.

any signature on a document that had not been independently time-stamped could be called into question. the public key can be chosen by any client in the system.Kenneth G. In terms of the questions that we ask with regard to key generation. and revocation of keys. It is then incumbent on the other party to obtain the matching private key from the TA. This is similar to the situation where there is often little to choose between a symmetric and an asymmetric system in applications where non-repudiation is not a concern. and hence also at a different time to the validation of the issuance of the private key. a public key can be generated at a different time to the private key. way in which they manage keys. • An area where PKI seems to have a distinct advantage over ID-PKC is in the consequences of the compromise of the CA/TA. • One of the proposed benefits of PKIs is that they can be organised into hierarchies that reflect the internal structure of a large organisation or group of organisations. No. the attacker can now decrypt all previously encrypted information. In an IDPKC. the public key is generated at the same time as the private key. As a result. the public key is either generated at the CA or by a process which the client deems to be trustworthy. the public key is generated at the site 4 Key management In this section. • In distributed systems where it is difficult to manage a revocation mechanism (e. The validity of the binding between the public and private keys should be checked by the CA before issuing the certificate. This limits the creation of the public key to either the CA or the client. as the system would only require partial synchrony for the sender to generate a currently valid key for the recipient.1. We separate our discussion into three topics: generation of public keys. Within an ID-PKC. mobile systems). recent work by Gentry and Silverberg [5] develops mechanisms for implementing similar hierarchies in an IDPKC context. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography come down to how the protocols that use those mechanisms fit in the wider architecture of the system. by the very fact that the attacker now knows the secret from which all keys are derived. here are the differences between public key generation in the two schemes: • Within a PKI. Within an ID-PKC. because of the separation between generation of private and public keys. we analyse the differences between PKI and ID-PKC by examining the Information Security Technical Report. While the compromise of a CA is disastrous to the future secure running of the system. When discussing the generation of keys we concentrate on the following four questions: Who generates the keys? When are the keys generated? Where are the keys generated? and How are the keys generated? 4.g. one way in which PKIs aim to deal with the problem is to use short-lived certificates. the keys are generated prior to the issuance of a certificate. this is the essence of identifier-based PKC. 3 61 . This might be addressed more efficiently using ID-PKC. 8. Generation of public keys In this section we look at the generation of the public halves of the key pairs and how that might affect the design of a security service built on top of them. the public key can be generated by any client within the system. Moreover. generation of private keys. The same would be true of signature keys. if the system has been designed carefully then all past encrypted traffic is still secure. If the TA within an ID-PKC system is compromised and the master secret revealed. • Within a PKI. Vol. While this might seem to provide an advantage for PKIs. • Within a PKI.

Generation of private keys In this section we analyse how the way in which private keys are generated in each approach can potentially affect their usage. but is a drawback in an 62 Information Security Technical Report. with ID-PKC.PKI re-visited – current issues and future trends of the client that wishes to use the public key. 4.2. This enforcement of the private key generation by the TA within ID-PKC raises concerns of escrow and/or privacy surrounding the management of private keys. The client that wishes to decrypt the message must then demonstrate compliance with the policy to the TA before it is issued with the corresponding private key. the verification key is generated from the signer’s identity. Signature verification For ID-PKC. the client that generates the ciphertext can generate the encryption key without having to know the identity of the client that will decrypt the message. Within a signature scheme. and the certificate that contains the verification key often accompanies the signature. Because a PKI allows the signer to attach a certificate to the signature. the verification key is created at the same time as the signing key. the main difference between the two approaches is that. However. This has the potential benefit of allowing the policy compliance to be encoded directly into the encryption key. No. in order to decrypt the message in advance. For PKI. This can be carried out either by the signer. in a PKI there is a choice of having the private key generated by the CA or the client. We now examine how these differences manifest themselves in terms of keys for encryption and signature verification. their proposal allows the client to encode a policy that specifies conditions under which decryption can take place. which implicitly requires the prior generation of a private key. we can mimic this ID-PKC functionality in a PKI by encrypting the message directly for the CA and attaching the decryption policy to the ciphertext. 8. In an ID-PKC. On the other hand. the key must be generated by the TA. we combine some of the issues raised here with the discussion at the end of Subsection 4. In terms of the generation of the private key. This might be of benefit to an encryption scheme in a business environment where the company owns the data. or by the verifier. a public key is only of any use when verifying a signature. the public key usually results from a process that makes use of a random secret input to generate both public and private keys. who calculates it at the time of verification. • Within a PKI. Encryption For ID-PKC. Chen et al [6] use this feature of ID-PKC to enable the control of work-flow within a system. Vol. the public key is generated from public information. the client would need to know the public key that was related to the private key to be used — usually the decryption key bound to the recipient’s identity. who then attaches the verification key to the signed message.2. The ability within an ID-PKC to generate a public key from public information at a time that is different from the generation of the private key provides us with perhaps the biggest difference between ID-PKC and PKI. it seems that ID-PKC’s advantage of being able to generate keys independently holds little advantage in this scenario. In brief. This would seem to make it less flexible than ID-PKC. In a PKI. 3 . Because of the close relationship between the generation of both public keys and private keys.

In IDPKC. For PKI. and either revoked or removed at the end of its natural life-cycle. The two users will now share the same public/private key pair. We now analyse the differences in private key generation for ID-PKC and PKI. A proposed benefit of ID-PKC over PKI — the separation between the public and private key generation — does not immediately appear to be of use here. perhaps with a legitimate reason (e. 8.1. Before entering further into the discussion of the relative merits between PKI and ID-PKC in this area. 3 63 . another client could request a key with the same ID. If a long-term key is used. but there is a difference. At first glance it would appear that a similar problem was inherent in PKI. because of the inherent link between Information Security Technical Report. At some point in the future. Otherwise. A key could be generated. the key is generated by either the CA or the client. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography implementation for digital signatures that might want to offer non-repudiation. there is potential for the following scenario to arise. This ability to choose who generates the private key offers PKI an advantage in terms of flexibility over ID-PKC. although a short-term key could also be used.g. it is also becoming an important issue for those running signature applications. as we discussed in Subsection 4. in that the same ID could be certified. The EU Directive on Electronic Signatures [7] states that a key that is used as an Advanced Electronic Signature should be under the sole control of the individual named in the qualified certificate. Collusion between independent TAs would then be required for a copy of the private key to be generated. in an ID-PKC implementation. Encryption For ID-PKC. While the notion of who generates and controls the key is of interest to those in the academic community. the private key is generated by the TA and given to the client. used. the TA needs to retain a database of every ID to which a key has been issued under the current system parameters. Vol. the users share a common name). the private key needs to be provided to the decrypting party by the TA. the inherent key escrow in ID-PKC makes it a less attractive choice. Boneh and Franklin [4] have proposed a means of circumventing the escrow problem by using multiple TAs and threshold cryptography. there seems to be little difference between the two schemes. Signature For ID-PKC. For PKI. as in the work of Chen et al [6]. we note that our discussion in Section 6 outlines recent research that could potentially be used to overcome the drawbacks of private key generation in ID-PKC schemes. We now discuss some of the issues raised when analysing the differences between the management of keys in ID-PKC and PKI: • It would appear that. The main difference comes to light when we consider the creation of session-oriented private keys whose release is managed by the TA.Kenneth G. We do this by separately considering encryption and signatures. Whether this key will be fresh for this particular session/message depends on whether the client generating the ciphertext used a long-term or a short-term public key. the public encryption key that is used is usually the client’s long-term key bound to their certificate. This is a policy decision that is influenced by the system security policy in conjunction with the policy of the client carrying out the encryption. No. Because signature schemes should normally uniquely identify the creator of the signature.

say. Such intervention may not be convenient if. the issue of how to manage the identity/identifier relevant to a particular public key has so far received very little attention. in ID-PKC. No. The more worried one is about duplication within the system. This suggests that less predictable identifiers would need to be employed. In a PKI implementation. 3 . the private key generation is done in a hardware security module. will provide the input to the 64 Information Security Technical Report. Revocation Revocation is one of the main difficulties faced by implementers of PKIs. they could choose an identity for which the TA will not release the corresponding private key. we note that removing the certificate from the system does not solve all the problems that are of relevance to certificate management. Whether this is considered a benefit or a drawback can only be resolved when it is considered in the light of a particular application. position in the organisation etc. Because of the strong link between keys and identities in ID-PKC. Here are the three main issues that we see for revocation in ID-PKC: • As mentioned in the previous section. we end up with a similar set of standards problems that are faced by the implementors of PKIs. In this section we will argue that revocation could potentially become as great a concern for ID-PKC as it currently is for PKI. Where does this leave us? The client must now contend with two issues when generating another client’s public key. Thus. even if the identities are the same. This problem is analogous to the problem of certificate management in a PKI.PKI re-visited – current issues and future trends ID and public key. Vol. In a PKI the separation is clear. • A related issue is raised if we consider the standard ID-PKC solution to the above problem. in actual implementations. the more the content of the identity starts to mirror the content of the certificate in a PKI. or result in the need for manual intervention and override. as part of the identity. it is likely that more complex identifiers. keeping track of identities that have been issued within the system is a potential problem for key management.3. • There is a potential safety issue when considering the generation of public keys in an ID-PKC scheme. additional detail such as date of birth. built on top of a client’s identity. but leads to identifiers that are difficult to predict. This is to include. the public keys and the identity are inexorably linked. such that the TA will give the corresponding private key to the correct recipient? By going down this path. For example. While IDPKC does not have a certificate per se. 8. revoking a public key requires the revocation of the associated identifier. How does a client know what each field in an identifier is meant to represent? There must be agreement between communicating parties and the TA. the keys will actually be the same. This means that the keys will almost certainly be different. Because it is the client that chooses the identity to be used to generate the public key. But these are precisely the identifiers that are easily predicted by the entity that is attempting to independently generate a valid key for an intended recipient. • Both previous points are specific problems that are encountered when we realise that. the keys are generated separately and usually using some client-controlled randomness. 4. the inclusion of issue numbers in identifiers is conceptually simple. This problem is acute if the identifier is one that could be inconvenient to change (such as an e-mail address). This could leave the intended recipient unable to read vital information. What is the correct form in which the identity should be created? What is the content of each field type. So.

to highlight the fact that rights represent any extension of the services that encryption and signature algorithms provide. can A sign orders up to a value of $10 000’. there is a potential drawback in terms of recertification. requires the reliable and timely distribution of confidential information. if a finer degree of control is needed). Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography key generation function. We split our discussion into two parts: one concerning rights implemented using signatures. This is related to the issue about form and content of identifiers that was noted in Subsection 4. For example. Applying this same level of security daily in an ID-PKC could make the process inherently difficult to manage. key generation and certification procedures should be among the most heavily guarded.12MAR2003’ could A provide the input for the key generation function). We separate our discussion here into the issues surrounding the generation and verification of these rights. being a purchase manager. This mechanism raises a few problems. This is not necessarily true: a CRL can be distributed by a server that is not the root CA. The term rights in this discussion encompasses anything that the possession of a key and/or related certificate/identifier allows the client to do. This means that there is likely to be a higher degree of complexity in the part of the system that manages those identifiers than might appear at first sight. No. The argument provided is that the re-issuance of keys on a per time basis obviates the need for a revocation mechanism. the string ‘ lice. At a recent PKI workshop. • When considering the issue of revocation. using the methods discussed here. then it forces the TA to be on-line for a greater proportion of the time and may significantly increase the TA workload.Kenneth G. Rights generation In this subsection we introduce the basic means by which rights are represented in each approach and how these representations are generated. • Because of the inherent binding between identifier and key in ID-PKC. we saw a demonstration for a product that separated the storage of private key and certificate. the Information Security Technical Report. This allowed the organisation to change the certificate content through re-certification without needing to go through the more expensive procedure of issuing the clients with a new private key. To put it more succinctly. The ability to remove the need for an on-line server is one of the benefits of using asymmetric cryptography in the first place. If we force all legitimate users to request fresh keys every day (or even every hour.g.2. Another problem with Boneh and Franklin’s model of revocation is that it requires an independent secure channel between the channel and the TA for the transportation of the fresh keying material. Boneh and Franklin [4] proposed merging the date with the client’s identity to provide the identifier for the key (e. It could be argued that having an OCSP or CRL server in a PKI has the same drawback. revocation in a PKI requires reliable and timely distribution of authenticated information. we use the term in as neutral a form as possible. 3 65 . 8. In a traditional PKI. As such. An exact replica would be impossible to achieve in an ID-PKC system. while the certificate was stored on the hard drive. a right could be ‘The right to view confidential report X’ or ‘ . The private key was stored on a smart-card.1. Revocation in an ID-PKC. 5 Rights management In this section we analyse the differences in the manner in which rights are handled in PKIs and ID-PKC systems. the registration. 5. Vol.

the right to sign is either implicit in the verifier knowing who the signing party is. Alice might want to see Bob’s credentials as a line-manager before passing on an encrypted version of the payroll file. Alice may know Bob personally and thus be willing to use the encryption key in Bob’s certificate — this may be the case when using e-mail security software. The authorisation mechanism could be a more traditional access control list. in advance of the decryption. subsequent verification of that right does not happen until the TA generates the corresponding private key. the right to decrypt is effectively generated when the client that is encrypting the message generates the public key But the . similar to those discussed above for PKIs. Alternatively. Depending on the system policy. Again. or contained in the client’s identity certificate.2. the right to sign will be assessed at the time of the signature key’s creation or when the identity is bound to the associated authentication mechanism. The right to sign is likely to be either implicitly recognised between signer and verifier or more explicitly contained in an additional mechanism. 3 . Signature PKI In PKI. To achieve this. In most commercial PKI systems. 8. 5. Vol. or it is explicit through a binding to an authorisation mechanism. One of the proposed benefits of using ID-PKC is that the public encryption key can be generated by the party that is encrypting the data in advance of the corresponding private key having been generated. The popular choice for a signature creation key is likely to be some variant of the signing party’s identity.PKI re-visited – current issues and future trends other concerning rights implemented using encryption. a separate privilege management infrastructure (PMI). it would appear that the same principles apply. Our goal in this section is to understand how the means by which these rights are verified affects the design of the system. the right to decrypt can be either implicit or explicit. ID-PKC As with PKIs. The right to sign for a particular purpose is assessed either by the CA when generating the identity certificate or by the authority in charge of the separate authorisation infrastructure. In both cases. For example. we keep our discussion at a generic level and develop our argument by the analysis of the following three factors for signatures and encryption: Who: Who is capable of carrying out the verification? When: When is the verification carried out in relation to the right generation? Where: Is there a physical or logical relationship between generation and 66 Information Security Technical Report. the right to decrypt is generated when the identity certificate or authorisation token is generated. the right to decrypt can be generated at the same time as the private key. As in the above discussion on signatures. which may happen at some point in the future. the signing key is usually bound to an identity. No. ID-PKC In an ID-based scheme. Encryption PKI Traditionally. PKIs have primarily been associated with authentication rather than authorisation (SPKI [8] being the notable exception). Rights verification We now turn our attention to how the verification of rights might take place. If used in this manner. the identity certificate is used to authenticate the client to a separate authorisation infrastructure.

Where: Because of the nature of a traditional public key and its associated certificate. then it is likely to be the client encrypting the data. Information Security Technical Report. The verification of the right to sign will happen when the signature is checked by the relying party. anyone who can use the public key associated with the signature key can verify the signature. If the PKI is set up with an encryption key in the certificate. If the signature is created on a document that may need to be verified multiple times by multiple parties. the signing party’s right to sign may be brought into question in the future. When: The verification occurs when the client verifying the signature carries out the signature validation. Encryption Again.Kenneth G. or explicit. anyone with access to the public key corresponding to the private key can verify the signature. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography verification that might affect the security policy? We note that. ID-PKC Who: In a similar manner to PKI. No. there is the potential for the signature to be verified somewhere that is logically and physically remote from the signing party. Signature We separate the analysis of PKI and IDPKC systems. then determining the true order of events could be difficult. Vol. in the sense that A knows B. then this is a benefit. we analyse potential PKI and IDPKC systems separately. This does not necessarily mean that they will be able to accurately verify the associated rights that may be bound to the public key through a certificate. If a signature on a particular document was generated at roughly the same time that a revocation was issued. on the other hand. then the relying party needs to be able to process the associated authorisation structure. then it is the security policy of the relying party that governs the right. then it is likely to be the policy monitor for the authorisation mechanism. 8. PKI Who: In the case of signature verification. This is considered to be one of the great strengths of public key cryptography. An example where this might present a problem would be a signature system that provided non-repudiation. through some other mechanism. As mentioned previously. This flexibility in separation is potentially both a benefit and a drawback. This will depend on the security policy of the system and the parties involved. When: The timing of the verification is likely to be similar to a PKI. 3 67 . If. If the right is explicit. PKI Who: Who verifies the right to decrypt will depend on how the system is built. we describe the most logical means of implementing the rights verification functions. the verification could be conducted at a logically or physically remote site to the signature. One of the influencing factors would be whether the verification of the right to sign was implicit. then there is an argument for re-validating the right to sign as close as possible to the time at which the signature is created. this could potentially be far removed from the time that the signature was created. If the PKI is only used as an authentication front-end to a separate authorisation mechanism. this does not necessarily imply that they can accurately verify the right associated with that signature. in an attempt to keep our analysis as broad as possible. In terms of time. Where: Once again. If the right is implicit.

the act of rights verification can be bound closely (both in terms of time and space) to point at which the verification is carried out. Where: As in the case of the PKI. then it is likely to be the client encrypting the message. if required. 8. in a PKI system. If the key is chosen by the sending client. It is this verification of the right to carry out a task that poses one of the problems in implementing a PKI. encrypt a document to a colleague). If the key is a sender-chosen key generated specifically for that encryption. Vol. Gutmann [9] recommends a similar binding when implementing a PKI. then the right should be checked as the data is being released to the recipient. rather than when encryption takes place. then the right to decrypt is verified at the point of encryption. When: If the client encrypting the message uses a long-term key. No. • There is a relationship between the management of rights and the revocation issues as discussed in subsection 4. These two points highlight the fact that both PKI and ID-PKC systems ultimately work in a similar manner. it would appear that such strong binding between verification and CA/TA. This results in a mechanism that is very similar to one that proponents of ID-PKC claim to be a benefit of their approach. When you use a right (e. It would appear that ID-PKC lends itself naturally to 68 Information Security Technical Report. The right might then be generated on-the-fly as part of the rights verification process. An example of such a system might be an encrypted file store on a server. then this would happen at the TA. At first glance. ID-PKC Who: In a similar manner to PKI. if the encrypting party carries out the verification. We now discusses some of the main issues raised by our analysis in this and the previous sections. then this happens in a place that is potentially logically remote from the recipient. If there is a monitor controlling access to the data. is only generated and assessed immediately prior to decryption. In the case of an access monitor. then right is likely to be verified when the encrypted message is being generated. If the encryption key is generated from the user’s long-term secret key. • There are scenarios where the right to decrypt. This is carried out through the use of clientchosen short-term keys with the recipient having to retrieve the associated private keys from the TA. then the location is likely to be carefully chosen to be within the same logical or physical security domain as the recipient. While discussing the future of PKI. to verify a signature.PKI re-visited – current issues and future trends When: If the verification is carried out by the client encrypting the message. 3 . then the rights verification should happen at the point at which the TA hands out the decryption key to the recipient. can be carried out more cleanly in an ID-PKC implementation. A client wishing to access the encrypted material asks a monitor for read rights.g. With ID-PKC. If the client is allowed to control the generation of the public key according to their security policy — as proposed by Chen et al [6] — then the verification of the right to decrypt is carried out by the TA that generates the private key for the recipient. who does the verification will depend on how the system is implemented. this could potentially be anywhere. Where: If the right is being checked — implicitly or explicitly — by the encrypting party. then you need to know at that point whether the right has been revoked or not.3. This might happen at a time that could realistically be far ahead of when the recipient decrypts the message. who is a trusted server within the security domain. There is a danger here that the original right may have expired or have been revoked in the meantime.

and a component which is time-dependent and issued to B on a regular basis by a CA. A makes use of both public components. Matching the two private key components are two public key components.1. Certificate-based encryption In [10]. A granularity of one hour per time period is suggested in [10]. the second private component acts as an implicit certificate for relying parties: one that a relying party can be assured is only available to B provided that B’s certification has been issued for the current time period by the CA. together with the current time value and the assumed value of A’s public key.) However. The first of these matches B’s own private component and is assumed to be readily available to any entity A that wishes to encrypt a message to B. Vol. This approach can significantly simplify revocation in PKIs: notice that there is no need for A to make any status checks on B’s public key before encrypting a message for B. an implicit certificate is needed by B in order to decrypt — for this reason.11].Kenneth G. perhaps certificate-based decryption would be a better name for the CBE concept. the ability for any client to verify the content of a certificate means that policies set by the CA can potentially be independently assessed by the client in relation to client-oriented policy. Thus. No. rather A needs to be in possession of what it assumes is a copy of B’s public key and an authentic version of the CA’s public parameters. It can even be argued that CBE loses the one key feature enjoyed by a traditional PKI: that the certificates issued by the CA allow the CA to distribute trust in an almost off-line manner (the CA 6. The security of CBE depends critically on the CA binding the correct public key into B’s implicit certificate in each time period. 8. encrypted by A if B is in possession of both private components. Nor are any certificates actually needed by A. an entity B’s private key consists of two components: a component which that entity chooses for itself and keeps private. In encrypting a message to B. Because of the structure of the CBE scheme. (Rather. In Gentry’s model. this substantially adds to the computation and communication that takes place at the CA for a PKI with even a small user base. Thus (quite naturally) the initial registration of users and their public keys must take place over an authentic channel and be boot-strapped from some other basis for trust between B and the CA. The second public component can be computed by A using only some public parameters of the scheme’s CA. Gentry introduced the concept of certificate-based encryption (CBE). The basic CBE approach can be regarded as effectively trading simplified revocation for an increased workload at the CA. 6 Beyond PKI and ID-PKC The focus of this paper has been to make a comparison between ID-PKC and PKI. the basic CBE approach of [10] does have a major drawback: the CA needs to issue new implicit certificates to every user in the scheme in every time period. Here we cast a look at some recent developments in research in the area of models for infrastructures supporting the use of public key cryptography [10. 3 69 . there are no CRLs and no requirement for OCSP. So. A is then assured that B can only decrypt messages Information Security Technical Report. with a view to simplifying revocation in traditional PKIs. In a PKI. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography situations where the TA should be given governance over policy decisions. This second component can be transmitted over a public channel from the CA to B.

In the first stage. In order to decrypt A’s message. it is rare that the public keys will depend on identities alone. then the CL-PKE scheme effectively becomes a CBE scheme. On the other hand. The key feature of their model is that it completely eliminates the need for certificates. The technical means by which it does so is actually rather closely related to that used in [10]: a user A’s private key is composed in two stages. an identitydependent partial private key is received over a confidential and authentic channel from a trusted authority (called a key generation centre. For example. Also. if the KGC has done its job properly. 3 . Instead. an entity A that wishes to rely on B’s public key is assured that. but where the full weight of PKI is untenable. 8. if one omits certain fields from the certificates in a CBE scheme. In the second stage. The schemes are no longer identity-based: they involve the use of B’s public key. but do not completely eliminate. However. this trust is produced in an implicit way. AlRiyami and Paterson [11] proposed another new model for supporting the use of public key cryptography. The specific instantiation of CBE given in [10] builds on ideas developed in Boneh and Franklin’s identity-based public key encryption scheme [4]. it is possible to convert a CL-PKC encryption (CL-PKE) scheme into a CBE scheme à la Gentry: if B’s identity in the CL-PKE scheme is extended to include a time period along with the public key. Differences do remain: in the strength and scope of the security models developed in [10] and [11]. Perhaps not surprisingly. hence the moniker certificateless public key cryptography (CL-PKC). A number of enhancements to the basic CBE approach are also presented in [10]. then only B. Thus CL-PKC supports the temporal re-ordering of public and private key generation in the same way that IDPKC does. The user also publishes a public key that matches the private key. which is no longer simply derived from B’s identity. No. 6.PKI re-visited – current issues and future trends needs only to be on-line to perform a revocation function). KGC). Vol. CL-PKC combines elements from IDPKC and traditional PKI. it might be well suited to a mobile e-commerce application where signatures are needed to ensure non-repudiation of payments. the user produces his private key by combining the partial private key with some secret known only to the user. as we have already discussed. B must then fetch the correct partial private key from the KGC. This would appear to make CL-PKC ideal for systems where escrow is unacceptable. the work that must be carried out by the CA. one obtains an encryption scheme that is functionally similar to a CL-PKE scheme. In fact. instead. when using ID-PKC in practice. who is in possession of the correct partial private key and user-generated secret. However. CL-PKC does not need certificates to generate trust in public keys.2. generate the signature etc. CL-PKC avoids the key escrow inherent in ID-PKC by having user-specific private information involved in the key generation process. These reduce. could perform the decryption. as well as in the technical details of the schemes’ realisations. Certificateless public key cryptography Independently of Gentry’s work. On the other hand. this public key does not need to be supported by a certificate. The details of Gentry’s specific CBE scheme are beyond the scope of this paper. CL-PKC allows A to use B’s public key but to choose an identifier for B. 70 Information Security Technical Report.

as presented in [10]. as is often true in security. the very nature of a certificate makes a PKI more useful in a situation where the policy should be controlled locally at the client using a certificate. 7. • The explicit dependence of the public key on the identity/identifier in ID-PKC could potentially become a hindrance in applications that might require flexibility in their certificate structure without having to go through the associated distribution of new keying material. 7. 7 Discussion and conclusions We draw this paper to a close with an overview and summary of what we consider are the key points that we have raised through our analysis. it would appear that ID-PKC could provide a more natural implementation in a situation where a centralised security policy should be checked regularly. then it could deliver the saving of not having to perform a certificate look-up. while CLPKC attempts to break free from the ‘mental straightjacket’ that is imposed by ID-PKC and PKI.2. it is worth re-iterating that CBE. Time will tell as to what extent these relatively new research ideas see further development and eventual deployment in applications. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography In closing this brief introduction to recent work. one of the ways in which revocation might be handled in ID-PKC would require the TA to be on-line potentially more often than a CA in a PKI. the verification of the rights used in the system can be more readily bound to the private key generation process at the TA. Conclusions Although research interest in ID-PKC is very strong at the moment. • With ID-PKC. As mentioned in our discussion on revocation (Subsection 4. but if the link over which the messages flow can easily become congested then the saving could be important. 8. • How the policies of the communicating parties interact is an important consideration when choosing whether to achieve security using a PKI or an ID-PKC system. • The liveness of the trusted authority (CA or TA) is a potential issue. it is a relatively new technology in comparison to PKI.1. If an ID-PKC implementation could guarantee that a client generating a public key generated it correctly.2). No. By contrast. Vol. we have sought to explore what Information Security Technical Report. However. • The message flow and interaction between clients can become an issue. is formulated within the confines of a PKI setting and is aimed at simplifying revocation. the differences in what can be achieved are not always restricted by the ‘how’ of the underlying mechanism. followed by some conclusions.3). a two-pass protocol is not much worse than a one-pass protocol.Kenneth G. As we mentioned in Subsection 5. 3 71 . In our article. where the encryption channel might be set up through knowledge of the recipient’s physical address. On the face of it. An example of this might be mobile networks. the following list represents a summary of what we consider to be the most salient points that we have raised in this paper: • The strong binding between an identity and a key in an ID-PKC could potentially provide a benefit in systems where there is a strong binding between the user and the identifier of the communication end-point.2. It is possible to emulate much of what ID-PKC has to offer within a PKI implementation by having the client that generates the encryption send an accompanying policy statement to a monitor (Subsection 5. Key points Although we have discussed various issues as they have arisen during each section.

Hierarchical IDbased cryptography. September 1999. A Shamir and L Adleman. the deciding factors when choosing between PKI and ID-PKC are likely to be environmental.int/eur-lex/pri/en/oj/dat/2000/l_013/ l_01320000119en00%120020. SpringerVerlag. IT-22(6):644-654. Springer-Verlag. 72 Information Security Technical Report.txt [9] P Gutmann. 2002. volume 2501 of LNCS. [6] L Chen. A method for obtaining digital signatures and public-key cryptosystems. K Harrison. 2001. [3] A Shamir. Identity-based encryption from the Weil pairing. New directions in cryptography. 21(2):120-126. Advances in Cryptology – EUROCRYPT 2003 (ed E Biham).eu. Springer-Verlag. Lecture Notes in Computer Science (to appear). InfraSec. Advances in Cryptology – ASIACRYPT 2002 (ed Y Zheng). Proceedings of Asiacrypt 2003. Our initial judgement. volume 2656 of LNCS. Identity-based cryptosystems and signature schemes. pages 260-275. is that there is very little to separate the two. Perhaps the important input when deciding whether to adopt PKI or ID-PKC is the different way in which the two technologies naturally generate and verify rights and keys. IETF RFC 2692: http://www. pages 47-53. admittedly made in the context of little or no commercial deployment of ID-PKC systems.org/rfc/rfc2692. February 1978.C. 2002. [5] C Gentry and A Silverberg. This influence of the constraints surrounding the implementations are likely to be greater. 2003. [4] D Boneh and M Franklin. 2003. (ed G I Davida. 3 . pages 272-293.ietf. Springer-Verlag. Advances in Cryptology – CRYPTO ’84. Y Frankel and O Rees). Springer-Verlag. Vol.PKI re-visited – current issues and future trends separates ID-PKC from PKI. [2] R L Rivest. SPKI requirements. just resting. 8. [11] S S Al-Riyami and K G Paterson. No. As with symmetric and asymmetric cryptography.pdf [8] C Ellison.. pages 548-566. volume 2139 of LNCS. Communications of the A. IEEE Computer 35(8):41-49. volume 2437 of LNCS. D Soldera and N P Smart. References [1] W Diffie and M Hellman. PKI: It’s not dead. pages 213-229. [7] EU Directive 1999/93/EC of the European Parliament and of the Council on a Community framework for electronic signatures.M. volume 196 of LNCS. 2002. 1984. Advances in Cryptology – CRYPTO 2001 (ed J Kilian). Certificateless public key cryptography. IEEE Transactions on Information Theory. 1976. Infrastructure Security. International Conference. Applications of multiple trust authorities in pairing based cryptosystems. given that there doesn’t seem to be such a strong separating factor such as the ability to provide non-repudiation is between symmetric and asymmetric cryptography. Certificate-based encryption and the certificate revocation problem. [10] C Gentry. December 1999: http://europa.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.