My app uses encryption indirectly as I'm using an encrypted Realm database (and Realm implement the encryption).
I don't therefore know if Realm
"... only uses encryption algorithms provided in iOS for its security
features ..."
Realm uses the crypto library and so its reasonable to assume it does use algorithms provided in iOS, but the point is I don't know for a fact if it does or doesn't or if it uses key lengths exceeding 512 bits etc. etc. etc.
So I can answer Apple's question:
".. does your app contain or incorporate cryptography"
as YES as it must do if I'm using a Realm encrypted db.
But I can't answer questions such as
"..Use of encryption is limited to encryption within the operating
system"
As I have no idea what Realm is doing with respect to its encryption.
If you have released an app using Realm encryption, what did you do regarding these points when releasing the app, and why?
(A couple of people who are possibly Realm developers have commented on forums that Realm only uses the crypto library and hence only algorithms provided within the OS, but there is no official statement of this on the Realm website. And it can be seen the the Realm code imports Crypto library hence it is very very reasonable to assume this is the fact. But to re-iterate - as an app developer I myself do not categorically know this for a verifiable fact or can refer to an official statement stating this issued by Realm. They have a Legal Considerations section here https://academy.realm.io/posts/tim-oliver-realm-cocoa-tutorial-on-encryption-with-realm/ and they state:
If you are unsure as to whether your app falls within the export
compliance exemptions, please contact an attorney
But they don't actually provide sufficient information regarding details of Realm to actually be able to do this.)
Related
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.
When I get
UserDefaults.standard.dictionaryRepresentation()
from any app, I can recover a list of many keys-values (that weren't saved by my application) like
AKLastCheckInAttemptDate
AKLastCheckInSuccessDate
com.apple.content-rating.AppRating
INNextFreshminRefreshDateKey
INNextHearbeatDate
and others
I searched through the internet and in the Apple documentation but I didn't find any list of possible keys that can be used by the operating system, much less what exactly each of these keys means. Does anyone know any such list or know what each of these keys mean?
The set of keys is not fixed or, in general, documented. Any string can be used as a key.
UserDefaults.standard is a global object in your app. So any framework used in your app has access to UserDefaults.standard and can set own entries, using any keys it wants. Some settings are even shared across the whole system and so they can be set by other apps or by frameworks you don't use in your app.
The keys and values used by an app or framework are usually considered to be implementation details, so Apple doesn't want you to rely on anything their code stores in UserDefaults.standard.
You would need to read the source code of an app or framework to understand what keys it might set and what they mean, but Apple releases very little of its source code. You could also try reverse-engineering the app or framework (that is, disassembling it and figuring out what it does from the machine instructions) but that is usually very difficult.
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.
I'm new to iOS development and working on a small iOS mobile app that stores sensitive information of users. Initially I thought of using custom AES encryption to encrypt/decrypt all the data. I also want the encrypted data to be synced with iCloud. After reading more I came to know from iPhone 3GS each device has a built-in AES-256 crypto engine. From the XCode, I observed that I can turn on an option called "Data Protection" for the mobile app to secure data. Based on my analysis I've below questions:
To use data protection for iPhone 3GS (uses iOS 6.1) do I need to set passcode?
Without setting passcode for the device how can I use the built-in crypto engine to encrypt my data?
The information are very sensitive and so in this case do I need to implement custom encryption?
RNCryptor is very useful, but it's basically just a wrapper for Apple's own CommonCrypto functionality (that makes implementing it pretty easy). It's useful if you want to encrypt data on the device that even the user cannot get ahold of.
Regarding your specific questions:
Data protection encrypts your app data using Apple's device-level encryption (you do not password protect it yourself). This has its uses - it will keep a 3rd party from being able to access data on a device if they are unable to unlock it - but does not prevent (for example) a user from getting access to data on their an unlocked device. Using RNCryptor and CommonCrypto which it is built upon you can AES256 encrypt content using a password of your choosing.
Apple details this here. Basically, from the end user's perspective they just set a password for their device as normal. You do not use a password of your own choosing.
You can set this up for your app using the following instructions:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AddingCapabilities/AddingCapabilities.html#//apple_ref/doc/uid/TP40012582-CH26-SW30
This depends on how sensitive the data is and what threats you foresee (Who are you trying to keep it away from? Are there any laws/regulations you intend to comply with? How much work do you want to take upon yourself to protect this data?). There are a lot of trade-offs and caveats that can apply in certain situations.
If you have a small amount of data, you might consider just storing it in the iOS keychain. Otherwise, I'd recommend giving RNCryptor a try. It's fairly easy to integrate.
I hope this helps.
UPDATE: Another thing to consider... There are potential export control ramifications that might come up if you implement your own encryption, even using RNCryptor/CommonCrypto. Depending on how much paperwork and/or delay you're willing to deal with, this may influence your decision. You can learn more about this from Apple's site, here:
https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/20.0.0.13.7.2.7.9.3.1.2.3.3.1.5.7.1
This really depends on how many scenarios you are trying to protect against. Pretty much any scenario you can possibly create will be broken given enough time and effort. However to address a few points:
1) Yes you need to set a passcode for this feature to become active.
2) You can make use of the CommonCrypto library (or a wrapper around it like RNCryptor)
3) This is a bad idea for the simple reason that developing a secure algorithm is insanely hard. The slightest flaw will leak out all of the data and people have devoted years of their lives to sniffing out these flaws (although I may have misunderstood what you meant by "custom encryption")
If you want to be as secure as possible you will have to do this: Send your file to a server for processing (via HTTPS). It is much harder to hack into a server then it is to hack into an iOS application. If you simply use RNCryptor it is pretty trivial to rip apart the app looking for the password, or how you obtain the password. Basically if the app can do it then BlackHat can do it too.
EDIT I forgot about one thing! If you generate a random password for each install and store it in the keychain then this will help, but it is not foolproof (There is a small chance that the iOS keychain contents can be retrieved from a jailbroken device, especially if the user has a week passcode). However this will make the user's data non-recoverable if they wipe the OS for any reason.
very very very simple : https://github.com/RNCryptor/RNCryptor
I was used it for a chat application it so good.
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.