1. Key Escrow
Key escrow system allows authorized third party to recover key
Useful when keys belong to roles, such as system operator, rather than individuals
Business: recovery of backup keys
Law enforcement: recovery of keys that authorized parties require access to
Goal: provide this without weakening cryptosystem
Very controversial
May 18, 2004
ECS 235

2. Desirable Properties
Escrow system should not depend on encipherment algorithm
Privacy protection mechanisms must work from end to end and be part of user interface
Requirements must map to key exchange protocol
System supporting key escrow must require all parties to authenticate themselves
If message to be observable for limited time, key escrow system must ensure keys valid for that period of time only
May 18, 2004
ECS 235

3. Components User security component Key escrow component
Does the encipherment, decipherment
Supports the key escrow component
Key escrow component
Manages storage, use of data recovery keys
Data recovery component
Does key recovery
May 18, 2004
ECS 235

4. Example: EES, Clipper Chip
Escrow Encryption Standard
Set of interlocking components
Designed to balance need for law enforcement access to enciphered traffic with citizens’ right to privacy
Clipper chip prepares per-message escrow information
Each chip numbered uniquely by UID
Special facility programs chip
Key Escrow Decrypt Processor (KEDP)
Available to agencies authorized to read messages
May 18, 2004
ECS 235

5. User Security Component
Unique device key kunique
Nonunique family key kfamily
Cipher is Skipjack
Classical cipher: 80 bit key, 64 bit input, output blocks
Generates Law Enforcement Access Field (LEAF) of 128 bits:
{ UID || { ksession } kunique || hash } kfamily
hash: 16 bit authenticator from session key and initialization vector
May 18, 2004
ECS 235

6. Programming User Components
Done in a secure facility
Two escrow agencies needed
Agents from each present
Each supplies a random seed and key number
Family key components combined to get kfamily
Key numbers combined to make key component enciphering key kcomp
Random seeds mixed with other data to produce sequence of unique keys kunique
Each chip imprinted with UID, kunique, kfamily
May 18, 2004
ECS 235

7. The Escrow Components
During initialization of user security component, process creates ku1 and ku2 where kunique = ku1  ku2
First escrow agency gets { ku1 } kcomp
Second escrow agency gets { ku2 } kcomp
May 18, 2004
ECS 235

8. Obtaining Access Alice obtains legal authorization to read message
She runs message LEAF through KEDP
LEAF is { UID || { ksession } kunique || hash } kfamily
KEDP uses (known) kfamily to validate LEAF, obtain sending device’s UID
Authorization, LEAF taken to escrow agencies
May 18, 2004
ECS 235

9. Agencies’ Role Each validates authorization
Each supplies { kui } kcomp, corresponding key number
KEDP takes these and LEAF:
Key numbers produce kcomp
kcomp produces ku1 and ku2
ku1 and ku2 produce kunique
kunique and LEAF produce ksession
May 18, 2004
ECS 235

10. Problems hash too short LEAF 128 bits, so given a hash:
2112 LEAFs show this as a valid hash
1 has actual session key, UID
Takes about 42 minutes to generate a LEAF with a valid hash but meaningless session key and UID; in fact, deployed devices would prevent this attack
Scheme does not meet temporal requirement
As kunique fixed for each unit, once message is read, any future messages can be read
May 18, 2004
ECS 235

11. Yaksha Security System
Key escrow system meeting all 5 criteria
Based on RSA, central server
Central server (Yaksha server) generates session key
Each user has 2 private keys
Alice’s modulus nA, public key eA
First private key dAA known only to Alice
Second private key dAY known only to Yaksha central server
dAA dAY = dA mod nA
May 18, 2004
ECS 235

12. Alice and Bob Alice wants to send message to Bob
Alice asks Yaksha server for session key
Yaksha server generates ksession
Yaksha server sends Alice the key as:
CA = (ksession)dAYeA mod nA
Alice computes
(CA)dAA mod nA = ksession
May 18, 2004
ECS 235

13. Analysis Authority can read only one message per escrowed key
Meets requirement 5 (temporal one), because “time” interpreted as “session”
Independent of message enciphering key
Meets requirement 1
Interchange algorithm, keys fixed
Others met by supporting infrastructure
May 18, 2004
ECS 235

14. Alternate Approaches Tie to time Tie to probability
Session key not given as escrow key, but related key is
To derive session key, must solve instance of discrete log problem
Tie to probability
Oblivious transfer: message received with specified probability
Idea: translucent cryptography allows fraction f of messages to be read by third party
Not key escrow, but similar in spirit
May 18, 2004
ECS 235

