[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: draft of storage client profile for discussion
Storage Client Profile
This profile references the Key Management Interoperability Protocol Usage Guide Version 1.0
<include URIs>
1.0 Storage client use cases
The storage industry has been introducing a series of options for protection of data in storage. A large number of different implementations have been implemented including:
1.1 Where is the key generated
The symmetric key used for encryption can be:
1.2 How is the key identified for retrieval
The key once used for encryption needs to be available for decryption. There are a number of methods for identifying the key for retrieval:
1.3 Mechanisms for establishing trust
Trust establishment in the certificates use of mutual authentication for the TLS session between the KMIP client and server are discussed in the KMIP base specification. This is not a substitute for the device identification also discussed with respect to the credential object and the client registration proposals.
1.4 mechanisms for key protection such as key wrapping
Optionally a number of choices exist for storage client implementations to use KMIP operations to get and register keys and attributes used in conjunction with the symmetric encryption keys for protecting the encryption key(s) on the client.
Best practices would recommend that encryption keys are either put into encryption hardware for operations and not persistent in the clear, or if keys are to be maintained be in the storage client that they have protection such as encryption and potentially tamper aware hardware protection.
2.0 Encryption key generation use cases
· Device requests a new key from the key manager
· Key is returned along with label or identifier and UUID
· Device generates a key and registers the key with the key manager
· Devices can add attributes associated as meta-data with the key
· Devices use a self-generated encryption key but get an authentication key from a key manager
2.1 Device requests a new key from the key manager
Create /specify
attribute name,
attribute activation date,
attribute process start date
attribute protect stop date
attribute deactivation date
attribute link
Perform locate using attributes, UUID is returned
Get request returns:
Algorithm
Length
Key
identifier
2.2 Device generates a key and registers the key with the key manager
Device generates a key potentially using hardware seed
Create /specify
attribute name,
attribute activation date,
attribute process start date
attribute protect stop date
attribute deactivation date
attribute link
contact info
custom attributes
algorithm
crypto length
UUID returned from server
2.3 Devices can add attributes associated as meta-data with the key
Key can be identified by:
2.4 Devices use a self-generated encryption key but gets an authentication key from a key manager
One of the variations on the getting a key from the key manager with the authentication key either being used to encrypt or hash the encryption key stored on the drive.
2.5 Retrieve key for encrypted storage unit
A key identifier or other attributes are used perform a locate and retrieve the UUID
Either the UUID passed in the by the storage client or the UUID found as a result of the locate is then used in a get request to get the symmetric key from the key management server. Also returned from get request is the algorithm and length.
3.0 Delete key
There are a number of scenarios that can drive deletion of keys:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]