[Cryptography] Clever physical 2nd-factor authentication

Joseph Ashwood ashwood at msn.com
Fri Apr 4 05:55:49 EDT 2014


-----Original Message----- 
From: Jerry Leichter
Subject: Re: [Cryptography] Clever physical 2nd-factor authentication

On Apr 2, 2014, at 7:37 PM, Joseph Ashwood <ashwood at msn.com> wrote:
[an attack]

> They send a bunch of random segments which produce nothing readable, then 
> the actual digit, then more random segments, then another digit, etc. 
> Listening in, you have no way to know which of the data sent is deliberate 
> noise, and which will produce a segment.  (That's not quite true:  The 
> random noise cannot contain anything that encodes a digit, so it differs 
> statistically from the actual digits.  This would actually provide an 
> attack, though it would take many more samples than you count.)

Actually there is a vastly more useful oracle that I used, the user. "At 
each step where a number was typed in there was at least one segment that 
was printed on the card" gives a time, and so a frame with that number. An 
user oracle failure will result in a failed login, so the login oracle works 
to eliminate any false signals. This kind of attack is also well within 
their proposed security model of assuming the machine is compromised.

> They are also explicit that they only consider a card valid for some fixed 
> number of challenges.  You count about 400 such challenges, using an 
> attack that the random confounders prevent.

I suspect that if I were to spend more than a few moments on it, I could 
have found a significantly more efficient attack. The first step to this 
would be to realize that I made a rather foolish mistake, it uses 7 segment 
(as opposed to my earlier largely mythical 8 segment) display, leading to 47 
locations to be mapped. Giving something like 250 digits (my mistake earlier 
on stating this was logins, each login has multiple digits) to break the 
card. From there the oracle that you pointed out, the one that prevents any 
such mapping on the false images should be good for significant gains. I 
suspect with work the number for a high probability of success could be 
brought under 100 digits, assuming 5 digits per login, that would be every 
20 login attempts. More "secure" logins that use a larger number of digits 
would actually reduce the number of logins needed.

>  I haven't gone through the arithmetic to see what they mechanism could 
> conceivably produce, but even if they get, say, a factor of 10, it would 
> be realistic to replace a card after 2000 uses and have a large safety 
> margin.  (In fact, the white paper indicates that the server itself 
> effectively simulates such an attack, and will cause a new card to be 
> issued when too much information has leaked.  The server, of course, is 
> the perfect attacker in this scenario; a real MITM would likely miss some 
> authentication events.)

I don't see any possible way they could gain anything with such perfect 
oracles presented. The login oracle is perfect in revealing which user 
oracle responses to ignore, and the user oracle timing perfectly reveals the 
important frame.

> An active attack would be much more powerful, but also much harder to 
> carry out.  The user would notice if he validated and repeated failed to 
> get connected to the appropriate site - and until you've actually figured 
> out enough of his card pattern, you can't act as a MITM beyond the faked 
> authentication prompts.

With only 47 total segments, and my attack being rather clumsy, with proper 
analysis that number could probably be cut by two thirds, we're only talking 
about highjacking a tiny portion of each login attempt. Increasing the 
number of digits by 1, for roughly a dozen logins assuming you combined the 
data with the user oracle data from the login. A dozen login attempts before 
card replacement is horribly weak.

> Anyway, it would probably be a good idea to read the white paper for some 
> details of what the system does before announcing attacks against it.

The whitepaper is garbage. It provides exactly 0 in the way of analysis. But 
since you brought it up, how about I analyze that a bit as well.

I won't bother going past the authors.
Matthew Slyman
His listed areas of specialty (according to his wikipedia user profile, 
http://en.wikipedia.org/wiki/User:Matthew_of_cambridge):
*Business automation software
*SQL databases
*Specialised scientific and engineering tools

His own credentials reveal he simply lacks the background necessary.

Gadescu Horatiu Nicolae - currently employed at Passwindow. Immediately 
disqualified, not independent.

Sean O’Neil
Having been a part of the team that developed a single cipher (VEST) 
submitted to eStream he is likely the most qualified. However having found 
some additional writing by him, he is apparently a VLSI implementer. It 
actually took finding his email address ending in vest.fr, finding a paper 
he co-wrote in 2009 "VLSI implementations of the cryptographic hash 
functions MD6 and ïrRUPT" to begin finding information. I reached the 
conclusion about his purpose based on VEST having been horrible in software 
but fast in hardware, apparently badly broken the moment anyone took a look 
(not unusual, a first cipher is typically dreadful), and his only other 
publication being about the hardware implementation of someone else's 
design. So I conclude he is not qualified to analyze such a system either.

Ben van der Merwe
Appears to now be a software development manager at Amazon in South Africa. 
So once again, he simply does not have the credentials.

So there you go, a piece of garbage written by people who have no knowledge 
on the subject, all about a pathetically weak login system. Unless there is 
something substantially new that comes up, I am ending my contribution to 
the thread.
                Joe



More information about the cryptography mailing list