Re: SecurID and garage door openers
| | Speaking of two-factor authentication, can anyone explain how servers | | validate the code from a SecurID token in the presence of clockskew? | | Does it look backwards and forwards in time a few minutes? | | Yes, it rolls forward and back 3-5 cycles. The server maintains a | list of what time it thinks the token thinks it is. So its not | testing what time it is, its testing what time the token thinks it is. Plus, I believe it maintains and updates an estimate of the skew between its clock and the token's. So the "what time I think the token thinks it is" value is pretty accurate. Note that a value read off the token is good for a minute, so your synchronization doesn't have to be that good to begin with. (I suppose you could scan over a larger number of cycles to find the entered value and then use the cycle distance *just to update the skew/token time calculation*, refusing the value. A legitimate user will just try again with the next generated number and succeed; but a guesser won't be helped by the broader scan range. At most, he can screw up the skew/token time estimate somewhat, but that will "heal" when the legimate user next logs in.) I think there's some special-case synchronization the first time the token is used, the details of which I can't recall. (It may be just that the server is very liberal about the allowed skew if it knows it hasn't talked to a token in a long time - which is how it would presumably look on the first attempt. I suppose if you're really worried that this would allow an attacker to get in before the legitimate user, you can make it a policy to log in with the token a couple of times after setting up the account but before handing out the token. Then again, the software could well have a mechanism to do exactly this synchronization step, so that you don't actually have to log in or even enable the account until synchronization is complete.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SecurID and garage door openers
- Original Message -
From: "Travis H." <[EMAIL PROTECTED]>
Subject: SecurID and garage door openers
Similarly, how do those garage door openers with "rolling codes" work,
given that the user may have pressed the button many times
accidentally while out of range of the receiver?
My understanding is that since it is a purely monotonic counter it is plenty
possible to do one of two things:
send {counter, data} instead of {data}, receiver stores last counter to
avoid replays
have the receiver just keep counting forward for a while (not a good idea
Is there any interest in reviewing the security of consumer-level
devices?
I'd be willing to take a look at the protocol, but dissection is not my
specialty.
PS: How many cypherpunks does it take to open a garage door?
http://www.cap-lore.com/Garage/
Currently, not very many, with proper designs openly published, not very
many because not very many companies will use it. However, it could be a
useful way for some cipherpunks to make some extra money. Anyone else up for
it? and how about the car alarm?
Joe
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SecurID and garage door openers
On 18 okt, Greg Rose wrote: >>Similarly, how do those garage door openers with "rolling codes" work, >>given that the user may have pressed the button many times >>accidentally while out of range of the receiver? > > Ahh, one of the dirty little secrets. If the base receives two > sequential outputs from a registered token, even if they are a long > way away from the currently expected output, it will resynchronize to > that. I guess this varies. At least my former car had a warning in the manual, regarding the remote, that it could get out of sync if I pressed the buttons too many time while out of range. So I guess at least some manufacturers did something a little bit better. /MaF - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SecurID and garage door openers
At 03:25 2005-10-18 -0500, Travis H. wrote: Speaking of two-factor authentication, can anyone explain how servers validate the code from a SecurID token in the presence of clockskew? Does it look backwards and forwards in time a few minutes? Yes, at registration time the server checks that the clock skew is reasonable (IIRC, within 100 minutes either way). From then on it knows and remembers the approximate clock skew. Similarly, how do those garage door openers with "rolling codes" work, given that the user may have pressed the button many times accidentally while out of range of the receiver? Ahh, one of the dirty little secrets. If the base receives two sequential outputs from a registered token, even if they are a long way away from the currently expected output, it will resynchronize to that. The replay protection just means that the attacker needs to record two sequential accesses, not a single one. When all is working as expected, this means the attacker must target you and hang around for a day, or do a lunchtime attack on your zapper. Greg. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SecurID and garage door openers
On Tue, Oct 18, 2005 at 03:25:40AM -0500, Travis H. wrote: | Speaking of two-factor authentication, can anyone explain how servers | validate the code from a SecurID token in the presence of clockskew? | Does it look backwards and forwards in time a few minutes? Yes, it rolls forward and back 3-5 cycles. The server maintains a list of what time it thinks the token thinks it is. So its not testing what time it is, its testing what time the token thinks it is. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
