Security Protocols Key Establishment, Chapter 13 of Understanding - - PowerPoint PPT Presentation

Introduction to Cryptography

Security Protocols

Jim Royer October 9, 2018

Crypto ❖ Security Protocols 1

References

◮ ”Key Establishment,” Chapter 13 of Understanding Cryptography by Paar & Pelzl ◮ Wide Mouth Frog Protocol from Wikipedia

https://en.wikipedia.org/wiki/Wide_Mouth_Frog_protocol

◮ Explain like I’m 5: Kerberos by Lynn Root

http://www.roguelynn.com/words/explain-like-im-5-kerberos/

◮ Secure Electronic Transaction from Wikipedia

https://en.wikipedia.org/wiki/Secure_Electronic_Transaction

Crypto ❖ Security Protocols 2

Having PKC’s Does Not End Our Problems

How to distribute public keys? ◮ Bob can go to Alice’s web page for her

public keys. ◮ But how does he know it is really Alice. ◮ Key exchange/distribution needs to include authentication. ◮ Here is an example of the problem ...

Crypto ❖ Security Protocols 3

Recall: Diffie-Hellman Key Exchange

Alice & Bob want to exchange a ton of data using the nice & fast AES cryptosystem. But first they have to agree on a key.

Diffie-Hellman

Setup p, a large prime (Pub) and α, a prim. elem. of Z∗

p (Pub)

Alice Picks x

ran

∈ Z∗

p−1 (Priv.) and sends αx (mod p) to Bob

Bob Picks y

ran

∈ Z∗

p−1 (Priv.) and sends αy (mod p) to Alice

Alice Computes k = (αy)x = αxy (mod p). Bob Computes k = (αx)y = αxy (mod p). Eves Knows αx and αy, but wants αxy all (mod p).

Crypto ❖ Security Protocols 4

The Man-in-the-Middle Attack

Alice ← → Eve ← → Bob Eve Chooses z

ran

∈ Z∗

p−1.

Intercepts αx and αy. Sends αz to Alice and Bob. Eve computes kAE = (αx)z and kBE = (αy)z. Alice believes she has exchanged a key with Bob. Bob believes he has exchanged a key with Alice. Eve reads everything & sends whatever she wants, spoofing Alice & Bob. We need to fix this!!

Crypto ❖ Security Protocols 5

Key Establishment Schemes

There are roughly two sort of such schemes: ◮ Key agreement schemes (e.g., Diffie-Hellman) Parties jointly generate a secret key ◮ Key Transport Schemes (examples below) One party (Trent) generates & distributes secret keys. Trent = Trusted Authority One reason we want robust, low-overhead key establishment schemes is that we want session keys: keys that are good only for a very limited time (Why?)

Crypto ❖ Security Protocols 6

Station to Station (STS) Protocol

Use signatures & a trusted authority (Trent) to defend against MiM. (Diffie, van Oorshot, & Wiener). More details: https://en.wikipedia.org/wiki/Station-to-Station_protocol Setup Each user U has sigU — a signature algorithm verU — a verification algorithm (established by Trent) p, a prime α, a primitive element of Z∗

p

Alice Chooses x

ran

∈ Z∗

p−1 and computes αx (mod p).

Bob Chooses y

ran

∈ Z∗

p−1 and computes αy (mod p).

More...

Crypto ❖ Security Protocols 7

Station to Station, Continued

Alice Sends αx to Bob. Bob Computes k = (αx)y. Ek(·) & Dk(·) - say AES Sends αy and Ek(sigB(αy, αx)) to Alice. Alice Computes k = (αy)x. Decrypts Ek(sigB(αy, αx)) and obtains sigB(αy, αx). Asks Trent to verify that verB is Bob’s verification alg. Uses verB to verify Bob’s signature. Sends Ek(sigA(αx, αy)) to Bob. Bob Decrypts Ek(sigA(αx, αy)) & obtains sigA(αx, αy). Asks Trent to verify that verA is A’s verification alg. Uses verA to verify Alice’s sig.

