How to submit an app to Apple’s App Store when it uses encryption | Hacker News Reader

How to submit an app to Apple’s App Store when it uses encryption

carouselapps.com

201 pointspupeno116 comments

Last year I learned that to publish an app in the App Store or Mac App Store, if it uses encryption of any kind and yes, HTTPS and SSL count, you need an Encryption Registration (ERN) from the US Bureau of Industry (BIS). Some people claim it's fine to lie to Apple, claim no use of encryption and get in the app store. I'd rather do it the right way.

When I started the process of getting the ERN, I quickly notice it was going to be a long and arduous process and that other people could benefit from the lessons I was learning the hard way, so I decided to document it all in a long blog post.

This is probably one of my most researched pieces ever. The whole process took about two months from the start, researching this thing called ERN, to getting the app published in the Mac App Store, satisfying that what I did was (more or less) correct.

Are you sure HTTPS counts? That seems insane to me.

I find that hard to believe too since Apple has basically deprecated HTTP is iOS 9 and OS X 10.11.

https://twitter.com/satefan/status/608093548827664384

Back when I was doing hobbyist iOS development (2009-ish) I asked Apple developer support about this, and they said it does. Worst part is it doesn't matter if you use a built-in system library like NSURLSession. Simply accessing an HTTPS URL from inside your app triggers this requirement.

Some people say the paperwork is easy to fill out yourself, but I was a college student and the legalese scared the crap out of me. And there was no way I could afford to consult a lawyer for a hobby project.

My only choice was to use plaintext HTTP for my app (which I wasn't willing to do for this particular app), or to restrict the app to the US and Canada, which doesn't require a government filing. I hated doing it, but I went with option two.

Edit: fixed typo.

That cannot possibly be true. I guarantee you virtually every REST app in the store uses HTTPS and none of them went through all of this. In the latest version of iOS you can't even load HTTP by default and must use HTTPS unless you put a special exception in your Info.plist. Everybody uses HTTPS, and nobody has to go through any of this.

So either you asked the wrong question, misinterpreted the answer, or you simply talked to someone who didn't understand your question or otherwise just didn't know themselves.

Thank you! It is definitely a misinterpretation. Apple makes https mandatory now and there is no way every developer would have to go through this process.

I think "only" apps that allow communication are affected. Websites that only pull generic data are safe.

If you are pulling through http and http only, yes. If you are using HTTPS, you are encrypting the requests that may contain arbitrary amount of data and the exception doesn't apply to you anymore.

Why do you say there's no way? This is US law, not Apple's policy, and US law is fully capable of being that dumb. (Whether Apple allows developers to lie to Apple and violate US law is beside the point.)

Debian's archive software used to send an automated mail to the US government every time a new package is accepted, just in case it involves crypto:

https://github.com/Debian/dak/blob/master/templates/process-...

(Looks like the government told them "Okay, okay, we don't care" at some point, but that was what they determined their legal obligation was after consulting with lawyers about what the law actually said.)

It's quite likely they don't enforce it very well.

I specifically asked them if using NSURLConnection (the standard, built-in URL library before NSURLSession) to access a URL over HTTPS qualified under the registration requirements. They told me, in no uncertain terms, that using any cryptography, including cryptography built into the operating system, meant I needed to register if I wanted to export the app outside of the US and Canada. I promise you, I didn't misinterpret. Though as you say, it's very possible the person I spoke to was wrong, or that their interpretation of the law was overly cautious and they've changed their policies.

Well, all apps in App Store are encrypted/signed. So they literally all use cryptography in that sense. Does not make sense.

I suspect the distinction is that the cryptography for encrypting and signing apps is done by Apple (and they've done all the paperwork for themselves).

First, if all your app does is download encrypted information and decrypt it, you might be covered under one of the exceptions.

Obviously the App Store is using HTTPS, so it's not. The App Store is a program by Apple and I'm sure Apple has an ERN to cover their asses.

They don't enforce it at all. Not even the US BIS really looks at your application to approve it as far as I can tell, because mine was approved instantly. They do have a lot of checks to make sure the record of your company and app are somewhat well formed.

When it comes to Apple, they don't check for this, they just want you to be on the record with either an ERN or the claim of no encryption, so that it's not their fault if the US government comes and says "hey, about all those apps you are exporting, are they using munition-level tech?"

It is true. There are a lot of exemptions, and not all uses of HTTPS require export registration.

However, if your app's main purpose has anything to with information security or sending/receiving/storing information, then you probably need ERN.

Define information, since information traditionally is just the meaningful analysis of some data.

It's whatever they mean by that word here: http://www.bis.doc.gov/index.php/policy-guidance/encryption/...

If you're not sure, and don't want to risk it, either do the ERN or get a lawyer to tell you it's not needed.

I'm not disagreeing with you, I'm pointing out that querying a RESTful page with any of the C, R or U parts of the CRUD process would involve transacting information, so you basically need to keep it as HTTP.

And that's why it's madness.

I don't disagree with you, either. But I'm pretty sure the legislative intent is to be able to thwart encryption in, say, instant messaging apps. Because terrorism, national security, etcetera. I don't agree with the means (it's futile), but being able to wiretap communications between people is the intent here as far as I can tell.

It's quite simple to implement an instant messaging app on top of CRUD, so "it's just CRUD" is not a valid counter against this type of politics.

I understand the intent, my point is that there's very few situations where you are not transmitting information if you have any connectivity whatsoever, so the law appears overly ambiguous and far-reaching. It should be more specific about its aims.

+1.

I'm beginning to wonder if the ACTUAL policy Apple is trying enforce w.r.t. HTTPS is if you were to roll your own suite of encryption tools (i.e. as opposed to using the OS's TLS/SSL implementations).

