Timing attack in OTA authentication

[skorokithakis]

Since the comparison function of the secret for OTA authentication is not constant-time, it is possible for an attacker to discover the OTA secret over the network and flash whatever firmware they like.

The following article has an explanation and fix:

http://blog.ircmaxell.com/2014/11/its-all-about-time.html

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[projectgus]

Interesting observation!

I saw this being discussed on gitter and I took a look at the code. I don't see how it's exploitable, but maybe I'm missing something.

Calling String.equals() to compare the challenge hash response is vulnerable to a timing attack. If you had multiple attempts at sending challenge responses then you could decode what the challenge response hash should be from the timing.

However, as soon as a challenge response fails the OTA system drops back to the OTA_IDLE state and the next time around it generates a new nonce, meaning a totally new challenge hash.

So I'm not sure how you'd attack that, but maybe I'm missing something.

(Also, there's a strong chance the WiFi transmit timing is jitterier than the timing difference between a 1-byte memcmp and a 32-byte memcmp, but that's probably not a good thing to rely on.)

[skorokithakis]

That's true, but theoretically-hard crypto attacks have a weird way of being exploited in the end. In this case, the fix is so simple that I'd rather add the two extra lines and be safe than sorry.

[projectgus]

Fair enough. :)

[tablatronix]

Could also do preffered double hash hmac comparison, you gotta avoid any optimizations for real protection, but I have no idea the state of the crypto atm, A simple ord comparison should be better than nothing.