Digital Signatures & Certificates, PKI & Key Management in CISSP Domain 3: A Deep Dive

Introduction

Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to digital certificates, digital signatures, Public Key Infrastructures and key management in Domain 3, to understand how they interrelate, and to guide your studies.

This is the seventh of 9 videos for domain 3. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.

In the last video, video 6 in domain 3, we started our voyage through the wonders of cryptography. Lets now delve a little deeper in what cryptography enables us to do with digital signatures and digital certificates, how we can establish trust on an untrusted network like the internet via Public Key Infrastructures, and how we must carefully manage encryption keys.

Digital Signatures

Integrity

Authenticity

Non-repudiation

And Non-repudiation means someone cannot deny the validity of something. There are two scenarios in which we can achieve non-repudiation with digital signatures.

Origin

Authenticity means we can confirm who something came from, we can for instance verify that a message came from a particular sender

Non-Repudiation

Non-repudiation of origin means the sender cannot deny that they sent exactly the message that was received

Delivery

And Non-repudiation of delivery means the receiver cannot deny that they received a specific message

Digital Certificates

Now on to Digital Certificates. Digital certificates are used to verify the owner of a public key. You often need someone’s public key to securely communicate with them and they need yours. You could just exchange public keys across the internet. You could send me your public key, but anyone could intercept and modify the keys, or more likely, swap out your key for theirs. And the major problem is I would have no idea this happened. I would have no idea that the key I received actually belongs to some sketchy character out there on the internet and not you. This is a major problem.

You cannot, for instance, securely communicate with your online bank unless you know you have your bank's public key.

Verify the owner of a Public Key

X.509

Digital certificates can be created by loads of different organizations:

• You can get a digital certificate from one of the big Certificate Authorities such as Comodo, Symantec, Digicert or Entrust, and everyone in the world will trust that certificate
• You can get a digital certificate from say your company, and that certificate will only be trusted within your company
• You can even create your own self-signed certificate that no one, but you, will trust

Because certificates can be created by so many different entities in so many different situations, we need a standard to make sure all these certificates are interoperable. That standard is X.509.

Replacement

Certificate Authorities will typically issue a certificate that is valid for one to two years. An expiry date will be noted in the digital certificate itself and when that expiry date has been reached, or just before it, a new digital certificate will need to be created. This is replacement. The regular replacement of expired certificates.

And you can easily see when a certificate needs to be replaced based on the expiry date noted in a Digital Certificate itself.

Revocation

Revocation is an entirely different matter. Digital Certificates contain a copy of a public key. A public key is one key in a key pair – the other key being the associated PRIVATE key. The public key can be shared with anyone and everyone. The associated private key MUST remain private. If the associated private key is compromised, you can never trust any communications from that entity. This is where certificate revocation comes into play.

If for instance your private key has been compromised, then you need to immediately tell everyone not to trust your associated public key. The way you do this is by contacting your certificate authority and asking them to revoke your digital certificate. The CA maintains a list of all the revoked certificates. Before you trust the public key in any digital certificate you should first check with the CA to see if the certificate has been revoked. If the certificate has been revoked, then you should absolutely not trust the public key contained within it.

How do you check with a CA to see if a certificate has been revoked? Or more specifically, how would the software you use, like your web browser, check for you? There are two protocols.

CRL

OCSP

OCSP - Online Certificate Status Protocol is a much newer and more efficient protocol. The Client queries the CA for the revocation status of a specific certificate and the CA responds: it’s been revoked you should run screaming OR nope all good, live long and prosper.

I may have just taken some comedic license there with exactly how the CA responds to OCSP queries

Pinning

PKI

All right let's now talk about how we create the whole infrastructure that allows us to trust users and systems across an entirely untrustworthy environment like the internet.

Public Key Infrastructures is the broad set of the roles, policies, procedures, hardware, and software that is used to create, distribute, use, store, replace and revoke digital certificates – and we do all this so that we can use digital certificates to bind a public key to its owner and trust who or what we are communicating with.

Certificate Authority (Root of Trust)

All the trust in a PKI is ultimately rooted in the certificate authority, which is why the CA is often referred to as the Root of Trust. The CA uses its private key to encrypt some data including the name of the owner and their public key to create a digital certificate. Because the CA is the only entity in the world that has their private key, no one can modify the certificates the CA creates or create spoofed certificates that look like they come from the CA but didn’t.

And on the flip side, anyone can decrypt a digital certificate that has been created by one of the big public CAs because everyone has their public key. How do we all have the big CAs public keys? They come pre-installed in our browsers, like Firefox, Chrome or Safari.

Registration Authority

Before a CA will create a digital certificate for you, they first need to proof your identity, to confirm you are who you say you are.

The role within the CA that performs the identity proofing is known as the RA – the Registration Authority.

Intermediate / Issuing CA

Now I mentioned that the Certificate Authority creates a digital certificate by encrypting a bit of data including the name of the owner and their public key with the CAs private key. That is an oversimplification and in fact a bad idea. If the CA was encrypting new certificates using its private key that would mean that private key would have to be on a system that is online – connected to the wildly untrustworthy internet.

