...
Anchor | ||||
---|---|---|---|---|
|
- CKA_CLASS
This attributes describes whether the object is a
- Data object -> CKO_DATA
- Certificate object -> CKO_CERTIFICATE
- Public key object -> CKO_PUBLIC_KEY
- Private key object -> CKO_PRIVATE_KEY
- Secret key object -> CKO_SECRET_KEY
- There are also objects like CKO_HW_FEATURE, CKO_DOMAIN_PARAMETERS, CKO_MECHANISM, CKO_OTP_KEY and CKO_VENDOR_DEFINED but these are out of scope for this documentation.
- CKA_TOKEN
This attributes decides whether the object will be stored on the token or is a session object.
- CKA_PRIVATE
This attribute decides whether a public session can read this object or the user must be logged in objects which should kept secret (like private- or secret keys) will internally overwritte this flag to private even when someone tries to create them as a public.
- CKA_MODIFIABLE
This attribute decides whether the object can be changed after it was created.
Not all attributes can be changed. Currently we only support changing the attributes mentionend in 3.3.3. |
The values set to the mandatory attributes influence the associated object for its complete lifetime. |
Object specific attributes
We previously learned that the CKA_CLASS attribute is responsible for determining the objects kind. Having this information leads us to being more specific in enclosing the objects implementation type. Lets have a look back to Figure 3. Each of the data-, key- and certificate object contains one more attribute giving better information about what the object really is all about:
...
- CKK_RSA and CKK_EC for CKA_KEY_TYPE
In conjunction with the CKA_CLASS attribute this leads to the following implementation types:
- RSA public key (CKA_CLASS -> CKO_PUBLIC_KEY)
- RSA private key (CKA_CLASS -> CKO_PRIVATE_KEY)
- EC public key (CKA_CLASS -> CKO_PUBLIC_KEY)
- EC private key (CKA_CLASS -> CKO_PRIVATE_KEY)
- CKC_X_509 for CKA_CERTIFICATE_TYPE
- and any user specific OID for CKA_OBJECT_ID
...
Regarding the implementation type each object has additionally attributes. Those attributes are defined here where the fat ones are mandatory while the others are optional. We first start with the base types before we handle the specific implementation types.
Each object inherits the base classe's attributes thus it also includes that attributes. Inherited attributes are no more listed and can be extracted from Figure 3. |
...
We will learn how the attributes shall be used in order to support our cryptoki implementation since in most of the writing-cases (create, change, generate) there are always some token (for us applet-) dependant attributes which are mandatory even when the specification says they are not or attributes which can't be modified or are unsupported.
Create / import an object
...
Table 3 describes the mandatory attributes for importing a RSA private key (token object) and a RSA public key (session object).
Since the applet generates the public key itself (for token objects) this object should not be created. Just import the private key and use the object-search (use the private keys CKA_ID) afterwards to find the corresponding public key. An example is given in 5.
RSA private key (token object) |
Do not use CKA_MODULUS_BITS as attribute when creating / importing a RSA keypair. This attribute is reserved and is used for detecting keypair generation! The attribute will be automatically set during import. |
We do not support the creation / import of a private key session object since we only allow public key operations in software. |
...
Since we only support public key operations in software a RSA private key can not be created as session object. Private key operations shall always be done in hardware – therefore import the private key as token object. RSA public keys can be created as session objects in order to encrypt
Anchor | ||||
---|---|---|---|---|
|
RSA public key (session object) |
Key Type | CKA_CLASS | CKA_TOKEN | CKA_PRIVATE | CKA_MODIFIABLE | CKA_KEY_TYPE | CKA_ID | CKA_PRIME_1 | CKA_PRIME_2 | CKA_PUBLIC_EXPONENT |
Private key (token object) | CKO_PRIVATE_KEY | CK_TRUE | CK_TRUE | CK_TRUE or CK_FALSE | CKK_RSA | All UTF8 symbols | CK_BYTE[] | CK_BYTE[] | CK_BYTE[] |
Key Type | CKA_CLASS | CKA_TOKEN | CKA_PRIVATE | CKA_MODIFIABLE | CKA_KEY_TYPE | CKA_ID | CKA_MODULUS | CKA_PUBLIC_EXPONENT | - |
Public key (session object) | CKO_PUBLIC_KEY | CK_FALSE | CK_FALSE | CK_TRUE or CK_FALSE | CKK_RSA | All UTF8 symbols | CK_BYTE[] | CK_BYTE[] | - |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
Table 3: RSA key import
...
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Table 5 describes the mandatory attributes for importing a EC private key (token object) and a EC public key (session object).
Table 4 lists the OIDs of the supported elliptic curves – use the desired OID as CK_EC_PARAMS.
Since the applet generates the public key itself (for token objects) this object should not be created. Just import the private key and use the object-search (use the private keys CKA_ID) afterwards to find the corresponding public key. An example is given in 5.
During the import a label can be also given. If not CKA_LABEL receives the same value as CKA_ID. |
We do not support the import of a private key session object since we only allow public key operations in software. |
Use one of the following OID values as CK_BYTE[] as value for CKA_EC_PARAMS attribute.
Defined elliptic curve | OID |
brainpoolP160r1 | 0x06, 0x09, 0x2B, 0x24, 0x03, 0x03, 0x02, 0x08, 0x01, 0x01, 0x01 |
brainpoolP192r1 | 0x06, 0x09, 0x2B, 0x24, 0x03, 0x03, 0x02, 0x08, 0x01, 0x01, 0x03 |
brainpoolP224r1 | 0x06, 0x09, 0x2B, 0x24, 0x03, 0x03, 0x02, 0x08, 0x01, 0x01, 0x05 |
brainpoolP256r1 | 0x06, 0x09, 0x2B, 0x24, 0x03, 0x03, 0x02, 0x08, 0x01, 0x01, 0x07 |
brainpoolP320r1 | 0x06, 0x09, 0x2B, 0x24, 0x03, 0x03, 0x02, 0x08, 0x01, 0x01, 0x09 |
ansi-x962 prime192v1 | 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x01 |
ansip224r1 | 0x06, 0x05, 0x2B, 0x81, 0x04, 0x00, 0x21 |
ansi-x962 prime256v1 | 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x07 |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Since we only support public key operations in software an EC private key can not be created as session object. Private key operations shall always be done in hardware – therefore import the private key as token object. EC public keys can be created as session objects in order to verify18 a signature. An example is given in 5.
EC public key (session object) |
Key Type | CKA_CLASS | CKA_TOKEN | CKA_PRIVATE | CKA_MODIFIABLE | CKA_KEY_TYPE | CKA_ID | CKA_EC_PARAMS | CKA_VALUE |
Private key | CKO_PRIVATE_KEY | CK_TRUE | CK_TRUE | CK_TRUE or CK_FALSE | CKK_EC | All UTF8 symbols | CK_BYTE[] | CK_BYTE[] |
Key Type | CKA_CLASS | CKA_TOKEN | CKA_PRIVATE | CKA_MODIFIABLE | CKA_KEY_TYPE | CKA_ID | CKA_EC_PARAMS | CK_EC_POINT |
Public key | CKO_PUBLIC_KEY | CK_FALSE | CK_ FALSE | CK_TRUE or CK_FALSE | CKK_EC | All UTF8 symbols | CK_BYTE[] | CK_BYTE[] |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
Table 5: EC key import
...
Generate a keypair
Table 6 shows the attributes necessary to generate a keypair. We only support this feature for token objects.
When calling the function C_GenerateKeyPair(…) the same template (the same pointer can be used) for pPublicKeyTemplate and pPublicKeyTemplate shall be used. |
We do not support the generation of keypairs for session objects. |
Keypair type | CKA_CLASS | CKA_TOKEN | CKA_PRIVATE | CKA_KEY_TYPE | CKA_MODULUS_BITS |
RSA KeyPair | CKO_PRIVATE_KEY | CK_TRUE | CK_TRUE | CKK_RSA | 512 – 2048 |
Keypair type | CKA_CLASS | CKA_TOKEN | CKA_PRIVATE | CKA_KEY_TYPE | CKA_EC_PARAMS |
EC KeyPair | CKO_PRIVATE_KEY | CK_TRUE | CK_TRUE | CKK_EC | use one OID from Table 4 |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Currently we do only support to change CKA_ID. |