Hello! Welcome to Session 711. Now, who's here to learn how to incorporate Touch ID into their application? [Applause] All right! Today, we're going to talk about some exciting new features we've added based on the Keychain. Now, this session is mainly focused on iOS and not so much on OS X. Let's get started with what we expect to go over in this session.

Now, for those of you who are new and never used the Keychain before, we're going to do a quick recap of the Keychain, and how your application interacts with the Keychain. Then we're going to talk about the additional new features and show you how those features fit in, like a new data protection class.

Then we're going to talk about Access Control Lists, and then, last year, with the release of iPhone 5s and Touch ID, many of you have asked, "Hey, how can I incorporate Touch ID into my own application?" We're going to go over that, but first we're going to do a quick recap of what the Keychain is.

Now, the Keychain is a database, and that database has rows, and those rows we call Keychain items. Now, those Keychain items have values, and those values are encrypted. Now, we allow you to describe Keychain items with a set of attributes, so that we can efficiently find them later.

Now, the Keychain is really good about storing user secrets in the database, but it's not so good about storing large files. And, for that, we provide another interface called Common Crypto. Now, with that interface we allow you to create a bulk encryption key, and then encrypt your large files and your bulk data, and then store that bulk encryption key into the Keychain.

Now, let's take a moment and talk about some of the security guarantees that the Keychain provides. Now, all of your Keychain items are protected by the user's pass code. In addition, they're protected by a device secret. Now, every device in the factory comes baked in with a unique secret, only known to that device.

Now, this is good because if the Keychain is ever removed from the device, this prevents access to the user's secrets. Now, the Keychain was also fundamentally designed to keep your secrets protected on disk. And also, by default, when the user's not using the device. And so what this means is, by default, Keychain items only are available when the user authenticates to the device, and are no longer available after the user locks the device. Now, all Keychain items also go into encrypted backups. So, if the user ever loses their device, or upgrades to a new device, they can restore that encrypted backup and get all of their user secrets back.

One of the fundamental designs of the Keychain is also to enforce access control. Now, what this does is it allows your application access to its portion of the Keychain, while preventing other applications access to the same secrets. Now, I'd like to take a moment and show how your application interacts with the Keychain.

And, in order for your application to call in to the Keychain, it first needs to link against the security framework. Now, the security framework provides a set of APIs called secItem, which work on both iOS and OS X. And now these are a set of CAPIs that work systemwide.

Now, when your application calls in to a secItem interface, it actually sends that request out to our process called securityd. So, all Keychain interactions happen outside of your process space. But what you might not be aware is securityd doesn't have everything required to actually decrypt that Keychain item.

And that's where the Secure enclave comes in. Now, the Secure enclave is a security code processor built on top of the Apple A7 chip, and was first introduced with the iPhone 5s. Now, some of its main operations are to handle all Touch ID operations. In addition, it handles all cryptographic operations for data protection.

Now, it also guarantees the integrity of data protection in the event that the kernel is compromised. And, for this reason, we put all of the device secrets and passcode secrets into the Secure enclave. Now, let me show you what happens when your application makes a request into the Keychain.

First, it sends its query to the secItem interface, which sends the request over to securityd. Securityd then will search the Keychain to see if it finds an item, but the item that's returned is encrypted. So this encrypted item gets sent to the Secure enclave, which may or may not be able to decrypt the item, depending on the state of the device.

Once the item is decrypted, it then gets sent back to securityd, and then the user secret gets sent back to your application. Now, I'd like to take a moment and look at the secItem interface, and show you how easy it is to add and retrieve items from the Keychain.

In order to add an item, and in these examples, what I'll do is I'll show you how to call into the C Interfaces, with Objective-C. And in order to add an item, it's as simple as creating an NSDictionary with a set of attributes that describe your Keychain item. In addition to the attributes, you also need to pass your secret that you want to protect. The encrypted payload. And pass this dictionary to secItemAdd.