That would be far more reasonable. Especially considering, with iOS 9, HTTPS is now the default configuration for all traffic.

This is all pre-snowden, so I'd venture a guess that the ACTUAL reason is, well, NSA.

> That cannot possibly be true. I guarantee you virtually every REST app in the store uses HTTPS and none of them went through all of this.

Then they're breaking the law. Which is unsurprising, since the law is way more complicated than anyone expects, but unless you have a lawyer who has said "No, that's clearly not what the law means," you shouldn't expect that the law is sensible.

This is true, and I think a lot of this applications are breaking the rules. You can easily claim your app doesn't use encryption and Apple will accept it. They don't check to see whether it does or doesn't use encryption. But should something happen, Apple is clear of guilt because they asked you and you would be the one producing a false statement.

I read a lot of blog posts and looked at a lot of information and there's a general advice of "just pretend not to use encryption" or "https doesn't count" which is just wishful thinking from people that didn't want to use ERN and when you go dig deep enough it doesn't hold any water.

Yes, it does. I talked to legal as well as export compliance department at Apple and they confirmed this. Maybe they were being overly cautious but so was I.

With HTTPS, what puts you clearly out of every potential exception, is the fact that you are encrypting the requests. Someone asked about this in the blog and I replied with more information.

Were you using the built in web capabilities or embedding a library to handle the encryption? In theory Apple's methods for accessing HTTPS should be safe while embedding OpenSSL would not be (unless you linked to a shared object they deployed).

Yeah, I'd like to see this answered too. If OP was just using the built in WebKit browser this seems to have all been a big misinterpretation of the rules. If they did indeed roll their own browser with HTTPS, why?

The post is a very good guide to navigating that bureaucratic process either way though.

I don't think it matters where the encryption capability comes from.

The iTunes Connect FAQ says: “If your app uses, accesses, implements or incorporates industry standard encryption algorithms other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https.”

There are a lot of exemptions, but only using Apple's HTTPS is not one.

> industry standard

What about custom crypto then?

The line between encoding and encryption is blurry, so it would be difficult to enforce without being seeming arbitrary or capricious.

On the other hand, custom crypto will almost certainly be defective, so why bother prohibiting it it?

Sounds like Apple is the cause here, since export restrictions don't apply to things that are never exported. If you aren't embedding the algorithm then your code is not exporting the algorithm.

Holy crap that is a bureaucratic nightmare. Why does encryption even need to be registered in the first place? I don't see any point beyond the holdover of 'encryption is munitions' which is a pile of crap in the first place.

