search

Drive-Trust-Alliance / sedutil

DTA sedutil Self encrypting drive software
603 stars 231 forks source link

Query: TCG Pyrite/Opal/Enterprise and IEEE 2883-2022 #465

Open nickhayhurstdev opened 4 months ago

nickhayhurstdev commented 4 months ago

Hello!

I am seeking some support with regards to following the IEEE 2883-2022 standard for sanitizing storage - within the realms of TCG support.

Firstly, thanks to the Drive Trust Alliance and all included within the project, sedutil is a great solution and works perfectly for me in my environment using Linux.

Secondly, down to the query... IEEE 2883-2022 is a standard for sanitizing storage media. In it's Clear definition, for ATA, SCSI and NVMe devices... it states something akin to the below (quoting where necessary):

  1. ATA - TCG Pyrite SSC 2.0 or Opal SSC 2.0

Quote - "If the LockingSP is owned, then perform the Revert method on AdminSP or LockingSP or the RevertSP method on the AdminSP with the ActiveDataRemovalMechanism column in the DataRemovalMechanism table set to Unmap, Reset Write Pointers, Block Erase or Overwrite Data Erase"

So for Opal SSC Opal SSC on page 18, the Table for the Supported Data Removal Mechanism Feature (Feature Code = 0x0404) is shown clearly and the comment on page 19 states "An Opal Compliant SD shall return the parameters listed in Table 10" of the same page and explains their features.

Looking at the output from sedutil-cli --query /dev/sdX for an Opal compliant device, I am unable to see this information. The question would be are we able to see this information in a standard query, and if so, would it be possible to render this information with the standard discovery data?

The information on for this in IEEE would suggest this can be "set" as in the top quote. Does anyone know if this is the case? :)

  1. SCSI - TCG Pyrite SSC 2.0 and Opal... (do SCSI drives even support Opal?!) 2.0 - I would presume this means Enterprise SSC...

Quote - "If the LockingSP is owned, then perform the Revert method on AdminSP or LockingSP or the RevertSP method on the AdminSP with the ActiveDataRemovalMechanism column in the DataRemovalMechanism table set to Unmap, Reset Write Pointers, Block Erase or Overwrite Data Erase"

So if this is for Enterprise SSC, Enterprise SSC there is no mention of any of the ActiveDataRemovalMechanism column or the DataRemovalMechanism table.

In summary, I am seeking a little bit of clarity, support and knowledge along the way.

I would be happy to take a look over any code to see if I can provide support in return.

Thanks in advance.

r0m30 commented 4 months ago

Hi, A few caveats: I haven't read the pyrite spec. I hate the enterprise spec. Sedutil was written to the 2.0 spec. My perspective is an outsider looking in.

1

The discovery data you reference, for Opal was not part of the spec at the 20 level. Are you getting a one or more unknown segments encountered error message?

2

that's not for enterprise, when you write a spec you have to cover as many outcomes as you can imagine.

I wasn't involved in the update to the spec, so I'm going to have to guess what they were trying to do. It looks like they are trying to assure the data is not recoverable, even if the key is recovered by first destroying all the linkages that tie things together. I'm not sure that's really effective but what do I know?

It's always been my position that if you trust the encryption is done properly, the data should be unrecoverable if the key is destroyed and is not recoverable. That means if locking is enabled a revert should make the data unrecoverable as it destroys the key. My solution for when locking isn't enabled, is to enable it and then do the revert. if you don't trust the encryption, why would you trust the data shredding?

apologies for any typos etc. I'm doing this on my iPad and I do not do well with glass keyboards.