Chapter 7

Cryptography Basics

Part II · IAM Core Concepts27 min read

For IAM (Identity and Access Management) professionals, having a foundational understanding of cryptography is crucial.

Cryptography plays a vital role in ensuring the confidentiality, integrity, and authenticity of sensitive data within IAM systems. Understanding cryptographic algorithms, such as symmetric encryption, asymmetric encryption, and hashing, allows IAM professionals to implement secure authentication and authorization mechanisms.

Encryption techniques are used to protect sensitive user data, such as passwords and personal information, while hashing algorithms help ensure the integrity of stored data by verifying its integrity against tampering. Familiarity with cryptographic protocols, such as SSL/TLS, enables IAM professionals to establish secure communication channels for transmitting authentication and access control information.

Moreover, knowledge of cryptographic key management practices, such as key generation, distribution, and revocation, is essential for IAM professionals to design and implement secure key management systems.

A fundamental understanding of cryptography equips IAM professionals with the necessary knowledge and skills to implement robust security measures, safeguard user identities, and protect sensitive data within IAM systems.

Key Points

Encryption/Decryption:
- Transforms data to protect confidentiality.
- Uses algorithms and keys.
- Different from encoding (data transformation for compatibility).
Symmetric Encryption:
- One key for both encryption and decryption.
- Algorithms: AES, DES, IDEA, Blowfish, RC4 (stream cipher), RC5, RC6.
Asymmetric Encryption:
- Two keys: Public key for encryption, private key for decryption.
- Enables secure communication without pre-shared keys.
- Used in TLS/SSL, digital signatures.
- RSA is a common algorithm.
Hashing:
- One-way function producing a fixed-size output (hash) from variable-size input.
- Used for data integrity verification, password storage, digital signatures.
Digital Signatures:
- Authenticates the sender and ensures data integrity.
- Uses asymmetric encryption and hashing.
Digital Certificates:
- Links a public key to an entity.
- Issued by Certificate Authorities (CAs).
- Used for secure connections (SSL/TLS) and authentication.
PKI (Public Key Infrastructure):
- Framework for managing digital certificates.
- Certificate chain: Root CA -> Intermediate CAs -> End-user certificates.
- Chain of trust: Verifying certificates through a hierarchy.
CRL (Certificate Revocation List):
- List of revoked certificates.
Key and Certificate Management:
- Securely managing cryptographic keys and certificates.
SSL/TLS:
- Cryptographic protocols for secure communication.
- TLS is the successor to SSL.
- Provides encryption, authentication, and data integrity.

Cryptography Intro

Cryptography is about a set of methods which enable storing and transmitting information while safeguarding it from intruders. In other words, we use cryptography methods to keep information private and only intended recipients can read the message.

Cryptography has been long. The oldest application of cryptography is military secrets protection. One of the best-known ciphers is the Caesar Cipher, attributed to Julius Caesar. It is used to send confidential information to his commanders and soldiers in the field.

A massive use of cryptography in the modern world is on the Internet. HTTPS use cryptographic ciphers to protect information flowing between client and servers. Passwords are stored in encrypted format to protect from hackers. Other sensitive commercial information is encrypted to avoid disclosing to the public.

Encryption and Decryption

Cryptography is achieved by converting data into a different form called ciphertext or code which is often incomprehensible. This process is called encryption. The reverse process, which converts ciphertext into original data, is called decryption.

To perform encryption and decryption, we will need Algorithms and Keys. The algorithm here can be considered as a mathematical procedure needed to convert data into ciphertext or recover from it. The key here is a piece of information used with an algorithm to fulfill that process.

Encryption VS Encoding

You probably have heard about encoding, which is a different process from encryption. The purpose of encoding is to transform data so that it can be properly stored or consumed by a different type of system.

For example, a message encoded by Morse code does not have privacy protection, as anyone who knows the Morse code standard can understand it; yet, the encoded message can be transferred from one place to another through telecommunication.

