Encryption and key management best practices

[olafinsbraaten]

I am using column-level encryption (ENCRYPT_CHAR, DECRYPT_CHAR) to
protect selected columns in DB2 LUW v.9.1 and v.9.5 on Linux. The
ultimate goal is to support the requirements put forward in Payment
Card Industry Data Security Standard (PCI DSS) which states: "Protect
stored cardholder data anywhere it is stored".

The encryption functions above requires a password to be set for each
db2 session (SET ENCRYPTION PASSWORD = '836b56319d9'). This implies
that the password must be provided by the client program accessing
db2.

I seek advice as how to store, use and manage such passwords ("keys")
securely and according to best practices.

https://www.pcisecuritystandards.org/
http://en.wikipedia.org/wiki/PCI_DSS

--

[Bernard Dhooghe]

On Nov 13, 2:37 pm, [e-mail] wrote:

I am using column-level encryption (ENCRYPT_CHAR, DECRYPT_CHAR) to
protect selected columns in DB2 LUW v.9.1 and v.9.5 on Linux. The
ultimate goal is to support the requirements put forward in Payment
Card Industry Data Security Standard (PCI DSS) which states: "Protect
stored cardholder data anywhere it is stored".

The encryption functions above requires a password to be set for each
db2 session (SET ENCRYPTION PASSWORD = '836b56319d9'). This implies
that the password must be provided by the client program accessing
db2.

I seek advice as how to store, use and manage such passwords ("keys")
securely and according to best practices.

https://www.pcisecuritystandards.org...g/wiki/PCI_DSS

--

Is it a good idea to push operational constraints in a database
engine?

I understand that all clients can encrypt/decrypt without additional
tool, obfuscating is the challenge then (the question posted here).
So additional programming is needed (again, as with a home-made
encrypt/decrypt capability).

Another drawback of using the available encrypt/decrypt routine is
that the encrypted info is in the DB2 log and the encrypt/decrypt
algorithm is, as far as I know, not given by IBM. How will tools that
process logs be able to tackle this?

In conclusion, maybe some design "team" must decide where to go with
first.

Bernard Dhooghe

[olafinsbraaten]

On Nov 14, 11:30 am, Bernard Dhooghe <[e-mail]:

Is it a good idea to push operational constraints in a database
engine?

Why should it not be? To me the database is just another tool, and if
can serve particular purpose, there's little to be gained in
reinventing the wheel by rolling your own.

I understand that all clients can encrypt/decrypt without additional
tool, obfuscating is the challenge then (the question posted here).
So additional programming is needed (again, as with a home-made
encrypt/decrypt capability).

The original question was about key management, and I believe that
challenge essentially remains the same whether on chooses to use
database encryption (DB2 encrypt/decrypt) or client encryption (C,
Perl, Python, etc.).

Another drawback of using the available encrypt/decrypt routine is
that the encrypted info is in the DB2 log and the encrypt/decrypt
algorithm is, as far as I know, not given by IBM. How will tools that
process logs be able to tackle this?

How would log processing of encrypted data differ from processing any
other kind of binary data?

http://tinyurl.com/2k2hvh

"Creating indexes on encrypted data is a good idea in some cases.
Exact matches and joins of encrypted data will use the indexes you
create. Since encrypted data is essentially binary data, range
checking of encrypted data would require table scans."

In conclusion, maybe some design "team" must decide where to go with
first.

Hey, that's me :)

--