RE: P1619 - non-removable
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 &
Re: P1619 - non-removable
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 chang
RE: P1619 - non-removable
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 - n
Re: P1619 - non-removable
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 wh
RE: P1619 non-removable. Should not be: "Physically secure"
Serge, >> Making it physically impossible to extract a key is VERY expensive It is not only very expensive, but impossible (to make an absolute secure key store). We only attempt to make an attack very expensive. A secure disk drive need not store anything secret in the clear on the platters. A few hundred bits can be securely stored in the electronics in nonvolatile memory. Even better, a random key can be derived from manufacturing deviations (ST Micro's patented process). This key cannot be extracted from a non-working chip (for reasonable costs). If the chip is powered up, it can employ all kind tamper detection, prevention, etc. Having this secure, hidden key, all other keys can be encrypted with that, and stored on the disk platters. This is what FIPS 140-2 requires. But, it is not necessary to store the keys anywhere, even in this encrypted form. Keys can be mixed (like with XOR) with the user passwords and only these encrypted and mixed keys are stored. Examining the platters reveals absolutely no information about the keys (assuming random passwords). >> Seagate's proposal best applies to the case where there is an explicit >> assumption that the disks will never be stolen Just the opposite! The main point is protection of the stored information in the case the disks do get stolen. >> thousands of physical disks with cleartext keys inside every disk If somebody is stupid enough to do that, he deserves the consequences. The proposal nowhere suggests storing keys on the platters. It is trivial and common sense to build security systems, which do not store anything in the clear, on accessible places, so why do you even bring it up? We don't tell users not to write their passwords on the disks, either. >> anything FIPS 140 compliant with a strong CC protection profile is usually >> much much more expensive. These costs are there with or without LRW. If you could extract the key from a working chip, it does not matter if it encrypts in LRW or counter mode. And the keys are not permanently stored in the device by either algorithm. Laszlo > Original Message > Subject: Was: P1619 - non-removable.Should be: "Physically secure" > ? > From: "Serge Plotkin" <[EMAIL PROTECTED]> > Date: Mon, March 27, 2006 5:04 pm > To: "Doug Whiting" <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > I would like to point out that calling Laszlo's proposal "non-removable" > is misleading. I think that "physically secure" is much better. > > Here is the rationale: > Imagine an enterprise with hundreds or even thousands of physical disks > with cleartext keys inside every disk. > Now, once a disk is lost, a key can be extracted and all data can be > read. > (Making it physically impossible to extract a key is VERY expensive, > much more expensive than the cost of a disk). > > So, the way I read it is that Seagate's proposal best applies to the > case where there is an explicit assumption that the disks will never be > stolen. > > But then, if this is the case, then maybe encryption is not the right > tool ? > > By the way, for all those that are claiming that "LRW is expensive", I > would like to point out that making anything FIPS 140 compliant with a > strong CC protection profile is usually much much more expensive. > > -serge plotkin > > -Original Message- > From: stds-p1619@LISTSERV.IEEE.ORG [mailto:[EMAIL PROTECTED] > On Behalf Of Doug Whiting > Sent: Monday, March 27, 2006 1:35 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: P1619 - non-removable > > OK, but, at the least, if the group agrees with your characterization of > LRW being only for removable disks, we should clarify that, or at least > mention it, in the spec. I'm afraid that there > may be a significant disconnect between the group and your assertions. > I'm not saying whether > either is right or wrong -- I'm obviously sympathetic to some of your > issues. But my fear > is that we're sending a confused message here. At least I'm confused > (which isn't unusual > for me :). > > > > -Original Message- > > From: stds-p1619@LISTSERV.IEEE.ORG > > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > > Sent: Monday, March 27, 2006 1:23 PM > > To: [EMAIL PROTECTED] > > Subject: RE: P1619 - non-removable > > > > 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
RE: P1619 - non-removable
OK, but, at the least, if the group agrees with your characterization of LRW being only for removable disks, we should clarify that, or at least mention it, in the spec. I'm afraid that there may be a significant disconnect between the group and your assertions. I'm not saying whether either is right or wrong -- I'm obviously sympathetic to some of your issues. But my fear is that we're sending a confused message here. At least I'm confused (which isn't unusual for me :). > -Original Message- > From: stds-p1619@LISTSERV.IEEE.ORG > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Monday, March 27, 2006 1:23 PM > To: [EMAIL PROTECTED] > Subject: RE: P1619 - non-removable > > 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" <[E
RE: P1619 - non-removable
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
RE: P1619 - non-removable
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- &g
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 >
RE: P1619 - non-removable
> 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 > > o
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 c
RE: P1619 - non-removable
Matt, Thank you for the information. >> The hardware complexity is roughly equivalent to that of LRW The main point of proposing counter mode instead of LRW, is complexity. If GCM is as complex as LRW and does not offer significantly higher security in the considered application field (access controlled non-removable storage) than the plain counter mode, it is better to stay with the cheaper counter mode. The only requirement is that a key must not be reused on different drives. It is automatic with random keys generated in the drive. >> drive appends a 16-byte MAC to each 'record' If there is a strong access control (what you never have with tapes or other removable storage), there is no need for a MAC: nobody is able to change the data, without being detected. In the discussion document I tried to point out, that access control can be replaced by MAC (as it is done in P1619.1). Attaching a MAC to each LBA is possible, but quite wasteful (up to 3% capacity loss). I described a tradeoff, where much less memory is used, with more processing time at write and after authentication, but no read penalty later. MAC is more expensive (in storage area, processing speed and hardware) than access control. You don't normally need both, but MAC has some advantages, too, like somebody could be granted the right to verify data, without enabling him to decrypt it, MAC provides error detection, etc. >> important to make sure the IV is unique It is easy in disk drives. The keys are random in each drive, re/generated in the electronics, which is forever physically attached to the storage medium. Laszlo > Original Message > Subject: RE: P1619 - non-removable > From: "Matt Ball" <[EMAIL PROTECTED]> > Date: Mon, March 27, 2006 12:25 pm > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > 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 &g
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
RE: P1619 - non-removable
Serge, >> using words like "useless" should be done with caution Don't take it out of context. I meant, LRW-AES is not the right solution for non-removable secure storage, if it provides strong access control. Since there were absolutely no response to my request for discussion (despite the promises on the last teleconference), I had to use strong words just to get some response. It worked. >>1. Do you envision FIPS 140 certification for the disk ? Yes >>2. What level ? 3 >>3. CC certification ? Yes >>4. What profile ? No clue. Do you have a suggestion? >>5. Is password-protected key is sufficient ? What are the implications ? Passwords are meant as basic functionality. For higher security, third party solutions could be supported with biometrics, tokens, network access, etc., with mutual authentication with the disk. Simple portable devices are not able to handle more than passwords, but if you think it should go into the standard, we can define some optional challenge-response authentication protocol, like in TCG. Laszlo > -------- Original Message > Subject: RE: P1619 - non-removable > From: "Serge Plotkin" <[EMAIL PROTECTED]> > Date: Fri, March 24, 2006 11:58 pm > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, "SISWG" <[EMAIL PROTECTED]> > > Laszlo, > > The document that you have submitted can be used as a "position > document" to start a discussion. You should be patient, since the > discussion will take a lot of time, mostly because many of the WG > members will strongly disagree with many of the points made in the > document. Also, using words like "useless" should be done with caution, > since this rarely leads to productive discussions. > > To initiate a more productive discussion, let me raise several > questions: > > 1. Do you envision FIPS 140 certification for the disk ? > 2. What level ? > 3. CC certification ? > 4. What profile ? > 5. Is password-protected key is sufficient ? What are the implications ? > > These are only some of the questions, but we need to start somewhere. > > -serge plotkin > > -Original Message- > From: stds-p1619@LISTSERV.IEEE.ORG [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Friday, March 24, 2006 8:12 PM > To: SISWG > Subject: RE: P1619 - non-removable > > Shai, > > I did not repeat in the email everything, what I wrote in the discussion > document, only the conclusion. If you have access control, you don't > need tweaking any more (as Serge put it: to provide some protection > against copy-and-paste attacks), therefore, half of the hardware (or > the running time in software) can be saved. The extra circuits consume > considerable power, which drain the battery of portable devices, > necessitate better cooling and adds design-, test-, certification- and > manufacturing costs. Even if the saving is only 10 cents per unit, in a > market of 100 million drives it is a significant amount, which would be > wasted if access control is added to LRW. > > But there are other points, too, like the handling of odd size sectors > adds extra delay to the critical path, which forces us to use faster > clocks, which consume more power, etc. We also need the flexibility to > leave some bits in the clear, which is trivial with counter mode but > complicated to add to the current draft. > > When I said the current proposal is useless for non-removable storage, I > did not mean it was not secure enough, but that it was unnecessarily > expensive. In a highly competitive market we cannot afford to implement > it. We MUST provide access control, so LRW is out of question. This > means, the overwhelming majority of secure storage applications will > not use P1619, if it stays as it is now. > > Adding counter mode and a paragraph about access control, which could be > left unspecified, is not very hard. I am surprised to encounter such a > resistance. But I am even more surprised, that nobody was even willing > to discuss alternatives, or possible implementation or security > problems I might have overlooked. > > Laszlo > > > Original Message > > Subject: Re: P1619 - non-removable > > From: Shai Halevi <[EMAIL PROTECTED]> > > Date: Fri, March 24, 2006 9:56 pm > > To: SISWG <[EMAIL PROTECTED]> > > > > Unfortunately I could not attend the last meeting, but my > understanding > > of the decision there was that no more changes to the draft will be > made > > before it is sent to IEEE. Was I wrong? (As far as I understand, the > > IEEE process does allow more changes to the document before the vote >
RE: P1619 - non-removable
Shai, I did not repeat in the email everything, what I wrote in the discussion document, only the conclusion. If you have access control, you don't need tweaking any more (as Serge put it: to provide some protection against copy-and-paste attacks), therefore, half of the hardware (or the running time in software) can be saved. The extra circuits consume considerable power, which drain the battery of portable devices, necessitate better cooling and adds design-, test-, certification- and manufacturing costs. Even if the saving is only 10 cents per unit, in a market of 100 million drives it is a significant amount, which would be wasted if access control is added to LRW. But there are other points, too, like the handling of odd size sectors adds extra delay to the critical path, which forces us to use faster clocks, which consume more power, etc. We also need the flexibility to leave some bits in the clear, which is trivial with counter mode but complicated to add to the current draft. When I said the current proposal is useless for non-removable storage, I did not mean it was not secure enough, but that it was unnecessarily expensive. In a highly competitive market we cannot afford to implement it. We MUST provide access control, so LRW is out of question. This means, the overwhelming majority of secure storage applications will not use P1619, if it stays as it is now. Adding counter mode and a paragraph about access control, which could be left unspecified, is not very hard. I am surprised to encounter such a resistance. But I am even more surprised, that nobody was even willing to discuss alternatives, or possible implementation or security problems I might have overlooked. Laszlo > Original Message > Subject: Re: P1619 - non-removable > From: Shai Halevi <[EMAIL PROTECTED]> > Date: Fri, March 24, 2006 9:56 pm > To: SISWG <[EMAIL PROTECTED]> > > Unfortunately I could not attend the last meeting, but my understanding > of the decision there was that no more changes to the draft will be made > before it is sent to IEEE. Was I wrong? (As far as I understand, the > IEEE process does allow more changes to the document before the vote > but these changes are not really something that comes from the working > group.) > > > [...] 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. > > I strongly disagree (and frankly I don't really believe that even Laszlo > thinks that). It is very clear to me that satisfactory access-control > can be added to systems that use LRW in "overwhelming majority" of > storage applications. > > -- Shai
Re: P1619 - non-removable
Unfortunately I could not attend the last meeting, but my understanding of the decision there was that no more changes to the draft will be made before it is sent to IEEE. Was I wrong? (As far as I understand, the IEEE process does allow more changes to the document before the vote but these changes are not really something that comes from the working group.) [...] 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. I strongly disagree (and frankly I don't really believe that even Laszlo thinks that). It is very clear to me that satisfactory access-control can be added to systems that use LRW in "overwhelming majority" of storage applications. -- Shai
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 > From: "Matt Ball" <[EMAIL PROTECTED]> > Date: Fri, March 24, 2006 6:42 pm > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > 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 > > -Original Message- > From: stds-p1619@LISTSERV.IEEE.ORG > [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] > Sent: Friday, March 24, 2006 3:55 PM > To: [EMAIL PROTECTED] > Subject: RE: P1619 - non-removable > > > Rob, > > The background: > > - The current P1619 proposal is not very good for non-removable storage, > which includes hard disks, disks in secure disk enclosures, solid state > memory organized as disk (all with integrated controller), and also > some other cases, with access control. > - I raised the issues in the last teleconference, that the largest > market segment (over 100 million units per year), or the most secure > solutions (secure boxes) are not served with the current P1619 standard > proposal. Therefore, I would vote against it, and publish the list of > problems. > - There was a consensus that we shall create a new proposal for > non-removable storage. If it was ready by 3/24, the WG would consider > including it in the current proposal, which was only submitted for > editorial review to gain some time, although it was far from finished. > - I posted a discussion document with the alternative proposal for > non-removable storage two weeks before the deadline, so we could have > alternative algorithms in time, well discussed, to consider > modifications to the P1619 text. > > Access control is an integral part of the non-removable proposal. It is > not "outside the scope of P1619". We can discuss, how much should go > into the standard. It might be enough to say, that secure access > control has to be provided by means, not specified in the current > version of the P1619 standard. Still, we must know that it is possible > for reasonable costs; otherwise we were to standardize something > useless. > > Laszlo > > > > Original Message > > Subject: RE: P1619 - non-removable > > From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > > Date: Fri, March 24, 2006 4:59 pm > > To: <[EMAIL PROTECTED]> > > > > I don't agree with that conclusion. > > > > You described your posting as a "discussion document," not a proposal to > > change P1619. I don't agree with a lot in your document, but discussion > > of passwords/access control seems outside the scope of P1619 so didn't > > think it warranted discussion at this time. Your complaints about LRW > > vs. other modes might be pertinent to P1619, but I assume those are just > > rehashing old debates in the WG (those that led to LRW being selected in > > the first place). > > > > (I missed the February concall, so probably missed some of the > > background for why you posted the document) > > > > -- > > Rob Elliott, [EMAIL PROTECTED] > > Hewlett-Packard Industry Standard Server Storage Advanced
RE: P1619 - non-removable
Rob, The background: - The current P1619 proposal is not very good for non-removable storage, which includes hard disks, disks in secure disk enclosures, solid state memory organized as disk (all with integrated controller), and also some other cases, with access control. - I raised the issues in the last teleconference, that the largest market segment (over 100 million units per year), or the most secure solutions (secure boxes) are not served with the current P1619 standard proposal. Therefore, I would vote against it, and publish the list of problems. - There was a consensus that we shall create a new proposal for non-removable storage. If it was ready by 3/24, the WG would consider including it in the current proposal, which was only submitted for editorial review to gain some time, although it was far from finished. - I posted a discussion document with the alternative proposal for non-removable storage two weeks before the deadline, so we could have alternative algorithms in time, well discussed, to consider modifications to the P1619 text. Access control is an integral part of the non-removable proposal. It is not "outside the scope of P1619". We can discuss, how much should go into the standard. It might be enough to say, that secure access control has to be provided by means, not specified in the current version of the P1619 standard. Still, we must know that it is possible for reasonable costs; otherwise we were to standardize something useless. Laszlo > Original Message ---- > Subject: RE: P1619 - non-removable > From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > Date: Fri, March 24, 2006 4:59 pm > To: <[EMAIL PROTECTED]> > > I don't agree with that conclusion. > > You described your posting as a "discussion document," not a proposal to > change P1619. I don't agree with a lot in your document, but discussion > of passwords/access control seems outside the scope of P1619 so didn't > think it warranted discussion at this time. Your complaints about LRW > vs. other modes might be pertinent to P1619, but I assume those are just > rehashing old debates in the WG (those that led to LRW being selected in > the first place). > > (I missed the February concall, so probably missed some of the > background for why you posted the document) > > -- > Rob Elliott, [EMAIL PROTECTED] > Hewlett-Packard Industry Standard Server Storage Advanced Technology > https://ecardfile.com/id/RobElliott > > > > > > -Original Message- > > From: stds-p1619@listserv.ieee.org > > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > > Sent: Friday, March 24, 2006 3:18 PM > > To: SISWG > > Subject: P1619 - non-removable > > > > Two weeks ago I posted my proposal and discussion document for > > non-removable storage. Since there was no comment in the reflector, I > > assume everybody agrees, and so Serge can edit the draft P1619 text: > > mark the current proposal as "for removable media" and merge my > > proposal, marked as "for non-removable storage". > > > > Laszlo Hars > > Seagate Research > >
RE: P1619 - non-removable
Eric, As we discussed in the last teleconference, the current P1619 proposal is against the business interests of the largest segments of the secure storage industry. I explained that I would have to vote against it, if there were no alternatives. Now you say that the absence of discussion about alternatives is the "indication of limited interest". This limited interest would kill the P1619 standard, and we have to explain to the press, to our employers that more than three years have been wasted. Laszlo > Original Message ---- > Subject: RE: P1619 - non-removable > From: "Eric Hibbard" <[EMAIL PROTECTED]> > Date: Fri, March 24, 2006 5:22 pm > To: <[EMAIL PROTECTED]>, "SISWG" <[EMAIL PROTECTED]> > > Standards typically operate from a position of explicit consensus. The > absence of discussion or engagement is frequently an indication of > limited interest, and therefore, a reason for not including an item. > > In addition, it was my understanding that changes of this nature need to > be voted on after the document returns from the IEEE editor. > > -Eric Hibbard > Hitachi Data Systems > > -Original Message- > From: stds-p1619@listserv.ieee.org [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Friday, March 24, 2006 1:18 PM > To: SISWG > Subject: P1619 - non-removable > > Two weeks ago I posted my proposal and discussion document for > non-removable storage. Since there was no comment in the reflector, I > assume everybody agrees, and so Serge can edit the draft P1619 text: > mark the current proposal as "for removable media" and merge my > proposal, marked as "for non-removable storage". > > Laszlo Hars > Seagate Research
RE: P1619 - non-removable
I don't agree with that conclusion. You described your posting as a "discussion document," not a proposal to change P1619. I don't agree with a lot in your document, but discussion of passwords/access control seems outside the scope of P1619 so didn't think it warranted discussion at this time. Your complaints about LRW vs. other modes might be pertinent to P1619, but I assume those are just rehashing old debates in the WG (those that led to LRW being selected in the first place). (I missed the February concall, so probably missed some of the background for why you posted the document) -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott > -Original Message- > From: stds-p1619@listserv.ieee.org > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Friday, March 24, 2006 3:18 PM > To: SISWG > Subject: P1619 - non-removable > > Two weeks ago I posted my proposal and discussion document for > non-removable storage. Since there was no comment in the reflector, I > assume everybody agrees, and so Serge can edit the draft P1619 text: > mark the current proposal as "for removable media" and merge my > proposal, marked as "for non-removable storage". > > Laszlo Hars > Seagate Research >
