Friday, March 18, 2005, 11:02 PM

Secure Transaction Tokens

Bruce Schneier's post on The Failure of Two-Factor Authentication prompted me to write down a few of the ideas that I had been toying with.

Schneier asserts that two-factor authentication won't make a difference to reducing cyber-attacks on remote authentication over the Internet -- because both the man-in-the-middle attack and the Trojan attack are possible attack modes. I agree that these attack modes are possible given certain assumptions about the types of the second authentication factor. However, I believe that it is possible to construct a token that can ensure secure transactions across the Internet.

Moreover, Schneier did not have to go into the study of attack modes to show that secure authentications (or any technical guarantees of transactional integrity) are not possible if you are running on compromised clients. There is a more fundamental reason for this weakness in remote authentication: So long as the user is approving transactions via a compromisable platform, transactions cannot be guaranteed secured. This is almost tautological. Man-in-the-middle attacks and Trojan attacks are just two classes of possible attacks. An authentication token that can be reliably used across the Internet has to be able to secure transactions in context of both compromised networks and compromised client platforms.

Assuming the server is a secured platform, there are two ways I can think of for securing transactions (1) secure the client platform, or, (2) off-load the security assurance to a Secure Transaction Token (STT).

In five to ten years, we might finally get a generic secured client platform(Windows 2010, anyone?) ... maybe. The problem is that the more a system can do, the less likely one is able to secure it.

My bias is to solving the problem with a Secure Transaction Token -- the minimal token system that's required to work across the Internet.

What does an STT need to do? I believe there are at least three requirements:

(a) Physicalize secrets. The purpose of a physical second factor authentication token is to make identity theft harder; to require the theft of a "what you have". A strongly physicalized token is a prerequisite to making cyber-attacks-only identity theft impossible.

(b) Know-your-server. Man-in-the-middle attacks are possible because the regular token will talk with any server that the client or network tells it to. An STT will only talk to trusted servers that it has been told about.

(c) Ask-the-user. If both the network and the client machine are compromisable, we cannot depend on the client to mediate conversations between the server and the user. Therefore, the STT must be able to act like a "terminal" for the server to securely communicate with the user. A compromised agent (Trojan) cannot tell the STT to do something bad without the user being aware because the server will always check with the user via the STT.

When we have such deployed such devices, we can support secured transactions across the Internet. The principle here is to build a minimal security component (the STT) to support transactions that cannot be compromised by technical attacks in the client or in the network.

Note that there are no systems that I know of that implement STTs ... but then again, I don't work for the government.

1 Comment(s):

Blogger harryh said...

Hello PT,

I'm having some trouble subscribing to your blog via Bloglines.

Bloglines can discover the available RSS feeds in many blogs. On yours it shows the only available feed to be http://blog.blogspot.com [http://blog.blogspot.com/atom.xml] which looks a lot like a default setting. As it happens, it's the Atom feed of "MyTechGirl's working log - official blog of MyTechGirl.com - POV + links + tech reviews = your peek into the life of a girly geek!" - definitely not "Random Thoughts on Digital Identity"!

It may be that you have to change a default blog feed to point to your blog.

Harry

9:11 PM  

Post a Comment

<< Home