Key Management Sandy Kutin CSPP 532 72401 Last

Key Management Sandy Kutin CSPP 532 7/24/01

Last Week: PKI z. Public key algorithms (RSA) z. Bob has public key B, private key b z. Confidentiality: anyone can write to Bob z. Authentication: Bob can sign messages z. Non-repudiation: Signature usable in court z. Solves key distribution problem z. Leads to other problems

Key Questions z. Who is trusted? (Key publication) z. What if Bob is “terminated”? (Key recovery) z. Where do you keep a key? (Key storage) z. When does a key expire? (Key termination, key archival, key revocation) z. Why might the FBI see your key? (Key escrow) z. How do you create randomness on a computer? (Key generation)

Pretty Good Privacy z. First widespread implementation of RSA z. PGP, by Phil Zimmerman (June 1991) z. Free email implementation of RSA yencrypts with 3 DES, IDEA, or CAST-128 ysignatures (MD 5, SHA-1), compression, radix-64 z. Cross-platform; used around the world z. Commercial version also available z. We’ll use it as a reference point

Talkin’ ‘bout my generation z. Public/private pairs, and also session keys z. True random numbers: require user input y. PGP: Type; use letters, timing information y. Mouse movements sometimes used z. Convert weak randomness to strong ye. g. , a line of text to a 128 -bit key yuse encryption (also, hashing) yin theoretical CS, use hashes for this purpose

Pseudo-random Numbers z. How do you generate “random” numbers? z. PRNG: Pseudo-random number generator z. Example: Linear Congruential Generator y. X 0 = seed (e. g. , time) y. Xn+1 = a. Xn + c mod m z. This is what computers do; good for a lot z. Not good for key generation; easy to break y(Eve figures out one key, or a few; learns all)

CSPRBG (I’d like to buy a vowel) z. Cryptographically-secure pseudo-random bit generator: ygiven first k bits, no polynomial-time way to guess the k+1 th bit more than 50% of the time z. A few techniques; we’ll discuss them z. One simple idea: Xi = EK(i), or EK(PRNG) y(then, take a single bit) z. PGP uses a CSPRBG for session keys

Key Storage z. OK, I have a key; where do I put it? z. Hard drive unsafe. Brain unsafe. z. Three Authentication Factors: y. Knowledge Factor (password, PIN) y. Possession Factor (smart card, badge, key) y. Biometric Factor (retinal scan, voiceprint) z. Best to use a combination z. PGP: Knowledge, Possession

Key Storage in PGP z. Public/private pair B, b generated by PGP z. User inputs key K; save B, EK(b) to disk y. EK is CAST-128; 128 -bit key z. Problem: how do you remember 128 bits? z. User enters passphrase P; K = H(P) y. H is SHA-1, keeping only the first 128 bits z. Hash converts weak randomness to strong y. No structure to the 128 -bit value K

And the passphrase is. . . z. So how long should your passphrase be? z. An attacker can do 2128 work, guess K z. Should contain 128 bits of “entropy” y. English text: roughly 1 bit per character z. Bottom line: you have to remember it z. Other attacks anyway: y. Keyboard sniffers, memory dumps z. Solution: key in tamper-proof hardware

When good keys go bad z. Part of PKI policy: expiration dates yalgorithms become outdated yeven a good key can be overused yminimize damage if a key is compromised z. Key termination: stop using it z. Key archival: keep a copy somewhere z. Key revocation: tell everyone else it’s bad y. The hard part; we’ll discuss this in a bit

Has anybody seen my keys? z. Keys get lost. People are fired, or die. z. Backing up EK(b) is easy, but need b or K. z. Someone in the company has to have it. z. Key escrow: government has a copy y. Necessary for wiretaps; are taps necessary? y. Clipper, Capstone; no one trusted them z. One solution: secret-sharing schemes y. M people get pieces; any m can solve for b

Key publication z. How does Alice get Bob’s public key? z. We’ll call this “key publication” y. Another name: public-key management z. Original solution: “phone book” y. Who prints the book? y. What if it’s compromised, or intercepted? y. How do you look someone up? Unique ID? y. What if Bob has multiple names, keys? y. Do keys expire? What if a key is compromised?

Solution #1: Dispe. RSAL z. One idea: Carol meets Bob face-to-face z. Carol says “This is Bob’s key”, signs it z. Ted knows Carol, says “This is Carol’s key, and I trust her”, signs it z. Alice knows Ted; verifies chain of signatures z. Flaw #1: “weakest link” z. Flaw #2: >6 degrees of separation z. Flaw #3: Unique IDs, expiration, . . .

PGP: Web of Trust z. Refined version of the “chain of trust” z. Assign weight; how much do you trust a key? (“mine”, “always”, “usually”) z. See how many people, at what trust level, validate Bob’s key; if it’s enough, you trust the key z. Same problems with expiration/revocation, unique IDs, long chains, . . .

#2: Certificate Authorities z. Certificate Authority (CA): trusted by all z. CA representative verifies Bob’s key z. Combines his name, info, key, expiration date, etc. into a “certificate” z. Signs the certificate using the CA’s key z. Bob publicizes the certificate z. Alice knows CA’s public key, verifies; knows she’s communicating with Bob

A Labo. RSAving solution z. Obvious problem: whom do we trust? z. Not as bad as it sounds; commerce goes forward (e. g. , Veri. Sign) z. Second problem: how to verify everyone z. Hierarchical structure: yglobal, local, company, department, individual z. To verify a signature, work your way up z. The relevant question isn’t “whom do we trust? ”, but “whom can we sue? ”

A Bunch of Malar. Key z. Big problem: certificates are meaningless z. In January, 2001, someone got Veri. Sign to issue him/her Microsoft certificates z. Veri. Sign messed up: “human error” z. Bad certificates immediately placed on revocation list z. But Microsoft messed up: IE doesn’t check the list z. Patch issued. Have you installed it?

When I fight the CA, the CA always wins z. The CA has no good means of checking up on a potential customer z. Credit card databases wanted to get into CA business; thought they knew secrets z. SSN, Do. B, mother’s maiden name; all had been sold already, publicly available z. No secrets left z. The CA has an impossible job

Validation Authorities z. Austin, chapter 5: discusses VAs z. Issuing certificates is a separate job z. VA handles revocation, online confirmation, levels of trust z. Analogy for CA/VA split: credit cards y. Bank (CA) checks credit, identity; issues card y. Store checks card with Visa/Master. Card (VA) z. Isolates problems, doesn’t solve them

Ove. RSAturation z. Problem: so many certificates, so much information; how do you tell what’s safe? z. What does a certificate mean? Does it guarantee fiscal security? z. What do you do if a certificate appears not to match? Do you trust it anyway? z. Example: the HBO store

Recommended Reading z. Miller-Rabin primality testing: Stallings, Section 7. 4 z. Key management: Austin, Chapter 4 z. Key publication, Certificate Authorities: y. Stallings, Section 6. 3 y. Austin, Chapter 5 z. PGP: Stallings, Section 12. 1