4 ms·

And that doesn't even touch on replay attacks. If you have a door lock that accepts "lock", "unlock" and "report status", a MITM attacker only needs to capture

And that doesn't even touch on replay attacks. If you have a door lock that accepts "lock", "unlock" and "report status", a MITM attacker only needs to capture the encrypted & signed "unlock" command, then replay it later. Many workarounds were developed to mitigate this such as random values, incrementing values and timestamps, but most were found insecure. Challenge-response systems with a short validity period are one of the better systems in use, but require bi-directional communication which can make some products (ex: garage door openers) more expensive.

davidhyde 6y ago
What about using a time based one time password algorithm instead of a challenge-response mechanism? Most embedded systems have a real time clock. Would it make sense to use this technology for that? https://en.m.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.m.wikipedia.org/wiki/Time-based_One-time_Password...
- cybergibbons 6y ago
  RTCs are actually quite rare, especially in a lot of the lower power RF SoCs. Drift would also be an issue - most move at least 10 minutes a year. That's with good temperatures, not being left in a hot car or at body temp. If you could solve the drift issue then it would be pretty good I think, it's an interesting idea.
  - davidhyde 6y ago
    Maybe you could use the secure connection to resync the time or some other clock with the authenticated server. I guess that’s just another request / response type of arrangement though. And then any breakdown of communication for an extended period of time would brick the whole thing. EDIT: Maybe the time based one time password algorithm can be configured to be made less time granular (say daily) so that it can handle clock drift.
renewiltord 6y ago
Actually, why doesn't signing a time-stamped unlock work?
- PowerBar 6y ago
  That's one of the other popular strategies, but relies on both devices have accurate clocks. With computers and servers (where the strategy is used quite a bit, sometimes in combination with challenge-response), it's quite easy. If you're working with something non-networked or battery powered like a garage door opener, clock drift becomes a serious issue.

davidhyde 6y ago

What about using a time based one time password algorithm instead of a challenge-response mechanism? Most embedded systems have a real time clock. Would it make sense to use this technology for that? https://en.m.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.m.wikipedia.org/wiki/Time-based_One-time_Password...

cybergibbons 6y ago
RTCs are actually quite rare, especially in a lot of the lower power RF SoCs. Drift would also be an issue - most move at least 10 minutes a year. That's with good temperatures, not being left in a hot car or at body temp. If you could solve the drift issue then it would be pretty good I think, it's an interesting idea.
- davidhyde 6y ago
  Maybe you could use the secure connection to resync the time or some other clock with the authenticated server. I guess that’s just another request / response type of arrangement though. And then any breakdown of communication for an extended period of time would brick the whole thing. EDIT: Maybe the time based one time password algorithm can be configured to be made less time granular (say daily) so that it can handle clock drift.

renewiltord 6y ago

Actually, why doesn't signing a time-stamped unlock work?

PowerBar 6y ago
That's one of the other popular strategies, but relies on both devices have accurate clocks. With computers and servers (where the strategy is used quite a bit, sometimes in combination with challenge-response), it's quite easy. If you're working with something non-networked or battery powered like a garage door opener, clock drift becomes a serious issue.