Talk:Hardware-based full disk encryption

Wrong assumption
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 212.79.110.32 (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:
 * 1) 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.
 * 2) 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.
 * 3) 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. --164.177.113.225 (talk) 12:36, 23 June 2016 (UTC)

I modified this section. Hopefully these comments can now be removed (as no longer current)? RobThinks (talk) 16:28, 26 May 2020 (UTC)

Bad article
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.

--HelgeStenstrom (talk) 08:03, 9 September 2010 (UTC)

Merge with Disk encryption hardware
I propose to merge tthis page with Disk encryption hardware, as they are very much related. —Preceding unsigned comment added by 129.215.90.169 (talk) 11:01, 5 May 2011 (UTC)

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."

&sect; Music Sorter &sect;  (talk) 03:32, 3 September 2011 (UTC)

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.

— Preceding unsigned comment added by 82.152.207.220 (talk) 22:10, 5 September 2011 (UTC)


 * 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. &sect; Music Sorter &sect;  (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:
 * SEDs At Risk

Here is where the PDF is hosted...just realized there is some video too: 71.185.210.175 (talk) 06:20, 4 May 2017 (UTC)
 * Hardware-based Full Disk Encryption (In)Security

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)
 * Anyone want to propose an alternate outline that we can start from with both sides covered? &sect; Music Sorter &sect;  (talk) 18:30, 30 April 2013 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Hardware-based full disk encryption. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://www.webcitation.org/65fUDqdql?url=http://www.trustedcomputinggroup.org/solutions/data_protection to http://www.trustedcomputinggroup.org/solutions/data_protection

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 04:47, 30 October 2017 (UTC)

Remove disk manufactures
As it is now, this article needs to be updated whenever a manufacturer change what it's disk support. I suggest to leave manufacturers out everywhere where it is not required (perhaps only a single manufacturer support something), and then at the end include a section with links to the major disk manufacturers page about how they handle disk encryption. Also, there's a lot assumptions that everyone know all these abbreviations...always write the whole term the first time and with the abbreviation in parentheses after the term, then the term can be used in the rest of the article. If the term is not extremely well known, it should be briefly explained. At the very least it should be made clear if it is a technology, a company, a standard or something else. — Preceding unsigned comment added by 84.55.110.220 (talk) 06:03, 11 June 2018 (UTC)

Merge from Disk encryption hardware
I don't think we need this article about the feature and a separate article about the hardware that implements it. ~Kvng (talk) 19:12, 30 May 2019 (UTC)


 * Support the merger; the two titles seem synonymous. Between Disk encryption, Disk encryption hardware, and Disk encryption software, we will have plenty of pages to cover disk encryption. BenKuykendall (talk) 03:16, 27 December 2019 (UTC)

I disagree - Software Encryption is totally different from Hardware Encryption.n.b. I merged this article with Disk encryption hardware in 2011 RobThinks (talk) 19:58, 27 August 2020 (UTC)

Removal of Article's Issues - at top of page
A major contributor to this article appears to have a close connection with its subject. (May 2017) I believe this issue is misguided as the other extreme is a major contributor appears to know nothing about the subject! So if there are no objections I plan to remove it soon - RobThinks (talk) 22:52, 23 June 2020 (UTC).