Can an iPhone app encrypt its stored data? So that even a user with a Jailbroken iOS device cannot access the file. For example, game-center may sync with local data, you do not want the user manipulating the scores. You do not want your IAP be circumvented either.
Is there a simple way to encrypt your data before writing to the device?
Maybe my questions are not very clear. Indeed they are:
When I'm using things like: [array writeToFile:path atomically:YES]; is there any auto-encryption that ensures only my app can access the file correctly?
If not, what is the simplest way to achieve it?
PS: now I found NSData can do the job, but the NSDataWritingFileProtectionComplete flag requires #if __IPHONE_4_0 <= __IPHONE_OS_VERSION_MAX_ALLOWED. I wonder what happens on not-supported devices?
More information on iOS encryption in #GrahamLee's answer to this question and on other iOS tagged questions on security.stackexchange.com.
Basic summary is - based on iPhone controls alone:
If someone has the device and it isn't locked, they can access all the data
If someone has the device and it is locked, they can get most of the data, and possibly all (some exceptions may apply)
You could obfuscate, and use encryption within your app when storing data, but an attacker could reverse engineer that encryption code to decrypt.
You need to work out the value of such DRM techniques and decide whether they are worthwhile in this scenario.
That docs will help you to find more accurate answer:
http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords.pdf
http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-faq.pdf
Related
is the data stored on an iPad/iPhone encrypted?
I assume that the iPad/iPhone has an advanced pass code (not just the 4-digit code).
So my question is if data that my custom app stores in the device is encrypted or not (if no special methods are taken in the source code of the app). Would an attacker be able to read the data? What if he jailbreaks the device?
Thanks!
The answer is no if you don't apply any encrypting technique on it. You can try to use iExplorer to browse all the sandboxes of your device's applications. You may get surprised about the security of many apps out there.
I am just starting getting familiar with security in iOS, but from what I read and understood from Apple's IOS Security whitepaper, files are encrypted by per file encryption keys and those are encrypted by class keys assigned by the application that owns the files (which are sandboxed with the application). And then, the files access depends on the protection policy you assigned in your application.
However, from this answer, it is unclear if the encryption is always on, or just when the device if off or unlocked.
In any case, the above applies from non jailbreaked systems (not sure if they do for jailbreaked ones as well).
In an iPhone iOS4 app containing an existing SQLite database (i.e. there at compile time), how secure is the data in the SQLite database?
For example, is it worth encrypting an SQLite database (using the sqlite3_key(...) method sold under license)?
It is secured until the iPhone is jailbreaked. After jailbreak one can go to your database and can copy it to his desktop and then can see your data. So I think if you have very important data then you should encrypt your database
First question you have to answer is how valuable is your data? That somewhat determines how much time a hacker is willing to spend trying to get at it. Security is a complex subject and you could spend days researching IOS security. It depends heavily on the IOS version, with IOS 4 being the first release that has a decent chance of being really secure. First off nothing is secure unless your device is locked. Also, your database is NOT encrypted even if the device is locked unless you set data protection flags in your code. Sandbox doesn't help you here at all really, except to protect one apps data from another. A hacker with your device will jailbreak it and install an SSH server and at that point can pretty much do whatever they want, including brute-force passcode breaking attempts. If an IOS 4 device was locked with a decent passcode and you set data protection on your database, you are probably ok with counting on the IOS hardware encryption. But can you depend on users to set a decent passcode? The default simple passcode is only 4 digits - not that great. And will they all be IOS 4+ users? If not, you'll need your own encryption on the database. Just don't store the key anywhere, cuz hackers will find it. And while you are considering security in your coding, consider that hackers can also decompile and run a modified version of your app.
AFAIK data are physically encrypted on iOS 4.x devices. Add to that the fact that application are sandboxed, it's a fairly secure system.
I want to create an app which holds sensitive information (imagine it's bank account details, thought it's not). The user enters this information on a form the first time the app starts up. I want this info to be saved, and available, any time the user uses the app (without having to enter a password). However, if the iPhone has a password lock on it, and is stolen, I don't want the data to be easily accessible from the file system.
What is the best way of encrypting or obfuscating the data? There is not a lot of data, just a dozen NSStrings from the UITextFields on the form.
I'm aware there are encryption export restrictions on the iPhone for non-US developers (I am in UK), so I would prefer to avoid going jumping through any of Apple's app submission hoops to get it on the store.
Why not use the built in Keychain Services? That's what it is for.
EDIT: There an article in SDKDevFAQ.com about Keychain Services that points to a tutorial and sample code on github. Also, check out this blog entry about using the Keychain.
I don't know if a jailbroken iPhone device lets you read NSUserDefaults from other applications or not. If not, you could just store your information in there instead of as a file.
Alternatively, you could generate some salt based on (but not equal to) the device ID, and simply XOR it with the bytes of the strings. As long as your algorithm to generate the salt isn't trivial and the strings aren't too long, the data will be fairly safe. Without getting into heavier encryption stuff, you can't guarantee too much more than "fairly safe".
I have a iPhone app which needs to have a self destruct option. This app is going to be use on sensitive locations and holds some algorithms which are not to be known by anybody except the iPod Holder.
What would be the most "complete" way of deleting the app?
I was thinking of some how writing zeros to the nib file. or the actual application.app but I believe this folders are write protected and sandboxed.
Anybody have any ideas of better ways to achieve this?
Elaboration (Taken from original poster's comments):
This is for a jailbroken iPhone.
These devices are going to be provided to military personnel this device falling into enemy hands would be the least of my concerns. It's going to have a button so wipe the app once the app is written to zero or better yet corrupted with garbage all over the "exe" the app has no way of working and it would require inspection of the iPod flash chip with equipment that i 100% know the wrong people wont have
If you are openly storing the code that contains this algorithm within your application, there's nothing stopping the "wrong people" from jailbreaking the device and copying the complete file structure of the device before you run your "wipe" process.
Additionally, if you are dealing with a U.S. Government customer, I doubt that they will approve of the purchase of a jailbroken device, given that the vendor of such a device has claimed that jailbreaking is illegal. Whether or not this will hold up in court, the government tends to be conservative in these matters and err on the side of caution. Because Apple is a large U.S. company and a vendor to the government, I wouldn't expect the government procurers to take the jailbreakers' side in this.
My recommendation would be to encrypt the particular algorithms within a file in your application's bundle, and require the user of this application to decrypt this file into memory with the correct (difficult) password. That way, even if the "bad guys" were to gain access to the application, they wouldn't have everything they need to access these algorithms and would have to brute-force the password on the encrypted portion. This could be done on a standard, non-jailbroken device.
The U.S. Army is rolling out iPods in the field, with custom applications on them, so I'm sure that you're not the first person facing this challenge. If this work is being funded through a Department of Defense SBIR grant (or similar), you may even be able to contact your contracting officer and see if they can put you in touch with people at the appropriate agency who may be able to help you out with this (or even determine if it an issue to begin with).
I'm going to go out on a limb here and say you may not want to use the iphone for this type of app. There are intentional limitations to this exact type of action on the iphone and in springboard. If you are doing something so sensitive that it can't fall into unauthorized hands my recommendation would be to use a different and more customizable/controllable platform.
Unless you're working from a jailbroken device, you're probably going to run into problems here.
Even if you can find a way to automatically delete the app, you're still running the risk of those algorithms getting into the wrong hands - you would essentially be running into the same problems that Apple has with jailbreaking - once the device is in someone else's hands, it only takes the proper amount of motivation for the data to be accessed.
The only way to secure your algorithms is to pass the data to a remote server and get the results. There's still a possibility of a security breach, but it's much, much lower.
I don't know how well this would work, but you could store the algorithm as a file inside the application bundle, run the algorithm from that file possibly using a scripting language or something, and delete that file if you need to.
The folders are sandboxed, but your application is in there. On my jailbroken iPhone I see that all the permissions are owned by mobile so I don't see any reason why you can't just overwrite all the files with zeroes and then delete them.
The application bundle is effectively read-only, perhaps you should store some of the information in an encrypted form somewhere on a network.
Even if you find a way to write over the app in the flash memory, you really aren't erasing the app. Flash memory chips use wear leveling algorithms to reduce writes to the same blocks and so when you write out zeroes they are typically written to a new block of memory and not to the same block used before, so you really aren't erasing anything. The data can still be recovered from the flash chip (by a pro).
Another option is to separate out the parameters of the algorithm so that the algorithm is no longer sensitive (or at least not usable) and provide the parameters encrypted in a file. Then provide the key to authorized users via the network and don't store that key into flash, only RAM. They would need to get the key every time they start the app. Only give the key to authorized users. Of course, you'll also need to encrypt that key for transmission over the network with another key... There are systems for doing this, don't invent your own, in any case you'll need a crypto expert to do this right.
I would use the built in encryption to store the data, with a key the user has to enter to decrypt it. Without the key it doesn't matter if the data blob is recovered from the device.
What are accepted methods to reduce iPhone application piracy, which do not violate Apple's evaluation process?
If my application "phones home" to provide the unique device ID on which it runs, what other information would I need to collect (e.g., the Apple ID used to purchase the application) to create a valid registration token that authorizes use of the application? Likewise, what code would I use to access that extra data?
What seem to be the best available technical approaches to this problem, at the present time?
(Please refrain from non-programming answers about how piracy is inevitable, etc. I know piracy is inevitable. I am interested in programming-based answers that discuss how to reduce it. Thanks in advance for your understanding.)
UPDATE
Please visit and read
Thanks to chpwn in the comments.
Code that's way too old! - 11th May 2009
For now there's an easier way to detect if your iPhone application has been cracked for piracy use. This does not involve you to check the iPhone unique IDs against a list of accepted IDs.
Currently there are three things crackers do:
Edit the Info.plist file
Decode the Info.plist from binary to
UTF-8 or ASCII
Add a key-pair to Info.plist{SignerIdentity,
Apple iPhone OS Application Signing}
The last one is easiest to check with this code:
NSBundle *bundle = [NSBundle mainBundle];
NSDictionary *info = [bundle infoDictionary];
if ([info objectForKey: #"SignerIdentity"] != nil)
{ /* do something */ }
Generally we don't have SignerIdentity in any of the App Store applications we build so checking for nil then performing set instructions should make it more difficult for crackers and pirates.
I can't take credit for this so please visit How to Thwart iPhone IPA Crackers. There's loads of information there about piracy on iPhone and how to curb it.
As pointed out by Andrey Tarantsov in the comments, looking for the "SignerIdentity" string in the binary (using an app like HexEdit) and replacing it is pretty easy.
You could encode that string, but then again all you have to do is change one char of it and the app is not going to look for the "SignerIdentity" key anymore but for some other key that probably doesn't exist (therefore is null). That key being null, the app thinks it isn't cracked (since SignerIdentity should be null if the app isn't cracked).
Instead, I'd rather check the size of the info.plist and compare it to a reference value. I noticed Simulator and Devices builds don't have the same info.plist file size. Same goes for Debug, Release and Distribution builds. Therefore, make sure you set the reference value using the info.plist file size for the Device Distribution Build.
How to look for the filesize at launch:
It looks like saving MD5 checksum of Plist and checking CryptID should do well till some time.
Check iTunesMetadata.plist for the date of Purchace as sometimes, when an app is cracked, that date is changed to something outrageous.
Also check to see if the purchacer name field exists. In my experience with cracking apps for personal use, that is usually removed. If anyone knows how the anti dump protection of Temple Run works, you could use that in conjunction with some protection that poedCrackMod can't get (google poedCrackMod create hackulo.us account, go to dev center look for poedCrackMod, install it on iDevice).
Clutch which will not crack things with Temple Run like protection, has a feature called OverDrive intended to silence an app's crack detection. poedCrackMod has LamestPatch, which isn't as good. Also poedCrackMod is an open source bash script that can be reverse engineered. To recap, you have an app that has copy protection that can't be circumvented with clutch / overdrive but can be cracked with poedCrackMod. However poedCrackMod can't circumvent the app's in app piracy checks. It is hard to manually patch integrety checks in the app's executable. So your app is hard to crack.