Feature request - Plausible Deniability
We need a SHTF backup plan. Use cases are many: robbery at gun point, police raid, stealing node from home etc. What about having an option like in BlueWallet to setup a fake account, with a fake wallet, fake LN channels? I also want to hide my LN transactions, I know is not possible to delete them from history, but in some way to not be visible. This aspect also have to be proposed for RTL and ThunderHub apps. That wallet history in wrong hands could be dangerous. We need ways to protect that.
Thank you for that idea!
This aspect also have to be proposed for RTL and ThunderHub apps.
Please do that yourself.
Use cases are many: robbery at gun point, police raid, stealing node from home etc. What about having an option like in BlueWallet to setup a fake account, with a fake wallet, fake LN channels?
Unfortunately, this would not easily be possible, because if someone would force you to tell the password, that person could check if the password is correct via the SSH login. Having two passwords for the SSH login is AFAIK not possible, because that's how Debian works.
I also want to hide my LN transactions, I know is not possible to delete them from history, but in some way to not be visible.
Even if we could hide them from the dashboard, it seems like the backend (lncli) would still allow seeing them, so we can't really protect data by having an option for that.
I also want to hide my LN transactions, I know is not possible to delete them from history, but in some way to not be visible.
Even if we could hide them from the dashboard, it seems like the backend (lncli) would still allow seeing them, so we can't really protect data by having an option for that.
At least to hide from those that don't know how to look deeply into your node belly...
Thanks! We might consider this in the future, our current focus is making Umbrel more reliable, but we'll look into this in the future (This doesn't mean it'll be implemented though, I'm not the one who decides that).
maybe passphrase wallets might help?
Thanks! We might consider this in the future, our current focus is making Umbrel more reliable, but we'll look into this in the future (This doesn't mean it'll be implemented though, I'm not the one who decides that).
yes, of course, this is not an urgent matter. There are many other aspects to do. Usability first. Later we can have many other features
Thanks for the idea @Darth-Coin. While it's an interesting idea, I don't actually think this attack vector makes much sense to protect against. Let me explain why.
If someone has physical access to your device, they can tamper with it and gain access to it. The solution to this is to not give anyone physical access to your device.
Even if we were to go full paranoia mode and implement full disk encryption and require a password on bootup to decrypt the drive, that doesn't actually achieve much if someone can get physical access to your device. They could just insert a malicious SD card that records the decryption password on next boot, and then come back later to retrieve it and they'll be able to decrypt everything.
This also comes with significant downsides. It means you need to enter the decryption key at boot up for the device to be able to function. This means in the event of a power cut or update that results in your device rebooting, it's offline until you can enter the decryption password. For a server, a device that's supposed to be running 24/7 with minimal downtime, this is not good. Especially when some apps entire security model (Lightning) depend on the device being always online.
Something like this makes sense for a device like a laptop/phone, where you could misplace it, in which case FDE is useful, and where you're always likely to be available when powering on the device.
But for a server, I don't think it makes much sense. You add minimal security, significantly increase the chance of server downtime, and really the assumption we're working under is that your home or wherever you run your device from is a physically secure location.
Does that make sense?
Thanks for detailed answer. Yes I understand that is quite a challenge to achieve this on a node machine like Umbrel with RPi. That's why I asked here, to see what options we have and if we can achieve some level of security. We need to be prepared for all sorts of "attacks", and I think you understand why I asked about that feature. Usually users will have their Umbrel node at home or in a safe place, where some level of direct security exist. My question was more like a SHTF situation:
- SWAT team come into your house and threaten you to reveal your node access
- a robbery with physical attack on you can happen, threaten to reveal your node
- all kind of situations where you are in danger to reveal that info, you need a backup plan.
I am not saying to focus your energy now on this, I know there are many other issues even more important and urgent. But just keep in mind that these scenarios CAN BE REAL and maybe in a future we will have something in place to defend ourselves.
Yeah those are good points.
One way I see that this could work:
- Read only boot disk that contains a minimal OS that loads a web UI and asks for decryption password.
- Main storage device that's read/write but has FDE.
- Read only storage gets booted, prompt user for FDE password via web ui (so works remotely), and then boots the rest of the OS from the read/write storage.
This would be quite a bit of work to implement and require specialised hardware, definitely something we can consider long term but probably not during beta.
@nolim1t yes, you are right... take the example of Jamesson Lopp, do you remember few years ago when he was raided?
Even if we were to go full paranoia mode and implement full disk encryption and require a password on bootup to decrypt the drive, that doesn't actually achieve much if someone can get physical access to your device. They could just insert a malicious SD card that records the decryption password on next boot, and then come back later to retrieve it and they'll be able to decrypt everything.
what is "full paranoia" about full disk encryption? every single computer I touch has full disk encryption, because why would I not want that
coming to your place, instantly figuring out what's on your Pi and how it has to be manipulated, and then returning later is not the most common scenario
most attackers (including the mentioned police raiders) would show up and take what's there in the moment
https://gitlab.com/cryptsetup/cryptsetup looks interesting for this