Meetings/Agenda/2009-11-17-18

OpenDNSSEC > Meetings > Agenda > 2009-11-17 - 18

Date: 17-18 November

The goal of these two days is to create a new design for SoftHSM v2. The list below is some topics that need to be discussed.

Update requirements

  • PKCS#11 v2.30 ?
  • Encrypted database
  • Make it easier to add support for new algorithms, etc.
  • Make it faster

Slot

An HSM can have different slots, e.g. a smartcard reader. The slot is represented by a number. A token can be attached to the slot, but the token may be moved into another slot or not even be present.

Current solution

SoftHSM is only virtual, so the slots are created by editing the configuration file. The configuration file is parsed when the library gets initialized. Each slot is appended to a linked list. It is also possible to select another configuration file by setting an environmental variable.

The SoftSlot object maintains the current state of the token, if a token is attached. Slot and token flags, hashed SO and user PIN.

Token

A token is a container which handles a set of objects and its attributes. This security realm has its own SO and user with corresponding PIN.

Current solution

To add a token to a slot, the user only has to give a path to a token database file together with the slot number in the configuration file. SoftHSM tries to load this database when it starts. Different flags will be set depending on the status of the database, e.g. if it is writable (thus present) or if it contains the correct tables with hashed PINs (thus initialized). The slot object will get a database connection, so the information may be read from it.

Objects

PKCS#11 handles different types of objects, CKO_DATA, CKO_CERTIFICATE, CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_SECRET_KEY, CKO_HW_FEATURE, CKO_DOMAIN_PARAMETERS, CKO_MECHANISM, and CKO_VENDOR_DEFINED. The user can get a handle to an object by searching for specific attributes. The handle number points to the same object, as long as the threads are in the same application.

Current solution

We only support private and public keys, CKO_PUBLIC_KEY and CKO_PRIVATE_KEY. The object handle is a reference to an ID in the database.

Suggested solution

Make it easy to extend the software with support of other object types.

Attributes

An object then also has attributes which describes the information about it. E.g. ID, label, key material.

Current solution

All the attributes are read directly from the database, so that we get the current information if some other application did some changes. values of some of the attributes depend on other attributes. This makes the code a little bit messy, regarding the setting of attributes.

Sessions

In PKCS#11, most actions require a session. The user gets a handle to a session, which maintains the current state. E.g. connection to slot, login state, remember information between multiple functions calls (e.g. find, digest, sign, verify), and read/write access.

Current solution

The handles given to the users are indexes to an array containing pointers to the SoftSession class. This class maintains the state of the session. The number of sessions is limited to the size of the array. The reason to use an array was to give quick access to the session state.

The sessions also maintain a key cache, for faster access to the key material. If we get a cache miss, then create the key from the information in the database. The key is then saved in the cache of this session. A single session will often use a limited number of key for e.g. signing. And when they are finished, they close down the session. Thus clearing the cache. The key cache cannot be shared between sessions, because the Botan key object is not thread safe.

Each session has its own instance of a random number generator, because the RNG object is not thread safe.

Database

All of the information must be stored somewhere.

Current solution

SoftHSM uses the SQLite database. The reason is that it is a light-weight software, BSD-license, and is just a file on disk.

There are three tables, token, object, and attribute.

  • The token table contains three rows, the token label, hashed user PIN, and hashed SO PIN. Used to authenticate the user.
  • The object table only have one column, the object ID. There is one row for each object. So we know what ID the new object should get. If a row is deleted, then the corresponding attributes are deleted.
  • The attribute table, have four rows: object ID, attribute type, attribute length, and attribute data.

What I see now is that the object table is redundant and not actually needed. But that would need some rewriting of the code.

Another problem is that some attributes are pointers to other attributes. E.g. a list of attribute templates. These are not supported because I have no good way of making them flat in database.

Algorithms

Different types of algorithms can be used for signing, verifying, hashing, encryption, decryption, look up of supported algorithms, etc.

Current solution

Only RSA and a number of hashing algorithms are supported. The code points for this are spread all over the program.

Suggested solution

Create a solution where it is easy to extend the supported algorithms.

Logging

The software should do logging of different events to syslog. Using the loglevels LOG_ERR, LOG_WARNING, LOG_INFO, and LOG_DEBUG. It should also be possible to specify the log level that should be written to syslog. E.g. only create log messages up to the info level and not debug.

Current solution

The loglevel is decided at build time. It is thus not possible to change this when the software is installed. The calls to the logging mechanism are done by using macros, to lower the number of function calls.

Suggested solution

It should be possible to change the loglevel once the software is installed. Perhaps make it possible to use some kind of format string.

Random number generator

An HSM has some kind of random number generator.

Current solution

SoftHSM uses the AutoSeeded_RNG class from Botan. It creates randomness from: 

 #if defined(BOTAN_HAS_HMAC_RNG)
    rng = new HMAC_RNG(new HMAC(new SHA_512), new HMAC(new SHA_256));
 #elif defined(BOTAN_HAS_RANDPOOL)
    rng = new Randpool(new AES_256, new HMAC(new SHA_256));
 #endif

    /* If X9.31 is available, use it to wrap the other RNG as a failsafe */
 #if defined(BOTAN_HAS_X931_RNG)
    rng = new ANSI_X931_RNG(new AES_256, rng);
 #endif

Suggest solution

Create a wrapper around the creation of the RNG object which returns a RandomNumberGenerator object. This makes it possible to change the generator as long as the same interface is used. E.g. if you want to create support for the  Araneus USB stick.

Access control

Each time a session wants to use an object, there must be an access control to authorize the read/write action. To determine this, you need to know the session state, if the object is a token object, if the object is a private object, and if it is a read or write action.

Current solution

The session state is a simple call to the session object and the action is determined by the function we are in, e.g. searching for an object is a read operation.

To know if the object is a token object and/or a private object, you must look into the objects attributes. Currently this information is in the database.

There is an attribute, CKA_ALWAYS_AUTHENTICATE, which is not supported. This would log out the user each time it uses an object with this attribute.

Coding convention

Do we want any changes to the current coding convention? So it gets more readable.

Botan crypto library

 Here are some more information about the Botan library.