micro-ecc

This is true. Many of these devices are using effectively joke crypto libraries however, theres a world of difference between something that needs a sophisticated setup, and the python crypto library that was transliterated into C and makes absolutely no effort at being constant time. The original Trezor software took something in the order of 300ms to produce a single signature. You could probably have done recovery of the nonce from ec multiply with a stopwatch. If your security appliance is using an ECDSA library for Arduino that has absolutely zero tests or review, you just outright lost. Some of the more well known products in the space do exactly this. https://github.com/kmackay/micro-ecc/blob/master/test/test_e...

https://github.com/kmackay/micro-ecc claims to run on an Arduino and supports secp256r1. The rest of the U2F flow is mostly packing and unpacking what gets signed and verified. U2F has a neat property that the device can be nearly stateless. The two main functions it performs, registration and authentication, can offload per-origin storage requirements onto the origin, like web cookies but in reverse. So the device can ship with its single unique signing key already generated in the factory, and no further configuration is ever needed. The one exception is the counter parameter that's supposed to track the number of authentication operations in the device's lifetime. Its purpose is to allow sites to detect device cloning. But I have a feeling that if someone always returned 1, most sites would still accept it. And if it really were a hard