1

ISA 562 Information System Security

Key ManagementChapter 10 from Bishop’s Book

          

2

Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures

          

3

Notation {Z}k: message Z enciphered by key k Z||W: concatenation of messages Z and W kA,T : a (secret) key shared by A and T kA: A’s (public or private) key r1, r2 nonces (nonrepeating random

numbers)

Example: X Y : { Z || W } kX,Y

A T : { Z } kA || { W ||r1} kA,T

          

4

Session Key and Interchange Key

Always encrypt message with a one-time use key

Alice wants to send a message m to Bob Alice generates a random cryptographic key ks and

uses it to encipher m ks is to be used for this message only Called a session key

She enciphers ks with Bob’s public key kB kB is used to encipher all session keys (that Alice uses to

communicate with Bob) Called an interchange key Could also be a secret key shared by Alice and Bob

Alice sends {m}ks || {ks} kB

          

5

Why? To limit the amount of traffic enciphered with

the same key Standard practice, to decrease the amount of

ciphertext an attacker can obtain Compared to encrypting all messages with

interchange key Prevents some attacks

Forward search attack Question 8 of your midterm exam

Secret key cryptosystem not vulnerable to forward search attack

Establish a one-time use secret key via public-key cryptosystem

          

6

Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures

          

7

Key Exchange Protocols Goal: Alice and Bob want to establish a

shared key Key cannot be sent in clear

Attacker can be listening Alice and Bob trust some third party

Always true (who do you trust in a public-key cryptosystem?)

Protocols publicly known Security by obscurity is a bad idea Anything transmitted is assumed known to attacker

          

8

Classical Key Exchange Bootstrap problem: how do Alice, Bob begin?

If you trust nobody at all, you can never establish trust

Assume both Alice and Bob trust Cathy Alice and Cathy share secret key kA,C

Bob and Cathy share secret key kB,C

Use this to exchange shared key ks

          

9

Simple ProtocolAlice Cathy

{ request for session key to Bob } kA,C

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

Alice Bob{ ks } kB,C

Hey, Bob, Cathy wants me to forward you a session key ks with which we can talk

Okay, Alice. This is your session key ks

And tell Bob I got him a session key ks

7:25

7:20

7:15

Alice Bob{ message } ks

Hey, Bob, here’s the message

7:30

          

10

Replay Attack Alice knows she is talking to Bob; Why? But, Bob is now sure who he is talking to

Eve records the last message, and later replays it to Bob

Bob re-uses the session key (none keeps history of keys)

Eve then replays messages encrypted with that key

Eve Bob{ message } ks

Eve Bob{ ks } kB,C7:35

7:40Hey, Bob, here’s the message He must

be Alice again

Hey, Bob, Cathy wants me to forward you a session key ks with which we can talk

He must be Alice again

          

11

Replay Attack (Cont’d) Why is replaying (a valid) message a problem?

Think about this scenario By SOD principle, Alice takes deposit and Bob credits

the corresponding account Alice sends Bob a message “Eve just deposited $50k” Eve replays it…

Protocols must defense against such replay attack Adds considerable complexity Basic idea is “challenge-response”

Eve: “Hey, bob, this is Alice” Bob: “Hmm, then you must have Alice’s key” Bob: (Bob generates r1 ) “Now encrypt this!” Eve: ……

          

12

Needham-SchroederAlice Cathy

Alice || Bob || r1

Hey, Cathy, I need to talk to Bob.

Alice Bob{ Alice || ks } kB,C

Hey, Bob, this is Alice. Cathy wants me to forward you a session key ks with which we can talk

Alice Bob{ r2 } ks

You’re Alice? So you must have ks. Prove it!

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

Hey, Alice, this is Cathy

And tell Bob I got him a session key ks

this is your key ks

Alice Bob{ r2 – 1 } ks

Here’s the proof that I have ks

          

13

Alice’s Point of View Second message

Encrypted with a key kA,C that only Alice and Cathy know, so only Cathy can create the message

Containing a challenge r1, so the message is not a replay

Third message Encrypted with a key kB,C that only Bob and Cathy

know, so only Bob can read it and extract the session key

Alice Bob{ Alice || ks } kB,C

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

          

14

Bob’s Point of View Third message

Encrypted with a key that only Bob and Cathy know, so the message can only be created by Cathy

