We have a very similar solution, but we use X.509v3 instead of PGP. There have been other emails describing specific libraries to use. I would like to touch on some architecture points which will be the same for PGP or X.509v3. 1. We thought about 2 different ways to implement the encryption. One way was to create a symmetric key that would be used to encrypt/decrypt all data in the DB. We would then use the public/private keys to encrypt/decrypt the symmetric key when needed. The other way was to create PKCS7 packages for each data element. PKCS7 means that there is a symmetric key dynamically generated for each data element and then the public key is used to encrypt the symmetric key. The encrypted data and encrypted key is then packaged together. We chose the second option because of three key reasons. First, we didn't have to keep track of a single symmetric key any more. This is very good because if you wanted to change the symmetric key with option 1, you would need to decrypt every piece of data with the old key and then encrypt it with the new key each time you changed the key. Second, we want to be able to roll-over our public/private keys yearly. The system that we use keeps key history, so we wouldn't have any problems as time marched on for the system. Third, the backups of the system was completely free of any keying material. The downsides of the second option are that it takes up more space in the DB and that it takes more processing time. The space for us wasn't a problem and probably not for you either unless you are talking about terabytes of data. The processing time is very minimal because of the dedicated hardware for storing/processing the encryption material. 2. Before we encrypt any data, we take the SHA-1 hash of the data, encrypt it (signature), and store it in the row. This is just a secondary check to make sure that the data hasn't been altered from the data submitted when the data gets transmitted to other systems. 3. Use a FIPS 140-1/2 level 3 compliant hardware for storing keys and processing all encryption. Level 3 is required because you want to separate hardware token actuation from operations. This means that there are external mechanisms to initialize, start, and stop token operations. These external mechanisms can then be given to trusted non-administrators. So to turn on your token that stores your public/private keys, you need other people to enable the token for processing (separation of duties). This should prevent someone from stealing your hardware token and being able to activate it later. 4. All encryption needs to be done on your hardware token. Otherwise, there may be ways to plant software on the host that could scour live memory/disk to search for keying material. 5. You didn't mention it as a requirement, but when we send the data to other machines, we also make sure that the data is protected. To protect this arrangement, we decrypt the data on the DB machine and then use TLS with client and server side authentication to protect the data in transit. We use our X.509v3 certs to do the client and server authentication. When we move the data, we also attach the signature for the row to show that the data hasn't been altered. Hope this helps. Ron Ogle Rennes, France > -----Original Message----- > From: Andrew MacKenzie [mailto:andyat_private] > Sent: Tuesday, January 07, 2003 06:02 PM > To: secprogat_private > Subject: PGP scripting... > > > I apologize if this is a bit off-topic, but I'd like to ask a question > about practical use of PGP. I am a software developer, and > have a client > who is making a great attempt at being security conscious (to > the extent of > hiring a security consultant). > > 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). > > I can understand the desire to archive these files in > encrypted forms, and > to encrypt these files while transporting out of the system. > But I think > this idea goes a bit too far as to be more counter-productive > than useful. > After many days of fighting with 'pgp -f' and modifying > processes to use > stdin/stdout, I've gotten much of this working. > > I would have prefered to use a PGP library (Java code), but > was unable to > find any within the timeframe. > > My question therefore is: is all this worth the trouble? In > order to use > PGP with scripts (or even Java code), the scripts need access > to both the > private key and pass phrase (which are stored locally in > files). If the > system were compromised would any of this help? Is there a > better way I > could do this than what I am already doing? This is somewhat > academic for > me at this point, as my client is inflexible on this point > and code has > been written, but I'd be interested in hearing your opinions on this > subject. > > Thanks. > > -- > // Andrew MacKenzie | http://www.edespot.com > // "Those are my principles. If you don't like them I have others." > // -- Groucho Marx >
This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 10:44:31 PST