IBM i > Administrator > DB2

The Next Step in Security

Given the numerous, well-publicized reports of personal data being stolen or compromised, its no surprise that consumers are demanding that greater efforts be taken to protect and privatize data. For iSeries* shops, increased data protection is a real requirement, since DB2* Universal Database* (UDB) for iSeries databases worldwide contain a plethora of sensitive consumer and business information.

 

One way to protect data is to utilize the robust security services offered by OS/400*. These security services are designed to help prevent unauthorized users from accessing personal and financial data stored in DB2 objects. However, when youre trying to limit access of authorized users (e.g., restricting support representatives from viewing customer Social Security Numbers (SSNs) ) OS/400 object-level security isnt as useful. And DB2 object security isnt designed to keep a hacker whos stolen an authorized users ID and password from accessing columns containing credit-card numbers.

In these situations, data encryption can provide another layer of security. For example, data containing credit-card numbers is encrypted as its written to a column (or field) in the orders table (or file). Once the data is encrypted, the encrypted versions of the credit-card numbers are always returned by default to any interface trying to access the orders table. Authorized users and applications can still access the orders table, but they cant view the credit-card numbers. The unencrypted (or decrypted) versions of the credit-card numbers can only be seen by those applications or users with access to the encryption key (or password) and decryption routines. Encryption provides an extra lock because to access these columns containing sensitive data, users must not only be authorized to the DB2 object, they must also have access to the encryption key and decryption function.

Encryption Prerequisites
For several releases, OS/400 has included cryptographic services (i.e., algorithms) that can be used with applications and system functions such as Secure Sockets Layer (SSL) and IP Security (IPSec). With IBM* i5/OS* V5R3 however, access to cryptographic services is integrated into DB2 through a set of encryption and decryption scalar functions. By installing the IBM Cryptographic Access Provider (5722-AC3), a 128-bit product, the DB2 encryption and decryption column functions can actually use the encryption algorithms embedded in i5/OS. So instead of interfacing directly with i5/OS cryptographic services, a developer can invoke a simple DB2 function:

INSERT INTO employees VALUES( ENCRYPT('777-88-9999'),
 'BOB SANDERS')

Once you verify that the Cryptographic Access API product is on your system, create a new column or modify an existing one so that encrypted data can be stored. The encryption process creates a string of binary data that requires one of these SQL data types be used in the column definition:

BINARY, VARBINARY
CHAR FOR BIT DATA, VARCHAR FOR BIT DATA
BLOB

If the target DB2 file is defined with DDS, the target field must be defined as a fixed- or varying-length character field with a CCSID value of 65535. In addition to its specific data type requirements, a column used to store encrypted data has size requirements because the encrypted string is longer than the original string value.

The length of an encrypted string value is the actual string length plus N bytes. Heres how N is defined:

• If a hint isnt specified, N is eight bytes (or 16 bytes if the input string is a large object (LOB) data type or different CCSID values are used for the input or password string) plus the number of bytes to the next eight-byte boundary.
• If a hint is specified, N is eight bytes (or 16 bytes if the data string is a LOB or different CCSID values are used for the input, password or hint string) plus the number of bytes to the next eight-byte boundary plus 32 bytes for the hint length.

Heres an example to better understand the length requirements (hints are covered later): A six-digit employee ID requires a target column length of 16 bytes: six bytes for non-encrypted data, eight extra bytes (assuming CCSID is constant and input string isnt a LOB) and two additional bytes to round the length to an eight-byte boundary.

 

Tweet