Alice is assured that ◮ Bob can compute k (Why?) ◮ No one but A&B can compute k (Why?) Bob is assured that ◮ Alice can compute k (Why?) ◮ No one but A&B can compute k (Why?)

Crypto ❖ Security Protocols 8

Establishing Keys & Trusting the Result

Key Distribution

A TA (Trent) and n users + a secure channel between TA and each User TA sends K to n users securely.

Key Agreement

Two users + a public network The users interact to agree on a key K.

Key Pre-Distribution

TA and n users + a pub. network + a secure channel tween TA and each user For each pair of users U, V (U = V) The TA constructs a key KUV (= KVU) and sends it to U and V securely. ◮ (n

2) messages

too many! ◮ each user stores n − 1 keys too many!

Crypto ❖ Security Protocols 9

Blom’s Distribution Scheme

n =# of users p a prime > n keys ∈ Zp

TA Setup

The TA chooses p as above (public) and a, b, c

ran

∈ Zp (private). For each user U, the TA chooses rU ∈ Zp (public), with U=V = ⇒ rU = rV For each user U, the TA computes: aU = a + b · rU mod p bU = b + c · rU mod p (private) Sends aU and bU securely to U.

Setup for a user U

U constructs gU : x → (aU + bU · x).

When Alice & Bob want to communicate

Alice computes KAB = gA(rB) and Bob computes KBA = gB(rA). Claim: KAB = KBA. proof on board

Crypto ❖ Security Protocols 10

Blom’s Distribution Scheme

n =# of users p a prime > n keys ∈ Zp TA Setup The TA chooses p as above (public) and a, b, c

∈ Zp (private). For each user U, the TA chooses rU ∈ Zp (public), with U=V = ⇒ rU = rV For each user U, the TA computes: aU = a + b · rU mod p bU = b + c · rU mod p (private) Sends aU and bU securely to U. Setup for a user U U constructs gU : x → (aU + bU · x). When Alice & Bob want to communicate Alice computes KAB = gA(rB) and Bob computes KBA = gB(rA). Claim: KAB = KBA. proof on board

2018-10-09

Security Protocols Blom’s Distribution Scheme KAB ≡ gA(rB) ≡ aA + bA · rB ≡ (a + b · rA) + (b + c · rA) · rB ≡ a + b · (rA + rB) + c · rA · rB ≡ (a + b · rB) + (b + c · rB) · rA ≡ aB + bB · rA ≡ gB(rA) ≡ KBA

Breaking Blom’s Scheme: I

Eve wants to determine a, b, and c.

She knows: aE = a + b · rE bE = b + c · rE Two equations, three unknowns, no dice

Eve also wants to determine KAB.

She knows: KAB = a + b · (rA + rB) + c · (rA · rB) aE = a + b · rE bE = b + c · rE Three equations, four unknowns: a, b, c, and KAB. Fact: For every possible value of KAB, there is a solution for a, b, and c.

But what if Eve has a friend?

Crypto ❖ Security Protocols 11

Breaking Blom’s Scheme: II

Together Eve and Ocsar know: aE ≡ a + b · rE bE ≡ b + c · rE aO ≡ a + b · rO bO ≡ b + c · rO        (mod p) Four equations, three unknowns: a, b, and c. So, Eve and Oscar together can break the scheme. ◮ The scheme can be generalized to be secure against coalitions of k users — k a parameter. ◮ E.g., There is a version that is secure against coalitions of 15 users, but fails against a 16 user coalition.

Crypto ❖ Security Protocols 12

Transport Protocols

Alice chooses k and sends it to securely to Bob ...or Trent acts as a key server: Alice tells Trent she wants to talk to Bob. Trent issues a key to Alice and Bob for the session.

Shamir’s Three Pass Protocol — Here Trent = Alice

Alice Publishes a prime p (with a hard discrete log problem) Chooses a

ran

∈ Z∗

p−1.

Bob Chooses b

ran

∈ Z∗

p−1.

Alice Sends K1 = Ka mod p to Bob. Bob Sends K2 = Kb

