PKI, encryption and the key management that decides whether any of it works

Objective 1.4 in this course covers cryptographic solutions — CompTIA's scope note for it uses public key infrastructure (PKI), encryption, obfuscation, hashing, digital signatures and blockchain. This lesson takes PKI, encryption and key management; hashing, signatures, obfuscation and blockchain are the next lesson.

Why this matters

Cryptography is one objective out of twenty-eight but it is examined far beyond its own domain: certificates appear in Domain 3's secure communication, key management appears in Domain 4's data protection, and downgrade attacks appear in Domain 2. Getting this lesson solid pays for itself repeatedly.

The exam does not ask you to do mathematics. It asks which tool fits a stated requirement, and what breaks when a key or a certificate is mishandled. That is a much smaller thing to learn than people fear, and it is mostly about being exact with vocabulary.

The lesson

Public and private keys, and what a certificate authority actually asserts

An asymmetric key pair is two mathematically related keys. What one encrypts, only the other decrypts. The public key is published; the private key never leaves the holder.

That gives two distinct operations, and confusing them is the single biggest source of lost marks here:

• Encrypt with the recipient's public key. Only the recipient's private key opens it. This gives confidentiality.
• Sign with your own private key. Anyone with your public key can verify it. This gives authenticity, integrity and non-repudiation — and no confidentiality at all, because the public key is public.

A certificate binds a public key to an identity. A certificate authority (CA) is a third party that vouches for that binding: it has checked, by some process, that the key belongs to the named subject, and it signs the certificate with its own private key to say so.

Be precise about what the CA asserts. For a common domain-validated web certificate, it asserts control of the domain name — nothing about the organisation behind it, and nothing about whether the site is trustworthy. An exam option claiming a certificate proves a site is safe is wrong.

Root of trust, intermediate CAs, CSRs, CRL and OCSP stapling

• The root of trust is the root CA certificate, self-signed, distributed with operating systems and browsers. Everything else chains to it. Its private key is the crown jewel of the whole system and is normally kept offline.
• Intermediate CAs sit between root and end entity. They exist so the root key can stay offline and so that a compromise can be contained by revoking one intermediate instead of replacing the root everywhere on earth.
• A certificate signing request (CSR) is what you send to the CA: your public key plus the identity details you want certified, signed with your own private key to prove you hold it. The private key never goes in the CSR.
• A certificate revocation list (CRL) is a periodically published list of certificates revoked before their expiry. Its weakness is freshness — a client may be working from a list hours old.
• OCSP asks the CA about one certificate in real time. Its weakness is privacy and availability: the CA learns which sites you visit, and if OCSP is unreachable the client must decide whether to fail open or closed.
• OCSP stapling fixes both: the web server periodically fetches a signed, timestamped OCSP response and presents it during the handshake. The client gets fresh revocation status without contacting the CA at all.

Revocation reasons the exam names include key compromise, CA compromise, superseded, and cessation of operation.

Symmetric and asymmetric, key length, and where each is the right tool

Symmetric encryption uses one shared key for both directions. It is fast, suited to bulk data, and its problem is distribution: how do both ends get the key without anyone else obtaining it? AES is the example to know; key lengths of 128, 192 and 256 bits.

Asymmetric encryption uses the key pair above. It is far slower, unsuited to bulk data, and it solves distribution — you can publish a public key safely. RSA (2048 bits and up) and elliptic curve (ECC, much shorter keys for equivalent strength, which is why phones and IoT use it) are the examples.

Real systems use both, and this hybrid is worth being able to state: asymmetric crypto is used to agree or transport a symmetric session key, and the symmetric key then encrypts the actual traffic. TLS does exactly this.

Key length is only comparable within an algorithm family. A 256-bit AES key and a 256-bit ECC key and a 2048-bit RSA key are not on the same scale. Longer keys cost performance, and the exam's framing is a trade-off: strength against speed, particularly on constrained devices.

Key stretching deserves a line because it appears here: functions like PBKDF2, bcrypt and Argon2 deliberately make deriving a key from a password slow, so that guessing is expensive. You meet it again in password attacks in Domain 2.

Full-disk, partition, file, volume, database and record-level encryption

CompTIA wants you to match the level to the requirement.

• Full-disk encrypts everything including the OS. It protects against the device being stolen while powered off. It protects against nothing once the machine is booted and the user logged in — which is why "we have BitLocker" is not an answer to a malware question.
• Partition and volume encryption protect a subdivision, letting you encrypt the data volume and not the system one.
• File-level encryption protects individual files, and keeps protecting them when the file is copied off the disk — the property full-disk lacks.
• Database encryption protects the whole store, typically transparently to the application.
• Record- or field-level encryption protects individual rows or columns, so that a database administrator who can read the tables still cannot read the card numbers. This is the answer when the threat is a privileged insider.

The rule of thumb: the more granular the encryption, the more separation you get from people who legitimately have access to the layer beneath it.

Key escrow, TPM, HSM, secure enclave, and the key exchange problem they solve

Keys have to live somewhere, and where they live is what usually fails.

• A TPM is a chip on the motherboard of an individual machine. It stores keys, ties them to that hardware, and can attest to the boot state. It is what full-disk encryption on a laptop typically binds to, which is why the disk will not decrypt in another machine.
• An HSM is a dedicated, tamper-resistant appliance for an organisation. It generates and stores keys and performs operations without the key ever leaving it. That last property is the point: an application asks the HSM to sign something rather than asking for the key.
• A secure enclave is an isolated processor region — common on phones — that holds keys and biometric templates apart from the main OS.
• A key management system is the software that handles generation, rotation, distribution, retirement and auditing of keys at scale.
• Key escrow is holding a copy of a key with a trusted party so that data can be recovered if the key holder is gone. It is a business necessity and a security risk in one: escrow defeats non-repudiation, because someone else can now produce your signature.

The key exchange problem these exist around is the one from the symmetric section: getting a shared key to both ends safely. Diffie-Hellman solves it by letting both sides derive the same secret without ever transmitting it, and perfect forward secrecy is the property that a compromise of the long-term key does not expose past sessions, because each session used an ephemeral key that was thrown away.

What to take into the exam

• Encrypt with the recipient's public key for confidentiality; sign with your own private key for authenticity and non-repudiation.
• A CSR carries the public key and the identity. It never carries the private key.
• OCSP stapling: the server fetches the signed status and presents it, so the client never talks to the CA.
• Symmetric for bulk and speed, asymmetric for exchange and identity; real protocols use asymmetric to establish a symmetric session key.
• Full-disk protects a powered-off stolen device. File- and field-level encryption is the answer when the threat is someone who already has access to the layer below.
• The HSM's defining property is that the key never leaves it.