Talk:Hardware-based full disk encryption
|WikiProject Computing / Hardware / Security||(Rated Start-class, Mid-importance)|
|WikiProject Cryptography / Computer science||(Rated Start-class, Mid-importance)|
SDD disk sanitization is completely different then regular disks. The claim that SDD can help to reduce amount of time for sanitization is therefore wrong. — Preceding unsigned comment added by 126.96.36.199 (talk) 14:11, 17 December 2014 (UTC)
Another part of the sanitization is slightly off, if not amusing: "There is no way to retrieve data once erased in this way - the keys are self generated randomly so there is no record of them anywhere." - except that:
- There is no perfect randomness, especially on such weak solutions as SEDs, many vulnerabilities were found where the RNG could be narrowed down a lot.
- The keys are either generated by the SED solution itself (if broken, big vulnerability) and forced on the users, or (very often) it is defined by the user's password input (dictionary attack!) with the occasional salting often being poorly implemented.
- The keys are stored in various places depending on the chosen solution: on the disk (= can be recovered), on the circuit board in the EEPROM (= can be recovered too, with the residual charges if the sanitization procedure only overwrite once and/or zeroes the bits, while the encryption of the key is often poor or nonexistent)(first page of googling "eeprom data retention" gives you this).
I'm not saying changing the key on a SED isn't a clever and very efficient way for sanitization, just that it's not a foolproof solution for critical data. A proper sanitization procedure would change the key several times to make it harder to recover the initial key. And if the encryption system is cracked (or partially cracked), then only overwriting over and over to reduce the probability of data remanence remains the only reliable way to sanitize a disk: at the very least, a few "random" passes with each new keys could help mitigate these 2 risks in one go.
So, in my opinion, the article could use some small corrections on the actual reliability of SEDs and the sanitization. At the moment it looks a little like a presentation by a product manager, trying to convince companies to subscribe to their SED transition cycle offer. The information are good, just not as accurate (in terms of exhaustivity) as they could be. --188.8.131.52 (talk) 12:36, 23 June 2016 (UTC)
This article is not written in a style suitable for Wikipedia. It looks more like magazine article based on a couple of press releases. There are a lot of terms used but not explained
Examples: FDE, OPAL, Enterprise standards, attack vector, Enterprise SAS, bridge and chipset, Stonewood, Flagstone.
The article should start with an explanation of what the topic is, not from where it's available. Vendor names should be removed, or moved to a less prominent place at the end of the article. There are disadvantages with hardware-based full disk encryption, but they aren't mentioned. Stated facts needs reference.
Questionable facts: "HDD FDE is available ... via the Trusted Computing Group." Perhaps it wasn't the authors's intention that I have to buy such drives via TCG, but it says so.
Merge with Disk encryption hardware
FDE is only safe with off or hibernated?
I removed this content because it conflicts with my direct experience and it is not sourced. If someone can find a source then we should reconsider it and I can examine why I do not see this in my system.
FDE is only safe when the computer is off or hibernated. When the computer is stolen while it is turned on or suspended, a restart which boots from a USB stick will reveal the data without need for the password. The problem is that these so called warm reboots will not prompt for the HD password, nor the power-on-password for that matter. This is as a security risk. In contrast, software-based encryption will prompt for the password on a warm reboot.
I had added this, and I'm disappointed you removed it. It is consistent with my experience on a Thinkpad laptop both X61 and T61. If you do a restart from the OS, i.e. a warm reboot, you are not prompted for the password THis is indeed what seagate also states. http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=205983
When I researched this issue I came across a discussion stating that making the machine prompt for a password with a warm reboot was technically difficult. Maybe this has been improved on recent machines, or it is unique to seagate discs. I have put it back in because I think it is important, but now I have added the references.
- It is always best to include a source for any material added to any article. I reworded your entry to more specifically support the sources you listed. Frankly I could not find the specific mention on the Seagate site to which you discuss. Maybe you can identify the specific entry on that Q&A page to help us also see it. The Forum talk page is not typically a valid source, but I did not want to get into a edit war with you so I left it in until we resolve the issue on the talk page here. Thanks for your consideration. § Music Sorter § (talk) 09:12, 6 September 2011 (UTC)
I'm too lazy to add anything-- here is a paper talking about defeating FDE while a machine is suspended:
Here is where the PDF is hosted...just realized there is some video too:
Neutral point of view issues
This article seems to me to have several issues with its point of view, specifically:
- It spends a great deal of time talking about the manufacturers of hardware-based full disk encryption (HBFDE) compared to HBFDE itself.
- This is purely my own opinion, but I think it's worth mentioning: the article reads like an advertisement one might find in a magazine, that is written in a style such that it will get mistaken for a magazine article. In other words, it's an advertisement that looks like a Wikipedia article, and gets around looking like an advertisement by mentioning more than one manufacturer.
- There is no discussion of any drawbacks of hardware-based disk encryption. While I am not well-versed enough in the technology to know what those drawbacks would be, I've never come across anything that had zero drawbacks. Does this cost more? Is it more labor-intensive to install? Lioux (talk) 01:12, 17 April 2013 (UTC)
- Agreed. The real problem with hardware encryption is that it's difficult to verify the crypto implementation (for backdoors and other weaknesses) and manufacturers have a track record of getting it wrong. Some relevant sources:      -- intgr [talk] 09:18, 17 April 2013 (UTC)