If you’re going to talk about encryption, it’s a good idea to discuss the threat model. In this implementation, as far as I can tell, there is a kernel that boots from the unencrypted disk image, without a SecureBoot attestation, and expose an SSH connection for entering the pass phrase, which is then stored in RAM. This means that the encryption can be defeated by anyone who can do any of the following:
Sit on the IP address that the machine normally lives on and use the same SSH server key
Tamper with the the unencrypted (and not integrity protected) disk.
Perform a cold-boot attack on the machine to dump the key from memory.
This means that your threat model is explicitly excluding anyone with physical access to the datacenter and, most probably anyone who has admin access to the datacenter back-plane (which will expose things like console boot, which allows them to set init= in the Linux boot and then replace the thing that asks for the passphrase with something that sends a copy to the attacker).
As far as I can tell, the only thing that this protects you against is someone getting access to the disks after you stop owning the machine. That’s not an unreasonable threat model, given the number of things that have been leaked by folks throwing away hard disks and someone else finding them, but it’s worth articulating.
Once you’ve done that, you realise that the hosting provider is fully in your TCB for confidentiality and integrity and so the comparison point is a fully-managed cloud storage thing. This is where it gets quite interesting. The cost of Azure file stores (I think AWS pricing is roughly the same) is around 3x the cost of this for the same amount of storage, so if this storage server is more than a third full then it probably makes sense (the availability guarantees and data integrity are probably higher for the cloud solution than a self-managed box. This also isn’t including admin costs, on the assumption that this is for personal use.
If you’re going to talk about encryption, it’s a good idea to discuss the threat model. In this implementation, as far as I can tell, there is a kernel that boots from the unencrypted disk image, without a SecureBoot attestation, and expose an SSH connection for entering the pass phrase, which is then stored in RAM. This means that the encryption can be defeated by anyone who can do any of the following:
This means that your threat model is explicitly excluding anyone with physical access to the datacenter and, most probably anyone who has admin access to the datacenter back-plane (which will expose things like console boot, which allows them to set init= in the Linux boot and then replace the thing that asks for the passphrase with something that sends a copy to the attacker).
As far as I can tell, the only thing that this protects you against is someone getting access to the disks after you stop owning the machine. That’s not an unreasonable threat model, given the number of things that have been leaked by folks throwing away hard disks and someone else finding them, but it’s worth articulating.
Once you’ve done that, you realise that the hosting provider is fully in your TCB for confidentiality and integrity and so the comparison point is a fully-managed cloud storage thing. This is where it gets quite interesting. The cost of Azure file stores (I think AWS pricing is roughly the same) is around 3x the cost of this for the same amount of storage, so if this storage server is more than a third full then it probably makes sense (the availability guarantees and data integrity are probably higher for the cloud solution than a self-managed box. This also isn’t including admin costs, on the assumption that this is for personal use.