1 / 35

Key Management The Connection Between Policy and Encryption

`. Key Management The Connection Between Policy and Encryption. Terence Spies CTO Voltage Security. Agenda. Encryption as a security mechanism The emergence of key management Key management technologies

Download Presentation

Key Management The Connection Between Policy and Encryption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 ***

More Related