Install and configure the RPM or DEB

Use the following steps to install and configure the CCA RPM or DEB.

Procedure

  1. Copy the RPM or DEB to the host where it will be installed. For example, /root on your host image.
  2. Login to the host as root. Change to the directory where the installation package is located by issuing these commands:
    <login to host>
    cd /root/
  3. Validate the RPM or DEB file (optional)
    For more information, read Verify the RPM or DEB package signature.
  4. Install either the RPM or DEB by issuing one of the following commands:
    
    rpm -i <rpm_name>   /* for RPM */           
    dpkg -i <deb_name>  /* for DEB */
    Note:
    1. For compatibility reasons a softlink is created from /opt/IBM/CCA to /opt/IBM/CEX3C. This is not valid when installing the CCA DEB package.
    2. If this is an upgrade, you can use this command:
      
      rpm -Uvh <rpm_name>   /* for RPM */
      dpkg -i <deb_name>    /* for DEB, same as for installation */
    3. When upgrading your CCA DEB package, you may be asked if you want to overwrite the following files:
      • /etc/init.d/CSUTKEcat
      • /etc/profile.d/csulcca.sh
      Answer with option 'Y' in both cases ('Y' or 'I' : install the package maintainer's version). This replaces the previously installed files by the new files provided during the package upgrade.
    4. If you are installing the RPM on a SUSE Linux distribution, you might receive the following warning messages because of an unsupported groupadd option.
      groupadd: You are using an undocumented option (-f)!
      groupadd: You are using an undocumented option (-f)!
      groupadd: You are using an undocumented option (-f)!
      groupadd: You are using an undocumented option (-f)!
      groupadd: You are using an undocumented option (-f)!
      No action on your part is needed. The installation proceeds with another call if this happens.
  5. Reboot the host by issuing the following command: shutdown -r now
    This is necessary because of the defaults added to /etc/profile.d/csulcca.sh and /etc/profile.d/csulcca.csh for using CCA must be propagated to all user login sessions.

    If all users that use the CCA logout and then login again, and if all applications that use CCA are re-started, then a reboot may be avoided. It is always recommended to reboot to ensure for new users or new system administrators that the updated profiles are actually in force after the install procedure is completed.

  6. Login to the host as root. Change to the directory where the RPM or DEB binaries are installed by issuing the following command:
    <login as root to host>
    	cd /opt/IBM/CCA/bin/
  7. Verify that at least one card is present and active:
    Note: Starting with kernel 4.10, the cryptographic device driver (zcrypt) is statically built into the kernel. So there is no need to load the ap module any longer.
    1. If required, you can use the lszcrypt command to check if the zcrypt device driver is available:
      $ lszcrypt
      If the command displays the message Crypto device driver not available, the zcrypt device driver is not loaded. To load zcrypt, issue the following command:
      $ modprobe ap
      or on older kernels, issue:
      $ modprobe z90crypt

      With the zcrypt device driver loaded, you can use lszcrypt to see the installed and configured crypto adapters for your LPAR or z/VM® guest:

      CARD.DOMAIN TYPE  MODE        STATUS REQUEST_CNT
      ------------------------------------------------
      00          CEX6A Accelerator online        2174  <- Adapter 0 
      00.0005     CEX6A Accelerator online        1347   <- Domain 5 on adapter 0
      00.001f     CEX6A Accelerator online         827   <- Domain 31 (X'1F') 
      01          CEX6C CCA-Coproc  online       15635  <- Adapter 1 
      01.0005     CEX6C CCA-Coproc  online        9187
      01.001f     CEX6C CCA-Coproc  online        6448
      05          CEX6P EP11-Coproc online          17  <- Adapter 5 
      05.0005     CEX6P EP11-Coproc online          10
      05.001f     CEX6P EP11-Coproc online           7
      
      The latest version of the zcrypt device driver can deal with more than one domain. The previous screen shot shows two domains (with IDs 5 and 31). By default the device driver uses the domain with the lowest ID. You can change this by setting a new default domain value using the command
      $ chzcrypt --default-domain=x
      
      or with a kernel boot parameter ap.domain=x (where x must be in hexadecimal notation).

      For CCA applications, an adapter in CCA coprocessor mode is needed. So the lszcrypt output should show some CEX*C cards, for example, CEX6C.

    2. When you are sure that the device driver is loaded, you can display details of all the available CCA coprocessors and verify their accessibility by running one of the RPM or DEB installed utilities:
      1. /opt/IBM/CCA/bin/ivp.e

        This command performs a health check for all active cards.

      2. /opt/IBM/CCA/bin/panel.exe -status

        This command shows the serial numbers and master key register states of all active cards running CCA that are visible to this Linux host. The total number of active cards and any errors are also reported. You also see the CCA numbering of the CEXnC adapters and the default card is shown.

      Note:
      1. To be able to use /opt/IBM/CCA/panel.exe the user must be either root or a member of the cca_admin group, that is, the owner of
        
        /usr/lib64/libcsulccamk.so  /* for RPM */
        /usr/lib/libcsulccamk.so    /* for DEB */
        
      2. If there is not at least one active card at this point, double check earlier steps and, if necessary, involve IBM service because the rest of the setup is designed around having active cards.
      3. Unloading the device driver requires killing the catcher.exe program, and then restarting it when the driver is reloaded. See the note in Installing and loading the cryptographic device driver for specific instructions.
        Note: Unloading the device driver is not possible with the ap module being statically in the kernel.
  8. Master key load - This procedure is for using the Linux on IBM Z native API or the utility (panel.exe) to load the master keys for the active cards.

    There are several methods available to load the master keys, and it is important to choose the correct method for your production environment. For more information, see CCA Master Key administration: choosing the right method or tool.

    If you want to use the TKE instead of the panel.exe utility, refer to the z/OS Cryptographic Services for proper use and also refer to TKE catcher configuration for a TLS connection. After completing this step using the TKE procedure, go to Step 9.

    1. Setup the groups for the users who will be loading the master keys to the cards. Each part of the load process is owned by a different Linux group created by the RPM or DEB install procedure, and verified in the host library implementing the API allowing master key processing. To complete a specific step the user must have membership in the proper group. There are a couple ways to change group membership depending on your Linux distribution. A third option is to create the users specifically for these roles.

      If a user does not have the proper group membership for a particular master key operation, the error X'0008005a' is returned and an error message is printed to the system log.

      Note: To be able to use /opt/IBM/CCA/panel.exe, the user must be either root or a member of the cca_admin group, that is, the owner of
      
      /usr/lib64/libcsulccamk.so /* for RPM */
      /usr/lib/libcsulccamk.so   /* for DEB */
      1. Group membership for Red Hat and Ubuntu based Linux distributions:
        1. Use the groups command to see a list of the user's current group membership:
          groups <user name>
          				---output is
          					<user name> : <grouplist>
          					<grouplist> is a single-space separated list
        2. <grouplist> must be passed along with the new group to the usermod command as a comma-separated list, followed by the <user name>. For example, if you wanted to add cca_lfmkp membership to user named admin, you would use the following commands:
          groups admin
          				---output:
          					admin : admin bin daemon sys wheel
          				usermod -G admin,bin,daemon,sys,wheel,cca_lfmkp admin
          				---output:
          					[none if successful]
          Note: Ensure the user logs out and logs back in, otherwise the group membership in the active session will not be updated.
      2. Group membership for SUSE-based Linux distributions:
        Use the usermod command to add membership for a specific group for a specific user. For example, if you wanted to add cca_lfmkp membership to user admin, you would use the following commands:
        usermod -A cca_lfmkp admin
        Note: Ensure the user logs out and logs back in, otherwise the group membership in the active session will not be updated.
      3. Create users for each role with correct group memberships (Same commands for Red Hat, SUSE, and Ubuntu):
        1. Create user cca_user, which will own default key storage by issuing the following commands:
          1. useradd -g cca_admin -d /home/cca_user -m cca_user
            This command creates the user with primary group cca_admin and a new home directory.
          2. passwd cca_user
            This command sets the new user's password.
        2. Create user cca_lfmkp by issuing the following commands:
          1. 
            useradd -g cca_admin -d /home/cca_lfmkp 
                    -G cca_admin,cca_lfmkp -m cca_lfmkp
            This command creates the user with primary group cca_admin, secondary group cca_lfmkp, and a new home directory.
          2. passwd cca_lfmkp
            This command sets the new user's password.
        3. Create user cca_cmkp by issuing the following commands:
          1. 
            useradd -g cca_admin -d /home/cca_cmkp 
                    -G cca_admin,cca_cmkp -m cca_cmkp
            This command creates the user with primary group cca_admin, secondary group cca_cmkp, and a new home directory.
          2. passwd cca_cmkp
            This command sets the new user's password.
        4. Create user cca_clrmk by issuing the following commands:
          1. 
            useradd -g cca_admin -d /home/cca_clrmk 
                    -G cca_admin,cca_clrmk -m cca_clrmk
            This command creates the user with primary group cca_admin, secondary group cca_clrmk, and a new home directory.
          2. passwd cca_clrmk
            This command sets the new user's password.
        5. Create user cca_setmk by issuing the following commands:
          1. useradd -g cca_admin -d /home/cca_setmk 
                             -G cca_admin,cca_setmk -m cca_setmk
            This command creates the user with primary group cca_admin, secondary group cca_setmk, and a new home directory.
          2. passwd cca_setmk
            This command sets the new user's password.
    2. Add group membership privileges to users based on their required function.
      Table 1. CCA groups

      CCA groups

      Group Name Description
      cca_admin All users who will run part of the master key load process must be in this group because the library itself is owned by root.cca_admin, with no permissions for 'world' as a protective measure. Reasons for this separate group also include allowing one owner of /usr/lib64/libcsulccamk.so and of /usr/lib/libcsulccamk.so for DEB, and allowing use of panel.exe without allowing any of the master key processing calls.
      cca_lfmkp The user to LOAD the first key part must be in this group.
      cca_cmkp The users to LOAD the middle and last key parts must be in this group.
      cca_clrmk The new master-key register can be CLEARed using the same Master Key Process call in case a mistake was made entering a key part (use the key verification patterns to check for this). To perform the clear, the user must be a member of this group.
      cca_setmk The user to call SET after the last key part has been successfully loaded must be a member of this Linux group.
    3. Load FIRST, MIDDLE (optional), and LAST key parts for the AES, SYM, ASYM, and APKA master keys and then call SET for each master key. This step can be done using the panel.exe utility provided or by writing your own application to call the Master Key Process (CSNBMKP) verb directly. The application must link with the correct library (installed to /usr/lib64/libcsulccamk.so by RPM and to /usr/lib/libcsulccamk.so by DEB), and must be executed at each step by a user with the appropriate group memberships. The utility supports scripted as well as prompt-driven access.

      Repeat this step for each configured adapter. See Changing the master key for two or more adapters that have the same master key, with shared CCA key storage.

      For details about panel.exe, see The panel.exe utility.

      See Master Key Process (CSNBMKP) about parity requirements for master key parts.

      Note: Loading master key parts modifies state information inside the card. For example you cannot load a 'FIRST' master key part twice in a row without clearing the new master-key register in between attempts. The same goes for setting the 'LAST' register. Any number of 'MIDDLE' parts can be loaded - with each call changing the contents of the new master-key register. Similarly a 'SET' operation changes the state of the 'new' register back to 'empty', while updating the 'current' register.
  9. Key storage initialization - To perform this step, see Using panel.exe for key storage initialization.
  10. Key storage re-encipher when changing the master key - To perform this step, see Using panel.exe for key storage re-encipher when changing the master key.
  11. If you are going to be using Central Processor Assist for Cryptographic Functions (CPACF), it must be configured. See CPACF support.