1 Key Management Interoperability Protocol (KMIP)

2 Agenda n The Need for Interoperable Key Management n KMIP Overview n KMIP Specification n KMIP Use Cases n KMIP Interoperability Demonstration

3 The Need for Interoperable Key Management n Today’s enterprises operate in increasingly complex, multi- vendor environments. n Enterprises need to deploy better encryption across the enterprise. n A key hurdle in IT managers deploying encryption is their ability to recover the encrypted data. n Today, many companies deploy separate encryption systems for different business uses – laptops, storage, databases and applications – resulting in: l Cumbersome, often manual efforts to manage encryption keys l Increased costs for IT l Challenges meeting audit and compliance requirements l Lost data

4 Enterprise Cryptographic Environments Key Management System Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database ReplicaStaging Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WANLANVPN Key Management System CRM Often, Each Cryptographic Environment Has Its Own Key Management System

5 Enterprise Cryptographic Environments Key Management System Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database ReplicaStaging Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WANLANVPN Key Management System CRM Often, Each Cryptographic Environment Has Its Own Protocol Disparate, Often Proprietary Protocols

6 KMIP Overview

7 What is KMIP The Key Management Interoperability Protocol (KMIP) enables key lifecycle management. KMIP supports legacy and new encryption applications, supporting symmetric keys, asymmetric keys, digital certificates, and other "shared secrets." KMIP offers developers templates to simplify the development and use of KMIP-enabled applications. KMIP defines the protocol for encryption client and key- management server communication. Key lifecycle operations supported include generation, submission, retrieval, and deletion of cryptographic keys. Vendors will deliver KMIP-enabled encryption applications that support communication with compatible KMIP key-management servers.

8 Enterprise Cryptographic Environments Enterprise Key Management Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database Replica Staging Key Management Interoperability Protocol Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WAN LAN VPN CRM KMIP: Single Protocol Supporting Enterprise Cryptographic Environments

9 Storage Array Tape Library SAN Application Server Application KMIP: Symmetric Encryption Keys Key Management Interoperability Protocol Enterprise Key Manager

10 KMIP: Asymmetric Keys Public Key KMIP

11 KMIP to Commercial Meter Utility KMIP: Digital Certificates KMIP to low-end Residential Meter KMIP to Industrial Meter

12 Encrypting Storage Host Enterprise Key *&^%$#&%$#$%*!^ Request Header Get Unique Identifier Symmetric Key Response Header Unique Identifier Key Value KMIP Request / Response Model Unencrypted data Encrypted data Name: XYZ SSN: Acct No: 45YT-658 Status: Gold

13 Encrypting Storage Host Enterprise Key *&^%$#&%$#$%*!^ Supporting Multiple Operations per Request Unencrypted data Encrypted data Name: XYZ SSN: Acct No: 45YT-658 Status: Gold Request Header LocateNameGet ID Placeholder Symmetric Key Response Header Unique Identifier Key Value

14 … TagLenValueTagLenValue … TagLenValueTagLenValue Messages in TTLV Format Type

15 Transport-Level Encoding Key Client Key Server API Internal representation Transport Internal representation Transport KMIP Encode KMIP Decode API KMIP

16 OASIS KMIP Technical Committee n OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. n KMIP Technical Committee chartered in March 2009 l “The KMIP TC will develop specification(s) for the interoperability of Enterprise Key Management (EKM) services with EKM clients. The specifications will address anticipated customer requirements for key lifecycle management (generation, refresh, distribution, tracking of use, life-cycle policies including states, archive, and destruction), key sharing, and long-term availability of cryptographic objects of all types (public/private keys and certificates, symmetric keys, and other forms of “shared secrets”) and related areas.” KMIP TC IPR mode is Royalty Free on RAND

17 KMIP status n KMIP Technical Committee was established in OASIS in April 2009 l Submissions included at the time of TC creation included draft specification, usage guide and use cases l Initial membership included most significant vendors in cryptographic solutions and key management and has continued to grow. n KMIP V1.0 standard approved end-September 2010 l Revision of initial submissions April-October 2009 l First public review Nov/Dec 2009 l Revision of documents Jan-April 2010 l Second public review May/June l Approval of KMIP V1.0 docs as OASIS standard Sept 2010

18 KMIP V2.0 n Work currently underway for KMIP V2.0 l Committee Draft targeted for Q l Public review anticipated to start in Q l Final KMIP V1.1 standard expected early Q l Additions to protocol include additional attributes (permissions and groups) and operations (client registration) l May include enhancements related to server-to-server use cases. l Additions to profiles include asymmetric key use cases. l Additions to authentication methods under discussion, l Enhanced interoperability testing through cooperation with SNIA.