1 mod p = Ka·b mod p to Alice.

Alice Sends K3 = Ka−1

2

mod p = Kb mod p to Bob. Bob Computes K = Kb−1

3

mod p. Man-in-the-middle problems!

Crypto ❖ Security Protocols 13

Authenticated Key Distributions, I

◮ Key pre-distribution schemes involve too much overhead to be practical. Typically, you want to refresh keys once every so often. ◮ An alternative is to have a trusted authority (our buddy Trent) issue new keys (securely) as needed. ◮ Authentication is a crucial issue. Eve can pretend to be Trent, Alice, Bob, ... ◮ Replay attacks

• Eve records a valid interaction.
• She repeats it later to pretend to be another party, or

to tease out some response to compromise a key.

• To protect against this, we need to keep keys etc. confidential

and guarantee each message is fresh (i.e., not a replay).

◮ For confidentiality ...initially shared keys ◮ For freshness: sequence numbers, timestamps, and nonces

Crypto ❖ Security Protocols 14

Authenticated Key Distributions, II

Sequence numbers Each message has a sequence number (i.e., “This is the 137th message I’ve sent you”) This entails lots of bookkeeping. Timestamps Each message has an expiration date. This requires a “global clock”. Nonces A challenge message issued only once. Requires a correct response for validity.

Crypto ❖ Security Protocols 15

The wide-mouthed frog protocol, 1

Alice wants to send a session key to Bob via Trent

Alice Picks KAB. Sends m0 = EKAT(tA||IdB||KAB) to Trent. tA = Alice’s timestamp IdB = Bob’s ID. Trent Receives & checks m0. Sends m1 = EKBT(tT||IdA||KAB) to Bob. tT = Trent’s timestamp IdA = Alice’s ID. ◮ Timestamp t: This key is good until time t. ◮ After time t, refresh the key. ◮ tT is a problem.

Crypto ❖ Security Protocols 16

The wide-mouthed frog protocol, 2

Alice wants to send a session key to Bob via Trent

Alice Picks KAB and sends m0 = EKAT(tA||IdB||KAB) to Trent. tA = Alice’s timestamp IdB = Bob’s ID. Trent Receives & checks m0. Sends m1 = EKBT(tT||IdA||KAB) to Bob. tT = Trent’s timestamp IdA = Alice’s ID.

Mallory wants Alice and Bob to use KAB indefinitely

Mallory Records the above exchange. Before time tT, sends Trent the replay: m1. Trent Receives m1 & thinks: Bob wants me to send Alice a key. Sends Alice m2 = EKAT(t′

T||IdB||KAB)

where t′

T > tT

Mallory Records the above and before time t′

T, sends Trent m2.

Trent Receives m2 & thinks: Alice wants me to send Bob a key. Sends Bob m3 = EKAT(t′′

T||IdB||KAB)

where t′′

T > t′ T

(Trent should never have replaced tT.)

Crypto ❖ Security Protocols 17

Needham-Schroeder Symmetric Key Protocol

Alice and Bob want a session key KS from Trent.

Alice Sends to Trent: IdA||IdB||nA nA is a random string. Trent Sends to Alice: EKAT(KS||IdB||nA||EKBT(KS||IdA)). nA makes sure the message is fresh. Alice Sends to Bob: EKBT(KS||IdA). Bob Sends to Alice: EKS(nB). nB, a random string & a challenge Alice Sends to Bob: EKS(nB − 1). Alice answers Bob’s challenge. Only Alice should know KS. The nB − 1 is to foil replays.

But if Mallory ever learns KS ...

Mallory Sends to Bob: EKBT(KS||IdA). a replay Bob Sends to Alice: EKS(n′

B).

Mallory Intercepts EKS(n′

B) and sends to Bob: EKS(n′ B − 1).

Bob Bob now thinks Mallory is Alice.

We can defend against this attack by adding timestamps or nonces, see:

https://en.wikipedia.org/wiki/Needham-Schroeder_protocol#Fixing_the_attack Crypto ❖ Security Protocols 18

