Tokenization for Centralizing Sensitive Data

Tokenization should be considered when sensitive data is stored on multiple systems throughout an organization.  Tokenization is the process of replacing sensitive data with unique identification numbers (e.g. tokens) and storing the original data on a central server, typically in encrypted form.  By centralizing all sensitive data onto a single system, tokenization can help thwart hackers and minimize the scope of compliance audits such as PCI.

Powertech Encryption for IBM i offers several advantages when tokenization is required:  

  • Centralizes key management and policies on a single server
  • Supports tokenization of data from diverse systems including IBM i, Windows, Linux, AIX, etc.
  • Provides remote connections to token functions through standard HTTP(S) protocol
  • Auto-assigns token identifiers from the central token server
  • Encrypts and stores tokenized data into scalable DB2 physical files
  • Allows securing data elements by User Id, User Group and/or Authorization Lists
  • Provides centralized audit logs and message alerts

Listed below is a diagram that illustrates Powertech Encryption for IBM i within a tokenized environment. 



Storage and Retrieval Process

When data needs to be stored (typically on an insert or update), the remote system will pass this data, along with the Field Id and User to the Token Server.  Powertech Encryption for IBM i will then assign a unique Token Id, and will encrypt and store that data into a DB2 physical file on the Token Server.  The Token Id will be returned to the remote system, which would usually be stored in the same field (or column) as where the original data used to be located.

When data needs to be retrieved from the Token Server, the remote system will pass in the Token Id, Field Id and User.  The data will then be retrieved from the DB2 physical file using the Token Id and Field Id.  Based on the User’s authority and requested function, Powertech Encryption for IBM i can return the fully decrypted value, masked value or no value (if not authorized) to the remote system.

Setting up Tokenization

Follow the steps below to set up tokenization in Powertech Encryption for IBM i for each remote data element.

Step1 – Create an entry in the Field Encryption Registry

First you should create an entry in the Field Encryption Registry using the ADDFLDENC command.  Listed below is the command with sample parameters:

CRYPTO/ADDFLDENC FLDID(ORDERS_CREDITCARD_PRODSYS1) 
     DBFLD(*REMOTE) 
     DBFLDTYP(*CHAR) DBFLDLEN(16) 
     ENCKEYLBL(ENCKEY1) ENCKEYSTR(KEYLIB/ORDERKEYS) 
     FLDMASK('************9999') 
     AUTLDEC(CCFULL) AUTLMASK(CCMASKED)
     STREXTFILE(*YES) EXTFILE(PRODLIB/CCFILE) 

When the ADDFLDENC command is prompted, you can press F1 on any parameter for help text.  Listed below is a summary of the parameters that should be specified when setting up tokenized fields:

  • FLDID –  It is recommended to have a descriptive field identifier that is composed of the file/table name, field name and the remote system name in which it is used.  In the example above, the field identifier is made up of the file name ORDERS, with the field name of CREDITCARD on the remote system of PRODSYS1
  • DBFLD – Always specify *REMOTE to denote that the data is from a remote system
  • DBFLDTYP – This is the data type of the field.  *CHAR means character data.  *DEC means decimal.
  • DBFLDLEN – Length of the data
  • ENCKEYLBL – Label of the Data Encryption Key (DEK)
  • ENCKEYSTR – Name of the Key Store that holds the DEK
  • FLDMASK – The format that will be used when returning masked values
  • AUTLDEC – The authorization list of users that are allowed access to the full decrypted values
  • AUTLMASK – The authorization list of users that are allowed access to the masked values
  • STREXTFILE – Always specify *YES to indicate that the encrypted values will be stored in an external physical file
  • EXTFILE – Specify the name and library of the external physical file to store the encrypted values

Step 2 – Activate the field in Field Encryption Registry

After adding the field to the registry, you then need to activate the field using the ACTFLDENC command.  Listed below is a command example with a sample field identifier:

  CRYPTO/ACTFLDENC FLDID(ORDERS_CREDITCARD_PRODSYS1)

The ACTFLDENC command will create the external physical file to hold the encrypted tokenized data for the field identifier and will change its status to *ACTIVE. 

NOTE: The external file will have the same authorities as the library in which it is created in.

Step 3 – Encrypt and tokenize existing data

On the remote system, a program should be written to loop through all records (rows) in the database file (table) that contains the data to encrypt.  For each record read, the program should call the appropriate Insert HTTP function on the token server, passing in the data to encrypt/store.  After calling out the Insert HTTP function, the returned token id should be stored in the existing database field.

Refer to the HTTP guide to learn about the insert procedures. 

Step 4 – Ongoing encryption and retrieval

Refer to the HTTP guide to learn about the procedures to call out from your remote systems for storing and retrieving data from the Token Server. 

Tokenization Considerations

Performance

Tokenization of data will not perform as well as native encryption/storage of data since the data has to be sent between systems over the network.  The speed of tokenized transactions will be primarily dependent on the performance of your IBM i token server and the speed of your network.  Adjustments can often be made to improve performance by consulting with Fortra. 

Failover

You should have a failover plan in case your token server is unavailable due to server failure or lost connections.  Without a failover token server and/or connection, the tokenized data will not be available to your remote systems until the token server/connection is restored.  Consult with Fortra on helping to develop an appropriate failover plan.