Related
I have requirement to store credit card number in iPhone app. How to store the data secure manner. I have looked at keychain. Apart from it, is there anything i can use.
As mentioned above, you should first look into the legality of this, especially with Apple restrictions on what goes in the app store.
That said, I have had to encrypt sensitive information before, and decided to go overboard with AES-256 encryption. Since usernames, passwords and personal data were being sent over a network, it was necessary. I used FBEncrypt for this - it's a great wrapper around CCCrypt.
https://github.com/dev5tec/FBEncryptor
That will allow you to do base-64 encoding and AES-256 encoding, among other things, and it is really convenient. Check it out if you really need it!
This question as stated is difficult to answer. It is up to author(s) of the requirement to determine the level of security needed. They may wish to get some legal advice about what, if any, liability may be incurred for leaking the data.
Once you know the appropriate level of protection, then you can start evaluating solutions. Keychain is good, but there are quite a few encryption options available.
Questions you may want to get answers to besides how to store the number include:
What authentication will be needed to expose the number?
What is the expected lifecycle of the exposed number?
How long can the number stay exposed?
How will the number be purged from memory?
How can the exposed number be used?
Can the number ever be displayed to the user?
Will you allow the number to be copied to the clipboard?
If you want to be serious about protecting information (any information), you need to do some serious design work.
Encryption and the use of SSL/HTTPS seems enough for this case. If you are new to the subj, good general guidelines here: Mobile App Development Tips: How to Ensure Data Security
There are many implementations, e.g. you can use AES256 algorithm mentioned above:
When an app saves a credit card number for the first time, a random
masterKey and initialization vector (IV) are generated. Use them
later for encryption.
A masterSalt is generated and saved locally.
Using plainPassword and masterSalt, a hash (PBKDF2) is calculated.
Using the AES256 algorithm, the calculated hash is used to encrypt
both MasterKey and IV.
Encrypted MasterKey and IV are saved locally.
Decrypt the MasterKey and IV using plainPassword and masterSalt hash
(PBKDF2).
Now, encrypt the data with MasterKey and IV using the AES256 algorithm.
You need to do very serious research into this and not necessarily accept what people on this site say without thorough research and confirmation on your part.
Storing information like credit card info is not something you should implement just based on responses on this site IMO.
If you are serious you need to read, understand and apply the material in the book "Hacking And Securing iOS Applications" to understand what the dangers are and how you can mitigate against them, and how techniques that people say are secure really aren't as secure as you think they might be.
I'm developing an application for iPhone which uses a HTTP request to get quote data from a webserver.
I am working with another developer who is managing the web service. We are using an MD5 encryption (simple xor) to pass the data between iPhone and webserver.
He posed a question to me this morning which is quite frankly way out of my pool of knowledge.
'How safe is the apple binary?'
He is worried about whether someone could obtain the .app bundle via iTunes, and then decode that bundle and access my source code directly, allowing them to obtain the secret key we are using to encode the data.
I personally, wouldn't even know where to begin, but i'm sure there are more knowledgeable/crafty fellows out there.
So, is it possible? if is it, what can I do to try and safe guard my source?
The binary is not even remotely safe. Whether through the iTunes download or on a jailbroken iPhone, there's nothing you can do other than obfuscation, which a determined adversary will always get past. Do not ever rely on the "secrecy" of something embedded in a client application, it is not secret. Ever. On any platform, in any language, with any technique.
If you need to limit who can access your system, you need per-user accounts. There is no other safe mechanism. Apple does provide ways to "authenticate" users via their iTunes accounts, you may want to look into that.
Also, "MD5 encryption" means nothing. MD5 is a hash function with cryptographic applications, but saying you're doing "MD5 encryption" and "simple XOR" is just meaningless. I can use XOR and MD5 to do any number of things, few if any would serve as a meaningful encryption scheme, and would have no advantages whatsoever over a real algorithm designed by experts, such as AES.
Use HTTPS (HTTP over SSL). There is no reason not to, the iPhone fully supports it. If you need to, you can get free SSL certificates for your server from at least http://www.startssl.com/ . There are lots of cheap SSL certificate providers out there these days, too. Google a bit.
I'd strongly recommend you and your co-developer start reading up on information security, both in theory and practice, because it appears you have very little grounding in the subject, and probably several significant misconceptions that will lead to easily-broken systems.
I have several plist files in my app, that I want to be non human readable, or editable.
The idea is to encode them using another app, then drop them in the normal iphone app just for decoding and processing.
I have drooped encryption because 1st, I don't need something with strong encryption, and 2nd because of the app store procedure for encrypted apps.
Can anyone suggest me how to proceed? What is the simplest (not the best in terms of encryption) method implement?
Please assist!
iPhone applications are "sandboxed", meaning that applications cannot read each other's data; each application has associated with it its own username and group, along with its own set of folders that it owns. An application cannot access the folder or data of another iPhone application. Therefore, the requirement doesn't really make sense. You should simply use NSDictionary -writeToFile:atomically, and NSDictionary -initWithContentsOfFile to read/write the data to/from a PLIST. If you need to add encryption (because you are worried about two people sharing the iPhone, or something like that), then I suggest you encrypt the individual entries before placing them in the dictionary.
Edit
Based on your comment below, it appears that you are trying to prevent people from pirating your application, rather than trying to protect user data as the question implies. Unfortunately, it is always possible to pirate an application. Anything ranging from obfuscation to using certificates to asymmetric encryption to running a checksum over the application binary can all be bypassed or defeated. The best way to deter piracy is to have a quick iteration cycle and to place most of your data in the cloud, where it is frequently changed and updated, as doing so diminishes the value of any pirated snapshot of the application. That said, it is generally a good idea to consider software piracy as simply a cost of doing business. Most users will not pirate the application, and since all the various methods for protecting your application can (and will) be defeated, the costs of implementing such things is generally not worth it.
Take a look at the NSDataWritingOptions of NSData. There is built in encryption for binary plist files. I've never used it so I don't know how easy it is for someone with developer's tools to defeat it. It should however provide protection against casual thievery.
However, if your worried about about other developers stealing your content, your best protection will be copyright. Copyright protects content, that's what its for. Make sure to include a copyright in the actual plist as part of the data. Stick a copyright in every resource file e.g. images.
I'm uploading a binary for the first time. iTunes Connect has asked me:
Export laws require that products containing encryption be properly authorized for export.
Failure to comply could result in severe penalties.
For further information, click here.
Does your product contain encryption?
I use https://, but only via NSURLConnection and UIWebView.
My reading of this is that my app doesn't "contain encryption," but I'm wondering if this is spelled out anywhere. "Severe penalties" doesn't sound pleasant at all, so "I think that's right" is a bit sketchy... an authoritative answer would be better.
Thanks.
UPDATE: Using HTTPS is now exempt from the ERN as of late September, 2016
https://stackoverflow.com/a/40919650/4976373
Unfortunately, I believe that your app "contains encryption" in terms of US BIS even if you just use HTTPS (if your app is not an exception included in question 2).
Quote from FAQ on iTunes Connect:
"How do I know if I can follow the Exporter Registration and Reporting (ERN) process?
If your app uses, accesses, implements or incorporates industry standard encryption algorithms for purposes other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https. This authorization requires that you submit an annual report to two U.S. Government agencies with information about your app every January.
"
"2nd Question: Does your product qualify for any exemptions provided under category 5 part 2?
There are several exemptions available in US export regulations under Category 5 Part 2 (Information Security & Encryption regulations) for applications and software that use, access, implement or incorporate encryption.
All liabilities associated with misinterpretation of the export regulations or claiming exemption inaccurately are borne by owners and developers of the apps.
You can answer “YES” to the question if you meet any of the following criteria:
(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 at encryption question. The Statement of Understanding for medical equipment in Supplement No. 3 to Part 774 of the EAR can be accessed at Electronic Code of Federal Regulations site. Please visit the Question #15 in the FAQ section of the encryption page for sample items BIS has listed that can claim Note 4 exemptions.
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
(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.
Please review Note 3 in Category 5 Part 2 to understand the criteria for mass market definition.
(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.
(vi) the source code of your app is “publicly available”, your app distributed at free of cost to general public, and you have met the notification requirements provided under 740.13.(e).
Please visit encryption web page in case you need further help in determining if your app qualifies for any exemptions.
If you believe that your app qualifies for an exemption, please answer “YES” to the question."
It's not hard to get approval for your app the proper way. SSL (HTTPS/TLS) is still encryption and unless you are using it just for authentication, then you should get the proper approval. I just received approval, and my app is in the store now for something that uses SSL to encrypt data traffic (not just authentication).
Here is a blog entry I made so that others can do this the proper way.
apple itunes export restrictions
Short answer: Yes, but you don't have to do anything
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
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 asked Apple the very same question and got the answer (from a Sr. Export Compliance Specialist), that "sending information over https is forcing the data to go through a secure channel from SSL, therefore it falls under the U.S. Government requirement for a CCATS review and approval." Note that it doesn't matter that Apple has already done this for their SSL implementation, but for the government, if you USE encryption that is the same (to them) as you would've coded it yourself. I also updated our blog (http://blog.theanimail.com) since Tim linked to it with updates and details on the process. Hope that helps.
All of this can be very confusing for an app developer that's simply using TLS to connect to their own web servers. Because ATS (App Transport Security) is becoming more important and we are encouraged to convert everything to https - I think more developers are going to encounter this issue.
My app simply exchanges data between our server and the user using the https protocol. Seeing the words "USES ENCRYPTION" in the disclaimers is a bit scary so I gave the US government office a call at their office and spoke to a representative of the Bureau of Industry and Security (BIS) http://www.bis.doc.gov/index.php/about-bis/contact-bis.
The representative asked me about my app and since it passed the "primary function test" in that it had nothing to do with security/communications and simply uses https as a channel for connecting my customer data to our servers - it fell in the EAR99 category which means it's exempt from getting government permission (see https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn)
I hope this helps other app developers.
If you use the Security framework or CommonCrypto libraries provided by Apple you do include crypto in your App and you have to answer yes - so simply because libraries were provided by Apple does not take you off the hook.
With regards to the original question, recent posts in the Apple Development Forums lead me to believe that you need to answer yes even if all you use is SSL.
As of September 20th, 2016, registering is no longer required for apps that use https (or perhaps other forms of encryption): https://web.archive.org/web/20170312060607/https://www.bis.doc.gov/index.php/informationsecurity2016-updates
In fact, on SNAP-R you can no longer choose 'encryption registration':
Specifically, they note:
Encryption Registrations no longer required – some of the information
from the registration now goes into the Supp. No. 8 to Part 742
report.
This means you may need to send an annual report to BIS, but you don't need to register and you can note when submitting your app that it is exempt.
Yes, according to iTunes Connect Export Compliance Information screens, if you use built-in iOS or MacOS encryption (keychain, https), you are using encryption for purposes of US Government Export regulations. Whether you qualify for an export compliance exemption depends on what your app does and how it uses this encryption. Attached images show the iTunes Connect Export Compliance Screens to help you determine your export reporting obligations. In particular, it states:
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
#hisnameisjimmy is correct: You will notice (at least as of today, Dec 1st 2016) when you go to submit your app for review and reach the Export Compliance walkthrough, you'll notice the menu now states that HTTPS is an exempt version of encryption (if you use it for every call):
I found this FAQ from the US Bureau of Industry and Security very helpful.
encryption
Question 15 (What is Note 4?) is the important point:
...
Examples of items that are excluded from Category 5, Part 2 by Note 4 include, but are not limited to, the following:
Consumer applications. Some examples:
piracy and theft prevention for software or music;
music, movies, tunes/music, digital photos – players, recorders and organizers
games/gaming – devices, runtime software, HDMI and other component interfaces, development tools
LCD TV, Blu-ray / DVD, video on demand (VoD), cinema, digital video recorders (DVRs) / personal video recorders (PVRs) – devices, on-line media guides, commercial content integrity and protection, HDMI and other component interfaces (not videoconferencing);
printers, copiers, scanners, digital cameras, Internet cameras – including parts and sub-assemblies
household utilities and appliances
Simple answers are Yes(App has encryption) and Yes(App uses Exempt encryption).
In my application, I am just opening my company's website in WKWebView but as it uses "https", it will be considered as exempt encryption.
Apple document for more info: https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations?language=objc
Alternatively, you can just add key "ITSAppUsesNonExemptEncryption" and value "NO" in your app's info.plist file. and this way iTunes connect won't ask you that questions anymore.
More info: https://developer.apple.com/documentation/bundleresources/information_property_list/itsappusesnonexemptencryption?language=objc
You can follow these 3 simple steps to verify if your application is exempt or not: https://help.apple.com/app-store-connect/#/dev63c95e436
You may need to submit this annual-self-classification to US gov. For more info: https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
LOOKS LIKE HTTPS COUNTS
link to "Learn more":
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
Just adding my personal interpretation of a very special case:
In my app the user has the option to go to a website themselves or let my app open Safari and Safari will call an HTTPS website. Could be any - own website, article etc etc. I interpret Safari making the actual HTTPS call, not my app and therefore answer the first question with No (or set the flag in the info.plist) and have no requirement to annually report.
If you're not explicitly using an encryption library, or rolling your own encryption code, then I think the answer is "no"
My client wants to encrypt/compress the html-code for their medical books in the iPhone bundle, to protect their IP.
Whats is a good way to prepare this file for the app bundle, and what complementary libraries (C, Obj-C) should I use to do the decryption and decompressing on the first launch of the app?
Copying the file to ~/Documents, then working on it seems like the best solution. Thoughts?
Here's a few thoughts.
If the book text is all alphanumeric data, then don't save the data as ASCII - save them in your own binary encoded format (for instance use 5 bits instead of 8 and pack into words). That gives you a bit of compression, slight obfuscation and a very cheap (in clock cycles) decompression. You would have a data format that is quick to access on the fly and will keep the casual curious hacker out of the text. Clock cycles would be my main concern and security second.
Another idea is store the decrypt key for a typical Blowfish encryption in obfuscated format in the app. Split into two or three constants that require some odd operation to restore for instance. But of course, now the overhead of Blowfish or whatever will be your concern.
Since you will not be able to implement perfect security (perfection is extremely expensive), the IP owners will have to use traditional copyright and trade secret techniques to fully protect their property. You've made it harder to hack, but it's still up to the lawyers to be diligent, just a book on the shelf in the reserved section of the library (no photocopies please!).
Cheers
This is quite tricky... almost impossible to make it really unbreakable. Any reasonnably motivated person will be able to pierce through it. You'll only make it a little harder to do. In any case, you definitely can't store any secret key in the bundle itself. You'd need to securely obtain the decryption key over a secure channel from a server and use it as needed. Even then, someone doing jailbreak would probably be able to run GDB over your running program and extract the secret key in RAM + the secret key would be shared amongst all users of your app... You're essentially trying to implement a DRM scheme, which is inherently flawed by design... Unless you need offline access, you might want to pull the data as needed from a secure erver... at least you "could" throttle information leakage...
I would keep the documents encrypted if I were you and just decrypt them as needed. One would easily be able to access the decrypted documents on a jailbroken device.
See the "Security Overview" document and the CryptoExercise sample code for encryption techniques
You probably won't like it, but the best way is to just not use HTML. Once you pass the decrypted HTML to UIWebView, it is very easy for a malicious user to steal it at that level, defeating any purpose your encryption algorithm had. A UIView subclass with custom drawing code and a custom encrypted backing format will be much more difficult to work around
From Mac OS X and iPhone OS Security Services:
You can use Keychain Services to
encrypt and store small amounts of
data (see Keychain Services Reference
and Keychain Services Programming
Guide). If you want to encrypt or
decrypt larger amounts of data in Mac
OS X, you can use the Common Security
Services Manager (CSSM) Cryptographic
Services Manager. This manager also
has functions to create and verify
digital signatures, generate
cryptographic keys, and create
cryptographic hashes. In iPhone OS,
the Certificate, Key, and Trust
Services API provides functions for
generating encryption keys, creating
and verifying digital signatures, and
encrypting blocks of data; see
Certificate, Key, and Trust Services
Reference.
It's always a choice between performance (encryption just doesn't come free) and security (security and everything else, really). But what else is new? If you keep the individual files small enough, maybe decryption doesn't slow you down much. Alternatively, you may consider predictive decryption such that you have certain files being decrypted in the background, say those linked from the currently viewed file, etc. I realize, however, that concurrancy on the iPhone may be pretty spotty (I don't know as I haven't dropped the cash for a license). You may also realize performance gains by only encrytping those files that really need it; does an index/table of contents or other often accessed file really need to be encrypted? Does that count as IP your client is worried about?
For compression I can recommend QuickLZ (fastest engine I saw, great compression ratio).