Public-Key Copy

Public key cryptography and PKIs Shortcomings of symmetric key Establishing a pairwise key requires a key exchange, which requires both parties K K to be online Issue #1: Requires pairwise key exchanges

File downloads Email / chat

One-to-many: All-to-all: O(N) key O(N2) key exchanges exchanges Shortcomings of symmetric key Establishing a pairwise key requires a key exchange, which requires both parties K K to be online Issue #2: Parties must be online

Blue user uploads a document, then goes File downloads ofﬂine (e.g., forever)

Later, a yellow user wants One-to-many: to get a copy; how can O(N) key it know the copy is really exchanges from the blue user? Shortcomings of symmetric key Establishing a pairwise key requires a key exchange, which requires both parties K K to be online Issue #3: How do you know to whom you’re talking?

Difﬁe-Hellman is resilient to eavesdropping, but not tampering

K K K1 K1 K2 K2 A protocol that solves this with trust

Trent: A trusted third party

Alice Bob A protocol that solves this with trust

Trent: A trusted third party

KAT KBT Alice Bob

KAT KBT

1. Everybody establishes a pairwise key with Trent Good: O(N) key exchanges A protocol that solves this with trust

Trent: A trusted third party

KAT KBT Alice Bob

KAT KBT

1. Everybody establishes a pairwise key with Trent Good: O(N) key exchanges 2. Trent validates each user’s identity; includes in message Good: Authenticated communication A protocol that solves this with trust

Trent: A trusted third party

E(KAT, msg || to:Bob)

KAT KBT Alice Bob

KAT KBT

Trent: A trusted third party

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

KAT KBT Alice Bob

KAT KBT

Trent: A trusted third party

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

KAT KBT Alice Bob

KAT KBT

1. Everybody establishes a pairwise key with Trent Good: O(N) key exchanges 2. Trent validates each user’s identity; includes in message Good: Authenticated communication Bad: All messages get sent through Trent What are we trusting Trent not to do? Just as “secure” meant nothing without an attack model, “trusted” means nothing without a trust model

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

KAT KBT Alice Bob

KAT KBT What are we trusting Trent not to do? Just as “secure” meant nothing without an attack model, “trusted” means nothing without a trust model

(Oh wow, “msg”!)

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

KAT KBT Alice Bob

KAT KBT

1. Do not read messages What are we trusting Trent not to do? Just as “secure” meant nothing without an attack model, “trusted” means nothing without a trust model

E(KAT, msg || to:Bob) E(KBT, msg’ || from:Alice)

KAT KBT Alice Bob

KAT KBT

1. Do not read messages 2. Do not alter messages What are we trusting Trent not to do? Just as “secure” meant nothing without an attack model, “trusted” means nothing without a trust model

…nothing… E(KBT, msg’ || from:Alice)

KAT KBT Alice Bob

KAT KBT

1. Do not read messages 2. Do not alter messages 3. Do not forge messages What are we trusting Trent not to do? Just as “secure” meant nothing without an attack model, “trusted” means nothing without a trust model

E(KAT, msg || to:Bob) ….

KAT KBT Alice Bob

KAT KBT

1. Do not read messages 2. Do not alter messages 3. Do not forge messages 4. Do not go ofﬂine Public key encryption A public key encryption scheme comprises three algorithms

Key generation G This is a randomized algorithm • Inputs (nondeterministic output) • Source of randomness • Maximum key length L Difﬁcult to infer SK from PK • Outputs: a key pair Only one person should know SK; • PK = public key PK should be public to all • SK = secret key

PK and SK are intrinsically bound together: for a given PK, there is a single corresponding SK Example: RSA’s public keys are a pair: (exponent, modulus) Public key encryption A public key encryption scheme comprises three algorithms

Encryption E(PK, msg) This is a randomized algorithm • Inputs (vanilla RSA is deterministic; • Public key PK in practice, RSA-PKCS is used • Message msg of instead, which adds a nonce ﬁxed size to the message) • Outputs: a cipher text c same size as msg PK a.k.a. “Encryption key”

Anyone who knows Alice’s PK can encrypt a message to her… Public key encryption A public key encryption scheme comprises three algorithms

Decryption D(SK, c) This is a deterministic algorithm • Inputs Should always return the • Secret key SK original message • Cipher text c • Outputs: original msg

…but only Alice can decrypt that message Public key encryption A public key encryption scheme comprises three algorithms

