Re: Encrypting data Was: Securing tape backup drive

Actually, after reading Rob's post I did a search of ibm.com on SQL
encryption and found a PDF specific to System i and encryption. It talks
about using KEK to store keys in the LIC so they don't land on any
backup tapes and can be used with SQL.

It also indirectly mentions another intermediate solution. Store the
passwords in a file in a special library. The programs retrieve the
password from the file and use it with either the APIs or SQL. The
special library NEVER gets backed up WITH the data that is encrypted.
Run a special tape AND store it somewhere other than with the data
tapes. You won't be changing this library/file often so... as needed
backup and put in the company's Valuable Papers fireproof location
instead of your routine off site data storage.

Roger

On 3/20/2007 9:04 AM, Bruce Vining wrote:

This wouldn't work with the SQL approach, but if you're willing to look at 
using the cryptographic services APIs the Key Management APIs (introduced 
with V5R4) allow you to have keys that are not visible to (or even in) 
your application programs.  For more information see the Key Management, 
Cryptographic Context, and Encryption/Decryption subcategories under the 
Cryptographic APIs cateogory of system APIs.  When reviewing these APIs 
keep an eye on how key contexts can be created and used.

Bruce Vining




rob@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/20/2007 08:33 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


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

Subject
Re: Encrypting data Was: Securing tape backup drive






Good question.  And the links I sent earlier touch on that, a little.

Keep in mind, that you do meet the requirements that the data is 
encrypted.  And it is encrypted using a "standard", which carries more 
weight than some homegrown that some of us have tried.  Anyone browsing 
the tape for patterns like '123-45-6789' or 9 digit numbers (packed or 
zoned) sure wouldn't find it.

1 - Never put the source on the production machine.  We don't.
2 - Save the programs on a different tape than the data.
3 - Consider not leaving any debug information on stuff with the password 
imbedded.
4 - Consider leaving the password constructed in a service program that 
people must call to use.  Then again, you could have someone, like my 
coworker, who executes it, get's the parameter back, and publishes it to 
the whole department.

For read only you could do something like:
  

create view rob/vickerduh as 
    

   (Select mykey, decrypt_char(myssn,'Ben123') as DisplaySSN 
    from rob/vicker) 
  View VICKERDUH created in ROB. 
  

select * from rob/vickerduh 
    

....+....1....+....2....+...
        MYKEY   DISPLAYSSN 
            1   289-46-8832 
********  End of data  *****



Rob Berendt