related posts
331 sats \ 5 replies \ @john_doe 8 Aug
Thank you, the post is quite neutral so not a challenge to read.
I have some doubts regarding two points though:
-
"Use hardware where you can easily verify the integrity of the source firmware and its updates". I don't think never upgrading a firmware is a best practice and should be recommended as a solution. In my case I do upgrades and verify as well my software has a signature matching what I downloaded. If users can't do it, then it should be done by the vendor.
-
Regarding the last part, if we are worried about Dark Skippy then just "use multisig". I use it myself so I am obviously not against but to a friend I would just give a hardware wallet I trust and not recommend multisig. I think the appropriate solution again is not on the user side but the vendor side for those who don't use multisig.
reply
352 sats \ 4 replies \ @hugomofn 8 Aug
(Author here.)
If a firmware update includes critical security fixes, then I agree 100% that you should upgrade. However, it's worth noting that a lot of firmware updates (and software updates in general) are about adding features (that you may or may not need). So merely by choosing to upgrade when absolutely necessary, you'd lower the risk of installing a malicious firmware.
All things considered, you are much more likely to lose bitcoin due to self-inflicted user errors than to lose bitcoin due to Dark Skippy. So for new users, I also agree that multisig might not be the best start. Better to start them on a singlesig wallet with a small amount of bitcoin, then help them gradually upgrade to multisig only when they're ready / have a significant amount of bitcoin.
reply
50 sats \ 1 reply \ @nerd2ninja 8 Aug
This is actually correct. This isn't an internet connected device remember so our main concern is not with RCE (remote code execution) from an unpatched vulnerability. Rather, our biggest threat in an airgapped system is the firmware update itself lmao. So reserving that update to only critical patches (which are typically geared towards defending against physical attacks, but could also maybe one day include an anti-exfil mitigation) is actually the right answer here.
What most corporate signing devices do, is have the old firmware verify that the signature of the new firmware matches before it allows the new firmware to install. This could technically be done in DIY devices too, but I feel it would have its trade offs. Not all development teams are good at keeping their signing keys from leaking due to them getting hacked (This happened to Samsung).
reply
300 sats \ 0 replies \ @hugomofn 8 Aug
Right. Companies can definitely screw up w.r.t. cryptography. Sony PS3 is another famous example that comes to mind: https://arstechnica.com/gaming/2010/12/ps3-hacked-through-poor-implementation-of-cryptography/
Even when the cryptography is correct, the signature is only as good as the person/group guarding the private key. So signed firmware significantly mitigate risks, but don't completely eliminate all issues. (This is why if you're super paranoid, multi-vendor multisig is still the most rational solution).
reply
41 sats \ 1 reply \ @john_doe 8 Aug
Since you are the author, thank you for the article again, it helped me understanding what the issue was about without all the noise around.
Regarding "So merely by choosing to upgrade when absolutely necessary", I still think this is a burden moved to the user which should be managed on the vendor side and at least suggest updates in some form on the UI. Let us say I want to use Taproot. It is not strictly necessary but updating a firmware just for that is legitimate and I don't think users should know about each bug fix or new feature which happened meanwhile to decide if they have to update or not.
The bottom line is in the end I believe the user should be comfortable to trust the vendor advertising for an update and update when asked for it. I am not aware of all issues in Linux or GrapheneOS for example and yet I update when asked to do it, at least I know I won't miss a critical bug fix.
reply
21 sats \ 0 replies \ @hugomofn 8 Aug
You're welcome!
I see what you mean from the end user's perspective.
Vendors can generally make the process of firmware updates more secure and more explicit/transparent. For example, they can clearly label which firmwares have critical security fixes (and well-maintained projects usually do so), and which ones do not. From there, it's up to the user to make the decision whether to upgrade.
About things that you don't strictly need but want to experiment with: as I mentioned in the article, that is fine, but IMO you'd want to use a separate device for that. Have it as your sandbox: put some small of bitcoin in it and try things out. But isolate it from your main savings as much as possible.
Unless a firmware release has critical fixes, you want to delay upgrading until it has been widely deployed. You want to do this not only because it lowers the chance of accidentally installing malicious firmware, but also because (a) newer firmware might have bugs and (b) many vendors disallow firmware downgrade, which makes the process irreversible.
So on the balance there are things vendors can do to make things easier, but there's a certain responsibility on the part of the user that I think is unavoidable. It might be more burdensome than say, upgrading Linux, sure, but IMO that's the cost one has to pay if one truly wants to be sovereign. After all, securing generational wealth is more critical than maintaining your typical software OSes/applications.
reply
310 sats \ 0 replies \ @kepford 8 Aug
This attack is interesting.
But it seems to boil down to verified firmware. Still figuring it out though
reply
10 sats \ 0 replies \ @iam_jerry 9 Aug
Great piece. Thanks.
reply
42 sats \ 1 reply \ @BlueSlime 8 Aug
There are more sinister ways to attack digital signatures than this.
FYI if your device uses a nondeterministic nonce when signing, then it is impossible to verify whether your signatures have been tampered with.
reply
0 sats \ 0 replies \ @hugomofn 8 Aug
Using a non-deterministic nonce is actually quite similar to this attack (and can be categorized under the same attack class) in the sense that they both involve messing with the process of securely generating a random nonce.
Dark Skippy is just more explicit in how it goes about it, e.g., causing the device to leak private key data into the nonce and/or blinding the nonce with a hacker-controlled key.
reply
0 sats \ 0 replies \ @160ed04091 8 Aug
thanks, for the tips i will surely start using Use hardware vendors that have tamper-resistant mechanisms in place, such as tamper-evident sealed bags, firmware attestation
reply