Now, it's really important that when you use the secItemAdd interface, that you also check the return codes to make sure you don't get any errors back. Because, just like any database, attempting to add the same Keychain item to the database will result in a duplicate error, so these attributes make that Keychain item unique. Now, let me show you how to retrieve items from the database.

In order to retrieve items, you have to call into the secItemCopy interface, and similar to add, you need to specify the set of attributes that are used to describe your Keychain item. In addition, you need to specify kSecReturnData, and what this does is it instructs a secItem copy matching to actually return the user secret. If you don't specify this, secItemCopyMatching will only let you know that the user secret existed.

Now, just like any database, we allow you to update your existing Keychain items. In order to update, first, it takes two dictionaries. Two NSDictionaries. One to specify the attributes of the item that you're trying to find, and then a second dictionary to specify the changes that you'd like to make to that Keychain item.

And, of course, when the secrets are no longer necessary inside of the database, we allow you to delete those secrets from the database. And we highly recommend, as best practice, to update, use secItemUpdate to modify your items instead of deleting and re-adding your items to the database. And this allows you to keep any established access control that you've previously added to an item.

Now that I've shown you how to simply add items to the Keychain, I'd like to show you what a simple workflow would look like in your own application. What your application might do is first it's going to query in to the Keychain to see if a password exists. If a password exists, great. And it works, great. You're done.

Right? However, if you query into the Keychain and no password exists in the Keychain, you may need to prompt the user at this point for a password. And once you've prompted for the password and verified it, you'll then need to add that to the database, so that the next time the user goes to use your application, you don't need to nag the user for the password again.

Now, you might run into a situation where the password in the database no longer works for the service that you're protecting. And in those situations, you may need to prompt the user again for a better password. And once you've verified that better password, go ahead and update that in the database so that later, when your application needs it again, it can use that password.

Now, as I mentioned before, the Keychain is really good about protecting your secrets on disk. And it is also your responsibility, as application developers, to protect the secrets that you retrieve from the database. And it's best practice that you handle those secrets with care, meaning, you know, only hold on to the secret as long as necessary.

Don't save it often to a global variable because it's easy to do, or don't retrieve it from the database and save it off into a Plist or a file. Now that I've done the quick recap of the Keychain, I'd like to talk a little bit about our access control story.

Now, when the Keychain was first introduced on OS X, it was-we first allowed, or we first introduced it with kSecAttrAccess, which was a form of access control based on the application itself. Now, with the iOS, we introduced kSecAttrAccessGroup. And what this was, was a form of access control based off of code signing and entitlements. And then we added kSecAttrAccessible.

Now, this isn't so much about who, but more of when are your items available? When can the Secure enclave be able to decrypt those items and return that secret back to your application? And today we'd like to introduce to you a new form of access control called kSecAttrAccess Control.

And this is more about getting user consent to be able to use those Keychain items as they're stored, and Libor will be up on the stage to talk about that in a moment. Now, last year, with the release of iCloud Keychain, we really needed a common interface. So, what some of you may not know is we actually ported the iOS Keychain to OS X last year. And so, when you call in to the OS X interface, secItem interface, and specify the synchronizable attribute, you're actually taking advantage of all of the features that we're introducing to the Keychain.

Now, I'd like to take a moment and dig into the accessible attribute. Now, like I said, by default, when you add Keychain items to the database, they default to WhenUnlocked. And again, when the user authenticates to the device, these Keychain items become available, and when the user locks the device, the Keychain items are no longer available. So, what we do is we actually securely erase those secrets that are used to protect those items in the Secure enclave.

And now, this works great for the majority of applications, however, if you have an application that runs in the background, this can be a little inconvenient, so we did introduce another data protection class AfterFirstUnlock, and what this means is that your Keychain items will become available after the user has first authenticated to the device. But this also has one drawback, is-the secrets that are used in the Secure enclave to protect these Keychain items do not go away after you lock the device.

