Application usability

Usability is an important consideration; if security requirements become an imposition, users are more inclined to work around them. For example, users forced to change their passwords too often tend to write them down or choose simple derivatives of the same password over and over again. Secure systems simply don’t work if they are not usable.

ProtectToolkit-C application usability

• ProtectToolkit-C allows PINs to be non-numeric and can be quite long (up to 32 characters). In fact, full 8-bit binary data can be used for PINs, but applications tend to use printable characters.

• When naming keys, use the CKA_LABEL attribute and name the key according to its usage and origin (or scope). For example, “KEK - Database” for a key-encrypting-key for use with an applications database. This makes the key's purpose clear to both trained and untrained users, who may not normally need to use it.

• Wherever possible, use the token label to find key sets belonging to a particular application, rather than slot numbers. It is advisable to use separate tokens in separate slots for separate applications.

• For server-type applications, it may not be possible to perform a login every time the system is restarted. This may force keys to be made non-private so that they are accessible without logging in, or the application will have to obtain the login password from some static location - either hard-coded or in some environment variable etc depending on the platform.

• Learn and use the ProtectToolkit-C additional libraries (CTEXTRA and CTUTIL) which have been provided to implement common PKCS#11 application features.

ProtectToolkit-C usability caveats

• The ProtectToolkit-C token browser is a developer’s tool and is therefore very low-level. It can be tricky for the user unfamiliar with it or PKCS#11.

• Watch out for embedded and trailing spaces in token and object label names. Some PKCS#11 implementations do exact matches and will not regard labels with and without the NULL termination as equal.

• Many applications only work on slot 0, making interoperability between them on the same platform impossible.

• System-level changes, such as slot creation and deletion, peripheral connection and disconnection, or enabling and disabling security flags, affect all applications that are using the HSM. You should make these changes before the HSM is brought into production or while it is not being accessed by an application.