Username : HeRetiK
BTC addy : bc1qwvnm4g4jfjg5nr0pzu9mxdyu865f24nc0dckhv

Good luck everyone!

Good point!

To clarify, I'm under no delusion that open source means 100% security -- see Heartbleed affecting OpenSSL for example. I'm just saying that the level of trust required and security provided by open sourcing your code is on a wholly different level.

Dapps and DEXs are actually a great example of the limits of using the many eyes principles of open source for additional security and trustlessness: (1) The developer communities are much smaller because they are splintered across a variety of projects, (2) the incentives for using an exploit yourself rather than doing a responsible disclosure are much higher (i.e. while you could monetize a 0-day you find on a hardware wallet or cryptographic library by selling them, exploiting a smart contract nets a much higher pay day without an intermediary) and (3) those projects unfortunately often come with both a leadership and community that tend to downplay and sometimes silence valid concerns as FUD (IIRC SOL was the posterboy for that).

Yes and no. Ledger is deliberately setting up a false equivalence of trust.

Yes, there's always a certain degree of trust required: If you can verify the code, you still need to trust the compiler. If you can verify the compiler, you still need to trust your CPU. If you can verify the CPU, you still need to trust the laws of physics.

But.

Contrary to what Ledger is trying to sell, trusting a single company to "do the right thing" is not even remotely the same as having thousands of developers and hackers -- independent and contracted alike -- making sure that there's nothing fishy going on. It simply isn't.

Well said. Lots of fluff, nothing that actually changes anything. Just a continuation of bullshittery, and not a good one at that.

I mean let's look at that step for step.

Already Open Source -- Yeah, I guess congratulations for using an open source cryptography library like any sane person would? Mentioning 150+ third party applications is just obvious padding. To be fair, not all SDKs are open source, but it's a really low bar and pretty much standard unless you are aiming for a very small niche and don't care about fostering a community of developers.

In the Coming Days -- A whitepaper and a few blog posts. *slow clap* Admittedly I am curious about the whitepaper though.

In the Coming Weeks -- Providing "tools to implement your own shard backup provider" is the first (and only) thing that sounds remotely like a step in the right direction (ignoring the core of the problem that is the devices' capability to send the seed over the internet, but that ship has sailed). "Open sourcing of the dashboard which is a specific part of the OS containing Recover implementation" is practically useless and just a thinly veiled diversion. But hey, maybe they get to out source the development of a dark theme for the dashboard to the community. Win-Win.

In the Coming Months -- "Modularize even more the OS in order to keep as little as possible the part that must be trusted." That's the sort of sentence that you dictate your intern to quickly jot down as a talking point, only for them to just use it word for word in the official communication without a second thought. Either way, that part of the roadmap is the most interesting to translate:

"In the Coming Months" => "We don't plan to actually do this, but if you keep pestering us we'll eventually have to throw you guys a bone in a year or two."

"Modularize even more the OS in order to keep as little as possible the part that must be trusted." => "Refactor the code in a way that keeps the nasty bits out of sight."

Honestly I find it downright malicious that Ledger's defensive message control boils down to lying about the current state of the hardware wallet ecosystem (ie. claiming that consumers always have to trust hardware wallet manufacturers while that's decidedly not the case). They are trying to normalize bad practices in terms of both security and privacy, making them the very antithesis of what one should expect from a hardware wallet company.

"Opening more source" "over time" can mean anything and is something I'll believe when I see it. And even if they start opening more of their source code -- as long as parts of their code stays closed source there will always be insecurity.

Case in point, Ledger's software is already mostly open source, except for the firmware. And that's where the bodies were buried. So even if part of it gets open sourced, as long as some parts stay hidden, they will always have room for burying bodies. "Welcome to my basement officers, feel free to look around, just don't open the freezer, that one's off-limit."


With Trezor you can download the source code and compile it yourself. Heck, if you feel especially nifty you can just go ahead and make your own Trezor clone [1]. Can't get much more trustless than that.

[1] https://www.instructables.com/Making-My-Own-Trezor-Crypto-Hardware-Wallet/

Looking at the script, I see nothing about it extracting and accessing the seed phrase.

For reference, these are the functions being used when converting the seed phrase directly on the hardware wallet (referred to as "Online" in the Readme):


