Hello, everyone. My name is John Wright. I'm part of Platform Technologies in Core OS. We're responsible for a lot of the security infrastructure in iOS. And today, we're going to talk about-- a little bit about protecting data on the phone. So we're going to go over-- this is our agenda. So first, I'm going to talk a little bit about what data protection is and what security mechanisms we have in place in iOS and kind of how they've evolved over the different releases.

And then we're going to kind of do a deep dive into the design of our data protection mechanisms, and this is more for your security analysis. This is not something that you actually need to know. It's all done under the covers. But I think a lot of you that are kind of in the trust-but-verify hats, really want to know this information.

Then we're going to talk a little bit about enabling data protection, both from a user standpoint and from an enterprised standpoint of managing a device. And then we're going to talk a little bit about the API's that you-- that we want you to adopt in your applications to be in data protection and how to protect your user's data.

So these devices that we have, these phones and iPads and iPod touches, they're very personal devices, and they have a lot of-- more data on them than we've ever had before ringing around people's pockets. And one of the things that is kind of a challenge here is that them being so mobile also means they're more easily stolen by someone.

And you have a lot of different data on here. You have all your messages from your messaging systems, you have your accounts for those social networks, you might have accounts for financial information, and you might have even enterprised apps that you're actually responsible for protecting your company's information. So this has become very, very important, being able to protect this data, especially in a mobile environment.

So what we introduced last year on iPhone 3GS was all the data was encrypted in place. Now, we actually added special hardware to these devices that would have no performance impact. Basically, it's you know, hardware encryption engines in the hardware that would do it for no performance, no battery life impact whatsoever. Now, the big reason that we did this was we want a really fast experience of Remote Wiping.

So Remote Wipe is that you can send a signal to the phone as long as that phone is still online that it will erase all that customer's data. So you can do this from, you know, if the device is lost. And we wanted that to be very, very fast. And if you encrypt all the data, you can just throw away the keys, makes it very fast.

Now, it also has this concept of protecting the data at rest. Now, this is kind of a concept that evolved from desktops. And the idea on desktops is that a lot of desktops, you can image your data and move it to somewhere else to try to compromise, or someone can steal a hard drive out of it. Now, this doesn't really apply to a lot of these mobile devices. So it makes-- if you have that device, it makes that device still very vulnerable to a local attack.

Now, the other thing that we added last year was encrypted backups. And this means that the data is protected when it is off the device and being backed up to a host machine. So what we're introducing for iOS 4. We have this goal to keep the data safe even if the device is compromised. So what we did is we added the ability to tie the encrypted data to the user's passcode. So this means that it's actually something that the user knows themselves that unlocks that data, so that data is only available when the device is unlocked.

Now, we added API's in so you can choose data availability, whether it's only available when the device is unlocked, or it's available all the time. And we went about adopting this in iOS 4 in mail, which is by far, the most complicated app and does the most complicated background activity. And we're making those API's available for you to adopt in your apps, so you can tie into the same security mechanism.

And I want to emphasize here again, there's absolutely no performance impact to this because we're doing this all in the hardware engine itself, and it's all just streamlining with how the data reads and writes out of the hardware. Now, I also want to mention that we still had to enable encrypted backups, and we actually had retool all of our infrastructure to do this.

But we got one big benefit. We now can allow the key chain to be migrated between devices if they are in an encrypted backup. So this was kind the last kind of excuse not to use the Keychain is that your credentials wouldn't move from device to device when your users upgrade.

Well, now they do. In an encrypted back-up scheme, they just move right across. So passcodes, we are tying this to the passcodes. But I want to remind everyone that the passcode is only as good as you make the passcode. And passcodes can be pretty forced. So if you choose one, two, three, four as your passcode, it's not gonna be very strong. Someone is going to guess that.

So we put a bunch of mitigations in place. Now, the first mitigation that we've always had in place is that we have back off between failed attempts on using the UI to putting someone's passcode. So it's kind of incremental as you have failed attempts. But by the sixth failed attempt, it takes like, 10 minutes for the UI to come back up and offer to you to put your passcode here. So this makes, you know, someone who's stolen your device, if they are just trying to punch the numbers it makes it pretty difficult for them to guess. It takes them a long time.

Now, we've also had the ability to force complex passcodes on the device. We've had this for a while with configuration profiles. Now, what's new for iOS 4 is we actually give you a user-configurable setting in the settings-- on the settings tab to actually force the complex-- or to actually use a complex passcode. Also, we've had the ability to force and erase of all the user's data after a failed numbers of attempts at the passcode. This is also something in iOS 4 that we've made user-configurable in settings.