Kerberos, I

Clients = users, processes Servers = gateways

Used in AIX, FreeBSD, Mac OS X, OpenVMS, Red Hat Linux, Solaris, Windows, . . .

The Dramatis Personæ

Cliff: a client Serge: a server Trent: a T.A. (authentication server) Grant: a ticket granting server

Before: Cliff and Serge share no secret data After: Serge will have verified Cliff’s ID and A session key (for Cliff and Serge) will have been established. Note: The following is all symmetric key cryptography!

Crypto ❖ Security Protocols 19

Kerberos, II

Trent

✫✪ ✬✩

Grant

✫✪ ✬✩

Cliff

✫✪ ✬✩

Serge

✫✪ ✬✩ ❪

1

❫

2

✸

3

✰

4

❄

5 [Copy onto board]

Crypto ❖ Security Protocols 20

Kerberos, III

1: Cliff → Trent

Requests ticket to ticket-granting server. Cliff supplies his name and Grant’s name.

2: Trent → Cliff

Checks: that Cliff is O.K. Generates KCG. Constructs T =def eKC(KCG) KC = Cliff’s secret key Constructs TGT =def Grant’s ID ||eKG(Cliff’s ID, timestamp1, KCG) Sends Cliff: T and TGT. TGT = ticket granting ticket

3: Cliff → Grant

Decrypts T to obtain KCG. Constructs AuthCG =def eKCG(Cliff’s ID,timestamp2). Sends to Grant: TGT and AuthCG.

Crypto ❖ Security Protocols 21

Kerberos, IV

4: Grant → Cliff

Grant decrypts TGT and obtains: Cliff’s ID, KCG, and timestamp1. Decrypts AuthCG and obtains: Cliff’s ID and timestamp2. Checks that the two versions of Cliff’s ID match. Checks that the two timestamps are sufficiently close. If OK, Grant generates: KCS =def the Cliff-Serge session key. ServeTicket =def eKS(Cliff’s ID, timestamp3, Exp-Time, KCS). Sends to Cliff: ServTicket and eKCG(KCS). Exp-Time = how long KCS is good for KS = Serge’s secret key

Crypto ❖ Security Protocols 22

Kerberos, V

5: Cliff → Serge

Cliff decrypts eKCG(KCS) and obtains KCS. Cliff constructs AuthCS =def eKCS(Cliff’s ID, timestamp4). Sends to Serge: AuthCS and ServTicket to Serge.

Crypto ❖ Security Protocols 23

Kerberos, VI

6: Serge

Decrypts ServTicket to obtain: Cliff’s ID, timestamp3, Exp-Time, and KCS Using KCS decrypts AuthCS to obtain: Cliff’s ID, timestamp4 Checks that the two versions of Cliff’s ID match. Checks that timestamp4 ≤ timestamp3+ Exp-Time. If OK, Cliff and Serge can chat using KCS.

Crypto ❖ Security Protocols 24

Public Key Infrastructures (PKI’s)

Public Key Infrastructure

A set of protocols for publishing and certifying keys

Certificate

Some information signed by its publisher, a certification authority. ◮ identity certification: id + email address + public keys ◮ credential certification: access rights

There is not “one-big-PKI” ◮ There are many of these things — operating at different levels of trust. ◮ Section 13.3.3 of P&P covers X.509. ◮ We discuss PGP and SET here. ◮ More modern PKI’s use blockchains.

Crypto ❖ Security Protocols 25

Pretty good privacy: Phil Zimmerman

◮ Dates from late 1980s and early 1990s. Old, but simple ◮ Very decentralized — works through a web of trust. Example 1.

• Alice knows Bob well and can verify his cerficate is valid.

She signs his certificate with her public key.

• Charles trusts Alice and has her public key. He can thus check the validity of Alice’s

signature on Bob’s certificate.

• BUT Charles may not trust certificates that Bob signs

— Bob could be a complete flake.

