pull down to refresh
0 sats \ 7 replies \ @expatriotic OP 16 Mar \ parent \ on: Cold storage without a hardware wallet bitcoin
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.
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.