The name Alice is in the message, so Cathy says the session key is to be used while talking to Alice

Fourth and fifth message Determine if it is a replay from someone other

than Alice

Alice Bob{ Alice || ks } kB,C

Alice Bob{ r2 } ks

Alice Bob{ r2 – 1 } ks

          

15

Denning-Sacco Modification What if after some time, Eve obtains the

session key ks? More likely to be compromised than kA,C or kB,C

Eve replays the third message

Eve Bob{ Alice || ks } kB,C

Eve Bob{ r2 } ks

Eve Bob{ r2 – 1 } ks

Hey, Bob, this is Alice (replay)

You’re Alice? So you must have ks. Prove it!

Here’s the proof that I have ks

          

16

Denning-Sacco Modification (Cont’d)

Solution: use time stamp T to detect replay Weakness: clocks must be synchronized

Alice CathyAlice || Bob || r1

Alice Cathy{ Alice || Bob || r1 || ks || { Alice || T || ks } kB,C } kA,C

Alice Bob{ Alice || T || ks } kB,C

Alice Bob{ r2 } ks

Alice Bob{ r2 – 1 } ks

7:35

7:36

          

17

Otway-Rees Protocol Key-idea: always challenges n is both a session identifier and a challenge

n in clear (e.g., in 4th msg) provides no security! Typo?

Alice Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA,C

Cathy Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA,C ||

{ r2 || n || Alice || Bob } kB,C

Cathy Bobn || { r1 || ks } kA,C || { r2 || ks } kB,C

Alice Bobn || { r1 || ks } kA,C

Alice challenges Bob via r1

Cathy verifies Bob’s response via n

Bob verifies Cathy’s response via r2

Alice verifies Bob’s response via r1

Bob challenges Cathy

          

18

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 Similar to Bob sending { r1 || ks } kA,C to Alice on

behalf of Cathy Authenticator

Identifies sender

          

19

Overview Authentication - user u authenticates to Kerberos

server Obtains ticket Tu,TGS for ticket granting service (TGS) Only at time of logon

Request for service - user u wants to use service s User sends authenticator Au, ticket Tu,TGS to TGS server TGS server sends user a ticket Tu,s to use service User sends Au, Tu,s to service provider Service provider grants services

          

20

Ticket and Authenticator Example ticket issued to user u for service s

Tu,s = s || { u || u’s address || valid time || ku,s } ks

A voucher issued for user u to be authenticated by server s, with a session key ku,s

Example authenticator user u generates for service s

Au,s = { u || generation time } ku,s An authentication request to be sent by user u to

server s

          

21

Protocol

user Cathyuser || TGS

user Cathy{ ku,TGS } ku || Tu,TGS

user TGSservice || Au,TGS || Tu,TGS

user TGSuser || { ku,s } ku,TGS || Tu,s

user serviceAu,s || Tu,s

          

22

Public Key Key Exchange Here interchange keys known

eA, eB Alice and Bob’s public keys known to all dA, dB Alice and Bob’s private keys known only to owner

Simple protocol ks is desired session key Answer to midterm question 8(d)

Alice Bob{ ks } eB

          

23

Problem and Solution Vulnerable to forgery or replay

Because eB known to anyone, Bob has no assurance that Alice sent message

Simple fix uses Alice’s private key ks is desired session key One of you’s answer to midterm 8(d) – although we

consider only the forward search attack

What if the public key is forged?

Alice Bob{ { ks } dA } eB

          

24

Man-in-the-Middle AttackAlice 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

To solve this, key must be bound to identity – key infrastructure

          

25

Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures

          

26

Key Generation Goal: generate keys that are difficult to

guess Problem statement: given a set of K

potential keys, choose one randomly Equivalent to generating a random number

between 0 and K–1 inclusive

          

27

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

          

28

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

          

29

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 Use on UNIX-based systems:

(date; ps gaux) | md5

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

          

30

Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures

          

31

Key Infrastructure Goal: bind identity to public key

To thwart the man-in-the-middle attack To provide a reliable channel

B's Public Key B's Private KeyRELIABLE CHANNEL

EncryptionAlgorithm

DecryptionAlgorithm

Plain-text

Plain-textCiphertext

INSECURE CHANNEL

A B

B's Public Key

          

32

Certificates A token (message) containing

Identity of principal (e.g., Alice) His/her public key Timestamp (when issued) Other information (perhaps identity of issuer)

