When I was on a team that made a similar device over a decade ago, we were up to our eyeballs in academic papers about SPA and DPA hardware and software countermeasures. That doesn't mean we didn't make any mistakes, but at least we were knowledgeable enough to hook an oscilloscope up and see what's going on.
These guys completely ignored an entire class of attacks, known in detail for a couple decades, (in reality since 1943, declassified 1972 (). I wouldn't trust these guys to protect anything of value.
Since all the crypto math happens with what is now essentially random numbers, you gain no knowledge from power analysis.
Downside of this method is that it requires additional operations and your crypto algorithm needs to be suitable for this. There is literature on this method, but don't be confused by "blind signatures" which is something different.
Any crypto wizz around that can tell me if secp256k1 ecdsa can be blinded?
There is a bunch of elliptic curve stuff you can do like "multiplicative blinding", e.g. https://www.iacr.org/archive/ches2010/62250433/62250433.pdf.
Still have to have solid software that doesn't do early returns and the like.
Include some kind of energy storage on the device, such as a battery or an ultra-capacitor. Your external power source (e.g., USB) charges your storage device, and your computation is powered from the storage device. Only charge the storage device between complete operations.
Someone watching power over USB would then see no power draw during key operations, and a smooth power draw between operations.
If your threat model includes attackers that will be able to probe inside the device while it is doing operations, and so who could look at the power on the far side of the battery or capacity, then buffering power won't be sufficient.
Random noise would just mean that you have to take multiple measurements and average them. Depending on the system in question, "multiple" may or may not be impractically many.
What I don't understand is why this device recomputes the public key on each read, instead of storing it persistently after creation.
Prevented by not letting anyone casually hook up an oscilloscope to your TREZOR.
Short of a oscilloscope hiding in the computer you use (totally possible), no process can derive the private key from the Trezor in theory.
Even if you have processes that blatantly copy every USB's contents (or even log all interactions verbosely) and log all key presses/clipboard interactions on the machine, you can still use a Trezor without compromising anything.
You can also verify that your clipboard is not being manipulated as the Trezor can verify the address it will be signing a transaction with on the display.
ADC's may be expensive in low volume discrete form, but integrated in (standardized!) peripheral bus (USB) controllers, this could be very cheap.
As always, it depends on the threat model: do you wish to protect against manufacturers/nation states or not?
Esentially adding a micro controller with an Analog to Digital converter that can watch the power pin inside the USB controller/port itself would be relatively simple and cheap.
If you stick a USB drive into a compromised computer to make a transaction, a virus can steal the private key.
If you stick a Trezor or Ledger into a compromised computer to make a transaction, your private key is still safe.
While this attack shows the trezor is probably a bit amateur-hour, it does provide some amount of value.
Specifically, I was answering the question "Why not just use a USB drive"
If I invested in one of these hardware wallets, I'd be interested in making it cost at least $X where $X is greater than the value in the wallet. I'd also like some time component, Y, that would allow me to transfer the money before the private key was found.
funny you say that, because TPMs aren't actually mandated to be tamper resistant, only tamper evident. what this means is that you won't be able to extract the keys without destroying the device, but if you delid the chip and probe it, you can probably extract the keys. I suspect it's the same with other HSMs you see in everyday life (smart cards, smartphone with trustzone, etc.).
 sorry i don't have a better source: https://media.ccc.de/v/32c3-7343-beyond_anti_evil_maid
While there are some smart cards and smartcard-like HSMs (Fortezza comes to mind, but it uses the battery primarily for integrated RTC and seems to not contain any tamper detection mechanism) with integrated battery, common smartcards does not have battery.
The term "smart card" is frequently misused in popular nomenclature. As a technical term, it refers specifically to contact or contact-less (like NFC) cards with an embedded chip which are, at minimum, physically tamper resistant. For example, a typical credit card is not a smart card. A SIM card is a smart card (or token).
Tamper resistant does not imply tamper proof, which can also be a source of confusion.
As jochen mentions in his timeline in the post trezor asked he delay publication until they could fix the bug in release 1.3.3. he says they included a fix on Mar 30 which you'll find in the link above
Plus, suddenly people are pumping millions (or billions) into private keys on little devices, it is amazing.
It's possible to create gold artificially, but because of the cost of doing it vs just purchasing the natural stuff, you can be almost certain any gold you come into contact with is not artificially created.
In much the same way, even though there are indeed tons of theoretical attacks that compromise various crypto keys linked to massive fortunes, because of the way the sector has evolved in terms of not making high value keys available in a low security context, and mitigating those threats in a high security context, the likelihood that any given crypto "account" you care to mention will ever be hacked is similarly low. It's not worth the attackers to invest the necessary resources to snag your minor android wallet stash, and even if they tried to bring those resources to bear on Xapo's vaults, they would fail.
Also, the sector as a whole has basically pioneered a whole new class of security measures, at least to the extent they're now in reasonably wide circulation, and improved security consciousness and software in general around the space immensely, exactly because now a bug isn't just some time and embarrassment, it may well be losing millions of dollars in value. In that context it makes sense to invest in the security to do it right and think carefully about all possible attack surfaces and vulnerabilities.
That said, this attack didn't make the TREZOR look great. What's a good option for a U2F key? On a similar topic, with WebAuthn, is it worth waiting for FIDO2 keys?
You can get a cheap, good YubiKey which is U2F/FIDO2 certified for 20 USD/EUR . These communicate over USB-A or USB-C depending on the one you buy. We're in a transition of USB-A to USB-C that's always a rough time. Do you go for backwards compatibility, the (better) future standard, or both (buying two)?
If you prefer Bluetooth or NFC the one I mentioned above is too limited. Then Google recommends a Feitan for the former, and I recommend a YubiKey NEO for the latter. YubiKey NEO is also open source.
With regards to TREZOR/Ledger, 2FA usage is more of a nice by-product. People buy it as Bitcoin wallet 2FA and that it can be used for more is an afterthought. One that can save you a couple of bucks though.
Either way I recommend at least 1 2FA backup. Could be codes, or an app, or a second YubiKey, or even SMS. Though, obviously, each of these has their weaknesses you could host the codes in e.g. cryptosteel  at a notary. I plan to do that with my important passwords (ie. the password for my password manager).
I think it's worth considering that these attacks are problematic in theory, but they still require quite a bit of access and opportunity.
If your threat model does not include physical attacks, then any U2F device (except software-based ones) is fine.
In terms of technically why it's really a bad piece of hardware, I can elaborate if someone wants details, but at a high level it lacks any form of hardware triggering (and everything is pretty much driven by the relatively slow on-board 8051 (no FPGA or anything similar)), and data transfer only happens over bulk USB transfers; furthermore sometimes the firmware just drops data.
The scope also works great on Linux with Sigrok.
Totally amazing bits of kit and together cost me less than a bottom end 100Mhz Tektronix scope. Both have Ethernet too so I do a lot of scripting with python and the two. You can add your own features then! So far I've written a simple distortion analyser similar to the one bob Pease described for ED magazine in around 2001. Basically it subtracts input and output and then applies arbitrary phase shift and gain and then subtracts that from the original signal to see where the distortion occurs in the cycle.
Only complaint is that the DG1022Z csv parser is a piece of shit if you want to load your own arb data. Works better over LXI.
All I need to do is take screenshots, is there a quick way to do that over USB without having to use Ultrascope?
I'm surprised there seems to be no stable way to do it by USB.
Or USB stick. But that requires carting the stick around.
It's pretty sad indeed. 48 MHz clock and performance is maybe 2 MIPS, if that...
The key to get the best out of FX2LP is to set MPAGE to 0xe6. This way you can index USB registers at 0xe6xx through 8051 r0 and r1 -- no need to load register address to DPTR. Most interestingly, this also works for XAUTODAT1 and XAUTODAT2 registers, which can act as (optionally auto-incrementing) read/write pointers anywhere in xram. This enables "fast" memcopy, memfill, strlen, etc.
If r0 points to XAUTODAT1 and r1 to XAUTODAT2, and auto-incrementing is enabled, memcpy becomes just this:
movx a, @r0
movx @r1, a
djnz r7, memcpy_loop
With FX2LP autopointers, 8051 native DPTR isn't typically needed at all.
edit: it is worth noting that if you can deal with the design and hardware limitations, the limitations of the included proprietary software should not necessarily scare you off, sigrok  has support for a lot of these cheap devices. Since writing this comment, I also just discovered a newer project called openhantek , which seems to be very active.
I have no need for an oscilloscope, nor do I even know how to use one. They've always seemed pretty interesting to me, but when I've looked before I've managed to convince myself out of spending XXXX on something I may only use once. If we're talking in the sub 100 range then it seems like something I could use or not use, and then upgrade it if I actually find it wanting (ie I invest enough time to find something I want to do with it but can't).
I think I'll do a bit more research anyway.