Introduction to PKCS#11 specifications

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.

<div class="imageauto"><img class="image" src="http://www.ncryptoki.com/Data/Sites/1/fig6.1.gif" alt="Image" height="316" width="433"><p class="imagedescription">Figure 1</div>

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.

<div class="imageauto"><img class="image" src="http://www.ncryptoki.com/Data/Sites/1/fig6.2.gif" alt="Image" height="146" width="434"><p class="imagedescription">Figure 2</div>
	
The specifications define three main object classes:
* ''Data''objects host generic data which semantics is defined by the application who created them;
* ''Certificate''objects store digital certificates;
* ''Key''objects 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:
 <a href="http://www.rsa.com/rsalabs/node.asp?id=2133">http://www.rsa.com/rsalabs/node.asp?id=2133</a>)
 that define function prototypes, Cryptoki-specific data types and a set
 of macros to manage objects classes and their attributes.
Meta Keywords: PKCS#11, Cryptoki
Meta Description: PKCS#11 Specifications
Change Comment:
NCryptoki Wiki

Navigation¶

Introduction to PKCS#11 specifications
