Outline Key Management Properties of keys CS 239 Key management - PDF document

Outline Key Management • Properties of keys CS 239 • Key management Computer Security • Key servers February 7, 2005 –Kerberos • Certificates Lecture 8 Lecture 8 Page 1 Page 2 CS 239, Winter 2005 CS 239, Winter 2005 Introduction Properties of Keys • It doesn’t matter how strong your • Length encryption algorithm is • Randomness • Or how secure your protocol is • Lifetime • If the opponents can get hold of your keys, your security is gone • Proper use of keys is crucial to security in computing systems Lecture 8 Lecture 8 Page 3 Page 4 CS 239, Winter 2005 CS 239, Winter 2005 Are There Real Costs for Key Key Length Length? • If your cryptographic algorithm is • Clearly, more bits is more secure otherwise perfect, its strength depends • Why not a whole lot of key bits, then? on key length • Much encryption done in hardware – More bits in hardware costs more • Since the only attack is a brute force • Software encryption slows down as you add attempt to discover the key more bits, too • The longer the key, the more brute – Public key cryptography costs are highly force required dependent on key length Lecture 8 Lecture 8 Page 5 Page 6 CS 239, Winter 2005 CS 239, Winter 2005 1

Key Randomness Generating Random Keys • Well, don’t use rand() • Brute force attacks assume you chose your • The closer the method chosen approaches key at random true randomness, the better • If the attacker can get any knowledge about • But, generally, don’t want to rely on exotic your mechanism of choosing a key, he can hardware substantially reduce brute force costs • True randomness is not essential • How good is your random number – Need same statistical properties generator? – And non-reproducibility Lecture 8 Lecture 8 Page 7 Page 8 CS 239, Winter 2005 CS 239, Winter 2005 Cryptographic Methods Random Noise • Start with a random number • Observe an event that is likely to be random • Use a cryptographic hash on it • Assign bit values to possible outcomes • If the cryptographic hash is a good one, the • Record or generate them as needed new number looks pretty random • Sources: • Produce new keys by hashing old ones – Physical processes (cosmic rays, etc.) • Depends on strength of hash algorithm – Real world processes (variations in disk • Falls apart if any key is ever broken drive delay, keystroke delays, etc.) – Doesn’t have perfect forward secrecy Lecture 8 Lecture 8 Page 9 Page 10 CS 239, Winter 2005 CS 239, Winter 2005 Don’t Go Crazy on Randomness Key Lifetime • Make sure it’s non-reproducible • If a good key’s so hard to find, – So attackers can’t play it back –Why every change it? • Make sure there aren’t obvious patterns • How long should one keep using a • Attacking truly unknown patterns in fairly given key? random numbers is extremely challenging – They’ll probably mug you, instead Lecture 8 Lecture 8 Page 11 Page 12 CS 239, Winter 2005 CS 239, Winter 2005 2

Why Change Keys? Practicalities of Key Lifetimes • Long-lived keys more likely to be compromised • In some cases, changing keys is inconvenient • The longer a key lives, the more data is exposed if it’s compromised – E.g., encryption of data files • The longer a key lives, the more resources • Keys used for specific communications opponents can (and will) devote to breaking it sessions should be changed often • The more a key is used, the easier the – E.g., new key for each phone call cryptanalysis on it • A secret that cannot be readily changed should be • Keys used for key distribution can’t be regarded as a vulnerability changed too often Lecture 8 Lecture 8 Page 13 Page 14 CS 239, Winter 2005 CS 239, Winter 2005 Destroying Old Keys Key Management • Never keep a key around longer than • Choosing long, random keys doesn’t necessary do you any good if your clerk is selling – Gives opponents more opportunities them for $10 a pop at the back door • Destroy keys securely • Or if you keep a plaintext list of them – For computers, remember that on a computer on the net whose root information may be in multiple places password is “root” • Caches, virtual memory pages, freed • Proper key management is crucial file blocks, stack frames, etc. Lecture 8 Lecture 8 Page 15 Page 16 CS 239, Winter 2005 CS 239, Winter 2005 Desirable Properties in a Key Users and Keys Management System • Secure • Where are a user’s keys kept? • Fast • Permanently on the user’s machine? • Low overhead for users – What happens if the machine is cracked? • Scaleable • But people can’t remember random(ish) keys • Adaptable – Hash keys from passwords/passphrases? – Encryption algorithms • Keep keys on smart cards? – Applications • Get them from key servers? – Key lengths Lecture 8 Lecture 8 Page 17 Page 18 CS 239, Winter 2005 CS 239, Winter 2005 3

