Introduction to PKI
Principles of Digital Certificate-based Security
Security is not just desirable; it is an essential component in any e-business system. Public key based security applications such as secure email and secure Web are the cornerstone of e-business and e-commerce solutions. The main security challenge to be addressed in these e-business applications is establishing the identity of the entities involved, be they servers, routers or end-users that communicate over public networks like the Internet. Underpinning such security applications is the Digital Certificate Management System, which registers users and issues them with their digital credentials.
Digital Certificates (also known as Digital IDs) are the technology available to perform secure authentication. Digital Certificate technology is based on the existence of a key-pair: one private key and one public key. The private key, for the sole use of the owner, must be kept secret and is used to generate digital signatures and to decrypt data. The public key, which can be made available to the public, is used to encrypt data (being sent to the owner of the corresponding private key) and to verify digital signatures.
A Public-Key Infrastructure is a comprehensive system consisting of protocols, services and standards that facilitate the use of public-key cryptography by allowing the secure distribution of public keys between communicating parties, and thereby supporting the exchange of sensitive information over an unsecured network such as the Internet. The core component of a PKI system is the “Certificate Authority” (CA), which generates, issues and manages digital certificates. The second key component is the “Registration Authority” (RA), which is used to generate the requests for certificates. For full operation, a PKI system usually has additional components, which assist in the management and distribution of certificates.
The purpose for which a PKI is built is to establish trust. The user community must trust the CA to distribute, revoke and manage keys and certificates in such a way as to prevent any breaches of security. As long as users trust the CA and its business processes, they can trust certificates issued by the CA. This is known as third party trust.
The CA’s signature in a certificate ensures that any changes to its contents will be detected. Such certificates can be publicly distributed and users retrieving a public key from a certificate can be assured of its validity, i.e. that the key: belongs to the entity specified in the certificate can be used safely in the manner for which it was certified by the CA.
There are a lot of issues to consider when setting up a Public Key Infrastructure. Firstly, you need to define what data will be contained in the certificate, the extensions required, validity period and the naming scheme used. Once these issues have been decided, you need to examine the options for key generation. How are the key pairs generated, who is responsible for key generation, how to ensure the quality of the keys, how the Personal Security Environments (PSEs) are protected during transport and storage and how to ensure that only the correct user will receive the PSE and associated PIN.
One of the major issues in deploying a PKI is the registration of users. There are many issues that influence the registration scheme - the distributed nature of the organization, logistical and operational issues surrounding the availability and skills of Registration Authority operators, corporate key recovery, security policy etc. There is no single registration scheme that will fit all organizations. Since the function of a PKI is to ‘bind’ a public key to a specific user who holds the associated private key, authentication of the user requesting the generation of a certificate is vital. The manner in which the users authenticate themselves during this registration process depends on the security policy of the organization, which in turn will depend on the secure application that will use the certificate.
Another challenge to consider is the distribution of the certificates. In small to medium sized companies certificates may be placed on a web server from where they can be downloaded or certificates may be included in an email signature. If large numbers of certificates are to be managed successfully a Directory Server is necessary. The Certificate Authority will publish all certificates to the Directory Server and the client secure application can download the required certificate from the Directory via LDAP.
Digital certificates have a limited lifetime after which the certificate will expire. Certificates may need to be revoked before they expire if a user feels that their private key has been compromised, or if the token storing a users private key has been lost or damaged. Issues such as who is allowed to revoke certificates, how that person is authenticated and how the information on revoked certificates is made available to the secure application all need to be defined in the organizations security policy and configurable in the PKI. The most common method to deal with revocation is “Certificate Revocation Lists” (CRL) which are published by the Certificate Authority at pre-defined intervals. The CRLs are digitally signed by the CA to avoid publication of a fake CRL. The CRLs are made available to the PKI users for download, to check if a certificate presented to them is valid.
Revocation status can also be checked by using an Online Certificate Status Protocol (OCSP) Responder. CRLs often contain millions of entries for revoked certificates. If clients need to check a CRL each time they wish to verify a signature (or encrypt a message) to ensure that a particular certificate is valid, then the workload involved in looking up such a large CRL could cause the client to hang for an unacceptable length of time. The purpose of OCSP is to pass this workload off to a dedicated server. When a client wishes to check whether a certificate is valid, it sends a request to an OCSP Responder, identifying the certificate that it wishes to check. The OCSP Responder then looks up a CRL (or some other mechanism) to see if the certificate has been revoked and sends back a status response to the client.
Another requirement of a PKI is the need for a key recovery and archive service for encryption keys. If a user loses his private key or leaves the organization this may result in the inability to recover data encrypted for that user. A process to recover the private key from a secure private key archive must be handled.
Remark: MoneyPINs can act as a Global Certificate Authority. Further discussion of this issue and the integration of MoneyPINs are outside of the general scope of this document.
Submitted and Modified to the WEB by: Albert Talker