[17821] in cryptography@c2.net mail archive
Re: the limits of crypto and authentication
daemon@ATHENA.MIT.EDU (Ben Laurie)
Tue Jul 12 13:17:40 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 12 Jul 2005 10:50:05 +0100
From: Ben Laurie <ben@algroup.co.uk>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
"Steven M. Bellovin" <smb@cs.columbia.edu>, cryptography@metzdowd.com
In-Reply-To: <87d5pqacgs.fsf@snark.piermont.com>
Perry E. Metzger wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
>
>>* Perry E. Metzger:
>>
>>>Nick Owen <nowen@wikidsystems.com> writes:
>>>
>>>>It would seem simple to thwart such a trojan with strong authentication
>>>>simply by requiring a second one-time passcode to validate the
>>>>transaction itself in addition to the session.
>>>
>>>Far better would be to have a token with a display attached to the
>>>PC. The token will display a requested transaction to the user and
>>>only sign it if the user agrees. Because the token is a trusted piece
>>>of hardware that the user cannot install software on, it provides a
>>>trusted communications path to the user that the PC itself cannot.
>>
>>On the surface, we already have such technology in Germany (it's
>>optional for bank customers), but there's a drawback: The external
>>device doesn't know anything about the structure of banking
>>transactions, so it relies on the (potentially compromised) host
>>system to send the correct message to display before generating the
>>signature. Ouch.
>
>
> That could be fixed. I think the right design for such a device has it
> only respond to signed and encrypted requests from the issuing bank
> directed at the specific device, and only make signed and encrypted
> replies directed only at the specific issuing bank. If anything in
> between can tamper with the communications channel you don't have the
> properties you want out of this.
Not entirely clear what you mean by the "issuing bank" here, but I'm
hoping you don't mean that the bank issues the device - that would be
very tedious.
I also find "directed only at the specific issuing bank" unclear - I
presume you mean encrypted s.t. only the issuing bank can read it? In
which case, you're adding complexity - a relying party has to let the
issuing bank come between it and you to get anywhere. This would
preclude, for example, offline transactions.
As I've said before, I totally agree that the only way to go is to have
signatures made on such a device, but I do think its very important to
design the thing right - and the above isn't sounding right to me.
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
