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:
-	encryption in the storage device,

-	encryption in the storage controller,

-	encryption in fabric switches,

-	encryption in network adapters, and 

-	encryption in host software providing storage connectivity.

Storage clients generally are interacting with KMIP implementations for managing symmetric keys, although there are also cases for managing asymmetric pairs associated with certificates.  The certificates and asymmetric key pairs used to establish the mutual authentication for TLS are outside of the scope of this profile, however KMIP can be used storing and retrieving certificates to support subsequent authentications or other operations like key wrapping used by storage use cases.

In general there are four design choices for storage clients related to the KMIP use:
1)	where is the key generated

2)	how is the key identified for retrieval

3)	what is the mechanism used to establish trust with client

4)	what mechanisms are used to protect keys such as key wrapping

1.1 Where is the key generated

The symmetric key used for encryption can be:
-	in the key management server

-	generated in the device and stored on the key management server

-	generated in the device and protected by a key generated by the key management server

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:
-	a key identifier is used that is assigned by the key management server – an example is the LTO usage where a key label or identifier is storage on the media such that when the media is mounted it can be used to retrieve the decryption key

-	a key identifier is created by the storage client and is associated with the key, an example would be a media identifier

-	client identification serves as a default identifier for keys associated with the client

-	the key is stored protected  by wrapping on the device and the key management server has enough information to can unwrap the key

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:
1)	passing in a key identifier and the client doing a locate to get UUID

2)	passing in attribute pairs and client doing a locate to get UUID

3)	passing in a UUID

perform get request

if key is found then compare attributes passed in versus attribute returned

if new or modified attributes:

attribute name, 

attribute activation date,

attribute process start date

attribute protect stop date

attribute deactivation date

attribute link

contact info

custom attributes

application specific

algorithm

crypto length

client calls server to modify or add attributes

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:
1)	a storage unit is being decommissioned, reaching the end of use, being repaired or retired where the key associated with the data should be destroyed

2)	key rotation or rollover where a new key has been used for encryption and the old key can be destroyed

3)	there are cases where there has been a loss of physical control of storage media where you would like to destroy a key so that it can not be possibly used to read the lost media

4)	there are cases where you would like to  destroy a key to support cryptographic erasure of a unit of storage

Key can be identified by:
1)	passing in a DKI and the client doing a locate to get UUID

2)	passing in attribute pairs and client doing a locate to get UUID

3)	passing in a UUID

perform delete request (deactivation, then destroy)

STSM, Technical Strategy Security and Storage Software

102 Thorncliff Circle

Cary, NC 27513

(1) 919 469 5725 - office

(1) 919 605 0331 - mobile