The right way to deal with this is to set up your system such that you can't turn over customer data because it's encrypted with a key to which only the customer access.
People need to get their head around the back that this is a political problem and requires political solutions.
I think we should try to get from a 4 to 5, even if we can't get all the way to 10 right away. We shouldn't just punt on the problem because it's not possible to have an immediately perfect solution. 4 to 5 might mean using keys that only the customer has access to. 7 through 10 might all be political, sure, but let's keep moving.
You could probably get around one, too, by selling pieces of the system and having the customer use OSS for the rest. That is, sell storage and key dongles while pointing your customer to front end software. The same way they used to sell crushed grapes during prohibition.
If the provider doesn't encrypt anything (which is the case with end-to-end encryption), then it doesn't have to hand over anything.
In theory that judge is supposed to make sure the law is being followed. My impression, though, is that some judges have a much more expansive view of government power than I think is warranted.
France? Much worse history on encryption than the US.
Germany? Officially better, but the intelligence services have been revealed to be essentially ignoring German law when it gets in the way of working with their US counterparts.
And so on and so forth.
Governments can be limited by legal constructs. Non-governmental actors, or government actors from other jurisdictions, cannot.
Crypto and legislative reform are mutually reinforcing bulwarks.
https://en.wikipedia.org/wiki/Windows_10#Privacy_and_data_co...
or:
https://en.wikipedia.org/wiki/Skype#Security_and_privacy
(I agree that it is good that Microsoft makes this move now.)
Microsoft has simply discovered that a previous business strategy - monopolistic embrace, extend and extinguish-is no longer a good one in today's open, networked world. Hence they have moved to new strategies which are more palatable to the tech community. Slightly late, but still in time to remain relevant.
Mostly, I'm referring to Ballmer.
c.f. Lavabit and "Reflections on Trusting Trust"
Even if the perfect technical solution existed, it wouldn't fix this problem.
To really protect the right to free speech we need both technical tools that are easy for everyone to verify, and a society who believes laws banning encryption are worthless.
Anything short of that is a risk that we flop into a state that is afraid of words.
People think there's no point to hardware drive encryption, because they look at it wrong; they think it's meant to protect your data in the same way that OS-level user-passphrase-derived-master-key drive encryption is. But it's not about "unlocking" the drive at all; it's really about this exact command, where you can change the key and thus, in an instant, permanently garble all the data on the drive.
(It's is also extremely necessary if you want computer refurbishers to be able to reuse SSDs. Trying to "securely overwrite" all the blocks on an SSD is both impossible at an OS level—some blocks are just unaddressible overprovisioned blocks that only come online when other blocks fail—and devastating at a physical level: the write multiplication of running e.g. DBaN on an SSD would completely burn out the disk. Overwriting the key, meanwhile, is a single write.)
This technique isn't just for SSDs. Something similar can be used with normal hard disks. Just store the true key as metadata on a hard disk. Erase the few sectors of metadata and the disk is no longer readable.
Apple's FileVault 2 does something like this. https://www.lightbluetouchpaper.org/2012/08/06/analysis-of-f...
How do we know that the firmware is actually erasing the block containing the encryption key?
Maybe it just leaves the block/key intact and alters the NVRAM key-address to point to another block or key-location, resulting in a history of every key used on the storage device.
In which case no matter how many times the device was secure-erased a well-equipped adversary could have ways to extract previous keys, either whilst the device is 'online' via undocumented commands, or whilst 'offline' with dedicated equipment.
The same 'destroy-the-key-not-the-data' procedure can be used from the user-controlled software level - Linux with LUKS/dm_crypt uses the same approach via the LUKS header, which can also be 'detached' - only stored on a different (possibly removable) device entirely.
As a bonus it is secure even against malicious (snooping) drive firmware since only encrypted data is seen by the I/O controller and storage device.
With drive-level encryption, the drive effectively acts as its own TPM: the drive's encryption keys never leave the drive (and there's no API to ask for them), so—excepting drives that allow their firmware to be upgraded—there's no possibility of some other untrusted component of your system pulling off a record of the drive keys for later offline recovery.
The best procedure is to combine the two, of course. There's no added cost to disk-firmware-level encryption, since each disk-block is going through a rather complex transformation anyway to protect it from the vagaries of flash array storage. And CPU time for doing OS-level encryption is cheap. Turning both on—and telling the OS to secure-erase its key before telling the disk to secure-wipe—protects you from both attackers.
---
If, for some reason, you only have one or the other available to you, though, I'd honestly prefer the disk-firmware-level encryption, with a foreign-made drive. (This is going to be a bit of a tangent.)
Both CPUs and disks can do encryption. Both CPUs and disks can keep the key locked inside themselves, basically acting as TPMs. And both CPUs and disks can have been suborned at the design or manufacturing stage by a state actor.
My main choices of CPU (Intel, AMD, ARM), regardless of where they end up being manufactured, were all designed by either US or British firms—that is, firms within the jurisdiction of the Five Eyes SIGINT-sharing agreement. I have many choices of disks, though, and many of those options are both designed and manufactured outside of that jurisdiction, in e.g. China.
Now, while I might not trust foreign state-level SIGINT any more than domestic, the incentives are different. Even if Chinese drives have suborned firmware, China has no reason to care what's on my drives—because I'm not a Chinese citizen—or any way to force me to hand the drive over—because I'm not physically in China—and no way to make me be in China, because Canada (where I live) has no extradition treaty with China.
Meanwhile, if I relied on a US-designed/manufactured drive, the NSA would care what's on my drives (because Canada's NSA-equivalent, the CSE, asks them to)—and, because Canada and the US do have an extradition treaty, I could get extradited to the US for a US law the NSA says I broke—and I then would be forced to hand the drive over, where the backdoored keys could be extracted and used to recover the drive's contents.
All these arguments are reversed, of course, if you deal in state secrets, or industrial trade-secrets, that foreign state-actors would actively target you for. The military has every reason to only want domestic CPUs and domestic drives. But I'm not a spy, or a diplomat, or a military officer, or an electrical-utility tycoon; I'm just a private citizen. The only country that cares about me, for better or worse, is my own (and, y'know, those other ones that they attend SIGINT club with on Friday nights.)
Easy web access etc don't work without the service provider being able to get the data.