Correctness Key generation G → PK = public key D(SK, E(PK, m)) = m → SK = secret key Security Encryption E(PK, m) → cipher text c E(PK, m) should appear random (small change to (PK,m) leads to large changes to c) Decryption D(SK, c) → original msg E() should approximate a one-way trapdoor function: cannot invert without access to SK Protocols with public key encryption Goal: deliver a conﬁdential message

Symmetric key

Email / chat

All-to-all: O(N2) key exchanges Protocols with public key encryption Goal: deliver a conﬁdential message

Symmetric key Generate public/private key pair (PK,SK) Email / chat Annouce PK publicly (on website, in newspaper, …)

All-to-all: O(N2) key exchanges Protocols with public key encryption Goal: deliver a conﬁdential message

Symmetric key Generate public/private key pair (PK,SK) Email / chat Annouce PK publicly (on website, in newspaper, …)

Obtain PK

Send c = E(PK, msg)

All-to-all: O(N2) key exchanges Protocols with public key encryption Goal: deliver a conﬁdential message

Symmetric key Generate public/private key pair (PK,SK) Email / chat Annouce PK publicly (on website, in newspaper, …)

Obtain PK

Send c = E(PK, msg)

All-to-all: O(N2) key Decrypt D(SK, c) = msg exchanges Protocols with public key encryption Goal: deliver a conﬁdential message

Symmetric key Generate public/private key pair (PK,SK) Email / chat Annouce PK publicly (on website, in newspaper, …)

Obtain PK

Send c = E(PK, msg)

All-to-all: O(N2) key Decrypt D(SK, c) = msg exchanges O(N) keys in total Overcoming ﬁxed message sizes

Encryption E(PK, msg) • Inputs • Public key PK Like block ciphers, • Message msg of but there are not ﬁxed size “modes” of public • Outputs: a cipher text c key encryption same size as msg Overcoming ﬁxed message sizes

Public key operations are slooooow! Overcoming ﬁxed message sizes

Public key operations are slooooow! Symmetric key operations are fast Hybrid encryption Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK

Obtain PK Generate symmetric key K

Compute cmsg = e(K, msg)

Compute cK = E(PK, K) Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK

Obtain PK Generate symmetric key K

Symm key Compute cmsg = e(K, msg)

Public key Compute cK = E(PK, K) Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK

Obtain PK Generate symmetric key K

Symm key Compute cmsg = e(K, msg)

Public key Compute cK = E(PK, K) Now throw away K Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK

Obtain PK Generate symmetric key K

Symm key Compute cmsg = e(K, msg)

Public key Compute cK = E(PK, K) Now throw away K

Send cK || cmsg Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK

Obtain PK Generate symmetric key K

Symm key Compute cmsg = e(K, msg)

Public key Compute cK = E(PK, K) Now throw away K

Send cK || cmsg

Decrypt D(SK, cK) = K

Decrypt d(K, cmsg) = msg Hybrid encryption

Generate public/private key pair (PK,SK); publicize PK

Obtain PK Generate symmetric key K

Symm key Compute cmsg = e(K, msg)

Public key Compute cK = E(PK, K) Now throw away K

Send cK || cmsg

Public key Decrypt D(SK, cK) = K

Decrypt d(K, cmsg) = msg Symm key Hybrid encryption

Obtain PK Generate symmetric key K

Compute cmsg = e(K, msg)

Compute cK = E(PK, K)

Send cK || cmsg

The easy key distribution of public key

The speed and arbitrary message length of symmetric key Protocols with public key cryptography Goal: determine from whom a message came

Symmetric key Ideally, a user (blue) could post a File downloads message (e.g., sensitive documents or a kernel update), and then go ofﬂine

And downloaders (yellow) could subsequently infer the message’s authenticity without having to have One-to-many: already established a pairwise O(N) key key with the publisher exchanges Digital signatures A digital signature scheme comprises two algorithms

Signing function Sgn(SK, m) • Inputs • Secret key SK • Fixed-length message • Outputs: a signature s Digital signatures A digital signature scheme comprises two algorithms

Signing function Sgn(SK, m) This is a randomized algorithm (nondeterministic output) • Inputs • Secret key SK • Fixed-length message • Outputs: a signature s Digital signatures A digital signature scheme comprises two algorithms

