TLS: Certificates and PKI (3/3)

Azmi Sbai Etude - Recherche

A public key certificate is a kind of digital identity card: it creates a link between a public encryption key, the identity of its owner and the use that can be made of that key.

To ensure the veracity of the certificate content, it is signed by a trusted authority, called a Certificate Authority. A certificate has a limited lifespan:reach its expiration date or be revoked. There are several reasons for revocation: loss of the private key, modification of the certificate holder’s name …

It is then placed in a Revocation List Certificate Revocation List (CRL) signed by the Certificate Authority on which it depends and where certificates that are no longer trustworthy are stored. There are several types of certificates: the X509 format, which relies among other things on the hierarchy of certification authorities.

Public Key Infrastructure (PKI):

A PKI is a set of means (technical and organizational) to ensure the management, use and life cycle of electronic certificates, and to ensure reliability. It is the PKI that will manage the relationship of trust in the validity of an identity. It has been made possible by the use of keys and certificates, and on the other hand by an organization guaranteeing the delivery and management of these elements.

A PKI meets the following IT security criteria:

  • Authentication: used to verify the identity of an entity (user, server, etc.)
  • Non-repudiation: an entity that transmits data can not deny being the author of the message
  • Integrity: this is to ensure that the data have not been altered, whether intentionally or accidentally
  • Confidentiality: the information exchanged is only readable by the holders of a secret sharing, usually a session key.

A PKI can be divided into five distinct entities:

  • The End Entity (EE): The entity (user or server) that is subject to a certificate, but also more widely the user of a PKI.
  • The Certificate Authority (CA): The trusted authority that signs Certificate Signing Request (CSR) and revocation lists. As we shall see later, this entity is the most critical.
  • The Registration Authority (RA): is the one that is contacted by the EA when applying for a certificate. It carries out the usual checks on the identity of the EA, then generates the certificate, awaits its signature by the CA and finally sends it to the EA.
  • The Repository: It saves revocation lists and signed certificates.
  • Key Escrow: The law requires PKIs to be able to decrypt data encrypted by a PKI user. The purpose of the sequestration authority is therefore to store the encryption keys that have been generated by the PKI and to provide them to the authorities if they so request. On the other hand, it can not know the private keys of the certificates that are not generated by the RA but only signed by the CA.

How a PKI Works:

  1. The client begins by requesting a certificate from the RA registration authority.
  2. The RA generates a pair of keys that will be used by the client and transmits the Certificate Signing Request (CSR) to the certification authority.
  3. The certification authority creates the certificate, at which point it usually takes the agreement of one or more managers to validate the operation.
  4. The private key is registered in the escrow authority.
  5. The certificate authority shall transmit the certificate to the registration authority which has requested it.
  6. The registration authority sends the signed certificate and the private key that was generated earlier.

Certification Authority:

There are currently a large number (about 700) of CA and unfortunately the users can not know all of them. The problem is that if a user wants to ensure the authenticity of a server that has a certificate signed by a CA that it does not know is very difficult with the large number of CAs. So to overcome this kind of problem the idea is to create a string, so that CA certificates can be certified by other CAs.

The CAs were therefore prioritized as follows:

  • Internet Policy Registration Authority (IPRA): this type of authority acts as the root (level 1) of the hierarchy. There are very few, they are managed by ISOC 1 and only issue certificates for the next level of authority: the BCPs.
  • Policy Certification Authority (PCA): each PCA is certified by an IPRA and is at the second level of the hierarchy. It shall establish and publish a definition of its user certification policy or of subordinate certification authorities.
  • Certification Authority (CA): CAs are at the third level (signed by a PCA) and at subsequent levels of the hierarchy (signed by other CAs).

Thus, a chain of CAs is created to verify the validity of a certificate: such a string is called a certification path. A CA can only certify other CAs that are at the lower level in the CA hierarchy tree.

Certication Revocation List (CRL) et Online Certicate Status Protocol (OCSP):

A CRL corresponds to the list of the identifier of the certificates revoked by a given certification authority. It is signed by the CA which publishes it in order to avoid any modification of it by an unauthorized entity. In addition to the certificate identifiers, a CRL may include a date of issue, an update date and the possible reason for revocation. For information, there are two possible revocation states (defined in RFC 3280): revoked (definitive) and hold (temporary).

Mostly used, CRLs have some disadvantages. We can mention, on the one hand, their large size which can increase network traffic, and on the other hand the fact that the validation of a certificate is carried out customer rating, which can be critical in terms of security. This last point is due in particular to the fact that browsers do not always perform this verification perfectly. To try to correct this, the IETF has standardized a new protocol, the OCSP, which centralizes this task within the PKI itself.

The operation of the protocol is rather simple since it is a question for the OCSP client to send a request to the OCSP responder (sometimes called validation authority or VA) which carries out the validation operation and sends a Signed reply that can take three states: good, revoked or unknown.

X.509 Certificate:

X509 defines a framework for the provision of X500 directory authentication services that serves as a repository of public key certificates. Each X509 certificate contains the public key of the user and is signed by the private key of the trusted CA.

The structure of an X509 certificate, presented below in the form of a table:

X509 extensions v.3:

As we can see from the above table, the extensions field is defined by RFC 5280 and it appeared in version 3 of X509. These extensions allow you to supplement the certificates by adding additional information. They can be divided into several major groups:

  • Constraints on certification: basicConstraints: this extension contains two variables, the Pathlen which corresponds to the maximum number of certificates that can appear in the certification path and the boolean cA that is set to TRUE if this certificate can be used to issue other certificates and To FALSE otherwise. Thus a Pathlen is relevant if and only if the cA is TRUE.
  • Key information: keyUsage, extended keyUsage: this extension is used to indicate and control the use that can be made of the key contained in the certificate: signature, signature of certificates / CRL, encryption Keys or data, algorithms with which it can be used, non-repudiation. If the criticality field of this extension is TRUE, then the key should only be used for the specified purpose, and any other use would be in violation of the CA or PKI policy.
  • Attributes of CA or users: Authority Info Access (AIA), Subject Alternative Name (SAN): the AIA is used to give additional information about the CA, for example its URL or its OCSP / CRL answering machine. The SAN field specifies one or more unique and additional names for the certificate holder. They can be used in email, web, network applications where it can be very useful to identify a user, or a machine, other than by a DN. The allowed names are: e-mail address, domain name, IP address, URL …
  • Certificate Use Information: Certificate Policies: This extension specifies the certificate policy that presided over the issuance of the certificate. It is represented by OIDs (Object Identifiers) which are internationally standardized numbers. These OIDs are registered internationally, and their use is standardized. A certificate may contain multiple OIDs, provided that they are not incompatible.