Hardware Key Generation

Integrated 13-May-2007 by mcpowers

Overview

Today, userland key generation nearly away done by hardware.  Only hardware cards like the SCA6000 or SCA4000 could provide key generation because they had object management ability.  Hardware like Niagara 1's ncp does not provide hardware acceleration in userland, despite it's nice and fast RSA and DH mechanisms.

When this project is integrated it will provide userland with RSA and DH accelerated key generation from ncp.  Speeds about 10x faster for RSA and over 200X faster on DH.  With the new SPI version, non-keystore accelerators can pass down key material to userland.  Hardware providers with a keystore that choose to use the new SPI will see less overhead as well.

We hope to have this integrated by the beginning of May.

Below is design information of how hardware key generation project changed code in the Crypto Framework.

*

CR 6339802 is for driver changes, kernel changes, and changes to
pkcs11_kernel.so ONLY. Changes to softtoken and metaslot are
covered by 6462782 and 6462780. The PSARC case for
all of these changes is PSARC/2007/092.

The gist of the changes for 6339802 are:

• New SPI crypto ops for key generation and derivation. These are for providers without keystores. Instead of returning an object handle, an array of attributes containing the generated or derived values is returned.

• Three new mechanisms have been added to the ncp driver: CKM_RSA_PKCS_KEY_PAIR_GEN, CKM_DH_PKCS_KEY_PAIR_GEN, and CKM_DH_PKCS_DERIVE. These use the new SPI crypto_nostore_key_ops mentioned above.

• Three new ioctls have been added to /dev/crypto. There is a one-to-one mapping between the SPI changes and the new ioctls.

• pkcs11_kernel.so has been modified to pass additional attributes to hold the generated values. The particular attributes depend upon the mechanism. For example, for CKM_DH_PKCS_KEY_PAIR_GEN, two new templates, each containing a single CKA_VALUE attribute, will be added to hold the generated values.

*

CR 6462782 is for changes to metaslot to generate token objects from
session object.

Problem:
When generating keys for userland applications, hardware accelerators like ncp
can not be used because they have no keystore or object management abilities
for userland to use the key.  If the user requested a token key, ncp would
not be able to generate it because it was a token key

Objective:

To use hardware crypto accelerators, like ncp, for key generation of session
and token key objects for userland use.

Design:

When looking at metaslot, one must see it as a single provider orchestrating
jobs to sub-providers.  We treat the sharing of information inside of the
slot as part of a single provider's job.

Metaslot already provides something called object cloning.  Object cloning is
a copy, not done in the C_CopyObject sense, of an object on multiple providers.
If one were to generate a key on one provider, the object cloning would load
all the attributes of the object into its master templates and then create a
new object on a second provider to use the key in an operation.  All these
objects and their clones are maintained by metaslot.   One of the requirements
of this object cloning was they needed to have many of the same values set on
the attributes for each clone.

What the hardware keygen work has done is take this object cloning a few steps
further.  Because of the limitation of clones having the same attribute values,
this presents a problem for ncp and token object.  Since ncp will never be
able to generate a token object because it lacks a keystore and object
management, it could only generate session keys.  In the new software,
metaslot takes this limitation out.  On certain pre-defined algorithms
(CKK_RSA, CKK_DH, and CKK_ECC) metaslot will keep the token state in the
metaslot object structure (FreeToken) so that the clones of the object can be
session or token object.  This allows ncp to be used for token object
generation by letting ncp generate a session object and metaslot loading that
data into the master template and creating a token object on the keystore.

A similar method is used for sensitive and private (CKA_PRIVATE) objects.  In
this case metaslot keeps the state of object (FreeObject).  When a private key
is generated, metaslot changes it into a non-private key.  After the key
values are returned, metaslot tries to copy or recreate the key as a private
key and deleting the non-private key before the object is activated in the
metaslot object list.  For private keys login permission is granted by the
keystore provider and if login fails, ncp will not be allowed to create a
private key.  ncp has no concept of logging. In cases where a hardware
provider, like Venus or Mars, where they will only create a private key, the
operation will fail and will try the next provider.  We cannot overcome these
hardware limitations or restrictions.

For sensitive templates the attribute CKA_SENSITIVE is set false for key
generation and then after the values are extracted from the key, the sensitive
attribute is set to true.

This change does not leak private or sensitive information outside the provider
of metaslot because any session object only exist in metaslot and any token
object is saved to keystore in its fail state.

When loading token objects from keystore, similar procedures are followed to
create session objects onto providers that can't handle token objects.
Sensitive objects are wrapped off the provider into metaslot's master template
for creation onto other providers.

*

CR 6462780 is for handling ECC objects in softoken.  This was a very straight
forward change.  It only allows softtoken to accept ECC attributes.  It does
not do any operations on the object.

Performance

In our development testing, we've seen that RSA  and DH key operations much faster in userland.  

Time is defined by 100 key gen operations for RSA, and 1000 key gen operations for DH.