Now, another thing that we did in tying all the data to the passcode is we, not-- didn't just tie it to the passcode itself, we also tied it into a set of device keys in the hardware. And the reason that we did this is that it makes it-- it prevents people from taking the data off the device and trying to brute force passcodes there, since it's actually encrypted also with a key that's only available in the hardware. That means that you actually have to-- someone would actually have to do an attack on that hardware itself. And our hardware is fast, but it's not as fast as a botnet. So this actually limits the speed of an attack on these passcodes.

So I want to kind of just run through what technologies we put in iOS and kind of why we put them there over the generations of releases. So obviously, we have had, since the first iPhone, a passcode. And this was really, you know, at that time meant to prevent casual device access.

It was meant to stop someone, kind of, at the door and make them know one number before they could actually use that device. Now, even at that point in time, we had some Privilege Separation and Sandboxing. And what Privilege Separation is, it means that applications, either in the OS or third party applications, only have access to those services that they have privileges for.

And Sandboxing is that basically, they only have access to those documents or API's that they have privileges for. Now, this has kind of evolved over time because obviously, in the first release of iOS, there was no third party apps. And as we added third party apps, we added more Sandboxing, we put those apps in the Sandbox.

Now, for iOS 2, we also added Code Signing. And the reason that we did this is that now, the user knows that-- they know that there is known origins for every piece of code on their device. This makes it much more difficult to spread around viruses and the like because you can actually trace it back to whether it's an enterprise, inhouse app, or whether it's an app from the App Store, or whether it's code from Apple. We also added Remote Wipe at that time. Now this would, you know, like I said before, erases all the data in the phone, if that phone is still online, you can send it a signal.

And obviously, at that time, what has to happen is we actually had to overwrite the data with zeros essentially, to erase that data. And then actually, it was a pretty long process, especially for the larger storage devices. So last year, we added encrypted storage. The main reason for that is to make Remote Wipe very, very fast, and we added encrypted backups, which protects the data off the device.

And now, we're adding data protection. And this really means that even if a device is compromised in some way, it's stolen and it's a compromised device, that user's data is still protected because it's protected with something that only that user knows. So you can see where this is all going here.

We want all the apps to adopt data protection, both throughout the OS and throughout all of your apps. So we start it with Mail which is the most complex app, and we want you to go through your app and choose how your data is protected. Now, the big thing here is that for app surges in the foreground, when the device is locked and not doing anything, it's pretty easy to choose they want their data protected by the passcode. If you are doing some kind of multitasking app that has some kind of background task, you have to be a little bit more careful with your data, and you have to choose a few different classes to figure out how to do that.

But we want you to start adopting these API's and these concepts into your apps because our real ultimate goal here is that when the user puts on their passcode, they know all their data is protected no matter what. So I'd like to invite up Mitch Adler, one of our Security Architects, to talk a little bit about-- more about the mechanism behind us.

Thanks, John. As John said, I'm going to take you on a little deeper dive into the mechanisms we put together in our system to help protect the user's data with their passcode. It-- the goal, as John said, is that when the device is locked, the user should be able to be confident that their device is protected.

And in iOS 3, we were relatively confident that if I-- my device is locked and I hand it to somebody and I watch them not penetrate the defense of the device, they're not going to be able to get through my passcode very easily because we limit the tries and all of the mitigations that John talked about. But for iOS 4, we want to provide a mechanism that the user can be confident that even if they've lost their device, if their passcode, if their device is locked, that their data is actually protected with their passcode, the strength to their passcode.

That requires that we actually encrypt their data with some derivation of their passcode. And this is very useful, but we run into a problem. And that problem is that applications want to use some of that data sometimes when the device is locked. So we needed to provide a mechanism for applications to specify jar system how they want given data protected. That mechanism is data protection classes. There are three data protection classes that we have established in our system in our API. The first class is available and unlocked. That's the most protecting class.

The availability and the protection are kind of reverse of each other, when something is available to the system than an attacker who manages to get through our outer protections and get inside the system can masquerade as an application and access that data. So if you set your data be able-- if you set your protection class to one that to-- WhenUnlocked, we'll protect the data cryptographically when the system is locked, and we'll make it available to your app when it's unlocked.

The second class is available after fist unlock. This is the kind of compromise class. We noted that many of the attacks on the device that compromise devices and get access to running code on the device requires the device reboot. In the process of rebooting, we can reset things that have been exposed.

So we add the second class, so that if there is data that you need to continue accessing while the device is locked, for example, credentials to reconnect to your server because you've changed networks and now you need to reconnect and revalidate, you can protect those credentials better than not at all, but still have them available when the device locks and unlocks, because after the first unlock, it will be available for you. And then if somebody attacks the device and then forces it to reboot, we'll reprotect that data.