Now, we also provide a stricter variant of these two data protection classes that are this device only, and so when these Keychain items go into an encrypted backup, you will only be able to restore that encrypted backup, these Keychain items will only come back when you restore that encrypted backup to the same device and will not successfully restore to a new device.

Now, a feature we get asked for all the time is, "Hey, it would be really nice if we knew if a passcode was set on a device." How many of you have been looking for a feature like that? [Applause] Well, we're still not going to provide an API like that [laughter], but we have something better.

See, we never really felt comfortable about providing an API that said, "Hey, a passcode is set on the device," because what happens if your application said "Oh, a passcode is set, now I'm going to store all my secrets on the device." And then, later, the user goes and removes a passcode from the device, and now you're sort of left in a situation you never wanted. And for that reason, we probably still won't provide such an API, but we have something better. Today, I'd like to introduce to you a new data protection class that is WhenPasscodeSet. Now, this has all of the same properties as WhenUnlocked [applause].

Meaning, these Keychain items will not be available unless the user authenticates the device, and will-I'm sorry, will be available after the user authenticates the device, and will no longer be available when the user locks the device. Now, it has a few other security properties we'll talk about. So, if the passcode is not set on a device, and you try to use this new data protection class, you'll actually get an error back, and so it only allows you to store Keychain items if a passcode is set on the device.

Now what happens to items that get stored when a passcode is set? Now, all items that get stored, or if you remove the passcode from the device, then what we do is we actually securely erase the key that is protecting those Keychain items in the Secure enclave, cryptographically preventing us from ever decrypting those Keychain items again.

Now, this new data protection also has a few drawbacks. So, this data protection class will not go into or will not sync to other devices when you have iCloud syncing turned on, or iCloud Keychain enabled. And also will not go into encrypted backups. So, we highly recommend that you stick with our default WhenUnlocked, and only switch to WhenPasscodeSet if the application truly requires this type of security guarantee. And now, I'd like to turn the time over to Libor, so he can continue talking about some additional features based on the Keychain. Libor?

Thank you, Wade. So, now you know how to use Keychain in your application. So, let me talk about a new, exciting feature, which allows you to use Touch ID with Keychain, and not only with Keychain. I really hope that you will like this feature, and I hope that you will use it in many applications. So, let's see how to use that feature.

Before I will start with Touch ID, and I know that you are waiting for that, I will have to start with Keychain Item Access Control Lists. Keychain item Access Control List, or ACL, is a new Keychain item attribute which you can use to set accessibility and authentication for each Keychain item.

And that means that you can control not only when the Keychain item is available, based on device state, but also what has to happen when this Keychain item is accessed. So, I will have to talk about authentication, how it's done, and how you can use it with Touch ID and passcode.

But before we start with the details, let's have a look at the result. What the user will see when they use this new feature. So, this is the new Touch ID authentication screen, which will be presented to the user any time he will try to access Keychain items protected by ACL on a phone with Touch ID.

I will talk about the user interface in much more detail later, and you will also see it in the demo. So, let's see, what are the changes you have to do to adopt this new feature? You already know that we have a new Keychain item attribute called Access Control, and this Access Control attribute holds the ACL.

ACL itself is represented by secAccessControl object, and to be able to create this object, you have to define which authentication and which accessibility you require for that item. So, let's see what options you have. The accessibility is pretty easy. You already know accessibility, because to set accessibility you will use the same accessibility classes and constants which you are now using with accessible attribute. And the behavior will be the same. So, the item will be available based on the device, if it's unlocked or locked, and the behavior keeps the same, what's added is authentication.

Authentication is the new component, and to specify authentication you have to provide policy. And policy defines what authentication methods have to be satisfied or done before the Keychain item is decrypted and returned back to your application. So, for now, we have user presence, policy. So, let's see how this policy is implemented and how it's used by Keychain.

The policy is enforced and controlled by operating system security domain, and that means that, for example, on an iPhone, iPhone 5s, it is Secure enclave which controls what authentication has to be done, and what is the best security for that authentication operation. And that allows us to have the highest possible security for given device configuration.

