Gordon,
Do you want to differentiate removable media (tape) from fixed media (disk) as there are different requirements for keys and handling of those keys (e.g. overwrite of tape is a good reason to allow a client to destroy earlier keys while with disk destroying keys can be a bad thing except in certain circumstances. With disk it is even different depending on whether you are looking at self encrypting drives (SED) versus array controller based encryption. The different requirements here potentially an issue because one may have the ability to re-key while the other inherently cannot without wiping the data based on current TCG specifications.
Based on the above and some additional differences, I feel we need to better define individual profiles for each type of use case. This would allow for better interoperability if the focus were on a Tape profile, a self encrypting drive profile, an encrypting controller profile without re-key, encrypting controller with re-key, network switch basic profiles with re-key, network adapter basic profile and a host storage software basic profile as a few based on the use cases below.
Also defining a format for UUID’s would be highly recommended here as some storage media that keeps the key ID’s have limited space (e.g. ACAD/UCAD for LTO tape).
I may have missed the point here but I feel that separating these use cases will bring the benefit of easing interoperability which is the primary goal of the profiles (or at least it is in my little world).
Thanks,
Bob L.
Robert A. (Bob) Lockhart
Chief Solution Architect - Key Management
THALES e-Security, Inc.
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Gordon Arnold
Sent: Thursday, August 16, 2012 11:49 AM
To: Griffin, Robert
Cc: kmip@lists.oasis-open.org
Subject: [kmip] storage client profile
The storage client profile has been posted - but i will include in this e-mail for convenience:
Storage Client Profile
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)
LTO example
Tape devices normally reside within a library. Tape devices may not have the ability to establish a TCP/IP session or a TLS session.
The tape library establishes a TLS session. The KMIP server must have configured the certificate used by the library or provide a mechanism for establishing trust in the certificate used for the TLS session.
When a cartridge is mounted in a tape drive it determines whether it is a new/scratch cartridge or a previously encrypted cartridge.
If it is a new/scratch cartridge then it requests a new key from the KMIP server. That key may be generated at the time of the request or be allocated out of a group generated asynchronously according to server and administrator policy.
The KMIP server returns the key and a label for that key. The tape device writes uses the key for the encryption and writes the label to the cartridge (in multiple places).
When a previously encrypted cartridge is inserted into a tape device it retrieves the key label and sends it to the KMIP server
The KMIP server uses the label to look up the key and returns the key to tape device. The tape device then uses the key to decrypt the tape.
Self-encrypting authentication key
Conformance clause language
STSM, Product Manager, Data Security
102 Thorncliff Circle
Cary, NC 27513
(1) 919 605 0331 - mobile