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