In every system, some parts have to be trusted, but they should also be verified through auditing. Even though this discussion was only talking about encrypting/decrypting data in/out of a database; we still required the system to be locked down and all OS and DB transactions to be audited. If you are really concerned about making sure that only authorized applications are able to communicate with the designated hardware token, then you have the choice of using a B2 or even A1 class OS instead of a C2 rated OS that most people would use. Of course, this will cost you big $$$, but you are assured that no attacker will be able to send data to be decrypted. The point of this exercise is that given that you've made the necessary changes to keep the bad guys out; how do you keep the good guys (authorized users) honest? IMHO, the system that I described accomplishes this goal. Ron Ogle Rennes, France > -----Original Message----- > From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawesat_private] > Sent: Thursday, January 09, 2003 08:32 AM > To: Ogle Ron (Rennes); 'Andrew MacKenzie'; secprogat_private > Subject: RE: PGP scripting... > > > One of my biggest issues with storing data encrypted, is how > to prevent an > attacker from decrypting it using the same mechanism as the legitimate > application. > > I've seen suggestion for a Decryption host, connected via UUCP/serial, > hardware crypto, etc, but what I haven't seen addressed is > preventing the > attacker from sending cipher text data via UUCP to be > decrypted, or calling > the decryption routines for the hardware crypto. > > It seems to me that the only real solution here is not being > able to decrypt > on that host at all. (Which is not really a solution in many cases!). > > E.g. sending out encrypted emails, containing a password, or > other sensitive > info. Store the encrypted email, so that it can be sent to > the user again if > required. You don't need to be able to decrypt that message > on the server. > > E.g. Storing an encrypted version of the user's credit card > number, so that > when the user supplies their cookie, the specific value can > be retrieved > (not exactly, but I saw a BRILLIANT implementation of this a > while ago). If > user's don't keep cookies, they probably don't want you to > store their > credit card numbers either. > > Comments?
This archive was generated by hypermail 2b30 : Sat Jan 11 2003 - 12:35:08 PST