Controlling token access and key policy

The PKCS #11 standard was designed for systems that grant access to token information based on a PIN. The standard defines two types of users, the standard user (User) and the security officer (SO), each having its own personal identification number (PIN). The SO can initialize a token (zero the contents) and set the User's PIN. The SO can also access the public objects on the token, but not the private ones. The User has access to the private objects on a token and has the power to change his or her own PIN. The User cannot reinitialize a token. The PIN that a user enters determines which role that user takes. A user can fill both roles by having knowledge of both PINs.

z/OS does not use PINs. Instead, profiles in the SAF CRYPTOZ class control access to tokens. For each token, there are two resources in the CRYPTOZ class for controlling access to tokens:
  • The resource USER.token-name controls the access of the User role to the token.
  • The resource SO.token-name controls the access of the SO role to the token.

A user's access level to each of these resources (read, update, or control) determines the user's access level to the token.

There are six possible token access levels. Three are defined by the PKCS #11 standard, and three are unique to z/OS®. The PKCS #11 token access levels are:
  • User R/O: Allows the user to read the token including its private objects, but the user cannot create new token or session objects or alter existing ones.
  • User R/W: Allows the user read/write access to the token object including its private objects.
  • SO R/W: Allows the user to act as the security officer for the token and to read, create, and alter public objects on the token.
The token access levels unique to z/OS are:
  • Weak SO: A security officer that can modify the CA certificates contained in a token but not initialize the token. (For example, a system administrator who determines the trust policy for all applications on the system.)
  • Strong SO: A security officer that can add, generate or remove private objects in a token. (For example, a server administrator.)
  • Weak User: A User that cannot change the trusted CAs contained in a token. (For example, to prevent an end-user from changing the trust policy of his or her token.)
Table 1 shows how a user's access level to a token is derived from the user's access level to a resource in the SAF CRYPTOZ class.
Table 1. Token access levels
CRYPTOZ resource READ (SAF access level) UPDATE (SAF access level) CONTROL (SAF access level)
SO.token-label Weak SO

Can read, create, delete, modify, and use public objects

SO R/W

Same ability as Weak SO plus can create and delete tokens

Strong SO

Same ability as SO R/W plus can read but not use (see Note2) private objects; create, delete, and modify private objects

USER.token-label User R/O

Can read and use (see Note 2) public and private objects

Weak User

Same ability as User R/O plus can create, delete, and modify private and public objects. Cannot add, delete, or modify certificate authority objects

User R/W

Same ability as Weak User plus can add, delete, and modify certificate authority objects

Note:
  1. The USER.token-name and SO.token-name profiles will not be checked to determine access to the omnipresent token SYSTOK-SESSION-ONLY. ICSF creates this token to provide PKCS #11 support even if no other token is available to an application. All users will always by considered to have R/W access to this token.
  2. Use is defined as any of the following:
    • Performing any cryptographic operation involving the key object; for example C_Encrypt
    • Searching for key objects using sensitive search attributes
    • Retrieving sensitive key object attributes.
    The sensitive attribute for a secret key is CKA_VALUE. The sensitive attribute for Diffie Hellman, DSA, and Elliptic Curve private key objects is CKA_VALUE. The sensitive attributes for RSA private key objects are CKA_PRIVATE_EXPONENT, CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2, and CKA_COEFFICIENT.
  3. The CRYPTOZ resources can be defined as RACF®-DELEGATED if required. For information about delegated resources, see the topic on delegated resources in z/OS Security Server RACF Security Administrator's Guide.
  4. Although the use of generic profiles in the CRYPTOZ class is permitted, you should not use a single generic profile to cover both the SO.token-label and USER.token-label resources. You should not do this, because there are additional resources in the class controlling key policy. (See Guidelines in this topic for FIPSEXEMPT.token-label and CLEARKEY.token-label.) Creating a generic profile that uses generic characters to match both the SO and USER portion of the resource name (for example *.token-label) will also inadvertently match these other resources and can have unintended consequences.
  5. If the CSFSERV class is active, ICSF performs access control checks on the underlying callable services. The user must have READ access to the appropriate CSFSERV class resource. Table 2 lists the resources in the CSFSERV class for token services.
