pull down to refresh
21 sats \ 14 replies \ @final 15 Mar \ parent \ on: Cold storage without a hardware wallet bitcoin
I will add some context for this in how we handle these situations:
Many/almost all CVEs we have discovered actually do not affect GrapheneOS. Many from the upstream also are not likely to work or cause damage. They get found because our exploit mitigations (MTE, Hardened Malloc, etc.) allow them to be uncovered since we forcibly crash apps that have memory corruption bugs and provide the ability to share logs to help developers/security researchers. More is good in this case because it means more identified, more patched, more R&D and security improvements. We're very happy to know we discover novel vulnerabilities thanks to our hardening.
For example, we recently uncovered a memory corruption bug introduced in Android 14 QPR2 for Bluetooth LE which we reported to Google. The team reported it as an Android vulnerability and has been designated as a High severity and quality report. On GrapheneOS this would make Bluetooth LE functionality with the relevant devices (Samsung Galaxy Buds and watches) to crash reliably or break, while in the stock OS it could corrupt user data.
When we discovered companies exploiting Fastboot mode on Pixels to allow data extraction, they explicitly avoided mentioning it's failure to work on GrapheneOS, noting separately GrapheneOS devices needs it's user to surrender their PIN for data extraction themselves for their products. No security measure will protect against someone willing to turn them all off to someone by surrendering their credentials.
You could just sideload instead of doing updates OTA if you wish. OTA is strongly recommended but they are optional. You can also read the source code and reproduce the builds. Even if you do all of this, you're still trusting GrapheneOS because you need updates to be signed by GrapheneOS if you are already using it or it will be rejected for security. There is a degree of trust in anything you use even if we try and make it as untrusted as possible. Overkill is you can just build the OS and the updates yourself.
This case affects system apps signed with a specific OEM's platform certificate. This attack is only possible due to incompetence by the OEM getting their keys leaked. If you leak your keys to sign your apps then anyone can sign their app as yours and make a malicious update to an app you created providing they have the same certificate and key. They should do better to make sure no one but them had access to it.
A mechanism like this is needed for operating system updates too. In the case of Verified Boot all updates must be signed with the same key pair, versions cannot be downgraded, turning it off or wanting to change the key erases your data. If you sideload an update or get it OTA it does not matter. If someone compromises the servers they can't push an update because it's not signed by the developers. You can also verify the boot key hash matches the legitimate OS at boot. Like with GrapheneOS: https://grapheneos.org/install/web#verified-boot-key-hash.
The Auditor app also helps with verifying you are using a legitimate GrapheneOS build and more.
Won't comment on the choice of Airplane Mode, you can hide the quick tab buttons but it's up to each person to do their due diligence and handle the device properly of course. Could be room for making enabling/disabling require more attention or difficulty in the future.
(This comment is in no way suggesting GOS should be used as a hardware wallet. It's up to them. We think the hardware/platform we have is very secure for cryptocurrency uses but of course a dedicated device with a secure element, upgradeable firmware and good security posture would be a recommended and sensible option)
Look, I'm using graphene myself you guys are great (for your intended usecase), but when it comes to securing people's net worth its just not okay to not meet the basic requirements (use hardware that doesn't have wireless devices on board). Its such a simple requirement to meet and so many signing device manufacturers fuck it up.
The way I think about cold storage is, if you wouldn't recommend it to a nuclear power plant to transfer a software update to their nuclear reactor, or to a government transferring classified data between devices, why are you recommending it to people to secure their net worth? Especially because the requirements are so achievable and just require actual verification and to not use hardware that isn't appropriate for the task, the baseline of which is to not have wireless devices on board.
I wrote a lot more, but I'm trying to write less to keep focus on the things that matter most.
reply
Not a problem at all! :) I'm just adding some context. I'd also prefer a dedicated device as mentioned in the end of my last reply especially for cold storage, GOS Foundation cryptocurrency funds are managed entirely by signing devices. I only use LN funds on my phone, nothing else (can't say the same about the others but I believe it's the same). It appears the OP is discussing a low budget, and if they really can't afford a dedicated device but have a phone then keeping that as secure as possible is likely the closest thing they can do.
GrapheneOS definitely is a massive improvement for a use case like that even though we aren't very oriented on cryptocurrencies, just mobile security and privacy.
If they are handling large amounts and all of their funds then keeping it in a dedicated, secure and offline signing device is a must-do. It's definitely one of the very basics someone should learn to do if they have the comfort and budget to do that. It's not just security but also just contingency against device failure.
reply
Just to put it out there, if you were looking to make a signing device, there are lots of PCB manufacturers out there. Personally, a file like the ones you see on kitspace that I could give a PCB manufacturer that was simple enough that I could visually inspect the board and verify its correct with no hardware level backdoors would be like my dream signing device.
Which sure cold card was going for that with the whole clear case thing but they kinda went source available rather than open source on us.
A GPLv3 license would also be pretty rad.
reply
We definitely don't have people for this and a hardware OEM would need to work on that, plus it seems may seem a bit out of what GrapheneOS is focused on as a mobile/security privacy non-profit. Although it could be a nice thing.
In the past there had been ideas of a phone that could essentially have a Trezor or equivalent built into it with a whole separate display on the back and completely isolated, but it already works as separate hardware anyway.
A serious OEM could make a phone with this in mind and make an ecosystem with it. Android keystore API could have support for secp256k1/Schnorr added and then apps could use additional secure element support for it. In practice someone could add that as an extension implementation, but it would need to be part of the stock Android standard apps APIs for app devs to consider using it. It wouldn't really be much of a hardware wallet alone since there's no secure display.
The open hardware would be more of a ethical choice than a security or privacy one. If it did use an open hardware design, there would still be just as much trust in the manufacturing for each component you buy like an SoC or secure element. The manufacturing process itself isn't open, and makes up a lot of their complexity.
Trezor do quite a similar job to what you describe, people build their own, they also do GPLv3: https://www.instructables.com/Making-My-Own-Trezor-Crypto-Hardware-Wallet/
https://github.com/trezor/trezor-hardware/tree/master/electronics
The issue is the Trezor's before Safe 3 don't have a secure element so strong PIN/passphrase and other remediations needed to protect physical attacks.
side note: Electronics is not my strong spot at all.
reply
I mean, I'm a nerd so if someone made a solderless breadboard signing device I'd be all over it.
Anyway, thankfully for all of us, physical attacks can be mitigated outside of just having more secure hardware. You know we can do geo-dispursed multi-sig.
We call throw casino dice against a wall and enter our manually generated randomness into the wallet
We can just use simple air gaps.
And we can use firmware with the least amount of software to get the job done (no need for a multi-coin bloat wallet when all you need is a bitcoin signer)
reply
It appears the OP is discussing a low budget, and if they really can't afford a dedicated device but have a phone then keeping that as secure as possible is likely the closest thing they can do.
Exactly.
And of course, I use a Foundation PASSPORT for my large funds, and LN funds are spendable from my phone.
reply
If the cold device stays offline does it need updates? E.g., some of the Samourai wallet guys argue that it's okay to use unsupported pixel phones with GrapheneOS because they're keeping it offline.
reply
TLDR: Update because there is several benefits.
It is always better to update. Updating also gets you the new security features and enhancements. We added a feature in Tensor Pixels to completely disable the USB-C port's data lines or the port entirely very recently. In a use case like cryptocurrency then that could be quite useful. Future in-development features like Duress Password could also go a long way.
Even if they don't matter, if you have a threat actor who is quite persistent, then updating prevents possible attacks. Air-gapping only protects network-based threats.
(Note: This scenario is neutral and isn't entirely specific to Samourai but I tried my best. Knowing them, they probably do have some anti-forensic features so some of these possibly won't count for them.)
Imagine a scenario where the Fastboot mode vulnerability affected GrapheneOS, or you were using an unpatched stock Pixel, or the vulnerability was never discovered by the team... Threats who had access to this company's capabilities would be able to just crash the device causing an unsafe reboot that doesn't clear RAM, memory dump the phone via their exploit and be able to brute force the device credential. For these users I imagine this is how far they'd get, they're probably incorporating a strong, high entropy passphrase.
So, lets imagine the user is stupid and that brute force is successful, they can extract the full filesystem and clone your application data. If an app stores data encrypted and was active/unlocked during the time they begun the dump, it is possible that memory dump could find possible information about the app. This happens with apps like KeePass in research where users can get the DB passphrase, and disk encryption all the time in the real world to get the decryption keys.
Even if there is no keys in memory or it is encrypted, cloning that data is useful in brute-forcing. It should in-theory bypass some brute-force prevention measures like a destruction PIN or attempt limits since they can just keep using the clone from before it. If I was a persistent actor who seized a phone and cloned the data of a Samourai user, I'd not target their backups or memory since BTC private keys cant be brute forced, rather I'd just clone the app data (samourai.dat), run on a bespoke script and brute force the PIN that opens it instead.
By the looks of it when writing this reply, someone else already had this idea: https://vrls.ws/posts/2021/08/samourai-wallet-bitcoin-pin-authentication-bypass-crypto/
(Does Samourai Wallet still do AES-KDF for derivation? Maybe someone should tell them to consider Argon2id if they haven't?)
This is not a security issue with Samourai by any means worth screaming about nor a critique of their security, the fact someone actually assigned a CVE to that is also quite petty, every app of it's kind with an authentication should have one then for the same reasons. I've seen KeePass make CVEs dismissed over this by saying it is the responsibility to use a secure OS to prevent such an attack.
Someone with a lost/seized device would be able to just import the private key to a new wallet and move the funds away before the brute force is successful. The article says around a hundred days but appears the guy using was using his notebook, would definitely be much faster for a sophisticated threat. Even if they could brute force instantly, the time to brute force the OS has been ignored, that takes time too.
They made a statement on Twitter which is a completely reasonable response: https://twitter.com/SamouraiWallet/status/1423590495054348290?s=20
While using a very strong passphrase, incorporating GrapheneOS exclusive security features and so much more would fix that scenario if the exploit was unpatched anyway, it is a matter of having defence-in-depth and better to have all the walls standing than one of them to break. Updating is always good because you keep all the walls standing and reinforced.
From my experiences all cryptocurrency wallet apps on a phone with a physical access have a way of getting fucked unless they take extreme measures. Securing the operating system running the app is sufficient for almost everyone and GrapheneOS definitely does that job. If you are this worried about a threat with all of these capabilities then maybe you should probably not have a computer. Even if a supposed brute-force took days, that's still more than enough time to move funds and import elsewhere like mentioned before.
reply
reply
AFU?
reply
After First Unlock. When a device is powered on, encryption keys to decrypt data are not in use until you use the device credential for the first time. With BFU (Before First Unlock) these are at rest in the Pixel's secure element. There is a huge difference between a device not unlocked once after boot and a device that is when it comes to exploitable attack surface.
reply
Thanks for that
reply
Update if possible, but GrapheneOS doesn't support 4gen and prior, in which case it's not possible.
reply
We do provide extended support releases for these devices but they have many missing features and are meant to help users transition to a newer device. The newer Pixels aren't just faster, they're more secure, especially the Pixel 8 and later thanks to hardware memory tagging.
The unsupported/extended support devices do not get firmware or driver fixes, any vulnerability incorporating them remains unpatched. Using a heavily insecure unsupported device with many missing patches as a wallet may not be the best choice, especially if you're relying on it for other sensitive manners. You could thrift it and buy a signing device in some cases. Likewise, if a phone is seized that actor can sit and wait how long he wants until an exploit in the secure element is uncovered which allows him to brute-force.
Having a dedicated user with a stronger passphrase just for managing cryptocurrencies could help especially if you have a larger (but not cold storage worthy) amount. All of it's data would be encrypted and at-rest when not in use and it won't be active if you have another profile in use providing you set up the options. I do this to handle other currencies or PayNym payments. An additional user also makes it harder for the threat actor in the scenario above, as the profile would be at rest and could not be unlocked via a RAM dump brute-force unless the dump occurred while the profile session was active. Would need to have an exploit for the secure element like the device was in BFU otherwise.