NeoScale proposes storage encryption interoperability network

NeoScale Systems Tuesday announced it will use a standards-based security API for key management interoperability and outlined a plan for managing data encryption of customers with multi-vendor enterprise storage resources.

The company, which makes the CryptoStor KeyVault appliance, is adopting the use of the RSA PKCS#11 API. The API specifies how devices hold cryptographic information and perform cryptographic functions. NeoScales is also proposing that storage security vendors such as itself, Decru, Vormetric and CipherMax form a global key management services network that will allow the interoperability of their key management systems via standard protocols.

The key management service network will connect multiple key managers and encryption endpoints such as tape, disk devices and backup applications to protect the data on these diverse devices. Key managers and encryption endpoints would communicate using standard protocols to deliver unified multi-vendor key management services.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

NeoScale Systems Tuesday announced it will use a standards-based security API for key management interoperability and outlined a plan for managing data encryption of customers with multi-vendor enterprise storage resources.

The company, which makes the CryptoStor KeyVault appliance, is adopting the use of the RSA PKCS#11 API. The API specifies how devices hold cryptographic information and perform cryptographic functions. NeoScales is also proposing that storage security vendors such as itself, Decru, Vormetric and CipherMax form a global key management services network that will allow the interoperability of their key management systems via standard protocols.

The key management service network will connect multiple key managers and encryption endpoints such as tape, disk devices and backup applications to protect the data on these diverse devices. Key managers and encryption endpoints would communicate using standard protocols to deliver unified multi-vendor key management services.

Analysts are supportive of the plan.

“Making heterogeneous global key management a service makes sense in the same way that common domain name services or RADIUS authentication services make sense,” says Greg Schulz, senior analyst for StorageIO. “Over time, for storage security to really flourish and become part of a much larger eco-system, security services including key management needs to be readily accessible.”

Other efforts to provide interoperability between key encryption systems exist. Sun, for example, proposed to the IETF the use of its SunScreen Simple Key Management for Internet Protocol (SKIP) technology. The National Institute of Standards and Technology (NIST) also was responsible for FIPS 140-2, which defines key management and transport.

Getting other industry players such as Decru, Vormetric and Ciphermax to cooperate over which standard protocols are sufficient to protect all storage data, may be a large task.

While NeoScale, Decru and Ciphermax are working closely with industry-standards organizations such as the Storage Networking Industry Association’s (SNIA's) Storage Security Industry Forum and the IEEE P1619.3 committee to drive standards for key management interoperability, there is no agreement on standard protocols to use for key management interoperability.

NeoScale’s CryptoStor KeyVault, for instance, uses the RSA PKCS#11 Cryptographic Token Interface Standard. The PKCS#11 API integrates with CryptoStor KeyVault’s key lifecycle management and key sharing, archiving, audit and administration and allows access to key management services across a network.

“CipherMax is an advocate of tiered key management systems that cooperatively work together over one or more networks to provide key management services for storage encryption,” says Mike Witkowski, CTO of Ciphermax. The company says it proposed just this idea at the SNIA Security Summit in January of this year and to the IEEE P1619.3 Key Management Workgroup in February.

The company however is not interested in a services network that uses proprietary technology or ‘generic’ APIs such as PKCS#11.