export regulations (was: [Cryptography Team] msh-crypto
designandtests)
Matthew S. Hamrick
mhamrick at cryptonomicon.net
Fri Oct 28 21:55:10 CEST 2005
Here are some of the fundamental truths I've come to understand after
getting crypto-enabled products exported without the BXA / BIS trying
to have me arrested.
* No Product, Project or Person in the United States is exempt from
regulation
* That being said, Open Source Projects are exempted from the
licensing requirement, assuming you follow the rules of alerting the
BIS before publishing your open source code.
* The US government still routinely investigates, prosecutes, and
jails people who violate these regulations. ( the last one I remember
was in 2004 when a couple guys in Baltimore conspired to avoid export
regulations when shipping a crate of crypto-enabled software to China.)
* Getting back to the "no person is exempt" doctrine. US Citizens who
have left the country to implement crypto libraries in an effort to
escape export regulations have been warned that the federal
prosecutors consider this illegal. Apparently if you leave the US for
the explicit purpose of avoiding US regulation, the feds view this as
conspiracy to commit a crime (or something similar.) And though I am
not a lawyer (IANAL) I was in a room with a Federal Prosecutor when
someone asked about this and got an answer directly from a federal
official whose job it is to prosecute violations of export rules. She
basically said, "don't do it."
* Getting back to the no project or product is exempt doctrine. It's
perfectly legal to import crypto libraries from foreign sources. It
is, however, illegal to re-export them without license. This
basically means if you're a US citizen in the US and you import a
crypto library, make a change to it and then want to post your
changes, you have to apply for a license, a license exemption, or
claim a license exemption if it's an open source project.
* It's not just crypto libraries that are regulated. We've been
focusing on crypto libraries here, but it's important here to note
that it's not only libraries. Non-security products or projects that
use crypto are subject to regulation. This essentially means if you
have a client that uses SSL to verify the identity of an update
server, you've got to go through the process to demonstrate it can't
be re-purposed to easily allow bad guys to send covert encrypted
messages to each other. (Or if it's open source, you alert the BIS
via email where they can pick up a copy of the source.) But I've got
to say I don't know how this is being interpreted these days... This
is where a lawyer would come in very handy. Not only do we not want
to expose ourselves to criminal liability, we don't want to make a
library or process that exposes users of the crypto bits to criminal
prosecution.
* "Crypto with a hole" was frowned upon by export regulators in the
late 90's. This is basically where you create a plugin interface for
crypto operations in your product. You ship the product with a plugin
implementing "broken" crypto like 40 bit RC4 and claim an exemption.
You then have a foreign integrator add an AES plugin to the product
before it's delivered to the end user. I remember that this caused us
no end of problems because we were making products that integrated
with smart cards and external crypto co-processors which were
essentially "crypto with a hole" products. I think interpretations
for these types of products must have been loosened a bit. Just about
everybody (Microsoft, Apple, etc.) have crypto plugin architectures.
OpenSSL has a crypto hardware interface that can easily be repurposed
to provide access to an external software crypto library. Again... an
experienced lawyer could probably shed a fair amount of light on this
issue.
As for the weak key issue on the BIS page... I too think it's a typo.
When the then-new regulations came out in 2000, the BXA started
granting exemptions for commercial products with 56 bit symmetric
algorithms (this was up from 40 bits.) Later this was upped to 64
bits. So there's a history of going easy on products that use small
key sizes while subjecting products with larger key sizes to closer
scrutiny.
Also... a bit of terminology and history... I don't know if you
picked up on the usage by reading the BIS pages. The US is a signer
of the Wassenar agreement, an international treaty regulating
trafficking of military and "dual purpose" goods. After signing this
treaty, we came up with the Arms Export Control Act which established
a regime for regulating the export of nuclear weapons and SSL-enabled
web browsers. The Export Administration Regulations (EAR) are
enshrined in Title 22 of the CFR (Code of Federal Regulations).
When you want to export a bit of military hardware or "dual purpose"
equipment (things that can be used for civilian OR military
purposes,) you're supposed to get an export license. Exporting
controlled items without one opens you up to the risk of spending
time in a minimum security federal facility where you'll be forced to
listen to Scooter Libby tell jokes about Dick Cheney. I've been to a
couple of functions in Washington, DC where politicians try to make
jokes. Trust me, you don't want to be anywhere near a political
staffer when they think they do their Dave Chappelle impersonation.
So export licenses are notoriously difficult to get. There's a lot of
paperwork, meetings with government officials, meetings with agents
for import/export companies, meetings with underwriters of shipping
insurance policies. You really don't want to go there.
So fortunately for you, you can apply for an exemption for an export
license. There are plenty of justifications you can use and the BIS
has compiled a list of them in part 740 of title 22. The ones I'm
most familiar with are the KMI and ENC exemptions for Key Management
and Encryption products. So when we say "you can't export a
commercial product with 128 bit crypto," what we really mean to say
is "you can't export a commercial product with 128 bit crypto without
a Export License or an Export License Exemption."
But fortunately we're talking about an open source project so we
don't have to worry about KMI or ENC. We just have to remember to
alert the BIS that we're exporting or re-exporting open source crypto
code under a TSU exemption (more info at http://www.bis.doc.gov/
Encryption/PubAvailEncSourceCodeNofify.html ).
Also... if you're interested in reading the regs, the GPO put links
to the regulations and some commentary all on one page at http://
www.access.gpo.gov/bis/ear/ear_data.html .
-Cheers!
On Oct 27, 2005, at 7:55 PM, Ron Teitelbaum wrote:
> Sean,
>
> Have you talked to James about this project at all? I am still
> waiting for
> a response. I'm trying to find a lawyer before contacting him
> again to help
> with negotiations if there is going to be any. In the mean time
> until there
> is some sort of agreement we should avoid working with any Concom
> code. Be
> careful what you work on Sean. We don't want to create any issues
> between
> you and your employer.
>
> Ron
>
> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On Behalf
> Of Sean
> Glazier
> Sent: Thursday, October 27, 2005 10:23 PM
> To: chris at funkyobjects.org; 'Cryptography Team Development List'
> Subject: RE: export regulations (was: [Cryptography Team] msh-crypto
> designandtests)
>
> All the algorithms we have used have been made public and there are
> implementations all over the internet. I do believe we talked with
> Cincom
> legal a while back and they said don't worry about them so I didn't
> give it
> another thought. And I do think they mean what that says so if you
> develop
> something that uses weak key you got to tell them. I guess so they
> can snoop
> on the fools using it. Trying to control crypto libraries is like
> trying to
> un ring a bell after it has gone off. According to the check list
> http://www.bis.doc.gov/encryption/ChecklistInstr.htm your are only
> required
> to do so if it is using weak keys. I am sure that is a typo. In any
> case
> Cincom legal should take a look at our stuff again and the law.
>
> Sean
>
> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On Behalf
> Of Chris
> Muller
> Sent: Thursday, October 27, 2005 9:04 PM
> To: cryptography at lists.squeakfoundation.org
> Subject: export regulations (was: [Cryptography Team] msh-crypto
> design
> andtests)
>
>
>
>> I've talked to James about the CinCom implementation a couple of
>> times. On thing that's a little disturbing is that he tells me that
>> they haven't alerted BIS (formerly BXA) as to the existence of the
>> package. The current rules for US open source crypto developers are
>> that you have to alert the BIS (Bureau of Industry and Security)
>> before you export (i.e. - upload to a ftp site, post to a newsgroup,
>> or include in an email distribution that goes overseas) you're
>> supposed to send an email message to them telling them where they can
>> find a copy. I think this is to insure that it's really open source
>> and to provide them with a working copy should they find bad guys are
>> using your source. (saves them from having to reverse engineer the
>> code.) I could be wrong about this, but you probably want to double-
>> check with them...
>>
>
> I must say you have shocked me out of ignorance. Or, rather, this
> did:
>
> http://www.bis.doc.gov/Encryption/nlr.htm
>
> This makes no sense..
>
> "The following items require such notification:
>
> * Mass market encryption commodities and software with key
> lengths not
> exceeding 64-bits;
> * Encryption items (including key management products and company
> proprietary implementations) with key lengths not exceeding 56-bits
> for
> symmetric algorithms, up to 512-bits for asymmetric key exchange
> algorithms,
> and 112 bits for elliptic curve algorithms."
>
> The (already exported) algorithms can be configured for larger key
> sizes, is
> this talking about default values for key lengths?
>
> But it looks like their stenographer got it backward..! It says, "the
> following items REQUIRE notification" but then they specify key
> sizes "NOT
> exceeding" but they surely mean exceeding. Unreal.
>
> I was on the verge of "exporting" a domain of security classes
> leveraging
> our
> Cryptography package. Is this about the stinkin' default values?
> You may
> have
> saved me from jail..
>
>
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> cryptography
>
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> cryptography
>
>
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> cryptography
>
More information about the Cryptography
mailing list