Welcome
Guest
, you are in:
<root>
•
Login
NCryptoki Wiki
Navigation
¶
Main Page
Random Page
Create a new Page
All Pages
Categories
Navigation Paths
Administration
File Management
Create Account
Search the wiki
»
Back
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:
ScrewTurn Wiki
version 3.0.4.560. Some of the icons created by
FamFamFam
.