Signing function Sgn(SK, m) This is a randomized algorithm (nondeterministic output) • Inputs • Secret key SK SK a.k.a. “Signing key” • Fixed-length message • Outputs: a signature s Digital signatures A digital signature scheme comprises two algorithms

Signing function Sgn(SK, m) This is a randomized algorithm (nondeterministic output) • Inputs • Secret key SK SK a.k.a. “Signing key” • Fixed-length message Only one person can sign with • Outputs: a signature s a given (PK,SK) pair Digital signatures A digital signature scheme comprises two algorithms

Veriﬁcation function Vfy(PK, m, s) • Inputs • Public key PK • Message and signature • Outputs: Yes/No if valid (m,s) Digital signatures A digital signature scheme comprises two algorithms

Veriﬁcation function Vfy(PK, m, s) Deterministic algorithm • Inputs • Public key PK • Message and signature • Outputs: Yes/No if valid (m,s) Digital signatures A digital signature scheme comprises two algorithms

Veriﬁcation function Vfy(PK, m, s) Deterministic algorithm • Inputs • Public key PK Anyone with the PK • Message and signature can verify • Outputs: Yes/No if valid (m,s) Digital signatures A digital signature scheme comprises two algorithms

Signing Sgn(SK, m) Veriﬁcation Vfy(PK, m, s) → a signature s → Yes/No if valid (m,s)

Correctness Vfy(PK, m, Sgn(SK, m)) = Yes

Security Same as with MACs: even after a chosen plaintext attack, the attacker cannot demonstrate an existential forgery Protocols with digital signatures Goal: determine from whom a message came

Symmetric key Generate public/private File downloads key pair (PK,SK) Annouce PK publicly (on website, in newspaper, …)

One-to-many: O(N) key exchanges Protocols with digital signatures Goal: determine from whom a message came

Symmetric key Generate public/private File downloads key pair (PK,SK) Annouce PK publicly (on website, in newspaper, …)

Compute sig = Sgn(SK, msg)

One-to-many: O(N) key exchanges Protocols with digital signatures Goal: determine from whom a message came

Symmetric key Generate public/private File downloads key pair (PK,SK) Annouce PK publicly (on website, in newspaper, …)

Compute sig = Sgn(SK, msg)

Publish msg || sig One-to-many: O(N) key exchanges Protocols with digital signatures Goal: determine from whom a message came

Symmetric key Generate public/private File downloads key pair (PK,SK) Annouce PK publicly (on website, in newspaper, …)

Compute sig = Sgn(SK, msg)

Publish msg || sig One-to-many: can now go ofﬂine! O(N) key exchanges Protocols with digital signatures Goal: determine from whom a message came

Symmetric key Generate public/private File downloads key pair (PK,SK) Annouce PK publicly (on website, in newspaper, …)

Compute sig = Sgn(SK, msg)

Publish msg || sig One-to-many: can now go ofﬂine! O(N) key exchanges Obtain PK, msg || sig Vfy(PK, msg, sig) Digital signature properties Digital signature properties

Bob can prove that a message Authenticity signed by Alice is truly from Alice (even without a pairwise key) Digital signature properties

Bob can prove that a message Authenticity signed by Alice is truly from Alice (even without a pairwise key)

Bob can prove that no one has Integrity tampered with a signed message Digital signature properties

Bob can prove that a message Authenticity signed by Alice is truly from Alice (even without a pairwise key)

Bob can prove that no one has Integrity tampered with a signed message

Once Alice signs a message, she Non-repudiation cannot subsequently claim she did not sign that message Do handwritten signatures at the end of a letter have these properties?

Bob can prove that a message Authenticity signed by Alice is truly from Alice (even without a pairwise key)

Bob can prove that no one has Integrity tampered with a signed message

Once Alice signs a message, she Non-repudiation cannot subsequently claim she did not sign that message Do handwritten signatures at the end of a letter have these properties?

Would require unforgeable Authenticity handwritten signatures. This is the one property they sort of get

Bob can prove that no one has Integrity tampered with a signed message

Once Alice signs a message, she Non-repudiation cannot subsequently claim she did not sign that message Do handwritten signatures at the end of a letter have these properties?

Would require unforgeable Authenticity handwritten signatures. This is the one property they sort of get

Would require having a signature Integrity that depended on each part in the body of the letter

Once Alice signs a message, she Non-repudiation cannot subsequently claim she did not sign that message Do handwritten signatures at the end of a letter have these properties?

