Re: PGP scripting...

From: Steffen Dettmer (steffenat_private)
Date: Wed Jan 08 2003 - 00:26:07 PST

  • Next message: Ogle Ron (Rennes): "RE: PGP scripting..."

    * 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