An Introduction to PKCS#11

The PKCS#11 Cryptographic Token Interface Standard, also known as Cryptoki, is one of the Public Key Cryptography Standards developed by RSA Security. PKCS#11 defines the interface between an application and a cryptographic device. This chapter gives a general outline of PKCS#11 and some of its basic concepts. If unfamiliar with PKCS#11, the reader is strongly advised to refer to PKCS #11: Cryptographic Token Interface Standard.

PKCS#11 is used as a low-level interface to perform cryptographic operations without the need for the application to directly interface a device through its driver. PKCS#11 represents cryptographic devices using a common model referred to simply as a token. An application can therefore perform cryptographic operations on any device or token, using the same independent command set.

ProtectToolkit-C is a cryptographic service provider using the PKCS #11 application programming interface (API) standard, as specified by RSA Labs. It includes a lightweight, proprietary Java API to access these PKCS #11 functions from Java.

The PKCS #11 API, also known as Cryptoki, includes a suite of cryptographic services for encryption, decryption, signature generation, signature verification, and permanent key storage. The software found on the installation DVD is compliant with PKCS #11 v. 2.20. The latest versions of the client software and HSM firmware can be found on the Thales Technical Support Customer Portal. See Support Contacts for more information.

To provide the highest level of security, ProtectToolkit-C interfaces with SafeNet access provider software and the SafeNet range of hardware security modules (HSMs):

>ProtectServer Network HSM

>ProtectServer PCIe HSM

HSMs include high-speed DES and RSA hardware acceleration, as well as generic security processing. Secure, persistent, tamper-resistant CMOS key storage is included. Multiple adapters may be used in a single host computer to improve throughput or to provide redundancy. HSMs may be installed locally, on the same host system as ProtectToolkit-C or they may be located remotely across a network.

ProtectToolkit-C can be used in one of three operating modes. These are:

>PCI mode in conjunction with a locally-installed ProtectServer PCIe 2.

>Network mode over a TCP/IP network, in conjunction with a compatible product such as the ProtectServer External 2.

A machine with a ProtectServer PCIe 2 installed may also be used as a server in network mode.

>Software-only mode on a local machine without access to a hardware security module.

Within the client/server runtime environment, the server performs cryptographic processing at the request of the client. The server itself will only operate in one of the hardware runtime modes.

The software-only version is available for a variety of platforms, including Windows NT and Solaris, and is typically used as a development and testing environment for applications that will eventually use the hardware variant of ProtectToolkit-C.

Runtime Licensing

All of the runtime software, including all applications and the software-only ProtectToolkit-C runtime supplied with this SDK, are licensed for development and testing purposes only. NO RUNTIME LICENSES ARE INCLUDED. Therefore this software, or any component of it, must not be used for production systems. Separate runtime licenses must be purchased for production systems deployed using any ProtectToolkit-C support.

Please refer to the readme.txt file found in the install directory of the ProtectToolkit-C SDK for licensing requirement details.

The PKCS#11 Model

The model for PKCS#11 can be seen illustrated below, demonstrating how an application communicates its requests to a token via the PKCS#11 interface. The term slot represents a physical device interface. For example, a smart card reader would represent a slot and the smart card would represent the token. It is also possible that multiple slots may share the same token.

Figure 1: General PKCS#11 Model

Within PKCS#11, a token is viewed as a device that stores objects and can perform cryptographic functions. Objects are generally defined in one of four classes:

>Data objects, which are defined by an application

>Certificate objects, which are digital certificates such as X.509

>Key objects, which can be public, private or secret cryptographic keys

>Vendor-defined objects

Objects within PKCS#11 are further defined as either a token object or a session object. Token objects are visible by any application which has sufficient access permission and is connected to that token. An important attribute of a token object is that it remains on the token until a specific action is performed to remove it.

A connection between a token and an application is referred to as a session. Session objects are temporary and only remain in existence while the session is open. Session objects are only ever visible to the application that created them.

Access to objects within PKCS#11 is defined by the object type. Public objects are visible to any user or application, whereas private objects require that the user must be logged into that token in order to view them. PKCS#11 recognizes two types of users, namely a security officer (SO) or normal user. The security officer’s only role is to initialize a token and set the normal user's access PIN.

NOTE   The normal user, which manipulates objects and performs most operations, cannot log in until the security officer has set that user’s PIN.