Before I delve into key management for FDE, I want to clarify that the ideal FDE architecture has two main components. The actual encryption component is a separate layer from the key management. The encryption can be done by the OS (e.g. BitLocker for Windows or FileVault2 for Mac), by Self-Encrypting Drives (SEDs) or by ISVs such as WinMagic’s FIP140-2 validated software cryptographic engine. Pick whichever encryption engine best fits your organizations’ needs and then manage the encryption engine(s). That brings us to the actual key management.
According to Wikipedia http://en.wikipedia.org/wiki/Key_management
Key management is the management of cryptographic keys in a cryptosystem. This includes dealing with the generation, exchange, storage, use, and replacement of keys. It includes cryptographic protocol design, key servers, user procedures, and other relevant protocols.
Key management concerns keys at the user level, either between users or systems.
When it comes to key management for FDE the key management
system has two sub-components:
- Pre-Boot Authentication (PBA) where the keys or credentials required for decrypting or unlocking the drive are revealed only after authentication. The user could be authenticated locally with single or multifactor authentication.Alternatively the device could utilize pre-boot networking (PBN) to communicate with a central key manager or Active Directory to authenticate, enforce policy and possibly obtain the keys required to unlock or decrypt the local drive. “Enforce policy” could range from sending the device the credentials or keys to automatically unlock without user intervention to sending a kill pill to the device and triggering a crypto erase. More typically if the policy was set to allow the particular user access, the central key manager would send the credentials or keys required to decrypt or unlock the drive protected by the user’s password or smart card. User authentication would then occur locally.
- Central storage and distribution of keys or credentials for managing access and recovery. An OS present agent may communicate post boot with the central key manager to report status and get policy updates and keys. For example, once booted the OS present agent could receive instructions and data to add or remove PBA users. In a less typical use case, the central key manager could send a kill pill to trigger a crypto erase.
It is important to note that in the ideal solution, the key management will be consistent across managed platforms and OS’s. The end user should get the same experience when performing PBA for BitLocker as they would for a SED. This includes the ability to utilize tokens or passwords or have the same customized corporate branded PBA login screen.
On the Key Manager side, the administer should be able to set and enforce policies relatively independent of the actual encryption engine on the end point. This includes provisioning of user access or helping users recover from lost passwords. A common central console for all encrypted end points, especially if the encryptions engines vary, greatly simplifies administration and keeps the total cost of ownership (TCO) low.