The last availability class is what we've had traditionally on all of our storage up to this date, which is it's available always. It is no less protected than it has been in the past, but it doesn't gain anything from data protection. But it's a way to express that need, if I need my data to be exactly the same as it is. So the two major clients of these classes that present them to you in the file system, which presents availability for WhenUnlock called ProtectionComplete and that available always called ProtectionNone, under the Keychain which provides availability for all three, WhenUnlocked, AfterFirstUnlock, and Always.

So these two clients, there is some risk that if the two clients were sharing all of their keys and classes, that if I were a client of one of the systems, I could use it to attack data stored in the other system. So for that reason, we make these very much independent. They have very intentionally similar semantics.

So when you're thinking about how you store your data, you can think about the problem the same way for the two systems. But from the point of view of how the data is protected, we use completely separate class keys to represent those classes, so we can isolate-- the people can access the Keychain from the people who are allowed to access the data on the file system.

I'm going to run through a quick example to demonstrate how we take some data that the user has and protect it through our new design system in iOS 4. So here's an example of a file, a mail that I happen to compose on the device, and it needs to be protected.

In iOS 4, every file in the file system or how it's made is protected with a file key. This is slightly different than it was in iOS 3 and that the whole file system is protected by a key. But in iOS 4, there's a randomly generated new key for every file that gets created.

That file key is stored in the files metadata. That file key is, in turn, protected by a class key. This is a class-- a key that was randomly generated at the time the class was established, and it protects the file key. If you don't have the class key, can't see the file key. If you don't have the file key, you can't see the contents of the file. Each class key is protected by an appropriate set of keys in the system depending on its semantics.

In this particular case, this is a-- protected with the user pin key, it's protected by two keys, the device key, to make attacks off the device less practical, and the user passcode key which is the tie that ties the protection of the file back to the passcode. The file is protected by the file key, the file key is protected by the class key, the class key is protected by the user passcode key.

There's one more thing that we needed to support in this architecture, and that was the ability to do fast Remote Wipe. In the past we have thrown away the one master file system key and it erased-- cryptographically erased the entire file system. Now that we don't have exactly one master key, we had to build one back in, and that's on all the metadata. The file metadata has file system key, that key, when erased, makes it cryptographically impossible to view the data on the file.

So to take this particular example, and show you how we take a collection of data and protect it, for an entire file system, we can have one file, like we just showed you, protected, the file protected by it's file key, the file key protected by it's class key, and the class key protected appropriately by a device key in our user passcode key. But since we've gone through this class key, we can have as many files as we'd like protected in this class.

So there's no limit, the class-- the-- each file can specify it belongs to this class. We also don't have to limit ourselves to how many classes we want. We can have a second class with exactly the same protections and maybe some different semantics on how you get the class key, and we can store it on the same data storage, same file system. We can have a third class with different semantics. In this particular example, this would be accessed always.

There's no protection that extends from the user passcode key to this class key. So this is how we store on our system things that are always available that are protected by the device key, but they're not protected by the user passcode key. The collection of classes that protect data on the system, we call a keybag.

The-- that collection of class keys is an important structure in our architecture. It's what embodies locking, unlocking, and protection states. There are three kinds of keybags we operate in our system with. There's the System Keybag, there's a Backup Keybag, and there's an Escrow Keybag. The first two are relatively important for everybody to understand. The last one is an interesting detail for anybody who wants to do security analysis on their device.

System keybags, these are the ones you'd imagine, as I've just described, they're sitting on the system, they're protecting your system. They hold the class keys for all the data that's on your system. They have one tweak they do. They force all of the class keys, and then to be protected with the device key that makes it hard to attack this keybag off the device.

They're stored on the system. They're actually stored on the file system, which is interesting, because the fact that they're stored in the file system means that if you use a weak passcode that's trying to protect this keybag, and we leave that data on the file system, somebody later can come and find it even if we've moved on to a new keybag and use that old keybag to try and steal your class keys. Because when passcodes change, we don't change the class keys. That way, we don't have to scour the entire file system trying to update it for this metadata.

So in order to mitigate that attack, we actually protect the storage of the keybag on the file system with a key that we can erase. Every time the user changes the passcode, we destroy the old key, we write a new copy of the Keychain out of the keybag out, and we write a new-- we use a new key, and we randomly generate a key.

So we've cryptographically erased the old keybag so that it's older, maybe weaker, passcode protection is not exposing my device anymore. The system keybag is also responsible for managing the lock and unlock state of the system. When the user enters their passcode, the system keybag is asked to expose the class keys that should be exposed when the device unlocked, and when it's told the device is locking, it discards those keys, forgets those class keys.

So it's-- this is the center of the universe of the device locking and unlocking and protecting the user's data. But in order for us to maintain our encrypted backups and to maintain our protection through it, we also created backup keybags. Backup keybags are created new for every back up. Their class keys are generated randomly and are different for every backup you've-you storeon your host.