signed by trusted authority (here, Cathy)CA = { eA || Alice || T } dC

          

33

The Role of Trust Bob gets Alice’s certificate

If he knows (and trusts) Cathy’s public key, he can decipher the certificate

When was certificate issued? Is the principal Alice?

Now Bob has Alice’s public key Problem: Bob needs (to trust) Cathy’s public

key to validate certificate Problem pushed “up” a level Two approaches: Merkle’s tree, signature chains

          

34

Merkle’s Tree Scheme Keep certificates in a

file Define hashes

recursively h is hash function Ci is certificate i

Signature on h(1,4) known to all

Changing any Ci changes the signature

h(1,4)

h(1,2) h(3,4)

h(1,1) h(2,2) h(3,3) h(4,4)

C1 C2 C3 C4

h(1,4)=h(1,2)h(3,4)

          

35

Validation The signature can be

verified with any Ci To validate C1:

Compute h(1, 1) Obtain h(2, 2) Compute h(1, 2) Obtain h(3, 4) Compute h(1,4), signature Compare to known

signature

Only need to know hashes of child nodes on path

h(1,4)

h(1,2) h(3,4)

h(1,1) h(2,2) h(3,3) h(4,4)

C1 C2 C3 C4

          

36

Problem Changing any certificate changes the

signature Not practical in most circumstances

Too many certificates and users Users and certificates distributed over widely

separated systems

          

37

X.509 Certificate Chains 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: enciphered hash

          

38

X.509 Certificate Validation Obtain issuer’s public key Decipher signature

Gives hash of certificate Recompute hash from certificate and

compare If they differ, there’s a problem

Check interval of validity This confirms that certificate is current

          

39

Issuers Certification Authority (CA): entity that

issues certificates Multiple issuers pose validation problem Alice’s CA is Cathy; Bob’s CA is Dan; how can

Alice validate Bob’s certificate? Have Cathy and Dan cross-certify

Each issues certificate for the other Why does Alice trust Cathy?

Root CA built-in (e.g., IE)

          

40

Validation and Cross-Certifying Certificates:

Cathy<<Alice>> Cathy<<Dan>> Dan<<Bob> (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>>

          

41

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

          

42

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!) All version 4 keys signed by subject

Called “self-signing”

          

43

Validating Certificates Alice needs to validate

Bob’s OpenPGP cert Does not know Fred,

Giselle, or Ellen Alice gets Giselle’s cert

Knows Henry slightly, but his signature is at “casual” level of trust

Alice gets Ellen’s cert Knows Jack, so uses his

cert to validate Ellen’s, then hers to validate Bob’s Bob

Fred

Giselle

EllenIrene

Henry

Jack

Arrows show signaturesSelf signatures not shown

Are you sure this will work in real world?

          

44

Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures

          

45

Storing Keys Depending on OS security?

In multi-user or networked systems attackers may defeat OS access control mechanisms

Encrypt files containing keys Malware can monitor keystrokes to capture keys

Use physical devices like “smart card” Smart card does encryption/decryption Keys never enter system Card can be stolen – combined with password

          

46

Key Escrow Encryption Dilemma

Public’s need for secure communication Government’s need for lawful access to

information

Key escrow system allows authorized third party to recover key (from ciphertext) Business: recovery of backup keys Law enforcement: recovery of keys that

authorized parties require access to Goal: provide key escrow without weakening

cryptosystem Very controversial

          

47

Clipper Chip In 1993, Clinton administration proposed the

clipper chip key escrow initiative Objectives

Make strong encryption technology widely available

Built-in decryption capability for law enforcement agencies

Clipper chip has the essential key escrow property — It ensures that the key needed to decrypt the data is bound to the ciphertext

Key-recovery requires cooperation of one or more trusted party

          

48

Clipper Chip (Cont’d) Encryption requires clipper chip Clipper chip is temper proof and uses a

secret-key encryption algorithm, called Skipjack

Skipjack was designed by NSA and is classified until 1998

It uses 80 bit keys (24 bits longer than DES)

          

49

Key Escrow in Clipper Chip Each clipper chip has a unique K and a

unique 32-bit ID For each key K, two numbers K1 and K2 are

determined as follows K1 is an 80 bit random number K2 = K K1

K1 and K2 (with the unique chip ID) are given to independent federal agencies

