Welcome Guest, you are in: Login

NCryptoki Wiki

RSS RSS

Navigation





Search the wiki
»

Cryptware
PoweredBy

Introduction to PKCS#11 specifications

RSS
Modified on 2010/10/11 18:07 by Administrator Categorized as Uncategorized
PKCS#11 (Public Key Cryptography Standards No. 11) specifications, developed by RSA Data Security labs, defines an high-level, platform-independent API to cryptographic devices (such as smart cards, USB Tokens, HSMs, etc.), that hides the low level operational logic of a cryptographic devices, presenting to the applications a unified abstraction layer for a generic cryptographic token with an higher level set of functions.

The high flexibility and the simple logic of such a model made the PKCS#11 specifications a de-facto standard widely used by applications interacting with smart cards. PKCS#11 is largely adopted to access smart cards, cryptographic tokens and HSMs. Most commercial Certification Authority software uses PKCS#11 to access the CA signing key or to enroll user certificates as well as cross-platform software that needs to use smart cards uses PKCS#11, such as Mozilla Firefox and OpenSSL (using an extension). Because the API is defined in C language, the PKCS#11 module is implemented in C as native library (a Dinamically Linked Library (.dll) in Windows OS or as Shared Object (.so) on Linux and MacOS) that exports the functions of the API. This means that if your application is in C/C++ you can easily import the API functions in your code, But what if your application is in C# or VB.NET? Or what if you application is in Visual Basic 6 or Delphi? NCryptoki addresses this stuffs and allows to call PKCS#11 API in your .NET applications.

Architecture

A typical Cryptoki-based system architecture is depicted in Figure 1.

Image

Figure 1


The cryptographic device (aka token) is connected to the system via a slot. Typically, a slot corresponds to a smart card reader or a specific card terminal. However, becaus e Cryptoki offers a purely logical view of the system it could happens that different slots point to the same physical reader device or, viceversa, a single slot could have more than one device.

The logical structure of a token

A specific Cryptoki implementation maps the token’s physical structure, typically composed by memory zones in which data, cryptographic keys and their digital certificates are stored, into a logical structure that adheres to the hierarchical model shown in Figure 2.

Image

Figure 2

The specifications define three main object classes:
  • Dataobjects host generic data which semantics is defined by the application who created them;
  • Certificateobjects store digital certificates;
  • Keyobjects contain a public, private or secret cryptographic key.

Cryptoki’s objects are classified depending on their visibility in public objects (i.e. accessible by all applications), and private objects (visible only after granting access permissions typically performed via PIN-verification as described later), and on their persistency in: token objects which persist when the token is plugged-out from the slot and in session objects which don’t persist. For each class of objects the specifications define a set of attributes (as described later) characterizing all instances of the class, which, are inherited by derived classes, similarly to an object-oriented model (for example, the Private Key class inherits all attributes from the Key class etc.)

The PKCS#11 API

PKCS#11 specifications define an API named Cryptoki (CRYPtographic TOKen Interface) that implements an API to an abstract model of a cryptographic device, such as a microprocessor-based smart card, a USB cryptographic token or an HSM. The API follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token. The API defines the most commonly used cryptographic object types (RSA keys, X.509 Certificates, DES/Triple DES keys, etc.) and all the functions needed to use, create/generate, modify and delete those objects:

The programming language used to define the functions and data types is ANSI C. Along with specifications, RSA Data Security published three C header files (pkcs11.h, pkcs11t.h and pkcs11f.h, available at this page: http://www.rsa.com/rsalabs/node.asp?id=2133) that define function prototypes, Cryptoki-specific data types and a set of macros to manage objects classes and their attributes.

ScrewTurn Wiki version 3.0.4.560. Some of the icons created by FamFamFam.