What's new in Android security (Google I/O '18) - VoiceTube: Learn English through videos!

Subtitles section Play video

[MUSIC PLAYING]
DAVE KLEIDERMACHER: Hello, and welcome to the Android P
edition of what's new in Android security.
My name is Dave.
I lead mobile security here at Google.
And in a few minutes, I'll hand it over
to Xiaowen, who is the lead security product manager
for the Android platform.
We have a lot of ground to cover,
so we'll start with a brief state of the union on Android
security, and then jump into all the really cool things
we've been working on in Android security over the past year
and launching here at Android P, including secure hardware
support advancements, lock screen authentication,
integrity, and privacy.
So state of the union.
Let's talk a little bit about what the Android security
strategy looks like.
There are really three main pillars.
First, Google Play Protect.
This is the malware protection and mobile security services
that run on over 2 billion Android devices today.
The second pillar is platform engineering.
These are the core operating system defenses
that we build into Android to improve security to systems,
such as SELinux, control-flow integrity protection, which
we've been investing in a lot in P, and encryption,
verified boot, lots of other features.
The third pillar is the security development lifecycle.
These are all the programs that we put in place
to ensure a consistent, high-quality level for security
across the Android ecosystem.
So this includes things like testing infrastructures,
and also includes our security patching programs.
We've been working really hard on that.
A couple of things we are investing in,
we've been trying to make Android just easier to patch.
So Google, we have a pretty steady track record
for years now every single month delivering those patches
to the market.
But we want to make sure that all Android OEMs are delivering
patches regularly to their devices
as well, not just Google's devices.
And so making Android more modular like with projects
like Treble really help contribute to that.
We've also worked on building security patching into our OEM
agreements.
Now, this will really lead to a massive increase
in the number of devices and users
receiving regular security patches.
So we're really excited about that.
But there are a couple of also really important
philosophical principles that underlie everything
we do when it comes to security.
We believe in transparency and openness,
because that breeds confidence and it breeds trust.
Conversely, a closed platform, secrecy, that breeds distrust.
But actually, there's a really important security advantage
to be open.
Today's mobile devices are faced with really sophisticated
attack threats.
When you have billions of users, it's an attractive target.
And so it deserves the strongest possible defense.
With a closed platform, the defenders
are the employees of the one company that owns the platform.
But with Android, we have the thousands of Googlers
that wake up every morning thinking
about how best to protect users and our platforms.
We have the device manufacturers who have their own security
team to work closely with Google on protecting
Android and its users.
We have the microprocessor manufacturers--
Arm, Intel, Qualcomm, Broadcom, and others,
also with their security teams helping to protect Android.
We have the worldwide open-source Linux community
contributing to Android security every day.
We have the academic research community,
which simply prefer working on open platforms.
So this is a mass force multiplier in protection.
And as operating systems have matured, the power of open
has really become evident to the point
where today, the protective capabilities of Android
are now on par with any other mobile platform.
And I strongly believe that the power of open
will accelerate those protective capabilities
for our users going forward.
The other really important philosophy
that underlies our strategy is measurability.
We always look for objective independent measurements
to help not only inform the work that we
do to ensure we're investing in the right directions,
but also to measure progress.
And so one example you see here is the incidence
of malware or Potentially Harmful Applications
we call PHA on devices.
The bottom curve are devices that load only from Play,
and the top curve are devices that load
from sources other than Play.
And you can see over time, it's been reducing across all users.
So we are committed to protecting users,
regardless of where they get their applications from.
But this improvement is due to many things.
It's locking down APIs and permissions over time.
We're constantly looking at that.
And it's investing in the malware detection
engine itself.
Today, 60% of malware is detected
through machine learning.
And that's been one area of big investment for us.
Over the past year, we've had a 50% reduction in PHA on Play.
And so we're really happy with the progress,
but certainly, we're not content with where we stand today.
Although, I will say that the odds of loading a PHA from Play
is about the same as being struck by lightning.
So it is a safe place to live on your mobile life,
but we're going to continue to invest tremendously
in this area.
Another really important measurement
is the overall ability of the operating system
to protect itself against exploitation.
In any complex product, there are going to be bugs.
But there's no reason why bugs have to lead
to exploitation to harm users.
And so we work really hard on building
features and improvements that make
Android much more difficult and expensive to exploit.
So how do you measure how well you're doing?
Well, lots of people want to purchase exploits.
There's a vibrant market for that.
And as exploits get more difficult, of course,
the law of supply demand, the prices are going to go up.
And so we watch the pricing over time.
And there's a number of different markets
you can look at.
On the left-hand side, you see the device manufacturers
rewards programs.
So the green bars are Google's rewards programs,
which now are paying out the highest
rewards in the industry.
Another market you can look at are the elite hacking contests,
like Mobile Pwn2Own.
And you can see on the graph on the right,
the price of Android exploits has risen each year
to the point where now this is the most recent event
a few months ago.
The pricing for Android is on par with other platforms.
And if you haven't seen the results,
Android performed quite well in that event.
Another market is the gray market.
It's independent researchers and brokers
who will sell exploits to the highest bidder.
This market is a little bit harder to track,
but we have connections to a lot of researchers out there.
And again, anecdotally, what we're seeing
is the price of exploitation on Android
is now as high or higher than any other platform.
So this is really great.
We're happy with the progress, but we continue
to invest in all these areas.
And now let's switch gears and talk about some
of the new emerging features in Android P,
starting with the feature called Android Protected Confirmation.
So the problem here is in today's secure mobility,
we use mobile devices for much more than we ever did before,
much more critical things.
But there's still a ceiling of trust
that we haven't quite broken through.
We don't vote for prime minister or president from our phones.
We don't program life-critical medical devices like an insulin
pump from our phones.
We don't have our passports built into our phones.
It is our goal to break through that ceiling,
and Android Protected Confirmation
is a bold step in that direction.
I'll talk about a few use cases--
medical, financial, enterprise.
But the key innovation here is Protected Confirmation
is the first time in any major operating system API
that we now have the ability to execute a high-assurance user
transaction completely within secure hardware running
in a Trusted Execution Environment,
or TEE, that runs separate from the main operating system.
So how does it work?
So an application developer, say you're a medical company that's
developing a solution for people with diabetes,
and so you're managing an insulin pump.
You want to inject two insulin units into your insulin pump.
And the application will enable the user
to select two insulin units, and then call the protection
API to transmit that data to the secure hardware area
where a completely independent trusted user
interface will execute.
The interface you see here on the screen
shows the two insulin units.
The user then confirms it by pressing a button.
The input is guarded in this protected area.
And then this entire transaction is
signed using a cryptographic key that
never leaves that secure area.
This provides higher assurance to the relying party,
whether it be an insulin pump, or a financial service,
or enterprise that the integrity of this data was not corrupted.
Even if you had root level malware,
you cannot corrupt the integrity of that transaction.
So in code, this is really easy.
We use the standard Android KeyStore
API to create a public key.
We have this new method to set the flag confirmation required.
We create the dialog for the confirmation dialog using
the Confirmation Dialog API.
And then we simply call the present prompt method
to transfer control from the main Android OS
to this trusted execution environment, where
the user will then interact with that special screen.
Really easy.
So we have a number of launch partners
who've been working really closely with us
on this technology.
They've been building prototypes that they
intend to make product into a product in the future.
So Bigfoot Biomedical is a firm that
works on solutions for people with diabetes.
And you see here an app, the Bigfoot Biomedical app.
The user is looking at the glucose level and deciding,
I want to inject 1 and 1/2 insulin units.
Uses the app to select that, then
calls the API to invoke the new user
interface that you see there.
The user confirms.
And then, and only then, will the insulin pump
administer that dose.
In the medical side, we have Royal Bank
of Canada, RBC, that is working to integrate Protected
Confirmations into their application.
I don't have a video for this one,
but you can track left to right.
This application is moving a person-to-person financial
transfer.
We see we're going to send $1,500 to [? Robbie. ?]
The application invokes the Protected Conformations
API, which you see in the middle.
The user confirms $1,500.
So $1,500 can't be changed to $15,000.
The relying party on the other end
has high confidence that indeed, we
intended to send [? Robbie ?] $1,500,
and the transaction goes through.
Duo Security is a firm that's working on strong enterprise
authentication.
Imagine you're logging into your Chromebook,
into your G Suite application, and it launches a second factor
authentication to your phone.
You see the request come in on the left.
The Duo Security application comes up
and asks for confirmation, but then there's
the second level confirmation using the Protected
Confirmation API that provides, again, a higher
level of assurance for the enterprise that it
is the device, and user, and location that's expected
for that authentication.
So there are a lot of other launch partners
we've worked closely with on this.
Insulet Corporation is also integrating their application
for control of diabetes.
ProxToMe is doing proximal-based authentication.
Nok Nok Labs in the enterprise authentication space as well.
I'd also like to throw a shout-out to Qualcomm.
We've been working really closely with Qualcomm
to integrate the Protected Conformations API
into the next generation Qualcomm chipsets.
Because Protected Conformations requires a deep integration
at the hardware level, it is optional for P,
and so it requires a supported Android P device.
We're breaking through that last ceiling of assurance
in mobility, so it's very exciting.
There's a lot more to talk about,
and so I'd like to now call up Xiaowen
to take us through the story.
[APPLAUSE]
XIAOWEN XIN: Thanks, Dave.
Good morning, everyone.
And I'm really excited to be here
to talk about a lot more of the security and privacy features
that we've built into Android P. So as Dave mentioned,
secure hardware is a huge focus area for us,
because they can provide defenses against attacks
that software alone is simply not sufficient to handle.
And so Protected Confirmation was
an API that really leveraged secure hardware.
And another feature that we're making in Android P,
it leverages secure hardware also
to provide stronger protection for private keys.
So why do we need stronger protection for private keys?
Well, Google Pay transit is a great example here.
And in fact, we're working closely with them
on this P feature, and they're going
to launch with it later this year.
Consider their security goal.
In the traditional transit use case,
they need to make sure that your transit card and only
your credit card can be used to pay for your bus ride.
So your transit card has your account information,
a lot of secrets in there that represents your account.
Now, the transit cards are simply
made using a secure element inside of it,
so it's very hard to break into it, extract secrets out of it,
and duplicate that card.
So Android Pay transit is now working to replace that transit
card with your phone.
And so we need to make sure that we provide the same security
guarantees, which is that your secrets cannot be extracted out
of your phone and put onto another phone.
So in order to pay for your bus ride,
you must present your phone.
And a great solution here is to use secure hardware.
Now, Google Pay transit is one example
of an in-person transaction.
Payments is another.
In all of these use cases, you want
to make sure that your phone and only your phone
can make that transaction.
There are quite a few other examples
where we benefit from stronger protection for private keys.
For example, if you have high value cloud data,
if you're an enterprise, or if you
are a financial institution, you want
to make sure that all requests, all data access
is coming from a known phone, a phone that you trust.
And that phone is identified by a private key.
Also, if you have high-value local data,
let's say your password manager, you're storing passwords
locally on disk, then you may want
to encrypt it again with a private key that's
well-protected.
And so how do we provide stronger protection?
Traditionally, secure elements such as those built [INAUDIBLE]
smartcard credit cards, and second factor security keys
and credit cards, are the gold standard for hardware security.
They're built to exacting standards,
and certified by professional labs
to be resistant to hardware tampering.
And phones are now starting to incorporate that exact hardware
directly into the phone so that your phone can
replace your transit card, replace your credit card,
and replace your second factor security key.
And so with Android P, we're now exposing APIs
so that all the applications on Android
can take advantage of this type of temporariness and hardware
on compatible devices and potentially enable
brand new use cases.
Specifically, we're adding a new type
of KeyStore called StrongBox.
StrongBox is built using a tamper-resistant hardware,
like a secure element, that has isolated CPU, RAM,
and secure storage.
The fact that it has its own dedicated
CPU and RAM is pretty important, because it makes it
so that it's resistant to shared resource attacks.
For example, many of the high profile hardware
attacks that we've heard about recently,
StrongBox is resistant to those, as well as
resistant to side channel attacks,
like timing attacks, as well as physical attacks,
like glitching the power line.
So when we look at the KeyStore types that
are available on Android, there are now
three types of KeyStore.
On older Android devices, KeyStore
was typically implemented using the Android operating system
directly.
On new Android devices that ship with Android Nougat and above,
KeyStore was implemented using the TE, the Trusted Execution
Environment.
And now with Android P, we're providing a new KeyStore
called StrongBox that can run alongside it together
with the existing KeyStore and the TE.
StrongBox is resistant to the widest variety of attacks,
and is really well-suited if you have
a use case that requires strong protection
for your private keys.
Now, the caveat here is that because it
does require new hardware, StrongBox
will be available on only some new devices
that ship with Android P.
To use StrongBox, it's fairly straightforward.
When you create your KeyStore key,
set a new flag to request that the key be backed by StrongBox.
If the device supports StrongBox,
then everything succeeds and goes well.
If the device does not support StrongBox,
you'll get a StrongBox unavailable exception.
So to summarize, StrongBox is implemented
using tamper-resistant hardware, like a secure element.
Secure elements are the gold standard for hardware security,
and this is the first time that we're
offering a generic API to access this type of secure hardware
for key management.
This feature, as well as the Protected Conformation API,
are really pushing the boundary for secure hardware support
on mobile.
And we're really excited about the use cases
that this enables.
So protecting your private keys is
one thing that apps need to do.
Another thing that apps often need to do
is to make sure that the right user is present.
When you look at a typical Android device, especially
one that's up to date and fully patched,
the most likely security incident
to happen to that device is not malware,
but rather getting lost or stolen.
And so a lock screen is very important for Android.
Make sure you set a lock screen.
And also, as an app developer, make
sure that you do gate-sensitive access on user presence,
on user authentication.
So in Android P, we added a few different features
to help app developers do that, starting
with keyguard-bound keys.
Keyguard-bound keys are KeyStore keys
that are well-suited for protecting
very sensitive data that you store directly on the device.
Like the name implies, keyguard-bound keys
have their functionality tied to the keyguard, which
is the lock screen on Android.
And so these keys can be used to encrypt data at any time,
and can be used to decrypt data only
when the device is unlocked.
And so the lifecycle of these keys
are tied to the lifecycle of the lock screen.
For example, if you have very sensitive, very
confidential enterprise data or very private
health and fitness data, you might
want to encrypt it with a keyguard-bound key
before you store it to disk, so that if that device does
get lost or stolen, as long as there's
a lock screen on that device, it's now a little bit harder
for an attacker to access the sensitive data.
To use a keyguard-bound key, it's
also fairly straightforward.
When you create your KeyStore key,
set a flag to require that the device be unlocked
to use it for decryption.
Then when you create your cipher objects,
you can create it for encryption at any time.
And you can create it for decryption
only when the device is unlocked.
So fairly straightforward, fairly simple.
Now, what if your device has been properly
unlocked, but you want to check for user authentication one
more time, let's say, before a very sensitive action
like a payment happens?
This is where BiometricPrompt comes in.
BiometricPrompt is our replacement
for FingerprintManager.
Now, a lot of apps today are using FingerprintManager
to reauthenticate the user using fingerprints one more time.
Now, FingerprintManager had a few limitations.
One is it only works for fingerprint.
A lot of devices today are starting to support face, iris,
and other biometric modalities.
And so with BiometricPrompt, we do support
more than just fingerprint.
We support several different modalities.
And it will automatically pick the right modality
for that user and for that device.
Another benefit of BiometricPrompt
is that it uses a standard system
UI, which is really nice from a user experience perspective
to show the user a standard UI when they're making
a security-relevant decision.
Also, it sets us up well for future advances in sensor
technology when you have, for example, an end display
fingerprint sensor.
It's much easier for the OEM to customize
this UI to tell the user exactly where to put their finger,
and less scalable for an app to have
to create device-specific UI.
We know that BiometricPrompt is quite
different from FingerprintManager.
And so to ease the pain of migration,
we're also providing a support library.
And so apps will be able to call the one API in that support
library, and that will use biometric prompt on Android P
devices, and fall back gracefully
to FingerprintManager on older devices.
To use BiometricPrompts, create the builder object,
and pass it, the title, and subtitle
in these kinds of properties.
Then call the authenticate method
on the prompt to create to show the authentication prompt.
We do recommend that you pass in the crypto object,
because that's how you tie successful authentication
attempts to a subsequent cryptographic operational.
All right, so biometric prompt works really well
when your users try to authenticate
your native Android app.
Now, what if the users actually go into your website in Chrome?
How do you authenticate them there?
This is where a WebAuthn and FIDO2 come in.
Coming later this year in Q4, Chrome on Android
will support WebAuthn, which means
if the user's going to your website,
they can now use their lock screen
or their biometric signals to authenticate to your website.
And I think this is very useful because, for example,
if you like to buy things on the web,
PayPal now actually has a demo running where
you can use your fingerprints to authenticate to PayPal
and use that to make your purchase.
And so that's a lot more convenient
than typing in your password every time
you go to PayPal to make a purchase on the web.
So then to summarize the several different methods
that we talked about to gate access based on authentication.
First, with keyguard-bound keys, you
can tie data access to the lifecycle of the lock screen.
If the user has already unlocked the screen
and you want to reauthenticate the user,
then you can use BiometricPrompt to show the system
UI to prompt for biometric.
And finally, if that user is going to your website instead
of your native app, you can use WebAuthn
to authenticate the user via fingerprint
in Chrome on Android.
OK, now that you've determined it's the right user,
let's switch gears one more time to talk about integrity.
A lot of apps really need to ensure
the integrity of their data as well
as the integrity of the device that they're running on.
So how do we do this?
In Android P, to help you protect
the integrity of your data in transit,
we're going to require TLS by default.
So for all new apps that target the P API level,
the system will throw an exception
if the app sends data in the clear.
Using TLS should be a no-brainer for apps today,
because it protects the privacy of your users,
and it also protects your content
from being modified in transit, whether it's
injection of unwanted ads, or injection of tracking
identifiers, or especially formatted data
to exploit a weakness in your app.
So you should always encrypt.
Now, if you're connecting to a legacy website that has not
migrated to TLS yet, then you can still
opt out of specific domains by updating your network security
config.
So do visit the website on this slide
to learn more about customizing TLS enforcement for your app.
Now, before you run off to change your code,
we have one more piece of good news.
A lot of apps care about FIPS cryptographic compliance,
because it's really important and regulated
industries and the government.
So we're really happy that BoringSSL,
which is used to secure SSL traffic on Android,
recently received CAVP certificates from NIST
for many FIPS-approved algorithms.
And so this means that developers targeting
regulated industries now basically
have automatic FIPS compliance built in.
So we're very excited about that.
All right, so another topic in the integrity section
that developers often care about is,
how do I make sure that the device itself
has not been tampered with?
The device itself is still healthy?
In Android O, we introduced a feature called key attestation.
And it's been updated in Android P. Key attestation allows
you to get a signed statement directly
from the hardware itself, from StrongBox, from TE
about the state of the device and about the properties
of your private keys.
So for example, key attestation can tell you
whether the device passed verified boot, whether it's
running a recent security patch, whether the private keys are
protected by TE or StrongBox.
Another thing that key attestation will return to you
on compatible devices on Android P
is the firmware hash that the device is running.
So this is the digest of the operating system
that you're running at this time.
Think of this as transparency-enabled verified
boot.
What this means is that if you're
running a firmware digest that's the same as that
of a known good version, then you're
actually running a bit for bit identical version
of the operating system as a known good version.
So that's a really powerful thing
to know about what you're running.
And it's really important for a tightly controlled environment,
like enterprises, to know that the operating system
that you're running is an exact copy of a known good version.
For users of the SafetyNet attestation API,
the implementation of that will call the platform
key attestation API under the hood.
So you [? would ?] be able to take advantage of this
without any changes to your code.
Now, in some cases, if you want to get more information
from the API than what's returned by SafetyNet,
you can still call the key attestation API directly.
Now, last, but certainly not least, privacy.
Privacy is an important area to security.
We actually talked about privacy quite a bit
already when we talked about, for example,
the TLS by default feature coming in Android.
But there are a few other privacy features
that are in Android P that we want to cover now.
First, this is probably one of my favorite features, sensor
access only in the foreground.
Running on an Android P device, regardless of your API level,
if your app is in the background and idle,
you will no longer be able to access the camera, microphone,
or sensors.
This behavior now is slightly different
based on the exact characteristics of the API
that you're targeting.
So for example, with the microphone API,
you will get silence when you try
to access a microphone from the background in idle.
With the camera API, it will behave
as if you were preempted by a higher priority camera client.
With sensors, it depends on whether the sensor returns data
continuously or via callback.
The bottom line is that if your app is
in the background and idle, you can no longer
access user data from sensors.
Now, if you need to access the camera, microphone, or sensors
and you're in the background, create a foreground service
with a persistent user visible notification.
So that gives users a lot more control and more transparency
into which apps have access to their sensors at that time.
To start a foreground service, create
that persistent notification first, and then
call the startForeground method, and pass in that notification.
All right, besides restricted background access to sensors,
we've also added a lot more user control over your data.
So Android is the first major operating
system to have DNS over TLS support built right in.
And so your DNS queries will be redirected to a trusted
resolver of your choice.
That means that third parties on the web
can no longer monitor or manipulate your DNS traffic.
Now, if your default DNS resolver already supports it,
then we will automatically encrypt your data.
We did this in collaboration with Alphabet's jigsaw team,
who are working on many other initiatives in this area.
And so we're really looking forward
to many new developments here.
Another cool feature that we added
an Android P in the privacy space is lockdown mode.
So lockdown mode is useful if you're
in a situation where you may temporarily
lose access to your device.
Let's say you need to hand it over for inspection
at a security checkpoint.
So at that time, you can put your device
into lockdown mode, which is now in a state
where only your knowledge factor, your pinpad
and password can be used to unlock the device.
And so your fingerprint and other biometrics
will be disabled.
Your Smart Lock will be disabled.
In fact, notifications will no longer show on the lock screen.
So you would now have much higher assurances
on the state of the lock screen, on the security
of a lock screen when the device is temporarily out of sight.
So that was a quick overview of the features that
are coming with Android P. There's a lot more that we
didn't have time to cover.
And so please do give us your feedback
at google.com/io/schedule.
And send us an email, security@android.com.
Thank you for coming, and have a great day.
[MUSIC PLAYING]