This holds the class keys that protects the data while it sits in the backup on those machine. These class keys, instead of being protected by the pin, are protected by the backup password. So when you have a protected backup, we-- everyone who would have used the pin on the device are going to be using the backup password in the protected backup keybag.

We happened to use PBKDF2, for those who care to generate the key. I don't remember the number of iterations off top of my head, happy to look it up for you if you want to know. If you don't choose to have a backup password though, we do one thing to protect credentials that are on the Keychain.

If you don't choose to protect your backup, we protect some of the Keychain class keys with the device key, and not the backup password key, causing them not to be able to migrate, and we'll get into that in more detail later in Adoption. The last kind of keybag is a keybag we created to enhance user experience. It was created for systems to be able to hold on to. It's called the Escrow Keybag. It was created for other systems to hold on to improve user experience.

The downside is that the improved user experience we want is systems that sync with your device, can sync without you having to enter the passcode on your device. And right there conceptually, is a security issue, in that now there is data in the world that can unlock my device. So we did a few things to mitigate it. First, we considered that the system that you're storing the Escrow Keybag on is a system you're already syncing you data to.

So if somebody can compromise that system and get your Escrow Keybag, additionally being able to compromise your device, if they can get their hands on your device, is not a big leap in security weakness. It's a little-- it's irritating and annoying but it's not of great loss, because most likely, all of your sync data is sitting on that host that was compromised. Them getting your Escrow Keybag is a potential future problem, but immediately, they've probably already taken all of your data.

The other thing we do is that we keep a key on the original device so we can invalidate the Escrow Keybag. It's part of the protection. The class keys in this keybag are protected with a device key, so this keybag can't be brute force except with access to the device, and the key we generated when we made the Escrow Keybag and stored on the device.

So if we could throw that key away on the device, we can make that Escrow Keybag cryptographically incapable of reading the data on the device. So anytime we decide that somebody's not worthy of trust, we can throw away the key, of course, part of the Escrow Keybag, and they can't access our data anymore.

Something I didn't mention is the Escrow Keybag does contain actual copies of the master class keys for the devices classes, which is why it can unlock the device without the user's passcode. So to dive a little deeper into the filesystem protection, all of the filesystem data is encrypted. Everything on the filesystem. It has been since iOS 3.

We've changed how we encrypt out the data on the filesystem. The metadata uses the filesystem key as I showed you in the diagram. That's what destroyed on Remote Wipe and breaks the chain of cryptographic exposure, so we-- your data is not exposed. The files are encrypted to an individual file key which is stored in the metadata.

The default, when you're creating a new file in iOS 4, is ProtectionNone. This is mostly for compatibility with applications, we don't want you to break all the applications that do anything across lock. We want them to opt in and decide what they-- how they want to protect it. And again, a reminder, there's no performance impact. We are already encrypting and decrypting. We've just changed what keys we're using in the process of pushing stuff back and forth to the file system.

The Keychain-- it's also protected by classes just for the Keychain, as the concept of migratable and not migratable. That as-- that actually doubles the number of classes that are available for the Keychain because you can put a piece of data into any of the three classes, and either migratable or not migratable. The default on the Keychain will remove data from back to a device by iOS 4, or if you create data without adopting data protection, will be always as migratable.

The three new classes that aren't migratable have the suffix ThisDeviceOnly. So WhenUnlock, ThisDeviceOnly, WhenUnlock-- AfterFirstUnlock, ThisDeviceOnly, AlwaysThisDeviceOnly. So this is a change that is in significance to people who want to protect data and don't want it to move form device to device, because our default now is going to allow things to migrate through a protected backup. We thought that was the right compromise for user experience. But if you have data that is really not supposed to migrate off of this device ever, you'll need to update your use to annotate that data and say it's not supposed to migrate.

Handling of the passcode. So one of the most critical things in trying to keep the user secret a secret is how we handle the passcode, because we have given that secret, and we have it for a while, and we really don't want to keep it because it's the user secret. It's not our secret. So we do two things to try and help protect that user secret.

The first thing we do is try and make it difficult to brute force attack the key that we derive from the passcode to avoid simple brute forcing the-- a user's passcode. And as John mentioned, we take a hardware key, something that's actually embedded in hardware individual to a given device, we do a derivation with that hardware key which resembles PBKDF2, but isn't exactly, and do a bunch of iterations to make you need to use that device in order to be able to attack the passcode.

This means that an attacker whose managed to get access to your device, broken through our outer defenses, gotten to the point where he's got a copy of your system keybag and wants to try to unlock it, and knows what it should look like-- what the header it should look like if it's unlocked, actually has to keep trying on that device to unlock that keybag. This helps us be able to control the time it takes to attack once. For example on an iPhone 4, on a new hardware, we use 50,000 hardware operations to drive the key from the original passcode. It takes about 50 milliseconds, give or take.