Would require unforgeable Authenticity handwritten signatures. This is the one property they sort of get

Would require having a signature Integrity that depended on each part in the body of the letter

Would require both of the above Non-repudiation (unforgeable signature that depends on each part of letter) Back to authentication

How can we know it was really who posted PK? Back to authentication

Generate public/private key How can we know it was pair (PK,SK); publicize PK really who posted PK? Back to authentication

Generate public/private key How can we know it was pair (PK,SK); publicize PK really who posted PK?

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

KAT KBT Alice Bob

KAT KBT Back to authentication

Generate public/private key How can we know it was pair (PK,SK); publicize PK really who posted PK?

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

KAT KBT Alice Bob

KAT KBT Can we achieve authentication without Trent in the middle of every message? Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

Alice

Bob Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

PKT Alice

Bob PKT Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

2. Alice generates a public/private PKT key pair and asks Trent to bind her Alice (PKA, SKA) PKA to her identity

Bob PKT Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

Trent vets Alice 2. Alice generates a public/private PKT key pair and asks Trent to bind her Alice (PKA, SKA) PKA to her identity

Bob PKT Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

Trent vets Alice 2. Alice generates a public/private PKT key pair and asks Trent to bind her Alice (PKA, SKA) PKA to her identity

3. Trent signs a message (with SKT):

“The owner of the secret key PKT Bob corresponding to PKA is Alice” Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

Trent vets Alice 2. Alice generates a public/private PKT key pair and asks Trent to bind her Alice (PKA, SKA) PKA to her identity

3. Trent signs a message (with SKT):

“The owner of the secret key PKT Bob corresponding to PKA is Alice” This message + sig = Certiﬁcate Authentication with public keys 1. Trent’s public key is widely Trent (PKT, SKT) disseminated (pre-installed in browsers/operating systems)

Trent vets Alice 2. Alice generates a public/private PKT key pair and asks Trent to bind her Alice (PKA, SKA) PKA to her identity

Alice = PKT 3. Trent signs a message (with SKT):

“The owner of the secret key PKT Bob corresponding to PKA is Alice” This message + sig = Certiﬁcate Authentication with public keys 4. Alice makes her certiﬁcate Trent (PKT, SKT) publicly available (or Bob simply asks for it)

PKT Alice (PKA, SKA) If Bob trusts Trent, then Bob trusts that he knows Alice = PKA Alice’s public key is PKA

Bob PKT Authentication with public keys 4. Alice makes her certiﬁcate Trent (PKT, SKT) publicly available (or Bob simply asks for it)

PKT Alice (PKA, SKA) If Bob trusts Trent, then Bob trusts that he knows Alice = PKA Alice’s public key is PKA

Bob PKT Alice = PKA Authentication with public keys 4. Alice makes her certiﬁcate Trent (PKT, SKT) publicly available (or Bob simply asks for it)

5. Bob veriﬁes the certiﬁcate using PKT PKT Alice (PKA, SKA) If Bob trusts Trent, then Bob trusts that he knows Alice = PKA Alice’s public key is PKA

Bob PKT Alice = PKA Authentication with public keys 4. Alice makes her certiﬁcate Trent (PKT, SKT) publicly available (or Bob simply asks for it)

5. Bob veriﬁes the certiﬁcate using PKT PKT Alice (PKA, SKA) If Bob trusts Trent, then Bob trusts that he knows Alice = PKA Alice’s public key is PKA

6. Bob (via hybrid encryption) PKT Bob sends a message to Alice Alice = PKA using her public key PKA Authentication with public keys

Trent (PKT, SKT) Properties

Trent vets Alice

PKT Alice (PKA, SKA)

Alice = PKA

Bob PKT Alice = PKA Authentication with public keys

Trent (PKT, SKT) Properties

Trent need be online only Trent vets Alice when giving out certiﬁcates, not any time users want to PKT communicate with one another Alice (PKA, SKA)

Alice = PKA

Bob PKT Alice = PKA Authentication with public keys

Trent (PKT, SKT) Properties

Trent need be online only Trent vets Alice when giving out certiﬁcates, not any time users want to PKT communicate with one another Alice (PKA, SKA)

Alice = PKA Communication needn’t go through Trent

Bob PKT Alice = PKA Authentication with public keys