◮ Each user has a keyring — a list of signatures with trust levels. complete trust > partial trust > no trust > no information ◮ The program judges certificates, and if not solid, asks the user. ◮ PGP mainly used for authenticating and encrypting email.

Crypto ❖ Security Protocols 26

PGP: Authentication

Alice wants to send a signed message m to Bob.

Alice Computes md = hSHA-2(m) and s = (md)dA mod n. Sends (m, s) to Bob. Bob Computes md = hSHA-2(m) and checks md ? = (s)eA mod n. If OK, Bob accepts that the message is from Alice. Just the RSA signature protocol.

Crypto ❖ Security Protocols 27

PGP: Encryption

Alice wants to send message m to Bob.

Alice Generates a random 128 bit session key KS. (for a block cipher like: 3DES or AES) Computes c = 3DESKS(m) and ck = (KS)eB mod n. Sends c and ck to Bob. Bob Computes KS = (ck)dB mod n and m = 3DES−1

KS (c).

Crypto ❖ Security Protocols 28

PGP: Authentication & Encryption

Alice wants to send a signed message, m, to Bob.

Alice Computes md = hSHA-1(m) and s = (md)dA mod n. Generates KS, a random 128 session key. Computes ck = (KS)eB mod n and c = 3DESKS(s||m). Sends to Bob: ck and c. Bob Computes: KS = (ck)dB mod n. s||m = 3DES−1

KS (c).

md = hSHA-1(m). Checks md ? = (s)eA mod n.

Crypto ❖ Security Protocols 29

PGP: Setup

Alice’s com- puter Generates random bits and (eventually) finds ◮ two big primes, p and q ◮ eA and dA such that eA · dA ≡ 1 (mod (p − 1)(q − 1)). Alice Chooses a secret password. Alice’s com- puter Stores d protected by the password. For more info, see: https://www.symantec.com/products/encryption http://www.philzimmermann.com

Crypto ❖ Security Protocols 30

Secure Electronic Transaction

SET = Secure Electronic Transaction (≈ 1997)

a collection of crypto protocols for credit card transactions

We want:

Authenticity No impersonations. No forgeries. Integrity Documents cannot be altered after the fact. Privacy The details of the transaction should be private. Security Credit card numbers & the like must be protected.

Note: What is Used in Practice ◮ 3-D Secure (a.k.a, Verified by Visa) and MasterCard SecureCode are alternatives to

SET that caught on in the market place. ◮ But these are also know to have lots of security (& fairness) problems. See:

https://en.wikipedia.org/wiki/3-D_Secure

Crypto ❖ Security Protocols 31

SET Example

Characters

◮ Cardholder ◮ Merchant ◮ Bank ◮ H – a public hash function ◮ PKC – say RSA The Cardholder, Merchant, and Bank do not trust each other.

Encryption Functions

EC EM EB Public

Decryption Functions

DC DM DB Private

Cardharder

GSO - goods services order PI - payment instructions

Crypto ❖ Security Protocols 32

SET Example, Continued

Q: Who knows what from the transactions?

Cardholder

Computes: GSOmd = H(EM(GSO)) PImd = H(EB(PI)) POmd = H(PImd||GSOmd) DS = DC(POmd) Sends: EM(GSO), DS, PImd, EB(PI) to Merchant.

Merchant (on receiving EM(GSO), DS, PImd, EB(PI))

Computes: gsomd = H(EM(GSO)) gso = DM(EM(GSO)) b = H(PImd||gsomd) c = EC(DS) Checks: gsomd

?

= H(EM(gso)) & b ? = c Sends: GSOmd, EB(PI), DS to the Bank

Crypto ❖ Security Protocols 33

SET Example, Concluded

Bank (on receiving GSOmd, EB(PI), DS)

Computes: pimd = H(EB(PI)) c = EC(DS) pi = DB(EB(PI)) b = H(pimd|GSOmd) Checks: b ? = c Sends: EM(a payment auth. + signature) to Merchant.

Merchant

Sends: EC(receipt + signature) to Cardholder.

Crypto ❖ Security Protocols 34