It was even worse before 2010, which was why Evernote used 64-bit RC2 encryption.

Throughout the process I found left-overs from the previous processes and yes, it looked much worse. The worst part for me is that there were steps in the process than though simple, they were not defined anywhere and thus it required me calling various departments to ask for clarifications.

Some say that this kind of policy is coming back.

   Crypto Wars Part II 
   The Empires Strike Back 
   Kurt Opsahl Deputy Executive Director of the EFF

https://media.ccc.de/v/32c3-7386-crypto_wars_part_ii#video

There is no first part of this specific talk. The talk is only called "Part II" because of the Crypto Wars of the nineties.

If you are interested in the "Part I" history

https://en.wikipedia.org/wiki/Bernstein_v._United_States

is a good starter.

Encryptions is munitions. It is the modern day "arms" that that the spirit of the 2nd amendment to the US constitution was trying to protect as a fail-safe to an overreaching corrupted government.

We don't need to bear arms anymore because we don't walk around dueling people at high noon anymore, but being an information based economy and information based society, encryption is the new gun in the wild world web.

We continue to need to bear arms of all sorts, equal to those that the military uses. As you pointed out, the purpose of the 2nd amendment was to avoid tyranny in a powerful central government. As long as the (federally funded & led) military uses firearms, responsible civilians _must_ also keep & bear them.

If that is so, then we have already lost. No firearm held by the citizens can compete with the firepower of the military of today.

The spirit of the amendment may have been in the right place and surely worked when the constitution was written but we live in a very different world now and if you still think the an armed citizenry will avoid tyranny, you need to go to youtube and see what the military can now do.

I believe the right to bear arms has been interpreted not only to mean the individual right to own and operate firearms, but also the right to form militias, or paramilitary organizations.

It is unlikely for a paramilitary organization to compete with the armed forces, but in a state where the country is stressed and divided, I don't think the armed forces would stand as a fully united organization. However, while I do concede that my argument is weak, I also assert that it is not nil.