All these functions do, is load the Monero-specific word list onto the hardware wallet. And while I don't understand the contents of the APDU (if anyone has a reference at hand that'd be greatly appreciated, as I didn't find any and it has sparked my intrigue), I can see that there's only write operations taking place with no data being fetched from the dongle (ie. nowhere in the code the return value of dongle.exchange is being used, though in this case it's probably just result and error codes).

Keep in mind that displaying the seed phrase on the hardware wallet's display doesn't imply that the wallet application is able to access it. It can tell the dongle to display the seed phrase without having access to it itself. To some extend this even applies to the firmware, but that depends on the architecture of the device and as we've seen for Ledger that's not the case anyway (the firmware not having access to the seed phrase, that is).

Please note that I'm not saying that this proves that applications can't access the seed phrase. I'm just saying that this particular example does not access the seed phrase.


Regardless of that, I agree with your conclusion:

That's good, as there apparently really is a technical limitation that prevents the Nano S to be affected by this update.

That's bad, as this confirms that the only thing preventing someone from writing barebones seed extracting firmware is security by obscurity (ie. fact that parts of the code are closed source).



2 sats say that they only admit that now, so that once this case inevitably happens they can say "hey we've always said this could happen, look at how honest and trustworthy we are!"



I'm not quite sure I can agree with this conclusion. Having the firmware and applications reside on the same chip as the seed does by itself not necessarily mean that the firmware or applications can access it. You can still have an architecture where part of the flash storage is accessible (ie. for firmware updates and installing apps) and some isn't (ie. for securely storing the seed). Additionally it should also be possible to have some parts of memory be accessible by the firmware, but not by applications.

So it's highly speculative whether the other applications can in theory access the whole seed phrase as well.

However, given what we now know and the closed source nature of the code... it's also highly speculative whether the apps can't.

(but we do know that at least the firmware can access the seed phrase, if only due to them admitting to it)

Thing is, he's not wrong. We should have never trusted Ledger to begin with. We, as a community, have failed, to properly communicate the technical implications of some elements of the code being closed source to those that are less tech savvy. We accepted a compromise out of convenience and now look at where it got us.

Also I have to cringe at how in his eyes (and apparently many other folks too) the "here are the facts" thread he's linked is making things better. Their main arguments being (1) you didn't seem to mind when you weren't aware of the problem and (2) other hardware wallets have problems too. Fuck me. And to top it all off, the gall to try to spin this as a communication problem rather than a technical one. Fuck.

Ledger is partially closed source, so there's always been a black box surrounding their "secure element". Accordingly security researchers were somewhat limited in their research.

Trezor on the other hand is completely open source, from top to bottom, from hardware to software. Accordingly security researches have been able to take it apart completely. Theoretically you can even build one yourself! And while they did find vulnerabilities that enabled the extraction of private keys with physical access, none of these where as simple as just adding custom firmware to the device. Which is something that for Trezor hardware would be fairly trivial, given the open nature of the device. Heck, there's even a guide by Trezor themselves on how to flash your device with custom firmware within their GUI: https://trezor.io/learn/a/downgrade-firmware-trezor-model-one

If extracting the seed from a Trezor were as simple as a malicious firmware update I'm fairly certain we'd know at that point. Otherwise researchers wouldn't have to rely on side channel attacks [1] or forcing RAM dumps by physically glitching the hardware [2][3]. [2] also briefly touches on why the seed itself can't be accessed by custom firmware at around the 38:45 mark.
(afaik [2] is still a threat, but [1] has been fixed before public disclosure and [3] seems to have been mitigated by increasing PIN length [4])

[1] https://jochen-hoenicke.de/crypto/trezor-power-analysis/
[2] https://av.tib.eu/media/39203
[3] https://cointelegraph.com/news/trezor-wallets-can-be-hacked-kraken-reveals
[4] https://www.reddit.com/r/Bitcoin/comments/sdx4r6/psa_trezor_doesnt_have_the_oftmentioned_seed/

TL;DR: Trezor we can verify, Ledger we have to trust. And what a misplacement of trust that has been.

The way that Ledger is partially closed source always left a sour taste in my mouth but I had given them the benefit of the doubt by virtue of being one of the oldest hardware wallet vendors around.

Alas, thank you Ledger for reminding me that giving someone the benefit of the doubt is never a good idea in the crypto space.



Repeating the passphrase, while stupid, would at least have implied that the seed isn't extracted from the "secure element".

However the Tweets referenced by RickDeckard point towards the firmware being able to extract the seed directly. In that case "requiring" the user to press "yes" doesn't matter. It's just security theater. There's nothing stopping the firmware from extracting and sending the seed without user interaction.



Source? From my understanding of Trezor's architecture the private key never leaves the chip -- the firmware is only able to send messages in and getting signed messages out. Which is also why all key extraction attacks (that I'm aware of) have to rely on side channel and glitching attacks rather than simply flashing the Trezor with malicious firmware (which anyone could, since unlike Ledger, everything single component of Trezor is open source).

