This is the first of three articles on securing user data at rest. In this post, we’ll start off with the basics of protecting data on iOS so you can learn the current best practices for storing data securely with Swift.
Any app that saves the user’s data has to take care of the security and
privacy of that data. As we’ve seen with recent data breaches,
there can be very serious consequences for failing to protect your
users’ stored data. In this tutorial, you’ll learn some best
practices for protecting your users’ data.
Permissions
Before we get into storing your custom data, let’s take a look at data that can be shared by system apps.
For many iOS versions, it has been required to request app permissions to use and store some of the user’s private data that is external to the app, such as when saving and loading pictures to the photo library. Starting in iOS 10, any APIs that access the user’s private data require you to declare that access ahead of time in your project’s info.plist file.
There are many frameworks that can access data outside of your app, and each framework has a corresponding privacy key.
- Bluetooth Sharing:
NSBluetoothPeripheralUsageDescription - Calendar:
NSCalendarsUsageDescription - CallKit:
NSVoIPUsageDescription - Camera:
NSCameraUsageDescription - Contacts:
NSContactsUsageDescription - Health:
NSHealthShareUsageDescription,NSHealthUpdateUsageDescription - HomeKit:
NSHomeKitUsageDescription - Location:
NSLocationAlwaysUsageDescription,NSLocationUsageDescription,NSLocationWhenInUseUsageDescription - Media Library:
NSAppleMusicUsageDescription - Microphone:
NSMicrophoneUsageDescription - Motion:
NSMotionUsageDescription - Photos:
NSPhotoLibraryUsageDescription - Reminders:
NSRemindersUsageDescription - Speech Recognition:
NSSpeechRecognitionUsageDescription - SiriKit:
NSSiriUsageDescription - TV Provider:
NSVideoSubscriberAccountUsageDescription
For example, here is an entry in info.plist to allow your app to load and store values to the calendar.
<key>NSCalendarsUsageDescription</key> <string>View and add events to your calendar</string>
If a usage description is missing when the API tries to access the data, the app will simply crash.
The Data Protection API
For any user data that’s internal to the app, the first thing to think about is whether you need to store the information, and what data is essential to
the app. Keep as much of that essential data in working memory instead
of in file storage. This is especially important for any personally identifiable information.
But, if you must store data, it’s a good idea to enable Apple’s Data Protection.
Data
Protection encrypts the contents of your app’s container. It relies on
the user having a passcode, and thus the security of the encryption is
tied to the strength of the passcode. With Touch ID and the upgraded
file system encryption introduced in iOS 10.3, the data protection
system has had many improvements. You can enable data protection across
your app by turning on Data Protection in the Capabilities section
of your project file. This updates your provisioning profile and
entitlements file to include the Data Protection capability. Data
Protection offers four levels of protection, depicted by the FileProtectionType structure:
none: no protection.complete: data is not accessible while the device is locked. This is the recommended setting for most applications.completeUnlessOpen: data
is accessible when the device is unlocked, and continues to be
accessible until the file is closed, even if the user locks the device. Files can also be created
when the device is locked. This option is good for when you need to open a file to process and have the process continue even if the user puts the app into the background and locks the device. An example might be a job that uploads a file to a server.completeUntilFirstUserAuthentication: when
the device is booted, files are not accessible until the user first
unlocks the device. After that, files are available even when the device
is locked again. The option is good for files that need to be accessed sometime later in the background when the device is locked, such as during a background fetch job.
complete is the default level. To help
avoid crashes when your code tries to access data that is locked, you
can register for notifications via UIApplicationProtectedDataDidBecomeAvailable and UIApplicationProtectedDataWillBecomeUnavailable to find out when the data is available.
NotificationCenter.default.addObserver(forName: .UIApplicationProtectedDataDidBecomeAvailable, object: nil, queue: OperationQueue.main, using: { (notification) in
//...
})
NotificationCenter.default.addObserver(forName: .UIApplicationProtectedDataWillBecomeUnavailable, object: nil, queue: OperationQueue.main, using: { (notification) in
//...
})
Additionally, you can also check the UIApplication.shared.isProtectedDataAvailable flag.
One important thing to keep in mind when enabling data protection is
that if you are using any background services such as background fetch,
that code may need access to your data in the background when the device
is locked. For those files, you will need to set a protection level of completeUntilFirstUserAuthentication. You can control the protection level of each file individually when creating files and directories using the FileManager class.
let ok = FileManager.default.createFile(atPath: somePath, contents: nil, attributes: [FileAttributeKey.protectionKey.rawValue: FileProtectionType.complete])
do
{
try FileManager.default.createDirectory(atPath: somePath, withIntermediateDirectories: true, attributes: [FileAttributeKey.protectionKey.rawValue: FileProtectionType.complete])
}
catch
{
print(error)
}
You can also set the protection level when you write to a file. The Data object has a method that can write its data to a file, and you can set the protection level when you call this method.
let data = Data.init()
let fileURL = try! FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: false).appendingPathComponent("somedata.dat")
do
{
try data.write(to: fileURL, options: ([.atomic, .completeFileProtection]))
}
catch
{
print(error)
}
You can also set the protection level when setting up your Core Data model.
let storeURL = docURL?.appendingPathComponent("Model.sqlite")
let storeOptions: [AnyHashable: Any] = [NSPersistentStoreFileProtectionKey: FileProtectionType.complete]
do
{
try coordinator.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: storeOptions)
}
catch
{
print(error)
}
To change the protection level of an existing file, use the following:
do
{
try FileManager.default.setAttributes([FileAttributeKey.protectionKey : FileProtectionType.complete], ofItemAtPath: path)
}
catch
{
print(error)
}
Data Integrity
Part of protecting your stored data includes checking
its integrity. It’s good practice not to blindly trust the data you
are loading from storage; it may have been accidentally or maliciously
altered. The NSSecureCoding protocol can be used to
safely load and save your data objects from storage. It will make sure the objects you load contain the expected data. If you will be saving your own object, you can conform
to the secure coding protocol inside your class.
class ArchiveExample : NSObject, NSSecureCoding
{
var stringExample : String?
...
The class must be inherited from NSObject. Then, to turn on secure coding, override the supportsSecureCoding protocol method.
static var supportsSecureCoding : Bool
{
get
{
return true
}
}
If your custom object is deserialized with init?(coder aDecoder: NSCoder), the decodeObject(forKey:) method should be replaced with decodeObject(of:forKey:), which makes sure that the correct object types are unpacked from storage.
required init?(coder aDecoder: NSCoder)
{
stringExample = aDecoder.decodeObject(of: NSString.self, forKey: "string_example") as String?
}
func encode(with aCoder: NSCoder)
{
aCoder.encode(stringExample, forKey:"string_example")
}
If you are using NSKeyedUnarchiver to load data from storage, make sure to set its requiresSecureCoding property.
class func loadFromSavedData() -> ArchiveExample?
{
var object : ArchiveExample? = nil
let path = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)[0] as String
let url = NSURL(fileURLWithPath: path)
let fileURL = url.appendingPathComponent("ArchiveExample.plist")
if FileManager.default.fileExists(atPath: (fileURL?.path)!)
{
do
{
let data = try Data.init(contentsOf: fileURL!)
let unarchiver = NSKeyedUnarchiver.init(forReadingWith: data)
unarchiver.requiresSecureCoding = true
object = unarchiver.decodeObject(of: ArchiveExample.self, forKey: NSKeyedArchiveRootObjectKey)
unarchiver.finishDecoding()
}
catch
{
print(error)
}
}
return object;
}
Turning on secure coding for your save operations will prevent
you from accidentally archiving an object that does not adhere to the
secure coding protocol.
func save()
{
let path = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)[0] as String
let url = NSURL(fileURLWithPath: path)
let filePath = url.appendingPathComponent("ArchiveExample.plist")?.path
let data = NSMutableData.init()
let archiver = NSKeyedArchiver.init(forWritingWith: data)
archiver.requiresSecureCoding = true
archiver.encode(self, forKey: NSKeyedArchiveRootObjectKey)
archiver.finishEncoding()
let options : NSData.WritingOptions = [.atomic, .completeFileProtection]
do
{
try data.write(toFile: filePath!, options:options)
}
catch
{
print(error)
}
}
Beyond NSSecureCoding, it’s always
good to implement your own data validation checks upon unpacking any
archive or receiving any arbitrary input in general.
Data Trails
As iOS continues to evolve, there are always new features
that have the potential to leak stored data. Starting in iOS 9, you can have your content indexed in the Spotlight search, and on iOS 10 you can expose your content to Widgets such as the Today Widget that shows up on the lock screen. Use caution if you would like to expose your content with these new features. You might end up sharing more than you planned to!
iOS 10 also adds a new Handoff feature where your copied pasteboard data is automatically shared between devices. Again, be careful not to expose any sensitive data in the pasteboard to Handoff. You can do this by marking the sensitive content as localOnly. You can also set an expiry date and time for the data.
let stringToCopy = "copy me to pasteboard"
let pasteboard = UIPasteboard.general
if #available(iOS 10, *)
{
let tomorrow = Date().addingTimeInterval(60 * 60 * 24)
pasteboard.setItems([[kUTTypeUTF8PlainText as String : stringToCopy]], options: [UIPasteboardOption.localOnly : true, UIPasteboardOption.expirationDate: tomorrow])
}
else
{
pasteboard.string = stringToCopy
}
Files that are saved to the
device’s storage can automatically get backed up, either in iTunes or in
iCloud. Even though backups can be encrypted, it’s a good idea to
exclude any sensitive files that don’t even need to leave the device. This can be done by setting the isExcludedFromBackup flag on the file.
let path: String = ...
var url = URL(fileURLWithPath: path)
do
{
var resourceValues = URLResourceValues()
//or if you want to first check the flag:
//var resourceValues = try url.resourceValues(forKeys: [.isExcludedFromBackupKey])
resourceValues.isExcludedFromBackup = true;
try url.setResourceValues(resourceValues)
}
catch
{
print(error)
}
The animation that happens when putting an app into the background
is achieved by iOS taking a screenshot of your app which it then uses
for the animation. When you look at the list of open apps on the app
switcher, this screenshot is used there too. The screenshot gets stored
on the device.
It’s a good idea to hide any views
revealing sensitive data so that the data isn’t captured in the
screenshot. To do this, set up a notification when the application is
going to the background and set the hidden property for the UI
elements you want to exclude. They will be hidden before iOS captures
the screen. Then when coming to the foreground, you can unhide the UI
elements.
NotificationCenter.default.addObserver(self, selector: #selector(didEnterBackground), name: .UIApplicationDidEnterBackground, object: nil) NotificationCenter.default.addObserver(self, selector: #selector(willEnterForeground), name: .UIApplicationWillEnterForeground, object: nil)
Remove your notifications when the view disappears.
NotificationCenter.default.removeObserver(self, name: .UIApplicationDidEnterBackground, object: nil) NotificationCenter.default.removeObserver(self, name: .UIApplicationWillEnterForeground, object: nil)
Your
app also has a keyboard cache for text fields that have auto-correct
enabled. Text that the user types, along with newly learned words, are
stored in the cache so that it is possible to retrieve various words
that the user has previously entered in your application. The only way
to disable the keyboard cache is to turn off the auto-correct option.
textField.autocorrectionType = UITextAutocorrectionType.no
You should mark password fields as secure text entry. Secure text fields don’t display the password or use the keyboard cache.
textField.isSecureTextEntry = true
Debug
logs are saved to a file and could be retrieved for production builds
of your app. Even when you’re coding and debugging your app, make sure not to log sensitive information such as
passwords and keys to the console. You might forget to remove
that information from the logs before submitting your code to the app store! While debugging,
it’s safer instead to use a breakpoint to view sensitive variables.
Network
connections may also get cached to storage. More information about
removing and disabling the network cache can be found in the article Securing Communications on iOS.
Destroying Data
You may already know that when a file on a
computer is deleted, often the file itself is not removed; only the
reference for the file is removed. To actually remove the file, you can
overwrite the file with random data before removing it.
The switch to
solid state drives has made it hard to guarantee the data has been
destroyed, and the best way to securely delete data is open to debate.
However, this tutorial would not be complete without an example of how
to wipe data from storage. Because of some other debates about the Swift optimizer, and because we hope to guarantee that
each byte of the file is actually being overwritten, we are implementing
this function in C.
The implementation below can go inside a .c file.
You will need to add the function definition or the file that contains the function into your bridging header
in order to use the function from Swift. You may then want to call this function right before
places where you use FileManager‘s removeFile methods.
Perhaps you may want to implement the best practices described in this and the upcoming
tutorials on an app update. You could then wipe the previous
unprotected data during migration.
#import <string.h>
#import <sys/stat.h>
#import <unistd.h>
#import <errno.h>
#import <fcntl.h>
#import <stdio.h>
#define MY_MIN(a, b) (((a) < (b)) ? (a) : (b))
int SecureWipeFile(const char *filePath)
{
int lastStatus = -1;
for (int pass = 1; pass < 4; pass++)
{
//setup local vars
int fileHandleInt = open(filePath, O_RDWR);
struct stat stats;
unsigned char charBuffer[1024];
//if can open file
if (fileHandleInt >= 0)
{
//get file descriptors
int result = fstat(fileHandleInt, &stats);
if (result == 0)
{
switch (pass)
{
//DOD 5220.22-M implementation states that we write over with three passes first with 10101010, 01010101 and then the third with random data
case 1:
//write over with 10101010
memset(charBuffer, 0x55, sizeof(charBuffer));
break;
case 2:
//write over with 01010101
memset(charBuffer, 0xAA, sizeof(charBuffer));
break;
case 3:
//write over with arc4random
for (unsigned long i = 0; i < sizeof(charBuffer); ++i)
{
charBuffer[i] = arc4random() % 255;
}
break;
default:
//at least write over with random data
for (unsigned long i = 0; i < sizeof(charBuffer); ++i)
{
charBuffer[i] = arc4random() % 255;
}
break;
}
//get file size in bytes
off_t fileSizeInBytes = stats.st_size;
//rewrite every byte of the file
ssize_t numberOfBytesWritten;
for ( ; fileSizeInBytes; fileSizeInBytes -= numberOfBytesWritten)
{
//write bytes from the buffer into the file
numberOfBytesWritten = write(fileHandleInt, charBuffer, MY_MIN((size_t)fileSizeInBytes, sizeof(charBuffer)));
}
//close the file
lastStatus = close(fileHandleInt);
}
}
}
return lastStatus;
}
Conclusion
In this article, you have learned about setting permissions for the data that your app has access to, as well as how to ensure basic file protection and integrity. We also looked at some ways that user data could be leaked accidentally from your app. Your
users put their trust in you to protect their data. Following these best
practices will help you repay that confidence.
While you’re here, check out some of our other posts on iOS app development!
iOS SDKSecuring Communications on iOS
Mobile DevelopmentBack-End as a Service for Mobile Apps
iOS SDKThe Right Way to Share State Between Swift View Controllers
SwiftSwift From Scratch: Closures
