Using the Symmetric Key Export (CSNDSYX or CSNFSYX) callable service, an application can transfer a symmetric (AES or DES) key from encryption under a master key to encryption under an application-supplied RSA public key. This callable service is used because a secure key (which is encrypted under a master key in the ICSF environment) might need to be shared with a partner, and to transfer it to that partner securely, it will need to be encrypted under an RSA key provided by the partner. The partner will then be able to decrypt it using a corresponding private key.

The export operation performed by the Symmetric Key Export callable service does not fit into a traditional access control hierarchy. Due to the nature of the export operation, you might want to restrict users from accessing a symmetric key for the purpose of exporting it, while still allowing users to access the key for other purposes. By enabling the Symmetric Key Label Export control for AES or DES keys, and creating profiles in the XCSFKEY resource class, you can increase the level of access authority needed to export AES or DES keys without increasing the level of authority needed to access the keys for other operations.

By default, the CSFKEYS class determines access authority to cryptographic keys passed to callable services (including the CSNDSYX/CSNFSYX callable service). When the Symmetric Key Label Export control for AES or DES keys is not enabled and the CSNDSYX or CSNFSYX service is called, a user needs only READ authority for the key (as specified in a CSFKEYS class profile). If, however, the Symmetric Key Label Export control for AES or DES keys is enabled and the CSNDSYX or CSNFSYX service is called, then a user needs UPDATE authority for the key (as specified in an XCSFKEY class profile). The Symmetric Key Label Export controls affect only the CSNDSYX/CSNFSYX callable service; for all other callable services, access to cryptographic keys is checked against profiles in the CSFKEYS class. What's more, the Symmetric Key Label Export controls affect access only to the symmetric key the application is attempting to export, and do not affect access to the RSA key that is being used to re-encrypt the symmetric key. Access authority to the AES or DES key will be checked against XCSFKEY class profiles, while access to the RSA key will still be checked against CSFKEYS class profiles.

It is recommended that you activate Key Store Policy for the CKDS before enabling the Symmetric Key Label Export control for AES or DES keys. If Key Store Policy is not activated for the CKDS and the Symmetric Key Label Export control for AES or DES keys is enabled, the access authority check for the symmetric key will be performed only when it is identified to the CSNDSYX or CSNFSYX callable service by its key label. If the application were to pass the callable service a key token instead of a key label, then no authorization checking will be performed. When a token is passed, ICSF will, in order to initiate a SAF authorization check, rely on an active Key Store Policy for CKDS. Enabling any one of the following controls will activate Key Store Policy for a CKDS:

• CSF.CKDS.TOKEN.CHECK.LABEL.WARN
• CSF.CKDS.TOKEN.CHECK.LABEL.FAIL
• CSF.CKDS.TOKEN.NODUPLICATES

The following table shows the controls for enabling Symmetric Key Label Export for AES or DES keys. To enable the controls, create the appropriate profile in the XFACILIT class. There are separate Symmetric Key Label Export controls for AES and DES keys, so you can require UPDATE authority (which will be checked against XCSFKEY profiles) for export of one type of key, while still requiring only READ authority (which will still be checked against CSFKEY profiles) for export of the other type of key. There are no Symmetric Key Label Export controls that enable the policy in a warning mode. However, you can use the WARNING operand on XCSFKEY profiles to achieve the same results.

For example, you want to require UPDATE authority to export any symmetric key (AES or DES) using the Symmetric Key Export callable service. You're not certain all the users currently exporting symmetric keys will have the necessary access authority, and do not want to disrupt current work patterns at your installation. For this reason, you decide to allow a warning period during which you can identify which users will need to be granted increased authority. To do this, you would:

1. Create profiles in the XCSFKEY class to cover the symmetric keys. In this example, your installation has a consistent naming policy for AES and DES key labels, so the following two generic profiles will cover all symmetric keys. The WARNING operand is specified to initiate the warning period.

   RDEFINE XCSFKEY AES* UACC(NONE) WARNING
   RDEFINE XCSFKEY DES* UACC(NONE) WARNING

   The XCSFKEY class will need to be activated and placed in common storage:

   SETROPTS CLASSACT(XCSFKEY)
   SETROPTS RACLIST(XCSFKEY)

2. Enable the Symmetric Key Label Export control for AES and DES. In this example, we enable both controls so that UPDATE authority is required when exporting any symmetric key.

   RDEFINE CSF.XCSFKEY.ENABLE.AES
   RDEFINE CSF.XCSFKEY.ENABLE.DES

3. Because the WARNING operand was specified on the generic profiles AES* and DES*, any failing access check will still allow access to the symmetric key, but will issue a warning message and log the access. Using this information, you can grant UPDATE access to users or groups as needed. Since the generic profiles in our example cover all AES and all DES keys, you may need to create other generic profiles or discrete profiles to limit access for certain users. Here, user BOBADMIN is given UPDATE access to all symmetric keys, while user GWEN is given UPDATE access to the key labeled DES.BURDA.MEDINC.

   PERMIT AES* CLASS(XCSFKEY) ID(BOBADMIN) ACCESS(UPDATE)
   PERMIT DES* CLASS(XCSFKEY) ID(BOBADMIN) ACCESS(UPDATE)
   RDEFINE XCSFKEY DES.BURDA.MEDINC UACC(NONE)
   PERMIT DES.BURDA.MEDINC CLASS(XCSFKEY) ID(GWEN) ACCESS(UPDATE)

   The XCSFKEY class will need to be refreshed in common storage:

   SETROPTS RACLIST(XCSFKEY) REFRESH

4. When you are ready to move to a stricter implementation of the policy, you can end the warning period. To do this, update the necessary profiles in the XCSFKEY class using the RALTER command with its NOWARNING operand.

   RALTER XCSFKEY AES* UACC(NONE) NOWARNING
   RALTER XCSFKEY DES* UACC(NONE) NOWARNING

   The XCSFKEY class will need to be refreshed in common storage:

   SETROPTS RACLIST(XCSFKEY) REFRESH