I got a Ledger wallet and was too paranoid to trust its seed generation, so I wrote some code to generate my own seed on an ESP8266 (after a failed attempt at doing the same thing with just a PDF and dice).
The checksum in a 12-word seed is only 4 bits. This means you could absolutely pick 12 random words using nothing but a dice. When importing the seed on a hardware wallet, if it complains that the seed is invalid (because the checksum is invalid) just change the 12th word by picking the next one in the BIP39 list (https://github.com/bitcoin/bips/blob/master/bip-0039/english...). If it complains again, tries the next one. And so on. At most you may have to try 2⁴ = 16 different words. One of them will pass the checksum. And there you go, you have a valid seed that was generated with a simple dice roll, without the need for custom code running on an MCU or offline computer.
Edit: BTW your method of calling MicroPython uos.urandom() to generate the seed is not necessarily safe! The MicroPython API does not guarantee the entropy always comes from a secure hardware RNG. Just "when possible". This means depending on your MicroPython version, how the framework was compiled, what exact revision of the ESP8266, entropy may or may not come from a secure hardware RNG. As a former InfoSec professional reviewing hardware/firmware/software security-related code, I often found flaws at many levels in this area.
Edit #2: In fact, after more looking into it, the current version of MicroPython relies on an undocumented register (https://web.archive.org/web/20160417080207/http://esp8266-re...) that "seems" to be a hardware RNG however it has never been determined if it is suitable to use for cryptographic purposes. It would be a lot safer to generate your seed on an offline Linux laptop booted of a Live USB or equivalent (with no storage device), using the good old cryptographically-secure getrandom(2) syscall than blindly trusting an undocumented sketchy ESP8266 register whose implementation is completely unknown. If I were you I would discard any wallet created using your ESP8266 code.
It'll take me 30 seconds to use, but setting up the Raspberry Pi and formatting the SD card afterwards is a hassle. You can't beat the ESP8266 method, since you can just look at the code and be sure what it's running.
I'm not sure the ESP8266 is a great way of accomplishing the goal of being able to know what's running by just looking at the code, unless the Espressif has suddenly opened their firmwares and toolchains. An AVR (like an arduino) would probably be better suited for the task, as the open toolchains are mature.
What would Espressif be able to do? Somehow retain the entropy it gave to the code that you used to generate the key and then send it to their servers when you reflashed with an unrelated program and connected to WiFi? That seems a bit far-fetched.
Regardless, sure, the Arduino is also a good platform to do this on. It doesn't run MicroPython, though, so I implemented my particular program on the ESP for speed/ease of development.
Don't forget the Debian bug that created weak keys from 2006 to 2008. These sorts of things happen. It's best not to attempt to disparage the possibility.
Shit I got mine through Amazon a few months ago and was a bit worried it could be compromised. My paranoia is kicking in a bit more now after this article. Do you have any recommendations on checking that my Ledger isn't compromised? Ledger has some suggestions on their site, but as far as I understand they only check the integrity of the wallet apps.
From what the article says, you basically can't be sure, unless you check the hardware. I would advise at least flashing the original firmware that you can get from Ledger themselves.
Am I correct in understanding that the exploit would most likely be cleared by re-flashing the firmware to a known good image before you use it? Especially if you did so using JTAG it seems like it'd be very difficult (albeit probably not impossible) for the firmware modifications described in the article to persist through a reflash as long as you're reasonably confident that the hardware itself hasn't been altered. That doesn't get rid of the evil maid scenario, but it does get rid of the supply chain attack, which is IMO the more concerning one. Evil maid attacks can be mitigated by physical security, but the supply chain attack is out of your control.
Yes, and that's what the update does. Since the bootloader wasn't modified (at least with this particular attack), flashing a known-good image fixes it.
The problem is, if you flash with JTAG you're basically just trusting your host computer not to be compromised. And isn't not having to trust your host computer the entire point of a hardware wallet?
Big difference, you're only trusting the host computer (and the JTAG dongle) once. This is manageable, use an airgapped junk laptop with no HDD or similar if you're ultra paranoid. Sure perhaps the firmware is compromised and leaking data through some super exotic attack but I mean come on. That should give you a pretty reasonable level of confidence. You can never 100% trust a device you didn't design and fabricate every aspect of yourself, there's always some risk with any hardware token.
I'd also argue that trusting your host computer is certainly better than trusting the supplier. Shifting the burden of trust from a device you don't control to one you do is at least an improvement.
unsure how feasible this is , but maybe check if they have a software version of their key generator and confirm the codes you use in that are identical to what your device displays.
Here's the writeup, with code you can audit/try:
https://www.stavros.io/posts/perfectly-secure-bitcoin-wallet...