RE: PGP scripting...

From: Michael McKay (mmckayat_private)
Date: Sat Jan 11 2003 - 22:34:45 PST

  • Next message: Craig Davison: "Re: PGP scripting..."

    Rogan wrote: 
    >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!). 
    
    and someone else (lost the thread) wrote:
    > > Using specialised tamper-resistant hardware minimises risk, but that 
    > > pesky passphrase is still stored programmatically - it's just inside 
    > > a black box with semi-proprietary I/O, hardware and algorithms.
    
    Let me provide some clarification as to the way TRSM (tamper resistant 
    security modules) handle this type of problem.  First I should mention 
    the most common TRSM standard (PKCS #11) will not provide you with this 
    type of functionality (works great as a client standard, but has serious
    problems when used on a server).
    
    We have already decided that the TRSM (or isolated computer, same concept)
    should never perform a straight decryption.  More accurately, it should 
    not provide access to any "elemental" encryption operations.  Naturally 
    you may ask (Rogan did), what about decryption?
    
    The solution to this problem is "translation".  The TRSM never performs a raw
    decryption, instead it translates it to some other useful value.  Take an
    example of a merchant site accepting credit card numbers.  A system could be 
    designed to recognize SSL credit card numbers coming in, and not just perform
    a raw decryption of the credit card number.  
    
    The TRSM would instead decrypt the credit card number inside it's secure 
    boundary, and than encrypt the credit card number with another key.  This
    key is associated** with the credit card processing gateway.  The TRSM 
    returns the encrypted value, which can be stored and/or sent to the 
    processing gateway (see the VISA CISP requirements for a better idea of 
    this type of system).  
    
    The TRSM knows the gateway key, but has no function to decrypt using it.   
    Even if an insider who knows exactly how things were set-up breaks-in and 
    gains complete control over the system, they still won't be able decrypt 
    the credit cards protected by the processing gateway encryption key.
    
    Now obviously this is not perfect security, since an attacker could still
    take over the web server, and get credit cards in the clear or use less 
    secure alternate SSL routine.  But even in that case, past transactions 
    would still be protected -- a concept known as "forward security".
    
    The concept of "translation" is very powerful, but there are two important
    caveats.  The first is that translation requires data oriented encryption
    protocols.  The "hows and whys" of the translation routine are very dependant
    upon the data and the specific use of that data.  This is classical networking
    (like IPSEC or SSL) which is pretty much data independent.  
    
    The second caveat is that obviously you need something to translate to.  If your 
    system allows vital data to be translated to weak systems, your entire 
    system is only as strong as that weak system.  This is why financial systems 
    tend to require a TRSM at every node that deals with clear data.  They even
    design protocols so that compromising a relatively weak link (like an ATM or
    POS terminal) will have a minimal impact to the entire system - ANSI X9-24 and
    the VISA DUKPT algorithms are classic examples.
    
    Michael McKay   
    iS3 Software Director (and TRSM architect)
    mmckayat_private
    
    ** Loose language that works with both symmetric and asymmetric key systems.
    



    This archive was generated by hypermail 2b30 : Sun Jan 12 2003 - 19:33:47 PST