[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