And if you do the math from there, for a reasonable passcode somebody's put on the device, it starts taking significant amounts of time, cryptographically interesting amounts in time, for you to brute force somebody's passcode. The other thing we do is we handle the passcode and the passcode key very carefully.

When we've given the passcode, and we to return it into a passcode key, we're careful to erase remnants to make sure that the user secrets stays the user secret. The thing we retain when the device unlocks, are the exposed class keys. So when we move from state to state, class keys come and go, and they're available and they're not.

Example of this, a device boot, we start out-- we don't know the user's passcode, he's never entered it, we're fresh and clean. The only class that is available is the always class, ProtectionNone, AlwaysThisDeviceOnly are available, the first two protection classes aren't available yet because we don't-- we haven't been able to unwrap the class keys. When the user enters their passcode, we unwrap the class keys, we-- if we get their passcode and their passcode key that help protect the class keys, but we keep this class keys around. So now, all of the classes are available.

WhenUnlock, AfterFirstUnlock, they're all available, the device operates, people do their normal operations. But at some point, the device gets locked, either by idling to lock or by the user clicking the lock button and wanting the device to lock itself. When that happens we forget the class keys for the first class. So that things that are only available when unlocked are no longer available, the device is locked. Note that the second class stays around as is defined after FirstUnlock, it remains available until we reboot, then we'll get back into the initial state, we've lost all the class keys.

So in summary about our mechanism and how we put this all together, our protection extends through a keybag, it comes from the user's secrets and device keys to bind it to the device and bind it to the user, it goes to the filesystem in the Keychain and the data stored in those places. The passcode key derivation has been made resistant to brute force attack to help protect the user's passcode. And the Keychain contents have been made migratable when we have protected backups. And with that, I'll hand it back to John to talk some more about configuration.

Thanks, Mitch.

. So for user-enabled data protection, actually on an iPhone 4, it's extremely simple. The formats already there in the device. All they have to do is set a passcode, and data protection is enabled. Now, on our last generation of devices, including iPhone 3GS and the iPod touch, the 3rd generation iPod touch, it's a little bit more complicated and that we don't have the right file system format on those devices, and you have to upgrade the file system format. And the way we do that is with an Erase Install.

And so, the user has to backup their device, do a full Erase Install, and then restore from that backup. And of course, the iPad is also capable of doing this, and it will inherit this feature with iOS 4, and it will also require an Erase Install to get that feature.

Now, to check to see if Data Protection is enabled if you go to Settings-> General-> Passcode Lock, and there is a picture right there, if you look at that little string at the very bottom of that screen, it basically says Data Protection is enabled. So now, you know you have it on that device. Now, I want to point out a couple of other things on this screen.

So I told you before that users now can configure their device to be able to Wipe if-- on 10 failed passcode events. That is that setting right there. And they're also able to set a arbitrary complex passcode by turning off the simple passcode, and then the dialog that comes up to change their passcode is a full alpha numeric keyboard, and they can choose what size length complexity they want.

Now, for devices that are being managed and our system to manage these devices is-- our Configuration Profiles. You can set this Configuration Profiles to enforce certain security requirements, and I'd like to point a few of those out there. So, the first one is that you can require data protection to be enabled on that device.

You can also require a passcode be set, the link of that passcode, and the complexity of that passcode. You can also require a minimum passcode grace period, and the grace period is how long a user has from the time they turn off the screen to when they turn on the screen again that it requires a passcode.

And you can also inquire that all the backups from that device are encrypted backups. Now, something else that we're introducing with iOS 4 is a way to manage your mobile devices, a bunch of API's actually use these Configuration Profiles with third party servers and third party device management systems. And these device management systems will be capable of doing initial device configuration and automatic updates of these Configuration Profiles, and then also be able to implement their own Remote Wipe capabilities.

And there was a whole session on Tuesday that went over how these API's work. And we've assumed that third parties will be adopting these into their device management systems. So that really makes a very capable management system for you guys to be able to implement these security type-- or these security requirements as well.

So the whole idea here is that we want configurations to be dead-simple for any users. We really don't want them to think about it other than they set their passcode. And we want these security requirements to be fully manageable by enterprises. And that's really the whole configuration story there. So I'm going to turn it over to Mitch to talk a little bit about adoption of these API's in your apps

So I'm going to talk a bit about how you adopt Data Protection in your application. To go back to what John was talking about a little bit, we really want to protect your customer's data, we want to protect all of our mutual customer's data, we want you to assume the data needs protection. You don't actually know what data users are going to decide to put inside your app. If you're making a note-taking app, they might put their credit card number in your app. It doesn't seem like a good idea to me, but they might do it.

