WWDC2014 Session 711

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> 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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]