WWDC2015 Session 706

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[Applause]
>> IVAN KRSTIC: My name is
Ivan, and I head the Security
and Privacy Strategy group at
Apple, and today we are going
to talk about security.
And, in fact, most of
today's talk will focus
on security on devices.
Now, as you know, we
have a very strong lineup
of device security
features, some of them unique
to OS X others to iOS, and some
present on both our platforms.
We are continually working to
make these features better,
and you're going
to see us continue
to relentlessly innovate
in this space.
But I'm actually here today to
have a brief interlude with you
about network security.
When we think about network
security most of you think
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
When we think about network
security most of you think
of HTTPS, which most
of us experience
as the lock icon in the browser.
It used to be that
websites used HTTPS and TLS
if they were transmitting
sensitive information.
But we no longer think of things
like credit card
information as sensitive.
In fact, today we think of
all kinds of user information
as being sensitive, and
even some things that you
as a developer may not think
of as sensitive, a user may.
One other really
important thing about TLS
that we don't often
think about is
that it doesn't just protect
the secrecy of information
as it moves across the network.
It also protects the
integrity of those connections.
And the threats on the
network have changed.
It's no longer just someone
wearing a black ski mask hiding
on some corner of
the Internet trying
to get your credit card numbers.
In fact, users may want
to protect themselves
against other kinds of threats.
For example, Internet
service providers
that are injecting tracking
headers into every request,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that are injecting tracking
headers into every request,
or even outright
recording browsing histories
to support ad targeting.
So in 2015 we believe that TLS
is really a minimum base line
for responsibly protecting
customer information
on the network.
But TLS is not quite enough.
Many servers still
use version 1 of TLS,
which is very old,
it's 16 years old.
And the newest version of TLS,
1.2, which is 7 years old,
contains a number of really
important cryptographic
improvements to the protocol,
which make it more resilient
to the kinds of threats
that we are seeing today
and will be facing
in the future.
And in fact, even TLS
1.2 is not quite enough.
With the way TLS works,
if an attacker is able
to compromise a server and
steal your TLS key, they can use
that key to retroactively
decrypt all previously encrypted
data by that server.
That's obviously
very undesirable.
There's a property
called forward secrecy
that makes it not true.
With forward secrecy,
if an attacker is able
to compromise a server and steal
the TLS key, they can only use
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to compromise a server and steal
the TLS key, they can only use
that key to decrypt
future traffic
that the server encrypts,
but no prior traffic.
And this is great because
it mitigates bulk recording
of network encrypted data.
TLS supports forward secrecy
and it does it through the use
of what are called cipher
suites which are combinations
of cryptographic primitives
that you actually have
to enable on your server.
So your server need only not
run just TLS, but in fact needs
to run TLS 1.2, and in order
to get forward secrecy,
you must configure
it to do that.
So why am I telling
you all of this?
Well, here is a quote from Tim,
and I will let you read it.
>> "We must get this right."
And to help you get it right,
we're introducing a feature
called App Transport Security.
Here's how it works.
If you link your app against
OS X El Capitan or iOS 9,
by default it won't be able
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
by default it won't be able
to make any unprotected
HTTP connections;
they will simply fail,
and any TLS connections
that your app makes will have no
adhere to these best practices
that I just described.
And that's TLS 1.2
with forward secrecy.
Cryptographic primitives
that are known
to be insecure are not allowed,
and there are minimum key size
requirements put in place.
Now, you may not be
able to comply with all
of these restrictions
immediately, and that's okay,
you can specify exceptions
in your Info.plist either
on a case-by-case basis for each
domain or as a global override.
But, as an industry we have
to very soon get to a point
where no user information
hits the network unencrypted,
and we need your help.
Thank you for that
and I will turn it
over to my colleague Pierre
who's going to tell you
about System Integrity
Protection.
[Applause]
>> PIERRE-OLIVIER
MARTEL: Thank you Ivan.
Hi everyone, my name is
Pierre-Olivier Martel.
I'm the engineering manager
for Sandboxing Technologies
here at Apple.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for Sandboxing Technologies
here at Apple.
And today I'm here
to talk to you
about System Integrity
Protection
which is a new hardening
mechanism
that we are introducing
in El Capitan.
Before I dive into the details,
I would like to take a step back
and provide some context
around what we're
trying to achieve here.
My team's mission at Apple is
to make sure that our users get
to enjoy the great user
experience that comes
with our product,
with the confidence
that their personal data is
protected and that malware
or even simply a poorly
written piece of software,
only has a limited impact
on their user experience.
So to that end we've designed
and integrated various pieces
of security technologies,
as Ivan mentioned before,
over the year in iOS and OS X.
One of the quotas and principles
that we applied there is the
concept of defense in depth.
Now, the key principle here is
something you've probably heard
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, the key principle here is
something you've probably heard
before, which is that
security is all about layers.
And for the same reason that you
shouldn't put all of your eggs
in the same basket, you
shouldn't rely on a single layer
of protection to
defend the device,
because no matter how
bulletproof, or water resistant,
or shock absorbent this layer
is, when it starts failing you,
then it's complete game over.
Instead, you should rely on
multiple layers of protection,
ideally with different
security properties
that will delay the
advance of an attacker
and reduce your attack surface.
Now, the concept of defense
in depth is an old military
concept that's been used
to defend fortresses all around
the world for centuries for now.
Because I you know
you guys like trivia,
I can tell that you it
was actually formalized
by this gentleman, Sebastien
de Vauban, in the 1670s,
when he was asked by
the King of France
to rebuild all the
fortresses around the country
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to rebuild all the
fortresses around the country
that were used to
defend the kingdom.
And you may not be
familiar with the character,
but maybe you've seen
some of his work before.
That's the design of
one of his castles.
You can clearly see several
layers of protection here
that are designed to stop
different kinds of attacks
and that will basically delay
the attacker and funnel him
through different bottlenecks
that are easier to defend.
So let's see how this applies
to the OS X security model.
And I don't know about you,
but I've always dreamed
to build my own fort,
so there it is,
and we'll put our own
security layers on it.
Starting from the bottom,
we'll start with Gatekeeper.
So Gatekeeper makes sure that an
application that gets downloaded
from the Internet onto the
user's machine has to be signed
by a -- we have a
Developer ID certificate
that Apple has issued
to a developer,
otherwise the application
does not get to launch.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
otherwise the application
does not get to launch.
And combined with some
other mechanism that we have
on the system, like some
malware detection mechanism,
then it's actually a
pretty effective measure
to stop a massive malware
attack on our ecosystem.
The second layer is Sandbox.
So back in Lion, we
introduced App Sandbox
and we mad it mandatory
for applications coming
from the App Store.
We also highly recommended it
for applications coming outside
of the App Store, like for
instance using the Developer
ID program.
Sandbox is a containment
mechanism.
Which means that it
makes sure that even
if your application
gets exploited,
then the application only
has access to the data
that the user actually gave it,
which means the application
cannot steal all the user's
data, and cannot compromise
the rest of the system.
The third layer, if you
manage to go through
or around the first two, is the
classic POSIX permission scheme,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or around the first two, is the
classic POSIX permission scheme,
which means that your
application only runs
with the set of privileges that
the system granted to your user.
So the application won't be
able to access data owned
by a different user
and it won't be able
to modify a systemwide
configuration settings
that are usually owned
by the root user.
And finally, we can think of the
Keychain as yet another layer
on top of that, which
is designed
to protect the user's secrets.
It relies on cryptography
and application separation
to make sure that only the
application that's stored a
secret in the first place
can get back to it later.
So when you look at
the big picture here,
you realize a couple of things.
First, Gatekeeper will stop
untrusted code downloaded
on the machine from
being launched.
But it's not actually a
containment mechanism.
It doesn't stop the application
when it's run from
doing anything.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
when it's run from
doing anything.
Also, it does not protect code
that's already on the machine.
So code that ships with
the OS, for instance,
is not protected by it.
Then, sandboxing, although it's
probably the most effective
containment mechanism
we have on the platform,
is only an opt-in in OS X.
So there's no requirement
for every single process
to actually run in a sandbox.
Finally, when you look at the
POSIX layer, you realize that,
well, most of the Macs out there
are actually single user systems
where the user is the de
facto administrator running
with administrative
privileges all the time.
The root account is
usually protected
or hidden behind an often weak
password or no password at all.
And in fact, if there is a
password and you ask for it,
the users likely give it to you.
And finally, when you root, then
you actually have full control
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And finally, when you root, then
you actually have full control
on the machine, because root can
disable all security measures
on the device.
It can replace the
kernel extensions,
it can replace launchd, any
other security services,
it can even interfere
with the Keychain layers
that sit on top of it.
So the reality is that once you
have code running on the Mac,
it's actually not that
hard to become root,
and once you are root, you have
full control of the machine.
Which means that any piece
of malware is actually
one password,
or one vulnerability away
from taking full
control of the device.
This shows us that we
need another layer.
We need a layer that will
eliminate the power of root
on the machine and protect
the system by default,
as it was installed by
Apple on the machine.
Both on disk and at runtime.
And because we are talking
about taking some power away
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And because we are talking
about taking some power away
from root, then we need
to provide a configuration
mechanism
that root itself
cannot compromise,
but that can give away
this power back to root.
This is what System
Integrated Protection is.
It is a new security
policy that applies
to every single process
running on the system.
Regardless of whether
this process is running
with extra privileges, or
if it's running unsandboxed.
It's designed to
provide extra protections
to system components, both
on disk and at runtime,
and it makes it so that system
binaries are only modifiable
by the installer, if it installs
an Apple signed package,
or the Software Update
mechanism.
And finally, that the system
binaries are protected
from runtime attachments,
and from code injection.
So before we dive
into the details here,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So before we dive
into the details here,
let's see how this is going
to impact you the developers.
Well the good news is that
if you ship your application
on the App Store, then your
application is not impacted
by any of this, because
the App Store guidelines
and the app sandbox policy,
already prohibits all
of these behaviors.
However, if you ship
outside of the store,
then your application is
potentially impacted by this,
if it relies on being able
to modify system binaries
or frameworks on disk.
If it needs to be able
to install content
in system locations, and I
will explain a little bit
about what system
locations mean in here.
And finally, if your
application needs
to inspect the memory
states of any process
on a system including system
processes, or if it needs
to be able to inject libraries
or debug over processes,
including system processes.
So let's look at the key
aspects of this new mechanism.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So let's look at the key
aspects of this new mechanism.
First, we look at new
filesystem restrictions
that we are introducing
in Capitan,
and then we'll see
how these extend
to new runtime protections.
Finally, we'll see
how this all ties
in with the kernel
extension development workflow
and how it potentially impacts
you if you are a kext developer.
And then because the feature
can entirely be disabled,
I will just show you how.
Let's talk about the
filesystem first.
What we're trying to
achieve here is we want
to protect system content
from being modified.
To do so, the installer will
actually flag system content
as it installs the
files on disk.
We have a new filesystem flag
that we introduced in Capitan.
And then later on, at runtime,
the kernel will stop any attempt
at modifying these
protected files
or protected folders
unless the attempt comes
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or protected folders
unless the attempt comes
from a specially
entitled process,
of which there's only
a handful on Capitan.
It will also stop you from
writing to the block devices
that back this protected
content.
And it will stop
you from mounting
over this protected content.
And one thing you have to
keep in mind is that for now,
this only applies to the
root, and the boot volume
of the currently running OS.
So you should see this
as a way for the system
to protect itself at runtime.
Now, because we are trying to
protect system content on disk,
we need to have a
clear separation
between system content
and third-party content.
So in Capitan, all the
locations that are on the left
of this chart will now be
considered system locations.
Which means that the system
will actually stop you
from writing there,
including if it comes
in an installer package.
So it should not
impact many of you here
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So it should not
impact many of you here
because we've been
advising for many years now,
that you shouldn't write
to these locations.
But it's not going to be
a hard failure in Capitan
if your package installs
content in there.
So if you install
anything in /System,
you need to move this content
into the appropriate subfolder
of /Library, if it's supposed
to be system wide content,
or (tilde)/Library if it's
supposed to be user content.
If you install anything in /bin,
or /sbin, or anywhere under /usr
like /usr/bin, /usr/lib,
/usr/libexec, then you need
to move this content into
the appropriate subfolder
of the /usr/local folder,
because that's the only location
that is now available
to third-parties.
And then a reminder
that the best location
for your content is
still /Applications
because that's the location
that is visible to the user
and it's easy for them to
actually drag your application
to the trash and just
remove all content.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to the trash and just
remove all content.
One important note here,
that when the user upgrades
from a Yosemite install,
to a Capitan install,
the installer will actually
migrate any third-party content
that it finds in
system locations outside
of these locations.
So you need to make sure that
today you start migrating
that content away as soon
as possible so as not
to impact these users.
Now, let's look at the
runtime protections.
Being able to modify the
behavior of a process
at runtime is more
equivalent to being able
to modify the binary on disk.
So if you try to protect
the binary on disk
and the system content on
disk, we have to make sure
that it's not possible to inject
code or modify the behavior
of these system processes.
To do so, we are introducing
a new restricted flag
in the process structure
that the kernel holds
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in the process structure
that the kernel holds
for every single process.
And a kernel will set
that flag at exact time
if the main executable
is protected on disk,
or if the main executable
is signed
with an Apple-private
entitlement.
And then later on, the system
will actually treat these
restricted processes
slightly differently
than regular processes.
For one, the task-for-pid
and the processor-set-tasks SPI
will now fail if they are called
on a restricted process.
And will set an 0 to EPERM.
Which means that if part of your
product relies on being able
to attach to a system process
at runtime, for instance,
the Finder, and that you expect
to be able to inject code
into the Finder, that is
not going to work anymore.
Then if you fork an exec,
a binary that will result
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Then if you fork an exec,
a binary that will result
in the child process
being restricted,
then the system will
automatically reset the mach
special ports on
this child process,
which means you won't
be able to keep control
over the child process.
So if you expect to be able
to fork a privileged tool
and then keep control on it,
that's not going
to work anymore.
The linker is going to ignore
all the dyld environment
variables on these
protected binaries.
So if you expect to be
able to inject the library
into a system binary
when you exec it,
the linker will just
ignore the new library.
And finally, if you use
dtrace, all dtrace probes
that target a restricted process
will not be matched anymore,
which means you won't be
able to see an interaction
between the process
and the kernel.
You won't be able to inspect the
restricted process memory space
and you won't be able to
inspect the kernel memory.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and you won't be able to
inspect the kernel memory.
Of course, this applies
to our own debugger, LLDB.
If you try to invoke lldb
even as root and try to attach
to the Finder, then
this is going to fail.
Now, when it comes to
the kext signing program,
I'm sure you know by now, all
extensions have to be signed
with a Developer ID for Kexts
certificate that was issued
by Apple, and then these
extensions have to be installed
into /Library/Extensions.
The new thing here is
that because we are pulling
the kext signing program
under the System Integrity
Protection umbrella,
the kext-dev-mode
boot-arg is now obsolete.
If you are a kext developer,
you need to be able to test
with unsigned kernel
extensions, you will need
to disable this protection, and
I'll show you how in a minute.
But it also means that,
this comment line here
that you probably saw out
there to disable kext signing,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you probably saw out
there to disable kext signing,
is not doing anything anymore.
So let's talk about the
configuration mechanism.
We strongly believe
that this new mechanism,
this new protection, is
critical for our users.
That being said, we realize that
it gets in the way of people
who want to have complete
control over their machine,
and because of what
I said before,
because it protects
the kernel on disk
and requires all kernel
extensions to be signed,
then it also gets in the way
of kext developers who want
to be able to test
with unsigned kext.
So because of that, it
can be entirely disabled.
The configuration is stored
in your NVRAM setting,
which means that it applies
to the entire machine.
So if you have several
installs of Capitan,
they will all be
configured the same way
and it's persistent
across OS install.
So as you move from seed 1 to
seed 2 up to GM and even later,
the configuration will persist.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
the configuration will persist.
So we won't reset it
every time we install.
Now, because root can
actually set a NVRAM setting
and we can't trust root to
do the right thing here,
it means we cannot have
the configuration mechanism
in the OS itself.
So we actually pulled it and
installed it in the Recovery OS.
So this NVRAM setting can
only be set in Recovery.
If you want to change
the configuration,
you need to reboot your machine
in Recovery OS, and you can do
so by holding the
Command+R key on boot.
Then all you have to do
is launch the Security
Configuration application
from the Utilities menu,
and check the System
Integrity Protection box,
apply and reboot.
Keep in mind that these types
that I just describe are likely
to change in an upcoming seed.
So make sure you read
the release notes
to know what the new steps are.
So let's summarize what
we discussed so far.
System Integrity Protection
is a new policy that applies
to every process on the system.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to every process on the system.
It protects the system as it was
installed by Apple, both on disk
and at runtime, by
restricting write access
to system locations, and by
preventing runtime attachment
and code injection
on system processes.
The installer will actively
migrate third-party content
outside of system locations,
so make sure you actually
migrate your content as soon
as possible or that you
fall back gracefully
when you can't find it.
Then finally, the feature can be
disabled using the configuration
mechanism that is
in the Recovery OS.
That's it for me.
Thank you very much, guys.
I will leave the
stage to Andrew.
[Applause]
>> ANDREW WHALLEY:
Thank you, Pierre.
I'm Andrew Whalley, and I
manage the data security group
within Core OS Security
Engineering.
You heard about app
transport security,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
You heard about app
transport security,
and how it helps
protect data in motion,
through the network
connections your app makes.
I'm going to look
at the various ways
that you can protect
data at rest.
I will touch on the Keychain
and storing user secrets,
look at Touch ID and how you
can use it to balance security
and convenience in your app.
Along the way, I will be looking
at existing technologies as well
as what's new in iOS 9 and
how they can fit together
to deliver a level of security
appropriate for your apps.
So let's start with a quick
overview of the Keychain.
You can think of it as a
very specialized database.
You store data by adding rows,
which we call Keychain items,
and then query for them
with the attributes.
It's optimized for small secrets
and by secret I mean a password,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It's optimized for small secrets
and by secret I mean a password,
a token or cookie,
or cryptographic key.
If you have tens of thousands,
thousands of megabytes to store,
consider using file-based data
protection or a bulk encryption
through an API like
Common Crypto
and then just store the
key in the Keychain.
These SecItem APIs have
been around a long time,
but they're still the best
place to store secrets,
including in your
new Swift apps.
So here we have a secret
and we want to store it
in the Keychain using
SecItemAdd.
To do that, we construct
a dictionary
which includes both the secret
and some attributes describing
how to find it in the future
and what protection
it should have.
This pattern of creating a
dictionary to describe or query
for an item, is also used by
the calls to query, delete,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for an item, is also used by
the calls to query, delete,
and update an item, as well
as some of the other APIs,
I should be talking about later.
There's a lot more
about Keychain APIs
in Session 709 from 2013's WWDC.
So here's some things
to consider
when you are writing code
to access the Keychain.
The first is dealing with user
secrets is a really security
sensitive part of your code.
So you should factor it into
small, simple, testable units.
Often this is done
with a wrapper class.
Whether you are using it
directly or through a wrapper,
make sure it has the
highest level of protection
that your application can use.
We describe and talk about
data protection classes,
which are the times at which
cryptographic access is provided
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
which are the times at which
cryptographic access is provided
to those items.
For example, when the
device is unlocked.
In iOS 8, we added the
AfterFirstUnlock --
I beg your pardon.
That's been around for a while,
but you can use it if you have
to access items in the
background, for example,
if you are a VoIP app.
Always accessible is going
to be deprecated in iOS 9.
So you need to start
moving items out of
that into a higher level.
We have WatchKit 2, your
Watch apps now have access
to the SecItem APIs, though
entering a full user name
and password on the Watch is
probably not the user experience
you want.
If your Watch app is displaying
data from a paired iOS device,
consider just sending
that content across
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
consider just sending
that content across
and not a persistent credential.
If your Watch app does
need direct access
to a credential then
consider rather
than storing a full
user name and password,
have your server send
you a token or a cookie
that only has the permissions
to access the content
that the focused functionality
of your Watch app requires.
It's not just on the
Watch that user name
and password prompts
can be inconvenient,
and over the last few releases
we have introduced a couple
of technologies to help you
prompt for passwords less often.
The first is shared
web credentials.
We all know and love
Safari saved passwords
and how it will suggest
and store them for us.
With iCloud Keychain, passwords
will be synced and autofilled
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
With iCloud Keychain, passwords
will be synced and autofilled
on all of your devices.
However, it's common
for a service
to have both a website
and an iOS app.
So it would be great to have
those applications participate
in Safari saved passwords
and with shared web
credentials you can.
Here's some code you might
want to include in the sign-up
or the registration flow
of your application.
SecCreateShared
WebCredentialPassword will
return a random string in the
same format that Safari uses
for it's suggested passwords.
Can you can call
SecAddSharedWebCredential
to let Safari know that there's
a new user name and password
to autofill for a
specific domain.
In iOS 9, we've made it easy to
give this functionality a try
by relaxing some of
the security checks
when you're running
in the Simulator.
So let's have a look at that.
Here I'm going through the
registration flow of my app
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Here I'm going through the
registration flow of my app
to which I just added the code
I showed you a few moments ago.
After that, just pop in
to the settings for Safari
and make sure that name and
password autofill is enabled.
Go to Safari and
see the results.
Here we are back in the
app, being presented
with a user name
and password prompt.
Shared web credentials
allows the application
to display a picker, which lists
all the accounts Safari has
saved for that domain.
When the user has
picked one, the user name
and password is returned to your
app in the completion handler
for SharedWebCredential and
you can then log the user
straight in.
If you want to use this
on device and not just
in the simulator, you're going
to have to add an entitlement
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in the simulator, you're going
to have to add an entitlement
to your application,
and you can do this
in the Associated
Domains section
of the Capabilities
tab in Xcode.
You are also going to
need to put a JSON file
up on your server, but you
might have this already.
As it's the same one
used for Handoff,
as well as in iOS 9 app links.
One change we have made in iOS 9
to make adoption even easier is
you no longer need separately
sign that file.
It's going to be protected
with a secure TLS connection.
I mentioned that Safari saved
passwords uses iCloud Keychain,
but you can also use it
directly in your own apps.
Imagine you have an iOS, iPad,
iPhone, and OS X App Store app
and you want to make
logging into one the same
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and you want to make
logging into one the same
as logging into them all.
So for all of your apps
passwords that can be used
on multiple devices, consider
just adding the synchronizable
attribute to all SecItem calls.
There are a few things that
you've got to think about,
for example, deleting an item
will delete it everywhere,
so make sure you only do that
under the right circumstances.
There are a few more
caveats, and you can see the,
in SecItem.h. If you are
interested in finding out more
about the security
of iCloud Keychain
and how synced passwords are
never accessible to anyone
but the user, see the
iOS Security White Paper.
There's a link at the
end of the session.
So to recap, on the Keychain,
store all your secrets there.
There really is no
place for passwords
in plain text files or plists.
Protect them at the
highest level possible
and if appropriate use
SharedWedCredentials
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and if appropriate use
SharedWedCredentials
like our Keychain to sync them
around your user's devices
and present fewer
password prompts.
So iCloud Keychain is great
for the secrets that can go
on multiple devices but
sometimes you want them
to stay firmly and
securely on just one device.
An example might be a
secure messaging app,
where encryption is device to
device rather than user to user.
The various protection classes
I already mentions have a
ThisDeviceOnly variant.
Items will be backed up,
but only ever restored
to the device they came from.
Last year, we added the
WhenPassCodeSet class,
that ensures items
are always protected
by a local device passcode.
And you can use AccessControl
lists
for even finer grained
control over items.
So since we are talking
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So since we are talking
about protecting
device-specific credentials,
let's look at the security
domains on an iOS device.
User space, where
your application runs,
and the kernel, which as Pierre
mentioned provides process
separation and other
security functionality.
But it also provides many,
many other OS facilities,
which means it has quite
a large attack service.
So with iPhone 5s, we
added Secure Enclave.
Secure Enclave is a separate on
core that has been architected
from the ground up
with security in mind.
That's where we put Touch
ID to ensure the privacy
and the security of your
fingerprint biometrics.
We also moved the KeyStore
component from the kernel
into Secure Enclave
and it's that component
which controls the cryptography
around Keychain items
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
which controls the cryptography
around Keychain items
and the data protection.
So let's focus for a
moment on Touch ID.
While we think of it as
a security technology,
where it really excels
is convenience.
You can unlock your
device without having
to enter your passcode
all the time,
but that itself can give
us some security benefits.
For example it's now much easier
to have a long, complex passcode
which improves the
security of data protection.
Or your phone can now lock
immediately so it's vulnerable
and unlocked for as
small a time as possible.
In iOS 8, we provided some
APIs so you can use Touch ID
in your own applications
as you balance security
and convenience.
But why two and how
do they differ?
Well to understand you're going
to have to know how Touch ID
and biometrics security works.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and biometrics security works.
But luckily, it's very simple.
It boils down to
an if statement.
If a presented finger matches
one that's been enrolled,
then do something.
It's what that something
is, and where it happens
that makes the difference.
Let's start with
Local Authentication.
A finger is placed on the
Touch ID sensor and is matched
within the Secure Enclave.
With Local Authentication,
knowledge of the match
just a Boolean success
or failure, is sent to your app.
And it's there that
your app does something
with that knowledge.
So while the process started
in Secure Enclave, ultimately,
it's the application
in user space
where a security
decision is being made.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So when might you
want to use Touch ID
with Local Authentication?
Think about your app and if
you have any security barriers,
such as requiring a passcode
to confirm an operation,
even though the user
is already logged in.
Touch ID at that
would be much easier.
Or maybe you always wanted
to have an extra step
in an authentication
process but without Touch ID,
it would have been really
just too much of a barrier.
So, for example, you could
prompt before viewing,
especially sensitive data.
Or before an operation like
permanently deleting an account.
One pattern is to have
a Touch ID prompt early
in your application's flow.
But this can lead to a situation
where the user has just unlocked
with Touch ID, and then moments
later has been prompted again
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with Touch ID, and then moments
later has been prompted again
by your application.
In iOS 9, we have added
the TouchIDAuthentication
AllowableReuseDuration,
which is a property
on the Local Authentication
context.
You can use this to
specify a window during
which you won't need
to prompt again
if the user has recently
unlocked their device
with Touch ID.
So that's one way to make
your policy a little more lax.
But maybe you want to make your
policy a little more strict
in some situations.
For example, by reacting to a
new fingerprint being enrolled.
Also new, we have the
evaluatedPolicyDomainState
property.
It's a totally opaque value
that represents the current
set of enrolled fingers.
All you can really do with
it is compare it over time.
If it changed, then a finger
has been added or removed
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
If it changed, then a finger
has been added or removed
to the enrolled set in settings.
If you detect that,
and it's appropriate
for your application, maybe
you can prompt again to see
if users still wants to use
Touch ID on your application,
or require a password
to reenable it.
So let's recap what's new for
Local Authentication in iOS 9.
I have already mentioned
AllowableReuseDuration,
and PolicyDomainState.
You can also invalidate a
Local Authentication context
and if a Touch ID prompt is
currently being presented
to the user, it will behave as
if the user had hit canceled
and tear down the dialogue.
evaluateAccessControl allows
Local Authentication to be used
with Keychain Access
Control Lists, I will touch
on that later and there's
also a lot more examples
in some example code
we are releasing today.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in some example code
we are releasing today.
So talking of Keychain
Access Control Lists,
that's the second way
you can use Touch ID
within your application,
by using it to protect
specific Keychain items.
Here's our architecture
diagram again.
As before, the Touch ID match
occurs in Secure Enclave
but this time, knowledge
of the match is sent
within Secure Enclave
to the KeyStore.
Only then will your Keychain
item be released back
to your application.
So this is useful in you
want to add protection
to a particular saved
credential.
And to take advantage
of additional security
around Secure Enclave.
Maybe at the moment you've
looked at the security tradeoffs
of your particular application
and there are some things you
really don't want to save,
you're prompting every
time or very frequently.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you're prompting every
time or very frequently.
Maybe using Access Control
Lists you can save it,
protect it with Touch ID
and provide a more
convenient experience.
Or you could use it to
increase the security
of something you're
already saving.
You create access control lists
by specifying two
security properties.
The first is effectively
the data protection class.
That's when the data is
cryptographically accessible
to the Secure Enclave.
Next, you specify a policy.
The policy describes a condition
that must be met before Secure
Enclave will release the item
even if it has cryptographic
access to it.
So let's have a look
at the policy types.
The first is .UserPresence.
This will prompt for a
Touch ID match and fall back
to the device passcode.
And you can go straight
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And you can go straight
to .DevicePasscode
as well if you want.
New in iOS 9, it's .TouchIDAny.
This will require a Touch ID
match and there is no fallback.
Also new, and stricter
still, is .TouchIDCurrentSet.
With this, items will only
be released if the set
of enrolled fingers
has not changed
since the item was stored.
I'm going to focus on
this because it might be
that your application
could benefit
from this providing a form of
multifactor authentication.
When you think about multiple
factors, you often talk
about something you know, like a
password, and something you have
and carry with you, like a
physical token, a smart card,
or maybe an iOS device with
Secure Enclave and Touch ID.
If you store an item, protected
with the TouchIDCurrentSet
policy, there's no way to get
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with the TouchIDCurrentSet
policy, there's no way to get
at the item without a
successful Touch ID match.
There's no fallback.
And if maybe an adversary
has the device passcode,
they can't go into
settings, enroll a finger,
and then have access
to that item.
The last two policies,
.ApplicationPassword
and .PrivateKeyUsage allow you
to implement some
advanced functionality
that goes beyond Touch ID.
The first is
ApplicationPassword.
To help illustrate,
let's look at how an item
in the WhenUnlocked class is
cryptographically protected.
In the same way that even
the best door lock is useless
if you've left your
key in the door,
encrypted data isn't
actually protected
if stored alongside the key.
The security of data protection
and the Keychain comes
down to the device passcode
and that's stored in one
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
down to the device passcode
and that's stored in one
of the most complex systems
we know, the user's brain.
They remember it, enter
it into the device,
and we take that passcode and
derive a cryptographic key
and it's that, which
decrypts the item.
Now, let's look at
an item protected
with ApplicationPassword.
Just the device passcode
is no longer sufficient.
Your application has also got
to provide its own password.
Again, we derive a cryptographic
key from it, and it's only
when the device passcode and the
app password are both present
that access is granted
to the Keychain item.
As I mentioned, if you store the
password on device or it's baked
into your app, this
really doesn't offer any
additional protection.
So you have to think
about where off
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So you have to think
about where off
that device you can
store that password.
Maybe it's up on a server, which
can implement its own policy
about when it's released
back to your app.
Or perhaps you have a
physical accessory and you want
to prove the user has it.
If the accessory can't
give your app a password,
then it can't decrypt
a Keychain item
and you know it's not present.
To use ApplicationPasswords, you
create both a AccessControl list
and a Local Authentication
context.
The first says please
use application password
for this item, and the second
specifies the password itself.
You then take both of
these and add to them
to the dictionary you
passed the SecItem call.
This is an example of using a
Local Authentication context
in conjunction with
the Keychain item.
So that was ApplicationPassword.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So that was ApplicationPassword.
The final new policy,
it's Private Key Usage.
Here's the diagram from earlier,
where we saw a Keychain item
being released from the KeyStore
in Secure Enclave, back
to your application.
This obviously is needed if you
take that password and use it
to log into a server,
but it exposes the password
it a potentially compromised
user space.
So wouldn't it be
great if there's a way
to keep the secret
inside Secure Enclave
but still have it be usable?
And there is, using
asymmetric cryptography.
There we don't just have a
single key, but a key pair.
A public key that doesn't
require any protection,
and a private key we
have to keep safe.
Using this requires the
SecKey API and the details
that are somewhat
beyond the scope
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that are somewhat
beyond the scope
of the few minutes I have left,
but here is an overview just
so you can see the flow.
Calling SecKeyGeneratePair
will cause the private key
to be stored in Secure Enclave,
if you specify some new
additional parameters.
But the public key
is still returned
to your application to store.
If you try and retrieve
the private key,
using SecItemCopyMatching,
you can get a reference,
but cannot get the actual
data out of Secure Enclave.
So how do you actually use it?
Well, you might have some
data you want to be signed.
So you can call SecKeyRawSign
and pass the data
into Secure Enclave, and if
you've set up the private key
to be protected by Touch ID,
only after a successful match
will the private key be used
to sign that data, and have it
returned to your application.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to sign that data, and have it
returned to your application.
So one place you might want
to use this is strengthening
Touch ID as a second factor.
I'm going to give an example
flow, but bear in mind
that there are a lot
of intricate details
in writing cryptographic
protocol.
So please don't take this
to be too prescriptive.
First of all, for
the enrollment flow,
you would generate a key pair,
and send the public key back
to the server, along with a
user's regular login details.
The server would record the
public key as being associated
with that user, and
that's enrollment.
Later on, when the server wants
to verify that you're logging
in from the same physical
device that you were before,
it can send a challenge
to your application,
which in turn calls
SecKeyRawSign.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
which in turn calls
SecKeyRawSign.
The user will present
their finger
and have a Touch ID match.
That will result in the
challenge being signed
and you can send it
back to the server.
And the server can then use the
public key it previously stored
to validate the signature.
Just a few more details
on this topic.
The supported keys are
Elliptic Curve P256,
the private key is not
extractible in any form,
even protected, and the
applications are RawSign
and RawVerify.
So in summary, I have given
an overview of the Keychain,
and some situations where
you might want to use it.
I talked about the
technologies we have
to avoid presenting the
user with password prompts.
Looked at the two Touch ID
APIs, Local Authentication
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Looked at the two Touch ID
APIs, Local Authentication
and Keychain Access Controls.
And told you about some new
advanced features you can build
on top the new things we
added to those APIs iOS 9.
App passwords and Secure
Enclave protected private keys.
I'm always fascinated to find
out what wonderful
things you are going
to make using these new APIs
and how you can better balance
security and convenience
in your own applications.
There's some more
information available online,
including the iOS Security
White Paper I mentioned earlier.
There's more information
about app transport security
on Thursday's Networking
with NSURL Session, session.
And come and visit us tomorrow
morning and Thursday morning
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And come and visit us tomorrow
morning and Thursday morning
in the Security and
Privacy labs.
Thank you very much, indeed.
[Applause]