Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analysis: Enterprise Key Management: Page 9 of 16

» KEY ESCROW, where the system stores keys on behalf of a third party--for example, so that an employee who abruptly quits or is terminated can't leave the employer high and dry; and

» SPLIT KEYS, often used to divvy up a master recovery key among executives of an organization, such that a certain majority of individuals must be present to recover the master key. Decru's Lifetime Key Management product uses split keys for emergency key access, though the product was developed for key management with the company's own DataFort systems.

And those are the easy problems. Once they're solved, there are still tough issues to address, like how to turn human-language data-security standards into technical policies for each encryption mechanism. A product must be aware of not just where each device is and how to manage its keys, but how to configure a device with an appropriate policy for the data it will handle.

One big impediment to this ideal EKM reality is a lack of interface standards. Sure, there are many standards for proper implementation of encryption, for example, FIPS 140-2, and even for how keys can be encapsulated for transmission, like RFC3852. But there are no standards for how such a proposed EKM device could speak to multiple encryption products without learning APIs for each vendor's platform.

Public-Key Cryptography Standards 11 (PKCS#11) seems like a near-solution; it specifies an API called "Cryptoki," pronounced "Crypto-key" and meant for doing key management on devices that hold keys or perform cryptographic operations. PKCS#11 was built specifically to allow for enterprise management of cryptographic tokens, but it doesn't solve the whole problem. First, it's not a network API, and it requires higher-level wrappers to be made available over the network. Yes, there are ways of doing that, but none is based on a standard that ensures interoperability among different implementations.