Re: [qubes-users] SSD and safety.
PS - don't experiment with erasing drives on your daily driver. the drive is going to do what you asked it to do, no matter, say, whether you booted on that drive or not. POOF! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/184f53fc-996c-4658-8cb5-7092201c16a8%40googlegroups.com.
Re: [qubes-users] SSD and safety.
On Wednesday, February 26, 2020 at 3:37:27 PM UTC, Steve Coleman wrote: > > On 2/26/20, ggg...@gmail.com > > wrote: > > > I discovered there is no program to clear an SSD. > > If you are using an Opal 2 compliant SSD and had created an encrypted > range before formatting your partition then all that data disappears > instantly when you reset the SSD. The one requirement is the SSD drive > must be functional in oder to reset it, and it won't matter much if > there are unuseable blocks or file corruption as all the bits on the > drive, good or bad, get flipped all at once. > ... > On the label of the Opal 2 SSD drive there would be a long hex PSID > number printed on it, and if you supply that # to the sedutil-cli > command: > > # sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MYPSID /dev/sdc > > then everything previously stored on that drive becomes unrecoverable [Many users of Qubes aren't too keen on relying on the black-box/closed-source hardware encryption that comes on SED SSDs - can they trust it? They can't review the code/implementation. There have been in-depth analysis showing issues with both design as well as implementations with many devices. Their points are valid. However, I don't want to get into a long digression on the pros/cons.] In addition to what Steve said about ranges or PSID revert, most tcg opal devices support utilizing the same hardware crypto engine for "CLASS 0" encryption, which allows use of the ATA PASSWORD as an alternate unlocking scheme. This generally allows suspend if, say, your laptop supports the ATA PASSWORD method. Flipside is that generally the complexity of the password data sent to the drive is < 90 bits no matter what you choose. Sometimes substantially less (depends upon BIOS). I don't recommend relying on that for all of your security. If you use it, use LUKS on top of it as well. There's no performance loss, it's transparent (the drive was always doing it anyway, you just chose to lock it). My point, however, is that the ATA Password support under "TCG OPAL CLASS 0" comes with a nice side-benefit Generally, when utilizing TCG OPAL CLASS 0, when you send an ATA SECURE ERASE ENHANCED request to the drive, it actually simply rekeys the hardware crypto engine of the drive. So, if you have non-zero data in a block, then use the ATA SECURE ERASE ENHANCED command and then read the block, it will be scrambled. Send the command again, it's scrambled a different way. So, other than throwing the device into the Sun, my recommendation is always to: 1. Sample (non-zero) data (random block list) on the device. 2. Execute ATA SECURE ERASE ENHANCED. 3. Verify sampled data (same block list) is all scrambled. 4. Execute ATA SECURE ERASE ENHANCED again. 5. Verify sampled data (same block list) is all scrambled again. 6. TRIM the entire drive. 7. Verify sampled data (same block list) is all now zero'd data. 8. Execute ATA SCURE ERASE *NORMAL* (might erase additional data beyond user-readable data, depending upon manufacturer). BTW, if ATA SECURE ERASE ENHANCED does not scramble the data, but the drive supports the ATA SANITIZE command, then use ATA SANITIZE CRYPTO instead, should do the same thing. Brendan PS - paranoid people might say "well, maybe the drive is keeping a list of all keys, hey they are small". Possible. Maybe a flash-thrashing "fill entire drive full of random data" step will help a bit, assuming you're worried about user data left behind and not targeted exfiltration into non-user-accesible flash by a nation-state agency, etc. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/faff5ede-8399-4977-848f-54a3dc35af13%40googlegroups.com.
Re: [qubes-users] SSD and safety.
On 2/26/20, ggg...@gmail.com wrote: > I discovered there is no program to clear an SSD. If you are using an Opal 2 compliant SSD and had created an encrypted range before formatting your partition then all that data disappears instantly when you reset the SSD. The one requirement is the SSD drive must be functional in oder to reset it, and it won't matter much if there are unuseable blocks or file corruption as all the bits on the drive, good or bad, get flipped all at once. Any used, free space, or damaged memory blocks get reset right along with the user data. The entropy values stored internally on that drive get reset so even someone having the prior password can still not regenerate the same encryption key to unlock the drive. All memory blocks that ever had your data will be meaningless 1's and 0's. On the label of the Opal 2 SSD drive there would be a long hex PSID number printed on it, and if you supply that # to the sedutil-cli command: # sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MYPSID /dev/sdc then everything previously stored on that drive becomes unrecoverable in an instant. If you think you need a non-recoverable "panic-button" then the above command will do nicely. Nobody, not even you, is ever going to see that data again. If you also used software based encryption on top of that partition then you can be doublly sure that your personal information can never be recovered. If you install the "Pre-Boot Authentication" (PBA) to unlock the encrypted drive during the initial boot cycle then you have the additional advantage that the boot partition locking range can even be made read-only while the data is at rest. When doing this even an Evil-Maid system admin won't be messing with your system. Just remember to make it writable again before trying to apply any updates to your boot partition. Note: With enabling these SED capabilities on your primary drive you will likely be giving up laptop "suspend" capability. If you absolutely need to protect your data then this is a fair trade-off since the suspended memory image would be far too dangerous to leave laying around anyway. A hot-plug attack is the achillies heel to an Opal drive, so powering down is important anyway. https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive https://github.com/Drive-Trust-Alliance/sedutil/tree/master/LinuxPBA http://chrisarges.net/2018/02/16/using-sed-encryption-on-disks.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ5FDnj0v3gJFwoaw816PN%2BFkv5nSVF5mmyK4%3D2pS_vYz0r1yw%40mail.gmail.com.
[qubes-users] SSD and safety.
Some months back I was going to send a computer in repair. I discovered there is no program to clear an SSD. Some years ago I was reading about how an SSD did wear leveling, and recovered from errors. The article claimed that often the SSD came with more memory than was listed. If, in the course of normal operations if found a bad section, it would somehow mark that area for "Do Not See or Use" and use the extra, secret memory space to do the work that was for the disabled section. I am guessing it is just that in normal operations for Qubes OS, such trivia does not matter. Don't let the evil power groups get their hands on the SSD. Then the potential loss of data is pretty small. Unless the SSD firmware can be tricked out in some way. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/17be83bf-042b-41eb-8f1d-c9b2774928c1%40googlegroups.com.
