My iOS App ONLY makes HTTPS calls to send data from the app to the server. And I also use bcrypt to encrypt passwords on the back end. Would I need to submit a classification report? This is what I see when I click 'No' when asked to provide export compliance information.
And this is what I see when I click 'Yes' and 'Next'
I am located in Asia, so which options should I check? And would I need to submit a self classification report if my app only makes HTTPS calls to send data to the server and only uses encryption in the back end?
The connection between your app and your server is encrypted when you make HTTPS calls so your app is using encryption.
Your app is subject to Export Administration Regulations when you make your app available to users outside of the U.S. and Canada because this means you are exporting an app using encryption from the App Store servers located in the U.S.
You do need to submit a self classification report between January 1st and February 1st.
Related
I have a piece of software which I would like to lock down using a license key. This key contains the expiration date in unix timestamp format. To check if the license in valid in the software, I compare the current unix timestamp to the expiration date in the license key. Here's the tricky bit: I want to be able to allow the user to run the software offline without making a request to a server to validate the license (in essence, the user shouldn't require an external network connection to run the software).
Are there any strategies which can be used to prevent the user from simply changing the clock on their machine which essentially bypasses the license expiration?
I work for a company that provides two solutions for the problem of node locking a license to a device when that device does not have an internet connection.
I'd also start by saying that there's actually two parts to your question: How do you perform a license activation on a computer that does not have internet access, and how do you perform the license checks on the local machine, once you bound the license to that device.
If you don't node lock the license to the device, then anyone with the key you generated can just use it on an unlimited number of machines. For this you still need a way to communicate a device identifier back to the license server, even if it's not done through a direct internet connection.
Our first solution tackling offline node-locking does basically the same thing that our online activation does, except it's through a series of request / license files being exchanged between the client machine and the license server instead of Server-to-server interactions. The gist of it is as follows:
cyrusbehrVendor issues a license key for cyrusbehrApp and gives it to the end user.
End user enters it into the app, which generates a request file containing information on the device, and the key which is being used to activate the app (the file is / should be encrypted). The file is actually generated by the SDK that we supplied to cyrusbehrVendor, who imported it into their project and is shipped with the app. The end user takes this request file and uploads it to the License Server using our offline licensing portal.
The Offline licensing portal returns a license file that contains all the license information associated with that key, and can only be used by the device that requested it. The End user inputs this license file back into the app, which gets parsed by the SDK, which is used to configure the state of the application (according to the entitlements granted by the license). The SDK will also create a local license file to check against each time the app is run, for example.
Most Software developers might find this a "good enough" solution to offline licensing that isn't toooooo inconvenient for the end-user. However, if your requirement also does not allow for files to be exchanged, or files cannot leave the target machine, we also provide an air-gapped solution to unlock license policies shipped with your app. We designed our air-gapped license activation in the following way:
You ship your app with our SDK along with license policy files.
You issue license keys for your app that can be used to unlock a specific license policy.
through a series of code exchanges (rather than file exchanges), a license gets bound to a device, and allows a specific license policy to be used.
Concerning your question about local license checks and having some sort of anti-clock tampering mechanism, you can do the following:
Read and Store a time stamp of the system clock on the last license check. If a subsequent license check has a timestamp that occurs prior to that time, then you know there's something going on with the clock being changed. You can either disable the license, or just throw an exception and don't let the app run until a license check with a timestamp in the future. Also, be sure to use UTC, since timezone changes can and do happen.
I'm publishing my app to App Store and I have doubts regarding the "Missing Compliance" step.
Here's some info about the app:
I used Expo (Managed workflow). That means I don't have direct access to Xcode.
It's a simple 2D video game, free, with Expo ADMob. You can pay to remove Ads.
It requests a camera and library permission (to take a picture if the player wants). No Notifications, or any other extra thing.
It uses Firebase (Database, Storage, and Analytics) and Sentry. (for HTTPS connections)
I didn't manually include any "encryption" custom thing (that I'm aware of)
I'm publishing the App from Portugal, Europe. I plan to publish it worldwide, if possible.
Does your app use encryption? I didn't code anything related to it... but I assume I should say yes, right?
Does your app qualify for any of the exemptions provided in Category 5, Part 2 of the U.S. Export Administration Regulations?. My app is a simple JS video game, with MobAds. Should I say yes or no?
Does your app implement any encryption algorithms that are proprietary or not accepted as standards by international standard bodies (IEEE, IETF, ITU, etc.)? I did say no... is it right?
Does your app implement any standard encryption algorithms instead of, or in addition to, using or accessing the encryption within Apple’s operating system? If I say no, it shows an extra message about HTTPS. My app does use HTTPS for Firebase (Database, Storage, and Analytics) and Sentry.
Finally, if I say yes, it says: Version 0.1.0 (1) cannot be tested at this time because the build does not have associated export compliance documentation. Where do I find this documentation and how can I get it? I'm from Portugal, Europe.
Thank you!
Question 1:
Reply YES as you use HTTPS encryption for connections
Question 2:
For what you said about your app the reply is NO. In brief you don't use any function inside your app that use a custom cryptography or it's strictly medical app. The encryption that you use it's only for data passing from app to server, nothing inside your app is encrypted (app or a part/module of app is not encrypted).
Question 3:
No you don't use a custom crypt algorithm. That is usually used for bank app data inside the app.
Question 4:
Say NO. The US rules give an exception for apps with only HTTPS calls (that is what you do). Read here for a full explanation:
https://developer.apple.com/forums/thread/98071
https://www.cocoanetics.com/2017/02/itunes-connect-encryption-info/
Just add this key to info.plist file:
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
For expo users, automatically answer this question by adding this to your app.json/app.config.js:
{
"ios": {
"config": {
"usesNonExemptEncryption": false / true
}
}
}
Apple provides an endpoint to validate receipts:
https://buy.itunes.apple.com/verifyReceipt and warns against calling the endpoint from the app
It is not possible to build a trusted connection between a user’s
device and the App Store directly because you don’t control either end
of that connection, and therefore can be susceptible to a
man-in-the-middle attack.
It is stated, that the safe way is to send the receipt to "my own" server firstly, then communicate with Apple endpoint from the own server.
Honestly, I do not understand how does it help to increase the level of security. Yes, I do not control the /verifyReceipt endpoint, but Apple hopefully does. And why
phone <-> my server <-> Apple server is better than phone <-> Apple server?
Could you elaborate on this from point of view of the hacker (or man-in-the-middle)? How would he tamper the receipt/response in the latter case and what makes it difficult for him in the former case?
It's relatively easy to change an app binary to alter a string within the app. If your binary contains a string "https://buy.itunes.apple.com/verifyReceipt" then an attacker can change the string to "https://example.com/verifyReceipt" (a server that's under their control) and have the server return the receipt JSON that makes it seem like a purchase was successful. This is an easy attack to automate, so you just run a binary through a script which replaces all instances of the Apple URL with another URL.
When you communicate with your own server to Apple you can be (relatively) sure that that connection is secure. There are also ways to secure the communication between the app and your server such as a certificate in the app binary with a public key, the private key on your server. (I'm not an expert at this part so the details about keys might not be 100% correct).
All this being said there are other ways an attacker can make it look like a purchase went through. They can search your app binary for common receipt parsing libraries and flip known booleans (e.g. a userCompletedPurchase boolean flag). These attacks are easily scriptable.
The best way to make sure that your app isn't attacked is to remove the low-hanging fruit and make it that much more difficult that the common scripts won't open your app to attack. One way to do that is to not verify receipts directly with Apple.
I think that the key part to the section from Apple documentation that you cited, but didn't include, was the sentence before.
Using your own server lets you design your app to recognize and trust
only your server, and lets you ensure that your server connects with
the App Store server.
In particular the first half of that sentence (emphasis mine). I see this as a bit of nudge from Apple that the app should be designed as such to "recognize and trust only your server".
In the simplest case (ie. minimal), one could use their server as a proxy to reach Apple's server. The server could simply pass Apple's payload back to the app, or maybe send some simple JSON like
{
success: true
}
Or maybe even it's something as lazy as just sending a 200 response.
Using MITM, it's easy to change the response as needed. So even though you are using your server, the only barrier at this point is the attacker would need to determine what a valid response looks from your server.
They may be able to figure it out by simply sending a bad receipt and then seeing the response. Or maybe a hacker will TOFFT and just make a purchase to get the valid response and then provide others so they can profit.
This is "one step" above going to Apple directly, because everyone knows what the Apple payload is. Thus if the app goes directly to Apple it's easier for someone to be able to run a MITM and replicate a valid receipt response.
Going back to what Apple wrote, they are encouraging you to have a design that is more robust to help mitigate potential fake purchases from occurring. This robustness is what protects you more.
This can take the form in many ways.
For example, perhaps your server sends back the response in an encrypted format. Or replies with a hash. Even better if your app relies on your server through the course of usage, so the server can act as the truth. Or maybe the app periodically "phones home" to get a config of privileges. There are numerous ways one can make it more difficult for a hacker.
Apple is leaving to you just how you determine that trust with your server is established. It is after all, your "money".
As an example, the latest game I've made is specially built to use the server as the truth. So all moves go through the server (game is simulated on the server). While someone could certainly modify the app, in the end the server should theoretically correct any badness introduced.
Note, that it still is possible that someone can bypass even more robust security measures.
You can validate the iOS receipt on the iOS device. But you cannot be sure that the receipt is actually valid. The user could have hacked the device to make you think the receipt is valid.
Your users can edit the executable code of your app, and they can edit the operating system. With common/shared APIs like Apple's purchasing system, there are publicly available tools a user can run on their own phone to avoid paying.
Your server, however, is controlled by you. Your customers do not have physical access to it. And therefore your server (hopefully!) cannot be hacked. This means your server can be trusted, unlike the device. When your server establishes an SSL connection to Apple's server, you know you really are talking to Apple's server. Not one that your user-installed to bypass in-app purchasing.
UPDATE
Let's say you have got your Receipt after a user purchased your consumable product. So now you want to validate it and you have two options:
1. Receipt validation locally(from a user device).
2. Receipt validation through your server.
Local validation:
When you receive the receipt, you then read the contents of the receipt file by passing it through the verifyReceipt endpoint from your app. And you will get a response include a readable JSON body from this endpoints. Based on this response you can validate the receipt and control user action.
And all this happened in your app[user device]. After publishing your app you can't modify your app(if you need) without another release. Also, the user has more control of their device than you.
Validation through your server:
After getting Receipt data you need to encode the data in Base64. Send this Base64-encoded data to your server.
On your server, create a JSON object with the receipt-data, password (if the receipt contains an auto-renewable subscription), and exclude-old-transactions keys detailed in requestBody. Submit this JSON object as the payload of an HTTP POST request. In the test environment, use https://sandbox.itunes.apple.com/verifyReceipt as the URL. In production, use https://buy.itunes.apple.com/verifyReceipt as the URL.
Now you will get a JSON object response from App Store's that contains the keys and values detailed in responseBody. According to the response, you can validate receipt and send a response to the app for further actions.
So, if the user buys something in your app you don't need to store the thing being purchased inside the app. You want to store it on a server, and that server only sends the purchased data to the device after it has verified the receipt with Apple's server.
And you have more control in your server than your app also you can change any mechanism about receipt validation at any time(don't need to update your app) and control your user from the server.
Hope you will get it. Now it depends on you which one you prefer for you.
I will try to put my understanding here as I am deeply involved in auto-renewable subscription workflows.
Why is that endpoint there? what is the purpose?
The purpose of that API is to verify the purchase that user made using your app. So why do you want to call that API from the mobile(phone). In that environment, you already know that user has made the purchase.
But if you want to call that API to decode the encoded receipt inside the app(to read important values), then consider the other recommended approach. That encoded receipt is PKCS7 encoded and Apple itself provide lib to decode that.
Hope this helps
I making a new app and want to submit to app store.
But at the time of final submission
there is check for Export Compliance.
What should I Check Yes Or No.
I use https url in my app.
Please Help Me .
Thanks In Advance.
When you know that you ARE export compliant you can put this in your Info.plist:
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
This will prevent App Store Connect from asking you questions about export compliance.
If you are using https in your application, you will need to answer yes to this question, even if all you are using is built in mechanisms to communicate over https. The good news is that you no longer need to get the Encryption Registration Number (ERN) - the current requirements (as of August 2017) are that you just need to submit the annual self classification report to the BIS(Bureau of Industry and Security). To submit a self classification report, follow the instructions on item 13 in this FAQ: A sample Self Classification report can be found here.
For a great write up that talks about both sides of the story (apps that only use common / freely available encryption, like SSL, as well as apps that have their own, proprietary encryption, see this Medium post.
Please don't listen to other people who state that they just answer no to this question to make things easier when submitting an app.
As of February 2018 this is the process to file an Annual Self Classification Report to BIS (Bureau of Industry and Security):
https://www.bis.doc.gov/index.php/policy-guidance/product-guidance/high-performance-computers/223-new-encryption/1238-how-to-file-an-annual-self-classification-report
To get a ECCN (Export Control Classification Number) for a HTTPS mass market iOS app follow, these steps.
Download the quick reference guide to classify your app.
https://www.bis.doc.gov/index.php/documents/new-encryption/1652-cat-5-part-2-quick-reference-guide/file
For a basic HTTPS iOS app used to securely access a webpage or transfer a file use
5D992 which is Information Security” “software” not controlled by 5D002.
If your app contains more encryption functionality, then reference the policy guide. https://www.bis.doc.gov/index.php/policy-guidance/encryption
Might not be what you want to hear, but you will need to review the policy and correctly categorize the app and get the correct ECCN.
Now go to the SNAP-R form. https://snapr.bis.doc.gov/snapr/
To get to the form from the BIS homepage.
https://www.bis.doc.gov/index.php
Then select Licensing -> Simplified Network Application Process Redesign (SNAP-R)
Register Online for a SNAP-R account.
https://snapr.bis.doc.gov/registration/Register.do
The Bureau of Industy and Security will return a CIN application ID quickly via email.
Return to the main SNAP-R page with the CIN issued number and login.
Select "Create Work Item "
The Type will be "Commodity Classification Request"
Reference number is 7 digits. I used my phone number.
Create
Fill in Contact Information.
Leave License Information Blank
Fill in Company Designation any info missing. When you created the CIN this info was requested.
Other Party can be left blank.
Now for each app you want to register, fill in a Export Item and press Add Export Item. Multiple apps can be submitted on the same request.
ECCN will be 5D992
APP can be left blank. It is the Adjusted Peak Performance"("APP") which for a commodity iOS app is not required.
Product/Model is the name of the app in the App Store.
CCATS can be left blank.
Manufacturer is your company name.
Technical Description - briefly describe the apps function and how HTTPS is leverage. Keep it simple. They are interested if the app is a security risk and how encryption is used.
example:
AppName is distributed as an Apple iOS App. It uses HTTPS to download/upload daily updates to and from xxxx. The download is used to generate a table. An In-App .99 cent purchase expands the table results to include xxxx.
Additional information explains in more detail how HTTPS has been implemented.
The HTTPS file transfer is a URLSession data transfer task found in the Apple Foundation library. The iPhone automatically performs the download of the published data in csv file format, using the HTTPS protocol for a secure transfer.
Make sure you saved all your drafts. Check for errors. Then submit.
The turnaround is pretty fast. Mine took around an hour. But I am sure it varies.
The other option is once a year you can submit an Annual Self Classification Report. But if you have a SNAP-R CCATS number you are not required to submit a Annual Self Classification Report.
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
This is very simple. Download the sample csv file. Delete out the sample data leaving the headings. The heading are required. Fill in the columns. The column Authorization Type is MMKT. Item type Other: HTTPS File Transfer. Save the file and submit.
The BIS SNAP-R hotline [202-482-4811 DC, 949-660-0144 CA] and the Encryption Hotline for the annual submission [202-482-0707] are both very helpful. Last point, the BIS has helpful set of YouTube video.
https://www.bis.doc.gov/index.php/online-training-room
Hope this helps.
From Complying with Encryption Export Regulations: Declare Your App’s Use of Encryption:
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
So Apple says that for usual HTTPS scenarios, you do not need to upload export documentation for your app.
The ONLY encryption my App uses is calls over HTTPS. Currently (7 June 2017) iTunes Connect requires an Export Compliance according to this information in iTunes Connect.
I've entered the iTunesConnect -> My Apps -> Features -> Encryption page, clicked the plus symbol besides "iOS Documentation" and in the Export Compliance form answered YES.
The following two screen shots show more details of the export compliance box as I scroll down.
The last 2 screen shots suggest using HTTPS is an EXEMPT use of encryption and I should therefore in info.plist set ITSAppUsesNonExemptEncryption=false. But this is not clear, and is contradicted in my 1st screen shot that says if you are making a call to HTTPS ... required to submit a year-end classification report to the US government.
So my questions:
is it correct to set ITSAppUsesNonExemptEncryption=false if the only encryption I use is via HTTPS calls?
if I must set ITSAppUsesNonExemptEncryption=true, where do I go to submit a report to the US government and how does this report get passed to Apple? I cannot find any clear information on the process. I don't want to screw this up as the consequences can be major as threatened in the last screen shot.
regardless of how I set ITSAppUsesNonExemptEncryption, according to my 1st screen shot if I use HTTPS I must submit a year-end self classification to the US government. Is that true, and what is the process? (clicking the "learn more" link doesn't help)
I was searching the web for this for some hours. Actually it is pretty easy and you can verify this in itunes connect:
1. All you have to do
If your app uses only HTTPS or uses encryption only for authentication, tokens, etc., there is nothing you have to do, just include
<key>ITSAppUsesNonExemptEncryption</key><false/>
in your Info.plist and you are done.
2. Verification
You can verify this in itunes connect.
select your app
chose features
chose encryption
click "+"
follow the dialog
for https or authentication the answer is yes and yes
3. Year-end self classification report
As is written in the dialog in 2., you still need to submit a year-end self classification report:
If you are making use of ATS or making a call to HTTPS please note
that you are required to submit a year-end self classification report
to the US government. Learn more
You can check How do I submit a Self Classification Report for Encryption Items and this SO question https://stackoverflow.com/a/48462458/276648 .
In any case you should of course read yourself carefully through the dialog.
A very helpful article can be found here:
https://www.cocoanetics.com/2017/02/itunes-connect-encryption-info/
I unfortunately do not have enough rep to comment but at the minute I am looking into the exact same issue and I believe that you are correct when you say that you can set the ITSAppUsesNonExemptEncryption key to false, at least this was the conclusion I came to from my research.
For the self classification report it does look like you have to submit one by February of next year, I found this link helpful in explaining the report and what to do
https://www.bis.doc.gov/index.php/policy-guidance/encryption/reports-and-reviews/annual-self-classification
Like I said this is all from my own investigation like you and I think this is correct but if anyone does have any more information would be greatly appreciated.