So, let's see how the device configuration influences policy evaluation. So, the easiest case is device without any passcode. And the result of policy evaluation in this case is easy to predict. We are talking about security here, so the policy evaluation will always fail, and you will have no access to your data.

A little bit more interesting example is device with passcode. And because we have the passcode, again, the result is pretty easy to predict because the passcode will be necessary to decrypt your Keychain item data. And the user will have to enter device passcode each time you are accessing the Keychain item. This is secure, but the usability can be improved. And we-here we are finally getting to Touch ID. Because on devices with Touch ID, and with registered fingerprints, the user presence policy will prefer Touch ID and will allow you to use Touch ID to decrypt your Keychain items.

This is great, but there might be some cases where you cannot use Touch ID. For example, you lend the device to someone, to try the Touch ID, and the Touch ID is now in a disabled state because he tried it so many times. So, for that, the user presence policy allows to use a backup mechanism. And this backup mechanism is device passcode. Actually, the user can decide if he wants to use passcode or Touch ID.

But a Touch ID will be always preferred in this case, and because it's preferred, and it's the interesting option. So, let's see how Touch ID works, and what's the security of this solution? You all know Touch ID from your iPhone 5s device unlock, and you know that it's an easy-to-use authentication mechanism, and it does not require much interaction from the user. So why not use it for Keychain protection? The obvious question you will ask is what about the security? Well, the answer is simple. Secure enclave.

The Secure enclave contains all the Touch ID data, and the Secure enclave also does all the Touch ID operations. And because the Secure enclave was created to protect all the data, even in case that the kernel has been compromised, all the components, which are running inside Secure enclave, can trust each other, and can trust the data, which are protected by Secure enclave.

And, fortunately, the Keychain key operations are running also in Secure enclave. You have seen the example Wade was showing, and in the case of Touch ID, the Keychain key operations can use the policy evaluation result, or the Touch ID match result, and use that for authorizing the Keychain item decryption operation. So, this way the Keychain can protect your items and still use the Touch ID.

But the matching is not the only service the Secure enclave provides to Touch ID. Secure enclave also enforces Touch ID policies, and one of these policies is really important for us and is the counter for failed matches. After several failed matches, it is Secure enclave that decides that the Touch ID should be disabled, and that it cannot be used for any other authentication operation.

And you are used to that from the device unlock, where you have to enter your device passcode after several unsuccessful tries, and the Keychain is exactly the same case. So, once the Touch ID is disabled, the only way how to get to your Keychain item is using the device passcode. And the device passcode will also enable the Touch ID, so the next Keychain operation will be able to use Touch ID again.

This all is supported by a new framework called LocalAuthentication. And we will be talking about LocalAuthentication a little bit later, but, for now, let's see how LocalAuthentication and Keychain work together with Secure enclave. So, here we have an application which tries to use Keychain API. The request is sent to the operating system service, which takes care of the Keychain, and this service communicates with Secure enclave to decrypt the Keychain items. This is what Wade was showing.

And this is the standard flow. So, what happens when you use the item with ACL? In such case, the Keychain service will start LocalAuthentication service, and the LocalAuthentication service is responsible for displaying correct user interface, based on information from Secure enclave. Because Secure enclave is the component which is actually controlling the policy and telling LocalAuthentication what authentication should be actually started.

And once the user provides his fingerprint, or passcode, the Secure enclave can authorize the operation in Keychain and the Keychain will decrypt your data and send them back to you. I was mentioning user interface here, and that it's the task of LocalAuthentication, so let's have a look at the user interface.

We have a new user, we have a new standard user interface for Touch ID authentication, and we have also a new standard user interface for device passcode entering. And the dialogue is relatively simple. It contains just the name of your application, which is provided by the operating system, and two buttons, which are allowing to cancel this operation or to use the fallback mechanism using passcode.

