|
CRYPTOZ is a resource class defined in RACF in support of PKCS
#11. Access to PKCS #11 tokens in ICSF is controlled by the CRYPTOZ
class, with different access levels as well as a differentiation between
standard users and security officers. 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 Security Officer (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 22 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 22. Token access levels | SAF access level |
|---|
| CRYPTOZ resource | READ | UPDATE | CONTROL |
|---|
| 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 Note1) private objects; create,
delete, and modify private objects | | USER.token-label | User R/O
Can read and use (see Note 1) 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 |
Notes:
- "Use" is defined as any of these:
- 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 the 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.
- The CRYPTOZ resources can be defined as "RACF-DELEGATED" if
required. For information about delegated resources, see z/OS Security Server RACF Security Administrator’s Guide.
- 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 23 lists the resources in the CSFSERV class
for token services.
- READ access is required for token management via RACDCERT or gskkyman
command. To manage tokens through the token browser panels, you’ll
need READ access to services listed in Table 23.
- Although the use of generic profiles is permitted for the CRYPTOZ
class, we recommend that you do not use a single generic profile to
cover both the SO.token-label and USER.token-label resources. You should not do
this, because another resource (FIPSEXEMPT.token-label,
which is described in z/OS Cryptographic Services ICSF Writing PKCS #11 Applications) can be used to indicate whether compliance with
the FIPS 140-2 standard is desired at the token level. Creating
a profile that uses generic characters to match both the SO and USER
portion of the resource names (for example *.token-label)
will also inadvertently match the FIPSEXEMPT.token-label resource
and can have unintended consequences.
|
z/OS Cryptographic Services ICSF Administrator's Guide
Copyright IBM Corporation 1990, 2014