I have a Mochabin which is stupidly over specced for my current needs (Armada 7040 CPU, 1.4GHz x 4 cores, 16GB eMMc and I've plugged in a 1TB SSD to it's SATA 3 port). I did look at using the simple samba share to use the SSD as a NAS drive but I'm a little over cautious and would prefer the SSD to be encrypted in some way in case the Mochabin ever gets nicked. I can't reasonably store it anywhere physically secure, so I wondered if anyone had a suggestion for some other way to run it as a NAS with the data somehow encrypted.
I did find a workaround that would enable me to use bitlocker (let me know if you want to know that workaround, it involves putting a virtual hard disk image on the SSD which is accessed via samba and then encrypted by client os), but I can see some pretty major stability issues with that option.
It may be that some free NAS software could be run in a docker but I can't seem to find a good suggestion that would run within docker on this device (NB. It does seem capable of running some docker images such as home assistant, but struggles with others such as portainer, albeit that could be a PICNIC issue)
If you do the encryption on the client, then it's up to each client what encryption to use.
If you do the encryption on the server, will the keys be stored on the server? Yes: anybody with physical access to the device has access to the data. No: you will have to enter the keys each time the device boots.
depending on what your concern is and whether you have BIOS support, the following may (*) be an option:
if you can set boot up and BIOS access password in BIOS, i.e. only be able to boot if you enter a password, and enter into BIOS with password.
have TPM support
store disk encryption key in TPM
have tpm tool in owrt which can read tpm to fetch the required key and inject it non-interactively into drive mount process.
if disk is stolen its content is protected due to encryption.
if someone hacks into OS as password/key is not stored in the filesystem cannot mount the drive manually.
if the whole setup is stolen cannot boot up without password, and cannot overwrite it via BIOS if BIOS access is password protected too. Replacing the BIOS chip physically is possible though but unlikely it worth, and likely new chip would not work with TPM anyway.
(*) but as the other reply stated, encryption only makes sense if your ciphered content and the key/password is not stored next to each other, you know, write your password to a post-it and put on to your monitor is usually not a good idea. proper (=effective and not business disturbing) security is very complex (and expensive), that's why usually KMS/HSM etc is used to store keys separately from content with proper access control, key rotation policy. and still at the end it is still the same challenge: at some point the password/key is in plain text (in memory for example), how to protect that ...
That really depends on the threat model... if that monitor is at a secure location that might well do (although even then I would put it somewhere where it might not end up accidentally on a photo/selfie). It also depends on the sensitivity of the thing protected by that password...
I assume you know all of this already, and made a sane policy decision for your network, however this thread might be stumbled upon by people just starting to research this issue, so...
A word of caution:
Running a fileserver on a router is quite convenient (as routers tend to be on 24/7 and often are not that power hungry), but if your router falls victim to a hostile takeover so does your shared data (unless the encryption is handled by the clients and the server just deals with blobs, but then the onus is on making sure all clients use encryption and to share the keys between clients). My solution to this conundrum was to only store data on the routers file server that is not really sensitive, like ripped audio/video media. Using VMs or containers can increase the hurdle to jump from taking over the router to taking over the file server, but that comes at its own complexity cost and you need to trust the separation between VMs/containers (but then, nothing ever is perfect so this will already up the security ante considerably).
/off
sorry but i don't see why you addressed your reply to me and disagree with some part of your reply.
OP has a use case, technically there might be a viable solution but i did not suggest in any way or form that s/he should do it. I personally would not do that, you would neither, hence i think (hoped) that tone of my original reply is more of "just because you can be does not mean you should do it". if failed with that, sorry.
further on quoting myself:
i think we agree on this. you actually proved my point:
so not sure why you challenged my post-it analogy. it is a generally approved good practice not to keep the key and the lock next to each other. even if it is a secure location, because if you don't worry if the root password is on a post-it just because it is a "secure" location then why the hell you have a root password first of all.
so no, keeping key and lock side by side is not a good practice, period.
(usually rational for secure location is the exact opposite you've said: you put things in secure location because they have high value for you and want to minimize threat vector and securing access with password for example, is just not enough, you need physical protection as well.)
but i guess we can talk days about how challenging security is.
/on so for future readers, to be clear: think carefully what the value of your data is and if you want to risk it to be exposed to the world.
Thank you for your replies. Yeah security is a head scratcher at times. To clarify, the possible threat I'm trying to mitigate is simply a Billy burglar who grabs the device not really knowing what it is. Maybe he has a techie mate who pulls it apart and finds the SSD inside. If completely unencrypted it would be easy to just plug it into an SSD caddy and grab all the data from it. I wonder if there's a solution that would just involve the Openwrt software encrypting the SSD, and holding the decryption keys so that it could access, and allow trusted devices (which are the only ones I allow to access my "LAN" VLAN) to read/write to that drive without having to hold the decryption keys themselves?
This obviously wouldn't mitigate a risk from someone who could forensically examine such a device to recover the decryption keys, but I'd imagine that kind of threat would only come from state actors/law enforcement, and I don't think I'm on any of those hit lists (that is unless it's suddenly become illegal to be addicted to Openwrt updates - as an aside is there a term for someone who appears to have developed a dependence/obsession on software updates?).
Your thoughts appreciated greatly. And in case anyone was interested in my proposed workaround it was based on this...
Client machines (x2 in my case) running Windows (10 in my case)
SSD shared via Samba and connected as standard network drive for each computer.
Virtual Hard drive file saved in that drive
When mounted on a client machine, use bitlocker to encrypt that virtual hard drive (I've got some instructions somewhere about how this can be done)
Any client machine that then needs access to that drive to use the bitlocker password to unlock that drive (with bitlocker can mark a drive to be automatically unlocked)
My big concern about the above workaround is what happens if 2 machines are connected to that bit-lockered virtual drive at the same time. And/or what happens if the network drops out for whatever reason whilst changes are being made. I think it could be a hot mess.
You might just be right. If I can avoid the withering looks of my better half for long enough to dig through that guide and set it up later I might well be marking that as my solution. Apologies,I feel like I over complicated my requirements in my question and didn't dig around enough for that guide myself, so thanks to all that replied.
So I've started looking at https://openwrt.org/docs/guide-user/storage/disk.encryption and got as far as the "automated" section. Although it doesn't make it explicit I took a guess that I had to create a file in /etc called crypttab which I did by just doing:
root@OpenWrt:~# touch /etc/crypttab
And then I used vi to enter the values I'd got from block info of:
data "1a23b4c5-a123-123a-ab12-a12bc345d6e7" /etc/config/secretkey "crypto_LUKS"
but with the actual UUID of the disk (which in my case I'm trying the UUID of sda3 because instead of encrypting the entire SSD I want to try just one partition so that I can also have some unencrypted partitions.)
What I can't work out from the instructions provided is do I need to update /etc/config/fstab before I do anything with the install-decrypt.sh script? And also do I need to update any of the values in install-decrypt.sh before running the script?
So having had a sleep on things, I've realised that the reason I couldn't get the automation part of it working was because the script wasn't designed to do what I was trying to get it to do (at least that's what I think I've been getting wrong). I was trying to see if it would decrypt the drive after a reboot, whereas I think it's designed to automatically decrypt when you plug an encrypted USB stick back in.
So anyways, I'm thinking that so long as I don't mess anything up too much on that router, it's stable enough that I won't need to reboot often, so I can just stick to manually decrypting. That also means I don't need to keep the key on the same device, thereby enhancing the security right?
Another quick question though. I've formatted that drive as f2fs as opposed to ext4. Does anyone think that'll be an issue or have any opinion on whether there's a preference of format on an encrypted drive?