15. Key Revocation Certificates invalidated before expiration Problems
Usually due to compromised key
May be due to change in circumstance (e.g., someone leaving company)
Problems
Entity revoking certificate authorized to do so
Revocation information circulates to everyone fast enough
Network delays, infrastructure problems may delay information
May 18, 2004
ECS 235

16. 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
Revocation message placed in PGP packet and signed
Flag marks it as revocation message
May 18, 2004
ECS 235

17. 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
Inability to deny one’s cryptographic key was used to sign
One could claim the cryptographic key was stolen or compromised
Legal proofs, etc., probably required; not dealt with here
May 18, 2004
ECS 235

18. Common Error Classical: Alice, Bob share key k
Alice sends m || { m }k to Bob
This is a digital signature
WRONG
This is not a digital signature
Why? Third party cannot determine whether Alice or Bob generated message
May 18, 2004
ECS 235

19. Classical Digital Signatures
Require trusted third party
Alice, Bob each share keys with trusted party Cathy
To resolve dispute, judge gets { m }kAlice, { m }kBob, and has Cathy decipher them; if messages matched, contract was signed
{ m }kAlice
Alice
Bob
{ m }kAlice
Bob
Cathy
{ m }kBob
Cathy
Bob
May 18, 2004
ECS 235

20. Public Key Digital Signatures
Alice’s keys are dAlice, eAlice
Alice sends Bob
m || { 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!
May 18, 2004
ECS 235

21. RSA Digital Signatures
Use private key to encipher message
Protocol for use is critical
Key points:
Never sign random documents, and when signing, always sign hash and never document
Mathematical properties can be turned against signer
Sign message first, then encipher
Changing public keys causes forgery
May 18, 2004
ECS 235

22. Attack #1 Example: Alice, Bob communicating
nA = 95, eA = 59, dA = 11
nB = 77, eB = 53, dB = 17
26 contracts, numbered 00 to 25
Alice has Bob sign 05 and 17:
c = mdB mod nB = 0517 mod 77 = 3
c = mdB mod nB = 1717 mod 77 = 19
Alice computes 0517 mod 77 = 08; corresponding signature is 0319 mod 77 = 57; claims Bob signed 08
Judge computes ceB mod nB = 5753 mod 77 = 08
Signature validated; Bob is toast
May 18, 2004
ECS 235

23. Attack #2: Bob’s Revenge
Bob, Alice agree to sign contract 06
Alice enciphers, then signs:
(meB mod 77)dA mod nA = (0653 mod 77)11 mod 95 = 63
Bob now changes his public key so he can make it appear that Alice signed contract 13:
Computes r such that 13r mod 77 = 06; say, r = 59
Computes reB mod (nB) = 5953 mod 60 = 7
Replace public key eB with 7; corresponding private key dB = 43
Bob claims contract was 13. Judge computes:
(6359 mod 95)43 mod 77 = 13
Verified; now Alice is toast
May 18, 2004
ECS 235

24. 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
May 18, 2004
ECS 235

25. 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 = (611 + 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 = mod 29 = 8
They match, so Alice signed
May 18, 2004
ECS 235

26. m = (da + kb) mod p–1 = (11d + 525) mod 28
Attack
Eve learns k, corresponding message m, and signature (a, b)
Extended Euclidean Algorithm gives d, the private key
Example from above: Eve learned Alice signed last message with k = 5
m = (da + kb) mod p–1 = (11d + 525) mod 28
so Alice’s private key is d = 6
May 18, 2004
ECS 235

27. Key Points Key management critical to effective use of cryptosystems
Different levels of keys (session vs. interchange)
Keys need infrastructure to identify holders, allow revoking
Key escrowing complicates infrastructure
Digital signatures provide integrity of origin and content
Much easier with public key cryptosystems than with classical cryptosystems
May 18, 2004
ECS 235

28. Overview Basics Passwords Other methods Multiple methods Storage
Selection
Breaking them
Other methods
Multiple methods
May 18, 2004
ECS 235

29. Basics Authentication: binding of identity to subject
Identity is that of external entity (my identity, Matt, etc.)
Subject is computer entity (process, etc.)
May 18, 2004
ECS 235

30. Establishing Identity
One or more of the following
What entity knows (eg. password)
What entity has (eg. badge, smart card)
What entity is (eg. fingerprints, retinal characteristics)
Where entity is (eg. In front of a particular terminal)
May 18, 2004
ECS 235

31. Authentication System
(A, C, F, L, S)
A information that proves identity
C information stored on computer and used to validate authentication information
F complementation function; f : A  C
L functions that prove identity
S functions enabling entity to create, alter information in A or C
May 18, 2004
ECS 235

32. Example Password system, with passwords stored on line in clear text
A set of strings making up passwords
C = A
F singleton set of identity function { I }
L single equality test function { eq }
S function to set/change password
May 18, 2004
ECS 235

33. Passwords Sequence of characters Sequence of words Algorithms
Examples: 10 digits, a string of letters, etc.
Generated randomly, by user, by computer with user input
Sequence of words
Examples: pass-phrases
Algorithms
Examples: challenge-response, one-time passwords
May 18, 2004
ECS 235

34. Storage Store as cleartext Encipher file
If password file compromised, all passwords revealed
Encipher file
Need to have decipherment, encipherment keys in memory
Reduces to previous problem
Store one-way hash of password
If file read, attacker must still guess passwords or invert the hash
May 18, 2004
ECS 235

35. Example UNIX system standard hash function As authentication system:
Hashes password into 11 char string using one of 4096 hash functions
As authentication system:
A = { strings of 8 chars or less }
C = { 2 char hash id || 11 char hash }
F = { 4096 versions of modified DES }
L = { login, su, … }
S = { passwd, nispasswd, passwd+, … }
May 18, 2004
ECS 235

36. Anatomy of Attacking Goal: find a  A such that:
For some f  F, f(a) = c  C
c is associated with entity
Two ways to determine whether a meets these requirements:
Direct approach: as above
Indirect approach: as l(a) succeeds iff f(a) = c  C for some c associated with an entity, compute l(a)
May 18, 2004
ECS 235

37. Preventing Attacks How to prevent this: Hide one of a, f, or c
Prevents obvious attack from above
Example: UNIX/Linux shadow password files
Hides c’s
Block access to all l  L or result of l(a)
Prevents attacker from knowing if guess succeeded
Example: preventing any logins to an account from a network
Prevents knowing results of l (or accessing l)
May 18, 2004
ECS 235

38. Dictionary Attacks Trial-and-error from a list of potential passwords
Off-line: know f and c’s, and repeatedly try different guesses g  A until the list is done or passwords guessed
Examples: crack, john-the-ripper
On-line: have access to functions in L and try guesses g until some l(g) succeeds
Examples: trying to log in by guessing a password
May 18, 2004
ECS 235

39. Using Time Anderson’s formula:
P probability of guessing a password in specified period of time
G number of guesses tested in 1 time unit
T number of time units
N number of possible passwords (|A|)
Then P ≥ TG/N
May 18, 2004
ECS 235

40. Example Goal Solution Passwords drawn from a 96-char alphabet
Can test 104 guesses per second
Probability of a success to be 0.5 over a 365 day period
What is minimum password length?
Solution
N ≥ TG/P = (365246060)104/0.5 = 6.311011
Choose s such that sj=0 96j ≥ N
So s ≥ 6, meaning passwords must be at least 6 chars long
May 18, 2004
ECS 235

41. Approaches: Password Selection
Random selection
All elements of A equally likely to be selected
ICBS: maximizes time to guessing password
Be careful—it may not be really “random”
Remembering these is hard
Write down transformed password, apply transformation to recover
Example: “Capitalize 3rd letter, append digit 2”; written down is “Swqgle3” so password is “SwQgle32”
May 18, 2004
ECS 235

42. Pronounceable Passwords
Generate phonemes randomly
Phoneme is unit of sound, eg. cv, vc, cvc, vcv
Examples: helgoret, juttelon are; przbqxdfl, zxrptglfn are not
Problem: too few
Solution: key crunching
Run long key through hash function and convert to printable sequence
Use this sequence as password
May 18, 2004
ECS 235

43. User Selection Problem: people pick easy to guess passwords
Based on account names, user names, computer names, place names
Dictionary words (also reversed, odd capitalizations, control characters, “elite-speak”, conjugations or declensions, swear words, Torah/Bible/Koran/… words)
Too short, digits only, letters only
License plates, acronyms, social security numbers
Personal characteristics or foibles (pet names, nicknames, job characteristics, etc.
May 18, 2004
ECS 235

44. Picking Good Passwords
“LlMm*2^Ap”
Names of members of 2 families
“OoHeO/FSK”
Second letter of each word of length 4 or more in third line of third verse of Star-Spangled Banner, followed by “/”, followed by author’s initials
What’s good here may be bad there
“DMC/MHmh” bad at Dartmouth (“Dartmouth Medical Center/Mary Hitchcock memorial hospital”), ok here
Why are these now bad passwords? 
May 18, 2004
ECS 235

45. Proactive Password Checking
Analyze proposed password for “goodness”
Always invoked
Can detect, reject bad passwords for an appropriate definition of “bad”
Discriminate on per-user, per-site basis
Needs to do pattern matching on words
Needs to execute subprograms and use results
Spell checker, for example
Easy to set up and integrate into password selection system
May 18, 2004
ECS 235