External Key Storage Model

External Key Storage shows how secure external key storage is achieved on the host system and HSM.

Figure 1: External Key Storage

PKCS#11 applications interface with the ExtToken library via standard PKCS#11 function calls. The ExtToken library uses the Cryptoki library to enforce security policies and to store all data unrelated to external token objects. All cryptographic processing is performed on the standard Cryptoki library. The Cryptoki Library uses the PCI driver to interface with local HSMs, and the Netserver Driver for remote HSMs.

ExtToken achieves secure external storage by using two master DES2 keys to transparently wrap and unwrap the external objects. One key is for protecting public objects, and the other for private objects. These master keys are stored in slot 0. The token in slot 0 is automatically treated as an external token. If the relevant objects (the external token data object and the two master keys) are missing, they are automatically generated.

Token objects created by the ExtToken library are stored in the External, Secure Object Store residing on the host system. The External Secure Object Store is divided so that objects wrapped by public keys are stored separately from objects wrapped by private keys. When these external objects are referenced by an application, the ExtToken library automatically loads them into the standard Cryptoki library. Any operations on a non-external token are passed on to the standard Cryptoki library for processing. All externally stored objects reside in the token in slot 0. The externally stored objects share the same logical slot (slot 0) as the master keys, although they are physically stored in separate locations.

The HSM utilizes internal cache memory to store the most often-used token objects. The number of token objects stored in cache is configurable by the user. During operation, the token objects are loaded into cache one at a time. If the user-configured limit is reached, the least-used object is unloaded from cache.

Key backup is accomplished by storing the master keys on a smart card and compressing the files used by the Secure Object Store.

Performance

When storing objects externally, the need to unwrap objects introduces processing overhead. SafeNet ProtectToolkit-C's CTPERF utility can be used to gauge performance on individual systems (see CTPERF). For example: 109 keys per second can be unwrapped using a DES3 key. As mentioned above, the HSM stores the most recently-used token objects in cache memory to reduce overhead. The user can choose the maximum number of token objects stored in cache by configuring the environment variable ET_PTKC_EXTTOKEN_MAXLOADED. Managing the keys stored in cache, however, also creates processing overhead that increases linearly as the number of items stored in cache increases. Systems must be individually tuned for maximum performance depending on patterns of key usage by the host application. The processing overhead tradeoff between unwrapping keys and managing the cache must be taken into consideration.

Mechanisms Underlying ExtToken

ExtToken library treats an underlying token as an external token if it contains a data object with the label "ExtToken". To be functional, the underlying token must also contain two DES2 keys (one public and one private) with the label "ExtToken". Both will have the CKA_WRAP and CKA_UNWRAP attribute set to TRUE. For security reasons, CKA_ENCRYPT and CKA_DECRYPT are set to FALSE.

The CKA_VALUE attribute of the ExtToken data object is of the form "file:<file_name>", where <file_name> is the base name of the files that manage the token objects of the external token.

Two files exist for each external token:

>The Object Data Store (ODS) contains the token objects of the external token, wrapped under its corresponding master key (public objects using the public master key; private objects with the private master key) using the SafeNet vendor-defined mechanism CKM_WRAPKEY_DES3_CBC. This mechanism wraps both the object value and attributes in the created cryptogram.

>The Object Reference Table (ORT) contains an index of the token objects stored in the ODS and the KVCs of the master keys of the external token.

PKCS#11 requires that the CKA_EXTRACTABLE attribute be set to TRUE for any object to be wrapped using a key which has CKA_WRAP set to TRUE. As a result, the ExtToken library transparently sets the CKA_EXTRACTABLE attribute to TRUE for all token objects on an external token.

When an application acquires an object handle to a token object on an external token, the related cryptogram is read from the ODS file, and unwrapped into the underlying token as a session object.

If allowed, the token in slot ID 0 is automatically treated as an external token. The relevant objects (the external token data object and the two master keys) are automatically generated, if they are missing.

Known Limitations

The ExtToken library does not protect against multiple processes updating the external token files concurrently. When an application starts, the ORT is cached. If a second application modifies the ORT by manipulating token objects on the external token, the cache of the first application will be inconsistent. The results are undefined.

For performance reasons, the attributes in the template passed to C_FindObjectsInit() function should be limited to:

>CKA_TOKEN (If present, must be TRUE. If missing, assumed to be TRUE - can only find token objects).

>CKA_LABEL

>CKA_CLASS

>CKA_KEY_TYPE

>CKA_PRIVATE

Session objects can be used in an external token, so long as they are generated or created. Other attributes in the template are supported, but they may have a negative effect on application performance. This negative effect can be mitigated by using as many attributes as possible from the list above, and limiting such operations to application initialization.

Only objects with the CKA_EXTRACTABLE attribute set to TRUE can be imported to an external token.

It is not possible to set the SafeNet vendor-defined CKA_EXPORT attribute to TRUE on an external token object.

It is not possible to set the CKA_TRUSTED attribute to TRUE on an external token object.

The ORT and ODS files are susceptible to growth. The space associated with the cryptogram of deleted objects in the ODS is not reused. One way to reclaim this space is to use the CTKMU utility to backup all the objects to a file, rename/delete the existing ORT and ODS files, then restore from the backup.

If an application uses one session to access all objects on an external token, the HSM may run out of resources. As this is related to the size and number of objects, it is not possible to state exactly the upper limit supported by SafeNet HSMs. One example of such an application is ctkmu. If there are too many objects on an external token to back them up, adjust the value of ET_PTKC_EXTTOKEN_MAXLOADED to a value that better suits your application/environment.

The SafeNet implementation of JCA/JCE (SafeNet ProtectToolkit-J) uses one session per KeyStore. An application using the same KeyStore to access a large number of keys runs the risk of consuming all HSM resources. To work around this risk, use a new KeyStore object when locating keys to avoid introducing a significant performance overhead.

Smart cards and the Admin Token cannot be used as external tokens.

External Key Storage cannot be used in conjunction with WLD.