Public key infrastructure helps achieve data confidentiality, integrity, and authentication, thus securing enterprises from cyber attacks. Let’s get familiar with the many components of this infrastructure.
The simplest encryption method used in cryptography is a key, which is a random set of characters to mathematically convert your text to some junk content, which cannot be understood unless decrypted.
The next method used is a secret key, in which a single key is used for both encryption and decryption. Either party uses the same key, leading to faster performance. The challenge is to send the secret key before starting the encryption.
Public key and private key
In public key cryptography, we use a public and private key. There are two common use cases for this:
- To share confidential information, we encrypt the message using the public key of the receiver. This can be decrypted only by using the paired private key, which is with the receiver and never shared with anyone.
- To authenticate a message, one can encrypt it using its private key, which can be decrypted only by using the public key.
Public key infrastructure (PKI)
In public key cryptography, the concern is whether we are talking to the legitimate user, as anyone can have the pair of public and private keys. PKI consists of technologies and policies that help build and use digital certificates, which can be validated by certificate authorities (CAs) using various models.
PKI protects information by providing:
- Identity authentication
- Integrity verification
- Privacy assurance
- Access authorisation
- Transaction authorisation
- Non-repudiation support
Certificate authorities (CAs)
The certificate authority or CA is an entity responsible for issuing and guaranteeing certificates. For secured communication, the CA must trust both the parties, and vice versa. There are primarily two kinds of CAs:
- Private CAs that are internal to an organisation.
- Public CAs, which are third party such as IdenTrust, Digicert, GobalSign, etc.
CAs offer a range of services, such as:
- Key generation: Creating a secure public and private key pair for the chosen cipher, algorithm and strength.
- Issuance of certificate: A user submits a request to the CA, giving its public key and its details. The CA verifies the user and provides a certificate.
- Validation of the certificate.
- Validation of the parties applying for the certificate.
- Establishing trust between users, government, and organisations.
- Managing the servers that store the certificates and private keys.
- Life cycle management of keys and certificates.
- Revoking invalid certificates due to their expiry; if the primary key is compromised, it is revoked from users.
- Renewal and issuance of new certificates generated either with the same key or new key. Usually, when the old key is not long enough or risky, a new key is used. In this case, the CA checks if any data encrypted with the old key needs to be decrypted and encrypted back with the new key.
Certificate practice statement (CSP)
CSP is the legal document a CA creates and publishes for users. It includes:
- Identification of the CA
- Types of certificates issued
- Applicable certificate policies
- Procedures for issuing, renewing and revoking certificates
- Security controls maintained by the CA
The certificate policy lays out the rules applied to an issued certificate.
PKI trust models
Trust model is an important concept in PKI. It helps us see how users and different CAs are able to trust each other.
Single CA: Here, only a single CA serves requests to the users and issues certificates. One issue with this is single point of failure. If the CA is compromised, the entire PKI collapses. This model is good only for small organisations.
Hierarchical CA: In this tree model, the root CA issues certificates to the next level CA called the intermediate CA. The good part is that each intermediate CA can have its own policies for issuing certificates and acts as a load balancer.
The intermediate CA can issue certificates, referred to as trust hierarchy. And each intermediate CA can be traced back to the root CA, which is called certificate chaining or chain of trust. For example:
- The root certificate verifies certificate A.
- Certificate A verifies certificate B.
- Certificate B verifies certificate C.
But the risk of single point of failure remains in this model too, as the root CA is the primary CA. Also, cross-certification is a limitation here, as the CA trusts another organisation.
Online vs offline CA: An online CA, usually referred to as intermediate CA, is responsible for the issuance and management of certificates to users or other intermediate CAs.
If the root CA is compromised, it can collapse the entire system. An offline CA is used only to add or remove an intermediate CA that is one level lower down in the hierarchy. It is usually powered off and disconnected from the network.
Cross-certification model CA: An alternative to the hierarchical model is the cross-certification model, also known as the web of trust model. Here we do not have single root dependency as the CAs are considered each other’s peers. But configuration of this model over a period becomes a challenge.
Bridge model CA: This model was introduced to solve the cross-certification problem. Here, a single CA called the bridge CA combines two or more hierarchical models.
Registration authorities (RAs)
Registration is the process by which end users create an account with the CA and become authorised to request for certificates. RAs carry out identity validation and submit CSRs or certificate signing requests on behalf of end users to the CA, but they do not actually sign or issue certificates. That job is done only by CAs.
The registration function is delegated by the CA to one or more RAs. CAs may use a range of tests to ensure that a subject is who he or she claims to be. It is in the CA’s interest to ensure that it only issues certificates to legitimate users, or its reputation will suffer.
Digital certificates
Digital certificates or DGs are used for identification and authentication purposes.
The DG is a wrapper for the public key and gives details of the user as well as certificate issuer or guarantor.
Digital certificates are based on the X.509 standard approved by the International Telecommunications Union and standardised by the Internet Engineering Task Force (tools.ietf.org/html/rfc5280). PGP uses its own certificate standards.
Certificate signing requests or CSRs
To obtain a certificate, a user needs to generate a special request and submit it to the CA. This is called a certificate signing request or CSR.
The CSR is a Base64 ASCII file containing the information the user needs in the certificate, including its public key, such as:
- Fully qualified domain name
- City, state, country
- Email address
The CA reviews the certificate and validates the information. If the request is accepted, the CA signs the certificate and sends it to the user.
Certificate policy
A certificate policy applies the rules needed to generate a certificate. Different certificates serve different purposes. Information in a certificate policy includes:
- Key management requirements
- Lifetime of the certificate
- Rules for exporting the private key
- Private and public key minimum lengths
Certificate attributes
The X.509 standard defines the attributes a certificate must have.
Serial number: Unique number to identify the certificate within the domain of its CA.
Version number: Version of X.509 standard the certificate complies with.
Signature algorithm: Algorithm used by the CA to sign.
Issuer: Name of the CA that has signed the certificate.
Valid from/to: Validation period of the certificate – often it’s set to one year.
Subject: Name of the certificate holder.
Public key: Holds the public key and information such as key size, algorithm, etc.
Extensions: X.509 version 3 has the option to define additional/extended attributes such as email, algorithms, intended key usage, etc.
Signature value: This ensures the validity of the certificate.
Subject alternative name or SAN: The SAN extension field is the preferred mechanism to identify DNS or names of the host. If the value is present in SAN, the subject (e.g., the browser) should validate it ignoring the CN (common name).
But the challenge here is that if a new domain is added, a new certificate needs to be issued. Whereas if a wildcard is preset in the SAN, such as *.abc.com, the certificate issued to the parent accepts all the valid sub-domains.
Types of certificates
Domain validation (DV) certificate: Provides the ownership of the domain and includes only the domain name. It is highly vulnerable. DV certificates are the quickest and least expensive certificates to acquire.
Organisation validation (OV) certificate: Provides stronger assurance than the DV; organisation verification is done manually and the certificate takes time to be issued.
Extended validation (EV) certificate: Uses a green padlock to indicate that the owner has been verified. Rigorous checks are performed on the subject. EV certificates can’t have wildcard domains, and provide assurance against phishing attacks. They also take some time to be issued after validation.
Server certificate: Part of the web server certificate, it guarantees the identity of the user.
Machine computer certificate: This is issued to machines/servers/routers/switches. Machines without a valid certificate are not allowed in the network.
Email certificate: This is issued to decrypt and encrypt messages, and is used by secure layer protocols such as S/MIME, POPv3S, PGP, IMAPS, and so on.
Code signing certificate: Software publishers use this certificate to verify source code.
Root certificate: This is used to identify the certificate’s root. Usually, the key size ranges from 2048 bytes to 4096 bytes, and more.
Self-signed certificate: Users create this for themselves, but it’s not trusted and generally used only for testing purposes.
User certificate: This identifies individuals. Also known as client certificates, it works like how passwords work.
Certificate formats
- DER – Binary format of the certificate.
- PEM – Binary data represented in ASCII text format using Base64 encoding.
- CER – Used in Windows; file extension is *.cer. Not a standard form.
- CRT – Used in Linux; file extension is *.crt. Not a standard form.
- PKCS – The contents of the file with this extension hold more than one certificate. Usually, these files are and need to be password protected. In Windows this is created with .PFX extension and in Mac or iOS with .P12 extension. In Linux, keys are stored in separate files. This file is used to transfer keys or for backup.
- P7B – This is similar to PKCS but stores information in the ASCII format and doesn’t contain a primary key. Usually used in chain of trust or secure email.
- KEY – Used only when the file holds the primary key.
Key recovery
Private keys should be shelved with the highest security and minimal access controls.
Key recovery defines a secure way to save backups, and to retrieve a key when lost.
A common way of providing access to the key is M-of-N control. Here, N number of admins are permitted to access the key and M number should be present to provide the access.
The key also needs to be backed up. If lost, access to the encrypted information would become a challenge. However, key backup increases the complexity of making it secure.
Key escrow
In key escrow, the private keys associated with public keys are archived and secured by the third party. Complete control is given to the third party to perform actions on behalf of the users. Organisations use it as it enables full control on the information at rest or in transit. If misused, it could cause harm.
Certificate revocation lists or CRLs
Certificates can be revoked or suspended for various reasons such as if they are compromised or no longer needed. Suspended keys are given a code called ‘certificate hold’. CAs maintain a list of all these suspended, revoked certificates to avoid their usage.
CRL is a mechanism for distributing the certificate revocation information. This needs to be updated constantly with the latest revoked details, usually once in every two weeks.
Online certificate status protocol or OCSP
OCSP servers are an alternative to CRL, where instead of validating the whole set, only the status of the requested certificate is communicated. Most OCSP servers can query the certificate database directly and obtain the real-time status of a certificate.
Other OCSP servers depend on the CRLs and are limited by the CRL publishing interval, which at times does not hold up-to-date information.
OCSP stapling
One issue with the OCSP server is that it requires a heavy load of the request responses. Also, it can record the requests from the clients leading to privacy issues.
OCSP stapling resolves these by using the SSL/TLS server and periodically obtaining a time stamped OCSP response from the CA.
The OCSP stapling process involves the following steps:
- A TLS-encrypted web server presents its certificate to the CA to check the validity.
- The CA responds with the certificate status, including a digitally signed time stamp.
- The web server staples the CA’s signed time stamp to the certificate when a client web browser connects.
- When the client makes an OCSP request, the server returns a time stamped response rather than making the client talk to the OCSP server itself.
- The client web browser verifies the signed time stamp.
The privacy issue is reduced here, as the browser does not need to contact the third party or even the internal CA and reveal the browsing history.
| OpenSSL |
Using the openssl command we can manage CA services such as:
|
Certificate pinning
There is a possibility of using a compromised certificate, which could lead to man in the middle or MITM attacks. Certificate pinning extends beyond certificate validations to avoid MITM attacks.
Pinning refers to the techniques used to make sure the client inspects the proper certificate. This can be achieved by either embedding the certificate along with the data so that we can decrypt and then validate the public key or by using more than one public key.
A similar (though now deprecated) variation, known as HTTP Public Key Pinning (HPKP), uses public key pins, which are essentially hashed values of the public key communicated to the browser client from the server in the HTTP header. After obtaining the server certificate, the client verifies the public key against the hash of the public key.
The challenges
PKI does have a few issues that need to be dealt with:
- It increases the operational cost of maintaining infrastructure.
- Synchronisation between the server and client is critical, in case either one rejects the certificate.
- There is the overhead of maintaining the keys securely and disposing them carefully only after decryption.
Constant effort is needed with respect to validation if the keys are compromised, if the algorithm needs to be changed, or if the CRL list is too long.
I do hope this article has got you acquainted with the importance of PKI. Further reading is suggested for getting more in-depth knowledge on the subject.
