I need to protect a file with user data, however I can't really verify if built-in iOS mechanism works. I implemented data protection in my app by:
Enabling Data Protection in AppId
Updating provisioning profiles
Adding Data Protection to entitlements.plist (entry: com.apple.developer.default-data-protection = NSFileProtectionComplete)
Setting attribute FileProtectionComplete on my file
Turning on passcode on iPhone
I was able to confirm, that this attribute is set properly. However, I tried to lock device, wait about 1 minute and access file through iExplorer or by downloading app container from Xcode->Devices and every time I'm able to get non-encrypted content.
I wonder if it's a matter of debug build or not. Is there any way to download encrypted file to confirm that data protection really works (without jailbreaking)?
Related
On iOS, if a file is stored using .completeFileProtection it is encrypted by the OS and only accessible when the device is unlocked according to the documentation.
In another app I looked at, the developers had encrypted all files manually and then stored the symmetric key in the device keychain.
I'm wondering if there really is any security benefit from doing that rather than using the built in .completeFileProtection? Or would it ever make sense to do both?
To my understanding, with an additional encryption, files will remain encrypted even when device is unlocked.
Also, file will be decrypted only when app needs to read it. With this approach, the app could decrypt and read files even in background mode — if we don't change the level of data protection, since default is NSFileProtectionCompleteUntilFirstUserAuthentication.
I've been researching literacy about the secure aspect of the NSUserDefaults leveraged by the ManagedAppConfig capability of iOS.
We are leveraging this "new" iOS capability to configure our enterprise application via various MDM systems used in our customers landscape.
A debate is now raging on how secure it is.
From our side, the only way that we have found to get this information is to actually JailBrake the device. Which of course would be detected by the MDM system.
Any other security vulnerability that we may have missed there ? Anybody looked into the security aspect of this feature ?
Thanks!
Ingrid.
Everything you store un NSUserDefault is easily accessible (with an app like iExplorer for mac, for example). No need to jailbreak. It is all stored in a .plist file in the Library/Preferences folder of your app.
I had to hide some information before, the way I did it was by using Data Encryption. For more information, read the section called Enabling Data Protection
All you would need to do after enabling correct data protection, is to create a file and store your configuration there. By putting the Data Encryption to NSFileProtectionComplete, your file will be visible, put not readable when the device is locked. For this to work, the user must have set a password on his device
My application captures location data in background and saves in sqlite database. It works well when Device is not locked, but when device is locked I am not able to access sqlite database. It always gives me error code as SQLITE_AUTH(error code:23).
I have tried below options:
Disable the Data Protection from Capabilities.(Does not work)
As per Failed to create SQLite3 database with file protection in iOS, I tried the below code :
sqlite3_open_v2([dbPath UTF8String], &myDatabase, SQLITE_OPEN_READWRITE|SQLITE_OPEN_CREATE|SQLITE_OPEN_FILEPROTECTION_COMPLETE, NULL)
But still its not working.
Could you please help me, How to access the sqlite database in background.
You need to enable Data Protection from your app from iTunesconnect.
1. Enable data protection for your app. For example,
2. Add below file protection key and value into your plist or entitlement file,
<key>com.apple.developer.default-data-protection</key>
<string> NSFileProtectionCompleteUntilFirstUserAuthentication</string>
The type must match to your capability set from itunes server.
3. Rebuild and test if the issue is resolved
File Data Protection
In addition to the hardware encryption features built into iOS devices, Apple
uses a technology called Data Protection to further protect data stored in flash
memory on the device. Data Protection allows the device to respond to common
events such as incoming phone calls, but also enables a high level of encryption
for user data. Key system apps, such as Messages, Mail, Calendar, Contacts,
Photos, and Health data values use Data Protection by default, and third-party
apps installed on iOS 7 or later receive this protection automatically.
Data Protection is implemented by constructing and managing a hierarchy
of keys, and builds on the hardware encryption technologies built into each
iOS device. Data Protection is controlled on a per-file basis by assigning each
file to a class; accessibility is determined by whether the class keys have been
unlocked. With the advent of the Apple File System (APFS), the file system is
now able to further sub-divide the keys into a per-extent basis (portions of a
file can have different keys). Find detail here in section File Data Protection.
I am trying to implement SSL mutual authentication in an iOS app.
In most of the examples that I have seen, the client certificate is bundled with the application package. But in my case, I need to load the client certificate remotely (i.e, from a link or via email).
If I try to load a certificate from an external source (i.e, mail app), it navigates to settings app and install it to the apple's keychain. So this certificate is not accessible with my app.
So anyone please suggest an idea for this ?
I built a system like this in our internal iPad app.
Forget the System preferences, profiles, etc. All certificates installed in this way are inaccessible to third party apps but only to the system apps, probably because are installed into the Apple keychain.
I have explored these three methods to load the certificate and used the last one:
Bundle into the app, as you have already seen is impractical
Send a file from another app (e.g. email)
Use a link to download (what I did)
FOREWORD
I think you have built your simil-PKI, with a CA, an automatic/manual way to issue/revoke certificates, etc.
So the problem is the delivery to devices.
For all the solutions I suggest to save the private key and cert in PKCS #12 format with a strong password.
Use an MDM to manage the devices and if your app is internal and will be used with company's devices supervise them for added options
(e.g. Meraki, is free but do not handle the ManagedAppConfiguration)
SOLUTIONS
Solution 1)
Impractical because is very hard (to impossible) to generate different versions of the app with specific certificates. Not to mention that will be nearly impossible to handle the distribution of a specific version on every single device of the users.
Solution 2)
Save the .p12 file
change the file extension to a custom one
register that extension to open with your app, so in the "Open in..." will be listed your app
"Open in" for specific document type
The safest way should be that the user can select the password to encrypt the .p12 file so when the p12 will be opened the user must enter his password but this lead to other work to make it work.
A less safe but working method is to use a single strong password embedded in the app and use that for all .p12 files
Solution 3)
Similar to 2) but you download the file directly from a specific URI of your web application, this allow some automatic configuration because the app can identify himself.
Basically these are the steps:
the app connects to a specific URL of our application via HTTPS.
checks that the server certificate is correct (trusted origin).
send something to authenticate.
In our case I use the device name that I set up during device preparation and I can change it remotely using MDM.
download the configuration bundle with the certificate in it
I use a JSON payload to send the PKCS #12 file base64 encoded and other data to config the app.
If your MDM supports ManagedAppConfiguration you can change a bit these operations to build a more flexible behavior:
With ManagedAppConfiguration you can send a specific string inside every app NSUserDefaults remotely, so you can use a different or temporary URLs/tokens to download the config bundle and ditch completely the use of devices name for authentication.
WWDC 2014 #704 - Building Apps for Enterprise and Education ~13:00
Apple Developer - ManagedConfig Sample App
ADDED PARANOIA
log everything! Everything that this part of the app does (failed/wrong requests, not existent device names requests, etc)
the configuration URL is activated/deactivated only when we need to configure new devices.
You can done this a lot of ways, my webapp checks for the presence of a specific file so I can do something like touch APP_CERTIFICATES_CONFIG_ENABLED to activate the auto-configuration service and disable everything deleting the file.
Just to be sure that no certificate will go around without my supervision.
I have a quick question:
I downloaded an iOS application that uses the NSFileProtectionComplete class to protect a sqlite file that contains sensitive information.
According to the iOS security documentation (http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf), when a device (iPhone/iPad) is paired with the laptop, the laptop obtains the escrow keybag from the mobile device . The keybag contains all the class keys necessary to decrypt information on the device.
However, I noticed that when I pair the device with the laptop and use iExplorer to browse the file system, the sqlite file is only available when the device is unlocked. When the phone is locked (still paired) the file is not readable. Files which are not using NSFileProtectionComplete can be viewed while the device is locked.
If the escrow keybag contains all the class keys to decrypt information, why do I have to unlock the device to access it through iExplorer?
I'm using iOS 6.0 on an iPad3 and used the ios-dataprotection tool (https://github.com/ciso/ios-dataprotection) to determine the data protection class used by the files.
iOS Application: AccountVault
File: PointMinder.sqlite
Any help will be appreciated.
Thanks.
From documentation file you've linked:
Complete Protection (NSFileProtectionComplete): The class key is
protected with a key derived from the user passcode and the device
UID. Shortly after the user locks a device (10 seconds, if the Require
Password setting is Immediately), the decrypted class key is
discarded, rendering all data in this class inaccessible until the
user enters the passcode again.
So device should be unlocked if you want to access that files. That is how Apple made it.
Edit: Found in "Hacking and Securing iOS Applications":
Protection class keys are master encryption keys used to unlock files based on their access policy.
Protection classes are the encryption mechanism used to enforce the access policies of files.
Some files are so important that the operating system should be able to decrypt them only when the device’s user interface is unlocked. These files’ encryption keys are wrapped with a class key that is available only after the user has entered his passcode. When the device locks again, the key is wiped from memory, making the files unavailable again.
Protection class master keys are stored in an escrow known as a keybag. The keybag contains the encrypted protection class master keys, as well as other keys to system files on the device. The system keybag is encrypted using another encryption key named BAGI, which is also stored in the effaceable storage of the NAND. Whenever the user authenticates to meet a specific security protection policy, the encrypted keys in the keybag can be decrypted.
So keys for that files are transferred, but are encrypted. When you enter your passcode, OS decrypt that key and it can then be used to decrypt files protected with it.
This works for me for SQLite databases in my app only, not for my other resources as I was hoping. BUT, I was having the same issues still being able to access the databases after locking the device and waiting several minutes with iExplore still open and device still connected. If I disconnect the iPad and connect right back in, iExplore forced to refresh I guess and I then could NOT access the databases. So not sure if it just has the old 'unencrypted' database info in memory or what.