As explained in the discussion document, direct data access is a weakness, and for reasonable security it has to be only enabled before shipment, or after special authentication. The SCSI encryption proposal (T10/06-172r1) does not seem to be right.
> -------- Original Message -------- > Subject: Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7 > From: [EMAIL PROTECTED] > Date: Fri, May 26, 2006 10:39 am > To: [EMAIL PROTECTED] > Cc: Curtis Anderson <[EMAIL PROTECTED]>, "'Gary Calder'" > <[EMAIL PROTECTED]>, "'Gideon Avida'" <[EMAIL PROTECTED]>, james > hughes <[EMAIL PROTECTED]>, [EMAIL PROTECTED], "'Landon Noll'" > <[EMAIL PROTECTED]>, "'Serge Plotkin'" <[EMAIL PROTECTED]>, > "'SISWG'" <[EMAIL PROTECTED]>, Steven Sletten > <[EMAIL PROTECTED]> > > To me it sounds like the SCSI proposal will not be exportable. > > I believe that customer qualification units have to have the read/write > long commands operating so that the drive can be tested (used to test the > ECC and stuff on the disc). Government will probably require that these > units be tracked, but I don't know. Once the drive is qualified, the > shipping units can not allow the read/write long commands. > > Bascially you get test units to see that everything works, and then you > get real units that are supposed to work the same way. There is a little > bit of trust involved. > > Don > > > > > > james hughes <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > No Phone Info Available > 05/26/2006 07:55 AM > > To > Steven Sletten <[EMAIL PROTECTED]> > cc > james hughes <[EMAIL PROTECTED]>, Curtis Anderson > <[EMAIL PROTECTED]>, [EMAIL PROTECTED], "'Gary > Calder'" <[EMAIL PROTECTED]>, "'Gideon Avida'" <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], "'Landon Noll'" <[EMAIL PROTECTED]>, "'Serge Plotkin'" > <[EMAIL PROTECTED]>, "'SISWG'" <[EMAIL PROTECTED]> > Subject > Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7 > > > > > > > Before rushing to this conclusion, I am interested in discussing this > further. > > Being able to read the ciphertext can be valuable to certify that the > device is indeed encrypting the data... If encryption is or is not > enabled, how would you know unless you can see the ciphertext? > > Jim > > > On May 26, 2006, at 6:56 AM, Steven Sletten wrote: > > > The new SCSI encryption proposal (T10/06-172r1) allows decrypting > > raw (plaintext) data. It also allows reading encrypted data without > > decrypting it. See the text from Table Y4 of the proposal below . > > It may be a good idea to add another mode that prevents reading > > ciphertext or decrypting plaintext. > > > > DECRYPTION MODE field values: > > > > RAW > > Data decryption is disabled. If the device server encounters an > > encrypted block while reading, it shall pass the encrypted block to > > the host without decrypting it. The encrypted block may contain > > data that is not user data. > > > > DECRYPT > > The device server shall decrypt all data that is read from the > > medium in response to a READ(6), READ(16), READ REVERSE(6), READ > > REVERSE(16), or RECOVER BUFFERED DATA command or verified when > > processing a VERIFY(6) or VERIFY(16) command. The data shall be > > decrypted using the algorithm specified in the ALGORITHM INDEX > > field and the key provided in the KEY field. > > > > Steve Sletten > > > > james hughes wrote: > > > >> That in itself can be considered access control. > >> > >> So it is the reading of the ciphertext that needs to be > >> restricted.. This does not say anything about the keys or access > >> control to the plaintext? Comments? > >> > >> On May 25, 2006, at 2:08 PM, Curtis Anderson wrote: > >> > >>> All, > >>> > >>> I'll ask the dumb question: instead of having an encrypting drive > >>> implement cryptographically secure access control mechanisms so that > >>> it can support the "read long" SCSI command, can we just not support > >>> the "read long"? If the only (known) problem is direct access to > >>> the > >>> ciphertext, then "just say no". > >>> > >>> Thanks, > >>> > >>> Curtis > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >>>> Behalf Of james hughes > >>>> Sent: Thursday, May 25, 2006 9:06 AM > >>>> To: [EMAIL PROTECTED] > >>>> Cc: james hughes; Gary Calder; Gideon Avida; [EMAIL PROTECTED]; > >>>> Landon Noll; Serge Plotkin; SISWG > >>>> Subject: Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7 > >>>> > >>>> Very cool explanation! Wow. Very unexpected.Thanks! > >>>> > >>>> > >>>> > >>>> On May 25, 2006, at 6:58 AM, [EMAIL PROTECTED] wrote: > >>>> > >>>>> To get export rights for the Seagate drives, the drive can not > >>>>> allow a way > >>>>> for the encrypted data to be read. > >>>>> > >>>>> If one was to do a normal sector write and then do a read-long > >>>>> command, > >>>>> they could use the drive as a cryptographic co-processor. With > >>>>> tape the > >>>>> encrypted data is also readable, and could be considered a > >>>>> cryptographic > >>>>> co-processor. One difference with tape is that the machines sell > >>>>> in lower > >>>>> quantities and to large customers, for disc drives there is a much > >>>>> higher > >>>>> quantity and it is easy for anyone to get one (go to your local > >>>>> store). > >>>>> > >>>>> An encrypting tape machine is a $10K (I don't know the real > >>>>> numbers) > >>>>> cryptographic co-processor. A disc drive could be a $75 > >>>> > >>>> cryptographic > >>>> > >>>>> co-processor. That is why there are export controls on the disc > >>>>> drive. > >>>>> > >>>>> Don > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> james hughes <[EMAIL PROTECTED]> > >>>>> Sent by: [EMAIL PROTECTED] > >>>>> No Phone Info Available > >>>>> 05/24/2006 10:57 PM > >>>>> > >>>>> To > >>>>> Gary Calder <[EMAIL PROTECTED]>, Gideon Avida > >>>> > >>>> <[EMAIL PROTECTED]>, > >>>> > >>>>> Landon Noll <[EMAIL PROTECTED]> > >>>>> cc > >>>>> james hughes <[EMAIL PROTECTED]>, [EMAIL PROTECTED], SISWG > >>>>> <[EMAIL PROTECTED]>, Serge Plotkin <[EMAIL PROTECTED]> > >>>>> Subject > >>>>> Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I basically agree what Gary suggests. Sun Microsystems has > >>>>> achieved > >>>>> export approval for several products and I do not remember text > >>>>> that > >>>>> requires "access control". The definitions of "Open Cryptographic > >>>>> Interface" is indeed an interesting one. I doubt that a disk drive > >>>>> with encryption but without access control would be considered an > >>>>> "open cryptographic interface". It is my understanding that open > >>>>> cryptographic interface applies to software APIs and chips, > >>>> > >>>> not where > >>>> > >>>>> someone has to open a device to harvest the crypto chip > >>>> > >>>> (where access > >>>> > >>>>> control can make that difficult). > >>>>> > >>>>> The response about China is correct, but irrelevant to the access > >>>>> control issue. The way I read this, they will not let it in, > >>>>> period, > >>>>> access control or not. > >>>>> > >>>>> Again. I think that the other storage encryption vendors > >>>> > >>>> should chime > >>>> > >>>>> in for both disk and tape. I assume that they are selling > >>>>> internationally! > >>>>> > >>>>> jim > >>>>> > >>>>> > >>>>> > >>>>> On May 23, 2006, at 10:21 AM, Gary Calder wrote: > >>>>> > >>>>>> James (all), > >>>>>> > >>>>>> I have exactly the same concerns as you about the 2nd para in > >>>>>> Laszlo's document, where it says that access control is > >>>>>> required by > >>>>>> authorities. Even just considering one country, the US, I don't > >>>>>> think it is as simple as that, here are some references: > >>>>>> > >>>>>> The up to date US Export Administration Regulations (EAR) > >>>>>> database > >>>>>> can be found here: http://www.access.gpo.gov/bis/ear/ > >>>>>> ear_data.html > >>>>>> > >>>>>> Of the many documents listed, I think these are the most > >>>>>> relevant: > >>>>>> Part 736 - General Prohibitions http://www.access.gpo.gov/bis/ > >>>>>> ear/ > >>>>>> pdf/736.pdf dated 11-09-05 > >>>>>> Part 740 - License Exceptions > >>>>> > >>>> http://www.access.gpo.gov/bis/ear/pdf/ > >>>> > >>>>>> 740.pdf dated 04-28-06 > >>>>>> Part 742 - Control Policy -- CCL Based Controls http:// > >>>>>> www.access.gpo.gov/bis/ear/pdf/742.pdf dated 5-16-06 > >>>>>> (Part 774) Category 5 (Part 2) - Information Security http:// > >>>>>> www.access.gpo.gov/bis/ear/pdf/ccl5-pt2.pdf dated 11-18-05 > >>>>>> > >>>>>> What follows is my interpretation of the above docs - I have not > >>>>>> read through all of them word for word (life's too short) but I > >>>>>> think I get the basic gist. > >>>>>> > >>>>>> Everything that is controlled is listed under an ECCN (Export > >>>>>> Classification Control Number). ECCNs 5A002, 5D002, 5E002 and > >>>>>> 5A992, 5D992 and 5E992 cover encryption items. Section 742.15 > >>>>>> gives > >>>>>> a broad outline of the licensing policy covering these ECCNs. For > >>>>>> 5A/D/E002 an export license is required to all countries, except > >>>>>> Canada. Further exceptions apply, given under 740.17. > >>>>>> In particular, there is this exception: > >>>>>> > >>>>>> -------------------------------------------- > >>>>>> (2) Encryption commodities and software > >>>>>> restricted to non-âgovernment end-users.â > >>>>>> This paragraph (b)(2) authorizes the export and > >>>>>> reexport of items described in §740.17(b)(2)(iii) > >>>>>> of the EAR that do not provide an âopen > >>>>>> cryptographic interfaceâ and that are controlled > >>>>>> by ECCNs 5A002.a.1, .a.2, .a.5, or .a.6, or 5D002 > >>>>>> to individuals, commercial firms, and other > >>>>>> entities that are not âgovernment end-usersâ and > >>>>>> that are not located in a country listed in > >>>>>> Supplement No. 3 to this part. In addition, the > >>>>>> transaction must meet the provisions of either > >>>>>> §740.17(b)(2)(i) or (ii) of the EAR. > >>>>>> -------------------------------------------- > >>>>>> > >>>>>> The relevant ECCN paras mentioned are: > >>>>>> > >>>>>> ---------------------------------------------- > >>>>>> a.1. Designed or modified to use > >>>>>> âcryptographyâ employing digital techniques > >>>>>> performing any cryptographic function other than > >>>>>> authentication or digital signature having any of > >>>>>> the following: > >>>>>> > >>>>>> a.1.a. A âsymmetric algorithmâ > >>>>>> employing a key length in excess of 56-bits; or > >>>>>> a.1.b. An âasymmetric algorithmâ where > >>>>>> the security of the algorithm is based on any of the > >>>>>> following: > >>>>>> a.1.b.1. Factorization of integers in > >>>>>> excess of 512 bits (e.g., RSA); > >>>>>> a.1.b.2. Computation of discrete > >>>>>> logarithms in a multiplicative group of a finite > >>>>>> field of size greater than 512 bits (e.g., Diffie- > >>>>>> Hellman over Z/pZ); or > >>>>>> a.1.b.3. Discrete logarithms in a > >>>>>> group other than mentioned in 5A002.a.1.b.2 in > >>>>>> excess of 112 bits (e.g., Diffie-Hellman over an > >>>>>> elliptic curve); > >>>>>> a.2. Designed or modified to perform > >>>>>> cryptanalytic functions; > >>>>>> ... > >>>>>> a.5. Designed or modified to use > >>>>>> cryptographic techniques to generate the > >>>>>> spreading code for âspread spectrumâ systems, > >>>>>> including the hopping code for âfrequency > >>>>>> hoppingâ systems; > >>>>>> a.6. Designed or modified to use > >>>>>> cryptographic techniques to generate channelizing > >>>>>> or scrambling codes for âtime-modulated ultrawidebandâ > >>>>>> systems; > >>>>>> ----------------------------------------- > >>>>>> > >>>>>> I think this is where the term 'required' has been misconstrued. > >>>>>> Essentially this is saying if you have a product covered by these > >>>>>> ECCNs, but aimed at end (non governmental) users not located in > >>>>>> certain countries, where there is no 'open cryptographic > >>>>>> interface', then export is authorized. > >>>>>> > >>>>>> But if you don't have a product that falls under the license > >>>>>> exemptions, you can still apply for a license.742.15 (i)(ii) says > >>>>>> that applications are treated on a case by case basis - I would > >>>>>> take that to mean that even if (say) you had a product that > >>>>>> had an > >>>>>> 'open cryptographic interface' you might still get a license > >>>>>> authorized, depending on the individual application. > >>>>>> > >>>>>> Now it may be that others on this list have some practical > >>>>>> experience of actually applying for a license - I might be > >>>>>> prepared > >>>>>> to accept that in practice, any product with an 'open > >>>>>> cryptographic > >>>>>> interface' operating at the kinds of data rates that hard disks > >>>>>> operate would stand a remote chance of getting a license. > >>>>>> > >>>>>> My only other experience is with the UK regulations. There is a > >>>>>> control list which lists a combination of military items > >>>>>> classified > >>>>>> by the UK, plus a European Commission (EC) list of so-called > >>>>>> 'dual- > >>>>>> use' items. These are items which are civilian in nature but can > >>>>>> have a dual military application. > >>>>>> The list is available here: http://www.dti.gov.uk/files/ > >>>>>> file27539.pdf current copy dated 12th April 2006 > >>>>>> > >>>>>> In this, category 5 covers "Telecommunications and Information > >>>>>> Security".In this, you will find similar words as the US EAR > >>>>>> regs. > >>>>>> Even the use of the same numbers 5A002 and 5D002. Why is that? In > >>>>>> fact, its because the US and Eu countries are all signatories of > >>>>>> the Wassenaar agreement, mentioned in the 1998 survey you quoted. > >>>>>> It covers the export of military and 'dual-use' items. This is > >>>>>> where you can see where the common text of the US/UK/EU lists > >>>>>> came > >>>>>> about. Everything is documented here: http://www.wassenaar.org/ > >>>>>> controllists/index.html (Category 5 part 2). > >>>>>> > >>>>>> This list does not have the corresponding License Exceptions or > >>>>>> mention of 'open cryptographic interfaces' so I have no idea if a > >>>>>> similar exception applies to the UK (or EU). I would expect > >>>>>> this to > >>>>>> be country by country dependent. > >>>>>> > >>>>>> Of course, many of the *export* regulations are perhaps moot > >>>>>> if, as > >>>>>> with my company, manufacturing and export of the actual > >>>>>> product is > >>>>>> done in the Far East (Taiwan. Korea etc). In that case *import* > >>>>>> regulations are relevant. AFAIK, these are much more relaxed. For > >>>>>> example, this is the UK position (http://www.dti.gov.uk/ > >>>>>> europeandtrade/importing-into-uk/page9728.html): > >>>>>> > >>>>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> > >>>>>> - > >>>>>> ------------------------------------------- > >>>>>> The majority of goods can be imported into the United Kingdom > >>>>>> without the need to apply for an import licence. > >>>>>> > >>>>>> Currently ILB issues import licences for certain goods mainly to > >>>>>> implement: > >>>>>> DTIâs trade policy measures > >>>>>> > >>>>>> * certain textiles from Belarus, China, Montenegro, North > >>>>>> Korea and > >>>>>> Uzbekistan > >>>>>> * iron & steel > >>>>>> > >>>>>> For safety reasons > >>>>>> > >>>>>> * > >>>>>> firearms and ammunition > >>>>>> * > >>>>>> nuclear materials > >>>>>> > >>>>>> As a result of international obligations > >>>>>> > >>>>>> * > >>>>>> anti-personnel mines > >>>>>> * > >>>>>> rough diamonds and wood products from Liberia > >>>>>> > >>>>>> Other Government departments may have their own import > >>>>>> restrictions. For example the Rural Payments Agency (RPA) issues > >>>>>> import licences for agricultural, horticultural products and > >>>>>> certain items of food and drink. Traders importing these products > >>>>>> will need to contact them for advice not ILB (for link to RPA > >>>>>> website see related links). It is the responsibility of the > >>>>>> importers to ensure that he/she is aware of any restrictions on > >>>>>> goods they wish to import. > >>>>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> > >>>>>> - > >>>>>> ---------------------------------------------------- > >>>>>> > >>>>>> So while the US and UK/EU and other Wasenaar signatories seem > >>>>>> to be > >>>>>> reasonably aligned in the export policy vis-a-vis encryption > >>>>>> products, things are still obviously very country dependent for > >>>>>> granting of export licenses and also imports. > >>>>>> > >>>>>> I hope at least this gives the insomniacs amongst you some useful > >>>>>> bedtime reading. > >>>>>> > >>>>>> Regards, > >>>>>> Gary Calder > >>>>>> Oxford Semiconductor > >>>>>> www.oxsemi.com > >>>>>> > >>>>>> james hughes wrote: > >>>>>> > >>>>>>> I would like some references to the claims in the > >>>>>>> introduction. My > >>>>>>> reason for asking about such is that it is important that we > >>>>>>> (IEEE) standardize what is right, not what is politically in > >>>>>>> vogue > >>>>>>> at a moment in history. The I in IEEE is for International. > >>>>>>> Additionally, I am interested in which market? Anyway, > >>>>>>> references > >>>>>>> to the claims of this paragraph should be provided. > >>>>>>> > >>>>>>>> Access control not just can be provided, but it is required by > >>>>>>>> the export control authorities, > >>>>>>> > >>>>>>> > >>>>>>> Reference? > >>>>>>> > >>>>>>>> and also by many local authorities, > >>>>>>> > >>>>>>> > >>>>>>> Reference? > >>>>>>> > >>>>>>>> where storage devices are sold. If the encrypted data is freely > >>>>>>>> accessible, the encryption module can be used as a stand alone, > >>>>>>>> high-speed encryption processor, which is prohibited in many > >>>>>>>> markets. > >>>>>>> > >>>>>>> > >>>>>>> Reference of the regulation and any example of a storage > >>>>>>> encryption device where the "encryption module can be used as a > >>>>>>> stand alone, high-speed encryption processor" in such a way that > >>>>>>> it violates a law? > >>>>>>> > >>>>>>> I have looked for information on the web about this kind of > >>>>>>> information. There is a summary done in 1998, but I have found > >>>>>>> nothing online more recent. > >>>>>>> http://www.gilc.org/crypto/crypto-survey.html > >>>>>>> > >>>>>>> > >>>>>>> On May 19, 2006, at 6:16 PM, [EMAIL PROTECTED] wrote: > >>>>>>> > >>>>>>>> Here is an update of the non-removable secure storage > >>>>>>>> discussion > >>>>>>>> document. It does not contain new information, only > >>>>>>>> editorial and > >>>>>>>> formatting changes, in an attempt to make it easier to > >>>>>>> > >>>> understand. > >>>> > >>>>>>>> -Laszlo > >>>>>>>> <Nonremovable Discussions-D07.pdf> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> > >
