On Apr 13, 2010, at 9:28 AM, James H. H. Lampert wrote:
Column level encryption Enables companies to secure - without
application changes - a specific column in a database table.
Something doesn't add up here.
"Encryption," "secure," and "without application changes" don't seem
to
belong in the same sentence. Anybody know what they're talking about?
James,
The claim of column level encryption stems from the fact that the
database group (and others, I am sure), ported the "Fieldproc"
capability from z to i. What FieldProc gives us is the ability to add
field level Exit programs to a DB2/400 field (field level, not file)
and have the database hand control of data to your program on reads
and writes. So if you are looking to encrypt, say credit card data,
in an existing app (especially one for which you do not have access
to the source code), FieldProc gives you the ability to force all
writes to use your encryption algorithm. Voila, encryption without
program changes. This is a huge development!
But it doesn't stop there, the really, really, really cool part about
Fieldproc is that it also hands control to your exit program on all
reads. This is very cool because you don't want your encryption
program to automatically decrypt every time someone reads (else, what
was the point of encrypting in the first place???), instead your exit
program can use business rules to decide under which users/programs/
circumstances should the data be be decrypted. This is the real
value FieldProc. Automatic encryption is not that hard, but
intelligent, automatic encryption that respects your business
processes is now possible under V7R1, and that is a very big deal.
Now, as for the "without application changes" claim, that _may_ be
true depending on your particular application. If the field you are
encrypting (SS#, CC#, etc.) is used as a key field, then you're
probably going to have to make a few tweaks to your application
because once that field is encrypted it loses its value as a key
field. (Ex: When Social Security number '123456789' turns into 'E9u&*1-
A]', your going to have a hard time with your sorts). You will have to
assess your application for the presence of encrypted key fields.
Also, you'll want to chose the right encryption method and mode for
your application. In almost all cases the right algorithm will be
AES-256 byte, and in most cases for DB2/400 on the i you'll want to
use Block mode. Block mode will allow you to encrypt a 9 character
SS# and place it back into the 9 character field from whence it came
without any loss of data.
You should also note that you still have to supply your own encryption
algorithm - V7R1 does not change this part of the equation. You can
either purchase the only N.I.S.T. certified database encryption tool
certified for IBM i from Patrick Townsend Security Solutions (OK, that
was a shameless commercial plug :-), or you can roll your own
encryption solution using the IBM API's.
Finally, when you do encryption, don't forget that you have to have an
Encryption Key Management solution in place. Many folks get mostly
done with their encryption project and then have an "Uh-Oh!" moment
when they realize they need to manage all those encryption keys.
There are commercial options available for Key Management as well so
you don't have to try to keep all this together in your head.
End result? This is a very cool offering from IBM that will make it
easier to encrypt sensitive data even if you don't have the source for
your package. Proceed with care, but the future looks very bright.
jte
P.S. V7R1 was our idea! ;-)
--
John Earl
President and CEO
Patrick Townsend Security Solutions
"The Encryption Company"
Olympia, WA | www.patownsend.com
Office: 360-357-8971 Ext 118
midrange.com
