I'm using Airdrop to transfer application internal data between two phones. Because Airdrop was intended for file sharing, it could occur that user choose "save the file" to save the data file in Files app by accident. Since my app is a financial planning app, I'm considering to encrypt the file transferred by Airdrop to keep user's data secure. The encryption only applies to the temp file transferred by Airdrop. Once the app on the receiver phone receivers it, it decrypts the file immediately.
I'm referring to this thread to determine how I should answer the export compliance question if I encrypt the temp file. And I noticed these two exemption items:
(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.
I don't quite understand the difference between the conditions in the two items (what is a mass market product?). But I don't think either helps, because the ciphers provided by iOS Cryptokit contains only AES and ChaChaPoly - the former takes a minimum key size of 128 bits and the latter takes 256 bits key size.
Since there are a lot of apps using Airdrop to transfer application internal data (I can tell that from the discussions on SO), I wonder how other people deal with this? Is this considered an exemption case?
BTW, I considered other options, but none is satisfying:
Don't encrypt the data. Obscure it instead (for example, using something like Caesar cipher). But that feels very unprofessional.
Don't use Airdrop. Implement my own data transfer mechanism. For example, start a tiny web server on sender side and the receiver side get the data through HTTPS, which from my understanding is an exemption case. I don't choose this approach because a) Airdrop provides a much better user experience than this approach, b) I'll need to use Bonjour to discover service, which requires local network permission. I'd like to avoid that if possible.
The answer depends on what cipher you use to encrypt the data.
Apple summarises your requirements in a couple of documents.
First, in the CryptoKit documentation
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.
This leads you to this document which has a table, that I have shown in part:
Assuming that you use AES from Apple's Crypto Kit framework, the second clause would apply. You don't need to provide any documentation to Apple but you should submit a self classification report to the us government.
The exemptions you listed in your question do not apply since you wouldn't use a symmetric cipher with a key length of 64 or 56 bits.
Related
After deploying build for my iOS app on TestFlight, Apple was asking me to fill "Export Compliance Information" with the following question:
Does your app use encryption?
Select Yes even if your app only uses the
standard encryption within Apple’s operating system.
I've searched little bit for an answer here on StackOverflow but my case is little bit specific and haven't found clear answer for my case yet.
I am using https to connect to the server.
I am using Apple Keychain to store user credentials.
I am using encryption on backend to encrypt/decrypt secret file and send decrypted content in response when my app is making an https request (so for this case my app does not use encryption directly).
I assume the answer to the first question is Yes. Definitely because Apple Keychain itself uses encryption.
If I select yes I get to the next question:
Does your app qualify for any of the exemptions provided in Category 5,
Part 2 of the U.S. Export Administration Regulations?
Make sure that your app meets the criteria of the exemption listed below.
You are responsible for the proper classification of your product.
Incorrectly classifying your app may lead to you being in violation of
U.S. export laws and could make you subject to penalties,
including your app being removed from the App Store.
You can select Yes for this question if the encryption of your app is:
(a) Specially designed for medical end-use
(b) Limited to intellectual property and copyright protection
(c) Limited to authentication, digital signature, or the decryption of data or files
(d) Specially designed and limited for banking use or “money transactions”; or
(e) Limited to “fixed” data compression or coding techniques
You can also select Yes if your app meets the descriptions provided in Note 4 for Category 5, Part 2 of the U.S. Export Administration Regulations.
I assume I my app is c))
(c) Limited to authentication, digital signature, or the decryption of data or files
Therefore the answer to this would be also yes.
However I am not sure about this and would like to know your opinion, ideally with a short explanation.
Thanks.
PS: I am including useful links which helped me on how to submit a Self Classification Report:
https://kitefaster.com/2017/08/10/encryption-export-compliance-ios-apps
https://simonfairbairn.com/bis-year-end-self-classification-report
The rules regarding a TestFlight app is slightly different from a "real" AppStore release, but the procedure is pretty similar.
As you said, the first question asks “Does your app use encryption?"
Here you should select "Yes" even if your app only uses the standard encryption in iOS and macOS / XCode.
Basically:
Use of encryption in this case 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.
The U.S. Government defines "non-standard cryptography" as any implementation of "cryptography" involving the incorporation or use of proprietary or unpublished cryptographic functionality, including encryption algorithms or protocols that have not been adopted or approved by a duly recognized international standards body.
Does your app qualify for any of the exemptions provided in Category 5,
Part 2 of the U.S. Export Administration Regulations?
As you said, option C is most often adequate and the correct choice if you don't use any proprietary or non-standard algorithms.
By the way, here's a link to that "Note 4 for Category 5" that they mention.
When you submit a final version of your app to the actual App Store, you will be required to answer these questions again in App Store Connect.
Determine your Export Compliance Requirements, blah, blah...
Basically, you can say yes in the following scenarios:
Select "Yes" for this question if the encryption of your app is:
a. Specially designed for medical end-use
b. Limited to intellectual property and copyright protection
c. Limited to authentication, digital signature, or the decryption of data or files
d. Specially designed and limited for banking use or “money transactions”; or
e. Limited to “fixed” data compression or coding techniques
It's usually no problems from here on, as long as you pass the internal testing etc.
Just follow the prompts when exporting / distributing to App Store.
Remember to update your Xcode settings for your build.
By the way: Consult an attorney for legal guidance if in doubt! This is only my understanding of the process.
This is from Apple's article about Complying with Encryption Export Regulations
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.
The big thing from this quote I noticed is the term "proprietary" and the fact that HTTPS is now exempt from regulation. I believe that this also means that keychain should also not be included in this, because it is public encryption to my knowledge.
But I am very uneasy to say that the encryption you use in the app's backend is safe from the regulation givin that it could be considered as proprietary and could be considered an extension of your app, not a separate entity. Historically Apple is very willing to take down apps that they don't believe to follow their guidelines. Here is a great stack overflow question and a Reddit link you should read through to be safe the stack overflow answer seems to be very thorough. Stack Overflow and Reddit.
Sorry I couldn't help you with the third point about your backend's encryption. I hope you can find some answers that I didn't see in the links I provided though.
My app computes hash of some strings (that identify in-app purchases) using simple function of my own making. This function is very far from something sophisticated like MD5 - it is just simple hash function with result multiplied few times by large primes - the whole computation is 8 lines in Swift. The hash is then stored using NSUserDefaults. The app does not do anything else that could be considered encryption.
When submitting my app Apple asks me to fill Export Compliance starting with this question:
Is your app designed to use cryptography or does it contain or incorporate cryptography?
So does it? The Export Comliance is required by Apple due to US Export Administration Regulations. Here is the regulation guide linked by Apple and here are some notes about it by Apple.
Incorporating/using hashing is not using encryption, you are not incorporating cryptography.
Cryptographic hash functions are one-way function, there is no reversal/decryption possible, it is not encryption.
Common Crypto is not Objective-C, it is "C".
Using weaker algorithms in place of standard algorithms because it is easier is not professional.
MD5 should not be used in new work, use SHA256 or better. On an iPhone 6s SHA255 is about 4x faster than MD5.
The Common Crypto implementation is FIPS-140-2 certified.
Short answer: yes
MD5 is a cryptographic one way function designed to be difficult to reverse. It uses a 128 bit key to perform the hash. Export restrictions require permission for any key length or 56 bits of higher
For a commercial online music stores like itunes, is the encryption of the audio file performed before uploading the file on its server? or there is an encryption algorithm implemented on the server?
I feel quite confident that the actual asset/file is exactly the same for everyone who downloads it. This would be a requirement for the file/asset to be distributed by a CDN (Content Distribution Network) which is how content providers present a huge, widely distributed user population with a consistent, fast experience when downloading content. I don't have any proprietary information, but based on twenty years developing distributed systems, this is the only approach that makes any sense from the server perspective.
Another answer posited that the content had to be individually encrypted for each user and said:
A system like iTunes can only work properly if a different encryption key is used for each user.
There are plenty of ways to handle this that don't involve re-encrypting the payload for every user. For instance, each content file could have its own key, and then the client could perform a much smaller (compared to the size of the payload) cryptographic exchange with a server to get the key to unlock that content on purchase. The idea that every consumer of a multi-gigabyte movie causes that movie to be re-encrypted seems extremely improbable.
We are developing a game where all the game logic is executed locally (no server back-end) and would like to make it difficult to tamper with game data (such as user credits, game settings and so on).
Now, it's even possible on non-jailbroken devices to access the filesystem and change game data - so, for example if user inventory stats are stored in a plist file, it's very easy to edit them.
If we move game settings from plist files to source-code files, such that they get compiled into the binary, it will require at least a modification of the binary to change settings. On non-jailbroken phones - will modified binaries still run, or does the apple codesigning prevent from modifying the binaries in any way?
What are some quick and easy to implement measures to make it a bit harder to tamper with game-data (especially on non-jailbroken phones. Optimally we'd like to provide some kind of security that will at least require a jailbreak to make modifications to the game)?
so - to summarize the questions:
can the binary part of an iOS app be modified and still run on non-jailbroken devices?
what are some quick and easy to implement measures to make it harder to tamper with gamedata on non-jailbroken devices?
You can't modify the binary as it would invalidate the signature. I would just use some sort of encryption on the data you don't want users to modify. You can make this as simple or as complex as you want. I don't think iOS provides any kind of encryption services out of the box, but you don't need to go hog wild with it - a simple ROT13 algorithm would do, since we're not talking about password-level security here. If you want, you can even add a checksum on the encrypted data, then invalidate it if the checksums don't match.
To answer your questions:
No. The application will be required to be signed again.
A simple but not unbreakable measurement is to safe the data in a secure container (key chain for example) or encrypt it yourself before you safe it to disk. An attacker now have to monitor a running app to get to the decrypted data in memory - or need to crack the secure store.
There are a few ways on iOS (and Mac OS X) where you can accomplish to encrypt and decrypt data. One way is pretty nicely described here in the official docs:
Encrypting and Decrypting Data.
I am developing an app that stores PDF files. These files should be stored secure, i. e. encrypted. I also found some libraries that extend NSData with AES en/decryption. But then I read, that iOS supports hardware encryption via AES. Is the NSData library really necessary if they both provide AES256 encryption?
If there are differences, which way is more secure? Also.. how do I activate the hardware encryption? Or is this a global setting that applies to all apps? I guess that the files become decrypted after the device is unlocked? So if someone cracks my phone he has also access to the decrypted files? But if I do the encryption by myself and connect the decryption with a SHA hashed password that is stored in the keychain the files might still be inaccessible?
Edit:
Did I get it all wrong and my library (AQToolkit) is just some kind of API for the built-in hardware encryption and I am basically talking about the same thing?
I heartily recommend RNCryptor, which uses Apple's own Security.framework guaranteeing hardware encryption/decryption if possible. It's incredibly easy to use in the default case (AES-256 with 10k iterations of PBKDF2). It's not an encryption library per se, but rather an Obj-C packaging of the open source Common Crypto C library. Check it out.