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