1 / 16

Key Management with the Voltage Data Protection Server

Key Management with the Voltage Data Protection Server. Luther Martin IEEE P1619.3 May 7, 2007. Overview. Key management with the Voltage Data Protection Server is motivated by the typical customer uses

marek
Télécharger la présentation

Key Management with the Voltage Data Protection Server

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 Management with the Voltage Data Protection Server Luther Martin IEEE P1619.3 May 7, 2007

  2. Overview • Key management with the Voltage Data Protection Server is motivated by the typical customer uses • An administrator defines policies at a central management console that pushes configuration and policy data to individual key servers • Management of symmetric keys is integrated with management of asymmetric keys (identity-based encryption) • Not really an API • Data is either Base64-encoded PKCS#7 or XML and is transported over HTTPS

  3. Typical use of the Voltage Data Protection System - 1 • Used to encrypt sensitive information in a database • Typically for PCI DSS compliance • In this case, encryption and decryption are both automated

  4. Typical use of the Voltage Data Protection System - 2 • Encrypting unstructured data in storage according to a security policy • Documents • Spreadsheets • Etc. • In this case, encryption may be automated but a human user may decrypt the data • May even be in a different security domain • “Federation”

  5. Design goals • Must support multiple cryptographic algorithms • Must support multiple authentication methods for each algorithm • Must work across multiple security domains • May require user interaction • Could be an application

  6. Components • Management console • Creates policies and pushes to key servers • Creates configuration data and pushes to key servers • Logs events and allows an authorized admin to review logs • Pulls logs from key servers • Key servers • Create and grant keys • Enforce policy • Log events • Users • Request keys • Request policy • Authenticate as needed

  7. The world according to Voltage (simplified)

  8. Downloading policy • Clients download policy from key server over HTTPS • A policy URL • Policy defines what keys a key server can create • Stored in a Base64-encoded PKCS#7 on the key server • Gives URL of where to request keys • Other administrative information • Validity period of the policy • How often clients should check for new policy • Etc. • Knowing the policy URL is all that a client needs to start encrypting

  9. Example policy – not very enlightening • -----BEGIN PKCS7----- • MIIKKgYJKoZIhvcNAQcCoIIKGzCCChcCAQExCzAJBgUrDgMCGgUAMIIGfgYJKoZI hvcNAQcBoIIGbwSCBmswggZnAgEBBEECjrk1vLeEyC1gbZBiII8GpSNU7hVZeGEA aCwkaTUA8e6G3Rtynz2GFiHrrrLTu6h9IKeaM1ZhuShK+CTMdiVrEjCCAT8CAQEw TAYHKoZIzj0BAQJBAJ8H1gR9xlCYucz2uTzLayuTJi7AILgeRz4Lp6rEpy0j9eGO wBieiN8DvimMxmoEtNs4FfZRAxbHx7VVIcwKoPMwgZEGC2CGSAGG/R4BAQEBBEAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBEECAmm7c2jAousQfwT1 myPOGhnHopYNvmRjaXs13efxL08k79KfSX/IEgcoRsnvbhRkfQDW30x85Om701UG W8vGjwIVAP/////////////v////////////MVIwUAYLYIZIAYb9HgEDAQIEQQKX 4RZI3e9oC3X/iuSx5i1NnbTW2Kq4yQ+jW9h7XtTGTfZ4rMlytgSsl1VpaWUXT7m4 Yhd7EgQtBP4SvELey3U4MB4XDTA0MDQyMjE4MDYwN1oXDTI5MDQxNjE4MDYwN1ox ggRmMBIGC2CGSAGG/R4BAwIKBAMCAQMwIAYLYIZIAYb9HgEDAgEBAf8EDhMMMDQw MjAzMjExNjE2MCAGC2CGSAGG/R4BAwIFAQH/BA4wDAYKYIZIAYb9HgIBATAsBgtg hkgBhv0eAQMCBgEB/wQaDBh2b2x0YWdlLmNvbSMwNDAyMDMyMTE2MTYwLwYLYIZI AYb9HgEDAgIBAf8EHRMbdm9sdGFnZS1wcy0wMDAwLnZvbHRhZ2UuY29tMC8GC2CG SAGG/R4BAwIHAQH/BB0MG3ZvbHRhZ2UtcHMtMDAwMC52b2x0YWdlLmNvbTBVBgtg hkgBhv0eAQMCAwEB/wRDE0FodHRwczovL3ZvbHRhZ2UtcHMtMDAwMC52b2x0YWdl LmNvbS9mb3JtcG9zdGRpci9zYWZlZm9ybXBvc3QuYXNweDBVBgtghkgBhv0eAQMC CAEB/wRDDEFodHRwczovL3ZvbHRhZ2UtcHMtMDAwMC52b2x0YWdlLmNvbS9mb3Jt cG9zdGRpci9zYWZlZm9ybXBvc3QuYXNweDCCAswGC2CGSAGG/R4BAwIEAQH/BIIC uDCCArQwggKwMIICcKADAgECAgEBMAkGByqGSM44BAMwFjEUMBIGA1UEAxMLdm9s dGFnZS5jb20wHhcNMDQwNDIyMTgwNjA1WhcNMjkwNDE2MTgwNjA1WjAlMSMwIQYD VQQDFBp2b2x0YWdlLmNvbSMwNDAyMDMyMTE2MTY6UzCCAbYwggErBgcqhkjOOAQB MIIBHgKBgQD2N0O2t9OUCRm+APvgYO1tEAPD1+heyLVFp5TgVABryChuhhtWdqXv cUCT6uA7+8pth2KWB6zvMR1FsBHHFb0Du2S3HvgaBqqhNRr+t1GvvP1/hfXyqhdL sAXKJNRntnbA4Srkkl4TfiGMWEidE+67k2aFLeTggTDn90hEqHHitQIVAO6MTSFm MJ777vg9hR76QUuHPqcjAoGAf+DTTEL/iLZwPHg2dAW7NQmHoEuaJZgVCtXVzrI6 C8axkSSEjgfxI0QPhnjgfAiPgnsWmJooxHvB62/kARCX6zFt5jjcr2gM7EnlYcwA Bw+PH8dWrQuGMQohwvUML2k/hEzhU+78p6J9h1hdWsoIR7yewuxiBWD+NpPn9UU2 3dQDgYQAAoGAG8tLodfqJNcquJfjpvXu7X/3hf7cnz+xNHEdEqMqTJOO5PVk9Ere nu0Aj50l84z+rJiGQvoXXtdeRVTxgqAgzlGXs/7FluF8cK2lpwBj5m1vQ3cAHzDA 8B1Rjr3qYGDdd8PkkOpxrJsNwArlKQidZZ2pRs+54ySwXRF9oVzKNUejQjBAMA8G A1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRDGs9zRYnj 2a4128+czLGaCsi3aDAJBgcqhkjOOAQDAy8AMCwCFDJB6Vsqx1HxT6CzXWxCPMJA SEfhAhQ3BIm2DH2m8MrGiNl4JMlB66hwNKCCArYwggKyMIICcaADAgECAgEBMAkG ByqGSM44BAMwFjEUMBIGA1UEAxMLdm9sdGFnZS5jb20wHhcNMDQwNDIyMTgwNjA3 WhcNMjkwNDE2MTgwNjA3WjAlMSMwIQYDVQQDFBp2b2x0YWdlLmNvbSMwNDAyMDMy MTE2MTY6UDCCAbcwggEsBgcqhkjOOAQBMIIBHwKBgQCcmUTb9u179pw8RQn27eEi 4Mc1RY2JWl/wRwYE+F3ruAmBmo4m6gMmI5pvj4MtGfU+3ipPbugOAOB3DLu5w9R5 ejY+xpys0RK4iFfJ7NLZz7eAMQwbkidzBGBibWNQsxdmsvvSJLc+26g54pa8Crj8 gNO6H4LkgtHE4rpUO63Z5wIVAITwIvRyibeCMuBHjdsL6C7g9Jy/AoGBAJnU/8K+ NipTQ0TX+1Dx9+mWdHhjMLfTessLdC47kFmwYepxBz/ZKu4ZG9+wtpqu5Rod0340 Q3Jd4YcmtTKtMTiLp/Pm6QQn6bKchxJqjS27wVe7Ig4G3Z4zXc0Yie18vTPDpD1l oNy1KML+n8kTAJp1elpT/0CySeph7KVjgutHA4GEAAKBgBvVSd19wQhGwXGr7zvb jLi8wKRFvveo8PPlfSfHJgzNZrMvBK4HlcK/KsTx/6BxSlLf8E2Uaax8JGArhPuW K+RoTFURqe82/1bfE1tnNnVE1jUEcFJodEpN1zQRQ6i1TOMV+0nVpJlb9ylOp9E1 3kVY5+huCZM4MqbQQvDd/ExIo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB /wQEAwIBBjAdBgNVHQ4EFgQU160Me2kzzl3w1cvJhf81RERMGVgwCQYHKoZIzjgE AwMwADAtAhUAgfWYot9R24alb8wuPD/2oWpA6ogCFEv9xddpdK78OLyOjHdMtFBl 8ipxMYHIMIHFAgEBMBswFjEUMBIGA1UEAxMLdm9sdGFnZS5jb20CAQEwCQYFKw4D AhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MTIwODAyMTYzM1owIwYJKoZIhvcNAQkEMRYEFBtovu1emwW496eAicS53o+Z dFXbMAkGByqGSM44BAEELjAsAhQoLURHiNst/mwFz7Fm+q31GDopDgIUXOGILtqM • YG2ajZgKJ/AGFeYkG7s= • -----END PKCS7-----

  10. Getting keys • Clients request keys from key server and use to encrypt/decrypt data • Key identifier can be stored as an Attribute in a PKCS#7 encrypted-data content type • As defined in RFC 3852/CMS • Identifier includes information about key • OID of algorithm • Key length • URL of policy • Application (can’t enforce, but useful for licensing) • Recipient identifier (device, user, etc.) • Identifier is a Base64-encoded DER-encoded block that can be used for multiple purposes

  11. Authentication • Authentication data can be passed with a key request • Optional • If a valid auth token is not present in a key request, the key server performs whatever auth is required by the security policy • May query user • May also query other data sources • Returns auth token to user upon success • User then requests the key using the valid auth token

  12. Key request <vs:request xmlns:vs="http://www.voltage.com/xmlns/vspv1"> <vs:header> <vs:client version="TKCOM/2.3.0.0"/> <vs:authToken value="dGhpcyBpcyBzb21lIHJhbmR8gY3JlYXRlIGFuIGF1dGggdG9rZW4="/> </vs:header> <vs:body> <vs:symKeyRequest> <vs:id> MHIwDAYKYIZIAYb9HgIBAQwgZGV2ZWxvcGVyLnZvbHRhZ2UuY29 tIzEwODjQwQDAaS6XQmLnZvbHRhZ2UuY29tNC26BBEAhzRCZWZv cmUEDL5lquI0eALv8A1JsnC4BOpwDAlub3RCZWZvcmUEDTA1MDg wODAwMDAwMFowIgwCaWQEHHNlbmRlckBkZjb20= </vs:id> </vs:symKeyRequest> </vs:body> </vs:request>

  13. Server response • Response from server includes the key plus an identifier for the key • Identifier includes information about key • OID of algorithm • Key length • URL of policy • Application (can’t enforce, but useful for licensing) • Recipient identifier (device, user, etc.)

  14. Key server response <vs:response xmlns:vs="http://www.voltage.com/xmlns/vspv1" code="100" message="Symmetric Key Follows"> <vs:header></vs:header> <vs:body> <vs:symKey> kMDkxODM0OWNudmtpdzR1MDkxdTJwdTE5OC0xOC0xMjc4MGhkeX b3VpeXNoMW5scmgxbmw0cnUxZm40ZjFucmo0bjRpdTs1aXUxNGk S1vNHU5MzQ4c3UxMDNqNC5kMWo0LmozNGtqMTNsazRqMWwzNGpo NHAxdTRwMWk0cGQxaXUzNHAxaXUzNHAxaXUzcDQxaXVwNG91MXA Gl1MXAzNHUxcDM0dXAxb3U0cDFpdTM0cDF1MzQxdTNwNDF1cDR1 A0dTFwMzR1MXAzNGl1cDEzaTR1cDF1NHAxdTM0cG8xdXA0dXA4d waWMxLmpsajE0cmxsY2kxdW5wMWNyaTFqcmkxamMuag== </vs:symKey> </vs:body> </vs:response>

  15. User authentication • User identifier and key identifier are in the key request • Key server requires authentication per its security policy before granting keys • Configurable per user/device or group of users/devices • Shared secret • Active Directory • E-mail answerback • Q&A • X.509 client certificates • SecureID • Others

  16. Summary • The key management capabilities of the Voltage Data Protection Server includes features that make it useful in a wide range of applications • Encryption and decryption may be automated but it is also easy for a human user to perform the same operations • Users/devices may even be in a different security domain • Wide range of authentication options • Same framework applies to asymmetric key management

More Related