Apple Export Regulations on Cryptography
Bureaucracy and the light at the end of the tunnel
2020 UPD: If you want to know how to file an annual self-classification report for your app that uses encryption, look into Apple export regulations for Themis for the current procedure and useful links.
Apple’s regulations for exporting apps that contain cryptographic code to the App Store could be described as hazy at best. At Cossack Labs, we like to see security done properly, and that includes understanding how to report crypto to authorities, so we decided to delve deeper into the subject of legalising your crypto. It turned out that things have changed considerably for the better since autumn 2016.*
Previously, any encryption used in an app — including with HTTPS and SSL — needed an Encryption Registration Number (ERN). Many developers didn’t realise that the crypto in their apps needed certification and unknowingly violated the app submission guidelines by deciding to skip the registration step altogether. Many also argued — why bother at all? — since Apple is famous for the “presumption of guilt” approach and any time any app can be suspended or “frozen” for seemingly no reason at all.
The Problem
Since you’re downloading apps from US servers, Apple treats the apps in the App Store’s roster as such that can be exported to other countries. The export laws of the USA require products containing encryption to be properly authorised for export (Export Administration Regulation) and promise severe penalties for disobedience. In the developer’s case, such penalties will mean the app being ‘frozen’ in the App Store and the developer’s account suspended — temporarily or permanently.
Previously, any kind of encryption used within the app needed to undergo several registrations and verifications for it to finally be submitted to the App Store. The most archaic way of registering in the 2000s was the “CCATS” (Commodity Classification Automated Tracking System). Issued by the US Bureau of Industry and Security, this classification needed tons of paperwork, an exercise in cursive handwriting, fax, snail mail, and about 2–3 months of waiting time — if you were lucky (curious ones can find the whole burdensome process as it took place in 2009 described in full detail here).
Later on, some parts of the process were digitised so you could save on paying international shipping fees ($80+) on mailing the paperwork to BIS for verification.
When in the summer of 2010s the necessity of getting CCATS was substituted with ERN (Encryption Registration approval from BIS) — 60+ days of waiting and endless recursive registration forms — it became a huge step forward. Now you could at least perform most of the registration on-line. For any kind of encryption used in your app, you now needed to have an ERN and to file annual self-classification reports, in accordance to the Section 742.15© of the EAR (you can read the description of the whole old-school procedure necessary in 2011 here).
So if the developers were outright terrified by the prospect of getting the CCATSs and only large firms (think Dropbox or someone that size) could actually dedicate time and effort to proper registration, with the coming of ERN it seemed less impossible to register a mobile app containing cryptography. But what kind of crypto was actually worth the trouble?
Most developers thought that the use of standard Apple or open-source encryption was not a reason to indicate you’re using cryptography. No one understood what the real crypto is, so no one filled in the forms. HTTPS, SSL, TSL, and the likes were overlooked. When asked about cryptography in their app, the developers would fail to declare their app properly.
However, even HTTPS and SSL still needed ERN! Apple’s own description of what the use of encryption included didn’t help too much:
“Use of encryption includes, but is not limited to:
- Making calls over secure channels (i.e. HTTPS, SSL, and so on)
- Using standard encryption algorithms
- Using crypto functionality from other sources such as iOS or macOS
- Using proprietary or non-standard encryption algorithms.”
It felt as a no-win situation — you’d face a risk of your app being rejected after all the hard work you’ve done registering the crypto. At the same time, you were risking an immediate “freeze” or suspension of your app if you didn’t register it properly. Sure there was a number of exemptions that could free many developers from performing the full proper registration, i.e. (as formerly stated in the depths of these regulations), but it was too hard to figure out if you actually qualified:
“(i) if you determine that your app is not classified under Category 5, Part 2 of the EAR based on the guidance provided by BIS at encryption question. The Statement of Understanding for medical equipment in Supplement №3 to Part 774 of the EAR can be accessed at Electronic Code of Federal Regulations site. Please visit the Question #15 in the FAQ section of the encryption page for sample items BIS has listed that can claim Note 4 exemptions.
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
Please review Note 3 in Category 5 Part 2 to understand the criteria for mass market definition.
(v) your app is specially designed and limited for banking use or ‘money transactions.’ The term ‘money transactions’ includes the collection and settlement of fares or credit functions.
(vi) the source code of your app is “publicly available”, your app distributed at free of cost to general public, and you have met the notification requirements provided under 740.13.(e).”
Most developers speak Code but don’t speak Lawyer, so they just skipped the registration step, too, hoping for the best, violating the US export regulations, and risking all kinds of penalties from Apple.
Inner conflict
Since the release of iOS 9, Apple has been actively enforcing the ubiquitous use of HTTPS (through their App Transport Security feature — ATS) and promoting security for users and communications. At the end of 2016 ATS has become mandatory for all developers who submit apps to the App Store, which was announced during an annual WWDC presentation. Apple also encouraged developers to use more advanced means of encryption (i.e. AES, TLS) as opposed to using older DES and SSL, etc. This didn’t quite fit with the actual state of affairs — the multipage registrations and ERNs were still required.
However, things started changing fast after September 20, 2016. At first, only the HTTPS protocol was expelled from the list of encryption tools subject to classification. And then, in late 2016, the registration forms and norms changed so rapidly that developers who tried to register their apps with encryption had to personally call the people from BIS to find out that the old procedures or registering HTTPS/SSL were put on hold, and soon to be abandoned. Those who still tried to register the old way found that the old forms changed and looked nothing like in the past. Then the new BIS regulations followed and it stated that:
“Publicly available” encryption source code is not subject to the EAR once the email notification per section 742.15(b) is sent.
A common example would be open source encryption source code available for free on-line.
“Publicly available” encryption object code is not subject to the EAR when the corresponding source code is also “publicly available” and has been notified as specified under Part 742.15(b)”.
It finally declared that the developers that use popular (open source) means of encryption will still need to indicate that they are using encryption, but won’t need to have an ERN.
Also, according to Electronic Code of Federal Regulations:
“(b) Publicly available encryption source code — (1) Scope and eligibility. Subject to the notification requirements of paragraph (b)(2) of this section, publicly available (see §734.3(b)(3) of the EAR) encryption source code classified under ECCN 5D002 is not subject to the EAR. Such source code is publicly available even if it is subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code”.
All that is needed from a developer who uses Apple standard or open source encryption in their open source app now is to file an annual self-classification report with information about the app every January to the email addresses stated in the paragraph below:
“(2) Notification requirement. You must notify BIS and the ENC Encryption Request Coordinator via email of the Internet location (e.g., URL or Internet address) of the publicly available encryption source code classified under ECCN 5D002 or provide each of them a copy of the publicly available encryption source code. If you update or modify the source code, you must also provide additional copies to each of them each time the cryptographic functionality of the source code is updated or modified. In addition, if you posted the source code on the Internet, you must notify BIS and the ENC Encryption Request Coordinator each time the Internet location is changed, but you are not required to notify them of updates or modifications made to the encryption source code at the previously notified location. In all instances, submit the notification or copy to crypt@bis.doc.gov and to enc@nsa.gov.”
A note from Cossack Labs — the email address crypt@bis.doc.gov is sometimes substituted for crypt-supp8@bis.doc.gov at the https://www.bis.doc.gov/ website so we advise sending the self-classification report to that address, too to stay on the safe side. See this page for more details on filing the reports.
The bad news is that if your app is using non-open source encryption (algorithm implementations), you’ll need to obtain the CCATS approval from BIS. Yes, that old scary one with 250+ pages of regulations. As this demand seemingly became an even rarer practice than before, the link to BIS from Apple in the documentation is broken (as at the moment of writing this) and Apple suggests that you seek legal advice or consult BIS directly. You can read the details on how to file and Encryption Classification Request (CCATS) following this link.
The good side to this is that you want trusted open-source algorithm implementations anyway, and don’t want to implement them yourself. So you are better off using community tested cryptographic libraries that simultaneously free you from having to submit anything but an annual report rather than reinventing the encryption wheel (which is plain unsafe, to say the least) or using obscure closed-source cryptographic algorithms.
Registering Apps That Use Themis
If you’re using Themis as your means of encryption within your app you’re submitting to the App Store, your encryption falls under the “open source” exception (although if your app is not open source/distributed free of charge, we strongly recommend that you seek legal advice):
“The source code of your app is “publicly available,” your app is distributed free of cost to the general public, and you have met the notification requirements provided under 740.13.(e).
In order for your app to qualify for TSU, as detailed in 740.13(e)1, the entire source code and the object file has to be open source, your app must be distributed free of charge to your customers, and you must provide the U.S. government the location of your source code.”
Themis is a free cryptographic library that builds on existing, community-tested cryptographic instruments (OpenSSL, LibreSSL, BoringSSL, depending on the target platform). It is open source and Apache 2 licensed, with its full source code publicly available on line on GitHub. This means you should indicate that you’re using encryption and only submit annual self-classification reports.
Our Summary
We at Cossack Labs rally for wide adoption of proper cryptography. So it made us kind of sad to see what Apple was doing. On the one hand, Apple is pushing developers to improve the security of their apps — like putting HTTPS everywhere — on the other hand — the procedures for developers who wanted to implement ‘real’ security and cryptography remained obscure and with contradictory guidelines. Having discussed this a few times with Themis iOS adopters on various occasions, we’ve realised that we know enough already to share with the community. Especially now, when it looks like the things have really changed for the better.
We strongly advise adhering to any legal regulations around cryptography and recommend carefully studying the Apple’s most extensive document on the matters of encryption and exemptions before trying to submit your app that uses any kind of encryption. Unfortunately, even this extensive document still leaves many points unclarified, features broken links to BIS (as at the moment of publishing this article) and advises you to consult the US BIS directly when in doubt.
If you think that your app was suspended by Apple for no other reason than the encryption you used, don’t just give up, but try writing or calling to the Apple Resolution Center to communicate directly with the App Review team. If it doesn’t help, try to submit an appeal.
Make your life easier and rid yourself of a reason why your app might be frozen and your account suspended. Register your crypto!
If you have a story to share about recently submitting an app that uses encryption to App Store — we’d love to hear from you! Especially if you used Themis for encryption. Please reach out to us via info@cossacklabs.com or @Cossacklabs.
Disclaimer:
*This is our subjective take on the issue as we see it, valid at the moment of publication in June 2017.
Cossack Labs Limited will not be responsible for any loss or damage whatsoever caused resulting from following the instructions or links provided in this article. The information provided here is not confirmed by Apple.
UPD: Updated in September 2018 to refresh a couple of older links and email addresses.
UPD: Updated in April 2020 with link to exact example of BIS annual self report.
