9.5 PKI & Cryptographic Applications

From Primitives to Infrastructure

Section 9.4 covered the building blocks. Public Key Infrastructure (PKI) is the system of policies, certificates, and authorities that makes asymmetric cryptography usable at scale by answering one question: can I trust that this public key really belongs to this identity? Without PKI, an attacker could simply publish their own public key claiming to be your bank.

Digital Signatures

A digital signature proves authenticity and integrity. The signer hashes the message and encrypts the hash with their private key; anyone can verify it by decrypting the signature with the signer's public key and comparing the result to a freshly computed hash.

A digital signature provides:

• Integrity — any change to the message breaks verification (the hashes no longer match).
• Authentication — only the private-key holder could have produced it.
• Non-repudiation — the signer cannot credibly deny signing, because only they hold the private key.

Note the directions carefully, a frequent trap: signing uses the sender's private key (only you can sign); encrypting for confidentiality uses the recipient's public key (only they can decrypt). Signatures do not provide confidentiality on their own.

Digital Certificates and the CA Hierarchy

A digital certificate, formatted as X.509, binds an identity (such as a domain name) to a public key, along with validity dates and the issuer. It is issued and digitally signed by a trusted Certificate Authority (CA).

PKI uses a tiered trust chain:

• Root CA — the trust anchor; its key is kept offline and highly protected. Its certificate is self-signed and pre-installed in OS/browser trust stores.
• Intermediate CA — signed by the root, used to issue certificates day-to-day so the root key stays offline and protected.
• End-entity (leaf) certificate — issued to a server, user, or device.

Clients validate the chain of trust from the end-entity certificate up through any intermediates to a trusted root. A Registration Authority (RA) may verify identity before the CA issues. The CA can also publish via a public/trusted hierarchy or, in private deployments, run an internal enterprise CA.

Certificate Revocation

Certificates can be invalidated before expiry (key compromise, employee departure). Clients check status via:

• CRL (Certificate Revocation List) — a periodically published list of revoked serial numbers.
• OCSP (Online Certificate Status Protocol) — a real-time query to the CA for one certificate's status; OCSP stapling lets the server present a signed, time-stamped status to avoid a client round-trip.

The TLS Handshake (Concept)

Transport Layer Security (TLS) — the successor to the deprecated SSL — secures data in transit (HTTPS). Conceptually the handshake proceeds: (1) the client and server agree on protocol version and cipher suite; (2) the server presents its certificate; (3) the client validates the certificate chain to a trusted root and checks revocation; (4) the parties perform an authenticated key exchange (commonly ephemeral Elliptic-Curve Diffie-Hellman, ECDHE) to derive a fresh symmetric session key; (5) the session continues using fast symmetric encryption.

This is the hybrid model in action: asymmetric crypto authenticates the server and establishes the key, symmetric crypto protects the bulk traffic, and ephemeral keys provide forward secrecy — compromising the server's long-term private key later cannot decrypt previously recorded sessions. Modern guidance is TLS 1.2/1.3 only; SSL 2/3 and TLS 1.0/1.1 are deprecated and vulnerable (e.g., POODLE, BEAST) and should be disabled to prevent downgrade attacks.

S/MIME and Email/Code Security

• S/MIME (Secure/Multipurpose Internet Mail Extensions) uses X.509 certificates to sign and encrypt email, giving confidentiality, integrity, authentication, and non-repudiation. PGP/GPG is an alternative web-of-trust model that does not rely on a central CA hierarchy.
• Code signing uses a developer's certificate to sign software, proving origin and that the binary was not tampered with after release.

Disk and File Encryption (Data at Rest)

• Full-disk encryption (FDE) — such as BitLocker (Windows), FileVault (macOS), or LUKS (Linux) — transparently encrypts an entire volume so a lost or stolen device's data stays confidential; it commonly anchors keys in a Trusted Platform Module (TPM).
• File/folder encryption — such as EFS — protects selected data and supports per-recipient access, useful when only some files are sensitive.

FDE protects against physical theft of a powered-off device; it does not protect data once the OS is unlocked and running, which is why it complements, not replaces, access controls and in-transit encryption.

Certificate Types and Trust Models

Not all certificates are equal. CAs issue Domain Validation (DV) certificates (prove control of the domain only), Organization Validation (OV), and Extended Validation (EV) (rigorous vetting of the legal entity). com`) secures many subdomains, while a Subject Alternative Name (SAN) certificate lists several explicit hostnames. A self-signed certificate has no CA vouching for it, so clients do not trust it by default — useful only for internal/testing use. Certificate pinning hardens a client by accepting only a specific known certificate or public key, blocking a fraudulently issued one.

Certificate Transparency (CT) logs publicly record issued certificates so mis-issuance can be detected.

Key Escrow, HSMs, and Common PKI Pitfalls

Key escrow stores a copy of private keys with a trusted party so encrypted data can be recovered if a key is lost — convenient but a single point of compromise. High-value CA and signing keys live in a Hardware Security Module (HSM), a tamper-resistant device that performs crypto without exporting the key.

Classic exam pitfalls: a CA private-key compromise undermines every certificate it signed (why root keys stay offline); an expired or untrusted certificate breaks the chain and triggers browser warnings; and accepting a certificate whose name does not match the host enables man-in-the-middle. PKI's security ultimately rests on protecting private keys and on clients faithfully validating the chain and revocation status.