"Use a real secure element" quietly assumes the SE is the whole trust boundary, and that the seed is structurally locked inside it. Neither has held up. Ledger Recover shipped a firmware path that shards the seed out to three custodians. When people objected, Ledger's answer was that firmware capable of key extraction had "always been possible" to write, and that users had simply been trusting Ledger not to ship it. So the actual model isn't "the silicon won't let the seed out," it's "we promise not to." BOLOS is closed, so there's no way to check the promise is being kept, and the chip documentation sits behind an NDA, so you can't check the layer underneath it either. Jade puts the gate outside the device, where you can run the oracle yourself and read the code.
Worth remembering the trust boundary took a while to settle, too. On the original Nano S the SE didn't drive the screen or the buttons, so an attacker owning the MCU could show you one address while the SE signed another. Ledger moved the display into the SE from the Nano X onward, which is a tacit admission that "keys are in the secure element" was never the whole story.
On your point about "breaking the ESP32," the level of evil maid attack needed to take advantage of EM fault injection is akin to someone replacing a Ledger device completely and logging PIN entries. Neither of those is a silicon problem.
None of which makes Jade invulnerable. The ESP32 is a general purpose MCU and it behaves like one under a lab attack. But Jade is the only wallet where I can read every line of the firmware, run the oracle myself, and see the whole security argument end to end rather than being handed a certificate and asked to trust it. For a device holding real money, that tradeoff isn't close. Jade is genuinely great, and I think it's underrated precisely because its threat model is honest about what silicon can and can't do.
顯示更多