Gideon, As a second thoughtÂ… 3 weeks have gone, and there was not a single meaningful comment about the standard proposal for non-removable storage, nor about the threat models, constraints, application examples. If a new sub-WG, or a new PAR has to be started, these show that there will be not enough interested members, and there will be no standard for non-removable storage in the near future. I understand that none of the members of the WG cares about it, having different business interests.
I see as our only chance is to include counter mode in the current P1619 text. Also, TCG is waiting for a hard-disk encryption standard, which would never come. (The current P1619 proposal is only an encryption mode, which could be employed for any storage device, but also for anything else. The special requirements, constraints, conditions of the majority of storage devices are not considered.) Somebody from the P1619 WG members wrote something to TCG, what they interpreted as that the technical work for a hard-disk encryption standard had been completed, although it has not even been started. After more than 3 years the P1619 WG was only able to produce a standard proposal with one encryption mode only, which, by itself, does not solve the problems of many secure storage systems. After adding necessary components, LRW-AES turns out to be too complex and expensive, without providing any documented advantages in those systems. Consequently, the P1619 standard text should be amended with the described application of counter mode, for devices, which provide access control to the stored data. If it is put there as an alternative, everybody, who implements LRW-AES still can claim conformance to P1619. There could be some discussions about how much, if anything about the implementation possibilities of access control should go into the text, but so far there were no comments about it in the reflector. Laszlo > -------- Original Message -------- > Subject: Re: P1619 - non-removable > From: "Gideon Avida" <[EMAIL PROTECTED]> > Date: Wed, March 29, 2006 7:36 pm > To: [EMAIL PROTECTED] > > Laszlo, > > > If you read my posting you cited in the bottom of your > > email, you find > > that this was one of the options I listed. But, it > > assumes, that the > > current text clearly identifies the application areas, > > which are > > covered, and which are to be covered by another PAR. > > Can you propose alternate for the text that you think does > not "clearly identifies the application areas" that does > not turn P1619 useless to the companies that are interested > in the standard? > > To me, section 1.1 Scope and Purpose is very clear, > specifically since the very first line is: > The purpose of this document is to specify the LRW-AES > transform, its use for encryption of data at rest... > > I don't think it says anywhere that a storage device must > use LRW-AES to be secure and there is already P1619.1 for > variable-length block storage devices, so the precedent for > alternate standards exits... > > Gideon > > On Wed, 29 Mar 2006 15:04:29 -0700 > [EMAIL PROTECTED] wrote: > > Gideon, > > > > >> Another requirement for use in sector-level storage > > devices is that the encryption transform must be > > length-preserving > > > > I tried to explain in my discussion document, that this > > should not be an > > absolute requirement for secure storage, but it is only a > > property of > > LRW. In a nutshell: any encryption module inserted in the > > data path > > must fully understand all-, and modify many host-device > > messages. There > > are at least two trivial ways to TRANSPARENTLY increase > > the data length: > > make some blocks hidden and lie about the disk size; or > > lie about the > > block size, making some bits in the disk hidden in each > > block. Adding > > or removing the encryption module always requires > > reformatting the > > disk, because the master boot record or the partition > > table will not > > make sense. > > > > >> These two properties allow the use of LRW-AES > > > > No question, LRW-AES can be used. However, in some > > circumstances we can > > create more-secure storage cheaper. P1619 should > > standardize secure > > storage algorithms, suitable for the most common > > applications. > > > > >> P1619 is not the right tool for Seagate > > > > ... neither for secure disk enclosure manufacturers, nor > > for the makers > > of solid state nonvolatile memory organized into sectors, > > nor for host > > software vendors, etc. This is why I proposed to clarify > > this in the > > current P1619 text. It claims to provide a mode of > > operation for secure > > storage in general, but the only mode of operation it > > proposes is > > LRW-AES, which is not optimal for the overwhelming > > majority of secure > > storage applications. > > > > >> Instead of trying to change the base assumptions of > > P1619... > > > > My proposal was also length preserving and block > > parallelizable. > > Nevertheless, if the base assumptions were too > > restrictive or even > > wrong, we had to change them. I only requested > > explanations, why these > > base assumptions were adopted. > > > > >> how about proposing a new PAR (P1619.2?) > > > > If you read my posting you cited in the bottom of your > > email, you find > > that this was one of the options I listed. But, it > > assumes, that the > > current text clearly identifies the application areas, > > which are > > covered, and which are to be covered by another PAR. > > > > Laszlo > > > > > -------- Original Message -------- > > > Subject: Re: P1619 - non-removable > > > From: "Gideon Avida" <[EMAIL PROTECTED]> > > > Date: Wed, March 29, 2006 3:57 pm > > > To: [EMAIL PROTECTED],[EMAIL PROTECTED] > > > > > > Laszlo, > > > > > > P1619/D4 states in the Scope and Purpose section (2nd > > > paragraph): > > > The LRW-AES transform is intended to be used to encrypt > > > data stored on sector-level storage devices, > > > which means that the data to be encrypted or decrypted > > is > > > presented in fixed-size units, and each unit must > > > be processed separately, independently of other data > > units. > > > Another requirement for use in sector-level > > > storage devices is that the encryption transform must > > be > > > length-preserving, meaning that the ciphertext > > > length must equal that of the plaintext. These two > > > properties allow the use of LRW-AES as transparent > > > encryption: an encryption/decryption module can be > > added to > > > an existing system without having to modify > > > the data layout of any of the existing components > > > > > > There is no mention of the media being removeable or > > not. > > > Since Seagate has full control of the media, it is not > > > bound by these restrictions, so P1619 is not the right > > tool > > > for Seagate. Instead of trying to change the base > > > assumptions of P1619, how about proposing a new PAR > > > (P1619.2?) that does not have the transparency > > limitations > > > and includes the assumption of user authentication? > > > > > > Gideon > > > > > > > > > On Mon, 27 Mar 2006 14:22:50 -0700 > > > [EMAIL PROTECTED] wrote: > > > > Doug, > > > > > > > > Clearly, LRW *can* be used for non-removable storage, > > > > too, but for half > > > > the complexity and costs we can provide the same > > > > security, with access > > > > control. In the December meeting I raised this issue > > and > > > > proposed the > > > > split. The WG agreed to support an alternative for > > > > non-removable > > > > storage with access control. It is not our business > > > > interest to > > > > implement an encryption mode more expensive than > > > > necessary, but if > > > > somebody wants to use LRW for hard disks, it is his > > > > decision, we have > > > > nothing against it. It is, however, important for us, > > > > that there is a > > > > less expensive alternative standard algorithm. > > Therefore, > > > > if the P1619 > > > > standard does not contain at least one alternative > > > > encryption mode for > > > > non-removable storage, or does not clearly state, > > that > > > > non-removable > > > > storage would be covered with another standard, we > > cannot > > > > support it. > > > > > > > > Laszlo > > > > > > > > > > > > > -------- Original Message -------- > > > > > Subject: RE: P1619 - non-removable > > > > > From: "Doug Whiting" <[EMAIL PROTECTED]> > > > > > Date: Mon, March 27, 2006 3:58 pm > > > > > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > > > > > > > > > OK, sorry if the subject line is misleading. > > > > > > > > > > Is LRW really intended only for "removable sector > > based > > > > storage > > > > > devices"?? > > > > > That's certainly not what the current draft says! > > > > > Here's a quote from the Intro page: > > > > > > > > > > Introduction > > > > > The purpose of IEEE1619 standard is to describe > > the > > > > method of > > > > > encryption > > > > > for data-at-rest in sector-based devices. In > > > > particular, the > > > > > standard specifies > > > > > the encryption transform and a method for > > > > exporting/importing > > > > > encryption keys > > > > > for compatibility between different > > > > implementations. Encryption of > > > > > data-in-flight > > > > > is not covered by this standard. > > > > > This standard defines the LRW-AES tweakable > > block > > > > cipher and its use > > > > > for > > > > > encryption of sector-based storage. > > > > > > > > > > I never understood the LRW discussions were only > > for > > > > removable media. > > > > > I suspect that many others, including industry > > folks > > > > who have not > > > > > participated > > > > > in the P1619 discussions directly, have the same > > (mis?) > > > > understanding. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: stds-p1619@LISTSERV.IEEE.ORG > > > > > > [mailto:[EMAIL PROTECTED] On Behalf > > Of > > > > [EMAIL PROTECTED] > > > > > > Sent: Monday, March 27, 2006 12:49 PM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: RE: P1619 - non-removable > > > > > > > > > > > > Doug, > > > > > > > > > > > > I fully agree with your critics on LRW-AES, > > although > > > > the subject line > > > > > > (non-removable) is a bit misleading. Landon and I > > > > raised this > > > > > > lack of documentation issue several times in the > > > > reflector, > > > > > > but there seems to be no volunteer to fix the > > > > problem. > > > > > > Seagate, my employer is not involved in the tape > > > > business, > > > > > > nor in removable sector based storage devices > > (where > > > > LRW is > > > > > > applicable), so I cannot justify the time > > necessary > > > > for > > > > > > writing such a document. Somebody with vested > > > > interest in > > > > > > CD/DVD/Zip drives or external encryption boxes, > > > > controllers > > > > > > should take the task to clear things up. > > > > > > > > > > > > There are constraints, which were never > > explained, > > > > like why > > > > > > length preserving is an absolute requirement, why > > one > > > > must > > > > > > not encrypt more than 2^50 bits with one key, > > etc. > > > > These > > > > > > should all go into a Backgrounds document, maybe > > > > together > > > > > > with the threat models, attack scenarios. > > > > > > > > > > > > Laszlo > > > > > > > > > > > > > -------- Original Message -------- > > > > > > > Subject: RE: P1619 - non-removable > > > > > > > From: "Doug Whiting" <[EMAIL PROTECTED]> > > > > > > > Date: Mon, March 27, 2006 3:17 pm > > > > > > > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
