RE: PGP scripting...

• Previous message: Crispin Cowan: "Re: PGP scripting..."
• Maybe in reply to: Andrew MacKenzie: "PGP scripting..."
• Next in thread: Michael McKay: "RE: PGP scripting..."
• Maybe reply: Mark Reardon: "Re: RE: PGP scripting..."
• Reply: Michael McKay: "RE: PGP scripting..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Dawes, Rogan (ZA - Johannesburg)" <rdawes@deloitte.co.za>
To: "'Ogle Ron (Rennes)'" <ron.ogle@thomson.net>, 'Andrew MacKenzie' <andy@edespot.com>, secprog@securityfocus.com
Date: Thu, 9 Jan 2003 09:31:36 +0200 

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?

Rogan

P.S. As I mentioned the cookie encryption scheme, I realised that I hae lost
my link to this scheme. Does anyone know where it is described?

Effectively, the user's credit card number is encrypted using a server
public key. The private key is stored on a different server, and can be used
to recover the original info in the event of payment failure. Other
manipulation is done (XOR, etc) and half of the result is stored in the
user's browser, as a persistent cookie, and the other half is stored on the
server. Each half is useless on its own, but in combination reveal the
credit card number.
 
-----Original Message-----
From: Ogle Ron (Rennes) [mailto:ron.ogle@thomson.net]
Sent: 08 January 2003 05:56 PM
To: 'Andrew MacKenzie'; secprog@securityfocus.com
Subject: RE: PGP scripting...

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:andy@edespot.com]
> Sent: Tuesday, January 07, 2003 06:02 PM
> To: secprog@securityfocus.com
> 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
>

• Next message: Kenneth Buchanan: "RE: PGP scripting..."
• Previous message: Crispin Cowan: "Re: PGP scripting..."
• Maybe in reply to: Andrew MacKenzie: "PGP scripting..."
• Next in thread: Michael McKay: "RE: PGP scripting..."
• Maybe reply: Mark Reardon: "Re: RE: PGP scripting..."
• Reply: Michael McKay: "RE: PGP scripting..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]