Your application actually has a possibility to extend this user interface. You can add an additional string which describes why you are doing this operation. And we are actually recommending you to use this string, because the user should know why you are calling this operation, why he is prompted for Touch ID or passcode.

And, of course, on devices without Touch ID, or on devices without any Touch ID enrolled fingers, we have the standard passcode entry screen which is also shown in case that the Touch ID is disabled, or when user decided that he will use passcode instead of Touch ID on the previous screen.

Because this authentication has to happen during the Keychain item processing, it means that the calls to Keychain, which will return the ACL protected items, will be blocking. So, you have to deal with that, and we will talk about that a little bit later. So, this is all about the authentication and Touch ID and the user interface. So, let's return back to the accessibility, and accessibility you already know, so I will not go through the details, and I will not repeat what Wade already said.

But I have a couple of recommendations, because ACL and the accessibility are connected, and there are some implications of using them. And one of the implications is that we need the user interface. The user has to authenticate. So, the obvious choice of the accessibility class is WhenUnlocked, or the new one, WhenUnlocked and PasscodeSet. Both are good. The second one is a little bit more straight, because it deletes your data in case that the passcode was removed.

But you can use both, and actually, even if you remove your passcode, the WhenUnlocked class will not allow the user to access the data, because the data are protected also by the user presence policy. So, the accessibility and the policy work together, and both need to be satisfied to get the data. So, you can choose, and now you know how to set the accessibility and what you can use for the authentication. So, let's see how the changes in your source code will look like.

This is a simple example of secret-of storing a secret. Wade was already talking about that, and it's actually the same example Wade was showing, so you know all the components of the dictionary. And to use the ACL, the only thing you have to do is to create the new access control object, and set the accessibility and authentication, and once you have this object, you can use it inside the dictionary. And by calling the secItemAdd, you will create the new ACL protected item.

That's all you have to do. This is really the only change. And once you have the item stored, you can read the item. And to read the secret, here we have the example from Wade's slide as well. And already this example will work. It will do everything. It will add the user for the authentication-you don't need to do any changes.

But I would suggest to do at least one change, and that is the addition of the operation prompt. Because contrary to the previous cases, where you were just reading the secret in your application, here you are asking the user for some action, so the user should be informed.

And all the magic happens in the secItemCopyMatching call. This call will start the LocalAuthentication service, and the LocalAuthentication service will start the user interface. And here, the user will have to touch or enter the passcode to actually decrypt your Keychain item. And once the item is returned back to your application, you can use it. But, as you saw, the call is blocking. So I would suggest to use it inside a dispatch async block, so you are not blocking your main queue for example.

And that's actually all you have to do. No other changes are necessary. So, now you know what is the authentication, how to do the changes in your code, so let's talk about some things to keep in mind when you are using ACLs, because this is quite a new concept.

You already see that we need the application to be foreground. Actually, if it happens, and you will call a Keychain item operation, Keychain operation when you are a background application, the call will fail in case that there is some ACL protected item. And an important thing to remember is that any query may contain actually ACL protected items. So, that means that also secItemAdd or, of course, secItemUpdate may ask the user for authentication because there might be some ACL protected item already.

What's not so obvious is that the Keychain is, in fact, a database. And as a database, it can return multiple results. So, in case that you are used to using quite broad queries, you may get the situation that the query will contain the ACL protected item, and in such case, the user will be asked for authentication as well.

So, first of all, you should not use broad queries if possible, but if you need help with that, we have a special no authentication mode which allows you to ask the Keychain to suppress the user interface, and Keychain will just let you know that this particular query would require authentication.

Last, but not least, these ACL protected items are not synchronizable and are not backup. These are really device-only items. So this is all about the Keychain. You can see that it's pretty easy to use, the Touch ID, with Keychain. And also the security of the solution is quite high. And we are talking about LocalAuthentication, so let's see how you can use LocalAuthentication in your code.