And if the CAs private key is ever compromised this whole entire system goes up in flames. No one can trust anyone. It is the end of the world! Okay yes, that is a bit overly dramatic, but it is REALLY bad if the CA’s private key is compromised. You can’t trust any digital certificate the CA has ever issued and therefore you can’t trust a whole lot of entities.

To avoid this major risk, of the CAs private key being stolen, the private key is in a system that is offline, air gapped, not connected to the internet, in a giant vault, within another vault, surrounded by hungry dogs, underneath a mount, in an undisclosed location.

Alright so if the root private key is offline how do certificates get signed and created? The CA’s private key is used to sign intermediate certificates, which can then be used to sign issuing certificates, and those issuing certificates can then be used to sign entity certificates- the certificates that we pay a CA to make for us.

This is often referred to as the chain of trust. You can follow the chain of trust back up to verify that ultimately it was the CAs private key that was used to sign the first certificate in the chain.

So if you get a question asking you which role in the CA issues certificates, the perfect answer is the Issuing CA.

Certificate DB (Revocation List)

The CA needs to maintain a list of all the certificates they have ever issued and which have been revoked. This data is stored in the Certificate DB. Each CA maintains their own Certificate DB.

Certificate Store (Local)

End-point systems, like our desktops, laptops and mobile phones, need to securely store our private keys and any other keys and certificates we might need – like the big CAs public keys. The Certificate Store is the local secure storage place for all such keys. Every end-point device will have its own little certificate store.

Key Management

Lets now talk in a little more detail about keys, and why we need to put so much focus and effort into key management. There is an expression I like: the hardest part of security is cryptography and the hardest part of cryptography is key management. Why is key management so critically important?

Kerchhoff’s Principle

Our guy Kerckhoffs summed it up nicely in 1883 with his principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. An attacker can know the algorithm being used, the initialization vector, can have access to the ciphertext – the attacker can know all of this and the information will remain secure so long as the key is kept secret.

This obviously implies that we need to do a very good and very secure job of generating keys, distributing keys, storing keys, rotating keys, disposing of keys and even recovering keys.

So, let's talk through each of these key management activities.

Generation

Key generation or key creation is all about creating new symmetric or asymmetric key pairs. What is of critical importance is that each new key must be randomly selected out of the entire keyspace to avoid the plague of cryptography: patterns.

Distribution

Key distribution is focused on securely transmitting shiny new keys to whoever may need them and no one else.

Diffie-Hellman, Out-of-band, Hybrid

A few options to know about for key distribution: You could use the Diffie-Hellman key exchange protocol which uses asymmetric cryptographic techniques to generate the same key for two people without sending the key itself.

You could use out-of-band, which means sending the keys through some other communications channel. You could write out the key and post it in a letter, send it via carrier pigeon or perhaps just call someone and read them a string of 256 ones and zeroes. That’d be fun for everyone involved.

Or more realistically, and much more commonly used, you could use hybrid cryptography. You could encrypt the symmetric key that you need to send to say Alice, with Alice’s public key. You could then send this ciphertext over to Alice and only she could decrypt the ciphertext with her Private key.

We call this hybrid cryptography because you are distributing / sending a symmetric key using asymmetric cryptography, and then once the receiver has securely received the symmetric key you can switch over to symmetric cryptography to encrypt and decrypt lots of data quickly and efficiently. This is exactly how a super popular protocol like TLS works.

Storage

When keys have been created and or received they need to be stored in an extremely secure location. There are two pieces of hardware that are purpose built to securely store encryption keys.

TPM, HSM

Rotation

Disposition

Sometimes we need to securely destroy every single copy of a key. Defensibly destroy the encryption keys.

Why?

Crypto-shredding, Key Destruction

One reason we might want to destroy every single copy of a key is so that we can crypto-shred some data. The idea of crypto shredding is to securely destroy data by destroying the encryption keys used to encrypt the data. If all of the data you want to crypto shred has been encrypted with an excellent algorithm, like AES, and you then destroy every single copy of the key used to encrypt the data – then the data has been crypto shredded – rendered unrecoverable and essentially, therefore destroyed.

Sometimes we may need to recover a lost key, and there are a few different ways we can recover keys.

Split Knowledge, Dual Control, Key Escrow

Split Knowledge – split the knowledge of the key up amongst two or more people. In order to recover the key these folks need to get together and combine each of their bits of knowledge to recover the complete key.

Dual Control – two or more people need to perform some action to recover the key. I always think about how they launch a nuclear missile. Two people have to turn their own keys at the same time. Same sorta idea with dual control – in order to recover the key two people have to do something together to recover the key.

Key Escrow – a copy of the encryption key is stored, kept is escrow, with a trusted third party. If you need to recover the key you ask for a copy of the key stored with the trusted third party.

And that is an overview of Digital Certificates, Digital Signatures, PKI and Key Management within Domain 3, covering the most critical concepts you need to know for the exam.

Hey if you haven’t already taken our completely free MiniMasterClass on cryptography, you need to. You going learn a ton of important stuff that you need to know for the exam.

Link is in the description below. 

If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.

I will provide links to the other MindMap videos in the description below.

Thanks very much for watching! And all the best in your studies!