19 OASIS KMIP l Reading material: n n

20 KMIP Specification

21 Create Create Key Pair Register Re-key Derive Key Certify Re-certify Locate Check Get Get Attributes Get Attribute List Add Attribute Modify Attribute Delete Attribute Obtain Lease Get Usage Allocation Activate Revoke Destroy Archive Recover Validate Query Cancel Poll Notify Put Unique Identifier Name Object Type Cryptographic Algorithm Cryptographic Length Cryptographic Parameters Cryptographic Domain Parameters Certificate Type Certificate Identifier Certificate Issuer Certificate Subject Digest Operation Policy Name Cryptographic Usage Mask Lease Time Usage Limits State Initial Date Activation Date Process Start Date Protect Stop Date Deactivation Date Destroy Date Compromise Occurrence Date Compromise Date Revocation Reason Archive Date Object Group Link Application Specific ID Contact Information Last Change Date Custom Attribute Certificate Symmetric Key Public Key Private Key Split Key Template Policy Template Secret Data Opaque Object Managed ObjectsProtocol OperationsObject Attributes Key Block (for keys) or Value (for certificates) KMIP defines a set of Operations that apply to Managed Objects that consist of Attributes and possibly cryptographic material

22 KMIP Base Objects n Base Objects are: l Components of Managed Objects: n Attribute, identified by its Attribute Name n Key Block, containing the Key Value, either in the clear, either in raw format, or as a transparent structure or “wrapped” using Encrypt, MAC/Sign, or combinations thereof possibly together with some attribute values l Elements of protocol messages: n Credential, used in protocol messages l Parameters of operations: n Template-Attribute, containing template names and/or attribute values, used in operations

23 KMIP Managed Objects n Managed Cryptographic Objects l Certificate, with type and value l Symmetric Key, with Key Block l Public Key, with Key Block l Private Key, with Key Block l Split Key, with parts and Key Block l Secret Data, with type and Key Block n Managed Objects l Template and Policy Template: n Template has a subset of Attributes that indicate what an object created from such a template is n Policy Template has a subset of Attributes that indicate how an object created from such a template can be used n Note that (Policy) Templates have nothing except Attributes: for convenience these Attributes are included in the (Policy) Template structure too. l Opaque Object, without Key Block Certificate Symmetric Key Public Key Private Key Split Key Template Policy Template Secret Data Opaque Object Managed Objects Key Block (for keys) or value (for certificates)

24 KMIP Attributes n Attributes contain the “meta data” of a Managed Object l Its Unique Identifier, State, etc l Attributes can be searched with the Locate operation, as opposed to the content of the Managed Object n Setting/modifying/deleting Attributes l Only some of the Attributes are set with specific values at object creation, depending on the object type n For instance, the Certificate Type Attribute only exists for Certificate objects l Some Attributes are implicitly set by certain operations n Certificate Type is implicitly set by Register, Certify, and Re-certify l Client can set explicitly some of the Attributes n Certificate Type cannot be set by the client l Not all Attributes can be added, or subsequently modified or deleted once set n Certificate Type cannot added, modified or deleted l Some Attributes can have multiple values (or instances) organized with indices n For instance, a Symmetric Key object may belong to multiple groups, hence its Object Group Attribute will have multiple values

25 KMIP Attributes cont’d n 33 Attributes defined Unique Identifier Name Object Type Cryptographic Algorithm Cryptographic Length Cryptographic Parameters Cryptographic Domain Parameters Certificate Type Certificate Identifier Certificate Issuer Certificate Subject Digest Operation Policy Name Cryptographic Usage Mask Lease Time Usage Limits State Initial Date Activation Date Process Start Date Protect Stop Date Deactivation Date Destroy Date Compromise Occurrence Date Compromise Date Revocation Reason Archive Date Object Group Link Application Specific ID Contact Information Last Change Date Custom Attribute Describes what “is” the object Describes how to “use” the object Describes other features of the object

26 Key Lifecycle States and Transitions

27 Symmetric key: Activation Date Deactivation Date Protect Stop Date Process Start Date Protect Process Asymmetric key pair: Activation Date Deactivation Date Protect Stop Date = Protect Activation Date Deactivation Date Process Start Date = Process Public key for encryption Private key for digital signature Illustration of the Lifecycle Dates Private key for decryption Public key for digital signature

28 Symmetric Key 2 Symmetric Key 1 Symmetric Key 3 Secret Data Object 1Object 2 Derivation: Re-key or re-certify: Private Key Public Key Certificate 1 Certificate 3 Public/Private/Cert: Certificate 2 Object 3 Derived Key Base Object Replaced Object Replacement Object Public Key Private Key Certificate Public Key Certificate Illustrations of the Link Attribute

