TCG Opal vs Opalite vs Pyrite (Seagate Barracuda / Firecuda 510)

[oom-is]

This isn't an issue per se for SEDutil but more of a buyer beware for anyone buying SSDs and thinking that they're getting full TCG Opal SSC 2.0 functions. Posting it here in the hopes that someone sees it before they buy. I almost picked up one of these drives until I read the fine print.

Short version: Seagate Barracuda 510 (lower capacity) and Firecuda 510 (higher capacity drives) only implement TCG Pyrite according to their documentation. That appears to be true both for SATA and NVMe drives - so yes, they have a PSID on the label, and they support a "secure erase" function, but that's basically all the buyer gets for sure. Might not have pre-boot authorization (PBA) and probably doesn't actually encrypt data.
==> There's a reason why when vendors wanted a minimal subset of Opal (a semi-precious stone) the minimal subset profile got named after Fool's Gold. Caveat emptor.

I've spent a lot of time working with Seagate 2.5" SATA products that had not only full TCG Opal 2.0 functionality but also FIPS 140-2 certification. These product lines have been around for awhile, and from what I can tell were still available in newer models because Bob Thibadeau A/K/A @dtasupport had ensured that the functions were part of the product line over a decade ago back when he was Chief Technologist at Seagate. Which drives supported TCG Opal 2 varied by product number, but each newer version of the product line at least had some SKUs that supported "real" TCG Opal 2.

Fast forward to current time, and Seagate acquired the controller and NAND memory components from third party sources instead of developing their own, and they no longer support full TCG Opal...or even Opalite. #sadness

• Opalite is a subset of Opal that trims certain features to save money. I haven't found an Opalite drive in-the-wild yet with which to test, but I think I can live with the reductions in datastore table size and number of admin/unlock users. For the things SEDutil does at this time, I think Opalite is "good enough" but I can't imagine that it actually saves an OEM that much time or money in implementation.
• Pyrite is a further reduced subset of Opalite. "Pyrite SSC specifies access control over user data without specifying requirements for encryption" and "Support for the MBR Shadowing feature is Optional in Pyrite SSC" meaning that Pyrite drives may or may not support a PBA, and even if they do there's no actual expectation/guarantee that data on the drives is encrypted.

[ChubbyAnt]

Have you seen the SEDutil fork which enables Pyrite and Opalite? Here:

https://github.com/amotin/sedutil

[oom-is]

I wasn't aware of that specifically within @amotin's codebase, and thanks.
I already had FreeBSD support on my list to pull into my fork at some point, but right now I'm not planning to add anything I can't fully test...which is most of why I just went shopping for inexpensive used TCG-E drives. (I also wanted to better understand user initialization e.g. BandMaster on Enterprise drives, which ideally would help with full multiuser support for Opal 2.0 drives.)

[ChubbyAnt]

@oom-is make sure you see this PR: amotin@4ff51c2

[youk]

I just went shopping for inexpensive used TCG-E drives. (I also wanted to better understand user initialization e.g. BandMaster on Enterprise drives, which ideally would help with full multiuser support for Opal 2.0 drives.)

I am wondering how do you manage those TCG Enterprise drives. I have one from HGST and sedutil is of no use for it (one should expect that since sedutil is designated for TCG Opal only).

On the other hand, judging by Seagate 7E8 SATA Product Manual, 4.0 About self-encrypting drives, the scheme and interfaces used in TCG Enterprise drives are basically the same as those utilized by sedutil.

[Artoria2e5]

@youk: the scheme and interfaces used in TCG Enterprise drives are basically the same as those utilized by sedutil.

It makes sense because these things are a subset of Opal. However, the identification is different, so at least the --scan bit needs to know to recognize them. That's what amotin@e8a35ab does.

I guess I will compile the fork some time later, when I really want ot get my secondhand Exos X18 working......

[youk]

@Artoria2e5 I don't seem to have issues with --scan. The drive is recognized and reported as a TCG Enterprise one. However, I can't proceed even with basic operations which involve changing the drive's state. It's not the case with sedutil only. I tried pretty much any tool I was able to find (including Seagate/TCGstorageAPI) and I am always getting NOT_AUTHORIZED. AFAIKS this is because the authentication fails.

I admit it might be some specifics of HGST SEDs. I would appreciate if you could try the above-mentioned TCGstorageAPI (sed_cli) with your Seagate SED. It should work OOTB – at least in theory.