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 > >
