` Key Management The Connection Between Policy and Encryption Terence Spies CTO Voltage Security
*** Confidential and Proprietary *** 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 *** Encryption is Inevitable Classic access control protects edges Outsourcing, partnering, customer data access All create new, complex edges Cant control all of them anymore Encryption protects without edges
*** Confidential and Proprietary *** The use of encryption has changed 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, , database enc Data encryption Large user set External, ad hoc users New apps and protocols
*** Confidential and Proprietary *** Policy drives this evolution 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 s of keys User, group, role auth
*** Confidential and Proprietary *** Key Management 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
*** Confidential and Proprietary *** Data Encryption is Easy! Well, its at least understood….but not really But we can ignore the core crypto for now Do this 10 times:
*** Confidential and Proprietary *** Encryption is easy, Key Management is hard Encryption Key Decryption Key How do we make sure both sides have the right keys?
*** Confidential and Proprietary *** 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 *** New Model Key Management SSL/VPN model One certificate per domain Costly enrollment process (~$150/cert) keys Policy based encryption model One key per user or group Cant pay $150/directory entry! MM keys Makes a difficult problem a nearly impossible one
*** Confidential and Proprietary *** How is key management done? Central server Symmetric key, ie. Kerberos Certificates Public key, ie. Classic PKI Identities Identity-based Encryption
*** Confidential and Proprietary *** 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 *** 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 *** 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 originators 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 *** Key Management for Symmetric Keys Example: 8 devices Key Store 28 keys How many keys total for 8 people? Key Server
*** Confidential and Proprietary *** 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 *** 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 *** Seems simple…. Except that its 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 *** 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 Invited by IETF to form new extension to S/MIME
*** Confidential and Proprietary *** Identity-Based Encryption Basic Idea: Public-key Encryption where Identities are Public Keys IBE Public Key: RSA Public Key: Public exponent=0x10001 Modulus=
*** Confidential and Proprietary *** IBE does not need certificates Certificates bind Public Keys to Identities e.g. 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 *** How IBE Works in Practice: Alice Sends a File to Bob Key Server master secret public params public params key request + authenticate
*** Confidential and Proprietary *** How IBE Works in Practice: Alice Sends a File to Bob Key Server master secret public params public params Fully off-line - no connection to server required
*** Confidential and Proprietary *** Private Key Generation 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 Key Server Master Secret s = Request Private Key
*** Confidential and Proprietary *** 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 Authentication Key Server Auth Service
*** Confidential and Proprietary *** Key Revocation, Expiration and Policy What happens if I lose my private key? Key validity enables revocation – key freshness Every week public key changes, so every week a new private key is issued revocation can be done on weekly basis To revoke someone, simply remove him from the authentication mechanism (e.g. corporate directory) address key validity || week = 252
*** Confidential and Proprietary *** Federation The Voltage IBE System has built-in federation Bob Key Server Alice Key Server Directory Intranet of alpha.comIntranet of bravo.comInternet alphas secret bravos secret PP-Bravo Send to: bravo.com Fetch bravos PPs from Host public params at
*** Confidential and Proprietary *** Extending IBE: Groups and Policies IBE is not restricted to using identities as keys Encrypt to a group: 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: 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 *** Policy & IBE Key Server master secret public params public params key request + authenticate Portal PCI corp.com AAA System Is Bob allowed to access PCI data?
*** Confidential and Proprietary *** 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 = || HIPAA key = HIPAA
*** Confidential and Proprietary *** Policy Definition HIPAA Notify HIPAA Officer Machine Must Be HIPAA- Approved Delegate Access for HIPAA Admins External Auth via Strong Pass Internal Auth via Directory Log HIPAA event
*** Confidential and Proprietary *** 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 *** Policy History HIPAA July 1, 2004 HIPAA v3.5 HIPAA v3 HIPAA v2 HIPAA v1.5 HIPAA v1 May 19, 2005 Februrary 11, 2005 October 20, 2004 April 6, 2004 January 15, 2004 HIPAA
*** Confidential and Proprietary *** Federated Policy Enforcement + HIPAA Privacy Policy HIPAA applied at company A Content transferred via existing channel Policy enforced per rules of company B
*** Confidential and Proprietary *** Policy & IBE: Another View PCI = - US access only - Audit access to PCI admins - Log PCI event Define PCI policy on management server Determine data is PCI-relevant Apply PCI policy (encrypt) Enforce PCI policy
*** Confidential and Proprietary *** Key Management - Public Key Infrastructure Certificate Server binds Identity to Public Key Send Public Key, Authenticate Receive Certificate CA Signing Key Certification Authority CA Public Key Certificate Server Store Certificate Look up Bobs Certificate, Check revocation CA Public Key Bobs Private Key Bobs Public Key Recovery Server Store Bobs Private Key
*** Confidential and Proprietary *** Key Management - IBE Binding is done by mathematics IBE Key Server Master Secret Send Identity, Authenticate Receive Private Key Public Parameters Bobs Private Key Certificate Server Store Certificate Look up Bobs Certificate, Check revocation X Recovery Server Store Bobs Private Key X
*** Confidential and Proprietary *** 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 *** Key Management Futures Practically, where is all this going? IEEE Standardization of key management for storage Oasis TC for key management IETF Keyprov working group
*** Confidential and Proprietary *** 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