In the initial proposal, National Institute of Standards and Technology (NIST) and Dept of Treasury were to be the escrow agents

          

50

Key Recovery in Clipper Chip Bob talks to Alice via clipper chip-equipped devices The devices generate a session key and send to

clipper chip, which uses the key to encrypt/decrypt Before encrypting, the chip transmits a string of bits

called the law enforcement access field (LEAF) LEAF is computed as follows

Session key is first encrypted using the chip-unique K Result together with the chip ID are then encrypted using

a family key F common to all chips Note that access to F allows recovery of the chip ID, but

not the session key since it is encrypted using the chip-unique key

          

51

Key Revocation Certificates invalidated before expiration

Usually due to compromised key May be due to change in circumstance (e.g.,

someone leaving company) Problems

Need to ensure the entity revoking certificate is authorized to do so

Revocation information circulates to everyone fast enough

Network delays, infrastructure problems may delay information

          

52

CRLs Certificate revocation list lists certificates

that are revoked X.509: only certificate issuer can revoke

certificate Added to CRL

PGP: signers can revoke signatures; owners can revoke certificates, or allow others to do so

          

53

Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures

          

54

Digital Signature Construct that authenticated origin, contents

of message in a manner provable to a disinterested third party (“judge”)

Sender cannot deny having sent message (service is “nonrepudiation”) Limited to technical proofs

Legal proofs, etc., probably required; not dealt with here

          

55

Common Error Classical: Alice, Bob share key k

Alice sends m || { m }kA,B to Bob This is not a digital signature, because a

third party cannot determine whether Alice or Bob generated message

          

56

Public Key Digital Signatures Alice’s keys are dAlice, eAlice

Alice sends Bobm || { m } dAlice

In case of dispute, judge computes{ { m } dAlice } eAlice

and if it is m, Alice signed message She’s the only one who knows dAlice!

          

57

RSA Digital Signatures Need to be careful

Never sign documents directly, but sign its hash Mathematical properties can be turned against signer

Sign then encrypt instead of the other way around

Changing public keys causes forgery

          

58

Attack #1 Example: Alice, Bob communicating

Alice: nA = 95, eA = 59, dA = 11 Bob: nB = 77, eB = 53, dB = 17

26 contracts, numbered 00 to 25 Alice has Bob sign 05 (overtime) and 17 (more

overtime) c = mdB mod nB = 0517 mod 77 = 3 c = mdB mod nB = 1717 mod 77 = 19

Alice computes 0517 mod 77 = 08 (raising salary) corresponding signature is 0319 mod 77 = 57; claims Bob signed 08 (raising salary)

Judge computes ceB mod nB = 5753 mod 77 = 08 Signature validated; Bob is toast

          

59

Attack #2: Bob’s Revenge Bob, Alice agree to sign contract 06 (OT +

raising salary) Alice enciphers, then signs:

(meB mod 77)dA mod nA = (0653 mod 77)11 mod 95 = 63 Bob now changes his public key

Computes r such that 13r mod 77 = 6; say, r = 59 Computes reB mod (nB) = 5953 mod 60 = 7 Replace public key eB with 7, private key dB = 43

Bob claims contract was 13 (OT + half salary). Judge computes: (6359 mod 95)43 mod 77 = 13 Verified; now Alice is toast

          

60

El Gamal Digital Signature Relies on discrete log problem Choose p prime, g, d < p; compute y = gd mod p Public key: (y, g, p); private key: d To sign contract m:

Choose k relatively prime to p–1, and not yet used Compute a = gk mod p Find b such that m = (da + kb) mod p–1 Signature is (a, b)

To validate, check that yaab mod p = gm mod p

          

61

Example Alice chooses p = 29, g = 3, d = 6

y = 36 mod 29 = 4 Alice wants to send Bob signed contract 23

Chooses k = 5 (relatively prime to 28) This gives a = gk mod p = 35 mod 29 = 11 Then solving 23 = (611 + 5b) mod 28 gives b =

25 Alice sends message 23 and signature (11, 25)

Bob verifies signature: gm mod p = 323 mod 29 = 8 and yaab mod p = 4111125 mod 29 = 8 They match, so Alice signed

          

62

Key Points Key management critical to effective use of

cryptosystems Keys need infrastructure to bind holders,

allow revoking Key escrowing complicates infrastructure

Digital signatures provide integrity of origin and content