29 Client-to-server Operations n Operation consists of a request from client followed by server response n Multiple operations can be batched in a single request-response pair l ID Placeholder can be used to propagate the value of the object’s Unique Identifier among operations in the same batch l Can be used to implement atomicity n Requests may contain Template-Attribute structures with the desired values of certain attributes n Responses contain the attribute values that have been set differently than as requested by the client

30 Client-to-server Operations cont’d n 26 client-to-server operations defined Create Create Key Pair Register Re-key Derive Key Certify Re-certify Locate Check Get Get Attributes Get Attribute List Add Attribute Modify Attribute Delete Attribute Obtain Lease Get Usage Allocation Activate Revoke Destroy Archive Recover Validate (optional) Query Cancel (optional) Poll (optional) Notify (optional) Put (optional) Generate objects Set/get attributes Use the objects Support for asynchronous responses Support of optional operations Search and obtain objects Server-to-client operations

31 Server-to-client Operations n Unsolicited messages from the server to the client with the following operations: l Notify operation, used by server to inform client about attribute-value changes l Push operation, used by server to provide an object and attributes to client, indicating whether the new object is replacing an existing object or not l Batching can be used l Support is optional

32 Message Contents and Format n Protocol messages consist of requests and responses, each with a header and one or more batch items with operation payloads and message extensions n Header: l Protocol version l Maximum response size (optional, in request) l Time Stamp (optional in request, required in response) l Authentication (optional) l Asynchronous Indicator (optional, in request, no support for asynchronous response is default) l Asynchronous Correlation Value (optional, in response). Used later on for asynchronous polling l Result Status: Success, Pending, Undone, Failure (required, in response) l Result Reason (required in response if Failure, optional otherwise) l Result Message (optional, in response) l Batch Order Option (optional, in request, in-order processing is default). Support at server is optional l Batch Error Continuation Option: Undo, Stop, Continue. Stop (optional, in request, Stop is default). Support at server is optional l Batch Count n Batch Item: l Operation (enumeration) l Unique Message ID (required if more than one batch item in message) l Payload (the actual operation request or response) l Message Extension (optional, for vendor-specific extensions)

33 Message Encoding n Example of TTLV encoding of the Application Specific ID Attribute l Attribute identified by its name “Application Specific ID” l Shows value at index 2 TagTypeLengthValue AttributeStructure TagTypeLengthValue Attribute Name String “Application Specific ID” Attribute Index Integer42 Attribute Value Structure TagTypeLengthValue App. Name String “ssl” App. ID String “

34 Message Encoding cont’d n In a TTLV-encoded message, Attributes are identified either by tag value or by their name (see previous slide), depending on the context: l When the operation lists the attribute name among the objects part of the request/response (such as Unique Identifier), its tag is used in the encoded message l When the operation does not list the attribute name explicitly, but instead includes Template-Attribute (such as in the Create operation) or Attribute (such as in Add Attribute) objects as part of the request/response, its name is used in the encoded message tag … typelengthvalue operation A tagtypelengthvalue Unique Identifier f165d65-cbbd-4bd e0b390acf9 Get Unique identifier

35 Authentication n Authentication is external to the protocol n All servers should support at least l SSL/TLS n Authentication message field contains the Credential Base Object l Client or server certificate in the case of SSL/TLS *&^%$#&%$#$%*!^ @!$%!%!%!%^& *&^%$#&%$#$%*!^ Enterprise Key Manager Identity certificate SSL/TLS

36 KMIP Use Cases

37 KMIP Use Cases n Purpose: provide examples of message exchanges for common use cases n Categories l basic functionality (create, get, register, delete of sym. keys and templates) l life-cycle support (key states) l auditing and reporting l key exchange l asymmetric keys l key roll-over l archival l vendor-specific message extensions n Details of the message composition and TTLV encoding (encoded bytes included)

38 KMIP Use Cases: Example n Request containing a Get payload The operation (object type) and payload parameter Get (symmetric key) In: uuidKey Fields and structure of the message (length not shown) Tag: Request Message (0x ), Type: Structure (0x80), Data: Tag: Request Header (0x ), Type: Structure (0x80), Data: Tag: Protocol Version (0x ), Type: Structure (0x80), Data: Tag: Protocol Version Major (0x ), Type: Integer (0x01), Data: 0x (0) Tag: Protocol Version Minor (0x ), Type: Integer (0x01), Data: 0x (98) Tag: Batch Count (0x D), Type: Integer (0x01), Data: 0x (1) Tag: Batch Item (0x F), Type: Structure (0x80), Data: Tag: Operation (0x ), Type: Enumeration (0x04), Data: 0x A (Get) Tag: Request Payload (0x ), Type: Structure (0x80), Data: Tag: Unique Identifier (0x F), Type: Text String (0x06), Data: bf-4352-b1c4-9d48dac4b77d TTLV byte encoding of the message A D F A D F D D D D

