RE: Threat Model
The intention of the T10 protection information may not come across
accurately from the summary alone. Comments are inserted below.
- Bob
> -----Original Message-----
> From: Donald.R.Beaver@SEAGATE.COM [mailto:Donald.R.Beaver@SEAGATE.COM]
> Sent: Tuesday, April 13, 2004 2:30 PM
> To: Williams, Jim
> Cc: stds-p1619@majordomo.ieee.org
> Subject: RE: Threat Model
>
>
> Hi all,
>
> Jim Williams wrote:
> >Shai Halevi wrote:
>
> >> The easiest thing would be to add a 64-bit
> message-authentication-code
> >> on top of the encryption. Optimizations are possible, of
> course (e.g.,
> >> use some variant of OCB).
> >
> >I was specifically talking about the addition of the 64 bit
> "Block guard"
> >which I believe is under discussion in T11. Perhaps someone
> can be more
> >specific here.
>
> See the excerpt below. The T10 proposal is merely for a CRC
...of only 16 bits, plus 48 bits of other stuff...
> during data transmission, not for explicit persistent storage or
> cryptographic protection.
The basic intention of the T10 protection information is that it is
generated by the application that writes the data, persisted by the storage
until overwritten, and returned unmodified to the reading application for
verification. It is allowed to be checked at points in transit, but the
storage is considered a point in transit, not an end point.
>
> Even though the proposal does claim 'protection information
> is retained,'
> it allows the device to 'recalculate on read back.'
The allowance for recalculation is to permit intermediate storage
virtualization devices to overload a single instance of the protection
information field with both application-to-virtualizer and
virtualizer-to-physical media protection information. It is recognized that
this will lose some of the protection afforded by true writer-to-reader
integrity data.
>
> I suspect that any debate in T10 will include the very strong
> but unstated
> assumption that 'retention' must not cause explicit storage space
> inefficiency.
Actually, there is a very explicit requirement to provide the physical
space: to use protection information, the device must be formatted for it
(see table 30 and many like it in SBC-2 rev 13). Formatting for protection
information unconditionally adds 8 bytes to the length of every block (see
the FMTPINFO bit in the FORMAT UNIT command in SBC-2 rev 13). One
implication may be important to SISWG, though...The community is sometimes
willing to give up space for security.
>
> Obviously this is incompatible with the 64-bit MAC approach.
or at least, totally distinct from it.
>
> Less obviously, the reasoning in T10 will probably not touch
> this future
> issue.
Probably true. It's an interesting debate whether the secured scope of each
block should envelop the T10 protection information, or vice versa.
>
>
> >It seems likely that use of the block guard will become the norm for
> >high end storage. Although, to be transparent, the block guard bits
> >must be encrypted and decrypted along with the data bits, there is
> >a difference. If the block guard bits are incorrect, this will be
> >detected and cause a fatal error. This is unlike the data bits,
> >which if incorrect will be passed to the application without
> checking.
>
> Assuming that T10 were to provide for explicit storage of the 'block
> guard',
> and we could use it for cryptographic protection instead, then I tend
> to agree with Shai's remarks above, IMHO. (Patent
> considerations aside.)
>
> Best,
>
> Don
>
>
> 4.15 Protection information model
>
> 4.15.1 Protection information overview
>
> This data protection model provides for protection of the data while
> it is being transferred between a sender and a receiver. Protection
> information is generated at the application layer and may be checked
> by any object along the I_T_L nexus. Once received, protection
> information is retained (e.g., write to medium, store in non-volatile
> memory, recalculate on read back) by the device server until
> overwritten (e.g., power loss, hard reset, logical unit reset, and I_T
> nexus loss have no effect on the retention of protection information).
>