Re: i5/OS Encryption

I just converted a set of tables to use encryption and selected the AES
algorithm. I could choose a new column size of 16, 24, 32 or multiple
thereof. So Social Security Numbers would only have to be stretched to a
16 byte field. Credit Card numbers didn't need any length changes.

Also, note that IBM recommends the column(s) have a CCSID of 65535 since
as encrypted it is binary not character data. In practice as long as the
data never goes anywhere that requires a conversion (like to a PC file)
you *can* get away without using column different CCSIDs. YMMV!

There are at least two algorithms (I think RC4 and another) that you can
use with SQL functions but they have other field length rules and always
(I think) increase the length. Their advantage is that you can execute a
SQL statement for the key code and then do the rest of your retrieval
with common SQL statements. Otherwise if you use native record IO you
have to take the encrypted value and pass it to an API with the key code
to get the clear value and the reverse to store it.

As Bruce said, handling of the keys is where the most thought really
goes. The above project had a very very basic requirement. The keys were
stored in a special library that *NEVER EVER* gets in a normal backup.
As the impetus exposed, you don't want your encrypted data on the same
tape as the keys. Kinda of like leaving the car keys on a key chain with
a bright strobe light in your car with the windows rolled down. IBM now
has some really neat APIs to let i5/OS store your keys for you so that
no backup (not even a Save 21) will ever include the keys. You still
need to make a special store of the keys as you set them up so you can
restore them in a DR.

Back to Steve's question. Implementation was pretty simple.

1) Lots of thought about the algorithm and key storage.
2) Basic database impact analysis. Exactly the same as any other change
to the database.
3) Change the DDS for field lengths.
4) CHGPF to apply the new fields lengths.
5) Change the programs that actually use the encrypted field to use the
APIs (via a service program) and %SUBST for clear values.
6) Recompile the rest of the programs that use the altered files.
7) Run a program to use the APIs (or service program) to encrypt the data.

3 Unique Files (but multiple copies for multiple companies)
1 Service program
1 Key implementer/changer program
3 Programs that actually used the encrypted columns modified.
15 Logical Files
30 Programs that use the files.
1 Key storage library
3 Days total and the end users never knew the difference.

No expansion of SQL usage. I would never turn off LVLCHK and actually
beat the heck out of a package vendor (that provided full source) that did.

If I had thought through the handling of the keys sooner I would have
implemented the encryption a lot (at inception) sooner.

I actually set up the service program as a variation of one I found by
Bob Cozi that I switched to AES and variable multiples of 16 byte
encrypted/clear parms. (Thanks Bob) The program I used in step 7 uses a
random binary string generator API (not the CEERND (sp?)). But first it
looks at the currently stored key. If that key is not = *BLANKS it uses
it to unencrypt the field and then uses the new random key to encrypt
and store the field. Then finally it stores the new key. This way, any
time (some what regularly) it can be run again to change the keys and
then a special (run and storage location) backup tape to preserve the
new key.

Sorry about the long windiness, but if I had seen something like this I
would have jumped in a long time ago. The only reason I now see not to
use encryption liberally is the OS version and availability of AES as it
seems to be the latest, bestest algorithm.

Roger Vicker, CCP

On 6/10/2007 6:27 PM, R Bruce Hoffman wrote:

As a practical matter, I can't think of a column, offhand, that would
qualify for encryption, that would not need to be expanded. SSN, devoid
of punctuation, under 3DES would require 32 characters for encryption.
In traditional i5/OS, DDS described files, very few people (if any) ever
defined a 9 digit SSN as a 32 character varying for bit data field. Even
if they stored it as character with punctuation, it's 11 characters.
Even with the original RC2 encryption, 11 becomes 19, and then becomes
24. (8 byte boundaries are used after the "additional" space is allocated.)

So, I would consider the statement about not increasing the length of a
field to be naive at best, and misleading.

The first step in using in place encryption, would most likely be to
isolate yourself from physical changes in the database. As long as you
are tied to the physical layout, recompiles are inevitable. This could
mean changing away from native I/O to SQL, or careful reconstruction of
your database, oriented towards turning off level checks followed by
appending the encrypted fields and then altering the programs that need
to access the encrypted data.

Encryption of the data in the database is not a quick add-on. It
requires careful planning including, but not limited to, how to handle
the encryption passwords.


Steve Martinson wrote:

More and more in my consulting travels, I come across
"AS/400-iSeries-i5-System i" (covering all my bases per a previous thread...
;-) shops that have i5/OS data-at-rest encryption requirements. This is not
an area of expertise for me or our company, so I typically tell them to look
at the cryptographic capabilities that are native to the OS or, if they
don't have in-house development support, tell them that they can check out
the various iSeries vendors for solutions.

My question to all of you bona fide programmers is: How much of an issue is
it (or would it be) for your shop to have to modify an existing DB2 table
due to column expansion required by an encryption enhancement?

IBM says "Depending on the encryption algorithm used to encrypt the data,
the length of an existing column might not have to be increased." You would
probably limit the number of encrypted DB columns to only the most sensitive
fields (think PCI-DSS) and, by doing so, also minimize the hit taken due to
performance and sorting restrictions when using encryption.

Would you seek out and try to incorporate the IBM algorithm that does not
increase column size to save work and reduce the "pain" of reaching
compliance? Or is it not that big of a deal when dealing with so few
fields? Would column expansion matter when buying off-the-shelf?

Best regards,

Steven W. Martinson, CISSP, CISM
Sheshunoff Management Services, LP.
Senior Consultant - Technology & Risk Management
2801 Via Fortuna, Suite 600 | Austin, TX 78746
Direct: 281.758.2429 | Mobile: 512.779.2630
e.Mail: smartinson@xxxxxxxxx



____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.
http://farechase.yahoo.com/