We need you to help put the data into the right class. Since we don't automatically try and protect all your data to preserve functionality of your application, we need help from you to know how you want that data protected, so that we can do the best protection we can for the user.

We recommend you find the most protected class, and we'll get it to how you decide on what's the most protective class you can. It's here. We also want you to help put the user data back into places that's protected because the file system and the Keychain are protected by Data Protection. RAM, you have your user's information and it's not protected by Data Protection. So somebody can attack the device and get into your process, which is not an easy feat.

But if they can do it, they can steal data that's in RAM. So we recommend that you push the data out of RAM, push it into the protected containers when the device locks. So one of the first things you're going to have to do when you're going to adopt is analyze your data to figure out what you need to protect. You pretty much need to answer these four questions, and you can figure out what class and what location and how you want to protect that data.

The questions are what data of the users do I have, do I need it when it's locked, you know, does it belong in the Keychain, should it move from device to device, and we'll get in to each one of these. So how do I answer what data of the users do I have. Well, it's everything they create.

It's all the data users are entering, and it's the credentials that they enter to connect to things, and it's credentials you create on their behalf, if you make a connection and then wanted to create credentials to make a persisting connection, or reestablishable connection, those credentials are data of the users because it represents them.

Do I need that data when the device is locked? Well, for most app writers, the answer is no. If the device locks, your app doesn't do much, it's waiting for the user to come back and interact with it. So you don't. But some background-aware applications are going to need things like credentials, and they're going to want to put those credentials in such a way that they get protected, but they're still accessible.

Which is why we have the compromise of AccessibleAfterFirstUnlock, which is a good place to put things like credentials you want to use and be able to reuse as users move around their networks but want to get some protection from the classical kinds of compromises, which involve a reboot.

Then you have to ask does it belong on the Keychain. This is a question we've talking about for a very long time. Credentials belong on the Keychain, particularly, things that you want to migrate around. Things like passwords, keys, identities you've establish for the user or imported for the user. Large bulk data doesn't really belong on the Keychain itself.

Should it move from device to device? Well, the simple answer is yes. The user wants their stuff to move from device to device. But the more complex answer is, well, unless you have some compelling reason then it doesn't, and you'll-- you in this room will probably aware of why you would want that to be the case.

We have an example on our system when you import VPN configuration profile, and you set up a VPN identity, that's the identity of the device, not of the user. So those identities stay on the device. They are not permitted to migrate from device to device. But we have to make our system aware of the fact that those might go away if I restore a backup. I'll get half the data back, but I won't get the migrated VPN identity, and I'll have to deal with that state.

So if you don't have a compelling reason to make it non-migratable, make your data migratable. So we'll go through a few examples to help clarify this. The first example I have is a theoretical game. I have a game that has some online play, it has some credentials it stores. It has some saved games it stores.

That's pretty much all the data we have from the user. So for each one of these, I've gone through the questions. Do I need access to the credentials when the device is locked? Well, no, my game has stopped and the device is locked. I don't need to connect to my server. It's-- we're done at that point.

Do I need it to migrate? Well, it's credentials and the user would like to be able to reconnect to our server if they migrate to a new piece of hardware. So, yeah, I'd like it to migrate. Does it belong in the Keychain? It's a credential. It belongs on the Keychain. So I'm going to put it on the Keychain and I'm going to give it the attribute AccessibleWhenUnlocked, the best protection I can.

I also have saved games which have similar attributes. Yes I-- actually, no, I do not need access to them when they're locked, yes, I want them to migrate, but, no, they don't belong on the Keychain. So the protection class I give them is ProtectionComplete, and I use their location on the file system to control their migration. I put them in my documents folder in my app, and those automatically get me moved into my backup and moved back to my app, and they're accessible when I won't migrate from device to device.

Second example is an online service. So suppose I have an online service that has decided to participate in a new background task completion multitasking type, and it has some credentials, it has some data that is trying to push up to the server in the background, or it's trying to not burden the user with failing to push my photo up to the server, and it has some cash data it wants to display because it's got some stuff it's pulled down from the server for fast access.

And all of these are user data. So start with the service credentials. I have some service credentials that I do need when it's locked because I'm participating in background task completion, and I might change networks and need to reconnect to actually complete the operation I'm doing with my server.

So next question is do I want to migrate this data? Well, it's credentials, they belong to a user, I'm-- I pretty much want it to migrate so my service will work on the new device it get to right out the box. And does it belong in the Keychain? Well, yes, it's a credential. It belongs in the Keychain. So the protection I give it is AccessibleAfterFirstUnlocked.

This is the second category of protection. It's not quite as good, as AlwaysIsProtectedWhenUnlocked, but it does give us some protection against the task that require a reboot. So we choose the second best protection because we want the user experience to be good. The second class of data we have is a data that's being uploaded. So I have some data the users put in the background.

