Key Management The Connection Between Policy and Encryption

1. ` Key ManagementThe Connection Between Policy and Encryption Terence Spies CTO Voltage Security

2. Agenda • Encryption as a security mechanism • The emergence of key management • Key management technologies • Key management and encryption is no longer confined to silos (messaging, storage, networking) • Key management requires understanding overall access control and business policies • Business and technical leadership must cooperate *** Confidential and Proprietary ***

3. Encryption is Inevitable • “Classic” access control protects edges • Outsourcing, partnering, customer data access • All create new, complex edges • Can’t control all of them anymore • Encryption protects without edges *** Confidential and Proprietary ***

4. Encryption Yesterday Driver: Secrecy Sensitive communications Machine to machine protocols Connection encryption Static, machine keys SSL/VPN Data encryption Small user set Pre-enrolled users S/MIME, etc. Encryption Today Driver: Compliance, Privacy HIPAA, PCI, SB1386, SOX User and group protocols Document encryption Dynamic group & user keys App, email, database enc Data encryption Large user set External, ad hoc users New apps and protocols The use of encryption has changed *** Confidential and Proprietary ***

5. Old Model “Encrypt this data to a trusted machine” Plaintext on the trusted machine Defending against untrusted wires 10s - 100s of keys Machine authentication New Model “Encrypt this document to a trusted group” No stored plaintext anywhere Defending against untrsuted storage 1000s - 1000000s of keys User, group, role auth Policy drives this evolution *** Confidential and Proprietary ***

6. Key Management is the bridge between old and new Encryption is just a tool Key Management connects business policy to security enforcement What is Key Management How can Key Management be done? Key Management as a technology category Key Management *** Confidential and Proprietary ***

7. Data Encryption is Easy! Well, it’s at least understood….but not really But we can ignore the core crypto for now Do this 10 times: *** Confidential and Proprietary ***

8. How do we make sure both sides have the right keys? Encryption is easy, Key Management is hard Encryption Key Decryption Key *** Confidential and Proprietary ***

9. What is hard about managing keys? • Enrollment • Key creation, duplicate keys • Distribution • Lookup, Storage and Access • Finding the encryption key of a system • Recovery of decryption keys • Content scanning, filtering, audit • Archiving for compliance, supervision • Synchronizing distributed key stores • Key life cycle • Revoking keys, expiring keys • Backup of keys, disaster recovery *** Confidential and Proprietary ***

10. New Model Key Management • SSL/VPN model • One certificate per domain • Costly enrollment process (~$150/cert) • 10-100 keys • Policy based encryption model • One key per user or group • Can’t pay $150/directory entry! • 1000-1MM keys • Makes a difficult problem a nearly impossible one *** Confidential and Proprietary ***

11. How is key management done? • Central server • Symmetric key, ie. Kerberos • Certificates • Public key, ie. Classic “PKI” • Identities • Identity-based Encryption *** Confidential and Proprietary ***

12. The Basic Key Management Operations • Actors • The Authority • Trusted, can authenticate all participants • Originator • Wants to encrypt something to someone • Might be a group or an individual • Receiver • Authorized receiver *** Confidential and Proprietary ***

13. The Basic Key Management Operations • Operations • Authority, Originator, Receiver: Initialize • Originator: Get Encryption Key • Receiver: Get Decryption Key • We can compare scalability, efficiency, flexibility on these operations *** Confidential and Proprietary ***

14. Symmetric Key Management Basic principle: use the same encryption algorithm to manage keys • Initialize: • Receiver, Originator: share a key with the authority • Get Encryption Key • Authority sends K encrypted with originator’s key • Or, Receiver sends K encrypted with rec key • Get Decryption Key • Originator decrypts K • Or, originator requests K encrypted with org key *** Confidential and Proprietary ***

15. 7 8 8 3 2 5 6 7 3 1 2 3 4 5 6 7 1 1 2 5 4 6 8 .. .. .. 4 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. Key Management for Symmetric KeysExample: 8 devices Key Server Key Store How many keys totalfor 8 people? 28 keys *** Confidential and Proprietary ***

16. Certificate Based Key Management • Basic principle: use a public key algorithm • Public key in a nutshell: • Encrypt(M, K1) -> C • Decrypt(C, K2) -> M • Symmetric: K1 == K2 • Public key: K1 != K2 • Allows separation of who can encrypt and decrypt *** Confidential and Proprietary ***

17. Certificate Based Key Management • Initialize: • Authority: Generate a signing key • Receiver: Generate a key pair, E and D. Send E to Authority, who signs “Receiver” + E together • (this signed object is a certificate) • Originator: Get verification key from authority • Get Encryption Key • Originator: Get certificate (somehow…..), verify signature, extract key • Get Decryption Key • Receiver: Decrypt *** Confidential and Proprietary ***

18. Seems simple…. • Except that it’s never just A to B • How do you • Recover a key if a receiver disappears? • Distribute the database of certificates? • Make a certificate for a group? *** Confidential and Proprietary ***

19. Identity-Based Encryption (IBE) – Breakthrough in Cryptography • IBE - proposed 20 years ago as next generation encryption • In 1984 Adi Shamir, co-inventor of the RSA Algorithm, challenged cryptographers to invent IBE • IBE solution is created 2 decades later in 2001 • Research funded by DARPA (DoD research) • Boneh-Franklin Algorithm published at Crypto 2001 • An award-winning breakthrough in security and usability • Users no longer need to handle multitudes of passwords, keys, certificates or complex tools • Industry acceptance • Over 600 scientific publications on IBE/Pairings • Dan Boneh awarded 2005 RSA Conference Award for Mathematics • Standardization Efforts • IBE being standardized by IEEE 1363.3 • Invited by IETF to form new extension to S/MIME *** Confidential and Proprietary ***

20. Identity-Based Encryption Basic Idea: Public-key Encryption where Identities are Public Keys • IBE Public Key: alice@corp.com • RSA Public Key: Public exponent=0x10001 Modulus=13506641086599522334960321627880596993888147 560566702752448514385152651060485953383394028715 057190944179820728216447155137368041970396419174 304649658927425623934102086438320211037295872576 235850964311056407350150818751067659462920556368 552947521350085287941637732853390610975054433499 9811150056977236890927563 *** Confidential and Proprietary ***

21. IBE does not need certificates • Certificates bind Public Keys to Identities • e.g. bob@b.com has key 0x87F6… • Signed by a Certification Authority • In IBE, Identity and Public Key is the same • No certificate needed • No certificate revocation • No certificate servers • No pre-enrollment X *** Confidential and Proprietary ***

22. publicparams How IBE Works in Practice:Alice Sends a File to Bob master secret KeyServer key request + authenticate bob@corp.com bob@corp.com alice@corp.com publicparams *** Confidential and Proprietary ***

23. publicparams How IBE Works in Practice:Alice Sends a File to Bob master secret KeyServer Fully off-line - no connection to server required bob@corp.com bob@corp.com alice@corp.com publicparams *** Confidential and Proprietary ***

24. Master Secret is used to generate keys Each organization has a different secret Thus different security domains Server does not need to keep state No storage associated with server Easy load balancing, disaster recovery, high availability Private Key Generation Master Secret s = 1872361923616378 1872361923616378 Key Server Request Private Key bob@corp.com bob@corp.com *** Confidential and Proprietary ***

25. Authentication • IBE can support any method of authentication • Clean separation between encryption and authentication • Authentication is not tied to message • Can be changed over time • External auth integration • Leverage existing passwords, directories, portals, etc. • Out of the box support for ad-hoc, self-provisioning auth Auth Service Key Server *** Confidential and Proprietary ***

26. Extending IBE: Groups and Policies • IBE is not restricted to using identities as keys • Encrypt to a group: “hr@corp.com” • To retrieve the key, the user/application must authenticate as a member of the HR group • Leverage existing directory structures (AD, LDAP) • As group membership in directory changes, key access rights change dynamically as well • Encrypt to a policy name/classification: “PCI@corp.com” • To retrieve the key, the user/application must meet the policy defined at the server • Example: Asking for “PCI” key might query back-end ERP system and execute business logic • Effectively impossible to do with PKI • Group certificates create major revocation and distribution problems *** Confidential and Proprietary ***

27. publicparams Policy & IBE master secret Is Bob allowed to access PCI data? AAA System KeyServer key request + authenticate “PCI” “corp.com” Portal bob@yahoo.com alice@corp.com publicparams *** Confidential and Proprietary ***

28. Policy-Based Encryption: • Define canonical privacy policies • e.g. “HIPAA”, “PCI”, “Confidential”, “Classified”, … • Define elements of policy on server • e.g. “HIPAA” requires delegated access, auditing, etc. • Encrypting agents specify privacy policy as part of key • Do not need to understand individual policy elements • Privacy policy enforced by server • Policy can be modified over time key = “bob@b.com || HIPAA”key = “HIPAA” *** Confidential and Proprietary ***

29. Policy Definition “HIPAA” Internal Authvia Directory External Authvia Strong Pass Machine Must Be HIPAA-Approved DelegateAccess for HIPAA Admins Log HIPAA event Notify HIPAA Officer *** Confidential and Proprietary ***

30. Policy Based Key Management “HIPAA” = - US access only - Auth via SecurID - Log HIPAA event Define HIPAA enforcement policy on management server Identify & classify: Determine document contains HIPAA data Apply “HIPAA” privacy policy Enforce “HIPAA” privacy policy *** Confidential and Proprietary ***

31. Certification Authority Certificate Server StoreCertificate CA Signing Key CA Public Key RecoveryServer Send Public Key, Authenticate ReceiveCertificate Look up Bob’s Certificate, Check revocation Store Bob’s Private Key Key Management - Public Key InfrastructureCertificate Server binds Identity to Public Key CA Public Key Bob’s Private Key Bob’s Public Key alice@a.com bob@b.com *** Confidential and Proprietary ***

32. X Certificate Server StoreCertificate X RecoveryServer Look up Bob’s Certificate, Check revocation Store Bob’s Private Key Key Management - IBEBinding is done by mathematics IBE Key Server Master Secret Public Parameters SendIdentity, Authenticate ReceivePrivate Key Public Parameters Bob’s Private Key alice@a.com bob@b.com *** Confidential and Proprietary ***

33. Where do IBE & PKI fit together? • Key management encompasses three areas: • Authentication • PKI very applicable in certain scenarios • IBE-based auth architecture makes it easy to leverage certs, SecurID, etc. • Signatures • PKI works well for signatures • In fact, IBE architecture effectively uses PKI for signatures • Encryption • Where PKI has never really worked *** Confidential and Proprietary ***

34. Key Management Futures • Practically, where is all this going? • IEEE 1619.3 • Standardization of key management for storage • Oasis • TC for key management • IETF • Keyprov working group *** Confidential and Proprietary ***

35. Key Management Futures • You are going to be exposed to a new category of product, a central key manager • The underlying crypto mathematics will determine performance and costs *** Confidential and Proprietary ***