On the other hand, encryption is to transform data in order to keep it secret from others.

Key Length and Encryption Strength

The strength of encryption is related to the difficulty of discovering the key, which in turn depends on both the cipher and the length of the key. Key length is measured in bits.

Generally speaking, longer keys provide stronger encryption. Then the question comes: should we always use a very long key? A longer key may be stronger for encryption; yet, it will also require more calculation during encrypting and decrypting. Thus, a proper key length helps finding a balance between encryption strength and its operability.

Furthermore, different algorithms have different compute procedures. Given the same key length, different algorithms will have different encryption strengths. In other words, to achieve the same level of encryption strength, different algorithms might need to use different key lengths.

Symmetric Key Encryption

Symmetric Key Encryption is a type of encryption where only one key is used to both encrypt and decrypt data. This is in contrast to Asymmetric Key Encryption, where two different keys are used: one for encryption and the other for decryption. The entities communicating via symmetric encryption must exchange the key in a secretive way.

The secret key being used can be a specific password/code or just a random string. Besides the secret key, an encryption algorithm is needed as well. This algorithmic procedure includes ways of both encryption and decryption.

Some examples of symmetric encryption algorithms include:

AES (Advanced Encryption Standard), this is the most popular one used today
DES (Data Encryption Standard)
IDEA (International Data Encryption Algorithm)
Blowfish (Drop-in replacement for DES or IDEA)
RC4 (Rivest Cipher 4)
RC5 (Rivest Cipher 5)
RC6 (Rivest Cipher 6)

AES, DES, IDEA, Blowfish, RC5 and RC6 are block ciphers. RC4 is stream ciphers.

Block cipher uses a block algorithm, where original data is divided into blocks and encrypted with the secret key. During the encryption process, data will be held in memory before the entire encryption process is done.

Stream cipher uses stream algorithm, where data is encrypted as streams instead of blocks being retained in system memory.

AES is the symmetric encryption choice for most applications today. It is very widely used, mostly with 128-bit or 256-bit keys. 256-bit keys are considered strong enough to protect military top-secret data.

Asymmetric Key Encryption

Asymmetric key encryption, also known as Public-Key Encryption, uses a pair of keys (Public Key and Private Key) for encryption/decryption in contrast to just one key in Symmetric Key encryption.

A public key is a key used by any person to encrypt a message so that it can only be decrypted by the intended recipient with the related private key. An encrypted message with a public key can Only be decrypted by the related private key when the pair of keys were initiated. A private key is usually held by the key initiator and is kept from the public.

Public keys are usually published online for users to download. In this case, when a user wants to send an encrypted message to a recipient, he can download the public key and encrypt the message with it and then send the encrypted message to the recipient. As the encrypted message can only be decrypted by the related private key, which is held by the recipient. The information contained will be protected from external access.

On the other hand, if a private key holder encrypts the message with the private key, any user with a public key can decrypt it. A scenario for this use case is to authenticate the message is really sent by the private key holder.

Because of the one-way nature of the encryption function, a sender is unable to read the message of another sender, even though they have the same public key. In other words, a public key cannot decrypt a message which is encrypted by that public key.

Asymmetric Key Encryption is widely used today and many protocols rely on it, such as TLS (Transport Layer Security) and SSL (Secure Sockets Layer) which makes HTTPS possible. The encryption process is also used when a secure network connection needs to be established. Besides, Asymmetric Encryption can also be used to authenticate data using digital signatures.

RSA (Rivest-Shamir-Adleman) Algorithm is usually used for Asymmetric encryption and it has become pretty much an industry standard, which also offers choices of key size and digest algorithm.

Symmetric VS Asymmetric Encryption

Asymmetric encryption was developed to replace Symmetric encryption, as Symmetric encryption has an inconvenient drawback – the need to share the symmetric key between sender and receiver.

