HP Security Research Blog
The HP Security Research blog provides a platform for security experts from across HP to discuss innovative research, industry observations, and updates on the threat landscape to help organizations proactively identify and manage risk.

How Protected is My Data at Rest?

One of the highest risk items on mobile devices is the sensitive data that users store, transfer, and access through apps. Protecting that data from other applications is one consideration, however, we also have to consider the very real possibility of having the device stolen and compromised.

 

Starting with iOS4, Apple provides a data protection API to encrypt data being stored on a device. However, developers need to be aware that the data protection classes, even when used properly, are dependent upon the user configuring their Apple device to have a passcode. Now in iOS7, Apple provides a more secure default setting that encrypts data for third‐party apps, until the user first unlocks their device after each reboot (NSFileProtectionCompleteUntilFirstUserAuthentication), provided that there is a device passcode. By enabling a device passcode, data protection is automatically enabled. Presently, iOS supports both four‐digit and arbitrary‐length alphanumeric passcodes.

 

Due to the passcode being "entangled" with the device's UID for the encryption keys, the strength of the passcode is very important. Strength of a passcode is directly linked to the number of symbols in the dictionary for the passcode combined with the length of the passcode. More precisely, the number of passwords is defined as (number_of_symbols)^(length_of_passcode). For example, a four‐digit passcode would provide 10^4=10,000 possible passwords. If we assume that a brute force attack is able to perform passcode‐guessing at a rate of 10 guesses per second then a 9‐digit passcode using only numbers would take roughly 3 years to brute‐force, a 6‐character passcode using only lowercase letters and digits would take roughly 7 years to brute force, and a 4‐digit passcode (the default for most users) would take roughly 17 minutes. A very good breakdown of the encryption is provided in “iOS Hacker’s Handbook” by Miller et al.

 

While the user controls the strength of the passcode, it is up to the developer to enforce the correct level of encryption to protect their data when it is viewed to be at risk. The Data Protection API is designed to let applications declare when items in the keychain and files stored on the filesystem should be encrypted (available for file and database APIs, including NSFileManager, CoreData, NSData, and SQLite). Passing one of four protection class flags to existing APIs for iOS, allows developers to instruct the underlying system when to automatically decrypt the specified file or keychain item. When a developer marks a resource as having the attribute NSFileProtectionCompleteUnlessOpen, or NSFileProtectionCompleteUntilFirstUserAuthentication, the resource is only protected with encryption that is based upon the UID key of the device and the passcode. When a developer marks a resource as having the attribute NSFileProtectionNone, which is also the default Data Protection class, the resource is only protected with basic encryption that is based upon the UID key of the device. As such, the default setting prior to iOS7 leaves the data unprotected and may be accessed at boot time and while the device is unlocked.

 

To provide a contextual example, we consider a simple example of what storing an NSString to a file might resemble (assuming default data protection in iOS 4 through 6):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES
  encoding:NSUnicodeStringEncoding error:&err];
...

Which would be logically equivalent to the following (explicitly specifying the equivalent default):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
... BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err]; ...

To enforce complete data protection (protected at all times unless the device is unlocked):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionComplete forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...

It is a developer’s responsibility to protect sensitive data (granted iOS 7 eases this burden with a better default setting for data protection). Ultimately, however, it is not enough to just enforce data protection in the source code. The user of the device must be educated in the use of strong passcodes if the data on an Apple device is to be kept secure (for example, if a device is stolen).
Note: Additional information on the Data Protection API may be found here.

Tags: encryption
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.