Hard disk encryption without OS access?
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
@scottalanmiller encrypted at rest is just full disk encryption, like all modern Android and Apple phones do, Filevault for Mac, BitLocker with Windows, FDE like when setting up Ubuntu.
With Android or iPhone, they require human intervention to unlock. So that's exactly what I just described. That's why you can reboot a phone to keep the police from just getting into it, because it can't be decrypted without the human.
Which is what I'm talking about when doing it correctly in the case of PCs and servers.
In the case of servers where you may not want to have a human unlock at startup, the main benefit in that case is drive theft protection (or virtual disk theft), the drive would still be encrypted and protected from access in that case, but pretty much ends there.
-
-
@Obsolesce said in Hard disk encryption without OS access?:
In the case of servers where you may not want to have a human unlock at startup, the main benefit in that case is drive theft protection (or virtual disk theft), the drive would still be encrypted and protected from access in that case, but pretty much ends there.
RAID already protects against that in most cases, as does cloudification. Drive theft is only useful when you can identify the single drive holding the data. Assuming you can't do that, people will steal a whole server. If they steal the drives containing the operating system too, no more encryption.
That's the problem with the OS doing the decryption... in any situation (essentially) where the drive can be stolen that you encrypted, the drive holding the key can be stolen as well. So if RAID isn't considered enough to protect, then neither is that. Same risk.
-
@JasGot said in Hard disk encryption without OS access?:
@JaredBusch said in Hard disk encryption without OS access?:
without a user present.
This is ok.
If a user isn't present, it can't qualify as encrypted. Or something equivalent to a user. This is the same as intentionally not complying. If that's okay, why not just ignore the request altogether?
-
@scottalanmiller said in Hard disk encryption without OS access?:
If they steal the drives containing the operating system too, no more encryption.
Not with full disk encryption, unless you steal the entire server. Full disk encryption is tied to the TPM for example, so you'd need the entire thing to decrypt a hard drive or virtual disk.
-
@scottalanmiller said in Hard disk encryption without OS access?:
How are you taking backups today?
The software vendor does. But VM will give us the ability for our own backup as a safeguard, right?
-
One thing I've seen done as a reasonable no-human system... is that the OS fires up, cannot access the data, calls out to another system that is physically extremely isolated from itself, but is reachable by network. That system does a series of checks to ensure it believes that the system is what it says that it is (such as verifying IP address and such) and then using an encrypted channel reaches out and decrypts the drive.
It's potentially actually safer than having a human verify. It's SO hard to work around or foresee or hack. Humans can be threatened, computers cannot. Stealing two entire systems from two different locations at the exact same time is extremely hard. Easier to put a gun to someone's head, for sure. And it guarantees the checks are done every time, and quickly.
-
@scottalanmiller said in Hard disk encryption without OS access?:
Why not do what I said? Seems like a REALLY simple solution that actually solves every aspect of the problem, including intent.
Because I hadn't read it yet
Hehehe...... -
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
How are you taking backups today?
The software vendor does. But VM will give us the ability for our own backup as a safeguard, right?
Exactly. That's what I was thinking. If you don't have OS access today, and you don't control the app, how do you know that backups are good? I am not a big fan of VM level backups generally, but this is a case where that brute force makes a LOT of sense (to me.)
-
@scottalanmiller said in Hard disk encryption without OS access?:
That would be the intent of any "encrypted at rest" request.
Correct!
-
@Obsolesce said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
If they steal the drives containing the operating system too, no more encryption.
Not with full disk encryption, unless you steal the entire server. Full disk encryption is tied to the TPM for example, so you'd need the entire thing to decrypt a hard drive or virtual disk.
Yes, there's a middle ground where someone has stolen LOTS of drives, but not the server containing them. It would protect against that case which I've never heard happen. It's a contrived case. Anyone going to that level of effort will actually find it easier to grab the server and run rather than to take the time to remove ALL the drives, but not the case that they are already in.
-
@Obsolesce said in Hard disk encryption without OS access?:
Full disk encryption is tied to the TPM for example
Actually it often is not. It CAN be, and that's a nice feature in some cases. BUT, how do you move those drives to another server when you do that (maybe it's easy, but what does the TPM do then?) Assuming drive mobility is a factor, and typically it is, you can't use that kind of full disk encryption, but you are stuck with the normal kind which doesn't use any special hardware. Then you get the assumed portability of the hardware, but just stealing the drives is enough.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@JasGot said in Hard disk encryption without OS access?:
@JaredBusch said in Hard disk encryption without OS access?:
without a user present.
This is ok.
If a user isn't present, it can't qualify as encrypted. Or something equivalent to a user. This is the same as intentionally not complying. If that's okay, why not just ignore the request altogether?
I meant: it's ok if a user has to go and start up the server after an outage.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
Full disk encryption is tied to the TPM for example
Actually it often is not. It CAN be, and that's a nice feature in some cases. BUT, how do you move those drives to another server when you do that (maybe it's easy, but what does the TPM do then?) Assuming drive mobility is a factor, and typically it is, you can't use that kind of full disk encryption, but you are stuck with the normal kind which doesn't use any special hardware. Then you get the assumed portability of the hardware, but just stealing the drives is enough.
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it. Full disk encryption with the key in the keyhole is pointless. I've not heard of any other way of doing it, that wouldn't make sense.
You can easily move drives to another system, in that case you'd need to enter the recovery key to unlock it.
-
Found some more info: https://ubuntu.com/core/docs/uc20/full-disk-encryption
-
@scottalanmiller said in Hard disk encryption without OS access?:
@pmoncho said in Hard disk encryption without OS access?:
If the client controls the server hardware, then SED SSD is a an option.
If they control the hardware, they can virtualize. Just image the system and done.
I'd like to explore this further. What is the best VM host these days?
-
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
@pmoncho said in Hard disk encryption without OS access?:
If the client controls the server hardware, then SED SSD is a an option.
If they control the hardware, they can virtualize. Just image the system and done.
I'd like to explore this further. What is the best VM host these days?
We use ProxMox. KVM is definitely the leader on the hypervisor side. Which package you use for it is up to you. We've had great luck with ProxMox now, though. We are running a LOT of them.
-
@Obsolesce said in Hard disk encryption without OS access?:
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it.
In essentially all cases, you'd want that anyway. Otherwise the fear of someone just stealing your computer remains. They just take the whole thing, turn it on, and attack it anyway that they want since it is decrypted, violating the intent of the rule.
-
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
@JasGot said in Hard disk encryption without OS access?:
@JaredBusch said in Hard disk encryption without OS access?:
without a user present.
This is ok.
If a user isn't present, it can't qualify as encrypted. Or something equivalent to a user. This is the same as intentionally not complying. If that's okay, why not just ignore the request altogether?
I meant: it's ok if a user has to go and start up the server after an outage.
Oh, then it's an easy thing. Lots of options. But I'd still do the VM route first. Solves so many things.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it.
In essentially all cases, you'd want that anyway. Otherwise the fear of someone just stealing your computer remains. They just take the whole thing, turn it on, and attack it anyway that they want since it is decrypted, violating the intent of the rule.
"Just" stealing someone's computer and turning it on to attack away will not work when protected properly, for example, BitLocker full disk encryption + BitLocker startup PIN + proper DMA attack protection (likely the case by default with modern hardware). The TPM simply won't release the key any other way. So you can't really argue against that. Anyone who cares about the security of data on end-user devices will always enforce proper protection.
With server data, similar rules apply. You also want full disk encryption as well as the other protections, so that "just" taking the whole server and attacking away won't work either.
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work. It does work, when used properly and how it was designed to work. When someone says you should use full disk encryption, it's implied that it's done properly. Any security measure can be done improperly and therefore made useless. That a given, so it must be implied done correctly.
