This post continues on Cryptography Basics - Part II to explore some of the essential concepts in cryptography. Specifically, we will look CA, PKI and TLS.
This is a series blog posts that explores the core concepts in modern cryptography:
Cryptography Basics - Part I: Encryption and Hashing
Cryptography Basics - Part II: Digital Signature and Digital Certificates
Cryptography Basics - Part III: CA, PKI and TLS
1. CA (Certificate Authority)
A CA is an entity that is trusted to sign, issue, distribute and revoke digital certificates.
When a user accesses a website, how does he know the website is safe or not? It would be difficult to tell just between the user and the unknown host.
This issue can be resolve by introducing a third party – Certificate Authority. Basically CA, as its name, is acting as an authority to certify an unknown website (unknown to the user) for its legibility. Since CA is usually an official institute or a trusted entity, the user can trust the website as well.
Requesting a Certificate from CA
To request a digital certificate from CA, an applicant will first generate a pair of keys and then put the public key together with the applicant’s personal identifying information to generate a CSR (Certificate Signing Request). A CSR is an encoded text file that includes the public key and other information such as domain name, organization, email address and etc. The private key is held by the applicant and will not be shown to CA.
Once the CSR has been sent to CA, CA will verify that information the CSR contains is correct. If so, CA will use its own private key to generate a signed certificate and send it back to the applicant.
Verifying CA Signed Certificate
When the signed certificate is presented to a third party, CA’s signature presented in the signed certificate will be verified. This can be done with the public key CA has published on its website. This is because if the signature was encrypted with CA’s private key, it should be able to be decrypted and thus verified by CA’s public key. On the contrary, if the signature can’t be decrypted with the CA’s public key, the verification fails.
8. PKI (Public Key Infrastructure)
So far, we have seen a list of tools and methods, e.g. asymmetric encryption, hashing, digital signature, digital certificate, which are used to fulfill various security needs in the modern world. To properly manage those, we will need a structure or a framework.
The concept of PKI (Public Key Infrastructure) can be considered as the infrastructure involving the set of hardware, software, policies, processes, and procedures required to create, manage, distribute, use, store, and revoke digital certificates and public-keys.
One of the main elements in PKI is asymmetric encryption which uses a public key and a private. Without PKI, sensitive information can still be encrypted, ensuring confidentiality, and then exchanged between two parties. However, there would be no assurance of the identity of the other party. A public key certificate helps to establish an association between an identity and a public key.
For example, suppose you receive a file from a sender, which can only be opened with a password. Yet, even though you have the password, how would you know the sender’s identity or legibility? The sender might be a camouflaged hacker or an illegal group. With the help of a trusted third-party- Certificate Authority, you have a much better confidence level on the source of the information.
Certificate Chain
There are three kinds of certificates here: Root Certificate, Intermediate Certificate and Leaf Certificate (Server Certificate).
Root Certificate: A certificate that belongs to the issuing Certificate Authority. A number of Root Certificates come pre-downloaded with most web browsers and are stored in a “trust store”. The Root Certificates are closely guarded by Certificate Authorities.
Intermediate Certificate: A certificate signed by Root Certificate and is also used to sign other Intermediate Certificate or Leaf Certificate. It acts as a middleman between Root Certificate and Leaf Certificate. There will always be at least one intermediate certificate in a chain, but can be more than one as well.
Leaf Certificate: A certificate signed by an intermediate certificate and can be used by end users.
The benefit of this hierarchical structure is that an intermediate certificate will create a separator between the root certificate and the end certificate. Even an end certificate is compromised in a way that allows malicious access to the next level of certificate, an intermediate certificate is acting as a layer protecting the root certificate.
Root Certificates are self-signed by CA as they are the top level and CAs follow very strict security guidelines to ensure those Root Certificates are well-guarded. Precious Root Certificates will not be used to sign the end certificate directly. Instead, root certificates will sign intermediate certificates which are then used to sign end certificates.
Chain of Trust
The Chain of Trust refers to how an end-user certificate is linked back to a trusted CA. As from the certificate chain, we know that each end certificate has one or more intermediate certificates and a root certificate.
For example, when you use your web browser accessing a website with HTTPS, that SSL/TLS certificate will be verified. It will first check the end certificate’s signature with the public key from the issuer. If the signature is verified on the end certificate, the question then is whether the intermediate certificate used to sign the end certificate is legitimate. The web browser will then check the intermediate certificate signature with the public key from root certificate. This builds up the chain of trust.
Yet, you may wonder how a root certificate is trusted here, as we know root certificate is self-signed. Solving this issue will need to involve third parties.
For a workstation or a mobile device, there is usually a place called ‘root store’, where a list of trusted root certificates is stored. If not provided by the device itself, a public-facing root store is usually maintained under the authority of a major software provider, which distributes their root store along with software which depends upon it to determine the trust. Many providers of browsers and operating systems operate their root store programs (usually very strict) and CAs may apply to be accepted into a root store using the criteria of that program. Note each root store is independent of the other. For example, Mozilla, Microsoft, Apple and Google maintain their own root stores.
Here is a list of trusted CAs from Firefox.
CRL (Certificate Revocation List)
A CRL is a list of certificates that have been revoked by the CA before their scheduled expiration date and should no longer be trusted. CRLs can be considered as a type of blacklist to verify whether a certificate is still valid and trustworthy.
For example, when a browser makes a connection to a site using TLS, the server’s certificate is checked for anomalies, and part of the process involves checking that the certificate is not listed in a CRL.
A certificate can be revoked for many reasons. The most common reason for revoking a certificate occurs when a certificate’s private key has been compromised. Other reasons could be that if a CA finds a certificate was issued improperly, it may revoke the original and issue a new one; if a certificate is found to be counterfeit, the CA will revoke it and add it to the CRL.
Note that the difficult part for CRL to work properly is that they are difficult to maintain and difficult to be distributed efficiently. When a CA receives a CRL request from a browser, it returns a complete list of all the revoked certificates that the CA manages. The browser must then parse the list to determine if the certificate of the requested site has been revoked. Even though the list is updated as often as hourly, there could still be a latency. Furthermore, to avoid the download overhead, a lot of times CRL is cached, which could also potentially post the risk of not having the latest list.
Certificate Lifecycle
So far, we know a certificate’s life span involves different stages. Let’s take a look at its lifecycle. The lifecycle of a certificate can be broken down into multiple steps.
Certificate Enrollment – An entity submits a request for a certificate to CA.
Certificate Issuance – CA validates the identity of the applicant.
Certificate Validation – Every time the certificate is used, it will be checked with CA ton confirm that it’s still valid
Certificate Revocation – When a certificate is expired or actively revoked by CA for other reasons
Certificate Renewal – A certificate can be renewed once it expires, where you can choose whether to generate a new pair of keys or not.
3. Key and Certificate Management
Key Management
As data encryption and protection has grown dramatically during the recent digital era, there is a large increasing in the number of encryption keys used throughout an enterprise.
In essence, key management deals with generating, exchanging, storing, using and replacing cryptographic keys as needed at the user level. Controlling and maintaining data encryption keys is an essential part of any data encryption strategy.
In an organization or enterprise, key management is usually done through a CKMS (Centralized Key Management System). CKMS is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications.
There are several key management standards, some of which are still underway. The best known is the KMIP (Key Management Interoperability Protocol) developed by vendors and OASIS (Organization for the Advancement of Structured Information Standards). KMIP’s goal is to allow users to attach any encryption device to a key management system.
Certificate Management
Similar to key management, certificates, as another essential asset to data encryption and protection, will need to be properly managed as well. This management process can include creation, storage, dissemination, suspension and revocation.
One thing from key management is that certificate has an expiration date and once that is passed, the certificate can no longer be used. Hence, certificate management requires close monitoring on the valid period of each certificate and proper alert message should be delivered to the right staff member.
4. SSL/TLS (Secure Socket Layer / Transport Layer Security)
SSL and TLS are both cryptographic protocols that provide authentication and data encryption between servers, machines and application operating over a network, e.g. client server connection.
When we talk about SSL/TLS, most likely we are referring to TLS, as SSL is NOT used anymore today.
SSL has been around for about 25 years and TLS is actually a new version of SSL. When IETF adopt SSL, it is renamed to TLS.
Why TLS
As we have seen previously, digital certificates are used in TLS to fulfill some security purpose. Specifically, there are three essential functions: Encryption, Authentication and Data Integrity.
Encryption: A mechanism to protect what is sent from one host to another
Authentication: A mechanism to verify the validity of the identified service provider
Integrity: A mechanism to detect message tampering or forgery
These three functions are crucial during network communication, especially when we are sending sensitive or valuable information.
How TLS works
In order to establish a cryptographically secure data channel, the connection peers must agree on which cipher suite to use and the keys used to encrypt the data.
The exact steps within a TLS handshake will vary depending upon the kind of key exchange algorithm used and the cipher suites supported by both sides. RSA key exchange (asymmetric encryption) is most often used and the following steps describe it.
TLS runs over TCP, which means we must first complete the TCP three-way handshake (SYN, SYN ACK and ACK). With the TCP connection in place, the client sends a hello message including a number of specifications in plain text, such as the version of TLS protocol it is running, the list of supported cipher suites, and a string of random bytes known as the “client random”.
When client message received, the server then selects the TLS version and cipher suite from the list provided by the client as well as attaching the certificate (contains public key), a “server random”, another random string of bytes that’s generated by the server, and sending the hello done response back to the client. Optionally, the server can send a request for the client’s certificate.
When the server response is accepted by the client, both sides have agreed on a common version and cipher, and the service certificate has been verified as well. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
Client will then initiate a key exchange, which is used to establish the symmetric key for the session. In the case of RSA, the client sends one more random string of bytes, the “premaster secret”, which is encrypted with the server’s public key and can only be decrypted by the server’s private key. This premaster secret will be used by both client and server to generate master secret and session key. The session key is a temporary key used to symmetrically encrypt the data communication within the client server connection session.
The “Change Cipher Spec” message from the client lets the server know that it has generated the session key and is going to switch symmetric encryption with the generated session key. The “Finished” message sent by client to server indicates that the handshake is complete on the client side.
The server processes the key exchange parameters sent by the client, decrypts the premaster secret and computes the session key. Then it sends its “Change Cipher Spec” message to indicate it is switching to symmetric encryption using the generated session key as well. Note both client and server will generate the same session key based on the shared premaster secret. Then the server sends its “Finished” message to the client.
After these steps, both parties now have a session key and can exchange application data over the secured channel they have established. All messages sent from client to server or server to client are encrypted using the session key.
5. Sum Up
This post continues on Cryptography Basics - Part II. First we looked at what a Certificate Authority is. Then we focused on PKI and checked out the details on how it works. After that, we touched some concepts about key/secret management. Lastly, we took a peek on TLS and how it works.