Key management focuses on protecting cryptographic keys from threats and ensuring keys are available when needed. And it’s no small task. That 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
One thought to “Key Management FAQ”