Security Measures for Key Security of Key Servers Servers • Don’t run anything else on the machine • The key server is the cracker’s holy • Use extraordinary care in setting it up and grail administering it –If they break the key server, • Watch it carefully everything else goes with it • Use a key server that stores as few keys • What can you do to protect it? permanently as possible • Use a key server that handles revocation and security problems well Lecture 8 Lecture 8 Page 19 Page 20 CS 239, Winter 2005 CS 239, Winter 2005 Kerberos The Kerberos Model • Probably the most widely used and • Clients and servers sit on the network well-known key server • Clients want to interact securely with • Originally developed at MIT servers –As part of Project Athena –Using a fresh key for each session • Uses trusted third parties • Kerberos’ job is to distribute keys to ensure that security –And symmetric cryptography • Scalability is a concern • Provides authentication in key service Lecture 8 Lecture 8 Page 21 Page 22 CS 239, Winter 2005 CS 239, Winter 2005 Obtaining a Key Through What’s the Point of the Ticket- Kerberos Granting Server? • The client needs to get a key to give to the • Scalability server and use himself – Most requests for keys for servers go to • He obtains the key from a ticket-granting ticket-granting server server – There can be lots of them – Essentially, a server who hands out keys • And issues of trust to talk to other servers – Different ticket-granting servers can work • But the ticket-granting server needs with different servers and clients authentication of the client – So not everyone needs to trust one ticket- • Which is obtained from the Kerberos server granting server Lecture 8 Lecture 8 Page 23 Page 24 CS 239, Winter 2005 CS 239, Winter 2005 4

Players in the Kerberos Protocol Kerberos Participants • The client • The server Client • The Ticket-Granting Service - Kerberos someone the server trusts to authenticate the clients • The Kerberos Server - someone everyone trusts Ticket-Granting Server Server Lecture 8 Lecture 8 Page 25 Page 26 CS 239, Winter 2005 CS 239, Winter 2005 Client Requests a Ticket- Kerberos Sends the Client a Granting Ticket From Kerberos Ticket-Granting Ticket I need to talk to the Ticket-Granting Server Client Client Kerberos Kerberos Ticket-Granting Ticket-Granting Server Server Server Server Lecture 8 Lecture 8 Page 27 Page 28 CS 239, Winter 2005 CS 239, Winter 2005 Client Asks TGS for a Server TGS Sends Ticket to Client Ticket Client Client Kerberos Kerberos Ticket-Granting Server checks ticket validity Ticket-Granting Ticket-Granting Server Server Server Server Lecture 8 Lecture 8 Page 29 Page 30 CS 239, Winter 2005 CS 239, Winter 2005 5

Client Requests Service Tickets and Authenticators • A Kerberos ticket is used to pass information to a server securely Client • An authenticator is an additional Kerberos credential passed along with the ticket –Used to pass timestamp information Server checks ticket about lifetime of a key Ticket-Granting Server Server Lecture 8 Lecture 8 Page 31 Page 32 CS 239, Winter 2005 CS 239, Winter 2005 What’s In a Ticket Kerberos in More Detail: Step 1 • T C,S = s, {c,a,v,K C,S }K S Alice, Tracy • s is the server • c is the client Client Alice Kerberos • a is the client’s network address • v is a timestamp • K C,S is a session key • K S is the server’s key Ticket-Granting Server Sidney Tracy Server Lecture 8 Lecture 8 Page 33 Page 34 CS 239, Winter 2005 CS 239, Winter 2005 Kerberos Sends Client Ticket- So What Has the Client Got? Granting Ticket {K Alice,Tracy }K Alice , • K Alice is derived from her password T Alice,Tracy = Tracy, • Which gets a session key allowing her to {Alice, xxx.xxx.xxx.xxx ,T Now , communicate securely with the TGS Alice K Alice,Tracy }K Tracy Kerberos – K Alice,Tracy • And she has a ticket for the TGS What’s in – Not directly usable by Alice the ticket? – But the TGS (Tracy) can use it to authenticate Alice Tracy Sidney Lecture 8 Lecture 8 Page 35 Page 36 CS 239, Winter 2005 CS 239, Winter 2005 6