key management n.
Skip this Video
Loading SlideShow in 5 Seconds..
Key Management PowerPoint Presentation
Download Presentation
Key Management

Loading in 2 Seconds...

play fullscreen
1 / 22

Key Management - PowerPoint PPT Presentation

Download Presentation
Key Management
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Key Management Sandy Kutin CSPP 532 7/24/01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  22. Recommended Reading • Miller-Rabin primality testing: Stallings, Section 7.4 • Key management: Austin, Chapter 4 • Key publication, Certificate Authorities: • Stallings, Section 6.3 • Austin, Chapter 5 • PGP: Stallings, Section 12.1