Re: Threat Model
Jim Hughes wrote:
> The T10 protection profile is more towards allowing the application to
> put this extra check data on the sector to use as a check to see that
> the data is still correct once it is read. It is a fixed format 8 bytes
> containing things like sequence number and a small (16 bit) CRC.
>
> The benefit is that if this check comes back messed up, then reader
> knows that the data does not have integrity.
>
> If we consider the application is adding these 8 bytes and then later
> we are EME (or similar) the entire 520 bytes, if the attacker tampers
> with the data then the 8 byte check will be garbage and the reader
> knows this.
>
> The points along the way (between the host and the encryptor) can check
> the 8 bytes for validity, and the points after the encryptor just
> passes the bits.
>
> This is more coverage than just adding an 8 byte integrity field
> because it does not protect between the encryptor and the host, it only
> protects between the encryptor and the disk and back...
>
> Does this make more sense?
There are clearly two simple options:
1. EME-520 (or whatever IEEE choice of sector-wide mode)
2. EME-512 | HMAC-SHA1-8 (or the like)
One advantage of EME-512|HMAC-8 is that it is compatible with both
protection-on and protection-off storage. [Software may not care much,
but HW might like to settle on an EME-XXX width.]
(Sorry, I used "520" and "512" instead of the "r" notation.)
One disadvantage of EME-520 is that it would be slower to check
integrity alone, it seems. (It's nice to trash forgeries before
bothering to decrypt them, too.)
Of course, the suggestion above means that the 'encryptor' is
merely a transform, not a filter; less filling or tastes great?
Other pros/cons?
Don