Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7

[james hughes]

Thank you. Very enlightening discussion.

Jim


On May 30, 2006, at 4:29 AM, Gary Calder wrote:

James,

Quite. Cisco routers (800, 1800, 2800, 3800) all come with built in hardware for encryption acceleration. See this datasheet: http://www.cisco.com/application/pdf/en/us/guest/products/ps5854/ c1650/cdccont_0900aecd80169b0a.pdf

However, it is only enabled through use of the Cisco IOS Software Advanced Security feature. Eg "Cisco 18xx (Modular) Router IOS Software w/AES [*G035731*]" appears in Cisco's list http:// www.cisco.com/wwl/export/crypto/tool/stqrg.html under 'Unrestricted Retail' and not under their 'mass market' (as defiined by Cryptography note 3) list at the top of that page.

This software employs 9or rather enables) symmetric encryption using a key > 64 (AES) which therefore means that they are NOT EXEMPT FROM REVIEW UNDER ECCNs 5A002/5D002

The fact that these products have the ciphertext visible (that's the whole point of a secure VPN ) makes it obvious to me that simply having this feature in a product does not automatically mean 'you can't export this freely as it will be subject to export controls'.

However, if you look further down the Cisco list, you will find a 'restricted (non retail)' category. In this you will find "Cisco IOS software [*G023912*] (Applies to Cisco 3600, 3700, 3800, 7100, 7200,7300, 7500, 7600, 10000, 10700, 12000 Series Routers). Supersedes D266484 and G019346." I don't know these products intimately, but I'm guessing they all have high speed interfaces like Gigabit Ethernet.

So it seems 100 Mbps ciphertext is ok, can be exported sold to anybody anywhere (other than users in Cuba, Iran, Libya, North Korea, Sudan, and Syria or to other sanctioned entities or for sanctioned end uses), but 1GBps is more controlled (licenses required for sale to Governments, with exceptions like the EU and Australia etc.)

The bottom line is that having ciphertext visible does not automatically make a product un-exportable. But such a product running at Gigabit speeds (like a hard drive ) might need to be restricted depending an the specific end user. Basically you might have to know who you are selling it to: some will require licenses, other not. Hence it can't be sold as a retail product. I would guess those tape drive systems that were mentioned are not sold as retail products and would be sold under this kind of 'known end user' restriction.

I go back to what I said before: *any* product using AES must be submitted for review under ECCN 5A002/5D002. BIS would then decide, based on the individual product whether to allow export (other than to Cuba, Iran, Libya, North Korea, Sudan, and Syria) with no license required, or require licenses to be applied for for export for certain (government) users. From what has been said about the Seagate experience, and also what you can see from the Cisco router products, ciphertext visibility and speed of operation are important deciding factors. Where the line is drawn is not clear - would hardware assisted IPsec over Firewire/1394 at 400Mbps be OK?

Regards,
Gary

james hughes wrote:

Very simple...

If I have an IPSEC router, I can cable the router in and out of the same machine and use this as an encryptor. This is especially true for any manual keyed scenarios. Even with key exchange, I can put 2 boxes on my machine to do this.

On May 26, 2006, at 8:14 AM, [EMAIL PROTECTED] wrote:

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