> All IPSEC routers would fall into this requirement. Could you explain it a little bit more? It sounds like a serious issue.
> -------- Original Message -------- > Subject: Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7 > From: james hughes <[EMAIL PROTECTED]> > Date: Fri, May 26, 2006 10:48 am > To: [EMAIL PROTECTED] > Cc: james hughes <[EMAIL PROTECTED]>, Curtis Anderson > <[EMAIL PROTECTED]>, "'Gary Calder'" > <[EMAIL PROTECTED]>, "'Gideon Avida'" <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], "'Landon Noll'" <[EMAIL PROTECTED]>, "'Serge Plotkin'" > <[EMAIL PROTECTED]>, "'SISWG'" <[EMAIL PROTECTED]>, Steven > Sletten <[EMAIL PROTECTED]> > > I am confused by this requirement. > > All IPSEC routers would fall into this requirement. > > While I agree that the non-readable ciphertext in a disk drive would > be trivial to turn into a low cost generic high speed hardware > encryptor, would the same hold for tape? > > > On May 26, 2006, at 7:39 AM, [EMAIL PROTECTED] wrote: > > > 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: > >>>>>>> DTIs 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> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >> > > > > > >
