[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:
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:
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]