468,119 Members | 1,904 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,119 developers. It's quick & easy.

Encryption and key management best practices


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

--

Nov 13 '07 #1
2 6201
On Nov 13, 2:37 pm, olafinsbraa...@hotmail.com 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

Nov 14 '07 #2
On Nov 14, 11:30 am, Bernard Dhooghe <dhoog...@yahoo.comwrote:
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 :)

--

Nov 15 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

34 posts views Thread by Blake T. Garretson | last post: by
6 posts views Thread by Codemonkey | last post: by
136 posts views Thread by Matt Kruse | last post: by
44 posts views Thread by craig | last post: by
4 posts views Thread by PJones | last post: by
7 posts views Thread by j1mb0jay | last post: by
11 posts views Thread by Jens | last post: by
15 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.