Capacity

Tokens have two kinds of memory: persistent (token) memory and session memory. Keys and other objects may be created and managed in either, and each has its own advantages and capacities.

ProtectToolkit-C does not impose a fixed limit on the number of Tokens or the number of objects in one token. Tokens and objects may be created until the persistent memory is full. However HSM performance will decrease as the number of slots and objects increases. For all practical purposes, the performance will be unacceptably degraded before the memory is full.

As a guideline, the developer should not design a system that requires more than 50 Tokens or more than 100 objects in any one token.

ProtectToolkit-C Capacity Improvement

>Externally-stored keys should be encrypted with a key-encrypting key. This way, only the master KEK needs to be stored on the device. All working keys are unwrapped (C_UnwrapKey) prior to use and destroyed afterwards.

NOTE   They can usually be unwrapped as session keys. This technique is common for managing a large set of terminals (EFTPOS or other) that have randomly-generated terminal master keys.

>Use derived keys from a master key stored on the security module. The working key is derived by encrypting some application-supplied data with the master key and using the cipher text data to create a key value. This technique is common for managing a large set of terminals (EFTPOS or other) that have terminal master keys derived from their terminal identifiers. The terminal identifier is usually used as the application-supplied data.

>Back up and restore keys rather than leaving old key sets online. After a key rollover, old key sets should not remain online any longer than necessary.

>Keys may be spread across the storage capacity of multiple HSMs. Cryptographic requests will have to be directed to the HSM containing the necessary specific key.

ProtectToolkit-C Capacity Caveats

>Keys and other objects take up memory according to the number and individual sizes of the attributes that make them up. The number of attributes may also change for different versions of PKCS#11.

>Memory leaks may happen in both token (persistent) memory and session memory. Detecting and plugging the leaks can be quite difficult. Some development tools (ctconf) take memory usage snapshots that can help track them down.

>Low memory conditions may make the device fail in unexpected ways.