The SCSI proposal is exportable, since it is will be incorporated into an INCITS standard and the "I" in INCITS stands for "International". Eventually, the standard the proposal will be incorporated into will also become an ISO standard. This proposal was approved for inclusion on SSC-3 several weeks ago.
I think what you meant to say was "devices that implement the SCSI proposal will not be exportable". This is not necessarily true either. In T10 standards, all features are to be treated as optional unless the standard specifically says it is mandatory. We were very careful to not make any of the encryption or decryption modes mandatory while we were developing this proposal. A device manufacturer that implements the SSC-3 standard encryption feature and does not support the RAW mode can still be compliant to the standard and should not have the types of problems you have been discussing with regards to export controls. Paul Entzel Quantum -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, May 26, 2006 8:39 AM To: [EMAIL PROTECTED] Cc: Curtis Anderson; 'Gary Calder'; 'Gideon Avida'; james hughes; [EMAIL PROTECTED]; 'Landon Noll'; 'Serge Plotkin'; 'SISWG'; Steven Sletten Subject: Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7 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> >>>>>>> >>>>>>> >>>>>>> >>>> >
