Controlling Access to Decrypted Values

There are two levels of security that can be used in Powertech Encryption for IBM i to control access to the decrypted field values.  At the 1st level of security, you should give *USE authority to the Key Store objects (which hold the decryption Keys) only for those users (or user groups) that can perform decryption, and *USE authority to the library that contains the Key Store. At the 2nd level of security, you can assign Authorization Lists to the field entries in the Field Encryption Registry and use designated APIs to only return the authorized values.

1st Level of Security - Key Store Authority

When a Key is requested to encrypt or decrypt data, Powertech Encryption for IBM i will first check if the user has at least *USE authority to the Key Store which holds the Key. If the user is not authorized to the Key Store, then the Key request will be denied and subsequently the user will not be able to proceed with the encryption or decryption of the data. The authority error will also be logged in the audit journal file.

It is likely that you will want a smaller group of users that can access (decrypt) sensitive data, compared to a larger group of users that can enter (encrypt) this data.  This can be accomplished by using two Key Stores with their own respective authorities.  In the first Key Store, you can store the Keys needed for encryption and give that Key Store a broader set of authorities. In the second Key Store, you can place the Keys needed for decryption and give that Key Store a much smaller set of authorities.

EXAMPLE:
For instance, any data entry user may be allowed to enter a credit card number and therefore must be authorized the Key Store holding the encryption key.  However, perhaps only Supervisors are allowed to view the credit card numbers and must therefore be authorized to the Key Store holding the decryption key.

Each Key within a Key Store can be designated for encryption only, decryption only, or both encryption and decryption. In the following example, the Keys in KEYSTORE1 may only be used for encryption and the Keys in KEYSTORE 2 may only be used for decryption. Notice that KEYSTORE1 has a broader list of authorities than KEYSTORE2.

(see following steps to implement this example)

Key Store Authority example

Listed below are the steps needed to implement two Key Stores with different authorities:

  1. Create KEYSTORE1 to contain the Key(s) needed for encryption. 
    EXAMPLE:
    >  CRYPTO/CRTKEYSTR KEYSTR(library/KEYSTORE1) MEKID(master-key-id)
  2. For KEYSTORE1, grant *USE authority only to those users (or user groups) that can perform encryption. 
    EXAMPLE:
    >  EDTOBJAUT OBJ(library/KEYSTORE1) OBJTYPE(*VLDL)
  3. Create KEYSTORE2 to contain the Key(s) needed for decryption. 
    EXAMPLE:
    >  CRYPTO/CRTKEYSTR KEYSTR(library/KEYSTORE2) MEKID(master-key-id)
  4. For KEYSTORE2, granting *USE authority only to those users (or user groups) that can perform decryption.
    EXAMPLE:
    >  EDTOBJAUT OBJ(library/KEYSTORE1) OBJTYPE(*VLDL)
  5. Create the Key in KEYSTORE1.  Allow the Key to be used for encryption only. 
    EXAMPLE:
    >  CRYPTO/CRTSYMKEY KEYLABEL(CREDIT_CARD_KEY) KEYSTR(library/KEYSTORE1)    

                       ENCRYPTALW(*YES) DECRYPTALW(*NO)
  6. Copy the Key from KEYSTORE1 to KEYSTORE2. 
    EXAMPLE:
    > CRYPTO/CPYSYMKEY FRMLABEL(CREDIT_CARD_KEY) FRMKEYSTR(library/KEYSTORE1)

    TOLABEL(*FRMLABEL) TOKEYSTR(library/KEYSTORE2)                                       
    NOTE: Since Powertech Encryption for IBM i uses Symmetric cryptology, the actual key values for the encryption and decryption keys must be the same.  This is why the decryption key must be copied from the first Key Store into the second Key Store, versus re-created.
  7. Change the Key in KEYSTORE2 so it can only be used for decryption.
    EXAMPLE:
    >  CRYPTO/CHGSYMKEY KEYLABEL(CREDIT_CARD_KEY) KEYSTR(library/KEYSTORE2) 

      ENCRYPTALW(*NO) DECRYPTALW(*YES)
  8. If using the Field Encryption Registry to encrypt the field values, listed below is an example of specifying the Key in KEYSTORE1 for encryption and the Key in KEYSTORE2 for decryption.
    EXAMPLE:
    > ADDFLDENC… ENCKEYLBL(CREDIT_CARD_KEY) ENCKEYSTR(library/KEYSTORE1)

       DECKEYLBL(CREDIT_CARD_KEY) DECKEYSTR(library/KEYSTORE2)                         

2nd Level of Security – Field Registry Authorization Lists

Authority settings can control what portion of the field values are available for users and groups.  For instance, one group of users could be authorized to the fully decrypted field values,  whereas a second group could be authorized to just the masked values, and a third group of users may be restricted from accessing any values for the field.  You can control this access through IBM i Authorization Lists and Powertech Encryption for IBM i’s Field Encryption Registry. 

Listed below is an example of the steps needed to create Authorization Lists and then associate them to a field in the Field Encryption Registry:

  1. Create an IBM i Authorization List to control authority to the full decrypted values for a field. 
    EXAMPLE:
    >  CRTAUTL AUTL(CCFULL) TEXT(‘Auth. List of Users with full access’)
  2. For the CCFULL Authorization List, grant *USE authority only to those users (or user groups) that should have access to the full decrypted values. 
    EXAMPLE:
    >  EDTAUTL AUTL(CCFULL)
  3. Create an Authorization List to control authority to the masked values for a field. 
    EXAMPLE:
    >  CRTAUTL AUTL(CCMASK) TEXT(‘Auth. List of Users with masked access’)
  4. For the CCMASK Authorization List, grant *USE authority only to those users (or user groups) that should have access to the masked values.
    EXAMPLE:
    >  EDTAUTL AUTL(CCMASK)
  5. When adding a field to the Field Encryption Registry, listed below is an example of how to specify the masking format and Authorization Lists for the field. 
    EXAMPLE:
    > ADDFLDENC… FLDMASK(‘************9999’)     
                    AUTLDEC(CCFULL) AUTLMASK(CCMASK) NOTAUTHFV(‘#’)

    You can also specify the fill value to use (with the NOTAUTHFV parameter) when the user does not have authority to either Authorization list.   

Based on the example settings used above, the field value returned on a decryption request will be one of the following:

  • The fully decrypted value, if the user has at least *USE authority to the CCFULL Authorization List. 
  • Otherwise it will return the masked value, if the user has at least *USE authority to the CCMASK Authorization List.
  • Otherwise it will return the fill value if the user does not have at least *USE authority to either the CCFULL or CCMASK Authorization Lists. For instance, if the fill value is #, then a 16 byte field will get a return value of ################
NOTE: The user will additionally need at least *USE authority to the Key Store object which holds the key needed for decryption and *USE authority to the library that contains the Key Store.

If using DB2 Field Procedures, then the authorized values will automatically be returned to the application/user on read operations. Otherwise, APIs in Powertech Encryption for IBM i can be used to access the authorized field values for the user. Read about the GetEncFldAuth Field Decryption API (in the Programmers Guide) if you are storing the encrypted field values externally. Read about the DecFldAuth Field Decryption API if you are storing the encrypted field values within the existing database. The GetEncFldAuth and DecFldAuth APIs have corresponding program call APIs, SQL functions and Stored Procedures which can optionally be used from your applications, which are also documented in the Programmers Guide. If needed, contact Powertech Support for the Programmers Guide.