Transcript
[ Music ]
[ Applause ]
>> Good afternoon!
[laughs] Welcome everyone.
Thanks for coming out to hear
about what's new in security.
My name's Lucia Ballard
and I manage the Secure
Transports Team here at Apple.
And together with my colleague
Simon we'll be talking you
through a bunch of new stuff
that we've been working
on to help you improve the
security for your customers.
So, I hope a lot of you caught
Evone's [assumed spelling] talk
before this.
It's a great overview of why
we do what we do and sort
of the fundamental underpinnings
of security on our system.
Here we're going to dive a
little more into the details.
So, here's what's on deck.
First up we'll be talking
about some network
security changes on iOS.
Then we'll discuss
a couple of updates
to our cryptography APIs.
And then Simon's going to talk
about platform security
on macOS.
So, diving into network
security; if you use your phone
as much as I do, you know
that it's accumulated an
incredible wealth of detail
about your personal life,
and a lot of that comes
across the network.
Whether it's articles
you're reading,
or messages you're
sending to your friends,
all these little bits of detail,
even if they seem
insignificant alone,
can add up to a really
incredible picture of a person.
So, that's why we
think at Apple all
of this detail should
be protected by default.
We think HTTPS is the new HTTP.
So, for every resource you're
loading across the network,
you should provide
confidentiality
you should provide
confidentiality
and data integrity
to your users.
The other key point here is that
not all HTTPS is created equal.
HTTPS is built on SSL, or now
in the modern age known as TLS,
and not all versions of this
protocol actually provide enough
security that your users be
resistant against attacks.
So, building on these
principles,
last year we introduced
App Transport Security.
App Transport Security
means that for all loads
that you're doing,
using the NSURLSession,
or even the older
NSURLConnection APIs,
you have to be using top of
line, solid TLS connections.
First off that means TLS
version 1.2; this version's been
out for a while, but it's the
only one that's fully resistant
to all the vulnerabilities that
we know about, like BEAST attack
or the POODLE attack, or other
exploits with these scary names.
or the POODLE attack, or other
exploits with these scary names.
It also means you have to
use strong cryptography
so that's ciphers like
AES-128 or better,
and certificates
signed with SHA-2.
Certificates signed with SHA-1,
it's getting easier to attack.
Finally, it also
means forward secrecy.
So, this is a way
to exchange keys
between server and the client.
It gives an amazing
property, which means even
if in the future
that certificate --
the server's certificate
is compromised,
you can't reveal the
content of any communications
that have happened in the past.
So, you add all these together
and you have, what we think,
is a secure connection
that protects the
data of your clients.
Now, we know that it takes
some time to get up to speed
with App Transport Security, so
we also introduced Exceptions.
You can turn it off globally,
or you could set Exceptions
up for particular domains
that you knew couldn't
move to TLS that fast.
that you knew couldn't
move to TLS that fast.
Now I'm wondering
how many people
in this audience are
thinking, "Oh yeah,
I set that Exception last
year and haven't thought
about it for a while."
Well, now is the
time to revisit it
because this year we're starting
to enforce App Transport
Security at the App Store.
This is going to kick in at
the end of 2016 and it means
that for most Exceptions
you'll need
to provide a reasonable
justification.
So, for all of these Exceptions
that actually turn off
App Transport Security,
or its key properties
like using TLS 1.2,
you'll need to explain
why you need
to use this Exception
in the first place.
For other Exceptions like
Forward Secrecy, we recognize
that support for those
is not fully universal,
so for now those Exceptions
will be granted automatically
without any justification.
So for example, if you have a
partner server you're working
with and you don't have control
over what cipher suites they're
offering, we will be able
to enable you to keep
talking with that server.
We're also adding
some new Exceptions
to make it easier to adopt.
So for example, if you're
using Streaming Media
and that media's already
encrypted in bulk, we'll be able
to offer an Exception through
AV Foundation for you to load
that media without
connecting over TLS.
I want to be clear, we still
think the right answer here is
that you use TLS for everything,
but in some cases we will be
able to provide this Exception
to help you transition
more smoothly.
We're also offering a
Web Content Exception.
So, here sometimes your app
needs to load arbitrary content
from around the web
and of course you can't
guarantee that's using HTTPS.
So, if you're WKWebView, then
you can just set this key
in your app's Info.plist.
NSAllowsAarbitraryLoads
inWebContentKey and then all
of those loads will be exempted
from the App Transport
Security requirements,
but everything else your
app is doing, like talking
to your own server, will
still get the protection.
So, that's App Transport
Security,
but we're also making changes
to TLS across the system
because cipher suites keep
evolving and keep getting more
and more effective attacks
posted against them.
So, no matter what
your ATS settings are,
we've now disabled
RC4 by default
for anyone using
our networking APIs.
We've also disabled SSLv3
in Secure Transport.
So, even if you're dialing
down into our lower level
APIs you won't be able
to access SSLv3.
Research has simply
moved too far for both
of these technologies
and no longer think
that they provide effective
security for our users.
that they provide effective
security for our users.
So, these are disabled.
Other algorithms are
starting to show their age;
specifically SHA-1 is showing
more and more vulnerability
to attacks, as is 3DES.
So, if you know that you
have a dependency on either
of these algorithms now
is the time to drop it.
And I recognize many people in
this room are app developers
and aren't in charge of their
own back ends, so you'll need
to reach out to the
folks at your company
or whoever's hosting your
back end to make sure
that they've dropped
any dependency
on these older algorithms
that are getting deprecated.
It would be a great time to
check in about the status
of loading things using
HTTPS and make sure
that you are cleared for
App Transport Security,
then you'll be able to
fly through app review.
So, that's App Transport
Security.
It's making sure everything
loads using strong TLS,
but strong TLS is not enough.
You also need to have
confidence that the certificate
that you're using to validate
that TLS connection
represents the right server.
So, I want to talk about a
couple of different technologies
that we're using today to help
you have confidence that you're
in fact reaching out to the
server that you think you are
when you're establishing
these secure communications.
So, first let's back up
and talk a little bit
about how certificates
work today.
So, if you're connecting
to a server,
that server has had
a certificate issued
from a certificate authority.
That authority validates
the host name
and says, "Yep, sounds good.
You are in fact example.com.
Here's your cryptographic
proof of that."
And when you connect the server
sends that certificate over.
But this is not always
a perfect mechanism.
If there's an attacker who
manages to get a certificate
If there's an attacker who
manages to get a certificate
for your host name, then
the attacker can provide
that certificate, and you as
the client don't have a way
to distinguish the attacker's
server from your own server.
This could happen
if the certificate
authority makes a mistake or,
worse case scenario,
if the certificate
authority gets compromised,
someone else uses their private
keys to sign with things.
So, today I'm proud to announce
that we're joining the effort
for certificate transparency.
Certificate transparency is a
technology that uses public,
verifiable logs of
issued certificates.
These logs collect certificates
from a huge variety of sources,
so there are many participating
certificate authorities,
but in fact anyone
can submit a log.
Then the logs issue
a cryptographic proof
that the certificate
has been logged
and a client can
check for that proof.
There are a bunch of
different ways to do it.
Proof can be embedded in
the certificate itself,
or it can get handed over
in the TLS handshake,
or it can be delivered
by OCSP stapling,
or it can be delivered
by OCSP stapling,
which I'll talk more
about in a minute.
So, here's a quick
overview on how it works.
First, the certificate authority
not only issues a certificate
to the server, but it also
sends it over to the log,
it gets added into
the public log.
The log then sends
a signed proof
that the certificate
has been included,
and the server hands both that
and the original certificate
over to you, the client.
That means you can
validate the pair together.
So, certificate transparency
makes it more difficult
to launch attacks.
Basically it puts the
attacker in a bind.
If the attacker can
get a certificate
from an authority that's not
participating, they have no way
to get that cryptographic proof
that the certificate has
been included in the log.
So, they hand over
the certificate alone
and the client can reject it.
Alternatively, if they are using
a certificate authority that's
Alternatively, if they are using
a certificate authority that's
participating, then that
tainted certificate gets logged
and is publically visible, and
that gives you an opportunity
to revoke the certificate at
the certificate authority level.
So, we think this is a critical
technology to enable you
to have confidence that the
certificate that you're talking
to is in fact the certificate
you want to be talking to.
So, here's how you
can try it out.
You can actually use the same
info.plist that you used to set
up your app for security
configuration.
It's a new keyword, so for each
example it has a certificate
that's participating, you
just set this keyword,
and then your client will reject
any certificate it can't prove
that it's been publically
logged.
Our current policy roughly
requires that you need a proof
from at least two logs.
These logs -- we're adding
new logs as we qualify them,
but basically if your
certificate works
but basically if your
certificate works
in Chromium it'll
work for us as well.
And there's a lot
more information
about the general technology
at certificatetransparency.org.
So, I encourage you
to go check that out.
Now certificate transparency is
a great piece of this ecosystem,
but it doesn't totally
replace revocation.
There's still that last
step where once you found
out the certificate is flawed
for some reason you have
to actually stop trusting it.
So, I want to take a
couple of minutes to talk
about our recommended
practice here.
It's called the OCSP stapling.
Now this is a standard that's
been out for a couple of years,
but we think that it --
now's the time for folks
to actually move to it
and start adopting
it because support
for it is now quite widespread.
OCSP stapling is an enhancement
to the online certificate
status protocol
and solves a bunch
of problems with it.
So, as a refresher,
this is how OCSP works.
We have the same set up, right?
Where your certificate authority
is issuing the certificate
to a server, every
time a client connects
to that server it sees the
certificate and it wants
to know whether it's
still valid.
So, it asks the certificate
authority right there
in the middle of
the TLS handshake,
and the certificate
authority says, "Yep,
the certs still valid," or
"No, sorry it's invalid.
Don't trust it."
This has some issues.
One of them is that it's slow.
You're right in the middle of
this handshake; you're trying
to get your resources,
you don't want to wait
to make your network
connection to some other entity,
especially if that
server's gone down,
you might be hanging
for a while.
The other major issue is
that it leaks a little bit
about whatever activity
you're doing online.
Your certificate
authority gets to see
which host names
you're connecting
to because you're
sending a response
up each time you connect.
OCSP stapling resolves
a lot of these concerns.
So, here's basically
how it works.
So, here's basically
how it works.
Instead of the client asking,
the server asks the
certificate authority,
and the certificate authority
hands a signed response back
to the server.
Now it's signed by the
certificate authority
so you know you can trust it.
Then the server gives both
the certificate and a promise
that it's valid over to
the client, all in line,
all in the same handshake.
So, this means that your
revocation information is
delivered reliably and quickly.
There's no extra waiting.
There's no concern there.
And it protects your
user's privacy
because the only connection
they're making is back
to your server.
You may have noticed
that diagram looked a lot
like the certificate
transparency diagram and that's
because you can use
the same mechanism
to deliver certificate
transparency proofs.
As long as your certificate
authority is participating you
can hand all of that information
together in the same handshake.
And, like I said, OCSP
stapling is widely supported
And, like I said, OCSP
stapling is widely supported
across many operating systems
and is backwards compatible,
so you can go turn it on
today, in Apache, in GenX,
whatever your backend
is hosted on.
And it's now fully supported
across every Apple platform.
So, if you could take a step
back and summarize where we are
with network security, now's
the time to move forward
to App Transport
Security Standards.
So, that's strong algorithms
and strong ciphers; TLS 1.2,
forward secrecy, and
SHA-2 Certificates.
Also, it'd be a great time
to start experimenting
with certificate transparency.
Find certificate authorities
that are participating
and get integrated
into this ecosystem.
And please, go enable
OCSP stapling
so we connect the
full loop and know
that you can have confidence
in making secured connections
back to your servers.
in making secured connections
back to your servers.
So, that's network security.
Now I'd like to take a
couple of minutes to talk
about some cryptographic
improvements.
So, first up is SecKey.
SecKey is our algorithm,
or excuse me,
is our API for asymmetric
cryptographic operations.
And in this release
we've unified it
across macOS and iOS APIs.
SecKey now has support for all
the common operations you would
want to do with asymmetric
key pairs; the RSA, the ACC.
So, that's signing and
verifying with asymmetric keys.
This means that SecKey
is a total replacement
for the deprecated
CDSA calls on macOS.
And it also replaces any use of
SecTransform you might be doing
to do cryptography
with asymmetric keys.
So, we strongly recommend
moving forward with SecKey.
We've also tied this into a
new kit called CryptoTokenKit.
We've also tied this into a
new kit called CryptoTokenKit.
CryptoTokenKit is system support
for cryptographic devices
so that smart cards you might
be using to prove your identity
and various enterprises
or USB tokens,
we now have out of the
box integration with these
and they can integrate
into system surfaces.
So, that means the Token content
is available in the keychain,
as you would expect, and the
Token operations are available
using the SecKey API.
Now this is a complex topic
and there's a lot of
detail to go into.
So, please come see us in the
security labs and we can talk
through your use case.
So, thanks for your attention
and with that I'll hand it off
to Simon to talk about what's
new in Platform Security.
[ Applause ]
>> Thank you very much Lucia.
Hello. I'm Simon Cooper.
I'm the manager of the
Trusted Engineering Team.
So, I'm going to talk about
what's new in security,
but first of all I
want to talk about --
a little bit about how software
is delivered on the Mac,
a little bit about Developer
ID, and I'm going to talk
about Gatekeeper and
some packaging issues
surrounding Gatekeeper.
So, let's start off about --
talking about how
software is delivered
for a couple of our platforms.
So, for iOS you can get
apps from the App Store.
You can build and
run apps using Xcode
and install them on
your own devices.
And there's some enterprise
programs that allow you
to deliver and manage
content to devices.
You'll notice that all of these
installation mechanisms are
silently handled by
the iOS platform.
So, now I'd like to talk
a little bit about macOS.
So, you can also get apps
from the Mac App Store
and that's a very good
way to get your apps.
You can also get apps that are
assigned with Developer ID.
You can also get apps that are
assigned with Developer ID.
You can also use Xcode
to build your own apps
and use the traditional
command-line UNIX tools
to build things in
the normal UNIX way.
So, let's go back and talk a
little bit about Developer ID.
So, what is Developer ID?
Developer ID allows you
to deliver apps outside
of the App Store.
These apps are usually
downloaded using a web browser.
The Developer ID
Program will issue you
with a Developer ID signing ID.
And when you sign apps using
that identity they are treated
specially by Gatekeeper.
There are actually some improved
flows in Xcode 8 that allow you
to properly export
your Developer ID
to properly export
your Developer ID
signed applications.
So, there's something
we're actually going to do
and that's a change to
the Developer ID Program,
and this was announced
yesterday.
We're actually allowing
Developer ID
to be used with iCloud.
So, Developer ID can
now use iCloud features.
That includes iCloud
Drive, iCloud Keychain,
Push Notifications, and VPN.
So, what does this mean?
This means that you can deliver
iCloud enabled apps outside
of the App Store and you can now
use Developer ID to share data
with your iCloud
enabled iOS apps.
You will be able to deploy
these new Developer ID apps back
to macOS 10.9.
So, I'm sure you want to know
when you'll be able
to do all of this.
So, you can start iCloud
Development testing today.
So, you can start iCloud
Development testing today.
That's using the Xcode 8 tools.
And I'm sure you're aware
that when you're doing testing
of iCloud there is a development
and production environment.
When you're going to deploy
your iCloud App you'll want
to be deploying against
the production environment
and you'll have to wait for
an upcoming seed in order
to start testing that.
When you are going to do
that, please use the new flows
in Xcode 8 because they make
sure that you are deploying
against the production servers.
The Xcode team also
asks me to remind you
that please don't distribute
apps unless you're using the
GM tools.
So, the other side of
Developer ID is Gatekeeper.
Gatekeeper allows us to
control what apps are allowed
to run on your machine.
And there is a Preference Panel.
And on that Preference
Panel, in El Capitan,
And on that Preference
Panel, in El Capitan,
there are these options; you can
run apps from the Mac App Store,
you can run from the Mac App
Store, unidentified developers,
or you can run apps
from anywhere.
When you first run an app
Gatekeeper will prompt you
before its first run.
We're actually making
some changes to Gatekeeper
and we're making changes to
the Gatekeeper UI in Sierra.
We are changing the
default options,
and those default
options are going to be --
you can run from
the Mac App Store,
you can run from the Mac App
Store unidentified developers.
Now if Gatekeeper rejects
your app for some reason,
there's usually a button that
appears in this Preference Pane
that allows you to open
and -- to open anyway.
Unfortunately I have to say,
in the seed build this function
is not actually working,
but it will be fixed
in a later seed build.
I also want to say that we
haven't actually changed the way
I also want to say that we
haven't actually changed the way
that this underlying
mechanism works and the way
that the policy works.
So, this means that if you
have managed configurations
or you use command line tools
and use the policy tools,
you can re-enable
the Allow Anywhere.
So, I want to talk a little bit
now about some other changes
to Gatekeeper, but
I first need to talk
about a repackaging problem
and the Gatekeeper enhancement
that we've developed
to address this.
Now the repackaging
problem is a problem
because of the way
certain apps are written.
There are a certain type of apps
that when they are written they
reach outside of themselves
and use external resources.
These apps may be delivered
in various ways and they may
in fact be correctly signed.
But the external
resources that they reach
out to may not be signed
and they can be code
or code equivalent.
They could be libraries,
they could be plug-ins,
they could even be HTML content.
And you may not be aware
that local HTML content,
that if it contains JavaScript
can access all of your system.
These resources could also be
Lua Scripts or Python Scripts
or even Apple Scripts.
So, what's the problem?
Well, if you put these two
things together inside a
container and deliver the app
in this way, maybe through a zip
or a disk image or using an
ISO image, and you put this app
into the container, and then you
put the resources alongside it,
when the app runs and it talks
to the external resources
it's loading these potentially
dangerous things.
And you'll notice that the
app, with its green border,
And you'll notice that the
app, with its green border,
meaning that it's signed, is
reaching outside of itself,
outside of the signature,
and trying to touch these
potential resources.
So, if I take that app
and I repackage it,
but instead of packaging it with
the external resources that you,
the developer, would
like to be there,
and I put malicious
content there,
then when the user runs
the app they're not going
to be getting your
experience, they're going
to be getting the experience
of the malicious code.
Now if that malicious code
is a [inaudible] library
that you may have put into a
plug ins directory, for example,
then your app is almost
certainly not going
to be doing what you
expect it to be doing.
So, we're calling this
a repackaging problem,
and there are some things
that are actually
not affected directly
by the packaging problem,
and those things are apps
that are delivered
from the Mac App Store.
And that is the best
way to get apps.
Other things that are
not directly affected is
if you install your apps using a
signed Apple Installer Package.
That doesn't mean to say
that the app once it's been
installed can't be repackaged
and delivered in
another mechanism,
but the actual Apple Installer
Package doesn't have the problem
of reaching outside
the resources.
So, there are things
that are affected,
and that is if you are
delivering your app using a zip,
or a disk image, or if you've
got a combination of things
in an ISO image, and any
other kind of archive format.
It's also possible that if
your disk image is structured
in such a way that
you are trying
to assemble an app using a
combination of pulling resources
from here and there, you can
also be affected by this.
from here and there, you can
also be affected by this.
So, I -- we need your
help with this problem.
And we also need to
protect our customers
because of this problem.
So, what do we need to do?
So, if you're delivering
something that has a signed app
with some external resources,
and you may be doing this
through using a zip, or a
disk image, or an ISO image.
And we need to ask you to
switch to using a disk image.
And the reason we're
asking you to do this is
because we can now
sign disk images.
You can sign a disk image
using macOS 10.11.5,
and that is the current
release of El Capitan,
or any of the later
release of OS X.
You can use the cosigning
tool to sign the app --
You can use the cosigning
tool to sign the app --
to sign the disk
image, I'm sorry,
and that will basically
bind the external resources
and the app together.
These signatures are actually
embedded in the disk image
and are carried along with it,
and this signed disk
image is compatible
with older OS releases.
So, I'd now like to give
some packaging advice.
So, one way to avoid
this packaging problem --
repackaging problem is
to avoid it completely
and put your resources
inside the app bundle
and then sign the whole thing.
If you're distributing just a
single app bundle you should
consider delivering it
via the Mac App Store.
You should certainly
sign the app.
Perhaps package it
in a zip archive,
but please verify the
signature before you release it.
Alternatively if you
have a complex set
up you can use a signed
Apple Installer Package.
up you can use a signed
Apple Installer Package.
For a container with apps and
resources, with a disk image,
please use, and switch to
using a signed disk image.
Sign any content that you
have inside the container
so that app that's inside
there should also be signed,
and you should sign
the disk image.
And please verify all
the signatures before you
release it.
So, some final words
on packaging,
so if you're adding
personalization
or licensing information
to your app
when it's being downloaded
please use an extended attribute
on the bundle route of the app.
And there's a tech note that
describes how to do this
and that's Tech Note 2206.
And you could also do this
by signing the personalized
disk image.
Here are some things that
you should definitely not do.
You should not modify
your app after signing,
because this will break
the code signature,
and when Gatekeeper comes
to verify your app
it will get grumpy.
You should never deliver your
app with a broken signature
and please stop shipping
ISO images.
So, now I'd like to talk
about a Gatekeeper enhancement
that we have developed that
helps combat this problem.
And this is all about
protecting customers.
This mechanism, we're calling
Gatekeeper Path Randomization,
it supplements existing
Gatekeeper --
all the existing
Gatekeeper protections,
and there's no change
for Mac App Store apps.
And there's no change when
you're upgrading to Sierra
for any apps that were
previously run on your system.
This mechanism will
come into play
for any newly downloaded apps
and it applies to apps that are
on unsigned disk images.
So, let me describe exactly how
this mechanism is going to work.
So, this is a complex
object, now this could be
in your Downloads folder and
it could be an unpacked zip,
or this could actually
be a mounted disk image
that contains your app
and those extra resources.
So, when you double
click on your app,
when your app runs it will be
relocated, with some tricks,
into a randomized place on the
file system and it won't be able
to access the resources.
So, this stops the
repackaging attack.
So there are some situations
where this relocation
does not happen.
If the user explicitly
moves the app
If the user explicitly
moves the app
and it's just the app
itself, if they move the app
with something else, then
this mechanism does not get
turned off.
If the user moves the
single app by itself,
maybe to Slash Applications,
then this mechanism
will be turned off.
This does not happen if
you sign your disk image.
So, any apps that are run
from a signed disk image will
not have this mechanism apply
to them.
This mechanism also
doesn't come into play
if you install software using a
signed Apple Installer Package.
It also doesn't apply to any
apps from the Mac App Store.
So, in summary if there
were two things to take away
from this talk; sign the things
that you deliver and check
that things that are valid.
So, more information about
this talk can be found here.
So, more information about
this talk can be found here.
[ Applause ]