Secure channels, identities, and key management

Prerequisites: Public-key cryptography and networking.

Learning objectives

• Describe channel authentication.
• Explain certificate-name validation.
• Plan key rotation and compromise response.

Encryption needs an authenticated peer

A secure channel aims to protect confidentiality and integrity between endpoints while authenticating the relevant peer identity. If a client encrypts to an attacker's key because it failed to authenticate the server, strong encryption faithfully protects the wrong conversation.

In a typical HTTPS connection, certificate validation checks a chain to a trusted authority, validity conditions, and whether the certificate covers the requested hostname. The exact protocol and platform rules matter. Disabling verification to make a connection succeed removes the identity guarantee the application depends on.

TLS protects bytes between its endpoints. If a reverse proxy terminates TLS, the next hop is a separate channel with its own requirements. It does not establish that the server's application is honest, that stored data is encrypted, or that a response contains correct facts.

Trace a name mismatch

A client intends to contact notes.example. It receives a certificate valid for files.example from a legitimate certificate authority. A valid signature chain alone is insufficient: the identity does not match the intended hostname. Accepting the certificate would let a credential for one name impersonate another.

This is a general rule: bind cryptographic evidence to the operation's context. A valid signature over an old software release does not by itself establish that installing that release now is acceptable. A signed message for one purpose should not silently authorize another.

Keys have a lifecycle

Generate keys with an appropriate cryptographic random source. Store them in a protection boundary suited to their value, restrict access, avoid logging them, and monitor use. Rotation requires deploying a new key, allowing a deliberate overlap where needed, updating verifiers, and retiring the old key. Deleting a local file does not remove copies from backups or compromised systems.

Forward secrecy, when provided by the negotiated protocol and key exchange, limits what later compromise of a long-term authentication key reveals about previously recorded sessions. It does not protect plaintext stolen from an endpoint while the session is active.

Plan for compromise before it happens. Know which data and signatures depend on a key, how to revoke or replace trust, and how clients will receive the change. A secret shared across many unrelated services expands the impact of one leak. Separate purposes and environments where the operational cost is justified.

Operational correctness is part of cryptographic correctness. An excellent primitive with a hard-coded shared key, permissive verification, or an untested rotation path does not deliver the system property its name suggests.

Practice problem

A service rotates its signing key from K1 to K2. Some clients are offline for a week. Describe a rollout that avoids both immediate breakage and indefinite trust in K1, then state what changes if K1 is known to be compromised.

Worked solution

Publish an authenticated trust update that introduces K2, define a bounded overlap during which appropriate artifacts under K1 remain acceptable, begin signing new artifacts with K2, and retire K1 according to an explicit version or time policy. Clients need a reliable way to learn current trust state, and offline behavior must be specified. If K1 is compromised, signatures under it cannot simply be treated as trustworthy during a convenience overlap. The recovery path needs an independent trusted mechanism or previously established recovery authority, plus revocation and an assessment of potentially forged artifacts.

Check your understanding

A trusted certificate chain for the wrong hostname is sufficient because encryption works.

• True for all HTTPS.
• True if the certificate is recent.
• False; the authenticated name must match the intended peer.
• True if the response is JSON.

Explanation

Peer authentication includes the identity the client intended to contact.

What does TLS termination at a proxy imply?

• The proxy-to-backend connection is a separate protection boundary.
• Stored data is automatically encrypted.
• The application cannot have injection bugs.
• Every client is authenticated as an account.

Explanation

The protected channel ends at the terminating endpoint.

Primary reading

• Computer Security textbook: UC Berkeley CS 161

Open the study and save your work →