...
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 slot ID will never change during the runtime of your application. Other applications could have different slot IDs - all IDs (not only slot IDs) are always context specific i.e. they are only valid for your application! |
...
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:
- 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. 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.
...
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.- 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. - 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 - 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.
| The mix-up of sessions having different session states is very limited:
=> When a user session exists SO mode can NOT be established due to 1. => When a read session exists (and even no user is logged in) SO mode can NOT be established due to 3. |
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...