14 key management & exchange

  • 276 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
276
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Welcome to SEC103 on Secure Programming Techniques. In this course, I assume that you have some background in computer security, but now you want to put that background to use. For example, in the Computer Security Principles and Introduction To Cryptography courses, we cover topics such concerning trust and encryption. In this course, we put these principles into to practice, and I’ll show you have to write secure code that builds security into your applications from the ground up.
  • Because encryption can be used for purposes other than confidentiality, security systems use encryption in many places. We have seen encryption used to achieve confidentiality and authentication. However, encryption can also be used as a primitive to achieve other security goals as well. In some systems, when different algorithms are often used for different purposes, but all of these algorithms require us to use keys. As a result, it is often useful to make a distinction between different types of keys that are used for different purposes. Since asymmetric encryption is very costly/expensive (RSA encryption takes 1000 times as long as DES encryption), it is typically only used for authentication. Symmetric encryption, due to its relative efficiency, can be used for authentication as well as confidentiality purposes. Authentication typically happens once per connection set up between two parties, and some keys might be used in order to accomplish the authentication. Keys that are used to accomplish authentication are typically referred to as “identity” keys. Identity keys (such as a user’s private key) are generated by the principal whom that key authenticates. Since they are used to authenticate a principal, and the lifetime of a principal might be long (i.e., up to 100 years), we use key lengths that would generally not be break-able within that timeframe. On the other hand, we might use a key to encrypt the contents of a conversation with another party, and this type of key is often referred to as a “conversation key” or a “session key.” Since we may only care about protecting the contents of a particular conversation for say 1 year or 5 years, we can use a key length for a conversation key that is shorter than a identity key. In addition, either party may generate the conversation key (assuming that both parties are, to an extent, “trusted”), or the conversation key may partly be generated by each party.
  • We might be able to prevent a man-in-the-middle attack by using public-key crypto to do the key exchange. In the protocol above, the first two messages are still susceptible to spoofing.
  • In this slide, we will talk about a protocol called Diffie-Hellman (DH) Key Exchange which allows two parties to agree upon a key without ever meeting, and without relying on an alternate secure channel. In DH, both Alice and Bob execute the protocol using some public parameters g and p that everyone knows. P is a (large) prime number, and g is a “generator.” This means that as we raise g to successive powers g^1, g^2, we get back all numbers 0 to p-1. After these two public parameters have been chosen, any two parties that know the public parameters can participate in a key exchange. In DH, Alice generates a random number a, and Bob generates a random number b. Parameters a and b are used to create a key that will be known to only Alice and Bob even if a passive eavesdropper can view the contents of their conversation. This happens as follows: after Alice and Bob choose a and b, respectively, they do not transmit a or b to each other. Instead, Alice transmits g^a mod p to Bob and Bob transmits g^b mod p to Alice. Alice takes the g^b mod p that she received, and raises it to the power a thereby computing g^b^a mod p. Bob takes the g^a mod p that he received, and raises it to the power b thereby computing g^a^b mod p. Now, Alice and Bob both know g^a^b (since g^b^a = g^a^b), and that is the key that they now share. Can Eve possibly have computed g^a^b by eavesdropping? They answer is no. Eve saw g^a and g^b go across the wire, and Eve could multiply these two numbers together, but that will give Eve g^(a+b); not g^a^b! As a result, Alice and Bob are able to agree upon a key even if the channel is susceptible to eavesdropping! However, while DH is not susceptible to passive eavesdropping in with the attacker can only listen to the information going by on the wire, DH is susceptible to active eavesdropping in which the attacker can not only listen to the information going by on the wire, but is also capable of modifying the messages.
  • Let’s look at how an attacker can construct a “man-in-the-middle” attack against DH. Let’s say that Mallory is able to listen to the communications being exchanged between Alice and Bob and is able to modify the contents. We will see that Mallory will be able to fool Alice in thinking that she has successfully participated in a key exchange with Bob, and that Bob can be fooled into thinking that he has successfully participated in a key exchange with Alice. The protocol starts off as before, with Alice choosing a secret random number, a. Alice sends g^a to Bob, but Mallory intercepts it. Mallory chooses a secret random number, m, and sends g^m to Bob instead of g^a. As a result, Bob receives g^m. Bob also attempts to engage in the protocol as expected: he generates g^b and attempts to send it to Alice. Unfortunately, Mallory intercepts g^b as well, and replaces it with g^m, sending g^m to Alice. Alice ends up computing g^m^a, and Bob ends up computing g^m^b. Mallory can compute both g^m^a and g^m^b. As a result, Mallory will be able to see any message that Alice attempts to send to Bob using the secret key g^m^a, and will be able to see any message that Bob attempts to send to Alice using the secret key g^m^b. Mallory is the “man-in-the-middle” and can impersonate either Alice or Bob. While we have shown that we can do a key exchange using DH, this method is unfortunately susceptible to a man-in-the-middle attack. How can we do a key exchange that is resilient to this attack?

