ID-based Public Key Cryptosystem

Shamir [30] proposed the identity-based (ID-based) public key approach to support public key cryptography without the use of certification. In ID-based public key cryptosystem, user A’s public key KUA is not delivered to user B, and therefore eliminates the attack presented in Fig. 3.1. User B encrypts a message for user A or verifies a signature from user A using a public key which is derived from user A’s identifier IDA (e.g., email address or telephone number; see Fig. 3.3 (3)). The trusted agent has a new role in ID-based public key cryptosystem, and is renamed as the Private Key Generator (PKG). The PKG issues the private key corresponding to the public key (derived from the identifier IDA) to user A over a secure channel (Fig. 3.3 (2)). This issuing action takes place after user A is authenticated by the PKG (Fig. 3.3 (1)). To generate private keys, the PKG makes use of a master key which must be kept secret. The requirement to have an authentic CA’s public key for verifying certificates in certificate-based cryptosystem is replaced by the requirement to have authentic PKG’s system parameters in ID-based cryptosystem. Notice that both the PKG and the user A know the private key KRA.

Figure 3.3 The ID-based public key distribution

3.5 ID-based Cryptography vs. Certificate-based Cryptography

The conventional public key cryptosystem uses the certificate to solve the authentication problem and is denoted as certificate-based cryptosystems. Both ID-based and certificate-based cryptosystems are asymmetric. Hence, the protocols for encryption, decryption, signing and signature verification have similar functionality in both systems. The main difference, however, is key management. ID-based cryptography was initially proposed to avoid the need for certificates for public key authentication. In fact, an ideal ID-based system would possess the following properties:

1. Users only need to know the identity of the user they want to communicate with.

2. There is no need for keeping public directories such as files with public keys or certificates.

3. The services of the Private Key Generator (PKG) are needed only during the system set-up phase.

However, in practice such an ideal scheme seems to be infeasible.

Depending on the application, there are several practical issues that stand in the way of the realization of an ideal ID-based system. We compare ID-based cryptography with the traditional certificate-based cryptography in the following practical aspects: authenticity of system parameters, registration at the authority, key escrow, key revocation, key distribution, master key security, and additional possibilities.

Authenticity of system parameters

Suppose an attacker in an ID-based system generates his own master key and corresponding system parameters, and fools users into believing that these forged system parameters are correct. Then for any public key, he can derive the

corresponding secret key under his master key. Hence, he can decrypt any message encrypted under his forged parameters. Further, he can create signatures under any name, which will be accepted by users who believe his parameters. The attacker might even impersonate the PKG and issue secret keys to users on request. A similar problem occurs in a traditional situation, where the users need to be sure of the authenticity of the public key of the CA. Namely, if an attacker can make users believe that some public key of his choice is the public key of the CA, then he can create certificates containing forged public keys for which he owns the secret key. Consequently, the attacker can read the messages encrypted under the forged public keys and create signatures that appear to be valid under those keys. The only difference with the ID-based setting is that the attacker cannot impersonate the CA, as users would notice that their requested certificate contains an incorrect public key.

Registration at the authority

In both systems, a user who wants to participate needs to register at a Registration Authority (RA), which we often consider part of the PKG or CA.

After some authentication procedure, the RA issues a unique digital identity to the user, for instance, in the form of an email address. In a certificate-based system,

a user can now present his digital identity and public key to the CA, along with a proof of possession of the corresponding secret key. The CA then issues a certificate that binds together the digital identity and the public key. Similarly, in an ID-based setting, the user presents his digital identity to the PKG. The PKG then computes the secret key corresponding to the public key derived from the digital identity. ID-based systems have an additional disadvantage that the secret key needs to be transported from the PKG to the user. Thus, a secure channel that guarantees both confidentiality and authenticity is required. Therefore, ID-based systems seem to work best in applications where it is easy to achieve a secure channel or where users request secret keys not very often.

Key escrow

ID-based cryptosystems have inherent key escrow. That is, since the PKG owns the master key, he can generate any private key at any moment.

Depending on the application, key escrow is not necessarily a bad thing. For instance, key escrow enables recovery of lost keys. For signatures schemes, however, it is often highly undesirable to have key escrow, as it prevents non-repudiation. Note that this escrow capability is also present in traditional public key settings where key pairs are generated by some central authority and