If you really wanted to oppose the government you'd encrypt your communications. Clearly that's s greater threat since government so vehemently wants to deny that (it's in their self interest to increase their power).

Are you sure about that? Look at Iraq. Also, while soldiers in the military might be fine oppressing a compliant populace, how many will jump ship if they are forced to wage actual war on their countrypersons?

All fine and well until the drone army comes online.

Only half kidding.

What citizens lack in firepower they make up in numbers. Just the 12.5 million registered hunters in the United States exceed the number of active duty military by an order of magnitude.

There is no possible way that the military of today, with all its tanks and bombs and drones and planes, could even attempt to hold any large portion of America under martial law.

When everyone has guns, the police have to have guns. Not only that, they're scared. All The Time. Traffic stop? Might have a gun. Stop and search? Might have a gun.

One fuck up and you've got death, permanent pain, or some other outcome that's pretty fucking unpalatable. (I assume that at least cops in the US have gold plated health insurance...?)

Here is my question. How much of the problem endemic to US police is on account of a culture of fear. Citizens should not fear the police, but that works both ways.

I'm just spitballing here.

The purpose of the second amendment was to avoid tyranny in a powerful central government _over the individual states_. The current (2008) Supreme Court interpretation of the second amendment is controversial because it largely ignores the "well regulated militia" text.[0]

[0] https://en.wikipedia.org/wiki/Second_Amendment_to_the_United...

Interpreting the "well regulated militia" text as limiting the right to state militias is an anachronistic, twentieth century attempt to read modern sensibilities into the text. In the eighteenth and nineteenth centuries it wasn't even a debate: the right of individuals to bear arms was understood simply to be the manifestation of their natural right to self defense. Consider texts contemporaneous with the constitution and written in similar places:

Pennsylvania State Constitution, 1776: "The right of the citizens to bear arms in defense of themselves and the State shall not be questioned."

New Hampshire State Constitution, 1783: "All persons have the right to keep and bear arms in defense of themselves, their families, their property and the state."

And, of course, the second amendment itself: "A well regulated militia being necessary to the security of a free state, the right of the people to keep and bear arms shall not be infringed."

Most other first-world nations would disagree with you.

This classification might by a blessing in disguise.

The supreme court disagrees with you (see District of Columbia vs. Heller) re your need to bear firearms. But if encryption is the new firearm, that might be an important ruling for crypto.

Same idea as in http://xkcd.com/504

> The supreme court disagrees with you (see District of Columbia vs. Heller) re your need to bear firearms.

He's talking about his need to bear firearms. SCOTUS in Heller was talking about his right to bear firearms. There's no disagreement here at all.

I read it as the following:

- I don't need firearms.

- I need encryption, as it is the equivalent of a weapon in the information age.

- I have a right to bear arms

- The Feds consider encryption to be a munition.

If these assumptions are true, I think you can make an argument that wielding strong encryption is conceptually equivalent to having a rifle.

Because you might be exporting it to an un-friendly country.

Don't try to apply logic here -- "But can't they just compile openssl or just use Linux!? or some library..." -- this is government contracting and security world, regular logic doesn't work here.

what if I am working in un-friendly country trying to import it to friendly countries via the App Store?

For exporting to friendly countries via App Store, you'll need an ERN. I'm not sure if the App Store will accept submission from unfriendly countries. It depends which one I guess.

Apple itself probably doesn't really care. Just needs to cover its ass in case Uncle Sam looks and asks questions. They can now say "We have enabled these checks and features on our side".

Bureaucratic nightmare? Don't you think that's an exaggeration? Sure, the government's web site UX is atrocious, but at the end of the day, it's just a couple of web forms and E-mail verification, similar to signing up for any web site. Try to legally immigrate to the U.S. and then come back and tell me that this web site is a "bureaucratic nightmare".

I agree that US migration processes are a bureaucratic nightmare also. I don't think it's an exaggeration when I phrase the term as 'overly unnecessary bureaucratic process that causes people incredible frustration'.

Note that the OP said that the list was the effort of months of trying to understand and negotiate the system. Just because it appears to be 'a couple of web forms and email verification', it's in no way similar to signing up for a web site because it's behind so much opacity. You can't judge the effort involved in producing something simply by its final output.

I think I remember reading that if you're using Apple's APIs and frameworks (like their builtins for HTTPS) then you don't need to go through this rigmarole.

From the screen shot of Apple's app submission: "Select yes even if your app is only utilizing the encryption available in iOS or OSX."

I've always interpreted "(ii) your app uses, accesses, implements or incorporates encryption for authentication only" as our uses cases for using HTTPS and thus said that I am exempt.

Unless you are using HTTPS with NULL encryption algorithm, your bytes are encrypted and decrypted, so it's not "authentication only". I think that you can use NULL encryption algorithm and in this case only authentication will be performed. But I'm not sure that standard library will allow to use this algorithm.

In that case, simply saving a file would also count as encryption now, since iOS devices are encrypted...

I'm far from an expert on this area, but I know there are exemptions many apps can qualify for. The most notable of these is that the encryption is limited to authentication [1].

[1]: http://stackoverflow.com/questions/2135081/does-my-applicati...

I would have thought this covered https.

I'm pretty sure "limited to authentication" means that the data is transmitted in the clear but covered by a signature. HTTPS actually encrypts, so it wouldn't count.

Could you not also argue that ongoing use of HTTPS after authenticating yourself with the server is to ensure the response is coming from who you intend (i.e., the server authenticating itself to you)?

IANAL, but if you assume law matches cryptographic reality: there's such a thing as the NULL cipher, which most SSL stacks don't support (at least by default) because it's a big footgun. It will let you have traffic that's authenticated but not encrypted.

What would you rather do, argue with the US government or get an ERN and focus on your business? I know my answer ;)

I talked to a couple of people at Apple and they explicitly told me that use of HTTPS is not covered under the exception. I think that exception was designed to authenticate licences of software. Programs that phone home, get a toke, and decrypt it to verify you paid for it, but that's just a hypothesis.

I am confident that it is not true and the apple dev support rep you talked to have no idea what they were talking about.

you'd think that this is a pretty frequently asked question though, no? how could apple dev support personnel not understand/answer basic questions that affect a significant portion of apple devs?

No I think most devs don't interpret the rules as the OP does. Connecting to an https endpoint is clearly not what they mean here.

