PKI and Key Management

P-K-I and key management. The previous lesson covered what cryptography does. This one covers the infrastructure that makes it trustworthy, and the part that most often fails.

The scene. An organisation is proud of using strong, modern encryption everywhere. Then you look closer: the private key for its main certificate is sitting in a shared folder several teams can read, a certificate that expired last month is still in use, and there is no process to revoke a key if it is exposed. The algorithm is excellent. Everything around the keys is broken, and that is where the security actually lives.

Public key infrastructure, P-K-I, is the system of certificates, authorities and processes that lets people trust that a public key really belongs to who it claims to. At its centre is the certificate authority, the C-A: a trusted third party that verifies an identity and issues a digital certificate binding that identity to a public key. You trust the certificate because you trust the C-A that signed it.

That makes the C-A a critical trust anchor. Trust flows from it. If a C-A is compromised, every certificate it issued becomes suspect, because the attacker could mint trusted certificates for identities they do not own.

And note what a C-A is not. It issues and vouches for certificates; it does not encrypt your data, and it does not, and must not, hold users’ private keys. Private keys stay with their owner, always.

The exam repeatedly checks that you know which key is used for which purpose, because the two asymmetric operations are mirror images. To encrypt for confidentiality, so only the recipient can read it, the sender encrypts with the recipient’s public key; only the recipient’s private key can decrypt. To sign for authenticity and non-repudiation, the sender signs with their own private key; anyone verifies with the sender’s public key.

So the rule of thumb: you sign with your private key; you encrypt to someone with their public key. Public keys are shareable and are used to send to someone or to verify them; private keys are secret and are used to read what was sent to you or to sign as yourself. Getting the key backwards is a classic wrong answer.

Now the lesson’s real point, and the scenario’s failure. Modern algorithms with adequate key lengths are not realistically broken by brute force. Cryptographic systems fail at key management: the generation, distribution, storage, rotation, revocation and destruction of keys.

So, the key lifecycle, where it actually fails. First, protect private keys, this is paramount. A private key anyone can copy, like the one in the shared folder, offers no real security however strong the algorithm.

Second, rotate them, replace keys periodically so a compromise has a limited window.

And third, revoke and expire: invalidate a compromised or superseded key, published through mechanisms like a revocation list so others stop trusting it, and handle expiry, because an expired certificate still in use is a control that has quietly lapsed. No revocation process, as in the scenario, means a stolen key stays trusted indefinitely.

So carry this away. Do not judge cryptographic security by algorithm strength; the algorithm is rarely the weak point, key management is, so protecting private keys and revoking compromised ones is what actually matters. And do not confuse the keys: you encrypt to a recipient with their public key, and sign with your own private key.