Do I want this access to the data when it's locked? Yes. Do I want this data to migrate? No, this is an in-process operation. This data's going to go up to the server. I don't need this data to move. Does it belong on the Keychain? No it doesn't belong on the Keychain. It's bulk data, it's a big file.

So I have to put it on the file system, and I've put in ProtectionNone. We have to admit we did not provide file system API's to get to the second class. We didn't think they were as valuable as they might be, and if you find reasons why they are interesting to you, we'd love to hear them. This is a case where it might be interesting, but in this case, we choose ProtectionNone and we put the file in a place it doesn't migrate, which would be the cache's directory in your application, for example.

Cash data, on the other hand, we don't need when the device is locked, because it's for-- presenting data to the user. And when the device is locked, we don't present anything to the user. We don't need this to migrate, it's caches. We might choose to. But in this case, we don't care to. Does not belong on the Keychain.

It's large data. So we put it in ProtectionComplete which protects it when the device is locked, and we put in it our caches directory so it doesn't migrate. The final example is a relative simple example if I make a diary. It's a place somebody can record their thoughts, whatever they want to put in there, their credit numbers because they are crazy.

So I have this diary which is on the device, and we don't need it when it's locked because it's for the user. We do want it to migrate, and we don't want another Keychain because its large unknown pictures, whatever they use or want to enter. But we do want to protect it. So we put it in ProtectionComplete.

This allows it to be protected with Data Protection, and we put it in our documents folder for our app, probably the simplest example of all. So once you've made your protection choices, and you've put your data into an appropriate class, there is one more thing that you want to do when you adopt, particularly, if you are an app that's running on the background or running while the systems is locked.

Your app does not really care with the systems is locked, and just pretty much left this data on the file system and tries to quit if the system locks, you'd-- there's not a lot you have to do here. But if you are a background app, or want to operate while the system is heading towards lock, there are some stuff you need to do.

There is a notification that comes through. There is actually a symmetric one for this also, that says protection data will become unavailable. This is a symmetric one that says become available, but it's less interesting. It's just telling you, you get your data back, and then you can choose to access your data at that point. This one is relatively important because it does give you a moment in which you can help enforce the security of the users' data.

In response to this notification, we ask that you purge the data in memory that is not necessarily-- that is not necessary when the device is locked. Specifically, we want you to take the data that needs protection, put it back into the containers that it's supposed to be protected in, and close those containers. So you push it back in the file system, you push it back on the Keychain, you get it out of your local address base, so that if somebody is clever enough to grovel your memory, they won't get that data either.

In order to make our system actually have a predictable behavior about locking, we have to give an upper bound to how long an application can hold us off from causing the system to actually lock. So you actually have-- only have 10 seconds to complete this notification. If you don't complete this operation in 10 seconds, we're going to lock the device behind you.

The reason why that is interesting is once the device is locked, you don't get access to the data that's in the highest protection class. You will actually get errors trying to reach in the files to get EPERM errors saying, no, can't read that data. We want you to be resilient to those kinds of failures, not necessarily your app has to keep chugging along and doing great, but don't crash, don't do spectacularly bad things for the user, considering that that might happen.

To move on to some interfaces in the file system. So how do I create and set this attributes. I need to help the system know. There are two API's we've added to help you communicate to the file system, what protection class, you want your data in. The first is in NSData writeToFile, there are new options added.

The file that is created will get the ProtectionComplete or ProtectionNone, depending on the option you include. The second is NSFileManager, has an API to set an attribute of the file, which is the protection key, which will then set the class of the file, the protection class of the file. You can use this on any existing file on the file system.

It's sticky. And then once you set the class for the file, it retains that class in the file, you don't have to tell us again. And most importantly, you can use any other file system access you want to, and then it will operate normally, except for the fact that if the device locks, and it's in a locked class, we'll get errors when trying to access it. So if you are creating a file to hand off to another subsystem on your device, you can set its class before you hand it off. If you know you've requested a file you created by some other system, you can find it, set its class.

The other thing we need to point out is that your existing files that have been run long, your documents and your documents folder are not going to have any protection classes except ProtectionAlways. So if you want to protect that data for the user, which we hope you do, you need to actually find those documents and set the protection class on the files in those documents.

So choosing your protection on the file system, this actually will be simple. Use ProtectionComplete, you know, protect the user's data. Right up until you find a good reason that you can't protect their data. You need to use it when you are in the background, this is probably the most popular.

I really can't think of many other reasons why you wouldn't want to protect the user's data, although you might come up with some. The Keychain has new interfaces, now just new attributes on its existing interfaces. SecItemAdd and SecItemUpdate have always taken a query with the dictionary of parameters in it. There's a new attribute case like accessibility.

