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

[Trikenstein]

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)
• The error messages are not explanatory enough (rc = 136 ?!?!)
• The 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.

[Blacklands]

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]

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]

Although I wondered why TCG didn't have any mention of this DTA

Why should it? TCG develops specifications.

One thing then appears clear is "Drive-Trust-Alliance" is NOT at all the representation of an official group

What is "official group"?

nor endorsed by any official company.

What is "endorsed"? What is "official company"? Were you able to google?
About – The Drive Trust Alliance

I suggest that you be less hysterical and not throw your agitation (like "?!?!") at the public.

[Trikenstein]

@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

[youk]

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.

It well might be that some software or firmware doesn't strictly adhere to Opal SSC specification. The specification is low-level and I'm not sure it is without its ambiguities. However, you are wrong if you think it is so overarching that it concerns BIOS or OS. No. As relates to drive management, it is only a protocol on top of SCSI.

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.

I can see that you took the PBA route. Did you try regular unlocking with sedutil-cli? Was it failing too? Current PBA image is reported to have issues with reboot cycle. To begin with, I would try to force warm reboot.

As for Samsung EVO 970 in particular, personally I never had any issue with this drive. Locking/unlocking, PBA, locking ranges, etc. work like a charm. The same goes about other Samsung SSDs which I used.

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.

You are correct that end-user experience with SEDs can be frustrating. However, I don't see this being the result of insufficient collaboration. IMO it's just the lack of interest from any big party in general. Corporations, for example, apparently don't consider Opal SSC a consumer-level technology. The modern version of the spec (2.x) and consumer-grade Opal SEDs have been around for more than a decade. Last 5-6 years – I don't see any significant changes as relates to more smooth experience.

[cranderson]

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/

[youk]

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.

[cranderson]

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

[youk]

It does have criticisms of the Opal TCG standard

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

partially blames for the poor implementations

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

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.

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?

[cranderson]

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.

[youk]

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?

Apparently, you should pay attention to what you are replying to. You were asked about the relevancy of those to Opal (preferably, in your own words).

I have read this rant long ago and it still looks mostly clueless to me:

However, it specifies a large feature set, of which the added value is debatable (multiple passwords per range, multiple ranges)

This is simply clueless statement. Multiple locking ranges allow for:

• Hardware protection of data among multiple users
• Additional hardware protection of highly sensitive data
• Write-protection of partitions which shouldn't be modifiable on a regular basis (ESP, boot partition)

I have no idea where they got "multiple passwords per range" from. There's nothing like this in the specs.

if we take the complexity of correctly implementing such a feature set into account

What exactly was not correctly implemented because of the deemed complexity? Not deriving DEKs from credentials (which the spec mandates to do, BTW)? It's the basics of symmetric encryption and only characterizes the developers of Micron/Marvell firmware.

On top of that, the specification offers no guidance
on how the key derivation scheme should be designed that
supports this feature set.

False. TCG Storage Architecture Core Specification Version 2.01, 5.3.4.1.11:

The key derivation function (KDF) is Concatenation KDF as defined in Section 5.8.1 of NIST SP 800-56A.

The paper has several other clueless statements too:

Additionally, a single password can be assigned permission to unlock multiple ranges

Really? Someone show me the relevant part of the spec.

First, the software running on the host PC controlling the hardware encryption, typically does keep a secret key in RAM, in order to support Suspend-to-RAM (S3)

This is completely irrelevant to the security model TCG SSC is based on. It deliberately doesn't address resuming from sleep, as secure enough implementation of this feature involves support from external system (UEFI). Which doesn't prevent infosec astronauts from creating sedutil forks that store passphrase in RAM, creating an obvious security breach.

In fact, the only TCG SSC criticism in the paper which I consider valid is the lack of reference implementation.

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.

Which issue are you talking about? Stop speaking in vague terms and speak about specific issues and specific vendors.

Moreover, once again: what any of the issues mentioned in the paper have to do with Opal?

• Crucial MX100, MX200 were not deriving DEK from user credential – this is TCG core spec not implemented properly
• Crucial MX300, Sandisk X600 left RDS key unprotected – this is the issue of particular firmware and has nothing to do with TCG/Opal
• Samsung drives – no issues related to TCG/Opal at all

WHAT ALL THIS HAS TO DO WITH OPAL? Do you understand the question?

Microsoft thought it was serious enough to NO LONGER TRUST HARDWARE ENCRYPTION by default in BitLocker:

You should stop inventing headlines for the sake of the argument. It's your claim, not the Microsoft's. For example, one of the related security advisories read as follows:

Microsoft is aware of reports of vulnerabilities in the hardware encryption of certain self-encrypting drives (SEDs). Customers concerned about this issue should consider using the software only encryption provided by BitLocker Drive Encryption.

Which pretty much explains the rationale of the later change. It's unrealistic to make a decision for particular user's drive, so better safe than sorry. Hardware encryption in Bitlocker is still there and can be easily enabled. And Microsoft says nothing about vulnerabilities in Opal, so don't make things up.

Interestingly enough, so much security-concerned Microsoft doesn't mention the fact that Bitlocker with software encryption disregards pre-boot isolation and manipulates encryption keys in OS. But it's no surprise for those who are aware of other reasons for pushing proprietary encryption: vendor lock-in and ease of provisioning as compared to hardware encryption.

and in this case researchers were able to show that the closed-source systems that were developed using the Opal specifications were horrendous.

They were not developed "using the Opal specifications". Those were custom designs, in some parts directly violating the specification. Study the paper already, for God's sake. And vulnerabilities in ATA Security have nothing to do with Opal.

It needs INDEPENDENT third-party verification by ANY interested party.

Sure, to some degree that would ensure secure implementation. But the lack of verification doesn't mean that Opal-conforming implementations are fraught with vulnerabilities – as you suggest, based on a paper which is basically irrelevant to Opal. Even old Samsung drives from the paper weren't found any.

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.

So what? It's a management software. What does it have to do with the security of Opal drives? Let alone there is TrueNAS fork and Opal-aware UEFIs (security-wise, they add zero).

The purpose of the rant about NIST is beyond me. I mentioned NIST in relation to your false claim that "SEDs are un-auditable". TCG Enterprise drives get audited during certification.

You are constantly making straw man arguments like above. Leave this habit if you expect me to continue this discussion. I am not getting anything useful from it already.