Application Security

ProtectToolkit-C applications must provide access control and confidentiality of any keys used by the application.

NOTE   In PKCS#11 there are three classes of users: the public, the token user, and the token security officer (SO). Please refer to the PKCS#11 documentation and see About the ProtectToolkit-C Administration Guide for more about these user classes and their roles and responsibilities.

ProtectToolkit-C Security

The following rules should generally be applied:

>Use one token per application. The tokens are access-controlled separately, collect all keys related to the application, and will normally be used simultaneously within that application. The application should log in to the token with the appropriate PIN, use the keys, then log out before terminating. This approach provides a completely separate logical security boundary for each application, ensuring that no cross-application leakage can occur.

>Each key in a system should have a clearly defined purpose and be used for only that purpose. This limits the potential damage done by any key's exposure,and lessens the likelihood of misuse.

>Secret values entered on a keyboard, such as PINs and clear keys, should always be masked. The ProtectToolkit-C KMU masks all PIN and key component entry.

>Set appropriate access control for keys. Even if the key value is safe from exposure, a key could still be used by unauthorized personnel. For example, a signature generation key (CKA_SIGN = TRUE) should not be usable for encryption (CKA_ENCRYPT = TRUE).  Most keys should be “user” keys (CKA_PRIVATE = TRUE), meaning they are accessible only after a C_Login has been performed.

Keys can be randomly generated, with their attributes set so they can never be known or extracted outside the token. More often, however, keys are backed up shortly after they are generated, then locked into the token with attributes preventing extraction. This is often done with clearly specified procedures, the application should assist where possible in enforcing these.

>Use the Key Management Utility (KMU) for key backup and restore purposes.

>Use the FIPS-compliant mode of the device.

ProtectToolkit-C Security Caveats

>CKA_SENSITIVE = FALSE. This attribute setting allows key values to be extracted from the security module using C_GetAttributeValue. Set to TRUE to prevent this form of key value extraction. 

>CKA_EXTRACTABLE = TRUE. This attribute setting allows keys to be wrapped (encrypted) by another key. If the wrapper key is known externally, it can be used to obtain the original key value. A wrapping key (CKA_WRAP=TRUE) may be created at any time to wrap extractable keys. To prevent this, use CKA_EXPORTABLE = TRUE; keys with CKA_EXPORT can be created only by the security officer (SO).

>Short PINs can be determined by brute force. Use PINs with more than just numeric characters, longer than 6 characters.

>Any key that has the attribute CKA_MODIFIABLE = TRUE can have most other attributes, including key usage attributes, changed. It is best to have persistent keys with this attribute set to FALSE wherever possible. 

>Once a session is logged on, all sessions of the same application are also logged on and can access all user keys on the token.

>FIPS operation may be slower and have some interoperability problems for some existing PKCS#11 applications. 

>The PKCS#11 library is a dynamic library the application attaches to, DLL under Win32/64, and shared object under UNIX. The library is not separately authenticated by library signing techniques used by other architectures, e.g., JCE and CryptoAPI. Instead, the application relies on the security of the operating system to assure that substitution or tampering with the library has not occurred. It is reasonable to expect modern operating systems to be capable of protecting system files in this way.