PKCS#11 is the standardization of a platform independant API for cryptographic tokens – in short "cryptoki" which stands for cryptographic token interface. Whenever we speak of cryptoki we use it as a synonym and mean the specification (see [CRTK04]) of the standard (other documents often mean the API).

On a physical abstraction level the standard is located almost on the top of the layers. Figure 1 shows how cryptoki is integrated in our environment. The standard itself does not define what kind of security token is used. Our implementation of cryptoki exclusively accesses smartcards as shown in Figure 1.

Image Added

Figure 1: abstraction layer of cryptoki

Cryptoki has the goal to simplify the access of cryptographic hardware. Once developers have integrated the API and use it within their applications they can switch the middleware to a different PKCS#11 implementation and use the dedicated security token without chaning any line of code as far as both security tokens offer the same features and do not have distinct special behaviours.
Before we list our supported parts of cryptoki (see chapter 2) we first want you to get familiar with some basic cryptoki principles. Developers who already got in contact with PKCS#11 can go on with reading the next chapter but are also invited to read the introduction parts.

Anchor
_Toc453149736 _Toc453149736

Anchor
_Toc453920086 _Toc453920086

Basic principles of PKCS#11

...

The mechanism-info gives information about the mechanism-class (in form of boolean values – isEncrypt, isDecrypt, …) and the token-specific supported key- or digests output-sizes.

Anchor
_Ref452969474 _Ref452969474

Anchor
_Toc453149744 _Toc453149744

Session

...