Page History

...

Cryptoki supports multislot architecture where our implementation uses slots to identify smartcard readers. More generalized a slot can be seen as a hardware element having a security token inserted or not. Each slot has a unique ID which does not change as long as cryptoki is once initialized.

...

The session-state limits the visibility of the token's objects and manages its access rights e.g. whether an object can be persistently written to the smartcard. We distinguish the following states:

1. Public read mode
   In public read mode we can create / destroy temporary public non token objects – also called public session objects. Furthermore we can see all objects on the token which are tagged as public.
   
   

2. Public read / write mode
   In this mode we have the same features as in the previous mode. Furthermore we can persistently write public objects to the card such as a certificate, a public data object or a public key. We also can destroy those objects.
   

...

1. 
   

   Image Added

   The applet installed on our smartcards supports the import of public keys BUT does not support internal calculations with them. This has the following reason: Whenever a keypair (public / private key) is imported or generated the necessary information for doing cryptographical calculations is completely stored within the private key record. A public key record will be also written but this is just for completeness. On APDU level whether doing a public (encrypt / verify) or a private (decrypt / sign) calculation always needs the private key to be selected! It is possible to store a single public key in a public key record BUT the applet will not be able to use it to encrypt or verify data. In order to support those calculations for single public keys or session objects (session objects are not stored on the token resulting in not being able to use the cards cryptographic processing unit) we offer this in software.

2. User read mode
   In this mode we have the same options as in the first mode. Furthermore we can read the private objects stored on the token and access them for cryptographic operations. Additionally we can create and destroy private session objects.
   
   
3. User read / write mode
   In this mode we have the same options as in the previous mode. Furthermore we have full access to create and destroy objects on the token. This mode is necessary to import or generate keypairs, secret keys or private data objects
   
   
4. SO mode
   In this mode we have the same options as in the first mode. Furthermore we can set (reset) the users PIN and install public root certificates (by tagging them with TRUSTED – this is not supported yet). We do NOT have any access to private objects but can create and destroy public token objects.

• • In order to create a user read session, create a public read session and log in as user.
  • In order to create a user read / write session, create a public read / write session and log in as user.
  • In order to create a SO session, create a public read / write session and log in as SO.

See Figure 2 for visualization.

Anchor
_Toc453149746 _Toc453149746

Anchor
_Toc453920102 _Toc453920102

...

Image Added

Anchor
_Ref452724889 _Ref452724889

Figure 2: session states

Anchor
_Toc453149747 _Toc453149747

Session objects

As we see objects stored on the token are accessible in different ways whereas session objects can be always created / destroyed creating private session objects is still limited to user mode!.

Image RemovedImage Added

A session object lives as long as its origin session stays alive and is accessible by all other sessions accessing that slot in an application specific context - other applications may have their own session objects but do not have any access to foreign application specific created session objects.. Other slot specific sessions are also allowed to destroy a session object even when they do not have created it! Image Removed

Anchor
_Toc453149748 _Toc453149748

Token Object

...

So far we've learned some PKCS#11 basics and are ready to exercise some workflows. As we already know we need a user read / write session in order to write private objects and at least a public read / write session to write public objects to the token. This small example tells us how to initialize the library and create a user read / write session. More information about e.g. how to gernerate or to import a keypair can be read in 3 and 5.

Before we can initialize the library we have to receive the PKCS#11 function addresses. This is done by calling C_GetFunctionList using an instance of CK_FUNCTION_LIST_PTR as parameter. After C_GetFunctionList returns successfully we can use the CK_FUNCTION_LIST_PTR for calling the PKCS#11 defined functions.

First we have to initialize the library by using the CK_FUNCTION_LIST_PTR to call C_Initialize. For this call we use NULL as parameter. The library then starts to communicate with the SCARD interface (also known as PCSC-lite) and retrieves all available smartcard information from the OS.

Now we have to call C_GetSlotList in order to get the available smartcard readers and their IDs. We can use CK_TRUE as first parameter in order to receive all slots having a smartcard inserted.

After receiving a valid slot having a token / smartcard inserted we can use its ID to create a session. For creating a session we call C_OpenSession having one previously received slotID and CKF_SERIAL_SESSION | CKF_RW_SESSION as two of the five parameters.

Now we are ready to change the session state from public read write to user read write by calling C_Login. Then we are ready for creating / destroying token objects or using the smartcards crypto functionality like encrypt decrypt can even be called in public mode when using public key cryptography.

We can revert all these steps by calling the following functions in the specified order:

...