You have seen how it participates on Keychain decryption for Keychain, and how it works together with Secure enclave. So, let's talk about the features you can use inside your own application. LocalAuthentication was created as a mechanism to collection credentials like device passcode or start authentication operations like Touch ID, and to work together with Secure enclave and other system components to finish the authentication of user.

But it's a generic policy evaluation mechanism as well. So any application can call policy evaluation inside secure-inside LocalAuthentication, and LocalAuthentication will start the operation inside Secure enclave, and this way, you can initiate the Touch ID operation and gather the result, even without contact with Secure enclave. So, to get a better idea, let's talk about some use cases, where you would use LocalAuthentication instead of the Keychain case.

For example, you may want to verify that a user is enrolled. This is something LocalAuthentication allows you. And you may want to verify it because you want to enable some feature of your application, or you want to do some kind of parental control, because you want to be sure that the owner of the device is present. For these cases, you can use LocalAuthentication.

Or you may want to extend your application authentication mechanisms. Well, you can use Touch ID as a first factor instead of your password or pin. And this is more a task for the Keychain, but in case that you do not want to use device passcode, you can use LocalAuthentication and you will see how. Or you may want to use Touch ID as a second factor in addition to your authentication. And then the LocalAuthentication is also the best choice for you.

I was talking about the difference between Keychain and LocalAuthentication a little bit, so let's see what the security is to set the expectations right. The security of LocalAuthentication and the Keychain solution with Touch ID is different. Because, in Keychain's case, it's the Secure enclave which is the trusted component, and the trust is really between the operating system and Secure enclave. With LocalAuthentication, the trust is between your application and operating system.

There are no secrets which will be stored in case of the LocalAuthentication. And that also means that you have no direct access to Secure enclave, you have just the access to the results. And, of course, and I want to emphasize this, you have no access to the registered fingerprints.

The registered fingerprints and the fingerprint images are all owned by Secure enclave. The Secure enclave is the only owner and no other system component can access this information, not even kernel has any access to fingerprint image or registered fingerprints. So, it means that you will also never get access to the registered fingers, or to the management of these fingers.

Let's see how this looks from the API perspective. So, you already know that you can use LocalAuthentication to invoke Touch ID operation. So, how to do that? We have two new functions. One is canEvaluatePolicy and one is evaluatePolicy. And the first one just checks if the policy can be ever evaluated on this device. So, in the case of the Touch ID, it will just tell you if the device is Touch ID enabled, and if there are any fingerprints enrolled. The Evaluate call then starts the authentication operation and shows the necessary user interface.

And the result, which you will get, is just plain "yes" or "no" from this Evaluate Policy function. Let's see what policy we have. So, this is the policy you can use to show the Touch ID. And contrary to the Keychain case, and I was already mentioning, that there's no passcode for back mechanism. But, your application has to provide its own password entry UI, and your own fallback mechanism, to allow the user to skip this operation. You should already have some mechanism like that, because you are just extending your application. So, this is the way how to reuse this mechanism.

And as with Keychain, there are some things you should remember when using LocalAuthentication. Again, because of the need to authenticate, you have to be a foreground application to use this API. And you have to also account with the possibility that the policy evaluation will always fail, even if it would be theoretically possible on that device to evaluate the policy, because, for example, if Touch ID is present, but it's in the local state or there might be some other configuration setting which will prevent the user to use the authentication. So, you should use your own fallback mechanism, and your application is really required to do that, and we will see how.

Let's see the real examples, how this is done in your code. So, the canEvaluatePolicy call to check if the Touch ID is enabled or any fingerprints are registered is really simple. It's just single call which is not blocking, it does not need any user interface, so you can call it any time.

And the actual call which shows the user interface and starts the operation inside Secure enclave is the evaluatePolicy. And to call evaluatePolicy you need two things. First of all, you need to specify the policy that's clear. But you have to also specify your localized reason, and in this case, this is really mandatory. We do not accept any nil or empty string here, because we want the user to know not only what application is calling this operation, but also why. And the result is then returned in a simple reply block. So, let's see what happens when you call this function.

