search

Drive-Trust-Alliance / sedutil

DTA sedutil Self encrypting drive software
611 stars 236 forks source link

is Drive-Trust-Alliance serious about QA ?!?! #445

Open Trikenstein opened 1 year ago

Trikenstein commented 1 year 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?

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.

Blacklands commented 1 year ago

eg. lacking description of the role and usage of SID, Admin1, MSID passwords

Since sedutil is mainly implementing the TCG Opal specification, you can read about those things in the spec. It's an open and public specification, you can find it online.

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.

Trikenstein commented 1 year ago

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.

Trikenstein commented 1 year ago

@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 sedutil-cli work. I thought it was a product of an organization standard. That's what I meant by "NOT at all the representation of an official group nor endorsed by any official company".

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

cranderson commented 8 months ago

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/

cranderson commented 8 months ago

How long that paper from Radboud University will be reposted? Did you try to read it a bit? Understand its contents? It has nothing to do with Opal in general. Do not spread bullshit.

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 Expiration date Oct 31, 2023

cranderson commented 8 months ago

It does have criticisms of the Opal TCG standard

Which criticisms in particular? How are they relevant to the security model of Opal drives?

Apparently you didn't read the paper. Shall I quote it?

"The TCG Opal standard, being specifically designed for the purpose of encryption, addresses this issue. However, it specifies a large feature set, of which the added value is debatable (multiple passwords per range, multiple ranges, see Section II-B for details), in particular, if we take the complexity of correctly implementing such a feature set into account. On top of that, the specification offers no guidance on how the key derivation scheme should be designed that supports this feature set. This lack of guidance combined with many required features is a source of issues, listed below."

partially blames for the poor implementations

Which implementations? What drives are they applicable to? Where can we see the exploits?

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/

The fact remains that SEDs in general are un-auditable

First, this does not make the above paper any more valid. Second, SEDs and Opal are not synonymous. Third, half of the TCG Enterprise drives are FIPS-certified. Are you sure you have a good idea about the things you are talking about?

my opinion should not be relied upon if there is an available alternative.

There are threat models. They govern security policies, not someone's opinion. In addition, the assumption that LUKS means universal availability in not valid. Its availability is marginal.

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"

Maybe that is why this software is abandonware?

Maybe there is no need for ridiculous remarks like that?

Ironically, the "Drive Trust Alliance" cannot even keep their own website secure.

Really? Is this the best you can do criticizing Opal drives?

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.