Re: PGP scripting...

From: Steffen Dettmer (steffenat_private)
Date: Wed Jan 08 2003 - 15:25:58 PST

  • Next message: Jason Lunz: "Re: Preventing ptrace()"

    * Andrew MacKenzie wrote on Wed, Jan 08, 2003 at 14:15 -0500:
    > > - 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).
    
    Well, but maybe you can store it encrypted in the DBMS with an
    own public key - and only the order processor has the secret key.
    Things as name you need in the front end could be encrypted by
    some different key set (and the front end controlling thing has
    this secret key). I assume the processing is done on a different,
    secured system also. This was already meantioned in the thread as
    "moving the problem to a different server", but in fact, often
    you cannot do more. 
    
    I assume you have a secured channel to the processing back end
    (for instance, the credit card aquirers). So maybe you need
    some "re-encrypting". Here you could build some box (a secured PC
    or some dedicated crypto hardware such as security modules) that
    just offers the complete re-encryption as functionality. So you
    could decrypt your date securely (since the crypto box knows the
    key), but without any chance to get out clear text, since it's
    re-encrypted for the aquirer immediatly. This data is again
    unreadble and secured - now the problem is moved again to a
    different server - to some aquirer authorization or processing
    system, which is out of your scope and responsibility - you're
    done.
    
    This has the big disadvantage that you cannot track what happens.
    When fraud or such occures, you don't even know what kind of
    transaction data was used. But you can work-around this a little
    maybe, when you add some secured transation logging which can be
    decrypted interactively (when you make it to have a small number
    of such cases, this could be possible, when someone needs to
    enter some passphrase daily for decrypting (or again,
    re-encrypting) and transfer the transaction log to some people
    (such people ususally have to be trusted anyway).
    
    If you need the possibility for each "not-so-secured" system to
    decrypt the data automatically, I don't think it helps much to
    store the data encrypted (well, except for billig, encrypted
    storage is of course an expensive software feature :)). But it
    would be really strange if this is true - maybe a design problem
    of the business process :)
    
    oki,
    
    Steffen
    
    -- 
    Dieses Schreiben wurde maschinell erstellt,
    es trägt daher weder Unterschrift noch Siegel.
    



    This archive was generated by hypermail 2b30 : Thu Jan 09 2003 - 04:33:50 PST