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