Summary

Improve support for Hardware Security Modules (HSMs) by choosing crypto providers based upon key metadata and by supporting functions such as key-zeroing and atomic generate-and-set operations.

Goals

1. Enable the JCE framework to select a crypto provider based on the supplied key.

2. Enable lifecycle metadata to be associated with a key.

3. Enable deleted keys to be explicitly zeroed.

Motivation

The current crypto-provider ordering mechanism is too coarse grained -- it moves all crypto operations to the HSM provider. This does not work well for network HSMs because it is expensive to move all the data across the network just to do a crypto operation on it -- especially since this network channel is usually over SSL, so the data requires an additional round of encryption and decryption in software.

Description

Currently, crypto providers have no way to determine which provider generated a key. Consequently, before performing a crypto operation, the JCE framework cycles through each of the providers listed in the security policy until successful. To eliminate this inefficient behaviour we need to introduce a mechanism to associate the provider that generated a key with the key itself. That way, the framework can inspect the key to immediately determine the correct provider.

A beneficial side-effect of this enhancement is that it introduces a mechanism to override the default ordering of providers, on a per-key basis. This is useful when several providers offering similar algorithms have been configured for the platform.

Alternatives

The only alternative at the moment is to explicitly hardcode the required crypto provider in the application code. This approach is unwieldly, inflexible and does not scale well.

Testing

Access to a variety of HSMs may be required for validation and testing.

Impact

• Compatibility: Minimal
• Documentation: Minimal; need to document the new behaviour