Hard disk encryption without OS access?
-
@JaredBusch said in Hard disk encryption without OS access?:
Define encrypted at rest please. From the flow of your post, I assume it means when the server is shut off.
The data on the drive. The OS will decrypt it when it or an application needs access.
So powered off, yes. Or another OS, like a live boot from usb or CD.
Self Encrypted Drives seem to be the only way to go. We may be be stuck with going to their cloud platform....
-
@JasGot said in Hard disk encryption without OS access?:
Self Encrypted Drives seem to be the only way to go.
Generally, SED are decrypted on boot by the TPM, so booting to a USB will still decrypt the drive.
If not, then there is no way to boot the system functional without a user present.
-
@JasGot said in Hard disk encryption without OS access?:
The data on the drive. The OS will decrypt it when it or an application needs access.
If the OS decrypts it, that's not really encrypted at rest per se because while technically you CAN stop it from being read, it's not really encrypted as it is automatically readable just be being powered on. There's no "working" encryption. Technically it might fool someone, but it meets no test of intent. To a casual intruder, they'd never know it was encrypted, even if the system got powered off.
-
@JasGot said in Hard disk encryption without OS access?:
Self Encrypted Drives seem to be the only way to go. We may be be stuck with going to their cloud platform
Why not do what I said? Seems like a REALLY simple solution that actually solves every aspect of the problem, including intent.
-
@JasGot said in Hard disk encryption without OS access?:
The OS will decrypt it when
it oran application needs access.This is not how anything works. I mean sure, it is what you want, but it is not how anything is actually designed.
-
@JaredBusch said in Hard disk encryption without OS access?:
If not, then there is no way to boot the system functional without a user present.
That would be the intent of any "encrypted at rest" request. When you get that legal requirement, it means either a human or a complex automated system acting like a human (a TFA system, for example) has to be involved to decrypt the data. That's the sole intent of the rule.
It's a bad way to write it, I realize. But the concept of encrypted at rest means human interaction to access, by any useful definition.
Otherwise, all data is encrypted at rest already by the nature of being encoded in ASCII or whatever.
-
@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 oran application needs access.This is not how anything works. I mean sure, it is what you want, but it is not how anything is actually designed.
If it is a database, it has to decrypt it before loading the database. If it is a file (used for a database or whatever) it decrypts it to open it the first time and it is decrypted once open.
-
@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.
-
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?
