Public Key Infrastructure (PKI)
A Public Key Infrastructure is a set of hardware, software, people, policies and procedures, required to issue, manage, distribute, use, store and revoke digital certificates.
There are three core functional components to a PKI:
- The Certificate Authority (CA), an entity which issues certificates. This can be either in-house or delegated to a Trusted Third Party;
- The repository for keys, certificates and Certificate Revocation Lists (CRL), usually based on a Lightweight Directory Access Protocol (LDAP)-enabled directory service;
- A management function, typically via a management console.
There may be a separate Registration Authority (RA), an entity dedicated to user registration and accepting requests for certificates. The RA performs the process of collecting user info and verifying user identity.
Encryption
Encryption is the process of encoding information is such a way that unauthorized persons are unable to read the information, unless they are in the possession of the key to decode it. Encryption does not prevent interception of the data, but protects against unlawful access.
Data is encrypted according to a specific algorithm which turns data into a Ciphertext. In combination with certificates, TLS (Transport Layer Security) and SSL (Secure Socket Layer) are the more frequently used protocols.
Plaintext and Ciphertext
Plaintext refers to information or data in an unencrypted, or unprotected, form. Ciphertext refers to the output of an encryption algorithm operating on plaintext. Ciphertext is unreadable without knowledge of the algorithm and a secret key.
Algorithms and Keys
An encryption algorithm is a step-by-step set of instructions that specifies precisely how plaintext is transformed into Ciphertext.
Asymmetric-key Encryption
Asymmetric-key encryption, also known as public-key encryption uses two keys, a of a public key for encryption and a private key for decryption. The public key and private key are mathematically related so that when the public key is used for encryption, the corresponding private key must be used for decryption. RSA and Elliptical Curve Cryptography (ECC) are the most common forms of asymmetric-key encryption.
Symmetric-key encryption
Symmetric encryption uses a single “key” for both encryption and decryption. The fundamental concern with this method is making sure that the intended recipient indeed is the one to receive the key.
The most common form of symmetric encryption is AES. The advantage of this over asymmetric encryption is that it is quicker to encrypt/decrypt by using a smaller key for the same level of protection, and simple to understand.
Hybrid Encryption
Encryption which combines the strengths of both symmetric and asymmetric encryption, while avoiding their weaknesses. The public key is used to encrypt the symmetric key.
The public key is used to encrypt the symmetric key. This encrypted symmetric key is sent to the recipient. The recipient can use their private key to extract the symmetric key. Now both parties have the same symmetric key which can be used to encrypt and decrypt data.
PKI Functions
The most common PKI functions are issuing certificates, revoking certificates, creating and publishing CRLs, storing and retrieving certificates and CRLs, and key lifecycle management. Enhanced or emerging functions include time-stamping and policy-based certificate validation.
Issuing certificates
The CA signs the certificate, thereby authenticating the identity of the requestor, in the same way that a notary vouches for the signature and identity of an individual. In addition, the CA “stamps” the certificate with an expiration date. The CA may return the certificate to the requesting system and/or post it in a repository.
Revoking certificates
A certificate may become invalid before the normal expiration of its validity period. For instance, an employee may quit or change names, or a private key may be compromised. Under such circumstances, the CA revokes the certificate by including the certificate’s serial number on the next scheduled CRL.
Storing and retrieving certificates and CRLs
The most common means of storing and retrieving certificates and CRLs is via a directory service, with access via LDAP. Other options include X.500 compatible directories, HTTP, FTP, and e-mail.
Timestamping
In addition to the content and authenticity of a transaction, the exact time of the transaction can be important. For instance, a transaction may have to be submitted by a certain time to be valid. The solution to having trusted transactions is to combine digital signatures with time-stamps. This can be accomplished by augmenting a PKI with a time-stamping service.
Key lifecycle management
The PKI performs some functions, such as issuing a certificate and listing a certificate on a CRL, in response of a specific request. In contrast, key lifecycle functions, such as updating,backing up, and archiving keys, are performed routinely.
Updating Keys
New keys are usually issued at regular intervals, such as every two or three year, to reduce the exposure of those keys.
Backing Up Keys
Users frequently forget the passwords that protect their private keys; or they may “lose” the keys, for example, through a disk crash or virus attack. The company should be able to restore the keys to the user.
Archiving Keys
When employees leave the company, their encryption keys are invalidated for future use, while retaining the keys in order to access previously encrypted files and email messages. Keys used for digital signatures may be retained for as long as the signed documents, so signatures can be verified. Note that many organizations archive encryption keys but not signing keys, since the availability of archived signing keys could invite abuse via identity impersonation.
Automated Key Lifecycle Management: A Critical PKI Function
The effort required to manage keys manually can limit the scalability of the PKI. Automated key management is a critical function for a large PKI.
PKI Related Standards
PKI standards permit multiple PKIs to interoperate, and multiple applications to interface with a single, consolidated PKI.
In particular, standards are necessary for:
Enrollment procedures;
- Certificate formats;
- CRL formats;
- Formats for certificate enrollment messages (client requests certificate, server issues certificate);
- Digital signature formats.
The primary focus of interoperable PKI standards is the PKI working group of the Internet Engineering Task Force (IETF).
X.509
The foundational and most universally supported PKI standards are ISO/IEC 9594-8 and RFC5280. The primary purpose of X.509 is to define a standard digital certificate format.
PKCS
PKCS is a series of standards covering PKI in areas of certificate enrollment and renewal, and CRL distribution. For PKI interoperability, the three most important PKCS standards are PKCS #7, “Cryptographic Message Syntax Standard,” PKCS #10, “Certificate Request Syntax Standard,” and PKCS #12, “Personal Information Exchange Syntax Standard”.
Standards That Rely on a PKI
Most major security standards are designed to work with a PKI. For instance, Secure Sockets Layer (SSL), Transport Layer Security (TLS), Secure Multipurpose Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET) and IP Security (IPSEC), all assume, require or allow the use of a PKI.
Hash Functions
A hash function is a mathematical function that converts a numerical input value into another compressed numerical value. The input to the hash function is of arbitrary length but output is always of fixed length. Values returned by a hash function are called message digest or simply hash values.
Compared to the (a)symmetric encryption and decryption, which are two way functions, hash functions are one way functions, meaning that from a digest, one can’t obtain the original message.
Hashing is often used to store passwords in a database, if used without salt, they are easy to crack since they result in the same digest for the same password.
Standard hashing
Hashing and Salting
A salt is random data that is used as an additional input to the hash function
Advantages of Hashing
- It is mathematically impossible to extract the original message from the digest;
- A slight change to the original message causes a drastic change in the resulting digest;
- The result of the hashing algorithm is always the same length;
- It is infeasible to construct a message which generates a given digest.
Digital Signature
A digital signature (not to be confused with a digital certificate) is a mathematical technique used to validate the authenticity and integrity of a message, software or digital document.
To create a digital signature a hash of the to-be-signed electronic data is generated. The private key is then used to encrypt the hash. The encrypted hash, along with other information such as the algorithm used, is the digital signature.
The reason for encrypting the hash instead of the entire message or document is that a hash function can convert an arbitrary input into a fixed length value, which is usually much shorter. This saves time since hashing is much faster than signing.
The value of the hash is unique to the hashed data. Any change in the data, even changing or deleting a single character, results in a different value. This enables others to validate the integrity of the data by using the signer’s public key to decrypt the hash. If the decrypted hash matches a second computed hash of the same data, it proves that the data hasn’t changed since it was signed. If the two hashes don’t match, the data has either been tampered with in some way (integrity) or the signature was created with a private key that doesn’t correspond to the public key presented by the signer (authentication). Digital signatures make it difficult for the signer to deny having signed something (non-repudiation) — assuming their private key has not been compromised. A digital signature does not guarantee confidentiality.
Digital Certificates
A digital certificate provides identity of a person, computer, system or organization. It allows those end-entities to exchange information securely over the internet. Digital certificates are generally issued by an official, trusted agency. The certificate contains the name of the certificate holder, a serial number, expiration dates, a copy of the certificate holder’s public key (used for encrypting messages and digital signatures) and the digital signature of the certificate-issuing authority (CA) so that a recipient can verify that the certificate is real.
To provide evidence that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority (CA). Operating systems and browsers maintain lists of trusted CA root certificates so they can easily verify certificates that the CAs have issued and signed.
Many digital certificates conform to the X.509 standard.
Types of Digital Certificates
Domain Validated Certificates
Domain Validated certificates are certificates that are checked against domain registry. There is no identifying organizational information for these certificates and thus should never be used for commercial purposes. It is the cheapest type of certificate to get, but this is a high risk certificate use on a public website. It is comparable to the “hooded man” or the zero star rating sellers. Visitors to a website with DV certificates cannot validate, via the certificate, if the business on the site is legitimate and thus often DO NOT trust this type of certificate. It is recommended using these types of certificates where security is not a concern, such as protected internal systems.
Organization Validated Certificates
Organizational certificates are Trusted. Organizations are strictly authenticated by real agents against business registry databases hosted by governments. Documents may exchange and personnel may be contacted during validation to prove the right of use. OV certificates therefore contain legitimate business information. This is the standard type of certificate required on a commercial or public facing website. OV certificates conform to the X.509 RFC standards and thus contain all the necessary information to validate the organization.
Extended Validation Certificate
Extended Validation Certificates are digital certificates that involves stringent vetting process to validate and verify if the entity which has requested for an SSL Certificate is legitimate. Users can see a green address bar if the website is secured with an authorized EV SSL Certificate. The green address bar builds customer trust and increases rate of conversion.
Nothing provides more trust and security than Extended Validation Certificates. It is used by most of the world’s leading organizations. They have found that switching from OV to EV certificates increases online transactions and improve customer confidence. It is no longer a luxury but a necessity.
Note: in some circumstances, even EV certificates can be fake.
Client vs Server Authentication Certificates
Server certificates are used to authenticate the identity of a server. When installed on a website, a server certificate turns the protocol on the website from HTTP to HTTPS and installs indicators that vouch for the authenticity of the website. Thus, users can know the website belongs to the said entity. Apart from authentication, server certificates also facilitate Encryption. Meaning, any information a user sends to the server is protected.
Contrary to Server certificates, Client certificates are used to validate the identity of a client (user). The user might be a website user or an email user. Simply put, it works as password, but without any intervention/input from the user. This way, the server makes sure that it’s connecting to the permitted user and that party is safe to communicate with. Client certificates also use public key infrastructure (PKI) for authentication, just like Server certificates. However, there is one significant difference between the two. Unlike Server certificates, Client certificates don’t encrypt any data; they’re installed for validation purposes only.
Certificate Authority (CA)
A CA issues and verifies certificates (see Digital Certificates). The CA takes responsibility for identifying (to a certain extent) the correctness of the identity of the person asking for a certificate to be issued, and ensures that the information contained within the certificate is correct and digitally signs it.
The CA could be seen as the PKI equivalent of a passport agency – the CA issues you a certificate after you provide the credentials they require to confirm your identity, and then the CA signs (stamps) the certificate to prevent modification of the details contained in the certificate.
Certificate Revocation
Where a system relies upon publishing certificates so that people are able to communicate with each other, there has to be a system for letting people know when certificates are no longer valid. A system of revocation lists has been developed. This is a list of certificates that are no longer trustworthy (for whatever reason).
There are currently two different methods for checking for certificate revocation – ‘CRL’or ‘OCSP’. Revocation lists may be publicly available. This is because certificates may have been distributed for use beyond the private network of the organization involved.
Certificate Revocation List
A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. CRLs are a type of blacklist and are used by various endpoints, including Web browsers, to verify whether a certificate is valid and trustworthy.
When a Web browser makes a connection to a site using TLS, the Web server’s digital certificate is checked for anomalies or problems; part of this process involves checking that the certificate is not listed in a Certificate Revocation List. These checks are crucial steps in any certificate-based transaction because they allow a user to verify the identity of the owner of the site and discover whether the Certificate Authority still considers the digital certificate trustworthy. There exists a IETF standard for CRLs RFC5280
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP) is one of two common schemes for maintaining the security of a server and other network resources. The other is the Certificate Revocation List (CRL), described above. IETF has defined an OCSP standard RFC6960.
OCSP overcomes the limitation of CRL: the fact that updates must be frequently downloaded to keep the list current at the client end. When a user attempts to access a server, OCSP sends a request for certificate status information. The server sends back a response of “current”, “expired,” or “unknown.” The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status). OCSP allows users with expired certificates a grace period, so they can access servers for a limited time before renewing.
Conclusion
It is very difficult to draw any general conclusion about PKI because it can be used in so many different ways. Implementing an organization-wide PKI for multiple applications can be a serious undertaking, requiring significant investment and commitment, while deploying a dedicated PKI for, let’s say, securing communication between a few servers can be achieved with much lesser effort. One important element to be taken into the decision may be the question of operating your own CA or using an external CA.
Identifying the problem(s) that need to be solved is the primary steps one needs to take before deciding if a PKI is the right solution. Many problems can be solved with other technology that doesn’t rely on PKI. If, however, one needs to provision digital signatures, PKI is the only technology that is capable of supporting this in a secure and scalable way.
Applications utilize more and more the benefits of a PKI, as well from an interoperability viewpoint as from the ability to control a user’s credentials from within this widely used and standardized framework. This makes PKI very valuable, especially because of just one single place from which to withdraw the user’s privileges if that user leaves the company or any other circumstance.
Useful link:
10 risks of PKI (Bruce Schneier)