For example, suppose we have a service provider who is also a message receiver. He will be communicating with various service users. Specifically, those users will be sending messages to the receiver and those messages need to be encrypted.

In this case, using Symmetric Key encryption requires that key to be shared among users. This is not a secure way to do it. If one user compromises the key, the encryption could be compromised. As more users are starting to use the service, the risk of compromising the key will increase as well. Furthermore, if a user who possesses the symmetric key is a hacker and intercepts the encrypted message, he will be able to decrypt the message as well.

On the other hand, a lot of times, it is not practical for service providers to use different symmetric keys for different users, e.g. 1000 users will result in 1000 different keys, and that would be difficult to manage.

Diagram: Symmetric VS Asymmetric Encryption

Asymmetric encryption resolves this issue. First, a public key is published to all the users, any user can download the public key, so there is no such thing as ‘compromising the public key’. Second, when a user encrypts a message using the public key, it can’t be decrypted with that public key. In other words, other users possessing this public key can’t decrypt the message. Only the private key holder can decrypt the message. Third, regarding user scaling, since the public key is already published, increasing user number is not an issue.

As Asymmetric encryption involves two keys, the processing time is increased. That is, Asymmetric encryption usually takes longer than Symmetric encryption.

Factor	Symmetric Encryption	Asymmetric Encryption
Number of Keys	One Key	Two keys – Public Key and Private Key
Complexity	Simple technique as only one key is used to carry out both operations	Contribution from separate keys for encryption and decryption makes it a fairly more complex process
Swiftness of Execution	Fast	Relatively slow
Algorithms	AES	RSA

Hashing

Hashing in the cryptographic context usually refers to the process of generating a fixed-size output from an input of variable size. This is done via the use of hash functions, which are mathematical algorithms.

Hashing is a one-way method. In other words, an input value through a hash function will generate a hashed string, but the hashed string can’t be reversed to recover the original input value. This is different from Symmetric/Asymmetric encryption and is designed on purpose.

Besides one-way feature, there are two important features regarding hashing:

Whether it’s a giant file or a small amount of input, the output hash string is fixed length
Even if it is a huge file, a tiny change will result in a very different hash string

Here are some examples:

Adding a dot to the “hello world” string will result in a very different string. The hash string of a downloaded Ubuntu ISO file is still 64 characters.

Seeing those features of hashing, now the question becomes where we should use hashing. While Symmetric/Asymmetric encryption is to protect the information from being accessed from others, the purpose of hashing is to verify the integrity of the data received.

For example, when a user receives a data pack from a sender, how does he know the received data is not missing fragments or tampered?

To help with that, the sender can generate a hashed value of the data and send both data and generated hash string to the receiver. Once the receiver receives the data and hashed value, the receiver can do the same as what the sender has done – generate the hashed value from the original data and then compare the two hashed strings. If the data received has changed, the newly generated hash string will be different from the original hash string, and hence the receiver knows the data is missing fragments or tampered. He can then inform the sender and find another way to send the data.

Real world applications of Hashing could involve:

Password Verification – Storing password in plain text is insecure, so nearly all passwords are stored as hashes. When a user inputs a password, it is hashed and the result is compared to the stored hash value to authenticate the user.

Signature Generation and Verification – Verifying signatures is a process to verify the authenticity of a digital document or message. A valid digital signature gives its receiver strong proof that the message was created by a known sender and that message was not altered in transit. We will look at digital signature and verification later.

Verify File and Message Integrity – Hashes can be used to make sure messages and files transmitted from sender to receiver are not tampered with during transit. This practice builds a “chain of trust”.

Digital Signature

Digital signatures can be considered as an electronic version of “fingerprints”. In other words, the digital signature securely associates a signer with a document in a transaction.

Here is the flow on how digital signature is created and verified.

