Key management focuses on protecting cryptographic keys from threats and ensuring keys are available when needed. And it’s no small task. That's why the SNIA Networking Storage Forum (NSF) invited key management and encryption expert, Judy Furlong, to present a “Key Management 101” session as part our Storage Networking Security Webcast Series. If you missed the live webcast, I encourage you to watch it on-demand as it was highly-rated by attendees. Judy answered many key management questions during the live event, here are answers to those, as well as the ones we did not have time to get to.

Q. How are the keys kept safe in local cache?

A. It depends on the implementation. 
Options include:  1. Only storing
wrapped keys (each key individually encrypted with another key) in the cache. 2.
Encrypting the entire cache content with a separate encryption. In either case,
one needs to properly protect/manage the wrapping (KEK) key or Cache master key.

Q. Rotate key question – Self-encrypting Drive (SED) requires
permanent encryption key. How is rotation is done?

A. It is the Authentication Encryption Key used to access
(and protect the Data (Media) Encryption Key) that can be rotated. If you
change/rotate the DEK you destroy the data on the disk.

Q. You may want to point out that many people use
“FIPS” for FIPS 140, which isn’t strictly correct, as there are
numerous FIPS standards.

A. Yes that is true that many people refer to FIPS 140 as just FIPS which as noted is incorrect.  There are many Federal Information Process
Standards (FIPS).  That is why when I
present/write something I am careful to always add the appropriate FIPS
reference number (e.g. FIPS 140, FIPS 186, FIPS 201 etc.).

Q. So is the math for M of N
key sharing the same as used for object store?

A. Essentially yes, it’s the same mathematical concepts that
are being used.  However, the object
store approach uses a combination of data splitting and key splitting to allow
encrypted data to be stored across a set of cloud providers.

Q. According to the size of the data, this should be the
key, so for 1 TB should a 1T key be used? (Slide
12)

A. No, encrypting 1TB of data doesn’t mean that the key has to be
that long. Most data encryption (at rest and in flight) use symmetric
encryption like AES which is a block cipher. In block ciphers the data that is
being encrypted is broken up into blocks of specific size in order to be
processed by that algorithm. For a good overview of block ciphers see the Encryption 101 webcast.

Q. What is the maximum
lifetime of a certificate?

A. Maximum certificate validity (e.g. certificate lifetime)
varies based on regulations/guidance, organizational policies, application or
purpose for which certificate is used, etc. Certificates issued to humans for
authentication or digital signature or to common applications like web
browsers, web services, S/MIME email client, etc. tend to have validities of 1-2
years. CA certificates have slightly longer validities in the 3-5-year
range. 

Q. In data center applications, why not just use AEK as
DEK for SED?

A. Assuming
that AEK is Authentication Encryption Key — A defense in-depth strategy is
taken in the design of SEDs where the DEK (or MEK) is a key that is generated
on the drive and never leaves the drive. The MEK is protected by an AEK. This
AEK is externalized from the drive and needs to be provided by the
application/product that is accessing the SED in order to unlock the SED and
take advantage of its capabilities. 

Using separate keys follows the principles of only using a key for one purpose
(e.g. encryption vs. authentication).  It
also reduces the attack surface for each key. If an attacker obtains an AEK
they also need to have access to the SED it belongs to as well as the
application used to access that SED.

Q. Does NIST require
“timeframe” to rotate key?

A.NIST recommendations for the cryptoperiod of keys used for a
range of purposes may be found in section 5.3.6 of NIST SP800-57 Part 1 R5.

Q. Does D@RE use symmetric or asymmetric
encryption?

A.There are many Data at Rest (D@RE) implementations, but the
majority of the D@RE implementations within the storage industry (e.g.
controller based, Self-Encrypting Drives (SEDs)) symmetric encryption is used.
For more information about D@RE implementations, check out the Storage
Security Series: Data-at-Rest webcast.

Q. In the TLS example shown, where does the “key
management” take place?

There
are multiple places in the TLS handshake example where different key management
concepts discussed in the webinar are leveraged:

• In steps 3 and 5 the client and server exchange their public key
  certificates (example of asymmetric cryptography/certificate management)
• In steps 4 and 6 the client and server validate each other’s
  certificates (example of certificate path validation — part of key management)
• In step 5 the client creates and sends pre-master secret (example
  of key agreement)
• In step 7 the client and server use this pre-master secret and
  other information to calculate the same symmetric key that will be used to
  encrypt the communication channel (example of key derivation).

Remember
I said this was part of the Storage Networking Security Webcast Series? Check
out the other webcasts we’ve done to date as well as what’s coming up