On advice of counsel, or on the intuition that the US government's laws about crypto cannot possibly be that dumb? Because yes, the laws are in fact that dumb.

I talked to the export compliance department at Apple. There's a chance that they say "yes, get an ERN" because they have nothing to lose and it's safer for them and in fact, there's no need for it. But I doubt it. I will consult a lawyer to make sure my whole process is good if people want me to get ERNs from them (an idea some people floated with me).

Are you US-based?

The OP and his company are based in London.

This seems to be only for US based developers, I can't remember having to fill in more then a handful of radio buttons regarding crypto when I submitted an iOS app as a Dutch developer.

From the blog post the developer's to be based in the UK.

Nope, this is for everyone. Apple is exporting your app from US, so they need this paperwork from you. The only other options are:

* send Apple a paper promising that you will only distribute your app in US and Canada stores, discarding all other markets.

* make your encryption use insecure 64-bit keys.

* make your complete app open source.

* (some other options, such as when using encryption only for authentication)

If you lied to Apple and if US government finds out you export encryption without registration, and if they care enough, they will fine you (http://www.theregister.co.uk/2014/10/17/intel_subsidiary_cry...)

Only US citizens are likely vulnerable to the attempts to fine though.

But everybody is vulnerable to Apple pulling your app because it's non-compliant.

Where is your blog?

https://carouselapps.com

At the same time Apple encourages the use of HTTPS with App Transport Security (ATS).

   Starting in iOS 9.0 and OS X v10.11, a new security feature 
   called App Transport Security (ATS) is available to apps and is 
   enabled by default. It improves the privacy and data integrity 
   of connections between an app and web services by enforcing 
   additional security requirements for HTTP-based networking 
   requests. Specifically, with ATS enabled, HTTP connections must 
   use HTTPS (RFC 2818). Attempts to connect using insecure HTTP 
   fail. Furthermore, HTTPS requests must use best practices for 
   secure communications.

https://developer.apple.com/library/ios/documentation/Genera...

Does that mean that in the future nearly every App will need the ERN?

This is a really interesting point, I was caught out by this during an update. All of a sudden my REST client broke. Took a little digging to find out Apple had enabled HTTPS by default.

Given this, it would seem odd that you would need to apply for an ERN (is this true for app outside of the US?)

My personal opinion, which is not that of a lawyer, is that yes, nearly every app developer will need an ERN.

I read this entire article thinking it was overly elaborate satire, but there was no punch line at the end, and the links are actually valid.

The TP pool memo[1] in Neal Stephenson Snow Crash seems sane by comparison.

[1] http://soquoted.blogspot.com/2006/03/memo-from-fedland.html

Not everything that "just uses HTTPS" necessarily needs ERN. Here's "note 4" which exempts a lot of apps: http://www.bis.doc.gov/index.php/policy-guidance/encryption/...

A big part of our app was "sending, receiving, and storing information", so we weren't sure this exemption would apply to us. So, we did the ERN anyway, and it took a couple of days calendar time, and a couple of hours of working time, IIRC.

By the way, nowhere does it say that using HTTPS is fine if you just use Apple's APIs and frameworks. I don't think it's relevant here.

> Note 4: Category 5, Part 2 does not apply to items [...] meeting all of the following:

> (a) The primary function or set of functions is not any of the following: [...]

> ...... (3) Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights management or medical records management);

(Emphasis mine.)

Triple negative - now that's something. And DRM and the entertainment industry gets a special case, isn't that great?

I would have thought that DRM is a loophole you can drive a truck through. As long as any of your data is of value, you can claim the reason for encryption is DRM. Even if you let the end user have access to all data, you could always send some sort of DRM heartbeat.

No loophole! It only count's if you exclusively need encryption for DRM. Not for other stuff like, to protect your users chat communication for example.

I don't see the word exclusively. If you had a chat application you could protect the user content by sending along a DRMed ping.

Great guide. If you are into these sort of guides of how to deal with the US government I have written a couple for the W8-BEN-E form [1] (you need this if you have any US customers) and also for registering to do business with the US government [2]. These are biased towards Australians, but they should be helpful for others too.

