Key Management and Identity

CS461/ECE422Spring 2012

Reading Material

• Chapters 2 and 23 from text• Handbook of Applied Cryptography– http://www.cacr.math.uwaterloo.ca/hac/– Chapter 5 for information on Pseudorandom

sequences– Chapter 12 for Needham-Schroeder protocol

• The Gnu Privacy Handbook– http://www.gnupg.org/gph/en/manual.html

Overview

• Digital Signatures• Key Exchange• Key/Identity Management– Kerberos– PKI• Hierarchical – X.509• Web of Trust

Digital Signatures

• Alice wants Bob to know that she sent message, m– Sends digital signature along with message– m || {h(m)}eA

• How would Bob verify signature?• Could Eve intercept and change message?• How does Bob know that Alice is the sender?

5

Session and Interchange Keys

• Long lived Interchange Keys only exist to boot strap• Short lived session keys used for bulk encryption

Kb,KaKa,Kb

{Ka,b}Ka{m1}Ka,b

Ka,bKa,b

6

Picking Good Session Keys

• Goal: generate keys that are difficult to guess• Problem statement: given a set of K potential keys,

choose one randomly– Equivalent to selecting a random number between 0 and K–

1 inclusive– Uniform distribution – Use entire space– Independence – Should not be able to predict next selection

• Why is this hard: generating random numbers– Actually, numbers are usually pseudo-random, that is,

generated by an algorithm

7

What is “Random”?

• Sequence of cryptographically random numbers: a sequence of numbers n1, n2, … such that for any integer k > 0, an observer cannot predict nk even if all of n1, …, nk–1 are known– Best: physical source of randomness

• Random pulses• Electromagnetic phenomena• Characteristics of computing environment such as disk latency• Ambient background noise

8

What is “Pseudorandom”?

• Sequence of cryptographically pseudorandom numbers: sequence of numbers intended to simulate a sequence of cryptographically random numbers but generated by an algorithm– Very difficult to do this well

• Linear congruential generators [nk = (ank–1 + b) mod n] broken

• Polynomial congruential generators [nk = (ajnk–1j + … + a1nk–1 a0)

mod n] broken too• Here, “broken” means next number in sequence can be

determined

9

Best Pseudorandom Numbers

• Strong mixing function: function of 2 or more inputs with each bit of output depending on some nonlinear function of all input bits– Examples: DES, MD5, SHA-1, avalanche effect– Use on UNIX-based systems:

(date; ps gaux) | md5

where “ps gaux” lists all information about all processes on system

10

Separate Channel

• Ideally you have separate secure channel for exchanging Interchange keys– Direct secret sharing grows at N2

Telephone, separate data network, ESP, sneaker net

Regular data network

11

Shared Channel: Trusted Third Party

• Generally separate channel is not practical– No trustworthy separate channel– Want to scale linearly with additional users

Regular data network

Key Exchange

KA,KB, … KZ

KA

KB

12

Classical Key Exchange

• Bootstrap problem: how do Alice, Bob begin?– Alice can’t send it to Bob in the clear!

• Assume trusted third party, Cathy– Alice and Cathy share secret key kA

– Bob and Cathy share secret key kB

• Use this to exchange shared key ks

13

Simple Protocol

Alice Cathy{ request for session key to Bob } kA

Alice Cathy{ ks } kA || { ks } kB

Alice Bob{ ks } kB

Eve Bob{ ks } kB

14

Problems

• How does Bob know he is talking to Alice?– Replay attack: Eve records message from Alice

to Bob, later replays it; Bob may think he’s talking to Alice, but he isn’t

– Session key reuse: Eve replays message from Alice to Bob, so Bob re-uses session key

• Protocols must provide authentication and defense against replay

Needham-Schroeder

Alice CathyAlice||Bob||R1

Alice Cathy{Alice||Bob||r1||ks {Alice|| ks} kB} kA

Alice Bob{Alice|| ks} kB

BobAlice{r2}ks

BobAlice{r2-1}ks

16

Argument: Alice talking to Bob

• Second message– Encrypted using key only she, Cathy knows

• So Cathy encrypted it

– Response to first message• As r1 in it matches r1 in first message

• Third message– Alice knows only Bob can read it

• As only Bob can derive session key from message

– Any messages encrypted with that key are from Bob

17

Argument: Bob talking to Alice

• Third message– Encrypted using key only he, Cathy know

• So Cathy encrypted it

– Names Alice, session key• Cathy provided session key, says Alice is other party

• Fourth message– Uses session key to determine if it is replay from Eve

• If not, Alice will respond correctly in fifth message• If so, Eve can’t decrypt r2 and so can’t respond, or responds

incorrectly

Kerberos

19

Kerberos

• Authentication system– Based on Needham-Schroeder with Denning-Sacco modification– Central server plays role of trusted third party (“Cathy”)

• Ticket– Issuer vouches for identity of requester of service

• Authenticator– Identifies sender

• Two Competing Versions: 4 and 5– Version 4 discussed here

20

Idea

• User u authenticates to Kerberos AS– Obtains ticket (TGT) Tu,TGS for ticket granting service

(TGS)

• User u wants to use service s:– User sends authenticator Au, ticket Tu,TGS to TGS asking

for ticket for service– TGS sends ticket Tu,s to user

– User sends Au, Tu,s to server as request to use s

• Details follow

Public Key: key exchange

• Bob picks session key, ksession

• Encrypts it with Alice’s public key eA

• Sends to Alice• Problems?

{ksession}eA

28

Problem and Solution

• Vulnerable to forgery or replay– Because eA known to anyone, Alice has no assurance

that Bob sent message

• Simple fix uses Bob’s private key– ks is desired session key

– Are we ok now?

{{ksession}dB}eA

{{ksession} eA}dB

29

