4 ms·

I wonder if the end result is just going to be mass production and adoption of memory, drives, etc that physically self-destruct. A combination of Apple's Touch

I wonder if the end result is just going to be mass production and adoption of memory, drives, etc that physically self-destruct. A combination of Apple's Touch ID as a fail-deadly switch, and physical destruction would just end this.

derefr 11y ago
One kind-of-nice thing about firmware-level-encrypted SSDs, is that you don't need to overwrite every block on them to "secure wipe" them. When you send the drive an "erase yourself fully" command, it just securely overwrites the sector containing the encryption key with a new one. In terms of getting access to the rest of the data at that point, you've effectively just blown up the drive. 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.)
- Aelinsaar 11y ago
  Ahhh... that's smart.
  - orbitingpluto 11y ago
    Please tell me that was an intentional pun, Agent 99.
    - Aelinsaar 11y ago
      talks into shoe
- PhantomGremlin 11y ago
  it just securely overwrites the sector containing the encryption key with a new one 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-filevault-2-apples-full-disk-encryption/ https://www.lightbluetouchpaper.org/2012/08/06/analysis-of-f...
- iam-TJ 11y ago
  It's turtles all the way down, though. 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.
  - derefr 11y ago
    One might turn that argument around: with OS-level encryption, you're trusting your OS and your CPU (even if it has a TPM) to not include NSA backdoors that will make it divulge its key, or use a different key for encrypting the drive than the one it says it's using. 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.)
userbinator 11y ago
I think that ultimately would lead to a pretty sad situation for future historians, despite how great it may seem for the present. At least we have the trash and various discarded bits of previous civilizations to study and learn from. In the future with everything encrypted and secured as it is today, there might not be much left.
- nitrogen 11y ago
  While it may be sad if history goes back to where it was before modern technology, where most people disappear without a trace, I think it is more important to ensure the world continues to be a viable place in which historians can operate uncensored, and privacy is a very important part of that.
- iamthepieman 11y ago
  In the future they'll be using 65536 bit encryption and an off the shelf GPU will be able to crack 4096 in a reasonable amount of time.

derefr 11y ago

One kind-of-nice thing about firmware-level-encrypted SSDs, is that you don't need to overwrite every block on them to "secure wipe" them. When you send the drive an "erase yourself fully" command, it just securely overwrites the sector containing the encryption key with a new one. In terms of getting access to the rest of the data at that point, you've effectively just blown up the drive. 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.)

Aelinsaar 11y ago
Ahhh... that's smart.
- orbitingpluto 11y ago
  Please tell me that was an intentional pun, Agent 99.
  - Aelinsaar 11y ago
    talks into shoe
PhantomGremlin 11y ago
it just securely overwrites the sector containing the encryption key with a new one 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-filevault-2-apples-full-disk-encryption/ https://www.lightbluetouchpaper.org/2012/08/06/analysis-of-f...
iam-TJ 11y ago
It's turtles all the way down, though. 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.
- derefr 11y ago
  One might turn that argument around: with OS-level encryption, you're trusting your OS and your CPU (even if it has a TPM) to not include NSA backdoors that will make it divulge its key, or use a different key for encrypting the drive than the one it says it's using. 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.)

userbinator 11y ago

I think that ultimately would lead to a pretty sad situation for future historians, despite how great it may seem for the present. At least we have the trash and various discarded bits of previous civilizations to study and learn from. In the future with everything encrypted and secured as it is today, there might not be much left.

nitrogen 11y ago
While it may be sad if history goes back to where it was before modern technology, where most people disappear without a trace, I think it is more important to ensure the world continues to be a viable place in which historians can operate uncensored, and privacy is a very important part of that.
iamthepieman 11y ago
In the future they'll be using 65536 bit encryption and an off the shelf GPU will be able to crack 4096 in a reasonable amount of time.