-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is Drive-Trust-Alliance serious about QA ?!?! #445
Comments
Since But yeah, this software is almost abandonware. I don't think much (or any) development is happening, still. At least not in this main repo. There's a bunch a forks where people (usually single individuals) have been working on some other features. |
Is was fooled by the name "Drive-Trust-Alliance". I thought that it's some kind of implementation arm of the Trusted Computing Group. Although I wondered why TCG didn't have any mention of this DTA. I spent a lots of time going over blogs, this repo, and tried on 2 different machines and NVMe. Still not successful and hard to know what was wrong. One thing then appears clear is "Drive-Trust-Alliance" is NOT at all the representation of an official group nor endorsed by any official company. |
@youk I just tried to setup Self-Encrypting-Drive in Aug 2023. I began to learn from the docs. So anything I read, I took it at face value. There were a lots of docs and concepts to absorb. Reading quickly, I didn't notice the difference between "Trusted Computing Group (TCG) and "Drive-Trust-Alliance" (DTA). And believe it or not, the whole time, I thought it was the same organization. Until when I gave up on SED after two failures to provision two different NVMe of different computers (Intel 7600p pro on Lenovo T580 and Samsung Evo 970 plus on HP z840) Then I wondered why TCG as an organization making standards, would make a an utility with so little support. And in particular with insufficient documentation. That was the moment I realize that maybe TCG and DTA have nothing to do. That what I meant by "I wondered why TCG didn't have any mention of this DTA" Hope you get the context now. During the time I tried to make You asked "What is "endorsed"? What is "official company"? Sorry for the unclear statement iin the question. Let's me propose and analogy, the TCP/IP standards for example, is implemented, supported by hardware manufacturers of network devices. TCP/IP network stack is supported by companies implementing the software part of TCP/IP. A windows machine at home can communicate with a Linux machine on the cloud using totally different hardware with a bunch of network card, switch, router, firewall in between. Naively, I thought that SED would be in similar scenario. ie. The drive, OS, and computer should be able to collaborate transparently on the basis of OPAL 2.0 standards. But my practical experience on two different hardware set told me a totally different picture. It is not working at all and I have spent almost my full week of vacation without any success. From the errors I got, it appears that the different parts (NVMe firmware, sedutil, BIOS of the machine, and maybe the OS as well) don't collaborate strictly on the OPAL 2.0 standards. Leading to failure or non-operation in various steps. For example on the Samsung Evo 970+ on the HP z840. I could get as far as reaching the Pre-Boot-Authentication screen. Entered the key and PBA confirmed the SED is unlock. But then the computer seems to fail to take over from the PBA. It cold reboot and somehow fail to read the NVMe and just hang. Power off was the only option. In summary, sorry if I seem to bash on DTA/sedutil. I didn't know this is a private contribution of a person or a small group of volunteers. Maybe it is stated somewhere but I missed it. There is no obligation for you to fix anything. Once I have realized the fragile nature of the collaboration between different parties in the SED ecosystem to comply harmoniously to OPAL 2.0 standards. I just accept it. Maybe after a few years of maturation, the industry would emerge a stable solution. But for now, at least for me, I give up on SED and used software encryption instead. In my case it's Debian with Linux Unified Key Setup |
LUKS is probably better anyway since it is open source and can be audited. I do not think drive manufacturers' closed-source SED implementations can be trusted given this history: https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/ |
I did read the paper in detail. It does have criticisms of the Opal TCG standard itself which it partially blames for the poor implementations. The fact remains that SEDs in general are un-auditable (except possibly by the extreme means taken by the authors of that paper) and in my opinion should not be relied upon if there is an available alternative. Maybe that is why this software is abandonware? (Yes, I know that ultimately you have to trust the hardware like the CPU, chipset, management engine, etc., but the smaller the footprint you must trust, the better.) Ironically, the "Drive Trust Alliance" cannot even keep their own website secure. https://www.sslchecker.com/sslchecker shows: drivetrust.com |
Apparently you didn't read the paper. Shall I quote it? "The TCG Opal standard, being specifically designed for
https://kb.cert.org/vuls/id/395981/ It looks like the ONLY vendors who took the issue seriously enough to write useful responses to these CVEs are Microsoft and Seagate. Microsoft thought it was serious enough to NO LONGER TRUST HARDWARE ENCRYPTION by default in BitLocker: https://www.howtogeek.com/442114/windows-10s-bitlocker-encryption-no-longer-trusts-your-ssd/
It comes down to who you trust, what their motivations are, and what their track record is. Anyone who wants to and is motivated enough can audit an open source full-disk encryption system (or pay someone else to) like LUKS. The same is not true of closed-source systems, and in this case researchers were able to show that the closed-source systems that were developed using the Opal specifications were horrendous. Have the drive manufacturers improved their firmware since 2018? Who knows...they don't say, and even if they did say would you trust them? It needs INDEPENDENT third-party verification by ANY interested party. "Show me the code." FIPS certification is mainly about using certain approved algorithms and having certain levels of physical tamper-evident properties. It doesn't thoroughly test that they applied those algorithms correctly to make the entire crypto system secure, nor does it test that they do not have severe implementation bugs. https://en.wikipedia.org/wiki/FIPS_140-2 "Steven Marquess has posted a criticism that FIPS 140-2 validation can lead to incentives to keep vulnerabilities and other defects hidden. CMVP can decertify software in which vulnerabilities are found, but it can take a year to re-certify software if defects are found, so companies can be left without a certified product to ship. As an example, Steven Marquess mentions a vulnerability that was found, publicised, and fixed in the FIPS-certified open-source derivative of OpenSSL, with the publication meaning that the OpenSSL derivative was decertified. This decertification hurt companies relying on the OpenSSL-derivative's FIPS certification. By contrast, companies that had renamed and certified a copy of the open-source OpenSSL derivative were not decertified, even though they were basically identical, and did not fix the vulnerability. Steven Marquess therefore argues that the FIPS process inadvertently encourages hiding software's origins, to de-associate it from defects since found in the original, while potentially leaving the certified copy vulnerable"
Those two remarks may have been over-the-top, but the fact remains that this project has not had a source code commit in 2 years, and those were "trivial" commits. The last substantial commit was 3 years ago. |
May I know who is really Drive-Trust-Alliance? Who is writing the
sedutil
program? Do you have a formal process of CI/CD and QA testing?sedutil
is lacking serious documentation (eg. lacking description of the role and usage of SID, Admin1, MSID passwords)sedutil-cli --help
is marred with typos (passwort
,GLobal
)For an organization with the word "Trust" in the name. Which designs a software aimed for security that the entire world Consumer and Enterprise should trust, I would say I am not impressed.
The text was updated successfully, but these errors were encountered: