D.4 Public key certificates

Section D.1 stated that in case of asymmetric ciphers the distribution channel used for transmitting the public encryption key KE of the receiver B from the KDC to the sender A , even though it does not require data confidentiality, must implement the data authentication service.

D.4.1 Authenticity of public keys

Indeed, imagine that this channel is not being protected against the impersonation threat. In this case an active attacker can mount a "man-in-the middle attack", whose scenario is described below. In this case an attacker E (ve) could interpret the encrypted messages sent by A and intended for B without breaking into the asymmetric cipher. The attacker E intercepts the distribution channel from the KDC to A and learns the public encryption key of B , referred to as KE . The attacker also produces a key pair consisting of a public encryption key and a private decryption key ( KE ² , KD ² ), using the same key generation algorithm as the KDC . She sends KE ² to A pretending that it is sent by the KDC as the public encryption key of B . Since there is no protection against the impersonation threat, A does not have any suspicions. The sender A uses the key KE ² to encrypt sensitive information, which is intended for B . The attacker intercepts the cryptogram produced with KE ² and uses the corresponding private decryption key KD ² to decipher this cryptogram. After learning the sensitive information, the attacker encrypts the data with the public encryption key KE , which really belongs to B . Neither A nor B realizes that its communication was disclosed. This is the reason why A must be convinced that she is encrypting under the authentic public encryption key of B . Public key certificates are the most used security mechanism to authenticate public keys in a system.

In order to implement public key certificates, both the sender A and the receiver B hire the services of a TTP, which is assumed to be honest and fair. Each party could delegate the generation of its private key/public key pair to the TTP, or it could produce this pair itself. In any case, the TTP produces the public key certificate on the public key of this pair for each participant, the reason for which the TTP is also called the certification authority. In the framework of electronic payment systems, the role of the CA is often played by an issuer when it generates public key certificates for public keys of chip cards, or rather is played by a card association or a payment system operator when it generates public key certificates for public keys of issuers .

D.4.2 Public key certificate generation

The CA must take appropriate measures for verifying the identity of B before generating a public key certificate for this entity. For example, when the entity B is a chip card, its public encryption key has to be certified by the issuer, which plays the role of the CA. During the personalization stage, the chip card can generate a pair consisting of a public encryption key and a private decryption key, or the issuer can generate this pair on behalf of the card and securely download the private decryption key in the chip. Only the chip card knows the private decryption key. The personalization terminal of the issuer further processes the card's public encryption key. To this end, the terminal computes the public key certificate associated with the card and downloads it in the chip in a protected production environment, which provides authentication. The issuer can keep a certificate revocation list with the public key certificates of all the compromised chip cards in the system.

To produce a public key certificate, the CA can use a digital signature scheme with recovery. The pair consisting of the public verification key and the private signing key used by the CA is denoted ( KV _CA , KS _CA ). To generate a public key certificate, the CA signs a formatted message M , which has a fixed length and is composed of several items [14]:

The certificate format distinguishes between various types of certificates ”for example, public key certificates for public encryption keys or public key certificates for public verification keys.
The CA identification number is the identifier that differentiates between several CAs that can coexist in a complex system.
The certificate expiration date is the time limit until a certificate is considered valid. After this date the verifier rejects the certificate even if the recover predicate of the CA's signature holds true.
The certificate serial number is an identifier that distinguishes among the certificates generated by a CA.
Identification means of the hash algorithm used for formatting messages, in case the signature scheme with recovery is applied to a hash code of the message to be signed.
Identification means of the algorithm used by the signature scheme with recovery.
The length of the public key to be certified and the public key itself.

A public key certificate generated by CA on the public key of an entity PK _B is denoted Cert _CA ( PK _B ). It consists of the concatenation of the signature part and the data part. The signature part is computed as Sign ( KS _CA )[ M ], where M = M _R M ² and PK _B is included in M besides items like the certificate format, the CA identification number, and the other items listed above. The formatted message M consists of two parts , M _R and M ² , where M _R is the part that can be directly recovered by the verifier from the signature part of the public key certificate. M ² represents the data part of the public key certificate that has to be separately transmitted to the verifier such that the Recover predicate can be evaluated. Note that the data part can be empty whenever the whole message M can be recovered from the signature part. Thus, one can consider that Cert _CA ( PK _B ) = { Sign ( KS _CA )[ M ], M ² }.

D.4.3 Public key certificate verification

The entity A can verify the authenticity of the public key of the entity B ,if A has an authentic copy of the public verification key KV _CA of the CA.

If the CA is the highest organization in a certification hierarchy, then there is no means to provide the authenticity of the key KV _CA in a cryptographic way. For example, this is the case when the CA is a card association. All the parties in the system know this key from a broadcast channel like a newspaper, or through normal mail sent by the CA to all the parties, the authenticity of which is provided by other means than cryptography.

However, if the CA is subordinated hierarchically to another organization CA' then KV _CA has to be further certified by CA ² . As an example, if the CA is an issuer that certifies the public keys of the chip cards issued to its clients , then CA ² is the card association where the issuer subscribed.

The entity A can verify the authenticity of the public key certificate of B as follows :

Retrieve the public key certificate Cert _CA ( PK _B ) = { Sign ( KS _CA )[ M ], M ² }of B from the entity itself or from a central database.
Retrieve the public verification key KV _CA of the CA that generated the certificate either directly, when the CA is the highest organization in the certification hierarchy, or through the verification of a chain of certificates when the KV _CA is certified by another certification authority CA ² at a higher level.
Use KV _CA to compute the predicate Recover ( KV _CA )[ Cert _CA ( PK _B )] = {?"True", M _R }. If the verification holds true, compute the formatted message M = M _R M ² , from which the entity A can retrieve the public key PK _B of the entity B .