39 KMIP Interoperability Demonstration

40 KMIP Interop Demo n Demonstrate protocol functionality using multiple independent implementations n Scenarios from the KMIP Use Cases document n Includes e.g. creating, deleting, searching and retrieving of symmetric keys

41 KMIP Interoperability Demo Servers Clients

42 Use Case (1/3) n The client asks the server to create a 128-bit symmetric key, using the AES algorithm, to be used for encryption and decryption n After the key has been created, the client asks the server to destroy the created key

43 Use Case (2/3) n Create-request, Attributes: { Algorithm=AES, Length=128, Usage Mask=encrypt&decrypt } n Create-response: Success, Unique Identifier of created key Client Server

44 Use Case (3/3) n Destroy-request, Unique Identifier of previously created key n Destroy-response: Success, Unique Identifier of destroyed key

45 Use Case (1/4) n The client registers a template with attributes n The client asks the server to create a symmetric key with the attributes specified in the previously registered template n The client retrieves some attributes of the key to verify they were set according to the template n Note: Only operations not shown until now are illustrated

46 Use Case (2/4) n Register-request, ObjectType=Template, Attributes (e.g.): { Name=Template1, ObjectGroup=Group1 } n Register-response: Success, Unique Identifier of registered template

47 Use Case (3/4) n Create-request, TemplateName=Template1 n Create-response: Success, Unique Identifier of created key

48 Use Case (4/4) n Get Attributes-request, Attribute Names: { ObjectGroup, AppSpecificInfo, ContactInfo, x-Purpose } n Get Attributes-response: Success, Attributes { ObjectGroup=Group1 etc. } ?

49 Use Case (1/3) n The client asks the server to create a key and specifies a Name attribute value n The client then performs a Locate operation, supplying the Name, to which the server responds with the Unique Identifier of the created key n The client retrieves the created key using its Unique Identifier

50 Use Case (2/3) n Locate-request, Attribute: { Name=Key1 } n Locate-response: Success, Unique Identifier of created key Previously created Key with Name attribute set

51 Use Case (3/3) n Get-request, Unique Identifier of previously created key n Get-response: Success, key material of the previously created key

52 Use Case 4.1 (1/4) n The client asks the server to create a key n The client gets the State attribute to confirm that the key is initially in the Pre- Active state n The client performs an Activate operation to change the state to Active n The client performs a Revoke operation to change the state to Compromised

53 Use Case 4.1 (2/4) n Get Attributes-request: Unique Identifier of key, Attribute Name: { State } n Get Attributes-response: Success, Unique Identifier of key, State=Pre-Active ? Previously created key in the Pre-Active state

54 Use Case 4.1 (3/4) n Activate-request: Unique Identifier of key n Activate-response: Success, Unique Identifier of activated key

55 Use Case 4.1 (4/4) n Revoke-request: Unique Identifier of key, Revocation Reason=Compromised n Revoke-response: Success, Unique Identifier of revoked key

56 Use Case 5.1 (1/4) n The client asks the server to create a key, activates it and sets a certain amount of Usage Allocation (1000 MB) n The client gets some Usage Allocation so that it can use the key e.g. for encrypting data n Once it has been used up, the client requests some more usage allocation n When the usage allocation has been used up, the key cannot be used for encryption anymore

57 Use Case 5.1 (2/4) n Get Usage Allocation-request: Unique Identifier of key, ByteCount=500 n Get Usage Allocation-response: Success, Unique Identifier of key Usage allocation

58 Use Case 5.1 (3/4) n Get Usage Allocation-request: Unique Identifier of key, ByteCount=500 n Get Usage Allocation-response: Success, Unique Identifier of key Usage allocation (usage allocation is used up)

59 Use Case 5.1 (4/4) n Get Usage Allocation-request: Unique Identifier of key, ByteCount=500 n Get Usage Allocation-response: Operation Failed, Usage Allocation requested could not be granted Usage allocation (usage allocation is used up)

60 Conclusion

61 Enterprise Cryptographic Environments Enterprise Key Management System Disk Arrays Backup Disk Backup Tape Backup System Collaboration & Content Mgmt Systems File Server Portals Production Database ReplicaStaging Key Management Interoperability Protocol Enterprise Applications eCommerce Applications Business Analytics Dev/Test Obfuscation WAN LAN VPN CRM KMIP: enabling enterprise key management through standard protocol

62 Q&A