Recent revelations in the areas of security and privacy have caught the attention of a wide audience and certainly have changed the attitude of many companies. But these revelations come with one piece of reassurance: Cryptography works. So whenever secrets are to be shared securely or privacy must be preserved, the best thing to do is encrypt all sensitive information. And as Google and others have experienced, this advice isn’t restricted to communication over the Internet; it extends to communication within intranets. Cryptography methods are highly complex. Therefore, using standard application programming interfaces (APIs), referring to well-known and trusted implementations of those methods, is a best practice to avoid security flaws when writing software that needs cryptography.
The Public Key Cryptographic Standard #11 (PKCS#11) is a popular cryptographic standard meant to support cryptographic hardware using a standard API. PKCS#11 can support so-called hardware “tokens” that may be cryptographic accelerators or hardware security modules (HSMs). The goal of accelerators is to improve the performance of cryptographic operations either by employing special-purpose circuits or by offloading cryptographic operations to an additional processor or adapter card. Accelerators don’t enhance the security of a system, as they use clear text keys (aka clear key) that can be observed by anybody who has access to the system memory. On the other hand, HSMs never reveal keys in clear text outside the tamper-proof HSM hardware. Therefore, any key that leaves an HSM must be wrapped (i.e., encrypted) and is therefore called a secure key. IBM System z provides:
Cryptographic accelerators such as the CP Assist for Cryptographic Functions (CPACF) instructions on the CPU and the CryptoExpress Adapter in accelerator mode
HSMs such as the CryptoExpress adapters in either Common Cryptographic Architecture (CCA) or Enterprise PKCS#11 coprocessor mode.
The PKCS#11 standard is largely independent of specific cryptographic hardware yet it allows programs to deal with many hardware-specific implementations. It supports the use of multiple, possibly different tokens.
Given the popularity of PKCS#11, many software products that support encryption provide plug-in mechanisms that if configured will redirect cryptographic functions to a PKCS#11 library. For example, IBM middleware such as the IBM WebSphere Application Server (WAS) and the IBM HTTP Server, including the IBM internal crypto library GSKIT, can be configured to use a PKCS#11 library. Open source software such as the mod_nss plugin for Apache can also call to a PKCS#11 library. In addition, some libraries support plug-ins for PKCS#11. Foremost, the Java Cryptographic Architecture supports PKCS#11 providers (IBMPKCS11Impl for IBM Java and SunPKCS11 for Oracle Java).
PKCS#11 isn’t used only to implement applications requiring specific cryptographic support but also to enable existing software to use cryptographic hardware.
The PKCS#11 standard was published by RSA and has been transferred to the Organization for the Advancement of Structured Information Standards (OASIS). It defines a C/C++ API that’s called cryptoki. The current version of the standard is 2.2 (which includes three amendments). While version 2.3 remains in draft status, OASIS is reviewing version 2.4, which greatly extends the set of cryptographic mechanisms that will be supported.
Here we provide an overview of the concepts of the PKCS#11 standard as well as a description of openCryptoki, an open source implementation of PKCS#11 that’s available for major Linux distributions such as Red Hat Enterprise Server Linux (RHEL) and SUSE Linux Enterprise Server (SLES). In addition, we’ll present two openCryptoki tokens that exploit System z cryptographic hardware in Linux on System z.
Since this section focuses on the PKCS#11 standard, it’s general and isn’t dependent on System z or Linux. The PKCS#11 concepts mostly come in pairs: slots and tokens, roles and sessions, functions and mechanisms, and objects and keys.
Slots and Tokens
It seems the use of smart cards has provided the model behind the hardware plug-in mechanism of PKCS#11. In the same way a smart card is inserted into a smart card reader, a PKCS#11 token is inserted into a PKCS#11 slot where a slot is identified by its ID (a small number) and a token is a piece of library code that knows how to interface with the cryptographic hardware. Clearly, there’s no requirement for the token to use any hardware, and accordingly, there are so-called soft tokens that represent a pure software library accessible via the PKCS#11 API.
The PKCS#11 API provides a set of slot and token management functions: