Kms Kmip

[Mandy Geise]

TheKey Management Interoperability Protocol (KMIP) is an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server. This facilitates data encryption by simplifying encryption key management. Keys may be created on a server and then retrieved, possibly wrapped by other keys. Both symmetric and asymmetric keys are supported, including the ability to sign certificates. KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key.

The KMIP standard was first released in 2010. Clients and servers are commercially available from multiple vendors. The KMIP standard effort is governed by the OASIS standards body. Technical details can also be found on the official KMIP page[1] and kmip wiki.[2]

A KMIP server stores and controls Managed Objects like symmetric and asymmetric keys, certificates, and user defined objects. Clients then use the protocol for accessing these objects subject to a security model that is implemented by the servers. Operations are provided to create, locate, retrieve and update managed objects.

Each managed object comprises an immutable Value like a key-block containing a cryptographic-key. These objects comprise mutable Attributes which can be used for storing metadata about their keys. Some attributes are derived directly from the Value, like the cryptographic-algorithm and key-length. Other attributes are defined in the specification for the management of objects like the Application-Specific Identifier which is usually derived from tape-identification data. Additional identifiers can be defined by the server or client per application need.

Each object is identified by a unique and immutable object-identifier generated by the server and is used for getting object-values. Managed-objects may also be given a number of mutable yet globally unique Name attribute which can be used for Locating objects.

Each key has a cryptographic state defined by the National Institute of Standards and Technology (NIST). Keys are created in an Initial state, and must be Activated before they can be used. Keys may then be Deactivated and eventually Destroyed. A key may also be marked being Compromised.

Operations are provided for manipulating Key-state in conformance with the NIST life-cycle guidelines. A Key-state may be interrogated using the State attribute or the attributes that record dates of each transformation such as Activation Date. Dates can be specified into the future thus keys automatically become unavailable for specified operations when they expire.

KMIP is a stateless protocol in which messages are sent from a client to a server and then the client normally awaits on a reply. Each request may contain many operations thus enables the protocol to efficiently handle large numbers of keys. There are also advanced features for processing requests asynchronously.

All of these protocols are expected to be transmitted using TLS protocol in order to ensure integrity and security. However, it is also possible to register and retrieve keys that are wrapped (encrypted) using another key on the server, which provides an additional level of security.

User objects can be created and authorized to perform specific operations on specific managed objects. Both Managed Objects and Users can be assigned to groups, and those groups can form a hierarchy which facilitates efficient management of complex operating environments.

Default values of attributes can be provided, so that simple clients need not specify cryptographic and other parameters. For example, an administrative user might specify that all "SecretAgent" keys should be 192 bit AES keys with CBC block chaining. A client then only needs to specify that they wish to create a "SecretAgent" key to have those defaults provided. It is also possible to enforce constraints on key parameters that implement security policy.

KMIP also defines a set of profiles, which are subsets of the KMIP specification showing common usage for a particular context. A particular KMIP implementation is said to be conformant to a profile when it fulfills all the requirements set forth in a profile specification document. OASIS has put forth various profiles describing the requirements for compliance towards storage arrays[3] and tape libraries,[4] but any organization can create a profile.

PKCS#11 is a C API used to control a hardware security module. PKCS#11 provides cryptographic operations to encrypt and decrypt, as well as operations for simple key management. There is considerable amount of overlap between the PKCS#11 API and the KMIP protocol.

The two standards were originally developed independently. PKCS#11 was created by RSA Security, but the standard is now also governed by an OASIS technical committee. It is the stated objective of both the PKCS#11 and KMIP committees to align the standards where practical. For example, the PKCS#11 Sensitive and Extractable attributes are being added to KMIP version 1.4. Many of the same people are on the technical committees of both KMIP and PKCS#11.

KMIP 2.0 provides a standardized mechanism to transport PKCS#11 messages from clients to servers. This can be used to target different PKCS#11 implementations without the need to recompile the programs that use it.

The OASIS KMIP Technical Committee maintains a list of known KMIP implementations, which can be found on the OASIS website. As of March 2017, there are 28 implementations and 61 KMIP products in this list.

The KMIP standard is defined using a formal specification document, testcases, and profiles put forth by the OASIS KMIP technical committee. These documents are publicly available on the OASIS website.

Vendors demonstrate interoperability during a process organized by the OASIS KMIP technical committee in the months before each RSA security conference. These demonstrations are informally known as interops. KMIP interops have been held every year since 2010. The following chart shows the number of individual tests performed by each client and server vendor combination since 2012.

The following shows the XML encoding of a request to Locate a key named "MyKeyName" and return its value wrapped in a different key with ID "c6d14516-4d38-0644-b810-1913b9aef4da". (TTLV is a more common wire protocol, but XML is more human readable.)

Documentation is freely available from the OASIS website.[5] This includes the formal technical specification and a usage guide to assist people that are unfamiliar with the specification. A substantial library of test cases is also provided. These are used to test the interoperability of clients and servers, but they also provide concrete examples of the usage of each standard KMIP feature.

Also @ncabatoff I had to modify pykmip to properly raise the error as it expected a string as well which was not being returned. I was wondering if vault uses a different kmip version and I could use those, I tried 1.0, 1.1, 1.2, 1.3, 1.4 and 2.0 on the client side but unfortunately no luck.

Thank you for reaching back. Yes you are right, I confused the two. However can you please confirm the response being sent back and the additional ObjectType tag added which results in pykmip not handling register response as desired and failing. I have pointed out a spec link as well which shows what the response can contain.

DataStax recommends using KMIP key server security policies to limit the number of nodes in the cluster that can remotely manage keys, due to the risks associated with expiring, revoking, and destroying keys.

DataStax Enterprise supports using encryption keys from one or more remote KMIP hosts to encrypt/decrypt table data and/or sensitive properties in the dse.yaml and cassandra.yaml configuration files.Follow these steps to add a KMIP server information to the list of available hosts.

chunk_length_kb: Configures chuck size for SSTables.The default (64) is used if the option is excluded.When these properties are set, DSE only uses a key that matches;if no matching key exists, start up fails.

'key_provider': 'KmipKeyProviderFactory' tells the encryptor to use a KMIP key server to manage its encryption keys.Include the 'key provider' entry only to specify to use a KMIP key server, otherwise omit this entry.

Security policies generally limit the amount of time an encryption key is in use;this section describes how to expire a key without re-encrypting the exiting data.After a key expires, it is no longer used to encrypt new data, but is still used to decrypt existing data.

After the key expires, the database gets a new key for encryption the next time it refreshes the key cache (key_cache_millis in dse.yaml);the default setting is five minutes.Expired keys are still available to decrypt data.

Change the encryption key that is used for both encrypting new data and decrypting the existing data.Use these steps to secure the data after an event that potentially compromised an encryption key, such as a change in security administration staff.Before destroying the old key, revoke the compromised KMIP key, wait for the database key cache refresh, and then re-encrypt existing SSTables with the new key.

The database caches the encryption keys and refreshes the cache at an interval set by the key_cache_millis in dse.yaml (default setting is 5 minutes).To get a new key, either wait for the key cache refresh interval or perform a rolling restart.

dsetool managekmip revoke: Permanently disables the key on the KMIP server.Database can no longer use the key for encryption, but continues to use the key for decryption of existing data.Re-encrypt existing data before completely removing the key from the KMIP server.

3a8082e126