Serge, >> the goal of the standard is to propose a mode of encryption that does not >> expand data and gives some protection against copy and paste operations If the WG agrees with you, the P1619 text should start with this statement. The name of the working group misled me, and many others. We thought we were dealing with "Security in Storage", that is, identifying storage related security issues, attack scenarios, and suggesting counter measures. A name like "Sector Copy and Paste Protection" working group would be more appropriate. Sector copying is not even an issue if we provide access control. If the WG can come up only with a partial solution for the general security goal, then we must state that in the standard: what general attacks we know of, what attacks we try to thwart, what we suggest to do.
Seriously, what value do we (a disk manufacturer) get from a standard offering only "some protection against copy and paste operations", which don't constitute a threat against our products? Hard disks are not interoperable, so the whole key export issue is irrelevant. If somebody wants to manufacture external encryption engines, it is not our concern, not even a competition. I just oppose to name the standard "Security in Storage", if it aims to mitigate one specific threat (copy & paste) against one kind of security products (external encryptors) for one kind of storage devices (disks). Laszlo > -------- Original Message -------- > Subject: RE: "the most important applications" > From: "Serge Plotkin" <[EMAIL PROTECTED]> > Date: Tue, January 17, 2006 6:52 pm > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Cc: "SISWG" <[EMAIL PROTECTED]>, "Shai Halevi" <[EMAIL PROTECTED]> > > Laszlo, > > I do not want to start a flame war, it is too tiresome. I fully agree > with Shai, but would like to add several observations of my own. > > Many of your messages were not answered not because of agreement, but > because of the desire to prevent useless discussions. For example, > discussions of whether the standard applies to flash-based drives in > addition to magnetic media are not productive. > > You seem to want to include too much into the standard. Some of what you > are trying to include is colored by your focus on your company products. > This is understandable, but there are other companies around, with > different products and different security targets. Some is colored by > your desire to be able to say that "if you are compliant, you are > secure", which I think is not achievable in a single standard. > > As I have written several times before, the compliance with the standard > DOES NOT guarantee security of the system. It is only a building block, > nothing more, nothing less. > Explaining all of the security implications is far beyond anything we > can include in the standard. > > Roughly speaking, the goal of the standard is to propose a mode of > encryption that does not expand data and gives some protection against > copy and paste operations from one sector to another. Additional goal is > to specify the parameters that are necessary so that one implementation > will be able to decrypt what was encrypted with another implementation. > Essentially, this is all we can hope to cover. > > There are a million attacks that the LRW-AES does not protect against. > There a million ways to make the system compliant with the standard and > at the same time being completely not secure. Explaining these issues is > outside the scope. All we can do is encourage implementers to use common > sense and to try and comply with FIPS/CC. > > Hope this message will stop the avalanche of mail messages. > > -serge > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, January 17, 2006 3:02 PM > To: Shai Halevi > Cc: SISWG > Subject: RE: "the most important applications" > > >>[magnetic (hard) disk drives] Not necessarily, other technologies can > use it as well. > Jim repeatedly confirmed that P1619 is for spinning magnetic hard disks > only. That is, not optical, solid state, magneto optical, > electrostatic, organic, printed, tape, etc. It is important, because > the assumption made were magnetic hard disk related: fixed size LBA's, > consecutive numbered sectors, size preserving encryption, etc. If you > have any other technology in mind, which shares all these assumptions, > we can add that to the list. > > >>[disk-internal encryptions] legitimate for you to have this viewpoint > The point I made several times is that we have to establish a threat > model. I proposed something: theft and periodic inspection. Nobody > argued with that, nothing was suggested to add or remove. Therefore, > you all seemed to agree, that data inspection and traffic analysis is a > threat. To prevent that, access control is needed, because LRW-AES is > weak in this regard. > > Therefore, without (physical, crypto, logistic...) access control to the > raw data LRW-AES is not to be recommended. Do you agree? If not, we have > to discuss this point. If yes: > > How do you provide physical, logistic access control? It is expensive, > clumsy and consequently it will never be a mass market. These are what > I considered less important applications, because in these situations > you don't even need data encryption: the guard providing access control > also protects the data, or, the data is not vulnerable to traffic > analysis, what you cannot tell for sure. What remained is cryptographic > access control to the raw (encrypted) data. It can only be provided in > the disk drive itself, which also makes logical that the next step, the > encryption, to be implemented in the disk drive, too. > > I explained these earlier, also in the December meeting and in several > of my emails. Up to now, nobody raised an argument, so I assumed we all > agreed on this point. > > >>We are not in the business of evaluating which technology is best > suited for "secure storage" > We provide a tool, and it is natural to tell what it is good for and in > what cases others are better. Without it, at the first successful > attack against a P1619 encrypted storage device the whole standard > looses credibility, and we should feel responsible to the damage, not > having provided a warning to our best knowledge. If all the > implementers were crypto experts, you could say that they should have > assessed the risks, but they will be engineers, without the right > expertise, time and tools. > > >>I'm wholeheartedly opposed to incorporating any of these > value-judgment assertions in the standard. > There is only one value judgment in the paragraph you speak about: "not > recommended" [allowing the transfer of raw encrypted data]. This is the > same issue as above: do you consider data inspection, traffic analysis a > threat? If not, we have to discuss it. If yeas, you should warn the user > about the vulnerability the raw data access opens up. > > In any case, if there will be no mention in the standard (or in an > accompanying document) about the dangers, pitfalls, weaknesses, too, I > will have to vote against it. (I don't want my name or our company's > name associated with a standard, which leads to insecure > implementations, even if they are based on the standard used in the > wrong way.) I don't mind replacing "not recommended" with something > else, saying that a certain implementation would make the system > susceptible to traffic analysis type attacks, when the data can be > repeatedly inspected by an intruder. Since this was going into the > backgrounds chapter, I just felt a shorter warning suffices. > > >>Zero-divisors will typically kill you here. > The tweak value T = K2*I. You only need that the probability of a > repeated T value is negligibly small. (Here you don't even need a ring, > a semigroup is sufficient.) If K2 is invertible, all T values will be > different. A trivial example was an odd K2 in the ring of residues mod > 2^128, which might not be secure, but many others, like the elliptic > curve groups look just fine. > > Laszlo > > > -------- Original Message -------- > > Subject: Re: "the most important applications" > > From: Shai Halevi <[EMAIL PROTECTED]> > > Date: Tue, January 17, 2006 4:07 pm > > To: SISWG <[EMAIL PROTECTED]> > > > > [EMAIL PROTECTED] wrote: > > > ... > > > We came back to my point that in the most important applications, > > > disk-internal encryptions, there is NO interoperability. > > > > Laszlo, it is legitimate for you to have this viewpoint, but we have > to > > be very careful that the standard does not contain any wordings that > > suggest that "the most important applications" are this technology or > > the other. > > > > Accrdingly, I very much object to the following comments (taken from a > > previous post from Jan-15): > > > > > 1.1 (first line) to be added: in magnetic (hard) disk drives. > > > > Not necessarily, other technologies can use it as well. > > > > > ... and external encryption is not best served with this standard. > > > > That's your opinion, others may disagree. There should be nothing in > > the standard to support (or refute) this opinion. We are not in the > > business of evaluating which technology is best suited for "secure > > storage". > > > > > --- (Last paragraph on page 5) The goal of data decryption in > another > > > device cannot be achieved if the standard is implemented in disk > > > drives. Raw (encrypted) data cannot be (must not be allowed to be) > > > moved from one device to another. Reword the second sentence to > > > reflect, that if data is encrypted by a disk-external > implementation of > > > the standard (not recommended because of the possible traffic > analysis), > > > than other compliant external decryption engines could decrypt the > data. > > > But, this goal is of questionable value. Why do we want to promote > an > > > inherently dangerous use of the standard? > > > > I'm wholeheartedly opposed to incorporating any of these > value-judgment > > assertions in the standard. > > > > > And, why do we use this finite field, at all? There are simple > rings, > > > which should work here better. > > > > Not that I know of. Zero-divisors will typically kill you here. > > > > > > -- Shai