It's anyone's guess since part of their code is closed source, but it might very well be that this backdoor can't be integrated into the Nano Ledger S for whatever reason -- why else would they want to miss out on that sweet sweet subscription money? On the other hand they might also just want to entice people to upgrade to their latest hardware wallets, because obviously everyone (and their moms, as we have learned) wants this feature.

Either way, at that point the 2.2.1 update is the vulnerability. If you can live without the GUI features even outdated hardware wallets can stay secure for a very long time (with few exceptions that involve physical access).

On the other hand it's unlikely that the backdoor has been there before because otherwise the hackers would have stolen the wallet seeds alongside the customer data way back when 

You don't need to open source the firmware if you just open source the costumer data! *taps forehead*



Interesting, I wasn't aware of the censorship controversy around Wasabi. Thanks for bringing this to my attention.

(Still, in my book not even remotely as bad as what Ledger is doing for 2 reasons: (1) I primarily expect security from a hardware wallet, with privacy being a nice-to-have, but I don't mind falling back on other options for that, (2) using transactions with questionable privacy is still optional while having a backdoor is not. But I'll leave it at that, for fear of straying off-topic. I definitely see your point regarding SatoshiLabs' company policy though.)

This is so wrong on so many levels and I just can't wrap my head around it. I just hope the market will punish Ledger accordingly, but I don't have much faith.

All the more important to keep calling this for what it is: A backdoor. Not an option. A backdoor. Your only option is to pay for the privilege of accessing the backdoor as well.



What happened with Trezor? I remember a seed extraction hack from a couple years back, but that one still required physical access which makes it not even nearly as bad as what Ledger is doing.



Reminds me a bit of that scene in The Big Short:

"I don't get it. Why are they confessing?"
"They're not confessing. They're bragging."



Probably. But you can't ever be sure that this backdoor hasn't been there all along, as pointed out by others upthread.

Kann auch sein. Wenn z.B. deren Compliance Abteilung mittlerweile zurecht gestutzt wurde, ist es einfacher Konten zu sperren als den ganzen Dokumentationsaufwand zu betreiben der mittlerweile gefordert wird. Fragwürdig ist nur wieso sie dir das Konto gesperrt, und nicht einfach gekündigt haben. Um compliant zu bleiben hätte Letzteres eigentlich auch reichen müssen.

(außer natürlich die Fidor kann nicht alle Konten so schnell kündigen wie sie gerne möchte, weil sie das Kapital noch braucht... ein Schelm, der Böses denkt)



Catch-22 des Bitcoiner Daseins: Je mehr man als Bitcoiner mit Banken zu tun hat, desto mehr erinnern die Banken einen daran wieso man zum Bitcoiner geworden ist.

Ganz so ist es auch nicht, dafür gibt's ja die Einlagensicherung. (wobei sich wer mehr als 100k bei einer Bank hat auch unabhängig von Fidor Gedanken über Risikomanagement machen sollte)

Und wenn die Fidor das Konto nicht nur sperrt, sondern auch schließt (z.B. weil sie den Laden endgültig dicht machen), dann kommt das Geld auf ein Treuhandkonto*. Das Geld aus dem Treuhandkonto dann rauszubekommen ist allerdings wieder ein eigener Kreuzweg, insofern macht es auf alle Fälle Sinn die Sache eher früher als später zu klären.

*Angaben ohne Gewähr, sind nur Infos die ich als Laie mal zu ähnlichen Fällen rausgefunden habe

Die Nachweispflicht bzw. Auskunft über Mittelherkunft kann sämtliche Einzahlungen betreffen die irgendwie "auffällig" sind. Das kann einem selbst bei privat an privat passieren, zumindest wenn es sich um größere Summen handelt. Allerdings fragen Banken sowas in der Regel an bevor sie das Konto sperren, um abzuwägen ob sie das Konto überhaupt sperren müssen bzw. das Geschäftsverhältnis auflösen sollten. Dementsprechend klingt das was dir da passiert ist in der Tat sehr komisch. Vielleicht versucht Fidor einen richtig harten Cut von Crypto zu machen oder es laufen gerade irgendwelche Ermittlungen die alle Kraken/Fidor Kunden unter Generalverdacht stellen.

Viel Erfolg auf alle Fälle!

Danke für die Auswertung 1miau! Ziemlich krass wie Kaspa derzeit unser Portfolio trägt, bin sehr gespannt wie sich der Coin im weiteren Verlauf des Jahres entwickelt.

EUR 24545,-

Username: heretik2

Permissionlessness is exactly the point though. Decentralization is only a means to an end.

Simply put, Bitcoin is not permissionless so that it can be decentralized. Bitcoin is decentralized because that's the only way for it to be permissionless.

Decentralization is the easy part, it's permissionlessness that's the tricky one.