Can I fully encrypt openwrt? It can be an SD card, emmc, embedded memory, or regular SSD/HDD. Some devices have a bios where keys can be stored, in another instance using a key server may be applied, and in the last instance I just want to manually enter the password [using SSH or a live console] after every reboot. My question leans towards is it possible and not is it practical.
Thanks,
I can’t see the point since OpenWrt is run on ram memory. So the only thing you will get is no more security and humongous big boot time without hardware AES crypto acceleration.
Aren't there some files located in the /etc/config/ folder located on whatever medium you installed openwrt on, lets say microSD, that need a little bit of protection like network? /etc/config/network has an option key'' for wireguard I wouldn't want getting out. There's probably a lot of other things in that file I wouldn't want shared but I don't know where else to store my wireguard keys but in that file [while still being able to utilize those links on the router].
Of course this is all offline security, but I can only physically protect the routers where I am. I have other routers using microSD or EMMC that are in an empty house or trailer for weeks at a time with no idea if someone broke in or not because it's not my place, I only own the router. If I (me, not whoever is physically there) can secure that router while the place is vacant using software, I am going to try.
Edit: other files I can potentially think of
/etc/config/ddns would have my ddns service user/pass and server info on it."My question leans towards is it possible and not is it practical."
I will use an I7 with 32GB ram and the fastest SSD I can find if I have to.
Also moving forward, does openwrt support tftp boot or any other network boot method that may be able to remove the storage requirement? tftp has its own issues, I am aware but if I could tftp boot an openwrt image, it'd be a workaround to full disk encryption.
tftp can probably be added, but it's hardly in the stock image. you'll have to compile your own kernel, and create your own image.
I don't think there is any way to do this without customizing OpenWrt's init-scripts. I suppose you could e.g. encrypt some partition (e.g. https://openwrt.org/docs/guide-user/storage/disk.encryption ), set up extroot on it and then modify the init-scripts so that when OpenWrt would mount extroot, it'll first ask for the passphrase needed to decrypt the partition. That means, however, that you need access to the router's UART or keyboard to enter the passphrase.
Saving a passphrase, a certificate or anything similar on the router and using that to decrypt the partition would make the whole exercise pointless.
Can't use SSH until network has been brought up and you need readable config-files to do that.
No, it wouldn't. TFTP isn't encrypted, so it'd be exceedingly trivial for anyone to hijack the connection. Even better: one could just look up the TFTP-settings on the router and copy the image from the TFTP-server as-is.
Is this relevant?
Source: https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/
See above what I said about SSH: you need working network to use SSH.
You could obviously set up a basic configuration and all that and write some custom script that will mount an encrypted partition, reads the configuration files there and applies those on-the-fly, and you could unlock that over SSH, but...well, you'd probably want at least DDNS working and that means saving at least some settings on the router as-is.
Then just use the built-in encryption in the SSD. Will give you full disk encryption without involving the OS at all.
The basic problem here is: if you can't trust the hardware, you can't really fix that in software. All software-solutions build on top of the hardware, so the hardware needs to be secure.
what built-in encryption or SSD is this?
https://wiki.archlinux.org/title/Self-encrypting_drives
https://teejeetech.com/2021/11/28/using-self-encrypting-drives-on-linux/
The problem remain the same, though: you still need a way of entering the passphrase or you store it on the device, rendering the entire exercise pointless.
It is stupid but I have a whistle that noone can really emulate without me and I will whistle to my voice authentication box.
AFAIK, they all support this. At least I haven't found any SSD without it.
Typically the SSD controller has an always-enabled AES engine. The key will be auto-generated by the controller and stored somewhere on the SSD. It could be in part of the mass storage flash banks or in some dedicated NVRAM storage - this is usually not documented. But the brilliant part of it is that the controller will encrypt this key using your "hard disk password" if you set one. Most PC BIOS firmware will allow you to enter this key on boot. If you want to do that remotely, then you have to use hardware with remote management support. Most servers will have such support, via serial and/or ip based KVM.
The SSD controller will use this AES encryption to implement stuff like "secure erase", which can be simplified to "generate new AES key and mark all flash blocks unused". Which is very very fast compared to the alternative of actually storing some random garbage in all the blocks. And it doesn't cause any additional wear. This is one of the reasons the AES engine always is enabled, even when the key is not encrypted.
This is sort of the idea behind disk encryption, isn't it? If you make the system automatically unlock itself then it's not much use.
That's actually how SSDs work by default, when you don't set a password. The data on flash is encrypted. But the key is not (or it is automatically decrypted by the controller - I don't know)
You have completely missed everything I've said. Of course that's the whole point of it, but OP wants to use full-disk encryption on remote devices; they'll need some way of entering the passphrase.
If driving up to the remote location and entering the passphrase manually via a keyboard is acceptable for OP, then a modern UEFI-enabled PC with SSD-encryption enabled is probably the least bad option, but whether that is acceptable or not is up to OP.
Not sure who missed what....
OP said
in the last instance I just want to manually enter the password [using SSH or a live console] after every reboot. My question leans towards is it possible and not is it practical.
I hope we can agree that it is possible to enter a password remotely without having physical access?
You'll obviously need some OOB management access to whatever is requesting the password, but I can't see that this was ruled out as part of the solution.
Cool. Driving up to the remote location and entering the passphrase works in 1 location. Any source on how to make that a reality.
Instance 2 and 3 cant have a user login on the console locally.
Oh, for the love of God. Just a few posts above, I literally wrote "you still need a way of entering the passphrase" -- I didn't say that physical access is the only possibility or anything like that, I explicitly stated "a way"
A PC with a modern UEFI-firmware and quite literally any remotely modern SSD. Then just go into UEFI, set it up to use password for the drive. It's not difficult and the links I gave earlier even have a couple of example screenshots.
Note: enabling a password for the drive is different from enabling a password for UEFI-setup.