I my application I use sha256 encryption (actually it's a hash function, so you can't decrypt it). For each request to server I need to make such a string "param1|param2|param3" and encrypt it with sha256 (I will get encryptedString) and I need to add the 4th parameter "hash" = encryptedString. It's the only use of the encryption in the application
sha256 function is:
import Security
func encryption_sha256(_ originString: String) -> String {
let data = originString.data(using: String.Encoding.utf8)!
var hash = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
CC_SHA256((data as NSData).bytes, CC_LONG(data.count), &hash)
let hexBytes = hash.map { String(format: "%02hhx", $0) }
let resultString = hexBytes.joined(separator: "")
return resultString
}
When I submit to App Store I have such questions:
1) Is your app designed to use cryptography or does it contain or incorporate cryptography? (Select Yes even if your app is only utilizing the encryption available in iOS or macOS.)*
As far as I understand, my Answer is YES . Or can I answer NO, because sha256 is not encryption, it's just hash and you can't decrypt it?
2) Does your app meet any of the following:
(a) Qualifies for one or more exemptions provided under category 5 part 2
(b) Use of encryption is limited to encryption within the operating system (iOS or macOS)
(c) Only makes call(s) over HTTPS
(d) App is made available only in the U.S. and/or Canada
Make sure that your app meets the criteria of the exemption listed here. 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. Read the FAQ thoroughly before answering the questions.
You can select Yes for question #2 if the encryption of your app is:
(a) Limited to using the encryption within the operating system (iOS or macOS)
(b) Limited to making calls over HTTPS
(c) Specially designed for medical end-use
(d) Limited to intellectual property and copyright protection
(e) Limited to authentication, digital signature, or the decryption of data or files
(f) Specially designed and limited for banking use or "money transactions"; or
(g) 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 here I answer Yes, everything is easy, I just need to insert <key>ITSAppUsesNonExemptEncryption</key><false/> in the info.plist file.
Can I answer YES to this question?
if NO, I get the 3d question:
3) Does your app implement any encryption algorithms that are proprietary or yet-to-be-accepted as standards by international standard bodies (IEEE, IETF, ITU, etc.)?
As far as I understand, answer is NO
4) Does your app implement any standard encryption algorithms instead of, or in addition to, using or accessing the encryption in Apple’s iOS or macOS?
As far as I understand, answer is YES
And in this case I need:
Please upload a short letter stating that you understand your legal obligations to submit a year-end self classification report required by the Bureau of Industry and Security (BIS).
Where do I need to submit this year-end self classification report required by the Bureau of Industry and Security ? Or may be can I answer YES to the 2nd question?
The key is "Select Yes even if your app is only utilizing the encryption available in iOS or macOS."
Since SHA256 is not encryption, answer no to question 1.
Cryptographic hash functions are not encryption since the are one-way functions, encryption is a reversible two-way function.
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.
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
I want to encrypt a parameter(which consist of sensitive data) while sending to server(WCF Service) using SHA1 algorithm, On server end I'll decrypt the string and use it.
This way i can ensure any third party won't read my sensitive data so easily.
How do I encrypt the string in windows phone 7 using SHA1 algorithm and decrypt the same in my WCF service.
Encrypted string may come to server from iPhone, android or WP7; How do I ensure that every client will produce the same result in server.
Update:
Can I use AES algorithm for above requirement?
How do I encrypt the string in windows phone 7 using SHA1 algorithm and decrypt the same
You don't. SHA-1 is a hashing algorithm. It's one way - you can't "decrypt" it. You should choose a symmetric or public/private key algorithm based on your requirements. Read the .NET cryptographic services documentation as a starting point - I'd expect pretty much any of the algorithms supported by .NET to also be supported on other platforms.
Alternatively, just use HTTPS instead of HTTP... that would satisfy your initial highlighted requirement without you having to do much work at all (beyond the server-side deployment of appropriate HTTPS certs).
Agree with Jon's post but with additional thoughts.
I cannot comment yet (need more street cred) so I will post it here.
Your question does not state if you are transmitting this from a native app, or a browser (using an Ajaxian mechanism). But I will presume native. Really though the answer is the same with the difference being implementation.
The easiest approach IMO would be to use the tools and APIs to be a HTTPS (SSL/TLS) client which will give you over the wire confidentiality. The details of what quality of service the SSL connection provides is for you to configure from the "cipher suites") available. AES is available.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
When submitting an app to the iOS App Store, one is required to declare whether the app "contains encryption" (and, as I understand, go through additional administrative hurdles).
Does anyone know of any guidance on what precisely is covered by the term "encryption" in this context?
Are they referring to:
specifically cryptographically secure encryption schemes (AES, RSA etc);
OR, any scheme or method that might in everyday parlance be referred to as 'encryption', or a variant of a standard scheme that is cryptographically weak?
Specifically, I was intending to use some weak scheme to protect some of the app's assets against a casual hacker, e.g. by XORing the data from the file with a string of bytes generated from a (non-cryptographic) random number generator. If you like, it would be a "one time pad", but where the key isn't actually cryptographically random: just random enough so that somebody looking to steal the data would need to go to a small amount of effort beyond 'just copying the data out of the file'.
So, for the purposes of the declaration, would this count as using "encryption" even though it's not actually a cryptographically secure form of encryption? What I'm doing is common enough practice that I'm guessing other developers have submitted apps using such a procedure: did you have to declare the app as using encryption?
(The iTunes Connect Guide, for example, doesn't give any further specification on this matter.)
This flow chart will probably help you get on the right track. It indicates that if the encryption is limited to copyright protection / intellectual property then it is exempt from the review. I got to this flow chart from the BIS homepage. That page is referenced by the FAQ entitled World Wide Trade Compliance for the App Store in iTunes connect which states you can claim exemption:
(i) if you determine that your app is not classified under Category 5, Part 2 of the EAR based on the guidance provided by BIS
Hope this helps clear things up a bit.
EDIT Another interesting section is this, you can claim exemption if:
(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