...
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:
...
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
...