Transcript
[ Music ]
[ Applause ]
>> Thank you.
You're all amazing for
coming to a security talk
at 4:00 p.m. I know
it's been a long day,
but thank you so
much for coming.
My name is Ivan Krstic, I
head Security Engineering
and Architecture at Apple, which
is the group that built security
from the ground up into every
product we ship to users.
Today the focus is iOS.
And I am so proud to tell you
about the role security
has played
as a key design philosophy
for that platform.
Before we dive in, we
need to set some context.
Before we dive in, we
need to set some context.
Why is security so
important to Apple,
and why do we believe it is
so critical to our users?
The answer is because our mobile
devices are an unprecedented
record of our lives.
Never before in history
have there been objects
that know so much about us.
About how we spend money.
About the emails we send,
and the photos we take.
About our messages.
From our quickest hellos to our
most intimate conversations.
When you think of it that way,
you realize that protecting
the security of all
that information is so much
more than just about technology.
For us it's a mission, and it's
a mission that is nothing short
of protecting the digital
personal sovereignty
of our users.
And when you think about it
that way, you also realize
that the very definition
of attackers has changed.
Attackers today might
be criminals looking
to hold your data for ransom.
They might be unscrupulous
business competitors looking
to gain an edge.
They might be internet
service providers looking
to indelibly mark your
online activity for tracking
and advertising without
your consent.
It could be nation states,
like in the 2014 hack
of Sony Pictures.
And sometimes curiosity
can get the better
of even those close to us.
And then, of course, we must
never underestimate the power
of the advanced feline threat.
[ Laughter ]
Thank you.
So when you think about all
of these attackers,
what do they want?
We find that the motives tend
to group in one of three groups.
There is personal stalking and
surveillance, which is trying
to access your photos
and your messages,
gin access to your camera
and your microphone,
then there is corporate
espionage,
which is gaining access to your
business emails and documents
which is gaining access to your
business emails and documents
and your intellectual
property, and then finally,
there is direct financial
benefit, stealing money directly
from your online banking
session or injecting ads
and committing click fraud
while you browse the web.
And to do these things,
attackers have created adware,
spyware, ransom ware,
remote access Trojans,
and a variety of other malware.
How do we know this?
Because we've seen it
on other platforms.
[ Applause ]
But not on iOS.
Nearly a decade after
it came into the world,
there hasn't been a
single piece of iOS malware
that has affected
our users at scale.
This is because nearly
10 years ago,
Apple realized what role mobile
devices would come to play
Apple realized what role mobile
devices would come to play
in the lives of our users.
We realized that existing
security technologies would be
woefully inadequate, and could
not step up to the challenge,
and so we decided to build
the best security technologies
that we could imagine to
protect our customers,
at a scale that is staggering.
We are protecting users that use
over a billion active iOS
devices all over the globe.
And every single one
of our security features
protects a real user
from real threats.
But we are not in this alone.
There are really three key
pillars to iOS security.
There is platform security
which are the technologies
that we build into our
software and hardware.
There is users who upgrade
their software to the latest
and most secure versions,
and then there's developers
like you, who use our
security technologies
to build secure apps.
We're going to talk about
all three pillars today.
We'll start with
platform security.
When you think about how
security used to work,
especially in enterprise
settings, it was a long
and complex list of
thing that users have
to do to try and be secure.
Loading secure configuration
into their devices,
complex batch management
schemes,
complex password policies.
It was difficult,
it was heavy handed,
and it set up users to fail.
It was so hard to be secure.
But because Apple owns all
the hardware and software,
we were in a position
to address this
in a unique and innovative way.
When you look at iOS security,
we've built security
directly into the silicon.
We have made the
devices that are secure
out of the box by default.
We've made it really easy
for our users to update
and run the latest and
most secure version.
We have made it really
easy to log
into the devices
securely with Touch ID.
We have a curated App Store, and
we've made security easy to use.
IOS platform security consists
of a great deal of features,
IOS platform security consists
of a great deal of features,
and today I only have
time to highlight five.
We'll start with Secure Boot.
One of the most important
ways of being able
to trust a device is to trust
the software that runs on it.
And the way we do this is by
building trust into the silicon.
The Apple design system chip
inside every iOS device holds
Apple's public keys in an area
of memory called Boot
ROM, which is read only.
It's written in the factory and
cannot be changed after that.
And when your iOS device
starts, we take that public key
and the Boot ROM will validate
the next step in the boot chain,
which is the low-level
boot loader.
And only that validation passes
will we move on to the next step
in the chain, and we'll repeat
this until iOS has fully booted,
which gives us confidence
that every piece of software
which gives us confidence
that every piece of software
that was used in boot was
signed with Apple's Private Key.
When you think about secure
boot, it's really interesting
that we don't rely
on any third parties
to deliver secure boot trust.
We don't rely on
certificate authorities
that are outside of our control.
The keys used or secure boot are
generated management provision
by Apple.
The code that does
the verification
that I just showed you
is written by Apple,
and only Apple is in possession
of the private keys required
to sign all the software.
But there is another
interesting element of this,
which is that when an iOS device
goes to update the version
of the software, it has
to contact our installation
authorization server,
and ask for permission to
update to a given version.
And it does this by taking
cryptographic measurements
of the update, sending
them to the server,
and asking whether
it's okay to update.
We do this because the
server is now in a position
to deny an iOS device the
ability to move to an older,
less secure version of iOS.
And so when you put these
two things together,
you get a strong and trustworthy
mechanism for relying
on the software that
runs every iOS device.
It's not possible to copy
an old version of iOS
from one device to another.
It's not possible to
tamper with the integrity
of the software of this process.
Now, let's talk about
protecting user's data at rest.
If you're really serious about
doing this, you don't want
to take the cryptographic
keys that protect user data
and make them available to
the application processor
or the normal processor
in the device.
That is because the attack
surface there is simply
too large.
If you're serious about
protecting user data at rest,
you build dedicated silicon that
holds those cryptographic keys.
We've done it.
We call it the secure enclave.
Now, when you think
about passcodes,
Now, when you think
about passcodes,
normally they're very
short, four to six digits.
And if somehow an
attacker were able
to take the encrypted data off
a phone, or off an iOS device,
and attempt every
single possible passcode,
it wouldn't take them very long.
So what we do instead is we
take the user's passcode,
and we derive a key from
it that is untangled
with the hardware key
that is only available
to our secure enclave.
Which means it's not possible
to guess passcodes offline.
Passcode guesses must
happen on the device,
and the device is free to
limit the number of attempts.
In fact, this is exactly
how your iOS devices work.
After a few incorrect
passcode attempts,
we start imposing a time delay.
But after 10 incorrect
passcode attempts,
the secure enclave will simply
not unlock that device again.
This has nothing to do with
the erase data feature,
where if it's on, the data
will actually be erased
after 10 incorrect
passcode attempts.
Even if you have
this feature off,
once 10 incorrect
passcode attempts are made,
the secure enclave
will not unlock
that device again regardless
of how much time you give it.
So we built the system using
industry standard algorithms.
We've subjected it to rigorous
internal security audits,
and third-party code review,
and then we've taken
it a step further.
We have taken our core
cryptographic libraries
that underpin data protection,
and we've posted them on the web
for everyone to download
and inspect.
Let's talk about sandboxing.
Sandboxing is a method for
isolating data between apps.
This is because even with
the best of intentions,
developers sometimes
make mistakes,
and sandboxing is a
way of mitigating some
of the potential harm
from those mistakes.
of the potential harm
from those mistakes.
It's a little bit like air
bags or seatbelts in a car
which mitigate the risk
of injury in an accident.
We also use sandboxing to
put some of the choices
around security directly
in the hands of our users.
We have a mechanism called
TCC, or transparency consent
and control, where we can ask a
user whether they trust a given
app with some of
their sensitive data,
like location, photos
and contacts.
And once a user makes a
decision in a dialogue by this,
the sandbox mechanism and the
kernel enforces that decision.
Another critical element
of our platform security
is code signing.
When an attacker is
trying to attack a device,
the very first step
is attempting
to get their malicious
code to run.
Because of this, iOS code
signing doesn't just cover the
operating system.
It covers every app
that runs on the device.
In fact, when you go to upload
your app into the App Store,
In fact, when you go to upload
your app into the App Store,
X code will calculate
the cryptographic hash
of every executable and
resource in your app bundle,
and will write them into a code
directory alongside the app,
which is then sent
to the App Store.
When the user then
downloads an app and runs it,
our kernel will look at every
executable page of memory
and compare it against the
code directory to make sure
that it hasn't been
tampered with.
As a result, an attacker can't
simply take some malicious code,
inject it into memory and then
divert the control flow to it.
Instead, they have to
resort to much more complex
and difficult schemes to get
their malicious code to run.
Let's talk a bit about Touch ID.
We know that for
our iPhone users
on average they unlock
their phone 80 times a day.
And if you have a passcode
set, it adds friction
to each one of those 80 unlocks.
As a result, almost half
of our users didn't
have a passcode set,
and we knew that because the
passcode is quite literally part
of the key used to protect
the user's data at rest,
this is a problem
we had to solve.
We needed a solution that
was easy, that was fast,
and that provided
great protection
to the data of our users.
For us, that solution
was Touch ID.
But we didn't just take
a fingerprint sensor
and put it in a phone.
You can change your passwords,
but you can't change your
biometric properties.
You can't change
your fingerprint.
And so we knew that we had
to afford the biometric
data the highest level
of protection we could build.
So what we did was we connected
the fingerprint sensor directly
to the secure enclave,
with an encrypted link.
to the secure enclave,
with an encrypted link.
And we made it so that when you
touch your finger to the sensor,
that fingerprint is transmitted
directly to the secure enclave,
where it is processed,
and then encrypted.
And it's never made available
to the application processor
that runs normal
applications on the phone.
Now, I mentioned
that before Touch ID,
about half of our users
had a passcode set.
Now, 9 out of 10 do.
This is a shining example
of what Apple is amazing at.
It takes our hardware
engineering expertise,
our software engineering
expertise, our dedication
to ease of use, and
combines them in a way
where a normal user doesn't
care about fingerprint sensors,
doesn't care about secure
enclaves or hash functions.
What they get is simply
an amazing step forward
for the security of their data.
The second key pillar
of iOS security is users
upgrading their software.
The latest versions of iOS
are always the most secure,
and we're constantly
making iOS more secure based
on the threats we see today and
threats we see in the future.
And we've built all
this deep technology
for trusting the software
that runs on our hardware,
but it doesn't matter how
secure a version of iOS is,
if people are not
installing the latest one,
the one that is most secure.
So when we think about
software updates, it is not just
about the device and
the software it runs,
it is also about our
relationship with carriers,
and our ability to get
updates out there quickly,
and also the user experience
for how a user sees an
update on their device.
One thing we've done with iOS 9
is we greatly shrank the amount
of space it took to install
updates, so that users
of space it took to install
updates, so that users
who had relatively little free
space could still get the latest
and more secure version
of the software.
We then took a look
at the user experience
and said sometimes users
don't want to be interrupted
to do an update, so
we'll give them a choice
to install an update
right then and there,
or to install it
later that night
when they're probably
not using their phone
or be reminded the next day.
The results are amazing.
Nearly 85% of our customers
are running the latest version
of iOS, the most
secure version we have,
and if you think this is easy
or obvious, you only need look
at some of the other
platforms [audience murmurs].
This, by the way, is a fair
comparison, because Android 6
and iOS 9 were released
within just a couple of weeks
of each other, and for some
perspective, every version
of Android before 5.1.1 has
a vulnerability called stage
of Android before 5.1.1 has
a vulnerability called stage
fright, which is
remotely exploitable.
You can exploit it by sending
a specially crafted message
to a vulnerable device,
and gain complete control
over that device.
And Google patched
this bug very quickly.
But it doesn't matter,
because most
of their users don't
have the fix.
And a fix that is not installed
doesn't do anyone any good,
which is why we invest
so much effort not just
in building secure versions of
iOS, but also making it easy
for our users to have that
last and most secure version.
The third pillar in iOS
security is developers like you,
using the security
technologies we provide,
to build secure apps.
This means following best
practices on the platform.
We have an amazing number of
apps that use Touch ID API
to save their users from having
to remember complex passwords
and type them directly into
the app, and last year,
and type them directly into
the app, and last year,
we introduced a feature
called App Transport Security
that provides strong protection
to app information as it travels
across the network to
that app's servers.
Today I'm proud to say
that at the end of 2016,
App Transport Security
is becoming a requirement
for App Store apps.
This means that by the end of
2016, when your apps communicate
with your own server
back-ends, they must do
so using a secure TLS
channel, using TLS 1.2,
unless the data being
communicated is bulk data
such as media streaming and
data that is already encrypted.
This is going to provide a
great deal of real security
for our users, and
the communications
that your apps have
over the network.
There is another piece of
responsibility that rests
on you, the developers,
when you build your apps,
and this is to know your code,
and not just the code you write,
and this is to know your code,
and not just the code you write,
but also any third-party
code you actually include
in your apps.
This is the because libraries
you use may undermine the
security of your app.
Maybe because they're doing
things you're not aware
of behind your back.
But maybe because
there is a more recent
and more secure version
out there.
There is kind of an
amazing example here
where there is a very popular
third-party networking library
that had a critical
flaw in the validation
of security for TLS connections.
And this flaw was patched
very quickly, but for a period
of time, there were up to
25,000 apps in the App Store
that didn't have that
latest, more secure version.
So it's really important that
you get your third-party code
from trustworthy locations,
that you know what it does,
and that you keep it current.
So these are our three key
pillars of iOS security.
Platform security, which are
the best security technology
mechanisms that we can build
into our hardware and software.
Our users who download the
latest and most secure versions
of iOS and developers like you,
using our security technologies
to build secure apps.
And it's a fair question to
ask, so how are we doing?
How good is iOS security?
Security is interesting,
because unlike performance,
you can't measure it directly.
You can't run a test, and
time how long it takes
to get an objective answer.
So what you're left with
are indirect metrics.
And I have three that
I'll share with you today.
The first one is that after
a decade of its existence,
there has still not
been a single piece
of iOS malware affecting
our users at scale.
This one is the one that
is most important to us.
Our users have been
fantastically well protected
Our users have been
fantastically well protected
for nearly 10 years.
The next indirect metric that is
interesting is to look at some
of the unfettered jailbreaks
that are coming out.
These are jailbreaks that
defeat iOS security mechanisms,
and what is interesting
about them is
that the latest launch we've
looked at frequently have
to find and chain
together between five
and ten distinct vulnerabilities
in order to be able
to defeat platform
security mechanisms.
This is much higher than
on any other platform.
And the reason is because iOS
security measures work together
in lock step in such a
way that defeating all
of them takes a long
time and a lot of work.
For my last indirect metric,
I want you to take it
with a grain of salt.
As probably most of you
know, there is a black market
for software vulnerabilities.
And every once in a
while, some of the prices
on the black market
become known.
Usually these prices are
tens of thousands of dollars,
sometimes a hundred thousand.
But in 2013, the New
York Times learned
that an iOS vulnerability sold
for $500,000 and last year,
Forbes interviewed a
jailbreak developer who said
that most experts agree
that the black market price
of an unfettered iOS
jailbreak is a million dollars.
Take that with a grain of salt,
but it's a fascinating
number to think about.
So where does this leave us?
Clearly, security is a
process and not a destination.
We're not done with iOS
security and we never will be.
It's also not something that we
just got interested in recently.
It's also not something that we
just got interested in recently.
What you're seeing now
is a result of a decade
of our best work in
protecting our users.
But the bad guys
aren't standing still
and we will constantly
evolve our security
to defeat not only
the threats of today,
but also the threats
of tomorrow.
We will take our
hardware expertise
and our software expertise,
and we will build the
best security technologies
that we can imagine to
protect our customers
and how they use their
mobile devices today
and also how they'll
use them tomorrow,
and protect our customers
against today's attackers
and tomorrow's, even if
they are cats [laughter].
Thank you very much.
[ Applause ]
>> For those of you who want
to learn more, I invite you
to read the iOS security guide,
which creates a great amount
to read the iOS security guide,
which creates a great amount
of technical detail about
all the great features I just
covered, including many others
that I didn't have time for,
like iCloud keychain and
two-factor authentication,
and a link will be available
at this session site.
Thank you again.
[ Applause ]