You can give it one of these values, and that will set the accessibility of your Keychain item. Just like the file system, the Keychain needs update if you want to change the accessibility class of a given Keychain item. By default, when we move the Keychain back to the device it came from because all backups that are currently out in the world, can only move back to the same device, all the Keychains out there will go back to the same device. But when it returns to that device, we set all the data to AccessibleAlways, which you should note is migratable.

So if you really, don't want it to be migratable, you should hit it with the hammer and tell it not to migrate. If you think it should be less protected because you want to operate in the background now, your app's updating and wants to upgrade in the background. You may want to set its protection class to be type to, AccessibleAfterFirstUnlock. If you don't need the data at all, except when you are running unlocked, set it to AccessibleWhenUnlocked.

So summarize that basic decision tree, the other direction. When you have data and you are trying to consider on the Keychain, how am I going to protect this data? You should start with the most restrictive, but we recommend migratable, which is AccessibleWhenUnlocked. That's probably the right class for the vast majority of the data that is on the Keychain.

But if you find reasons that you need to access a credential when it's locked, the most obvious one I thought of is I need to get back to that server because I was just told the network changed and I still have stuff to talk to that server about. Use AccessibleAfterFirstUnlock, that still maintains some protection for the user's data, but let's you do the background operation.

And if you really create data for this device only, and really, if you create device-- for this device only, be sure it's for this device only. And then you can make the user experience with that data appropriate, and make it for this device only. But if you suddenly discover that that data was for the user, when they go to a new device, they won't get it. So we recommended you think seriously if you want it to stay on this device. But you will know. I mean, if you create a data that's for the device and not for the user, that will be relatively obvious too.

So a quick example of modifying the access a SecItemAdd, those of you who are using the Keychain already will recognize this. You build the query, you called SecItemAdd with that query as data to the Keychain. All you have to do is add one more set of attributes you put in the query dictionary, kSecAttrAccessible, in this case, accessible and unlocked is the-- actually what we're requesting. And then you can use that SecItemAdd. You can also use the SecItemUpdate.

So some way in our adoption, it's relatively straightforward. We're asking you to protect your users' data, we're asking you to choose the strongest protection class you can, and we're asking you to update the existing data protection on the file system and on Keychain. We're also asking that you use the Keychain. It supports migration now.

That was a big hindrance before. If people would put on the Keychain, they're-- you'd migrate to a new device, your passwords would all be lost. It was really irritating for users. That's gone now. So we think we have all the reasons or mood to now use the Keychain.

So what we talked about today, John started talking about why we want to help protect the user's data. These devices are all more mobile, they're much more active, they actively do access in the background. The data on these devices are more personal, and there's a lot more of it.

So it has higher value, particularly to an appointed attack, and it looks and says, hey, I want Mitch's data, I'm going to steal his phone, and get his data off of it. And we're willing to help deal with this, we want to tie the data to a user's secret. That way, the user owns the secret, not us and not our system, not penetrating the owner's system. The data protection model is to protect the data with the passcode.

So all the user data is supposed to protected with a passcode to strengthen against devices that get compromised. So if somebody takes my device, they can break through the front barriers that we think are pretty strong, but are not perfect, if they get through that, they still have to get through the cryptographic protection with the user's passcode.

We also protect the user passcode by tying its derivation to a key to the hardware, so that brute force on that passcode, even if I have all the data inside the device, if I've gotten into the device, requires I do operations on the device to attack it. I can't send it out to my botnet and get a factor of a million on my attacks speed. We want data protection to always be on. It is always on when the user set his passcode. You can't have it off. You got a new passcode, data protection comes on.

And to reiterate again, there is no performance impact. We're already encrypting and decrypting data as it goes to and from the file system, and to and from the Keychain. All we've done in this update is change the architecture of what keys we use when we push the data in and out of the storage systems.

And lastly, we talked about was how you guys adopt and help us make all the user's data protected. We're asking that all applications protect the user's data. Since user information is all over the place, any application where I can have a text deal and enter data, I could put something that I want protected. We're adopting it. We're adopting it as quickly as we can. We chose mail first since it was one of our most complicated ones to prove out that the technology worked. We're definitely going to be adding more apps.

We're asking you to put your data into appropriate classes, to update your existing data into the appropriate classes, and we really are trying to encourage you to use the Keychain. We think there are no excuses left to not use the Keychain for credentials. So if you are interested in any more information about the presentation, you can contact our Evangelist or you can check out the forms. There are few related sessions. The first ones of the Multitasking on iPhone have already occurred, but there is rerun of them tomorrow morning.

And, if you want to pay attention to how you handle being a multitasking app, because those moments will be interesting for you to decide about data protection. The Managing Mobile Devices session was last Tuesday. You can catch the replay when they are posted. It talks about how to configure devices and manage them remotely.