Brainstorming: security hardening tools

[Kixunil]

There are security considerations mildly out of scope of the repository itself (the repository assumes OS is securely installed) but perhaps we could provide additional tools to make things easier for people.

Things that come to mind:

• Make a tool that can unlock LUKS and somehow keep the key in memory for expected reboots but the key is lost in case of unexpected outage. May require special HW
• Make it possible to prove to the admin that he's unlocking genuine system. This is obviously impossible without the above and/or some tamper-detection system. Not sure if it's even valuable (proving would rely on signing key and if signing key is secure from attacker, encryption key s as well).
• Are there OS-level settings that can reasonably improve security without causing UX problems? We could add tooling to make them easier to configure.

[Kixunil]

Key points from OT RaspiBolt discussion:

• Locking LND is not helpful because we sandbox everything properly, lcoked LND may be harmful for security and unlocking is racy. Well this is why auto unlock is the default here anyway, just summing it up for completeness.
• Remote unlocking is also problematic because if an attacker can get physical access he can backdoor the OS (without some kind of secure boot). If an attacker can not get physical access then encryption is not needed.

Additionally, requiring physical access can be annoying and even then covertly compromising a device is not entirely impossible. Perhaps best approach it with paranoia: if the device is off/locked verify checksum of its bootloader, then unlock. Use UPS to reduce false positives. Also possible to automate it with a USB stick with bootloader that does it automatically and the owner carries it around all the time or just has it at a hidden separate place. This still requires the owner to check bios settings to guarantee that it'll boot from that stick only.

[GordianLN]

This is one huge project 😮
Ambitious too, as with the amount of software it encompasses, it will require constant and strict maintenance.
In the OT discussion, by automating my node I meant operationally: "intelligent" autofees and autorebalance based on performance, channel closures and additional channels suggestions based on past statistics, best performing channels leaderboard. First two are probably 65% complete, the following two should only be a boring work of writing the code since they are conceptually simple.
Myself, as the kind of user that I am, I would still prefer an approach like the one of Raspibolt where you install everything granularly (given the updates it does need, I still like to choose a custom combination of software) and yet your repo is a much, much better alternative than Umbrel for all those users who are scared of CLI, as they would get something more solid.

Also, honoured to be the first "foreign" poster 😄

[GordianLN]

I do not have specific background in system security, nor IT is my trade actually, yet my idea is to have a system that will boot, and independently go to operational state, only as long as its hardware has not been tampered with, much like what you exemplified above. This wouldn't require any unlocking, either remote or local.
An administrator would be able to make changes only by logging in, hence even in case of physical theft, an attacker shouldn't be able to compromise the system and get to the funds, in absence of the system password.

[Kixunil]

Thanks for feedback! You can actually very granularly install things here! E.g. apt install lnd will only install bitcoind, btc-rpc-proxy, lnd, lnd-auto-unlock and their respective services. It will not install unneeded things like btcpayserver. If you want very strict control over your setup you can just pass --no-install-recommends to apt (but then you should really know what you're doing). Further, this being Open Source allows you to review and build the software yourself if you want additional confidence.

Yes, the maintenance required is pretty significant, I managed to automate bunch of it but there are still a few pieces missing and some developers don't care much about compatibility. But so far this is working pretty well and the users seem to be satisfied.

If you're willing to share any scripts I'd be interested since I want to provide similar things here at some point and inspiration would be nice.

To actually guarantee the security you want you need some kind of tamper-detecting case for your device. E.g. something like what Orwl has. I'm interested in this too but I consider it a long-term plan. I have a pretty good understanding of how and why such should be designed but it requires lot of work to actually execute.

[GordianLN]

My scripts are an unreleased work in progress, and they are inspired to what 03d is doing on LEGALIZE_MATH repo on a much more advanced stage, while he uses nodejs I code in PHP which is the only advanced language I'm fluent in. It's used to automanage fees and rebalances for now, and I need to complete both functions to my liking; in the future I might add a function to suggest new channels, or channel closures, who knows.

Orwl is extremely expensive, and that's not what I'm after on my raspberry, and yet that looks like going in the right direction

[Kixunil]

Yeah, I didn't mean to suggest buying Orwl, just somehow having similar case. Perhaps it could be possible to DIY.

[GordianLN]

I would love to DIY something like that, and yet I cannot fathom how someone would go about having an encrypted system to boot up to operating status without user input and still being inaccessible unless password is enterede

[Kixunil]

The trick is having the password stored in a safe battery-backed chip that erases it if anything suspicious happens (tampering with the case, low battery ...) If nothing suspicious happened the chip sends the password to the device on boot. The operating system knows that the password entered is not the same as logging in so it doesn't allow use by anyone. (Something similar can be observed in Qubes OS - the password has to be entered twice - for decryption and login.)

[GordianLN]

So the chip would have to be seen, for convenience's sake, as a /dev/sdX mounted as fat or ext4 or whatever, that contains the keyfile after you copy it over, and is mounted via /etc/fstab, and it might auto-erase itself given the conditions you stated, or rather, just erased when a pin is pulled to ground, whatever triggers that grounding... or if there is no power. So maybe plugged in a usb port, you wouldn't need the "autoerase on grounded pin", it might just be any volatile usb pendrive? If it's taken out, bam no more keyfile to be read by an attacker. Downside is that after a power outage that takes out the ups, you'd still need to be there to insert the password and copy over the keyfile.
Or can you think of a workaround for this as well?
I could make a working prorotype out of it... where is such device sold? 😛
Searching for "volatile pendrive" on chinese websites...