Table 2. Resources in the CSFSERV class for token services
Name of resource Service Called by
CSF1TRC Token or object creation C_InitToken, C_CreateObject, C_CopyObject
CSF1TRD Token or object deletion C_InitToken, C_DestroyObject
CSF1TRL Token or object find C_Initialize, C_FindObjects, CSN_FindALLObjects
CSF1SAV Set object attributes C_SetAttributeValue
CSF1GAV Get object attributes C_GetAttributeValue
CSF1GSK Generate secret key C_GenerateKey
CSF1GKP Generate key pair C_GenerateKeyPair
CSF1PKS Private key sign C_Decrypt, C_DecryptUpdate, C_DecryptFinal, C_Sign, C_SignFinal
CSF1PKV Public key verify C_Encrypt, C_EncryptUpdate, C_EncryptFinal, C_Verify, C_VerifyFinal
CSF1SKD Secret key decrypt C_Decrypt, C_DecryptUpdate, C_DecryptFinal
CSF1SKE Secret key encrypt C_Encrypt, C_EncryptUpdate, C_EncryptFinal
CSFOWH One-way hash C_Digest, C_DigestUpdate, C_DigestFinal, C_Sign, C_SignUpDate, C_SignFinal, C_Verify, C_VerifyUpdate, C_VerifyFinal
CSF1WPK Wrap key C_WrapKey
CSF1UWK Unwrap key C_UnwrapKey
CSF1HMG Generate MAC C_Sign
CSF1HMV Verify MAC C_Verify
CSF1DVK Derive key C_DeriveKey
CSF1DMK Derive multiple keys C_DeriveKey
CSFIQA PKCS #11 initialization C_Initialize
CSFRNG Random number generate C_GenerateRandom
Guidelines:
  1. If your organization controls access to ICSF callable services using the CSFSERV class, define the resources listed in Table 2 and grant access accordingly.

    Tip: Define generic profiles. For example, a profile named CSF* covers all the ICSF services. A profile named CSF1* covers the PKCS #11 subset of the ICSF services, with the exception of those covered by the CSFOWH, CSFIQF, and CSFRNG resources.

  2. The CRYPTOZ class supports generic profiles. Take advantage of this by creating a token naming convention for your organization and enforce it with generic profiles. For example, require users and applications to prefix their token names with their user IDs, as with data set names. (See Sample scenario for setting up z/OS PKCS #11 tokens.)
  3. For server applications, grant security officers (server administrators) Strong SO access and their end-users (server daemon user IDs) Weak User or User R/W access.
  4. For applications for which you do not wish to separate the security officer and end-user roles, grant the appropriate user IDs access to both the SO and USER profiles.
In addition to these two resources for controlling access to tokens, each token also has two additional resources in the CRYPTOZ class: FIPSEXEMPT.token-name and CLEARKEY.token-name.
  • The FIPSEXEMPT.token-name resource is used for identifying applications that are subject to FIPS 140 restrictions when ICSF is running in FIPS compatibility mode. Refer to Operating in compliance with FIPS 140-2 for more information.
  • The CLEARKEY.token-name resource will be queried to determine the policy for creating a clear in contrast to a secure key when CKA_IBM_SECURE=TRUE has not been specified for key generation. The following table indicates the significance of the different access levels. When there is no matching profile defined, the row indicating RACF access of UPDATE or No Decision is considered, the policy is to base the decision on the key’s sensitivity and whether an Enterprise PKCS #11 coprocessor is available or not.
Table 3. CLEARKEY.token-label resource access and key security policy
Key Security Objective RACF ACCESS Action taken when PKCS #11 coprocessor not available or algorithm not supported Action taken when PKCS #11 coprocessor available and algorithm supported
Generate no secure keys. Stay compatible with earlier releases CONTROL
Sensitive – Clear Key
Non-sensitive – Clear Key
Sensitive – Clear Key
Non-sensitive – Clear Key
Use key sensitivity and environment to determine security UPDATE or No Decision
Sensitive – Clear Key
Non-sensitive – Clear Key
Sensitive – Secure Key
Non-sensitive – Clear Key
Ensure keys explicitly marked sensitive are always secure keys READ
Sensitive – Denied
Non-sensitive – Clear Key
Sensitive – Secure Key
Non-sensitive – Clear Key
Prevent generation or creation of any clear keys NONE
Sensitive – Denied
Non-sensitive – Denied
Sensitive – Secure Key
Non-sensitive – Secure Key
Service specific notes:
  1. For generate key and generate key-pair, CLEARKEY.token-label checking is always performed as described previously.
  2. For create object, no CLEARKEY.token-label checking is performed. By default, all keys created via create object are clear keys. To get an encrypted key, the caller must specify CKA_IBM_SECURE=TRUE. Such keys are not true secure keys since the sensitive key material has appeared in-the-clear outside the bounds of the secure coprocessor.
  3. For copy object, no CLEARKEY.token-label checking is performed. By default, the source key’s security is carried forward to the target key. Clear keys may be upgraded to encrypted keys by specifying CKA_IBM_SECURE=TRUE.
  4. For unwrap key, the security of the base key always determines the security of the unwrapped key. However, in the case of clear key unwrap, CLEARKEY.token-label checking is performed to see if clear keys are permitted.
  5. For derive key, the base key can be clear or secure. The resulting derived key will be clear. CLEARKEY.token-label checking is performed to see if clear keys are permitted.
General notes:
  1. You should avoid setting a discrete or generic profile that would restrict clear key creation in the omnipresent token. This token is used by other z/OS components to create session keys only. It is typical for session keys to be clear keys. The clear key resource checked for the omnipresent token is CLEARKEY.SYSTOK-SESSION-ONLY.
  2. If no CLEARKEY profile is created to protect a given token, the No Decision row governs the action taken for that token for key creation and generation requests. The action taken depends on whether a PKCS #11 coprocessor is active or not. If no PKCS #11 coprocessor is active, all key creation and generate requests result in clear keys. If a PKCS #11 coprocessor is made active, sensitive keys (CKA_SENSITIVE=TRUE) may be generated as secure keys, depending on the algorithm. This could have an unexpected effect on existing programs.