13.2 Asymmetric Crypto & PKI

Symmetric encryption needs a shared secret before it can protect data. Asymmetric cryptography — also called public-key cryptography — solves a different problem: how two parties who have never met can still authenticate each other, exchange a secret safely, or prove authorship of a message. This section covers key pairs, common RSA-oriented use cases at exam depth, and PKI (Public Key Infrastructure) — the certificate and Certificate Authority system that makes public keys trustworthy on real networks.

Public and Private Keys

An asymmetric algorithm generates a mathematically linked key pair:

• The public key can be distributed openly (posted on a website, embedded in a certificate, emailed without secrecy).
• The private key must stay under the owner’s exclusive control.

Operations come in complementary pairs:

• Encryption for confidentiality (small payloads): Anyone can encrypt with the recipient’s public key; only the holder of the matching private key can decrypt. This is useful for wrapping a short secret (such as an AES session key), not for encrypting multi-gigabyte files directly — public-key math is comparatively slow and constrained.
• Digital signatures for authenticity and integrity: The signer applies their private key to create a signature over a message (typically over a hash of the message). Anyone can verify with the signer’s public key. A valid signature shows the private-key holder authorized that exact content (assuming the private key was not stolen).

If the private key leaks, an attacker can decrypt messages meant for the victim and forge signatures as that victim. Protecting private keys (permissions, hardware tokens, HSMs, passphrases) is therefore as critical as protecting AES keys — with the extra risk that a single long-lived private key may be used for identity across many sessions.

RSA and Practical Use Cases

RSA is a widely taught public-key algorithm historically used for encryption of small secrets and for digital signatures. For Cyber Test purposes, focus on roles, not modular exponentiation:

• Key exchange / secret wrapping: Encrypt a randomly generated AES session key under the recipient’s public key so only that recipient can unwrap it.
• Authentication via signatures: Prove possession of a private key during a handshake or when signing software/packages.
• Certificates: CAs use their private keys to sign certificates that attest to other parties’ public keys.

Modern Internet security also uses other public-key and key-agreement algorithms (for example elliptic-curve schemes). The exam-relevant abstraction stays the same: asymmetric tools establish trust and short secrets; symmetric tools protect bulk data.

What asymmetric crypto alone does not magically solve: it does not prove that a raw public key file emailed to you actually belongs to the bank, the Air Force portal, or your commander — unless you have an independent way to bind that key to an identity. That binding is the job of certificates and PKI.

Certificates: Binding Identity to a Public Key

A digital certificate (commonly an X.509 certificate in TLS) is a structured document that typically includes:

• The subject’s identity information (for example a DNS name like login.example.mil or an organization name).
• The subject’s public key.
• Validity dates.
• The issuer (who vouches for this binding).
• A digital signature created by the issuer’s private key.

When your browser or OS validates a server certificate, it is checking: “Did a trusted authority sign a statement that this public key belongs to this name, and is the certificate still within its validity window and not revoked (where revocation checking applies)?” If validation succeeds, you can use that public key to establish a secure channel with higher confidence that you are talking to the intended host — not an impostor who simply generated their own key pair.

Certificates do not contain the subject’s private key. The private key stays on the server or user’s device. Anyone can download the certificate; only the legitimate owner should hold the matching private key.

Certificate Authorities and the Trust Chain

A Certificate Authority (CA) is an organization (or internal enterprise service) trusted to verify identities and issue certificates. PKI usually works as a chain of trust:

1. Root CA certificates are embedded or carefully installed in trust stores (operating systems, browsers, enterprise-managed device images). You trust the root by administrative decision, not because some other CA signed it in the everyday browsing case (self-signed roots are trust anchors).
2. Intermediate CA certificates are signed by a root (or by another intermediate). Enterprises and public CAs use intermediates so the root private key can stay offline.
3. End-entity (leaf) certificates — the ones presented by websites, VPN gateways, or users — are signed by an intermediate.

Validation walks the chain: leaf → intermediate(s) → trusted root. If any link fails (wrong signature, expired cert, name mismatch, untrusted root), the client should reject the connection. That is why installing a malicious root CA on a machine is catastrophic: the attacker can issue fake certificates for any site and your trust store will accept them.

PKI is the broader system of policies, CAs, certificates, registration practices, and revocation mechanisms (such as CRLs or OCSP in many environments) that keep this trust usable at scale. You do not need every RFC detail for the Cyber Test; you do need the mental model: trust anchors → signed certificates → bound public keys → secure use of those keys.

Putting It Together With Symmetric Crypto

A typical HTTPS-style flow (simplified for learning):

1. Client connects; server presents its certificate chain.
2. Client validates the chain to a trusted root and checks the hostname.
3. Client and server perform a handshake that authenticates the server (and sometimes the client) using asymmetric cryptography / key agreement.
4. They derive or exchange a symmetric session key.
5. Application data is protected with AES (or another symmetric AEAD cipher) for the rest of the session.

That hybrid pattern answers a common exam trap: “If RSA is so important, why is AES everywhere?” Because asymmetric operations are expensive and awkward for bulk data, while AES is fast — once PKI and the handshake have established whom you trust and what session key to use.

Operational Pitfalls Worth Remembering

• Self-signed certificates can encrypt traffic but do not provide third-party identity assurance unless the client explicitly trusts that specific certificate.
• Expired or mismatched names should fail validation even if the cryptography is otherwise correct.
• Private key theft lets an attacker impersonate the certificate subject until the certificate is revoked and clients honor revocation (or until the cert expires and is replaced).
• Internal PKI in military and enterprise networks often uses organization-run CAs with roots pushed by device management — same chain logic, different trust anchors.

Master the vocabulary triad — key pair, certificate, CA trust chain — and you can reason through most asymmetric/PKI questions without algorithm internals.