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

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

Enable lifecycle metadata to be associated with a key.

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.