When submitting an app that contains cryptography, I know there's a checkbox you must check, as well as subsequent questionnaire you must answer. And if the app contains cryptography you need to go through complex Exporter Registration and Reporting process.
There are three specific cases I'm curious about:
1. Cryptocurrency wallets
One of the "exemption" clause says:
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
Does this exempt the app from having to go through all the complicated government approval process? Most cryptocurrency wallets only use cryptography for signatures and authentication, but I'm not sure how this applies to this case.
Simply put, do all Bitcoin wallet app developers have to get government approval before submitting the app?
2. End-to-End encrypted messaging apps
How about end-to-end encrypted chat apps? Do I have to go through the approval process?
I'm talking apps like Signal and whatsapp.
3. Does WKWebView + Webcrypto count?
What if I'm using WKWebView which contains access to webcrypto API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API inside the app, does this count as "contain encryption"?
From Apple FAQ:
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
You didn't specify source of your "exemption", but I guess it is not from Apple guidelines.
I would say that your cases are using encryption or crypto so are in scope of this guidelines.
I found some more informations here - maybe will help you.
Related
This might not be a direct code question, but it's one that comes up frequently on SO and I find very useful to read.
App Store - Help answering “Missing Compliance” (using Expo + Firebase)
Does my application “contain encryption”?
ITSAppUsesNonExemptEncryption export compliance while internal testing?
I don't live in the US and therefore don't navigate freely in their law system or stays up to date with changes. But using american products and platforms like the Apple App Store means that I have to comply with the national rules and policies.
There is this one thing about encryption compliance whenever I submit to the app store. It always ask me if I'm using encryption. The answer is yes - since fetching like OTA updates are https. The SO questions are often so yes to the first and no to the rest if https is the only encryption used.
BUT what if you are using encryption to authenticate a user. Then it seems like it has to be yes to encryption and yes to this question:
Does your app qualify for any of the exemptions provided in Category 5, Part 2 of the U.S. Export Administration Regulations?.
Here is what I don't get. If this is the case for US compliant mobile apps - do I need to report to US authorities if I deploy a web site that do the exact same type of authentication logic
There is a lot of great material on how to build a good authentication system - but have never come across a mention of
"BTW ☝️ don't forget to report to the US authorities that you authenticate your users with encryption"
First IANAL, so take this a professional experience, not legal advice. There is no requirement to notify any specific US authority that you use encryption in your auth process. I suspect that these questions are asked because of the ITAR Regulations that deem certain kinds of encryption to be "arms" and therefor not legally exportable from the US (Discussion of ITAR and Crypto here) given you are already in (presumably legal) possession of whatever encryption scheme you are using, these rules do not apply to you. There may be more specific regulations if you have an affiliation with the military or intelligence agencies of the US or any other country.
Basically, I'm using Firebase authentication SDK in my iOS app to provide secure login to users and trying to upload the app to TestFlight. Upon upload, I'm seeing this question below that asks if the app uses cryptography but then there are exceptions where some cryptography algorithms are exempted? Please advise on how to answer in regards to using Firebase Auth SDK.
Thank you!
"Is your product designed to use cryptography or does it contain or incorporate cryptography?
Please answer “YES” to the question even if your app uses or accesses encryption from another source, e.g., iOS or Mac OS X.
If your application does not use, access, implement or incorporate encryption, you can answer “NO” to this question and you can continue with the process of uploading your binary.
If your application does use, access, implement or incorporate encryption, it may be necessary to submit confirmation of approval by the United States Government and an approval from French authorities if your app is going to be distributed in France."
The Firebase Auth SDK does not currently make use of cryptography on the client. The SDK is now open source on github, please feel free to take a look at the source code.
https://github.com/firebase/firebase-ios-sdk
I am using https://github.com/ideawu/Objective-C-RSA this library to encrypt some data using a public key.
Current live app is already using https for all calls. I am confused as to how will my answers on export compliance change on version update?
Also, do I need to add export compliance documentation on itunes connect?
Additional details:
I am using only encryption from the library.
Then the encrypted string is sent to server. The backend server is responsible for decryption using private key.
The encryption is NOT for authentication purpose. It is used send sensitive data to server
Turns out my use case was falling under the money transactions category. As per the export guidelines, this category is allowed to use cryptographic algos.
All I had to do is mark "Yes" to the below questions during submission.
As per FAQ on iTunes Connect:
Does your product qualify for any exemptions provided under category 5 part 2?
(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.
Keychain access groups and application groups are both segregated using the app's team id.
Named pasteboards are also sandboxed using the team id.
Kerberos SSO seems to work well, but opening the KDC to the internet is a security hazard so it can only really be used together with a VPN.
The Shared Web Credentials API works well between native apps, but has intrusive popups showing up every time you attempt to access or even just check for the existence of credentials.
libdispatch can send messages to arbitrary apps, but the payload is limited to 64 bits and the recipient app must be currently running.
No unique device identifier that could be used to derive a key for a cloud-based encrypted KVS can ever be shared between apps not on the same team id.
…is there any way to share credentials (or any data, for that matter) between applications signed with different team ids, on recent versions of iOS? Apple doesn't allow migrating IAP, Passbook, etc to new team ids and it's blocking my team from implementing SSO between apps with historical team ids (M&As, etc).
You can open the app with deeplink that will reopen the other app with the infos you want to pass along. That's good for login but can be cumbersome if you want to pass a lot of infos back and forth.
We have developed a REST API which is consumed by two apps: one running on Android and one on iOS. The API is not public - we built the apps in-house.
Does it make sense to give a different consumer key to each different platform (e.g.: one for iOS on smartphone, one of iOS on tablets, one for Android on smartphones...)?
One advantage of having several keys is being able to easily do device segmentation analysis (however, that can be done in other ways).
Any strong point for one of the two strategies?
What are the advantages and disadvantages?
Thanks.
In the context of OAuth, any application that runs on an end-user device (including iOS and Android devices) is known as a "public" client because the secret key is distributed along with the application.
This is in contrast to a server-side web application, in which the key can safely remain secret. Only permitted developers and operations staff have access to it. In the case of applications that are distributed to devices, even with obfuscation, it's impossible to guarantee that the secret won't be exposed to unauthorized parties (essentially anyone with your app in their pocket), effectively rendering the key publicly available.
Given that, there is very little significance, from a security perspective, for assigning unique client IDs and secrets to devices that access your API. A malicious developer could very easily use the public credentials to pose as an "approved" app.
As you note, you can use a client ID to do device segmentation, but there are other ways to do that as well, such as a User-Agent header that don't convey misguided security implications.
In summary, there is no real benefit to issuing unique client IDs to apps based on platform. However, it is important to consider how public clients factor into the security concerns when authorizing access to your API.
If you will make app developers to use several OAuth consumer keys for each platform then developers will not be happy! Developers will have to somehow manage these keys to your service. What if app developers need to reissue the keys? If they launching app on new platform? How much additional effort of you these developers will need to maintain the keys?
Also, consider some platforms that you are not aware of: new mobile OSes, strange devices, unusual use cases. Do you want to limit and control all variants of uses of your service?
One of the reasons why you might still do that is that you can sell your API services separately for each platform (and probably with different prices).