Yes, you can run ICSF without a crypto card, however, the functionality may be somewhat limited. If the CPACF is enabled you have hardware support for clear key AES and DES/TDES encryption and SHA hashing. (It also depends on which machine you're running on. For example, the z10 and z196 can do all of the above, however if you're still running on a z890/z990 we didn't support AES clear key in the hardware.) The PCI card provides significantly more crypto functionality (secure key encryption, ATM/PIN processing, RSA support and key generation).
Starting with HCR7751 (which shipped with z/OS 1.11), ICSF also supports a clear key only CKDS. Prior to that version you had to have a crypto card to create a CKDS where you could store keys. With HCR7751 you have the option of creating a CKDS that will only contain clear keys. One of the drivers for that support was the Data Encryption Tool for IMS and DB2. DB2 can take advantage of the crypto infrastructure two ways: The DB2 Built-In Functions or The Data Encryption Tool for IMS and DB2 The Built-In Functions require changes to the database and to the application, however that means that the application has more control over exactly which data is encrypted, and how it is protected. You code the BIFs in your app to encrypt the columns that need to be encrypted. The application is also responsible for the keys that are used. The Data Encryption Tool for IMS and DB2 is a priced product that allows you to encrypt the entire table, on a row-by-row basis. It uses an exit (EDITPROC) for each table and the EDITPROC specifies which key (stored in the CKDS) will be used to encrypt the table. Each time the table is written/read, the EDITPROC is driven and the appropriate encryption/decryption performed. It relies on ICSF to get the key from the CKDS and then invokes the appropriate APIs or instructions to perform the encryption. Implementing the Data Encryption Tool does not require changes to the application, nor changes to the table layout. You do need to unload the table to a sequential file, define the EDITPROC with the key label for the table, and then reload the table which will drive the EDITPROC and encrypt the table. So, ICSF is a pre-req for the product, however with the new clear key only CKDS support, a crypto card is not a requirement. Hope that helps. Greg On Fri, 23 Jul 2010 11:18:02 -0400, Lizette Koehler <[email protected]> wrote: >I have been asked to research the use of ICSF in DB2. > >I know that ICSF comes with z/OS. However, I am not sure if it really requires a Crypto card to run. > >Q1: Can you run ICSF without a Crypto Card? > >Second, the intent is to encrypt row(s) of DB2 Data. Is ICSF the best way to go or are there other options? > > >I will probably switch over to the DB2-L Group on this, but wanted to know about the basic ICSF and Crypto Card issue first. > >Thanks > >Lizette > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
