Yubico Forum

I got a Yubikey last year at RSA Europe (thanks Stina), obtained the AES key and
have done some Python programming with it.

But I'm stuck with this:

Assume a website which uses the Yubikey OTP to 1) authenticate users and
2) validate transactions. Classic example of such a site is an online
banking site. User generates an OTP to logon, and then has to generate
an OTP for each financial transaction.
A web browser trojan could insert it's own transaction like this:
- I generate an OTP (OTP1) with my Yubikey
- The trojan intercepts and stores OTP1 together with a timestamp,
doesn't send OTP1 to the website, but makes the browser display a fake
error message (404, server load to high, Yubikey error, ...) prompting
me to generate a second OTP
- I'm fooled by the fake error, and generate a second OTP (OTP2) with my
Yubikey
- The trojan intercepts and stores OTP2 together with a timestamp, and
sends OTP1 to the web site
- Web site grants me access.
- After an amount of time equal to the delta between the 2 stored
timestamps, the trojan starts a transaction (invisible to the user) and
uses OTP2 to validate the transaction.
- When the user starts his own transactions, the trojan pases the OTPs
on to the website, but delays them with the same timestamp delta to
avoid post-exploitation detection.

I cannot device an algorithm to detect this fraud on the website, if the
Yubikey is the only authentication and validation mechanism used.

Any ideas?

Asking the user to reinsert his Yubikey to force each OTP to have a session
counter equal to 0 (and thus prevent above scenario) is not a good idea,
because then the user is accustomed to have to reinsert his Yubikey.
The trojan could just do the same and ask the user to reinsert his Yubikey.

Didier
-----
Didier Stevens
http://blog.DidierStevens.com

Sure, but once you have a trojan on your system pretty much all bets are off anyway. It could just as easily intercept my communication with my online bank, changing the amount and receiver of any transaction I perform without me knowing it (except for my original transaction not being made, but the damage is already done and the trojan could make it look like it went through), regardless of authentication device. At least, I am unaware of anything that is able to fully protect you when using a compromised system.

Still, it is an interesting problem. One way to solve it would have a more advanced trusted device which itself is capable of displaying the transaction to sign, so that the user cannot be tricked into signing something else than what was intended.

.

I guess you can't do it unless you add some crude mechanism to verify if he transaction is executed in real time. What about something like this:

1 - upon login the server shows a graphic that depicts 4 random digits.
2 - the user types over these digits and presses the key.
3 - the server verifies the correctness of the number (it is only valid for let's say 15 seconds)
4 - if correct, the server registers the wall clock time and Yubikey timestamp.
5 - if not correct, go to step 1 again.

6 - upon verification of he transaction the server shows a graphic that depicts 4 random digits
7 - the user types over these digits and presses the key.
8 - the server verifies if this is still the same session (key has not been unplugged). If not: go to step B
9 - the server verifies the correctness of the number (it is only valid for let's say 15 seconds)
A - if correct, the server uses the wall clock time to determine if the timestamp on the key is within acceptable range
B - if not correct, refuse transaction and go to step 1.

C - allow transaktion
D - goto step 6

Yes, this exists and is one way to deal with trojans.

Example: there are security tokens that use a different protocol to logon and to validate a transaction.
logon: user types his PIN, security token generates digits, user types digits
transaction signing: user types his PIN, user types in transaction challenge (a unique number for the transaction generated by the bank server), security token generates digits, user types digits

So already in this simple case, a trojan can't use 2 logon digits to logon & sign a transaction

Other banks go further and include data of the transaction in the challenge, for example the number the user has to type in the security token includes the amount of the transaction and/or the account number.

This makes sense. If I understand you correctly:
You associate the OTP the server gets with an action that only the user can perform, and not the trojan? And this assures you that the OTP comes in real time from the Yubikey?
In your example, this action is reading digits from a graphic and typing these digits? Did I understand that correctly?
So the key is to find an operation that a user can perform, and not a program. A CAPTCHA?

Yes. The 'in real time' is a bit fuzzy, as the Internet was not really designed for realtime actions. I'm not sure (haven't looked at it yet) how precise the 8Hz clock in the Yubikey actually is, it will probably drift, so your algorithm needs to take care of that too. But it should be do-able.



Yes, that's what I meant.

Mine is 30% !

Well, as long as it is constant, you could calculate the drift and take that into account. Worst case the timer depends on the voltage provided by the system it happens to be plugged in to.. the key probably does not contain a crystal or something like that. Might even be that the clock is implemented in software, so pressing the button will actually stall updating the timer.. Perhaps some of our Yubico friends here can provide additional information?