1. http://www.tillett.info/2015/06/20/how-to-complete-w-8ben-e-...

2. http://www.tillett.info/2015/12/01/how-to-register-an-austra...

US customers here must mean that if you sell directly to US customers. If you sell via App Store to end users in US, then this is not needed, because Apple will be your customer (Apple Luxembourg for Europeans), not the end user.

Yes this is true, but lots of people sell directly to US customers. As soon as you do you have problems :)

Not specific to Apple. Same thing has to be done for any other app store, like Google's. Some mentioned that there is an exception if you use OS libraries for encryption. I think that's not the case, but I think using some third party SDKs like Game Center (for which I guess the providers did the paper work) is excepted.

> any other app store, like Google's

Not sure. This looks like a US-centric, bureaucratic thing. I doubt that F-Droid https://f-droid.org/ requires this kind of nonsense when submitting apps.

Yeah, that's true. I meant US company app stores. But some other countries have these kinds of rules. I know of France.

That is correct. It applies whenever a computer program goes from US soil to non-US soil. Wether it's Apple's App Store, Google Play or carrier pigeon, it's the same.

How is this different from Android apps distributed through Google Play? Legally I mean, why don't Google Play do the same thing?

Apple requires the ERN because Apple is very US centric. For Google, there might be cases in which the ERN is not required because the app never leaves the US (because for other countries it comes from other countries).

Apple is required the ERN to cover their asses, I believe. The ERN is required by the US government, so, if you don't have it, you are breaking the law whether you are using Google Play or Apple. So, you should get it for Google Play too.

To add to that, maybe Apple is more liable because of their promises to check for quality and problems in the store, while Google allows more things in it. That just means a change for them, you, as the app maker, are always liable.

If I inform everyone that their iOS app uses AES, SHA-1, and RSA at the lowest level (codesign and Fairplay DRM), does everyone have to register? I think a plain reading of the question poised by Apple would require a "Yes" answer.

There's an exception in the law for DRM

For cross reference, here is another list of steps based on our experience. It took about 3 days.

https://www.chatmap.io/blog/iPhone-iTunes-ERN-Encryption.php

Which cryptographic algorithms are included in Atom Electron and NW.js frameworks? Does the page [1] list all of them?

[1] https://www.chromium.org/blink/webcrypto

ignoring anything else, that process seemed pretty smooth to me, esp for government. Sure you hit a few snags, but the main one (a lost email) could've happened signing up anywhere.

I think the process had two issues. The main one being several steps that though simple, were not specified anywhere, so, figuring them out took a lot of time and phone calls. It's like someone tells you to drive from point A to B, that's easy, but they don't tell you were the car is.

The second problem was a lot of jargon that was in my opinion unnecessary and was internal US government leaking to the end users and you had to learn it to understand the documentation about what to do. Figuring out what SNAP-R stood for took me way to long and it's nothing more than a website registration (from my point of view).

How does this apply to non-US based app publishers?

Am I legally exporting crypto from the US if am not in the US?

Yes, this is explained in Apple's FAQ on the issue - they have servers that are distributing your app from the US, thus you are exporting crypto from the US.

Don't you wish you hadn't surrendered software distribution authority to a single faceless corporate party? When nobody tried to demand bullshit crypto paperwork?

Remember when you could distribute software yourself without getting threatened[1]? Remember when platform vendors didn't take a 30% cut of everything you earned just because they wrote an OS? Not even Microsoft was that evil.

I hope you enjoy the world you've built, hipsters.

[1] See the f.lux Apple distribution debacle

You are off topic.

This is unrelated to Apple and it's AppStore. Even if you sold this on your own, you'd be subject to the same rules.

https://www.bis.doc.gov/index.php/policy-guidance/encryption

There is an important difference, though. Small companies and individuals often fly under the radar of wacky bureaucratic rules like this, whereas big companies are more visible and are stuck with them. By routing all the small-timers through a big company, they can no longer do that.

You might say, small companies should be following these rules regardless so this is just as well. And I'd probably agree. But it's still a pretty big difference.

No, most people wouldn't.

Calm down. It is the US Govt requiring this form. Apple is only passing along the requirement.

Reply on news.ycombinator.com