> Do you mean Chapter 8, Attack Scenarios, is not precise, not > complete or incomprehensible? Please suggest improvements, > additions to it. I mean for the LRW stuff. I wasn't commenting on your doc, which is perhaps a good start (but it's less than two pages long). However, there's nowhere I know of that addresses how LRW deals with these (or other) threats.
> What threat do you see? If read access is only provided with > full authentication, or it requires destruction of the drive, > only one snapshot can be taken. In your model, that may be true. But for LRW, I don't know that that is the model we are providing or assuming. My point is, I don't know what model we are assuming. > -----Original Message----- > From: stds-p1619@LISTSERV.IEEE.ORG > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Monday, March 27, 2006 12:02 PM > To: [EMAIL PROTECTED] > Subject: RE: P1619 - non-removable > > Doug, > > >> careful about considering any variant of counter mode for > >> update-in-place storage applications > > What threat do you see? If read access is only provided with > full authentication, or it requires destruction of the drive, > only one snapshot can be taken. > > >> I'm still not quite sure that I fully understand what > threats we are > >> trying to protect against > > Do you mean Chapter 8, Attack Scenarios, is not precise, not > complete or incomprehensible? Please suggest improvements, > additions to it. > > >> we owe the world a careful and coherent threat model document > > Chapter 8 was meant as a draft for it. If it ever gets > cleaned up enough, we can put it in a separate document, but > I thought it could remain a chapter in the Backgrounds document. > > Laszlo > > > -------- Original Message -------- > > Subject: RE: P1619 - non-removable > > From: "Doug Whiting" <[EMAIL PROTECTED]> > > Date: Mon, March 27, 2006 1:13 pm > > To: "Matt Ball" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, > > <[EMAIL PROTECTED]> > > > > RE: P1619 - non-removable > > > > FWIW, I think we should be extremely careful about > considering any variant of counter mode for update-in-place > storage applications (e.g., disk). While GCM can be used > securely, the GCM IV has to be unique not only across blocks > and vendors, but also across rewrites. Thus, you need a > unique IV stored within the block itself (e.g., a write > counter). So it adds even more overhead to the block. While > this may be acceptable, it must be very explicitly considered > and specified, as a "naive" application of GCM (e.g., IV = > sector number + vendor ID) has serious potential security problems. > > > > But of course all of this gets back somewhat to the threat > model. I'm still not quite sure that I fully understand what > threats we are trying to protect against. While I understand > that a standards document perhaps should specify only "what > to write" and not necessarily the underlying rationale, I > remain uncomfortable with the lack of an accompanying threat > model document (or have I missed it?). Clearly, non-expanding > encryption like LRW would NEVER be recommended by a > cryptographer in a vaccum, but the constraints here are very > tight so we have littte choice. Thus, I think we owe the > world a careful and coherent threat model document, or the > industry will misunderstand and possibly misuse the > standard(s) that we produce. > > > > > > > > From: stds-p1619@LISTSERV.IEEE.ORG on behalf of Matt Ball > > Sent: Mon 3/27/2006 9:25 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: P1619 - non-removable > > > > > > > > > > I'm resending this message because it was rejected by the e-mail > > server. I noticed that this has happened to other people as well. > > Here is an error message that Jim forwarded to me after the last > > meeting: > > > > The enclosed message, found in the STDS-P1619 > mailbox and shown under the spool > > ID 2510543 in the system log, has been identified > as a possible delivery error > > notice for the following reason: "Sender:", > "From:" or "Reply-To:" field > > pointing to the list has been found in mail body. > > > > I suspect that it's necessary to delete instances of > certain strings > > within the message body. I've gone through and deleted all > instances > > of the string 'From:' in hopes that this won't get bounced. > > > > -Matt > > > > -----Original Message----- > > ***** Matt Ball > > Sent: Monday, March 27, 2006 9:27 AM > > To: 'laszlo'; [EMAIL PROTECTED] > > Subject: RE: P1619 - non-removable > > > > > > Hi Lazlo, > > > > I recommended the GCM mode of P1619.1 because it would also > be well- > > suited to a hard disk implementation. Although the scope > for P1619.1 > > states that it is "an architecture for protection of data in > > variable-length block storage devices", the solution is equally > > applicable to fixed-block storage devices such as disk drives. > > > > The only requirement for a 1619.1-compliant disk drive is that the > > drive appends a 16-byte MAC to each 'record'. Since many > disk drives > > already have provisions for supporting a CRC, it would not be too > > difficult to replace this with a cryptographically secure Message > > Authentication Code. > > > > GCM mode in particular would be an excellent solution for a disk > > drive. The hardware complexity is roughly equivalent to > that of LRW > > (one AES-encr block, and one 128-bit Galois multiplier). > > > > Here are a couple of other useful features for GCM: > > - Uses a 128-bit message authentication code (MAC) > > - Uses counter (CTR) mode encryption, allowing any size for > the plaintext > > and ciphertext. > > - Allows Additional Authenticated Data (AAD), which is included > > in the MAC computation, but is not encrypted > > - It is possible to incrementally compute the MAC because of the > > linear nature of the Galois field multiplier. This allows for > > parallel implementations (GCM essentially uses GMAC) > > - NIST is nearly ready to approve GCM mode for FIPS 140-2 > (or FIPS 140-3). > > > > Since most new disk drives will begin support 4096-byte sectors, it > > would be possible to add a 16-byte MAC to each sector without > > incurring too much overhead (overhead = 0.4% for 4096-byte sector). > > > > The only trick with GCM mode is that it is much more > important to make > > sure the IV is unique across different vendors. The > P1619.1-D5 draft > > current mitigates this problem by providing a standard > key-transform > > algorithm, or imposes requirements for an IV that is derived from a > > cryptographically-secure pseudo-random number generator. > > > > See the latest P1619.1-D5 draft for more details. Let me > know if you > > have any other questions! > > > > -Matt > > > > > > -----Original Message----- > > ***** stds-p1619@LISTSERV.IEEE.ORG > > [mailto:[EMAIL PROTECTED] Behalf Of laszlo > > Sent: Friday, March 24, 2006 7:31 PM > > To: [EMAIL PROTECTED] > > Subject: RE: P1619 - non-removable > > > > > > Matt, > > > > >> Have you considered using the GCM mode of P1619.1 for > your disk drives? > > > > We are not involved in the tape business, so I did not pay > attention. > > Could you tell in a nutshell, what are the advantages of > GCM over the > > simple AES counter mode? > > > > >> I can't see any reason to make any more changes to P1619 > at this time. > > > > In the last teleconference I expressed my concerns that the > WG would > > not take the security of non-removable storage seriously. I was > > promised that the WG would fully support it. The last two weeks and > > your comment show the opposite. I only voted for submitting > the draft > > for editorial review, because I believed that alternatives would be > > added to it. I cannot change my cast vote, but it proved to be a > > mistake. I can only repeat, what I have said several times: the > > current proposal is useless for the overwhelming majority of secure > > storage applications. I thought it was a damn good reason > for changing the draft. > > > > Laszlo > > > > > -------- Original Message -------- > > > Subject: RE: P1619 - non-removable > > > ***** "Matt Ball" > > > Date: Fri, March 24, 2006 6:42 pm > > > To: laszlo, stds-p1619 > > > > > > Hi Lazlo, > > > > > > Have you considered using the GCM mode of P1619.1 for > your disk drives? > > > I think it has most or all the features you're looking for. > > > > > > I skimmed through your document, and it looks like > there's a lot of > > > stuff in there that has already been covered by the SATA > spec (like > > > master passwords and such), or will likely be covered by > the Trusted > > > Computing Group (user authentication and access control). > > > These things are beyond the scope of this working group. > > > > > > The other complaints are basically handled by the GCM mode. > > > > > > I can't see any reason to make any more changes to P1619 at this > > > time. > > > > > > -Matt > > > > > >
