pull down to refresh
0 sats \ 31 replies \ @expatriotic OP 14 Mar \ parent \ on: Cold storage without a hardware wallet bitcoin
I disagree, grapheneOS is extremely hardened. Phones are much safer (or can be) than a laptop... (Sans removing physical equipment as you're suggesting)
You disagree in ignorance. GrapheneOS is hardened sure, but cves are still found for it and it hardens even still.
One of the biggest problems with GrapheneOS (especially for this setup) is that software updates come over your wireless network. If that software update were malicious, you get pwnd.
So the way you propose to solve this problem is by using airplane mode, but what that looks like to me is you have a gun pointed at your foot and you aren't worried about shooting yourself because you just trust yourself not to pull the trigger.
You should do a lot more research on airgap security (and airgap penetration those are fun) before being so confident about your advice.
reply
I will add some context for this in how we handle these situations:
GrapheneOS is hardened sure, but cves are still found for it and it hardens even still.
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.
One of the biggest problems with GrapheneOS (especially for this setup) is that software updates come over your wireless network. If that software update were malicious, you get pwnd.
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)
reply
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
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.
BTW, in this setup, you would not be updating the software over a wireless network (or at all TBH) because the phone with Samourai on it that is cold is... cold. It's offline. Always. It has the private key and is just used for signing. Sentinel will broadcast and send out the message.
reply
My apologies sensei, clearly you are extremely knowledgable and I disagree with you at my peril, the peril of my stack, and the peril of the stack of everyone unfortunate enough to use the woefully inadequate GrapheneOS.
reply
You still haven't gotten that GrapheneOS isn't the problem tho. Its the rest of it. Its how do you remove the wireless devices to make sure only SD card or QR codes with PSBT files come on or off the device?
reply
No I understood your point... It's just boring...
The comments section here is just ridiculous at this point... I'm accused of telling people to BUY a new phone (never said that), and then I have people saying, use a laptop instead.
Okay... What if someone doesn't have a laptop... or what if the laptop they have is already full of spyware unbeknownst to them? Or what if they've never heard of TailsOS, or they aren't technically capable of removing the hardware you mentioned from a laptop (Full disclosure, I'm not). In fact, I might even recommend they buy a new laptop that's never touched the interwebs (but NO! Now I'm recommending spending money... And a LOT more than the $200 they'd spend on a foundation passport.
Long story short, buy a HWW, however, you CAN use an offline phone coupled with a hot phone to store bitcoin.
This post is about saying something is POSSIBLE.
If you prefer not to, or have a different way... Sure... Do that thing. Don't come to this comment section just to fuck shit up.
reply
We can go a lot cheaper.
Open source firmware under a mix MIT and Apache v2.0 licenses. Installs on a $48 device.
Now last time I looked at this, one of these devices had wireless onboard. Maybe I'm blind or not spending enough time looking or not searching the page for the right words or something, but it looks like the 2 named devices in their recommended devices list don't have wireless onboard anymore.
reply
I'll check it out 🙏🏻👌🏻
reply
reply
reply
But LineageOS, GrapheneOS, CalyxOS is open source. No need to trust airplane mode. You can look through the code and see what happens when you disable wifi, bluetooth etc. Is it actually doing that or not? With Apple though... turning off wifi is annoying because it just toggles off (til later 🤦🏻♂️)
reply
Okay 👍🏻
reply
reply
Sandboxing. With laptop qubes accomplishes this. With iOS or android, sandboxed apps is default. Yes you have to worry about apps getting permission to things like mic, camera, wifi etc etc in a malicious way, but the information between apps is sandboxed.
This is quite a short answer and you could explain these details for hours. Smartphones and their OSes are often designed with better security models than a desktop computer. Most of this comes down to a lot of societal factors, such as:
- mobile operating systems like iOS and Android coming out decades after desktops so they naturally build a better foundation with the knowledge people have today.
- mobile devices being more of a target due to their portability, prevalence, and the data people store in them being more sensitive therefore there is more effort to protect them.
- mobile device security is far more scrutinized than desktops.
In a technical description, you'll expect a proper smartphone operating system to have an actual application security model, proper app sandboxing with permission controls, use of memory-safe languages for apps, exploit mitigations, verified boot and a lot of security principles (like least-privilege, assume-compromise, secure-by-default and defence-in-depth) adopted. A mobile OS gets criticized as being "locked down" and "restrictive" but that's also why they are extremely safe.
Mobile hardware (on a good OEM) is also better, they are always receiving complete firmware security updates and driver support until the device's support timeline ends. Sadly on Desktops you need to rely on the OEM doing a barely-decent job and if you are building your own you'd need to check every hardware device you build with has firmware updates / is supported. Firmware attacks are a big deal on desktops.
Where a desktop shares a security feature, the mobile device does it far better. One example is the secure boot in a desktop is not really comparable. x86 Secure Boot does not verify all firmware, does not have downgrade protection, does not have an unbroken chain of trust from the hardware and verifies far less of the OS than a proper Android verified boot device does. TPMs are also nothing compared to the dedicated secure elements used in a Pixel or similar either, and TPMs are rarely used for much by default regardless, while you'll see them used in Android and iOS for multiple things.
Desktop operating systems are flawed since they lack the security practices or a complete implementation of them. For example, a ton of Windows' best security features are opt-in so they don't get used, apps are not sandboxed and are over-privileged, often made in unsafe languages, most users' main accounts are also the administrator by default (and is the source of most Windows security issues), and much more. Windows wants to go adminless and move to Rust (great!) and also add sandboxing for Win32 apps (currently opt-in, not great!) but there's still a long way to go. Windows laptops with a half-done attempt at real secure boot instead of BS are Secured Core certified, but only an attempt doesn't really amount to anything.
MacOS on an ARM Mac does a great job in some of these things but there's room for improvement. Linux-based operating systems do this the worst as oftentimes they completely don't do some of the things listed or do it very badly. Linux works on Android because they barely use any of the same software a desktop distribution does, they also have an enforced SELinux policy among other additional work to secure it that the desktop operating systems do not. ChromeOS does the best of all of these for the same reasons as Android but of course being a desktop OS it doesn't do everything perfectly, but MacOS prevails with hardware.
This response isn't putting things like privacy-invasive telemetry of the OSes into account but obviously if you want to completely avoid it on a desktop your options are practically miniscule and you should accept some. I also avoided mentioning what GrapheneOS does better than Android here for neutrality but of course we improve on what Android does by a lot. When upstream gets a Desktop Mode there will hopefully be a future where someone could use a GrapheneOS device as a desktop and with VMs to run Linux or Windows apps thanks to hardware accelerated VM support in the newer PIxels.
I have no say in the discussion about using a GrapheneOS device as cold storage by @expatriotic and to be honest I haven't read it when writing this reply.