Page History

...

The secure object store component forms the backend storage of SoftHSM v2. It stores PKCS#11 objects in a directory structure organised as follows:

• There is a top-level directory for the complete secure object store that is configurable in the SoftHSM v2 configuration file
• For each token there is a separate directory; tokens are uniquely identified using a UUID
• Inside the token directory there are separate files for each token. There is also a special file that stores token specific attributes (such as the label, the PINs, etc.)

The secure object store - as it name implies - is capable of storing sensitive attributes of an object securely using the secure data manager (see below).

...

To verify the design, we have performed a detailed analysis of two use cases and created the corresponding sequence diagrams:

• Use case: Initialising a token
• Use case: Using a key to sign data

The description of the use cases also shows some details on the expected internal implementation of some functions.

...

There should be clearly defined interfaces between some of the main components in the design specified above. These interfaces make it possible to break down the work on SoftHSM v2 into separate parts and facilitate unit testing. Below is a list of components with links to their interface specifications:

• Secure object store: Interface specification
• User manager: Interface specification
• Secure data manager: Interface specification
• Cryptographic abstraction: Interface specification

Module testing

SoftHSM v2 will incorporate module tests for each component at the interface level of the interfaces specified above; these tests will be implemented using the CPPunit test framework.