First, the signer generates a hash value from the data and then encrypts the hash value with his private key. The encrypted hash value will be “packaged” together with data and sent to the receiver. After the receiver receives the “package”, he generates a new hash value with the data received. Besides that, the receiver will use a public key published by the signer to decrypt the encrypted hash value from the “package”, which will give us the original hash value. The two hash values are then compared for their values. Any discrepancy means the “package” is not valid and should be discarded.

Let’s take a closer look to see why this is a fail-safe delivery. First, if the encrypted value is not using the signer’s private key, the verifier's decryption will fail. As the public key is published from the Signer’s website, the public key guarantees its originality. This means the private key used to encrypt the data was incorrect. This could be due to a mistake or a hacker’s interception. The data will be discarded in this case. In this case, the public and private keys guarantee the source of the data (the sender) is valid. Next, we need to ensure the validity of the data. Any modification on the data, even so very tiny, will result in a different hash value due to the feature of hashing. If the two hash values are different, it means the data has been tampered and the “package” should be discarded as well.

The failure on the verifier’s side will bring up exceptions in the system which can then be handled by the system. For example, verifiers can ask the signer to send another “package” or some other methods will be used to tackle the situation.

The point here, with the digital signature which leverages Asymmetric Encryption and Hashing, is that message delivery is guaranteed to be successful.

Digital Certificate

A Digital Certificate, also known as Public Key Certificate or PKI Certificate, is used to link ownership of a public key with the entity that owns it.

The majority digital certificates serve two main functions:

It verifies the identity of the applicant. With digital certificates, you can be ensured that the entities (website, companies, individuals, etc.) you are interacting with are really who they say they are.
It encrypts the data transferred between two systems so data can only be interpreted by the intended receiver.

The format of digital certificates is defined by X.509, which is an industry standard. It is defined by ITU-T (International Telecommunication Union’s Standardization sector).

Certificate Sample

Here is a sample certificate which is the SSL cert for Wikipedia.org. Note it is encoded so it is not human-readable. The “-----BEGIN CERTIFICATE-----” and “-----END CERTIFICATE-----” parts are usually required when you use the certificate.

The decoded information is as below:

And the detail information is listed here:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:02:b3:43:f5:59:0b:2e:55:ca:6e:47:59:a4:d3:0f:df:0b
    Signature Algorithm: sha256WithRSAEncryption
        Issuer:
            commonName                = Let's Encrypt Authority X3
            organizationName          = Let's Encrypt
            countryName               = US
        Validity
            Not Before: Mar 22 07:01:41 2020 GMT
            Not After : Jun 20 07:01:41 2020 GMT
        Subject:
            commonName                = *.wikipedia.org
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:74:b5:b5:1c:df:2e:26:46:2c:50:ac:cd:51:15:
                    e6:56:88:0e:ba:b4:bf:38:b6:18:41:0a:91:d8:1e:
                    cd:7b:66:0a:a1:16:f3:8f:25:3e:71:02:8a:7e:88:
                    94:ad:eb:17:f0:8e:03:a3:26:cc:09:39:bf:68:65:
                    77:37:37:5f:4f
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A4:78:12:BA:69:56:E0:CE:DA:1C:14:A7:2C:23:FA:33:2B:65:B0:C6
            X509v3 Authority Key Identifier:
                keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
            Authority Information Access:
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
            X509v3 Subject Alternative Name:
                DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikipedia.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikipedia.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

Digital certificates are most commonly used for initializing secure connections (SSL/TLS). Digital certificates are also used for sharing public keys which are used for public key encryption and authentication of digital signatures.

A digital certificate mainly includes:

Public key being certified
Identifying information about the entity that owns the public key
Metadata related to the digital certificate
Digital signature created by the issuer of the certificate

Format

Usually, the format of a digital certificate will contain the following information.

Certificate Format Types

There are different formats of X.509 certificates: PEM, PCKS#7, DER and PCKS#12.

PEM and PCKS#7 formats use Base64 ASCII encoding while DER and PKCS#12 use binary encoding. The certificate files have different extensions based on the format and encoding they use.

