1. Dr. Nermin Hamza

2.  “Encryption is easy. Key management is hard. Really hard.  The difficulty arises not from the complexity of keys and encryption schemes, approaches to them, or their applications, but from the impacts of encrypted data to operational systems and procedures.  One perspective on key management provides insight into implementing encrypted data storage in a typical n-tiered system and identifying the impacted concerns with appropriate implementation strategies for mitigating them.”

3.  Key Management: process of generating, storing, agreeing upon and revoking keys

4. Assuming that you’ve selected an appropriate, well vetted symmetric encryption technology, managing the keys that will be used to perform encryption and decryption is comprised of: ◦ Key Generation ◦ Key Storage ◦ Key lifetime (cryptoperiod) ◦ Key Distribution ◦ Key exchange

5.  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

6.  Secret to store for later use ◦ Cryptographic key (private) ◦ Password or any info system’s security depends on  Recall a principle: security should depend not on secrecy of algorithm, but on secrecy of cryptographic keys

7.  Options for storing secrets? ◦ 1. keys on files on disk ◦ 2. “Hard to Reach” Places ◦ 3. Storing Secrets in External Devices

8.  Alternative to storing in source code, could store in file on disk  Attacker with read access could ◦ Find files with high entropy (randomness) ◦ These would be candidate files to contain keys

9.  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

10.  Store secrets in device external to computer! ◦ Key won’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

11.  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

12.  Key Disk ◦ USB, non-volatile memory, 2 nd 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

13. 13 Key life time: 1- key creation 2- key used 3- key expiration 4- key archiving

14. COMP4690, HKBU14  given parties A and B, we can have various key distribution alternatives: 1.A can select key and physically deliver to B 2.A third party can select & deliver key to A & B 3.if A & B have previously used a key, can use previous key to encrypt a new key 4.if A & B have secure communications (by encryption) with a third party C, C can relay key between A & B

15.  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?  Use symmetric Keys  Diffie-Hellman (DH) Key Exchange

16. COMP4690, HKBU16  symmetric schemes require both parties to share a common secret key  issue is how to securely distribute this key  often secure system failure due to a break in the key distribution scheme

17. 17  Ideally you have separate secure channel for exchanging keys ◦ Direct secret sharing grows at N 2 Telephone, separate data network, ESP, sneaker net Regular data network

18. 18  Generally separate channel is not practical ◦ No trustworthy separate channel ◦ Want to scale linearly with additional users Regular data network Key Exchange K A,K B, … K Z KAKA KBKB

19. 19  “Classical” means “no public key infrastructure”  Bootstrap problem: how do Alice, Bob begin? ◦ Alice can’t send it to Bob in the clear!  Assume trusted third party, Cathy ◦ Alice and Cathy share secret key k A ◦ Bob and Cathy share secret key k B  Use this to exchange shared key k s

20. 20 Alice Cathy { request for session key with Bob } k A Alice Cathy { k s } k A || { k s } k B Alice Bob { k s } k B Eve Bob { k s } k B Notice : Cathy gives Alice the job of sending key to Bob Notice : Eve might break key, and entice Bob to use it with her or might simply replay the communication Alice had with Bob using that key

21. COMP4690, HKBU21  KDC: key distribution center ◦ Every user share a unique master key with KDC  A and B communicate using a session key. ◦ The session key is used for the duration of a logical connection. ◦ Session key is generated by KDC dynamically.

22. COMP4690, HKBU22

23.  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

24. Alice Bob { CK=8a6cd93b2b4f8803 } RSA(XYZ) { Hello Alice } AES(8a6cd93b2b4f8803) I am Bob. My public key is XYZ. Asymmetric (e.g. RSA) AliceBob {k} PK(B) {data} k Symmetric (e.g. AES)

25. COMP4690, HKBU25  Assume A and B have securely exchanged public- keys.  It can provide confidentiality and authentication.

26. COMP4690, HKBU26  first public-key type scheme proposed  by Diffie & Hellman in 1976 along with the exposition of public key concepts ◦ note: now know that James Ellis (UK CESG) secretly proposed the concept in 1970  is a practical method for public exchange of a secret key  used in a number of commercial products

27. COMP4690, HKBU27  a public-key distribution scheme ◦ cannot be used to exchange an arbitrary message ◦ rather it can establish a common key ◦ known only to the two participants  value of key depends on the participants (and their private and public key information)  based on exponentiation in a finite (Galois) field (modulo a prime or a polynomial) – easy  security relies on the difficulty of computing discrete logarithms (similar to factoring) – hard

28. COMP4690, HKBU28

29. COMP4690, HKBU29  all users agree on global parameters: ◦ large prime integer q ◦ α a primitive root of q  each user (eg. A) generates their key ◦ chooses a secret key (number): x A < q ◦ compute their public key: y A = α x A mod q  each user makes public that key y A

30. COMP4690, HKBU30  shared session key for users A & B is K AB : K AB = α x A. x B mod q = y A x B mod q (which B can compute) = y B x A mod q (which A can compute)  K AB is used as session key in private-key encryption scheme between Alice and Bob  if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys  attacker needs an x, must solve discrete log

31. COMP4690, HKBU31  users Alice & Bob who wish to swap keys:  agree on prime q=353 and α=3  select random secret keys: ◦ A chooses x A =97, B chooses x B =233  compute public keys: ◦ y A = 3 97 mod 353 = 40 (Alice) ◦ y B = 3 233 mod 353 = 248 (Bob)  compute shared session key as: K AB = y B x A mod 353 = 248 97 = 160 (Alice) K AB = y A x B mod 353 = 40 233 = 160 (Bob)

32.  A Key Exchange Protocol: ◦ provide a secure way for two communicating parties to share a symmetric key (so called a session key) ◦ This session key is then used to provide privacy and authentication for subsequent message flow. ◦ History: problem first posed by Merkle at UC Berkeley, Diffie and Hellman came up with the protocol: Alice Bob a  R Z p-1 g a mod p g b mod p b  R Z p-1 Shared Session Key = g ab mod p More details next…

33.  Alice and Bob agree on global parameters: ◦ Large prime integer p (e.g. 1024 bits long) ◦ g a primitive root / generator of Z p * (i.e. the multiplicative group modulo p)  Alice ◦ chooses a random positive integer: a < p ◦ computes y A = g a mod p  Bob does the same and generates y B = g b mod p

34.  Shared session key for Alice and Bob is K AB : K AB = g a b mod p = y A b mod p(which Bob can compute) = y B a mod p(which Alice can compute)  K AB will then be used as a session key in symmetric key algorithms between Alice and Bob  Attacker needs to find K AB from y A and y B ◦ A difficult problem

35. Alice and Bob want to carry out DH Key Exchange: 1. Agree on prime p=353 and g=3 2. Select random secret keys: ◦ A chooses a = 97 ◦ B chooses b = 233 3. Compute session key contributions ◦ y A = 3 97 mod 353 = 40 (Alice) ◦ y B = 3 233 mod 353 = 248 (Bob) 4. Compute shared session key as: K AB = y B a mod 353 = 248 97 mod 353 = 160 (Alice) K AB = y A b mod 353 = 40 233 mod 353 = 160 (Bob)