Transcript

  • 1. CHAPTER 14 Key Management & ExchangeSlides adapted from "Foundations of Security: What Every ProgrammerNeeds To Know" by Neil Daswani, Christoph Kern, and Anita Kesavan(ISBN 1590597842; http://www.foundationsofsecurity.com). Except asotherwise noted, the content of this presentation is licensed under theCreative Commons 3.0 License.
  • 2. Agenda Key Management: process of generating, storing, agreeing upon and revoking keys Generation: How should new keys be created? Storage: How to securely store keys so they can’t be stolen? Agreement: How do 2 parties agree on a key to protect secrets?
  • 3. 14.1. Types of Keys Encryption keys can be used to accomplish different security goals Identity Keys Conversation or Session Keys Integrity Keys One Key, One Purpose: Don’t reuse keys!
  • 4. 14.1.1. Identity Keys Used to help carry out authentication Authentication once per connection between two parties Generated by principal, long-lifetime (more bits) Bound to identity with certificate (e.g. public keys in asymmetric system)
  • 5. 14.1.2. Conversation or SessionKeys Helps achieve confidentiality Used after 2 parties have authenticated themselves to each other Generated by key exchange protocol (e.g. Diffie- Hellman algorithm) Short-lifetime (fewer bits)
  • 6. 14.1.3. Integrity Keys Key used to compute Message Authentication Codes (MACs) Alice and Bob share integrity key  Can use to compute MACs on message  Detect if Eve tampered with message Integrity keys used in digital signatures
  • 7. 14.2. Key Generation Key generated through algorithms (e.g. RSA)  Usually involves random # generation as a step  But for IBE, also need PKG, master key Avoid weak keys (e.g. in DES keys of all 1s or 0s, encrypting twice decrypts) Don’t want keys stolen: After generation  Don’t store on disk connected to network  Also eliminate from memory (avoid core dump attack) Generating keys from passwords: Use password-based encryption systems (e.g. PKCS #5) to guard against dictionary attacks
  • 8. 14.2.1. Random NumberGeneration Ex: Alice & Bob use RSA to exchange a secret key for symmetric crypto (faster)  Alicegenerates random # k  Sends to Bob, encrypted with his public key  Then use k as key for symmetric cipher But if attacker can guess k, no secrecy Active eavesdropper can even modify/inject data into their conversation Problem: Generating hard to guess random #s
  • 9. 14.2.2. The rand() function How about using rand() function in C?  Uses linear congruential generator  After some time, output repeats predictably Can infer seed based on few outputs of rand()  Allows attacker to figure out all past & future output values  No longer unpredictable Don’t use for security applications
  • 10. 14.2.3. Random Device Files Virtual devices that look like files: (e.g. on Linux)  Reading from file provides unpredictable random bits generated based on events from booting  /dev/random – blocks until random bits available  /dev/urandom – doesn’t block, returns what’s there $ head -c 20 /dev/random > /tmp/bits # read 20 chars $ uuencode --base64 /tmp/bits printbits # encode, print begin-base64 644 printbits bj4Ig9V6AAaqH7jzvt9T60aogEo===== # random output
  • 11. 14.2.4. Random APIs Windows OS: CryptGenKey() – to securely generate keys Java: SecureRandom class in java.security package (c.f. AESEncrypter example, Ch. 12)  Underlying calls to OS (e.g. CryptGenKey() for Windows or reads from /dev/random for Linux)  No guarantees b/c cross-platform  But better than java.util.Random
  • 12. 14.3. Key (Secret) Storage Secret to store for later use  Cryptographickey (private)  Password or any info system’s security depends on Recall Kerchoff’s principle: security should depend not on secrecy of algorithm, but on secrecy of cryptographic keys Options for storing secrets?
  • 13. 14.3.1. Keys in Source Code Ex: Program storing a file on disk such that no other program can touch itMight use key to encrypt file: Where to store it? Maybe just embed in source code? Easy since you can use at runtime to decrypt. Can reverse-engineer binary to obtain the key (even if obfuscated) e.g. strings utility outputs sequence of printable chars in object code
  • 14. 14.3.1. Reverse-Engineering/* vault program (from 6.1.2) */ # partial output of printable1 int checkPassword() { # characters in object code2 char pass[16]; $ strings vault3 bzero(pass, 16); // Initialize C@@0@4 printf ("Enter password: "); $ @5 gets(pass); Enter password:6 if (strcmp(pass, "opensesame") == 0) opensesame7 return 1; __main8 else _impure_ptr9 return 0; Key Leaked! calloc10 } cygwin_internal11 dll_crt0__FP11per_process12 void openVault() { free13 // Opens the vault gets14 } malloc15 printf16 main() { realloc17 if (checkPassword()) { strcmp18 openVault(); GetModuleHandleA19 printf ("Vault opened!"); cygwin1.dll20 } KERNEL32.dll21 }
  • 15. 14.3.2. Storing the Key in a Fileon Disk Alternative to storing in source code, could store in file on disk Attacker with read access could  Findfiles with high entropy (randomness)  These would be candidate files to contain keys C.f. “Playing Hide and Seek with Stored Keys” (Shamir and van Someren)
  • 16. 14.3.3. “Hard to Reach” Places Store in Windows Registry instead of file?  Part of OS that maintains config info  Not as easy for average user to open But regedit can allow attacker (or slightly above-average user) to read the registry  Also registry entries stored on disk  Attacker with full read access can read them Registry not the best place to store secrets
  • 17. 14.3.4. Storing Secrets inExternal Devices (1) Store secrets in device external to computer!  Keywon’t be compromised even if computer is  Few options: smart card, HSMs, PDAs, key disks Smart Card (contains tamper-resistant chip)  Limited CPU power, vulnerable to power attacks  Must rely on using untrusted PIN readers  Attacker observes power of circuits, computation times to extract bits of the key
  • 18. 14.3.4. Storing Secrets inExternal Devices (2) Hardware Security Module (HSM)  Device dedicated to storing crypto secrets  External device, add-on card, or separate machine  Higher CPU power, key never leaves HSM (generated and used there) PDA or Cell phone  No intermediate devices like PIN readers  More memory, faster computations  Can have security bugs of their own
  • 19. 14.3.4. Storing Secrets inExternal Devices (3) Key Disk  USB, non-volatile memory, 2nd factor  No CPU, not tamper-resistant  No support for authentication  Ex: IronKey, secure encrypted flash drive External Devices & Keys  Allows key to be removed from host system  Problem: connected to compromised host  Advantage: if crypto operation done on device & key never leaves it, damage limited  Can attack only while connected, can’t steal key
  • 20. 14.4. Key Agreement andExchange Keys have been generated and safely stored, now what?  If Alice & Bob both have it, can do symmetric crypto  Otherwise, have to agree on key How to create secure communication channel for exchange? Few Options  Use Asymmetric Keys  Diffie-Hellman (DH) Key Exchange
  • 21. 14.4.1. Using Asymmetric Keys Public-key crypto much more computationally expensive than symmetric key crypto Use RSA to send cryptographically random conversation key k Use k as key for faster symmetric ciphers (e.g. AES) for rest of conversation
  • 22. A Word of Caution In the following example, as well as some other examples presented in later chapters, the simple toy protocols that we discuss are for instructive and illustration purposes only. They are designed to make concepts easy to understand, and are vulnerable to various types of attacks that we do not necessarily describe. Do not implement these protocols as is in software.
  • 23. 14.4.1. Key Exchange Example I am Bob. My public key is XYZ. Alice Bob {CK=8a6cd93b2b4f8803}RSA(XYZ) {Hello Alice}AES(8a6cd93b2b4f8803) Asymmetric (e.g. RSA) {k} PK(B) Alice {data} k Bob {data} k Symmetric (e.g. AES)
  • 24. 14.4.2. Diffie-Hellman (DH) (1) Key exchange (over insecure channel) without public-key certificates? DH: use public parameters g, p  Large prime number p  Generator g (of Zp = {1, …, p-1}), i.e. powers g, g2, …, gp-1 produce all these elements Alice & Bob generate rand #s a, b respectively Using g, p, a, b, they can create a secret known only to them (relies on hardness of solving the discrete log problem)
  • 25. 14.4.2. Diffie-Hellman (DH) (2) Alice Bob Choose a ga mod p Choose b gb mod pCompute (g b ) a Compute mod p (g a ) b mod p Secret Key = g ab mod p Eve can compute (ga)(gb)= ga+b mod p but that’s not the secret key!
  • 26. 14.4.2. Man-in-the-Middle Attack against DH Alice Mallory Bob Choose a ga Choose m Choose b gm gb Compute (gb)m Compute (gm)b gm Compute (ga)mCompute (gm)a Secret Key = g am Secret Key = g bm Mallory can see all communication between Alice & Bob!
  • 27. 14.4.2. Detecting Man-in-the-Middle Attack Both Alice and Bob can compute hash of the shared secret h(gab) and display it Mallory’s secret key w/ Bob different from key with Alice (gam ≠ gbm), hashes also different If hashes don’t correspond, then there must have been a man in the middle! Proposed by P. Zimmermann in VoIP protocol ZRTP
  • 28. Summary Key Management consists of generation, storage, and agreement/exchange Key Types: Identity, Session, Integrity Key Generation  Problem is random number generation  Use device files or SecureRandom Java API Key Storage: use external devices Key Exchange:  Public-keycrypto  DH – guard against man-in-the-middle attack