* Andrew MacKenzie wrote on Tue, Jan 07, 2003 at 12:02 -0500: > We (my client) have a system that loads orders into an Oracle DB, and > processes billing (Java/Solaris based). One of the 'decrees' from my > client is that all files that store 'sensitive' data (customer info and the > like) shall be PGP encrypted, and *never* be stored on a HDD in > un-encrypted form (even while processing said file). Even if this thread had great replies already, I'd like to response also. First, why PGP? Why is the customer requiring an implementation for an unclear problem? At first, it's quite clear that any decryption mechanism, that can be used automatically, can be compromised. Even with tamper evident hardware modules: if they work without user interaction, an intruder can use the stored keys for decryption (but not reading the keys, of course). Maybe you look carefully at the system and it's data. Maybe you find 3 types of data: - Data that must be evaluated in clear text (such as name) - Data that must be compared with (passwords) - Data that must stored only The first group cannot be secured very well, as told, but could be hidden by some obscurity like PGP encryption and decryption (I would prefer using some block chipher directly, no need for asymetric cryptography I think). The second group can be implemented with salted one-way hashing as done in the OSes. The third group is implemented by encrypting with some asymetric encryption (or hybrid, such as PGP) to some public key. The private key for that data is not needed on the system and of course not present here. The server itself cannot read back the data - this is more secure. Credit card data may fall into this category. You can change the data but not view it. For order processing, some other system decrypts the orders. If concerned, this process may require manual passphrase entry. Maybe it's sufficient to have this on a different, secured system which is not directly reachble from outside and so on. An interesting approach would be the usage of special hardware crypto modules that implement an encrypt(customer_data), but decrpyt and return only "safe" parts of it w/o interaction, but before returning the complete clear block requires pressing "OK" button or such. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 10:38:27 PST