Trust assumptions from our Trent (PKT, SKT) symmetric key protocol: 1. Do not read messages Trent vets Alice 2. Do not alter messages 3. Do not forge messages PKT 4. Do not go ofﬂine Alice (PKA, SKA)

Alice = PKA

Bob PKT Alice = PKA Authentication with public keys

Alice = PKA Trust assumptions in this public key protocol: 1. Correctly vet users Bob PKT (Some more in practice…) Alice = PKA Certiﬁcate revocation

3. Trent signs a message (with SKT):

“The owner of the secret key corresponding to PKA is Alice” This message + sig = Certiﬁcate

Put another way: “The only person who knows SKA is Alice”

What happens if Alice’s key gets compromised? (Stolen, accidentally revealed, …) Certiﬁcate revocation

Trent (PKT, SKT) Please revoke my certiﬁcate (ID #3912…)

Alice Certiﬁcate revocation

Trent (PKT, SKT) Please revoke Trent signs a message (with SKT): my certificate (ID #3912…) “Certificate ID #3912… is no longer valid, as of April 5, …” Alice Certificate revocation

Trent (PKT, SKT) Please revoke Trent signs a message (with SKT): my certificate (ID #3912…) “Certificate ID #3912… is no longer valid, as of April 5, …” Alice This message + sig = revocation Certificate revocation

Bob obtains revocation information Bob Obtaining revocation data Certiﬁcate Revocation Lists (CRLs)

A (often large) signed list of revocations

“Certiﬁcate ID #3912… is Trent no longer valid, as of April 5, …” Obtaining revocation data Certiﬁcate Revocation Lists (CRLs)

A (often large) signed list of revocations

“Certiﬁcate ID #3912… is Trent no longer valid, as of April 5, …”

Browsers and OSes occasionally download CRLs

Bob Obtaining revocation data Certiﬁcate Revocation Lists (CRLs)

A (often large) signed list of revocations

“Certiﬁcate ID #3912… is Trent no longer valid, as of April 5, …”

Browsers and OSes occasionally download CRLs

Disincentive: CRLs can be large, Bob so it takes time & bandwidth Obtaining revocation data Certiﬁcate Revocation Lists (CRLs)

A (often large) signed list of revocations

“Certiﬁcate ID #3912… is Trent no longer valid, as of April 5, …”

Browsers and OSes occasionally download CRLs

Disincentive: CRLs can be large, Bob so it takes time & bandwidth

Result: delayed days/weeks/forever Obtaining revocation data Online Certiﬁcate Status Protocol (OCSP)

Browsers and OSes perform OCSP checks on-demand (when verifying the certiﬁcate)

Bob Trent Obtaining revocation data Online Certiﬁcate Status Protocol (OCSP)

Browsers and OSes perform OCSP checks on-demand (when verifying the certiﬁcate)

Is certiﬁcate ID #3912… still valid? Bob Trent Obtaining revocation data Online Certiﬁcate Status Protocol (OCSP)

Browsers and OSes perform OCSP checks on-demand (when verifying the certiﬁcate)

Is certiﬁcate ID #3912… still valid? Bob Trent

“Certiﬁcate ID #3912… is still longer valid, as of April 5, …” SKT Obtaining revocation data Online Certiﬁcate Status Protocol (OCSP)

Browsers and OSes perform OCSP checks on-demand (when verifying the certiﬁcate)

Is certiﬁcate ID #3912… still valid? Bob Trent

“Certiﬁcate ID #3912… is still longer valid, as of April 5, …” SKT

Disincentive: Still delays the initial validation of the certiﬁcate (can increase webpage load time) Obtaining revocation data OCSP Stapling

Websites issue OCSP requests, include responses in initial handshake

Is certiﬁcate ID #3912… still valid? Alice Trent

“Certificate ID #3912… is still longer valid, as of April 5, …” SKT Alice forwards this to Bob along with the certificate when they first start to communicate Certificate revocation responsibilities

Alice’s responsibility: Request revocations

Trent’s responsibility: Make revocations publicly available

Bob’s responsibility: Check for revocations Certificates in the wild The lock icon indicates that the browser was able to authenticate the other end, i.e., validate its certificate Certificate chain

Subject (who owns the public key)

Common name: the URL of the subject

Issuer (who verified the identity and signed this certificate) Verifying certificates

Browser Certificate “I’m because says so” Verifying certiﬁcates

Browser Certificate “I’m because says so”