Notes

• Can include message enciphered with ks

• Assumes Alice has Bob’s public key, and vice versa– If not, each must get it from public server– If keys not bound to identity of owner, attacker Eve can

launch a man-in-the-middle attack (next slide; Cathy is public server providing public keys)

• Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI)

30

Man-in-the-Middle Attack

Alice CathySend Bob’s public key

Eve Cathysend Bob’s public key

Eve CathyeB

AliceeE Eve

Alice Bob{ ks } eE

Eve Bob{ ks } eB

Eve intercepts request

Eve intercepts message

31

Cryptographic Key Infrastructure

• Goal: bind identity to key• Classical: not possible as all keys are shared

– Use protocols to agree on a shared key (see earlier)

• Public key: bind identity to public key– Crucial as people will use key to communicate with

principal whose identity is bound to key– Erroneous binding means no secrecy between

principals– Assume principal identified by an acceptable name

32

Certificates

• Create token (message) containing– Identity of principal (here, Alice)– Corresponding public key– Timestamp (when issued)– Other information (perhaps identity of signer)– Compute hash (message digest) of token

Hash encrypted by trusted authority (here, Cathy) using private key: called a “signature”

CA = eA || Alice || T || {h(eA || Alice || T )} dC

33

X.509 Certificates

• Some certificate components in X.509v3:– Version– Serial number– Signature algorithm identifier: hash algorithm– Issuer’s name; uniquely identifies issuer– Interval of validity– Subject’s name; uniquely identifies subject– Subject’s public key– Signature: encrypted hash

34

Use

• Bob gets Alice’s certificate– If he knows Cathy’s public key, he can validate the certificate

• Decrypt encrypted hash using Cathy’s public key• Re-compute hash from certificate and compare• Check validity• Is the principal Alice?

– Now Bob has Alice’s public key• Problem: Bob needs Cathy’s public key to validate

certificate– That is, secure distribution of public keys– Solution: Public Key Infrastructure (PKI) using trust anchors called

Certificate Authorities (CAs) that issue certificates

PKI Trust Models

• Single Global CA– Unmanageable– Who is the universally

trusted root?

• Hierarchical CA– Tree of CA’s– But still need to be

rooted somewhere

36

PKI Trust Models

• Hierarchical CAs with cross-certification– Multiple root CAs that are cross-certified– Cross-certification at lower levels for efficiency

• Web Model– Browsers come pre-configured with multiple trust

anchor certificates– New certificates can be added

• Distributed (e.g., PGP)– No CA; instead, users certify each other to build a “web

of trust”

37

Validation and Cross-Certifying• Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s

certificate?– Have Cathy and Don cross-certify– Each issues certificate for the other

• Certificates:– Cathy<<Alice>>– Dan<<Bob>– Cathy<<Dan>>– Dan<<Cathy>>

• Alice validates Bob’s certificate– Alice obtains Cathy<<Dan>>– Alice uses (known) public key of Cathy to validate Cathy<<Dan>>– Alice uses Cathy<<Dan>> to validate Dan<<Bob>>

38

PGP Chains

• OpenPGP certificates structured into packets– One public key packet– Zero or more signature packets

• Public key packet:– Version (3 or 4; 3 compatible with all versions of PGP, 4

not compatible with older versions of PGP)– Creation time– Validity period (not present in version 3)– Public key algorithm, associated parameters– Public key

39

OpenPGP Signature Packet

• Version 3 signature packet– Version (3)– Signature type (level of trust)– Creation time (when next fields hashed)– Signer’s key identifier (identifies key to encrypt hash)– Public key algorithm (used to encrypt hash)– Hash algorithm– Part of signed hash (used for quick check)– Signature (encrypted hash)

• Version 4 packet more complex

40

Signing

• Single certificate may have multiple signatures• Notion of “trust” embedded in each signature

– Range from “untrusted” to “ultimate trust”– Signer defines meaning of trust level (no standards!)– Few implementations support this

• All version 4 keys signed by subject– Called “self-signing”

41

Trust in GPG

Owner TrustGPG enables assignment of trust in entity

• Unknown, Not Trusted, Marginal, Full• How much do you trusted signatures by that entity

Key ValidityHow much do you trust that the key corresponds to the

owner?• Unknown, Not trusted, Marginal Full

Configurable• X full paths or Y marginal paths

42

Web of Trust Example

From GPG manual, arrows show key signatures

43

Web of Trust Scenarios

In all cases the key is valid given 1 full or 2 marginal paths. Always fully trust directly signed keys

Fully Trust Dharma Marginally Trust Dharma and Blake Marginally Trust Dharma and Chloe Marginally Trust Dharma, Blake, and Chloe Fully Trust Blake, Chloe, and Elena

44

Key Revocation

• Certificates invalidated before expiration– Usually due to compromised key– May be due to change in circumstance (e.g., someone

leaving company)• Problems

– Verify that entity revoking certificate authorized to do so

– Revocation information circulates to everyone fast enough

• Network delays, infrastructure problems may delay information

45

GPG: Revocation Certificate

Use the –gen-revoke option to create a revocation certification.

When you suspect that your certificate has been compromised

Send revocation certificate to all your friends

Or send the revocation certificate to a GPG key server

46

CRLs

• Certificate revocation list lists certificates that are revoked

• X.509: only certificate issuer can revoke certificate– Added to CRL

Recent Root Certificate Issues

• Vast numbers of Root certifiers in web browsers

• How strenuous is the background check of the certificate providers?

• How strong is the internal security of the certificate providers?

• What goes wrong with bad root certificates appear?

Network Perspectives

• Ask several notifiers throughout the network what they get for the target server’s certificate.

Summary

• Tracking identity is important – Key negotiation– Digital signatures

• Managing the root of trust is a very hard practical problem