The Trusted Computing Group (TCG) published the Opal 2.0 specification for SEDs in Feb 2012 so this isn’t a new topic. However, now that most of the drive manufacturers that supported Opal 1.0 now have, or will soon have, Opal 2.0 drives I have been getting more inquiries about the differences between them.
Fortunately, 1 year and 4 days after the specification was published the TCG Storage Work Group published a FAQ for Opal 2.0. I am not sure why it took so long but as a member of the Storage Work Group I can attest to the fact that that a certain amount of debate and intellectual rigor goes into the review and editing of all documents including the FAQs.
From the TCG FAQs you can read that the Opal 2.0 specification is not backward compatible with the Opal 1.0 specification but that the drive manufacturers may choose to support both standards in the same drive. That means, at least in theory, one could use old Opal management software that was written before Opal 2.0 to manage these new drives.
However, I really don’t think that this is a good idea because:
- Not all Opal drives take this dual support approach
- It is hard to find out if Opal drives support both versions before actually getting one and spending ( wasting) time testing it
- Opal 2.0 is not backward compatible for a good reason. That is, you definitely want to use Opal 2.0 for some drives.
So what is the good reason Opal 2.0 is not backward compatible?
The FAQ writes:
“Q. Why was the backwards incompatibility introduced in Opal SSC v2.00?
A. The Opal SSC v2.00 specification was extended to allow storage devices with physical block size restrictions to be supported.”
Opal is a standard for managing SEDs and is independent of the physical media type used to actually store the data. Back in the day when Opal 1.0 was being designed most drives had spinning platters with magnetic media (Hard Disk Drive – HDD). These drives either had 512 byte physical block sizes which corresponded one to one with the 512 byte Logical Block Address (LBA) presented to the host computer or they had a pretty efficient way of dealing with a 512 byte LBA and 4k or 8K physical storage blocks. Since then Solid State Drives (SSDs) have come on the scene in a big way. These drives also have 4K or 8K or more physical block sizes but due to the underlying nature of the memory used in SSDs it is very inefficient to let the host computer obliviously write data at just any address in any size hunks.
Due to this reason some Opal 2.0 SSDs drives will NOT also support the Opal 1.0 specification and if they did it would be just too slow. The bottom line is that for the end customer to avoid getting embroiled Opal 1.0 vs. Opal 2.0 issues they should just update their Opal management software to a version that supports both transparently. SecureDoc 6.1 released in Nov 2012 supports both.
Opal 2.0 has other new mandatory capabilities but these don’t introduce a backward compatibility. Some of my favorites are:
- Protocol Stack Reset: Enables the computer host software to reset the communication with the Opal drive. Without it sometimes the only way to get out of an ‘Opal hang’ is to power cycle the drive.
- Revert methods (on both the Locking SP and the Admin SP): Supports the use case where the IT administrator can repurpose the drive (crypto erases all the data) without having access to the user’s data.
- DataStore Table: The minimum size of the DataStore table has been increased to 10MB (from 1KB). 1 KB was just too small for this feature to be of much use.
