1 / 22

Key Management

Key Management. Sandy Kutin CSPP 532 7/24/01. 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

ledell
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related