PEM Format

Most CAs provide certificates in PEM format in Base64 ASCII encoded files. The certificate file types can be .pem, .crt, .cer, or .key. The .pem file can include the server certificate, the intermediate certificate and the private key in a single file. The server certificate and intermediate certificate can also be in a separate .crt or .cer file. The private key can be in a .key file.

PEM files use ASCII encoding, so they can be opened in text editor. The certificate is contained between ---- BEGIN CERTIFICATE ---- and ---- END CERTIFICATE ---- statements.

PKCS#7 Format

PKCS#7 format is a cryptographic message syntax standard. PKCS#7 certificates use Base64 ASCII encoding with file extension .p7b or .p7c. Only certificates can be stored in this format, not private keys. The P7B certificates are contained between ---- BEGIN PKCS7 ---- and ---- END PKCS7 ---- statements.

DER Format

The DER certificates are in binary form, contained in .der or .cer files. These certificates are mainly used in Java-based web servers.

PKCS#12 Format

The PKCS#12 certificates are in binary form, contained in .pfx or .p12 files

The PKCS#12 can store server certificates, the intermediate certificate and the private key in a single .pfx file with password protection. These certificates are mainly used on the Windows platform.

Certificate Usages

TLS/SSL Server Certificate

In TLS (Transport Layer Security), which is a replacement for SSL, a server is required to present a certificate as part of the initial connection setup. A client connecting to that server will perform the certification validation:

The subject of the certificate matches the hostname, i.e. domain name, to which the client is trying to connect
The certificate is signed by a trusted Certificate Authority

The primary hostname (domain name of the website) is listed as the Common Name in the Subject field of the certificate. A certificate might be valid for multiple hostnames, that is multiple websites.

A TLS/SSL server may be configured with a self-signed certificate. In that case, clients generally won’t be able to verify the certificate. Depending on the context, sometimes clients can proceed with access while sometimes they are forced to terminate the connection.

Self-Signed Certificate

A Self-Signed Certificate is a certificate that is not signed by a CA. These certificates are easy to generate and cost-free. Yet, they lack some security properties compared to the ones signed by a CA.

For example, when a web server uses a Self-Signed Certificate to provide HTTPS services, users will see a warning sign in the browser. Sometimes users will be forced by the browser to terminate the connection.

Root Certificate

A Root Certificate is a certificate that identifies a root CA. Root certificates are self-signed and form the basis of X.509-based PKI (Public Key Infrastructure). We will be looking at more details for PKI later.

Intermediate Certificate

An Intermediate Certificate is a certificate used to sign other certificates. It’s within the middle tier in the PKI hierarchy. An intermediate certificate must be signed by another intermediate certificate, or a root certificate.

Leaf Certificate

Leaf certificate is any certificate that cannot be used to sign other certificates. For example, TLS/SSL server certificates.

TLS/SSL Client Certificate

Client certificates are less common compared to server certificates. They are used to authenticate a client connecting to the TLS server as well as providing access control.

Client certificates are more common in RPC systems, where they are used to authenticate devices to ensure that only authorized devices can make certain calls.

Email Certificate

In the secure email protocol, senders need to discover which public key to use for a given recipient. They get this information from an email certificate.

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 if the website is safe or not? It would be difficult to tell just between the user and the unknown host.

This issue can be resolved 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, 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.

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 illegit 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 the 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.

Key and Certificate Management

Key Management

As data encryption and protection has grown dramatically during the recent digital era, there is a large increase 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 the 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.

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 applications operating over a network, e.g. client server connection.

When we talk about SSL/TLS, most likely we are referring to TLS.

SSL has been around for about 25 years and TLS is actually a new version of SSL. When IETF adopted SSL, it is renamed to TLS.

Diagram: SSL/TLS (Secure Socket Layer / Transport Layer Security)

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.