21

Which aspects do I need to consider when designing and publishing software that must meet the US export restrictions for cryptographic software?

Wikipedia says that there are various categories which you can assign to cryptographic software. And the export destination (e.g. China, Russia) does play a major role as well. But I didn't really understand those restrictions and their effect on my work.

Can anybody explain that to me?

I'm asking because if you try to publish your application (e.g. on Apple's App Store or Android's Market) you have to assure that your application meets the US export restrictions. And there are lots of applications who offer secure information storage, e.g. for passwords.

Have they all notified the government and asked for a review? Of course, you cannot know if they did. But do they need to do this?

yannis
  • 39,547
  • 40
  • 183
  • 216
caw
  • 215
  • 2
  • 10
  • 1
    Your first prognosis became true. But regarding the second one: This is a question which is interesting for lots of programmers, isn't it? Many have published software which uses cryptographic algorithms. So somebody must know. – caw Dec 31 '11 at 00:49
  • Yes definitely, that doesn't mean anyone is certain enough of what you've done to give you definitive advice. See "go see lawyer" below! – Ben Dec 31 '11 at 11:16
  • You may check out the [FIPS](http://itl.nist.gov/fipspubs/) website for more details – Ubermensch Jan 04 '12 at 13:47
  • 1
    For something like this, I'd consult a lawyer. My career is in the defense industry, including at contractors who create products for domestic as well as foreign customers. There is not only a legal team, but specific export control specialists that review everything to make sure it's following the guidelines. There are a lot of little things to watch out for and relying on an answer from a software developer isn't wise since it's so easy to overlook something important. – Thomas Owens Jan 10 '12 at 11:44
  • 1
    Thank you, Thomas. I just thought it may be a clear case as there are sooo many application in Android Market (all must meet the guidelines) that use AES Encryption. Imagine, all the banking apps, the password storage apps etc ... And I don't sell my applications, I offer them for free. So asking a lawyer is expensive. – caw Jan 10 '12 at 17:28

4 Answers4

15

If your code is open source, the restrictions are very light-weight: you cannot export your code to countries or entities that have been restricted and you must notify the government of the location where they can download source and object files. You must make some effort to prevent the code from being downloaded by Cuba, Iran, Libya, North Korea, Syria, and Sudan. You must ask all your users to not export to these nations.

You will be expected to prepare lists of all "packages" and "files" that contain the encryption primitives. (I recall that we were allowed to skip hashing primitives that were used only for authentication or integrity controls.)

If your code is not open source, you must file for exceptions on your own code. I expect you'll need to prepare similar lists of source / object files and which algorithms are implemented for what mechanisms. I further expect it'll require review before the license is granted.

While I believe all my information is correct as of 30 December 2011, I am not a lawyer and cannot provide you with legal advice. These are simply pointers to currently-available US government resources.

sarnold
  • 932
  • 5
  • 11
  • 1
    Thank you! This sounds really complex and onerous. Please see my edit in the question: Is your explanation even for this case or only for software which enables user to encode or decode information freely? – caw Dec 31 '11 at 00:48
  • It is my recollection that hashed passwords aren't one of the things they're interested in -- so if that's all your application does, you're almost certainly fine. I can't speak for what any other application authors do... – sarnold Dec 31 '11 at 00:53
  • Okay, thank you. So if we take an online banking application or a password safe as an example - they both encrypt data for safe storage: Is this fine or must it be reported and reviewed? – caw Dec 31 '11 at 11:57
  • If you're relying 100% on the host OS to provide the cryptography primitives, you don't have to do anything. :) – sarnold Dec 31 '11 at 23:27
  • Yes, nearly 100%, as I use the Cipher class in Java for example. But if this is so, I don't know why Java doesn't come with large key sizes built in. They say it's due to US export restrictions. – caw Jan 02 '12 at 00:07
  • @MarcoW. - I would trust the reason Java says is the reason. Your question really does not explain the reason you are concerned over those markets that the export restrictions would even be a problem. – Ramhound Jan 04 '12 at 15:06
  • What made me think about this question is: When you want to publish an application in Android Market, they ask you to affirm that your application doesn't violate the US export restrictions where you should pay special attention to cryptography. – caw Jan 04 '12 at 21:06
  • I can't speak to why the Java keysizes are limited -- I do know that before the US regulations were relaxed, Cryptography in Java was extremely awkward, requiring a specific download from Sun to provide the algorithms. Of course, [others filled the void](http://www.bouncycastle.org/), which just complicate matters further. Perhaps Sun / Oracle have an understanding with the US Govt to not make high-powered cryptography "too easy", perhaps they just haven't seen a need to extend the cryptography in Java since Bouncy Castle seems to be preferred anyway. – sarnold Jan 04 '12 at 23:17
  • According to this link (http://www.ngs.ac.uk/tools/jcepolicyfiles), it was not that Sun/Oracle is just nice to the US government but it is a legal restriction which Java has to obey. But now I found another source which states that the whole issue is not due to US export restrictions but other countries' IMPORT restrictions - which would be fine for me. – caw Jan 05 '12 at 01:35
  • 1
    FROM JAVA'S UNLIMITED STRENGTH JURISDICTION POLICY FILES: The JCE architecture allows flexible cryptographic strength to be configured via jurisdiction policy files. Due to the import restrictions of some countries, the jurisdiction policy files distributed with the Java SE 7 software have built-in restrictions on available cryptographic strength. The jurisdiction policy files in this download bundle (the bundle including this README file) contain no restrictions on cryptographic strengths. This is appropriate for most countries. – caw Jan 05 '12 at 01:36
  • So it's no problem anymore? Do I understand this text correctly? But one question is still important for me: The Java JCE has been approved in a review process. Do I have to ask for a review in the US as well? – caw Jan 05 '12 at 14:25
7

Are you writing your own cryptographic routines or merely calling a 3rd party routine?

The reason I ask is because if for example on Windows you are using one of the Microsoft provided routines then you are not the one publishing or distributing the controlled software, in which case your software would not be under any restriction.

JonnyBoats
  • 1,783
  • 13
  • 11
  • Thanks for the answer! If this is true, it would be great :) I will be using famous algorithms such as AES, SHA etc. So I will reuse other algorithms and call native functions. I will not publish my own cryptographic algorithm. – caw Dec 31 '11 at 03:32
  • Marco: That is definitely the way to go. What operating system are you targeting? – JonnyBoats Dec 31 '11 at 05:15
  • iOS and Android. But as you can see here (http://www.ngs.ac.uk/tools/jcepolicyfiles), some key sizes are even not allowed in Java due to US export restrictions. So just using famous algorithms and implementing them is not as "innocent" as we might think?! – caw Dec 31 '11 at 11:14
  • 3
    Marco: Code your program to simply use the best routine available on the customer's phone, check at run time. Beside how much product will you be selling in Cuba or North Korea? – JonnyBoats Jan 02 '12 at 06:08
  • Implementing the best routine which is available is easy. The legal issues are more important to me. Cuba or North Korea are special cases, obviously. The export restrictions are there for almost all countries, even though they're not that strict elsewhere. – caw Jan 04 '12 at 21:04
  • Marco: You essentially have no restrictions since you are not exporting the routines you are calling. – JonnyBoats Jan 04 '12 at 22:55
  • 1
    If you use the Microsoft-provided routine crypto on Windows, then you aren't exporting the stuff because you aren't providing it. If it's already there, it's presumably OK to call it. Using standard implementations of standard algorithms is still providing the crypto, and you may well be exporting it. (Also, don't write your own security software for production purposes, unless you have experience in the field. There's too many things you can easily get wrong.) – David Thornley Jan 10 '12 at 14:47
  • These guys got it right. Don't implement your own encryption, use the OS APIs for it and you can't go wrong. If you did it's because Google, Microsoft, or Apple failed massively and they will be the ones liable. – Rig Jan 10 '12 at 17:57
  • 1
    I'm pretty sure that you still need to file all that crypto export stuff if you're merely using crypto APIs. – CodesInChaos Oct 21 '13 at 12:00
1

If this is just a question for interest's sake, then the other answers are great. If it pertains to something you are actually doing?

GO SEE A Lawyer. NOW.

Are you still waiting? Then I'll expand.

Go see a lawyer. Now. Don't wait, don't think. If you don't have one already, find one. Ask them to put you in touch with someone who handles business law as a job. Check his credentials, and if they look right, sit down with that person and offer them money for advice. Feel free to negotiate on terms.

If you don't trust me, and I'll admit I'm being very definite without much experience in this area, read this article, written in May 2010, by someone who's been successfully running a family business since '93.

If you are trying to run an Indie game business, you are, first and foremost, running a business. All local, state, and federal laws apply. You need a business license. Or licenses. Every business should have a lawyer and an accountant. I personally have done without having a dedicated lawyer on tap (an unwise course), but every business should have a skilled accountant.

What this means is that someone whose business comprises two people selling games where lizards in armour beat up goblins is aware he's taking a risk by not having access to his own personal lawyer at all times.

Are you a business? Don't know. If you're selling something, you could well be. Guess who would know? A Lawyer.

You don't have to pay for a very expensive lawyer for a long time, but at the very least you need to have someone available by appointment who you can run things by before doing stuff that may be legally dangerous, and who can explain to you what may be legally dangerous.

Because here's the thing. If you do it up front, then many things apply.

  1. You're less likely to screw up and attract the attention of the govt.
  2. You're more aware when you have screwed up, and what to do about it, including an existing contact you can call to help you.
  3. If you do screw up and attract the attention of the govt, you can explain that you tried to do everything right, and have the notes from the lawyer to prove it.

If you don't? Well, I recently discovered that if you are aware that you're not competent to handle something, and you don't seek advice, that legally means you deliberately chose to screw up. In money, that's fraud. In export sanctions, I think it's on the same scale as treason.

Regarding internet research: This blog post was written in Jan 17 2011. And the first thing it says in there? That this stuff changed recently. So it could change again. It could already have changed. Which means that if someone blindly follows this 3 years from now, they could end up having to spend some serious time explaining to besuited men that they're not a traitor, they're just daft enough to think that blog posts are legal documents.

Do me a favour for my own peace of mind. Go see a lawyer.

deworde
  • 1,892
  • 14
  • 21
  • Thank you very much for this detailed answer. It's just that I thought it's a clear case and easy to decide. I wrote in the comment to the question (above) why I thought this. – caw Jan 10 '12 at 17:31
  • Yes, and you could probably consult Apple directly in this case to get their rules, if you're only going to publish through the App Store, and if your App isn't doing anything particularly novel with the encryption. To be honest, I'd imagine that when you submit, if it's non-compliant, they'll throw it back. They'll have their own safeguards to keep the App Store out of sanctioned countries. They also have their own legal team to deal with this stuff, and that counts as dealing with a lawyer. – deworde Jan 10 '12 at 22:57
  • 1
    The question I answered was the more general "Which aspects do I need to consider when designing and publishing software that must meet the US export restrictions for cryptographic software?" For the Android/iOS specific stuff, then the people to consult would be Apple and Google. Send them an e-mail laying out what you plan to do, and they'll probably have a procedure all laid out for you. – deworde Jan 10 '12 at 23:03
  • But if something does go wrong, I maintain it'd be wise to have a local lawyer aware of your existence and what you were doing. Just in case. – deworde Jan 10 '12 at 23:05
  • Thanks for your additional comments. I will keep your words in mind ;) – caw Jan 12 '12 at 00:46
0

A slightly different answer, but why write the encryption code in the USA? Even if you write the rest of the product in the USA, it makes a lot of sense to do the encryption parts elsewhere. You can still sell your product in the USA, but you import into the USA, rather than export from the USA.

As an aside, in the early PGP days, the export rules were sidestepped by printing a book containing the source code, and exporting the book.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
  • 3
    This is a very bad idea. US Sanctions/Export regulations apply to any company registered in the US, and determine vendors as well as sales. Yes, with a very clever lawyer you might find examples of people scraping around them using crazy legal trickery, but DON'T. Big companies have to pay hundreds of millions of pounds if they screw this up. Small companies, everyone goes to jail, bankrupt or both. – deworde Jan 10 '12 at 09:45