Re: PGP scripting...

From: Steffen Dettmer (steffen@dett.de)
Date: 01/09/03

  • Next message: Jason Lunz: "Re: Preventing ptrace()" 
    Date: Thu, 9 Jan 2003 00:25:58 +0100
From: Steffen Dettmer <steffen@dett.de>
To: secprog@securityfocus.com

    * 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.

    Relevant Pages

    • RE: PGP scripting...
      ... Let me provide some clarification as to the way TRSM (tamper resistant ... The solution to this problem is "translation". ... example of a merchant site accepting credit card numbers. ... The TRSM would instead decrypt the credit card number inside it's secure ...
      (SecProg)
    • RE: PGP scripting...
      ... Let me provide some clarification as to the way TRSM (tamper resistant ... The solution to this problem is "translation". ... example of a merchant site accepting credit card numbers. ... The TRSM would instead decrypt the credit card number inside it's secure ...
      (SecProg)
    • Credit Card Details
      ... gaining access to the server will therefore gain access to the credit card ... on the server in an encrypted format. ... will legitimately need to decrypt the data in order to use this information. ... It would be equivalent to buying a secure safe and ...
      (microsoft.public.security)
    • [PHP] Re: keeping credit card info in session
      ... You have to store the keys somewhere to decrypt the data to use it. ... As we have seen with blu-ray and HD DVD movies, the keys are the weak point that are easily compromised. ... Once you have the decryption key, the strength of the encryption means nothing. ... Anyways, if you're storing the credit card in the database, then why are you ...
      (php.general)