Hard disk encryption without OS access?
-
When I worked in sovereign trusts we sometimes had to do this and every time required huge discussions because encrypted at rest is such an insanely bad idea generally. Especially for servers.
But the answer was always this... if the system lost power or rebooted for any reason, the concept of encryption at rest required, no ifs, ands or buts, that a human with extremely high level authorization had to decrypt the data because the purpose of encryption at rest was to ensure that using power, OS changes, or reboots could not be used to bypass the encryption. Anything else while meeting the requirements of the English phrase "encrypted at rest" did not meet the engineering requirements in IT of the concept.
It's like redundancy. In English it means two of something. In engineering it means secondary backup mechanisms to protect against primary failure.
In IT, encrypted at rest means human (or similar) interaction.
-
@JaredBusch said in Hard disk encryption without OS access?:
@JasGot said in Hard disk encryption without OS access?:
The OS will decrypt it when it needs access.
This means that the data is basically not encrypted as long as the OS is booted. Also, no system works this way.
Encrypted volumes are unlocked by the OS once and remain unlocked. No system that exists in the normal space works like you are wanting.
He's correct. If it is the hard drive you are thinking of, that decrypts the moment it gets first accessed (meaning mounted.) If it is an OS-encrypted drive, same thing, it decrypts on mount. If you are encrypting file by file, it decrypts the first time it is accessed and stays that way generally until reboot.
"At rest" is when the system is powered down or, maybe, unmounted. That's all.
Encrypted at rest provides nearly zero real world data protection, even in the biggest enterprise spaces protecting trillions of dollars of assets, it borders on being a joke (for servers) due to RAID and other obfuscation functions. It has a time and a place, but the ENTIRETY of its value comes from the requirement of a human to verify a lack of tampering before allowing a system to power on.
-
@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. Set up properly, e.g., encryption startup PIN, among others, definitely provides a lot of benefit and is a defacto standard these days. The issue is that so many do not do it correctly, for the wrong reasons, and with the wrong idea.
An easy way to see it in practice where it works, imagine if everyone's smart phones were not encrypted at rest, they are, which is why authorities have such issue with it (I mean if samsung/apple weren't forced to create back doors for the government).
-
@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.
-
@Obsolesce said in Hard disk encryption without OS access?:
An easy way to see it in practice where it works, imagine if everyone's smart phones were not encrypted at rest, they are, which is why authorities have such issue with it (I mean if samsung/apple weren't forced to create back doors for the government).
Exactly, so you have to do the same with the server. If no human interaction is needed to decrypt, the police or a hacker will get the hardware, turn it on, and never know that you thought it was encrypted. Because at a system level, it's not at all.
-
@Obsolesce said in Hard disk encryption without OS access?:
encrypted at rest is just full disk encryption
That's the easy way, but there are others. Lots and lots of places opt for filesystem, database, or file level encryption. It's all equal as long as you maintain the same decryption methodology.
-
@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.
