Chapitre 1 sur 8

Why PKI exists

The trust problem, the two jobs of cryptography, and the three questions a certificate answers.

Environ 10 minutes de lecture

À la fin de ce chapitre, vous saurez

  • Explain why a shared secret does not scale to the public internet
  • Distinguish symmetric encryption from public key cryptography
  • State the three questions a certificate answers and one it does not

01The problem: talking to a stranger

Imagine you want to buy a book from a shop you have never visited. You find the shop's web address, and your browser starts talking to a computer somewhere in the world. How does your browser know that the computer answering is the real bookshop, and not someone sitting in the middle pretending to be the shop?

That is the trust problem. On a local network you can walk over and check. On the internet there is no walking over: you only ever receive bytes, and bytes carry no identity by themselves. Every secure internet technology you will study exists to answer the question 'who is on the other end, and how sure am I?'

02Two jobs: secrecy and proof

Cryptography is used for two quite different jobs, and students often blur them together.

JobQuestion it answersTypical tool
ConfidentialityCan anyone else read this message?Symmetric encryption (AES)
AuthenticationWho created this message, and has it changed?Digital signatures (RSA, ECDSA)
IntegrityWas the message altered in transit?MACs, AES-GCM, signatures

Symmetric encryption uses one shared key: the same key locks and unlocks the box. It is fast and it is what actually protects your HTTPS traffic. Its weakness is distribution. If two people want a shared key, they first need a private channel to exchange it — and on the open internet they do not have one.

Public key cryptography solves that distribution problem by giving everyone a pair of keys: a public key you may publish anywhere, and a private key that never leaves your machine. Anyone can encrypt to your public key; only you can decrypt. Anyone can verify a signature made with your private key.

03What a certificate actually claims

A certificate is a signed statement from a certificate authority (CA). The statement is narrow: this public key belongs to this subject, and this CA vouches for it. Keeping the claim narrow prevents most confusion.

  • It proves a binding between a key and a name, under the rules the verifier applies
  • It proves the holder controlled the matching private key when the certificate was issued
  • It does not prove the holder is honest, or that their software is patched
  • It does not authorise anything. Authorisation is the application's decision, not the certificate's

If a certificate proved honesty, no bank would ever be breached. What it proves is far more limited, and far more useful: the party you are talking to holds the private key that matches the name you asked for.

04Who trusts whom

Trust does not live in the certificate. It lives in the verifier. Your browser ships with a store of root certificates from organisations it has decided to trust. If a certificate chain leads back to one of those roots, and the chain passes validation, the browser accepts the identity.

This has an important consequence: the same certificate can be trusted by one program and rejected by another. A browser may accept a site that a Java application rejects, because they use different trust stores. Many 'it works in my browser' incidents are exactly this.

À retenir

  • The internet has no built-in identity, so cryptography must supply one
  • Symmetric keys are fast but hard to distribute; public key cryptography solves distribution
  • A certificate is a CA's signed claim that a public key belongs to a subject — nothing more
  • Trust comes from the verifier's trust store, not from the certificate itself