Key Management ( Ch 2.4, 20.6, 21.5 and 23.1 - PowerPoint Presentation

Slide1

Key Management(Ch 2.4, 20.6, 21.5 and 23.1)

Shared Key Exchange Problem

How do Alice and Bob exchange a shared secret?

Offline

Doesn’t scale

Using specially crafted messages (

Diffie

-Hellman)

Using a trusted third party (KDC)

Secrets should never be sent in clear

We should prevent replay attacks

We should prevent reuse of old keys

Using public key cryptography (possible)

Exchange a secret with someone you never met while shouting in a room full of people

Alice and Bob agree on g and large nAlice chooses random a, sends ga mod nBob chooses random b, sends gb mod nAlice takes Bob’s message and calculates gab mod n – shared secret. Bob does the same.

Diffie-Hellman Key Exchange (Ch 21.5)

Alice

Bob

g, n,

g

a mod n

g

b mod n

g

ab mod n

g

ab

mod n

Why is it hard for anyone to guess

a and b in Diffie-Hellman key exchange?Why is brute force the only possible way of guessing? Let g be a “primitive root” of nPowers of g generate all numbers 1..n-1For any integer x<n one can find a s.t.: x=ga mod na is called the “discrete logarithm” of xThere is no algorithm to efficiently calculate a given x, g and n

Discrete Logarithms

Alice and Bob can exchange a shared key

Multiple users can:Select their “private” key PriCalculate their “public” key xi = g mod nand publish it in a central directoryWhen another user wants to talk to them, they can calculate a shared key for this communicationOn-demand shared key exchange

Uses of Diffie-Hellman

Pr

i

Mallory sits between Alice and Bob and replaces their messages with her own

When Alice and Bob send messages, Mallory decrypts them and re-encrypts themThis works because there’s no authentication

Diffie-Hellman and MITM

Alice

Bob

g, n,

g

a mod n

g

b mod n

g

mb mod n

gam mod n

Mallory

g, n,

gm mod n

g

m mod n

Building up to Needham Schroeder/KerberosClient sends req. to KDC (key distrib. center)KDC generates a shared key: Kc,sKeys KKDC,C and KKDC,S are preconfiguredNo keys ever traverse net in the clearWhy are identities in tickets?

KDC Based Key Distribution (Ch 20.6)

C

KDC

S

EK

KDC,S

{C,

Kc,s}

EKKDC,C{S, Kc,s}

C, S

ticket

KDC does not have to talk both to C and SMessages 2 or 3 can be replayed by MalloryForce C and S to use same secret for a long timeCause S to have an old ticket, break communication with C

KDC Based Key Distribution

C

KDC

S

ticket

S

= EK

KDC,S{C, Kc,s}

EKKDC,C{S, Kc,s}, ticketS

C, S

ticket

S

Use nonces to prevent replay attacks

Needham-Shroeder Key Exchange

C

KDC

S

ticket

S

= EK

KDC,S{C, Kc,s}

EKKDC,C{N1, S, Kc,s, ticketS}

N1, C, S

EKC,S{N2}, ticketS

EK

C,S{N2-1}EKC,S{N3}

EK

C,S

{N

3

-1}

What happens if attacker gets session key?Can reuse old session key to answer challenge-response, generate new requests, etcNeed validity period in ticket to ensure freshness = tickets expire after some time

Problem

Introduce Ticket Granting Server (TGS)Issue tickets for clients to talk to serversAuthentication server (AS) authenticates usersIssues a ticket for clients to talk to TGSTGS+AS = KDCEach ticket has a validity period: timestamp and lifetimeEach service request (client to server) has an authenticator (nonce): timestamp + client identity, encrypted with a session key

Solution: Kerberos (

Ch

23.1

)

Kerberos

Key Exchange Using Public Keys

Alice selects a shared key, encrypts it with Bob’s public key – only Bob can readWhy not just use public keys? It would be much slower

Alice

Bob

EPub

B

(KAB)

Public Key Exchange Problem(Ch 2.4)

How do we verify an identity:

Alice

sends to Bob her public key Pub(A)

Bob

sends to Alice his public key Pub(B

)

How do we ensure that those keys really belong to Alice and Bob?

Need a trusted third party - Trent

Digital Certificates

Trent is a trusted third party

Everyone has Trent’s public key

Trent signs Alice’s ID, public key pair

He generates

public-key certificate

Does same for Bob

When they receive keys, verify Trent’s signature

And

that identity of the sender matches that in the cert.

Mallory cannot impersonate Alice or Bob because her key is signed as Mallory’s

Certificate usually contains more than the public key

Name, network address, organization

Trent is known as

Certificate Authority (CA)

Authentication stepsAlice provides nonce, or a timestamp is used instead, along with her certificate.Bob selects session key and sends it to Alice with nonce, encrypted with Alice’s public key, and signed with Bob’s private key. He sends his certificate tooAlice validates certificate – it is really Bob’s key insideAlice checks signature and nonce – Bob really generated the message and it is fresh

Certificate-Based

Key Exchange

Revocation lists (CRL’s)Long lists of public keys whose private key got compromisedHard to propagateLifetime / ExpirationShort life allows assurance of validity at time of issueReal time validationReceiver of a certificate asks the CA who signed it if corresponding private key was compromisedCan cache replies

Recovery From Stolen Private Keys

You run a company and want any machines inside to be able to talk to each otherNeed confidentialityYou run a public server – anyone could attempt to talk to itNeed confidentiality and the clients need to be able to authenticate the serverYou want to design a messageexchange protocol betweentwo phonesNeed confidentiality

What Should You Use?