The Illogical Export of Cryptography
Posted by pramatr on December 14th, 2008
I have recently had the pleasure of dealing with the Export Compliance Organisation (ECO) in the UK. For those that don’t know what their purpose is and how it relates to software development you should check out their website.
For the lazy I will quote in their own words:
“The Export Control Organisation is responsible for assessing and issuing export licences for specific categories of “controlled” goods. A wide range of items fall under Export Control Legislation including so-called dual-use goods (such as nuclear, chemical or communications goods), torture goods, radioactive sources, as well as military items (such as firearms and ammunition). Other exports are controlled by separate legislation.
If items exported from the United Kingdom are subject to control, then those items will need a licence to be legally exported.
Who Cares?
So why should we as software developers care about export control?
Well cryptography software is classified as a dual-use item and may require control under Export Control Legislation. This is because it can be used to secure communications and to stop the authorities finding out what someone is getting up to.
For example say we develop a proprietary symmetric cipher that is highly secure and we use this to create a communication program that we sell over the Internet. This legislation is designed to ensure that the government knows about it, and that we can demonstrate to them, who we have sold it to and where, and for what purpose its being used.
A Closer Look
Taking a closer look at the Export Control List we find that software that employs the following techniques is controlled under the legislation:
A “symmetric algorithm” employing a key length in excess of 56 bits; or
b. An “asymmetric algorithm” where the security of the algorithm is based on any of the following:
1. Factorisation of integers in excess of 512 bits (e.g., RSA);
2. Computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over); or
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 anelliptic curve);
Is Your WebApp Licensed?
Now anyone that knows a little about the common protocols used on the Internet today should know that any Secure Socket Layer application will fall under this definition. That means any web server running HTTPS could possibly require an export license because it uses a key length greater than 56 bits, most web servers as standard now use 128 bit encryption.
How To Get A License
Getting the license is fairly straight forward, the government provide open licenses that can be used so you don’t have to obtain an individual license for every sale. You simply register with the ECO and keep records of your exports. If you are unsure as to whether your product needs to have a license you can obtain a rating from the ECO by registering on SPIRE this is also the same place where you can apply for the open licenses.
Commerical Product vs Opensource Product
I recently went through the rating process for a product that used a web server. The product had two editions, an open source and commercial edition that had additional features. The main cryptographic component was the secure web server which utilised the cryptographic components from the Sun Java Runtime.
When I got the rating back I was surprised to find that the open source edition did not require any license but the commercial edition was controlled under category 5D002.
This seems highly illogical to me, the open source edition does not require a license to export even though it’s in the public domain, free for all to use and modify as the source code is available, yet the the commercial edition (which ships with compiled obfuscated code) requires licensing.
Which one would you choose if you wanted to hide your activities from the authorities?
Common Sense Please
Whilst I agree that export legislation is a good thing and is designed to protect us I think that some common sense needs to be applied to software. With so much cryptography in the public domain surely we should only control proprietary cryptographic algorithms and leave the known standards alone.