this authority stores the issued keys. On the other hand, if users generate the key pairs themselves or the central authority does not store the keys, there is no way that keys can be retrieved and there is no key escrow. This is in contrast to an ID-based setting, where the PKG always has the ability to regenerate keys. The ID-based encryption scheme by Boneh and Franklin provides a way to block key escrow by introducing multiple PKGs. In brief, each of these n PKGs has its own master key. A user presents his public key to each KGC and gets from each of them a partial secret key in return. Then the correct secret key is obtained by combining the n partial secret keys. Thus the ability to retrieve any user’s secret key is distributed among n PKGs. In practice, setting up a system with multiple PKGs can be a complex task. Hence, an ID-based system works best in an application where key escrow is not an objection, or where the group of users is small enough to allow multiple PKGs.

Key revocation

When a certificate is revoked in a certificate-based scheme, other users are notified by means of a public Certificate Revocation List (CRL). This occurs when a user leaves the user group or a secret key is compromised. In the latter case, or when a key pair needs to be replaced after expiration of the certificate

(key rollover), a user can simply generate a new key pair and obtain a certificate for it. However, in an ID-based setting, since a user’s public key is derived from his identity, he cannot simply obtain a new key pair after revocation as in a certificate-based scheme. That is, it can be very inconvenient to change identity every time a new key pair is needed.

A partial solution to this problem could be to derive the public key not only from the identity, but to concatenate the identity with some other general information. For instance, if the current year is added to the identity, users can use their secret key during this year only. Hence, secret keys expire annually and each user has to request a new key every year. Unlike traditional situation, users do not have to obtain new certificates from other users, because the public key is still uniquely determined in a straightforward manner (since the current year is common knowledge). But what if a user’s secret key is compromised during the year? Then the user has to wait until the end of the year. This situation can be improved by concatenating the identity with the current date instead of the current year. But the big disadvantage is that each user has to obtain a new secret key from the PKG every day. This results in a large increase in communications and a computational overhead for the PKG. Hence, the length of the validity period

is a trade-off between convenience and efficiency.

Key distribution

The great simplification of key distribution (from the users’ point of view) is the main reason to introduce ID-based cryptography. That is, all public keys can be derived from the identity of the users. So obtaining someone’s public key, for encryption or signature verification, becomes a simple and transparent procedure.

This is in contrast to certificate-based setting, where one has to look up the corresponding certificate, verify the CA’s signature, and check the expiration date of the certificate.

Master key security

The PKG in an ID-based scheme forms a single point of weakness. An attacker who is able to retrieve the PKG’s master key can derive all secret keys, and is thus able to read all messages and forge signatures under everyone’s name.

Therefore, it is very important for a PKG to keep his master key secret. To prevent the master key from being stored in one place, it can be distributed among several KGCs, like the prevention of key escrow. Similarly, the CA in a certificate-based setting is a single point of weakness as well. If the CA’s secret

key is compromised, an attacker can create certificates in the CA’s name for new public keys of his own choice, thereby fooling other users into believing those public keys. However, the leak of the CA’s secret key does not enable an attacker to retrieve previously existing secret keys. So the attacker cannot read messages encrypted under previously existing public keys, or forge signature under corresponding secret keys.

Additional possibilities

The fact that any value can be a public key offers some additional possibilities. For instance, we can concatenate the identity with other information to accomplish certain nice properties that do not exist in a certificate-based setting.

In fact, in this setting, users can send encrypted messages into the future. This is done by using the public key as the concatenation of the identity with a future date.

Now the recipient cannot decrypt the message until the specified date, when the PKG issues the corresponding secret key. Here we assume that the PKG is honest and does not issue keys before the specified date.

Furthermore, another application arises from the original idea of ID-based cryptography. For example, we can combine ID-based cryptography with traditional public key systems as follows. User U plays the role of PKG and

generates his own system parameters and master key for an ID-based encryption scheme. U keeps his master key secret and publishes the system parameters.

These parameters function as U’s public key in a certificate-based encryption scheme. As in a regular PKI setting, the authenticity of U’s public key (the system parameters) is guaranteed by a certificate from a CA. Now other users can encrypt messages for user U as in an ID-based scheme with system parameters that are given by U’s public key. Since U (and in fact only U) owns the master key for the ID-based system, he can derive the secret key for any identifier key and is thus able to read the messages encrypted under his system parameters.

Chapter 4