Re: i5/OS Encryption

The boss wants a simple list sorted by encrypted
field with specific other requirements. This
happens a lot at here in the office, and I was
wondering how query or SQL access to those
encrypted fields is impacted.

I'm starting to work with the encryption functions, and the first thing I
wonder about is if the data is sensitive enough to encrypt, do you really
want to print it on a bunch of reports? Will you be logging who runs the
reports, and ensure that all of those reports are properly destroyed?

While you can key a file on an encrypted field, there would be no way to
predict the order of keys in that file. For instance the encrypted value
of account 567 may place it before the encrypted value of account 123.


Steven Morrison
Fidelity Express
903-885-1283 ext. 479



"Jim Essinger" <dilbernator@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/11/2007 02:58 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: i5/OS Encryption






Just a question from one that has not looked into encryption at all,

What is the impact of queries run over files with encrypted data? If the
encrypted field is a part of the key to access the records in the file,
what's the impact there? The boss wants a simple list sorted by encrypted
field with specific other requirements. This happens a lot at here in the
office, and I was wondering how query or SQL access to those encrypted
fields is impacted.

Thanks!

Jim

On 6/10/07, R Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx> 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