Key Escrow. Desirable Properties

Transcription

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 Slide #1 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 Slide #2 1

2 Components User security 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 Slide #3 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 Slide #4 2

3 User Security Component Unique device key k unique Nonunique family key k family Cipher is Skipjack Classical cipher: 80 bit key, 64 bit input, output blocks Generates Law Enforcement Access Field (LEAF) of 128 bits: { UID { k session } k unique hash } k family hash: 16 bit authenticator from session key and initialization vector May 18, 2004 ECS 235 Slide #5 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 k family Key numbers combined to make key component enciphering key k comp Random seeds mixed with other data to produce sequence of unique keys k unique Each chip imprinted with UID, k unique, k family May 18, 2004 ECS 235 Slide #6 3

4 The Escrow Components During initialization of user security component, process creates k u1 and k u2 where k unique = k u1 k u2 First escrow agency gets { k u1 } k comp Second escrow agency gets { k u2 } k comp May 18, 2004 ECS 235 Slide #7 Obtaining Access Alice obtains legal authorization to read message She runs message LEAF through KEDP LEAF is { UID { k session } k unique hash } k family KEDP uses (known) k family to validate LEAF, obtain sending device s UID Authorization, LEAF taken to escrow agencies May 18, 2004 ECS 235 Slide #8 4

5 Agencies Role Each validates authorization Each supplies { k ui } k comp, corresponding key number KEDP takes these and LEAF: Key numbers produce k comp k comp produces k u1 and k u2 k u1 and k u2 produce k unique k unique and LEAF produce k session May 18, 2004 ECS 235 Slide #9 Problems hash too short LEAF 128 bits, so given a hash: 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 k unique fixed for each unit, once message is read, any future messages can be read May 18, 2004 ECS 235 Slide #10 5

6 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 n A, public key e A First private key d AA known only to Alice Second private key d AY known only to Yaksha central server d AA d AY = d A mod n A May 18, 2004 ECS 235 Slide #11 Alice and Bob Alice wants to send message to Bob Alice asks Yaksha server for session key Yaksha server generates k session Yaksha server sends Alice the key as: C A = (k session ) dayea mod n A Alice computes (C A ) daa mod n A = k session May 18, 2004 ECS 235 Slide #12 6

7 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 Slide #13 Alternate Approaches Tie to time 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 Slide #14 7

8 Key Revocation Certificates invalidated before expiration 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 Slide #15 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 Slide #16 8

9 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 Slide #17 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 Slide #18 9

10 Classical Digital Signatures Require trusted third party Alice, Bob each share keys with trusted party Cathy To resolve dispute, judge gets { m }k Alice, { m }k Bob, and has Cathy decipher them; if messages matched, contract was signed Alice Bob Cathy { m }k Alice { m }k Alice { m }k Bob Bob Cathy Bob May 18, 2004 ECS 235 Slide #19 Public Key Digital Signatures Alice s keys are d Alice, e Alice Alice sends Bob m { m }d Alice In case of dispute, judge computes { { m }d Alice }e Alice and if it is m, Alice signed message She s the only one who knows d Alice! May 18, 2004 ECS 235 Slide #20 10

11 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 Slide #21 Attack #1 Example: Alice, Bob communicating n A = 95, e A = 59, d A = 11 n B = 77, e B = 53, d B = contracts, numbered 00 to 25 Alice has Bob sign 05 and 17: c = m db mod n B = mod 77 = 3 c = m db mod n B = mod 77 = 19 Alice computes mod 77 = 08; corresponding signature is mod 77 = 57; claims Bob signed 08 Judge computes c eb mod n B = mod 77 = 08 Signature validated; Bob is toast May 18, 2004 ECS 235 Slide #22 11

12 Attack #2: Bob s Revenge Bob, Alice agree to sign contract 06 Alice enciphers, then signs: (m eb mod 77) da mod n A = (06 53 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 13 r mod 77 = 06; say, r = 59 Computes re B mod φ(n B ) = mod 60 = 7 Replace public key e B with 7; corresponding private key d B = 43 Bob claims contract was 13. Judge computes: (63 59 mod 95) 43 mod 77 = 13 Verified; now Alice is toast May 18, 2004 ECS 235 Slide #23 El Gamal Digital Signature Relies on discrete log problem Choose p prime, g, d < p; compute y = g d 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 = g k mod p Find b such that m = (da + kb) mod p 1 Signature is (a, b) To validate, check that y a a b mod p = g m mod p May 18, 2004 ECS 235 Slide #24 12

13 Example Alice chooses p = 29, g = 3, d = 6 y = 3 6 mod 29 = 4 Alice wants to send Bob signed contract 23 Chooses k = 5 (relatively prime to 28) This gives a = g k mod p = 3 5 mod 29 = 11 Then solving 23 = ( b) mod 28 gives b = 25 Alice sends message 23 and signature (11, 25) Bob verifies signature: g m mod p = 3 23 mod 29 = 8 and y a a b mod p = mod 29 = 8 They match, so Alice signed May 18, 2004 ECS 235 Slide #25 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 ) mod 28 so Alice s private key is d = 6 May 18, 2004 ECS 235 Slide #26 13

14 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 Slide #27 Overview Basics Passwords Storage Selection Breaking them Other methods Multiple methods May 18, 2004 ECS 235 Slide #28 14

15 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 Slide #29 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 Slide #30 15

16 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 Slide #31 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 Slide #32 16

17 Passwords Sequence of characters 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 Slide #33 Storage Store as cleartext 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 Slide #34 17

18 Example UNIX system standard hash function 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 Slide #35 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 Slide #36 18

19 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 Slide #37 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 Slide #38 19

20 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 Slide #39 Example Goal Passwords drawn from a 96-char alphabet Can test 10 4 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 = ( ) 10 4 /0.5 = Choose s such that Σ s j=0 96 j N So s 6, meaning passwords must be at least 6 chars long May 18, 2004 ECS 235 Slide #40 20

21 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 Slide #41 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 Slide #42 21

22 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 Slide #43 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 Slide #44 22

23 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 Slide #45 23