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.
Related
App Store Review Guidelines says: "Apps that download code in any way or form will be rejected."
I'd like to make an app using Challenge-Response for authentication. The app has a set of basic algorithms such as SHA-1, SHA-256, MD5, DES, AES and so on. The challenge server makes contains an array of the algorithms' name with random arrangement and a string names A. Client uses the algorithms and the sequence that challenge indicates to manipulate string A, and returns it to the server as the response.
Although all I transfer between server and client is a bunch of strings, but they indeed change the behavior of my app. Should I consider them a form of code? If not, why downloading shell code to execute is forbidden by Apple? I mean, shell code is also a bunch of strings and interpreted by running environment. Where is the essential difference?
Forgive my English :)
What Apple is worried about and wanting to prevent is applications that get through the approval process (disguised as something benign) and later change their fundamental function.
An extreme example would be an application downloading new, malicious executable code after it has been installed on the user's device.
Apple is using broad wording in order to be able to reject any app that in any way tries to be harmful to the user. It would be impossible to specifically describe every technique and specific way this could happen, so Apple keeps the wording loose.
Apps "download code" in some form or another all the time, consider an application that accesses an API that returns JSON formatted responses. Technically that could be considered code, and it can change the apps behavior (which view to show, what options would be available on a certain view, etc). But an app that access an API in this manner would certainly not be rejected.
From what I can gather from your question, it sounds like you don't have to worry about that particular clause in the guidelines.
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 am building an iPhone app, and I currently need to encrypt a string, store it in a file and be able to decrypt it later. As I understand, I can use symmetric encryption to do this but my key for encryption/decryption can be reversed-engineered. Assymetric encryption can solve this problem but it seems I would need a server to send the data to decrypt with the private key. Does anyone know of a way I can encrypt/decrypt the string securely in a stand-alone app?
Thanks!
As with all matters concerning security, the question is: who are you defending against?
If you are trying to prevent the casual thief (or script kiddie) from reading an encrypted string, using the built-in iOS cryptographic services, such as the Keychain, can provide adequate-to-good security. Obviously the strength of the security will hinge in part on various factors beyond your control (notably, what sort of password lock, if any, the user has configured for the device).
The next level up would be symmetric encryption using a symmetrically encrypted key (i.e. one protected by a user passphrase). As #lukas noted, of course in principle this can be cracked, but from a practical standpoint if the user chooses a sufficiently strong passphrase for a sufficiently large key, a casual to intermediate-level attacker will be effectively thwarted.
If, on the other hand, you need to keep secrets, as Bruce Schneier would say, not from your kid sister but from major world governments, these approaches are likely to be insufficient, and you will have to explore other options, including but not limited to storing the string in multiple locations, using multiple keys, and multiple factors of authentication.
The lead Apple reference for all this (save the last option) is the Secure Coding Guide, which has references at the end of the opening page to the other more specific programming guides (covering, e.g., the Keychain and Cryptographic Services). I also heartily recommend Graham Lee's Professional Cocoa Application Security. If you want a theoretical foundation, the gold standard is Schneier's Applied Cryptography.
This basic question is asked pretty constantly on Stackoverflow. The answer is that you cannot obfuscate yourself to security against your own customers, and you should never spend excessive money trying. I recommend the following links to find the many previous discussions:
Best practices for iOS applications security
Secure https encryption for iPhone app to webpage
From the above you will find several more links. But the final answer is that you are likely trying to solve the wrong problem, and the problem you think you want to solve is unsolvable.
Does anyone know of a way I can encrypt/decrypt the string securely in a stand-alone app?
No. If someone have the physical access to the data it can be cracked. Make a webservice to solve the problem.
Have you considered using Keychain Services?
Recently we developed and published a mobile banking app on the app store, for a big banking organization. The bank hired a security firm to perform ethical hacking over the app to see if it, in anyways compromises confidential data.
We recently received the hacking report from the firm, which in-spite of saying that no serious security issues are present, contains a list of all the class files, method names and the assembly code of the project.
Now the client insists that we fix these security loop holes and republish the app. However we don't have any idea how did they manage to get all these details from the application's IPA. I searched this over SO and found a particular post mentioning this link, which states that you can't save your app from being hacked.
Please help me how to fix these security vulnerabilities , or if not possible, how to convince the client.
Edit:
Recently came across this page. Seems like EnsureIT from Arxan can prevent app IPAs from reverse engineering. Anyone experienced with this?
There's always a risk involved. Even if you don't introduce vulnerabilities yourself, the platform may allow for exploits which in the end may offer an entry point for a malicious attacker.
As to your question: It is not safe to assume that a hardcoded URL, even if obfuscated beyond belief, can't be peeled out of your product. Always design your apps such that safety of user data is guaranteed (as far as possible) even if built in ressources get compromised. If the knowledge of that URL alone poses a security threat, then your whole approach and your clients API is inherently insecure. Remember that such information could possibly be captured by a man-in-the-middle attack (and other modes of attack) as well.
Avoid security by obscurity. Store sensitive data only on disk if it is necessary. As a rule don't allow PIN / TAN storage.
Some thoughts which may (or may not) convince your client that your app is as safe as it can be:
As long as the app runs on a non-jailbroken device, it is unlikely that an attacker, even with knowledge of your apps internals is able to get to any user data, because the iPhone normally doesn't offer opportunities to interfer with your app
If the attacker is able to get to your users data, and provided you have been protecting that data with all means available under iOS (-> keychain -> crypto chip ->...), then it's not your fault. It means the device is either jailbroken or there are vulnerabilities to the system itself which have been exploited, you just can't do anything about either possibility.
It is impossible to prevent reverse engineering of your app. Even if you had put more effort into obfuscation, an attacker with strong motivation would still be able to get what he wants. Your client needs to get used to this as it's a fact.
Other platforms suffer from similar vulnerabilities, yet on the iPhone at least you have a somewhat closed environment and a reduced risk of being attacked with trojans and the like.
The governments and security firms get hacked on a regular basis, although they should now how to protect themselves. This means life is inherently insecure, cope with it.
I was recently researching over this and I found this article helpful, especially the part quoted:
The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.
Security in iOS: Protecting .ipa File Content by Stoyan Stoyanov
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).