The user will see a user interface which is similar to the Keychain case. We can see that there is again the name of your application, and also the reason string, and two buttons. And the main difference is in the enter password button, and also in the behavior of this dialogue.

In case of Keychain, you could use a passcode or the Touch ID to satisfy the authentication. In the case of LocalAuthentication, the only way how to successfully authenticate is to use your fingerprint. And both enter password and cancel buttons will actually dismiss this dialogue and return control to your application. So, your application has to process these return values.

And when this happens, so in case that the user used the finger and he was successfully authenticated, you will get success, and that means that the Touch ID was really used, and you can use this information to change the behavior of your application. In case that this fails, you have to check for the error codes. And you have to check if user used the enter password button, and react by showing your own UI with your own password for back mechanism. And, of course, the cancel has to be processed the same way.

So, this is how it looks from the source code. So, let's see a short demo, which will show the Keychain and Touch ID on a real phone. So, here we have a Keychain demo application. This demo application will be-the sources for the demo application will be available after this session, so you can try it and you can experiment with that. And let me show the features.

It's really very simple. For the Keychain, I have just four functions here which I can try. So, let me start with adding the item, and by adding the item using secItemAdd, I created an item which is protected by ACL. And I used exactly the same code as I was showing in the slide.

And to read that item, I can ask for the secCopyItemMatching for the items, and I am presented by the Touch ID user interface. So, let me try, for example, a wrong finger, to see how the operation looks like when it fails. So, this is not an enrolled finger, so it asks me to try again. And I will use an enrolled finger to get the secret back.

And I got the secret which I stored using secItemAdd, so I want to update the secret. And because the item is there, I will be calling the update, I am again asked for Touch ID or passcode. And the message is changed here, so I am informing the user what's actually going on.

So, I will use again a correct finger to update the item, and to check that, I will do this operation again, but this time I decided that I want to use passcode. So, I will enter the passcode. And as you can see, the passcode is also able to decrypt your item and return it back to you. So, it's very simple from the developer's perspective, and it's very simple and natural from user perspective, because users are used to similar screens already from the payments for app store.

For LocalAuthentication, we are just two functions. One is canEvaluatePolicy, and the result will be, of course, success because you saw that I am enrolled and everything is working. And policy evaluation actually shows the user interface, which contains enter password and cancel. So first of all, I want to see how it works successfully.

And I can try also to press the enter password. And here, I don't see any user interface, because the user interface has to be provided by our application. What I see is an error which tells the application to show its own fallback mechanism and to take care of the backup mechanism.

So, this is all about the APIs. I have just a couple, few things, as a summary. Any time you need to store a user secret, you should use Keychain. The Keychain is here for user secrets and keys, and it's really operating system protected database, which you should use for any secrets, and it has Secure enclave protection. So, it's the highest security you can achieve. We have also a couple of new features, which we added in this release. And you can use the new accessibility class to protect your items, and to delete your items in case that the passcode is removed on the device.

We have also the new Keychain item ACL mechanism, which allows you to define what authentication has to happen when you are accessing your Keychain items. And you can use it currently with Touch ID and passcode to protect your Keychain items. And we also have a new LocalAuthentication framework, which allows you to start the Touch ID operation directly from your application.

And to get more information about this, you can send your e-mails to Paul Danbold, or you should check the documentation. There will be documentation describing LocalAuthentication and the new changes. And I suggest you to read the Security White Paper, because this is really a great source of information about Secure enclave and security in general. And it will tell you also how Touch ID is done.

And, of course, Apple Development Forums are the great source of information, so ask your questions there. We have also one related session tomorrow, it's the User Privacy in iOS and OS X, so you might find this interesting. So, tomorrow, here in Nob Hill. Thank you very much. I'll be looking forward to meeting you in the security labs. And yeah, see you there.