For my iOS 6+-only app, I would like to enable the On-Disk Encryption offered from iOS.
I read this guide and I saw the "Protecting the User's Data" video of the WWDC 2012 (Session 714). However, I could not make it work.
Here are the steps I followed:
1- In the iOS Dev Center, I created a new App ID with:
2- In Xcode, I added an Entitlements file with the key:
3- On the device, I activated a passcode lock.
If I'm not wrong, this should be all. I now expect that while the device (in my case: an iPhone 5) is locked, protected files are inaccessible. But... if I use iExplorer, I can easily access the files created by my app, even when the device is locked. But this is exactly what I want to avoid. Did I forgot something?
The reason you can access files without unlocking your device is that an escrow keybag has been created. This is explained in Apple's iOS Security Guide (pdf):
Escrow keybag is used for iTunes syncing and Mobile Device Management (MDM). This keybag allows iTunes to back up and sync without requiring the user to enter a passcode, and it allows an MDM server to remotely clear a user’s passcode. It is stored on the computer that’s used to sync with iTunes, or on the MDM server that manages the device.
The Escrow keybag improves the user experience during device synchronization, which potentially requires access to all classes of data. When a passcode-locked device is first connected to iTunes, the user is prompted to enter a passcode. The device
then creates an Escrow keybag and passes it to the host. The Escrow keybag contains exactly the same class keys used on the device, protected by a newly generated key. This key is needed to unlock the Escrow keybag, and is stored on the device in the Protected Until First User Authentication class. This is why the device passcode must be entered before backing up with iTunes for the first time after a reboot.
If you reboot your phone, you will not be able to access files without unlocking it once.
If you want that files to be available only when device is unlocked(+about 10 seconds of grace period), set file protection to NSFileProtectionComplete. Be sure to implement delegate methods to know when data will become [un]available.
Related
I have developed an iPad application and I have distributed that application to my clients. Now my clients ask what will happen if their iPad lost or stolen. My iPad application has very sensitive data. So they need to wipe out remotely if iPad is stolen or lost.
I found two solutions.
One is configure 'Find My iPad' in each iPad with same apple account.
Second one is configuring MDM server with push notifications.
If I'm going to configure MDM server I need to contact third party vendor who supports push notifications service of apple or I need to buy Lion Server and configure profile Manager.
Can some one tell me what is the best solution to implement and pros and cons of these two options.
Push notifications won't help you here - they only will pop up a message to the user, you cannot influence the app from them.
Possible solutions:
Protect your app with username / password: Each user should choose a username and password, store those in the keychain and check on app start. Of course you should also encrypt all data with the password when storing it to the device.
Like said above, implement a server request which gets the unique id of the installed app (of course you'd have to create one first on first app startup), returns whether the app is reported as stolen and then either do nothing or delete all data. I'd be careful about deleting though in case there was an error somewhere in your implementation and you wipe out a 'normal' application's data. Also in this case I'd encrypt any sensitive data that is stored to the device. This solution also won't work when the app is offline, of course.
Just make a web service and get response from server, and after getting response , run your application otherwise kill.
if(stolen)
exit(0);
else
run
My App can work with or without iCloud support.
If a user connects a device to iCloud and then wants to disconnect it, it's pretty easy for me to copy all data back to the local sandbox and stop using iCloud, and this device won't contribute anything new to iCloud anymore. However, changes from other devices will still be received (although not handled) on this device.
Is there a way to completely disconnect the device from iCloud, so that new changes won't be received?
iCloud stores data in a folder called "Mobile Documents." Your app's container resides in this folder. iOS devices know about new files and changes immediately. However, they do not actually download the file until the app specifically requests it. Here's an example scenario:
Someone is running your app on their iPhone and their iPad. They use iCloud on both. However, on their iPhone they disable your app's iCloud but leave their iCloud account active. This means that their device always knows about changes. But since your app never requests those documents, they are never downloaded to the device and therefore do not take up space. Also, iOS will automatically remove the local copy of an iCloud file to free up space if necessary.
For more information, see developer.apple.com/icloud, specifically the videos on how to use iCloud.
You can simply stop responding to the NSNotifications received by your app. You can either unregister your views from these notifications, or ignore them when they're received.
I've a multitasking application and I'm using all the app delegate events for backgrounding but when the device locked or idle timer expires none of the delegate events get fired. So I need to check device lock status.
Is there way to do this with SDK(non private api solution)?
Maybe you can watch after an item in the Keychain :
kSecAttrAccessibleWhenUnlocked
The data in the keychain item can be accessed only while the device is unlocked by the user. This is recommended for items that need to be accesible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.
Declared in SecItem.h.
From : http://developer.apple.com/library/ios/#documentation/Security/Reference/keychainservices/Reference/reference.html
From the discussion it sounds like you could use applicationProtectedDataWillBecomeUnavailable:
On a device that uses content protection, protected files are stored in an encrypted form and made available only while the device is unlocked. This notification lets your application know that the device is about to be locked and that any protected files it is currently accessing will be unavailable shortly.
If your application is currently accessing a protected file, you can use this method to release any references to that file. Although it is not an error to access the file while the device is locked, any attempts to do so will fail. Therefore, if your application depends on the file, you might want to take steps to avoid using that file while the device is locked.
I assume this will get called regardless of whether or not you are using protected files. I have not tested it yet though.
Everytime I get a call my old wallpaper shows even though I have a new one. I'm trying to find it on my iOS but I cannot seem to figure out where. So I'm trying to track down what folders gets backed up when i backup my iPhone since I have restored it and it's still there.
(I'm using a jailbroken device)
I know this isn't the actual folder names and etc but it will give you an idea what it's backing up though. Good Luck.
With iOS 1.1 and later
Safari bookmarks, cookies, history,
and currently open pages
Map bookmarks, recent searches, and
the current location displayed in
Maps
Application settings, preferences,
and data
Address Book and Address Book
favorites
Calendar accounts
Wallpapers
Notes
Call history
Mail accounts
YouTube bookmarks
SMS messages
Saved suggestion corrections (these
are saved automatically as you reject
suggested corrections)
Camera Roll (photos and screenshots
taken by the iPhone)
Voicemail token (This is not the
Voicemail password, but is used for
validation when connecting. This is
only restored to a phone with the
same phone number on the SIM card.)
Web clips
Network settings (saved Wi-Fi
hotspots, VPN settings, network
preferences)
Paired Bluetooth devices (which can
only be used if restored to the same
phone that created the backup)
Keychain (this includes email account
passwords, Wi-Fi passwords, and
passwords you enter into websites and
some other applications. The keychain
can only be restored from backup to
the same iPhone or iPod touch. If you
are restoring to a new device, you
will need to fill in these passwords
again.)
With iOS 2.0 and later (in addition to the above)
Managed Configurations/Profiles
List of External Sync Sources (Mobile Me, Exchange ActiveSync)
Microsoft Exchange account configurations
Nike + iPod saved workouts and settings
App Store application data (except the application itself, its tmp and caches folder).
With iOS 3.0 and later (in addition to the above)
Videos in Camera Roll
Per app preferences allowing use of location services
Offline web application cache/database
Voice Memos
Autofill for webpages
Trusted hosts having certificates that cannot be verified
Websites approved to get the location of the device
In-app purchases
New with iOS 3.1: Videos in the Camera Roll that are 2 GB or larger are not backed up (iOS 4 and later will back up videos 2 GB and larger)
All user documents and settings get backed up, Application settings as well as system settings.
Applications each have a Documents folder that user data can be saved to, so thats pretty much what gets backed up for applications, including app preferences.
These are the Wallpaper locations:
/private/var/mobile/Library/SpringBoard/HomeBackground.jpg
/private/var/mobile/Library/SpringBoard/HomeBackgroundPortrait.jpg
/private/var/mobile/Library/SpringBoard/LockBackground.jpg
/private/var/mobile/Library/SpringBoard/LockBackgroundPortrait.jpg
I have manually managed to find out what gets backed up and managed to solve the problem :)
I downloaded the trial of iphone packup extractor http://www.iphonebackupextractor.com/ and found what I was looking for.
Also it seems like I just had to change the lockscreen in the iPhone since the file called LockScreen.jpg was the picture I was looking for but since I had another lockscreen using winterboard I didnt think of this.
Good luck to anyone else who has problems similar to this.
My app is going to save a flag in the database (core data) saying whether the user is authenticated or not. How easy or difficult is to someone to access the "core data" database and change the information there without going through the App?
I am going to save a flag there saying "this user is authenticated" so he never has to authenticate again. This is a fun app, not a bank app, so I wonder if that's ok.
Putting in other words: Should I assume that a regular iPhone user (not jailbroken of course) will not be able to mess with the "core data" database and this database can only be accessed through its intended iphone app?
This isn't the kind of thing you should use Core Data for anyway. You should instead use NSUserDefaults or the keychain (depending on if you're just storing that flag, or associated user/password information).
The user defaults are there for storing settings, the keychain for private data. Use the right screwdriver for the right screw.
The iOS app sandbox is quite tight on-device. As such other apps won't be able to access your database, nor will the user on-device.
Application data in the app's Documents directory is backed up through iTunes, however. Though I've never tried such a thing, I can imagine a scenario where the user installs and runs your app but is not authenticated. He syncs and the user data is written to his computer. He opens the backed-up resource on his PC (iTunes does encrypt or obfuscate it) and figures out how to change the sqlite database or plist to show himself as authenticated. He then uninstalls the app on his device, then reinstalls it through iTunes, authenticating himself.
If the scenario is possible, you could potentially store the database in the cache directory instead, a directory that's not backed up when the device is synced with iTunes. It means the database would vanish if the user had to restore his device, but that might be an acceptable loss in your scenario, I don't know.
Edit
I agree with jer that the database isn't the best place to store such info, and if you're targeting iOS 3.2 and above, keychain is definitely the better place.
I don't believe a user on a non jailbroken phone would be able to mess with the data.