Hot answers tagged

162

Modern SSDs use a technology called SED which allows instant erasure. It works by transparently encrypting the entire drive and keeping the key on the drive. ATA Secure Erase is then implemented by wiping the key alone, which renders the rest of the data immediately unreadable (assuming of course that it has been correctly implemented on that particular ...


51

Data destruction is a technique of last resort. If you are planning to use a new storage device, you should use full disk encryption. This allows you to either destroy the encrypted master key or simply forget the password, effectively rendering all data unrecoverable, despite no data actually being wiped. Encryption is a solution for both solid state and ...


13

Tl;dr: Because you can never trust all storage drives to securely wipe themselves, you must plan as if none of your drives can be securely wiped. Placing a dependency on the type of media is not the right way to approach the problem, because the technology is always evolving and changing, and you can never be in 100% control of all IT spend. Remember that ...


11

TL;DR: Do not use hardware encryption on any storage medium no matter whether it's a thumb drive, an HDD, or an SSD! That's a really, really bad idea! Hardware manufacturers are know to have included back doors or just bee very, very stupid about encrypting the data. This goes as far as them just using the same key for all their devices or them letting the ...


9

I don't know why you say that SSDs implement ATA Security Erase improperly. Modern ones implement it using SED (which uses an encryption key known to the drive and stored in non-volatile memory for all your data, allowing it to simply erase the key to instantly render data unreadable), while others mark all sectors for being TRIMed, which should effectively ...


8

It depends on how serious your potential adversary is. If they're just using normal data recovery tools, they won't be able to get at anything without breaking the encryption first. But because of the way SSDs write data, if they're really serious about it, an adversary could disassemble the SSD, bypass its flash translation layer, and get access to blocks ...


8

If you encrypt the disk from the start, when you first start using it, then this isn't a problem. All data you write is encrypted and remapped sectors just lead to encrypted data being remanent on the over-provisioned area. Since the data is encrypted, you can't do anything with it even if you recover it using direct flash reads on a disassembled SSD. ...


7

FileVault was designed to be enabled at any time so you will have no problems encrypting your data after the fact.


7

TL;DR: Full-disk encryption: do not blindly trust what is repeated on the Internet. While there is some technical truth behind these claims they may be incomplete or not match current technologies. Using FDE on SSD disks should be fine. Password managers: there is no technical reason why a password manager would particularly increase SSD wear and tear, so ...


7

The Gutmann method is not useful for any modern device, whether a hard drive or a solid state drive. The fact that you cannot safely wipe a solid state drive due to wear leveling is irrelevant. For any modern hard drive, the best way to erase data on it is to wipe it once with a random pattern. For modern solid state drives, there is no effective way to wipe ...


7

There is a standard to write firmware, the ATA DOWNLOAD_MICROCODE command and the segmented version (transfer protocol 3), but there is no standard for reading the firmware back. As another answer says, some manufacturers may add their own vendor-specific techniques to do so. There is another reliable way to access firmware, but it cannot be done from ...


7

FDE does not need to know anything about overprovisioning. If the partition is encrypted, no plain-text will ever be written anywhere. Blocks reserved for wear leveling will either have un-initialized random data, or encrypted blocks. If you are using the encryption provided by the controller, encryption/decryption occurs inside the controller, so no plain ...


6

Is password hashed before saving to CMOS? Depends on the BIOS. Which hash algorithm is used? Depends on the BIOS. How much storage is dedicated for passwords? Depends on the BIOS. What is about passwords of SSD with AES? Does BIOS save it inside drive (just pass it to device for further processing)? There are a lot of different technologies for ...


5

There's no practical way to inspect the Samsung disk's implementation of AES-256. The same is true of the Bitlocker algorithm, but the software implementation has a few advantages: Microsoft can issue patches if vulnerabilities are discovered Runtime entropy sources are more varied than whatever entropy source is used to encrypt the Samsung disk (remember ...


5

The trim command does not delete the data but simply marks a block of data as currently unused by the OS. It will probably return the block as zero if asked by the OS (although I don't know if this is guaranteed) but internally the data might be still there and could be extracted when accessing the flash storage directly, which is usually not possible by the ...


4

The "solution" is to thoroughly document your imaging procedure, including pictures, chain of custody, write blockers, and so on, so that if/when someone does call your methodology into question, you can defend it. Additionally, you should understand what's happening in an SSD so that if someone asks you about the hashes and why they don't match, you can ...


4

My very first thought: Nobody can be absolutely sure that something has not happened, so the only acceptable answer to your question would be an example. I'm trying to explain my thoughts on why you are very unlikely to get such an example. My argument is inspired by the Drake equation. Let me start with some facts that I think we all agree on (more or ...


3

Because of the way SSDs manage writes, it is not possible to truly verify that data has been erased without modifying the low-level firmware on the drive itself. Below are the features SSDs have (wear leveling and overprovisioning) that make erasing data problematic. If you already know all that, skip down to "ATA Security Erase", which is the only solution ...


3

Recovery is only possible under certain conditions: have an older SSD with no TRIM support or have Windows XP (as it does not support TRIM) or another old OS with no TRIM support or you connect the SSD as an external hard drive via USB port. or AHCI / SATA interfaces are not detected in your old MB - you use legacy mode/IDE mode or you have a RAID 0 setup ...


3

At a stage where the OS cannot do even raw read/writes to the disk you have usually lost as a normal user. Further access is probably only possible by using special functions in the firmware which only the vendors knows, using a special firmware or getting physical access to the chips, depending on the cause of the problem. None of these are available to ...


3

Self Encrypting Drives (SED) Many SSDs offer a "Self Encrypting Drive" feature where the encryption is completely transparent to the operating system. These require that you enter your drive password via a UEFI module and it will unlock the drive. These drives are always encrypting your data, even when SED is not enabled. Enabling SED causes the drive to ...


3

TLDR: Toss 'em. It's the only option. You're asking for a way to ensure that the drives haven't been tampered with by a proven motivated and well-funded state actor. But I can see no way to be sure that the firmware is secure. The best option I can think of is to read the firmware from a potentially-compromised drive and a known-untampered drive of the ...


3

Partially. Full disk encryption, when done through software (e.g. LUKS), means that a compromised storage device will only ever see encrypted data, never decrypted data. It will never have access to the key. However, it would still be able to tamper with data by exploiting the malleability of non-authenticated modes which could potentially be abused to ...


3

There aren't tools readily available to read/dump a SSD firmware (except for a few specific cases). Each manufacturer implements their hardware and firmware however they want. This means there's no standard protocol to dump a SSD firmware. The only way we get a tool to dump a specific vendors firmware is if they release it, or someone reverse engineers one....


3

There's a lot of information here so I'll try to answer directly and clear up anything that's incorrect. First and foremost, BitLocker drive encryption and the built-in encryption on the SED are two mutually exclusive forms of encryption and I would not recommend running both due the likely significant performance impact. If you are using the built-in ...


2

Whether it is an HDD or SSD, FDE will not write unencrypted data to the drive. However on an SSD, there are no guaranty that data that existed before the FDE install are securely erased. (unless you are destroying the drive)


2

In the absence of TRIM, an external USB drive (SSD or not) is pure block storage. It just stores 512 or 4096 byte blocks. It doesn't know about files, let alone whether they're deleted.


2

We have a whole bunch of questions on the difficulty of wiping data from SSD's. You should have a good browse round this site. Simple answer is: By default, SSD's leave more data on the drive. This is because of wear leveling - overwriting doesn't exist as a concept in the same way as on a physical platter. That said, there are known solutions, the most ...


2

Yes, your interpretation is correct. Now, if you suspect that the drive might have been compromised while it was not password protected, you could do a secure erase, which essentially means generating a new DEK, rendering all the previous data unreadable. By "compromised" I mean that the DEK, not being encrypted by a password, was somehow extracted from ...


2

Short answer: Disabling the HPA and resetting the DCO only unhides previously reserved sectors on the drive, and does not involve any secure erasure itself. It only makes these sectors available to the system for later deletion by system tools. Update 2: Now, the remaining thing I need to know is: Does the implementation of DCO and HPA respective ...


Only top voted, non community-wiki answers of a minimum length are eligible