Whole drive encryption (e.g. TCG Opal) has many drawbacks. Most importantly: it's "whole drive". There's no way to segregate individual user data and still get the benefits of hardware accelerated encryption. For systems that need segregated users (or even something like an unencrypted system volume with a single encrypted user), you need to toss encryption hardware into the upstream IO pipeline for any benefit. Sticking such hardware into the drive is too restrictive, and also raises the cost of each drive.
Furthermore, many chipsets (such as Nehalem and Sandy Bridge) have integrated AES acceleration that offer significant encryption/decryption performance improvements. While encrypted reads/writes will never match the performance of standard reads/writes, Nehalem and SB very much mitigate the performance hit and will still give multi-hundred MB/s throughput on fast SSDs.
If I were Apple, I'd ignore TCG Opal and focus on distributing Nehalem and Sandy Bridge throughout the product lineup. (Or, in the case of iOS devices, toss custom ASICS on the upstream IO pipeline.) Then you can offer true encrypted user segregation (or one encrypted user and an unencrypted OS volume) while still buying standard HDDs and SDDs in bulk. Win-win.
The point of WDE isn't to do fine-grained separation of interests by security level; it's to ensure that a stolen drive yields nothing to an attacker. In a lot of settings, anything less than whole disk encryption sets a process in motion requiring formal disclosures.
Segregated users and accelerated filesystem-level encryption is all good stuff, but even with it, you still need WDE.
No, you don't. Only user data needs to be encrypted. There's no value in encrypting the OS or any apps. None. By definition, they must ship on unencrypted media. Why pay any encryption/decryption cost for information that exists unencrypted?
Assuming a perfect implementation, whole disk encryption costs money and power. Any additional logic on the drives will raise their cost (at no benefit if there's already CPU provided acceleration for the same operations) and will raise power consumption.
The biggest benefit comes from truly segregated, properly and completely encrypted user volumes, where all user-created is always encrypted with their private key at all times. Chrome OS does exactly this, and all OSs should strive to do the same. [1]
Opal solves a single use case. Flexible per-user encryption solves all cases and offers better performance.
You don't understand. You're thinking about this like a systems programmer. The problem is not that anyone cares about your OS binaries. The problem is that it is theoretically possible that customer data could have wound up in /sbin (maybe a script broke and did something stupid as root). Obviously customer data could routinely end up in /. Unless you can promise that there is no customer data in any unencrypted volume --- not assure that it is extremely unlikely, but promise --- then the assumption is going to be that the data was compromised, and stakeholder disclosure has to happen.
WDE solves that problem. If your disk is block-level encrypted and you carry your laptop around powered off, you can make an attestation-level promise that a stolen laptop didn't compromise customer data.
Along with an audit regime that makes sure it's configured properly, WDE allows you to promise that not one block of data on a device is readable without a key.
> You're thinking about this like a systems programmer.
Indeed, yes, I am. My experience in shipping systems used by tens of millions leads to that line of thinking.
> The problem is not that anyone cares about your OS binaries. The problem is that it is theoretically possible that customer data could have wound up in /sbin (maybe a script broke and did something stupid as root). Obviously customer data could routinely end up in /. Unless you can promise that there is no customer data in any unencrypted volume --- not assure that it is extremely unlikely, but promise --- then the assumption is going to be that the data was compromised, and stakeholder disclosure has to happen.
I agree 100%. No one cares about OS or app binaries, as long as those binaries can be cryptographically guaranteed to be unmodified. Given that, no one cares about them.
So, set that aside. Once that's a given, why can't you entirely isolate all user data into individual per-user containers? I can think of numerous ways that can be implemented. Chrome OS has done one such implementation themselves. Hell, union mount an encrypted per-user volume over the unencrypted OS volume. If you don't like that, find some other way. The bottom line: it's software. Implement some way to promise user data is always isolated and encrypted. It can be done and if you think it can't, you're thinking too small.
WDE guarantees one thing – whole disk encryption. That buys you nothing when one single malicious user gains access to that volume. And keep in mind: that malicious user could have been benign and even friendly to begin with.
WDE has nothing to do with malicious users and malware. You really do want a lot of things. There are a myriad of threats. For the threat of "car window cinderblocked and laptop bag stolen out of back seat", what you want is WDE.
WDE is simpler. Even if you wrote the perfect operating system or bootloader that never made a mistake, you'd still fail at the goal. User A could install a keylogger or some other kind of hardware manipulation and use that to steal user B's passphrase or spy on B.
> You really do want per-user data encryption.
What kind of situation where users don't have physical access to the machine is user-segregated on-disk data encryption necessary?
Without WDE, how can you verify that the OS and apps haven't been altered? If a laptop with WDE is left in my control for days and then returned, you know you're still safe. Without WDE, you have to completely wipe the unencrypted portion lest modified apps upload your encrypted user data once the system boots.
Arguably, all binaries comprising the OS and installed apps should be individually signed to ensure they're never modified, even by a malicious user who can access the encrypted disk.
Whole disk encryption guarantees nothing more than your disk is encrypted. On pure single-user systems that are never accessible by other users, that might be fine. The second you allow more that one user, remote or local, to access the disk, you may as well treat the disk as unencrypted. At that point, you need to rely on per-user data encryption and OS and app signature validation to prevent malicious attacks.
Furthermore, many chipsets (such as Nehalem and Sandy Bridge) have integrated AES acceleration that offer significant encryption/decryption performance improvements. While encrypted reads/writes will never match the performance of standard reads/writes, Nehalem and SB very much mitigate the performance hit and will still give multi-hundred MB/s throughput on fast SSDs.
If I were Apple, I'd ignore TCG Opal and focus on distributing Nehalem and Sandy Bridge throughout the product lineup. (Or, in the case of iOS devices, toss custom ASICS on the upstream IO pipeline.) Then you can offer true encrypted user segregation (or one encrypted user and an unencrypted OS volume) while still buying standard HDDs and SDDs in bulk. Win-win.