Re: PGP scripting...

From: Andrew MacKenzie (amackenz@edespot.com)
Date: 01/08/03

  • Next message: Andrew MacKenzie: "Re: PGP scripting..." 
    Date: Wed, 8 Jan 2003 14:15:40 -0500
From: Andrew MacKenzie <amackenz@edespot.com>
To: Steffen Dettmer <steffen@dett.de>

    > > 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?
    PGP was choosen as it will be used by external as well as internal
    machines. We will receive a PGP encrypted file, and proceed to process the
    data within. HOWEVER, we will also use the same public key to encrypt
    files that are to be archived on the same system (encrypting to ourselves).
    This is being done mearly to be consistant with the rest of our processes.
    If it would be better to use a different encryption I'm open to
    suggestions.

    > 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).
    This is my dilemma.

    > 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)
    Unfortunately all of the data concerned falls into this group. We have
    credit card info (which you mention *may* be treated like passwords), but
    we need to validate the account numbers and perform other processing on
    them (send to a merchant processor for billing).

    *snip*

    > 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.
    Unfortunatly we don't have an option for any of this to be interactive.
    Just batch. 

    -- 
// Andrew MacKenzie  |  http://www.edespot.com
// An intellectual snob is someone who can listen to the William Tell
// Overture and not think of The Lone Ranger.

    • application/pgp-signature attachment: stored