Security on Android: What’s Next (Google I/O’19)
Articles Blog

Security on Android: What’s Next (Google I/O’19)


[GOOGLE LOGO MUSIC] XIAOWEN XIN: Now, I
first tried out Android when I tried out the
HTC Dream phone, which was the first commercial device
that launched with Android not more than 10 years ago. At launch, Android was known for
its transparency and openness, and we still stand by
these principles today. And since then, Android
has made its way into the hands of
billions of consumers and some of the most demanding
enterprise environments. And in order to protect all
of our users and their data, security is a top priority. And we’re making
measurable progress in raising the bar across
the mobile ecosystem. We run a vulnerability
rewards program, which is a bounty program
with some of the highest payouts in the industry, paying
up to $200,000 for a security exploit chain that
compromises your device. High rewards plus
our open source code fosters a vibrant
community of researchers who help us find bugs before
they affect our users. And in 2018, there were
zero critical security vulnerabilities affecting
the Android platform that were publicly disclosed
without a security update or mitigation available. As another data point,
there are a number of vulnerability discovery
and disclosure competitions that invite hackers from around
the world to come and break mobile devices and are paid
up to hundreds of thousands of dollars to do so. At [INAUDIBLE],, I
own, which is one of the most well-known
competitions of this kind, Google Pixel has a
great track record of being unbroken
year after year. Now, we know that these
results were achieved on fully patched,
up-to-date devices and that the ability
to patch a device is critical to its
security posture. And we’re doing a lot
to increase patch rates across the ecosystem. At the technical level, we’ve
re-architected the operating system to make patching easy
for device makers and seamless for users– to make updates
easy for device makers and seamless for users. And beyond the technical level,
our ecosystem of partners have come together to form
a strong collaboration and to remove barriers. And in Q4 of 2018, we saw 84%
more devices receive a security update compared to
Q4 the prior year. Now, we know that security
threats come in many forms, and some of them, like
phishing and spyware, don’t need to actually
compromise your device and bypass the security
model in order to harm users. So Android devices
with Google services have Google Play Protect built
in and enabled by default. We leverage a combination
of human security expertise and state-of-the-art machine
learning to find potentially harmful apps before
they find our users. And in 2018, we saw a 20%
year-over-year decline in the proportion of
devices that installed a potentially harmful app. All of this data plus a lot more
is available in our annual Year In Review report. We also publish a quarterly
transparency report with details on the overall
health of the ecosystem. To find links to these
reports along with a lot more information, visit the Android
Security Center website at Android.com/Security. OK. So that was a quick overview
of how we’re doing today. Now, developers in the
audience and everyone else in the audience
probably came here to learn more about
what’s new in Android Q. And there were a lot of changes. They fall under
three categories– privacy, updatability,
and hardening. Now, privacy’s a huge
focus area for us and has been for many years. We made dozens of changes across
all aspects of the operating system. We’re giving users a lot
more transparency over access to their data. We’re giving users more
control over their location and then with
further restricting app access to persistent
device identifiers. Now, this is just the
tip of the iceberg. There was a talk
yesterday at I/O focused on privacy for Android. So take a look at the recording
for that to learn more. Next, updatability. We’re building upon the momentum
that we started with Project Treble a couple of years ago. And this year, we
launched Project Mayline. With Project Mayline, a
few system components, including some
security-critical ones, will now be updated
directly by Google. So for example, the
media frameworks, which accounted for about 40%
of the bugs that were patched in last year’s monthly
security bulletin, will now be updated by Google
on all new devices that launch with Android
Q. And device makers can also choose
to have Conscrypt, which is Android’s TLS
provider, also updated directly by Google. With this in place, future
bugs affecting these components can now be fixed
much more quickly across the entire
ecosystem, so we don’t leave our users vulnerable. To learn more about this, we
published a blog post yesterday on the Android Developers
blog, so take a look at that to find out more. And finally, hardening. Android leads the
ecosystem in leveraging compiler-level mitigations such
as sanitizers, control flow integrity, and Hardware
ASan, and many more to harden the operating system. In Android Q, we
expanded the usage of these techniques
in the kernel as well as the most critical
parts of the user space to significantly reduce the
potential exploitability of bugs in these areas. Now, these hardening tools
can also be leveraged by apps. For example, for apps that
target the Android Q API level, you’ll now have execute-only
memory enabled by default. This marks executable
memory regions as not readable, which
strengthens ASLR, Address Space Layout Randomization. To learn more
about hardening, we have a blog post coming out
in the next couple of days to the Android Developers Blog. OK. So that was a quick overview
of how the operating system is becoming even more secure
with Android Q. Now, the developers in the
audience probably came here to learn more about
what we can do to make our apps more secure. So last year we launched
industry-leading APIs such as Strongbox and
Protected Confirmation. And this year we’re
building upon that momentum. So for the remainder
of this session, we’ll cover a few
topics in encryption, in application signing keys,
and then user authentication. We’ll also cover a couple of
really exciting areas, a couple of really big areas that
we’re working on that promise to be very impactful
in the future. OK. Let’s now dive into
the first topic– encryption. This is an area where we’ve
gotten a lot of questions from developers over the years. Developers want to know, is
my data actually encrypted on the device? Now, the answer has always
been fairly complicated. While the vast majority
of new Android devices fully encrypt user
data, there are a number of low-end devices such
as Android Go devices sold primarily in developing markets
that use low-end hardware and don’t have hardware
acceleration for encryption. And so encryption
on those devices causes noticeable slowdowns and
makes the device hard to use. And this affects not just phones
and not just Android devices. Smartwatches, Internet
of Things appliances, and similar smart,
connected devices often reuse the same
hardware as in phones. And so they inherit the
same hardware limitations. To address this, we
set out to create an encryption mode
that can run fast without additional hardware. And the result is Adiantum. Adiantum is a new
encryption mode created by Google engineers
and cryptographers designed specifically for disk encryption
on low-end ARM devices. It has a couple of
very nice properties. First, Adiantum was designed
to run using only operations that all CPUs natively
support, so it doesn’t need digital hardware. And our benchmarks running
purely on CPUs, Adiantum runs five times as
fast as AES, which is the standard cipher
used on Android today. And so, besides being fast,
from a security perspective, Adiantum only uses well known
cryptographic primitives with well known
security properties. And because we developed
it fully in the open, we got a lot of
input and feedback from the worldwide community
of security researchers to help us make sure
that it works correctly. And so besides being
fast and being secure, Adiantum now levels the playing
field for all Android users. While high-end, premium devices
with specialized hardware will always have
an edge in speed as well as some
security properties, low-end devices now also have
a tool to help them encrypt and secure their user data. So now with Android Q,
100% of compatible devices launching with Q will
now encrypt user data with no exceptions. So this includes all form
factors supported by Android, including the phone
in your pocket, the tablets that your
kids may be playing with, the Android-based TV that
may be in your living room, and the Android Auto-based
car that you may be driving. So this is a huge
milestone for Android. And beyond Android, it’s
also a huge milestone for the entire community. Adiantum is fully
open sourced and has been merged into Linux 5.0. And so in today’s world, where
computation is increasingly moving to the edge, often
to low-power devices, device makers, regardless of
whether your device is running Android or not,
now have a new tool to help secure your user data. OK. So Adiantum is great
for new devices, but device makers
in the audience, you probably have apps that
need to run on older devices as well. And so you need a
solution for encryption that runs everywhere. Now, unfortunately,
writing an encryption layer is far from easy and
mistakes are common, mistakes such as
reusing nonces or not having enough entropy
in your key generation. And what’s worse is that these
mistakes often go unnoticed until an incident happens. And so, this year, in
order to make that easier, we have built a security
library into Jetpack. [APPLAUSE] Thank you. The Jetpack security
library was built based on our experiences
talking with developers, talking with all of you
about your top pain points. And the goal here is to make 80%
of the most common tasks really easy to get right. These tasks include
encrypting files, encrypting shared preferences,
and securing our API keys. And under the hood, the
Jetpack security library handles all the boring
details for you, such as creating and managing
your keys and secure hardware. And we use industry-standard
best practices. The Jetpack security library
is in alpha this week and exports to
Android 6.0 and above. So, if encryption is a pain
point for you, take a look and give us your feedback. OK. So we’ve now talked a lot
about encryption of your data at rest with Adiantum, with
the Jetpack security library. Now, what about encryption
of your data in transit, your network traffic? Last year we launched
DNS over TLS, which encrypts your DNS traffic. And this year, we’re
improving HTTPS by enabling TLS 1.3
by default. TLS 1.3 is a new revision of the TLS
standard, finalized by the IETF in August of last year. It is faster because it can
often complete the connection handshake in fewer round trips,
making connection times up to 40% faster. It’s more secure because
it removes support for problematic features. And it uses a
redesigned handshake that fixes several weaknesses. And finally, it is more
private, because it encrypts more than a
negotiation handshake to protect the identities of
the participating parties. Now, how do you use
TLS 1.3 in Android? For web browsing,
modern browsers, such as Chrome and Firefox,
have already enabled support. For apps, if your app uses
Chrome Custom Tabs or WebView, then you’ll also be
using TLS 1.3 by default if the server
supports it regardless of the Android platform
version that you’re running on. And on Android Q, if your app
uses Android’s built-in TLS provider called
Conscrypt, then you’ll also be using TLS 1.3 by default
regardless of your app’s target API level. OK. So encryption’s getting better. The next question to ask is,
is anyone using encryption? Are apps actually encrypting
their network traffic? So we pulled some numbers. And we’re really happy to see
that for apps in the Play Store targeting Android
Pie, more than 80% are now using
NetworkSecurityConfig to block clear-text network traffic. And another 5% of apps are
blocking clear text by default, with a few manually
configured exceptions. So these are great numbers. And a big thank you
to all the developers out there who are encrypting
your network traffic and securing your user data. Now, if you own one of these
remaining apps that’s still allowing clear text
by default, please take a look at
your configuration and see if there’s
anything you can do to choose to switch
to a safer default. Moving forward, we’ll be
adding more hints and warnings into both Android Studio as well
as the Play Developer Console to help developers
ensure that we’re all using encryption and HTTPS
as much as possible OK. So we’ve talked about encryption
with encryption of your data at rest, encryption of
your data in transit. Let’s now switch gears and talk
about application signing keys. So this is an area
where we’ve gotten a lot of questions from
developers in the past as well. I’ve personally had meetings
with a few top developers where this is a huge pain point. The issue here is that there
are some apps in the Play Store, especially a few that
have been in the Play Store for a long time, that are
now using application signing keys that are no
longer strong enough. Maybe they didn’t
have enough entropy when they were generated,
or maybe the developer has lost access to
their keys, or a spec that has been compromised. So, in order to make
key management easier, a couple of years ago,
we launched app signing by Google Play,
where apps can opt in to have Google Play
manage your signing keys and protected against
many types of compromise. Since launch, we’ve seen that
a large majority of new apps are now opting in
to app signing. Now, while key
management is now easier, there remains a gap
for many existing apps who are using weak
keys and need a way to move to a stronger key. And so, in order
to help with that, this year we’re launching
key upgrade for new installs by Google Play. If your app is already using
app signing by Google Play and if you’re using
a weak key, you can now ask Google Play to
manage a second, stronger key on your behalf. And the way that this works is
that for your existing users who already have
your app installed, all updates to that
app will continue to be signed by
the original key. Now, on the other hand, for your
new users and returning users, on devices that don’t currently
have your app installed, new installs will be signed
by the new key and an update to that will also be
signed by the new key. So this is how we can
gradually move your user base to primarily using the original
key to using the new key, for example, when a user
of yours buys a new phone and installs your app
on that new phone. Now, you may be wondering, why
are we using the new key only for new installs? The main reason here is that
older Android platform versions do not have great
support for key rotation. And so if we try to update your
app to a new version signed by a different key, the platform
will reject that update. And so this approach of
gradually moving your apps from using the old key
to using the new key is the most non-disruptive. Now, the good news here is that
Android Pie added great support for key rotation natively
into the platform. And support is coming as well. So in the future, on new
Android platform versions, we’ll be able to move existing
installs to the new key as well. Enabling this
feature is very easy. First, make sure
you already opted in to app signing by Google Play. Then go to the App Signing page
on the Google Play Developer Console and click on Request
Key Upgrade to get started. The rest of the developer
workflow doesn’t change. You can continue to
upload a single artifact, whether it’s your APK or
your application bundle, and Google Play
will transparently, in the background, sign
it with either the old key or the new key and deliver the
right version to the end user. OK. Before you enable this,
there are a couple of things to keep in mind. Because you are going to be
changing your application signing key, you need to
check for dependencies on that old signing key. For example, if you’re using
any third-party services that recognize your app based
on the signing key, you’ll probably want to
update them to also recognize the new key. Also, if you’re using any
platform features that depend on the signing keys,
such as signature permissions, then you’ll probably
want to refactor your app to achieve your objectives
in a different manner. Now, as I mentioned earlier,
this is a temporary limitation. Android Pie added in great
support for key rotation natively into the platform, and
Play support is coming as well. So in the future, you’ll be
able to both rotate your key as well as continue to
use platform features that depend on the signing key
on new platform versions. OK. So we’ve talked about
encryption of your data at rest, encryption of
your data in transit. We also talked about your
application signing keys. Let’s now turn to the last
topic, user authentication. This is another area where
we’ve gotten a lot of questions from developers over the years. And it’s easy to see why. There are a lot of
security-sensitive apps such as banking apps,
password managers that need to prevent unauthorized
access to their apps. And so they need to authenticate
their users on a regular basis, and we want to make that easy. So last year, in
order to do this, we launched the
BiometricPrompt API. BiometricPrompt allows apps
to use a common interface to authenticate. And so users get a
consistent experience across all of their apps. And BiometricPrompt is
built in a generic way to support a wide variety of
biometric types such as face, fingerprint, and iris. Since launch, we’ve seen
a lot of apps adopt this, and we’ve also noticed
a few gaps in coverage. And so this year, we’ve updated
the underlying framework with more robust support
for face and fingerprint, and we’ve also updated the
API to support more use cases. So let’s now dive
in and take a look at the new features
in BiometricPrompt in Android Q. First,
BiometricPrompt now supports both an implicit
confirmation flow as well as an explicit confirmation flow. The explicit confirmation
flow is the default flow, and it’s how
BiometricPrompt works today. In the explicit flow, the user
must explicitly do something to confirm the
transaction, such as tap their finger to the
fingerprint sensor or, if they’re
using face or iris, they need to press a button
to confirm the transaction. The explicit flow should
be used for all high-value transactions, such as payments. Now, new in BiometricPrompt
in Android Q is our support for an
implicit confirmation flow. In the implicit flow,
the user doesn’t actually need to do anything to
confirm the transaction. And this is useful if–
for example, let’s say you’re a personal
diary app, and you want to authenticate your
user, and your user, let’s say, is using face authentication. Now, when the user
starts your app, you can use BiometricPrompt
to authenticate your user using their face and
transition immediately into a signed-in state without
the user having to do anything. So this provides a much lighter
weight, much more seamless user experience to your users. So the implicit
confirmation flow is best for transactions
that are easily reversible, such as sign-in and autofill. In order to select the
implicit confirmation flow, call the API on your screen, and
note that while the system will do its best to honor
this, there are situations where user
confirmation will still be required. OK. So this is one great
feature of BiometricPrompt in Android Q. Another great
feature is that apps can now give users the option of having
more options to authenticate to the app. This is really
useful in situations where biometric authentication
may not work very well, such as face authentication
in poor lighting conditions. So in those situations,
apps can now give users the option to
use their device pin/pattern password to authenticate
to the app, which can give a much better user
experience in those situations. Now, of course, it may not
be appropriate for all apps, and so apps can also not
allow a fallback [INAUDIBLE] default flow. If you don’t have
a fallback, you can always use your
app-specific methods, such as your
app-specific password to authenticate your user. OK. So that was a second
great feature. We’ll talk about one last
feature for BiometricPrompt in Android Q. And that is
that apps now have the ability to check on the status of
biometric authentication on the device. So this is useful
if, for example, you are the owner of this
beautiful app on the screen. You want to show this Enable
Biometric Sign-In toggle if and only if the device
actually supports biometric prompts and the user
has enrolled in it. So you can now
check for the status of biometric authentication
on that device by calling the
API on the screen. All right, so that was a
quick overview of what’s new for BiometricPrompt
in Android Q. Since we’re talking about
user authentication, I have two more
pieces of good news. First, as of earlier this
year, Android 7.0 and above is now FIDO2-certified. This means that, if you’re
a website on Android, you can now use
WebAuthn to authenticate your user without a password. So your users can use their lock
screen pin/pattern password, or their biometric, or their
second-factor FIDO-compliant security key to
authenticate to your app. So this allows us
to extend the ease of password-less
authentication to the web. Native apps on Android can
access equivalent functionality by calling the FIDO2 APIs
provided by Google Play services. OK. So another piece of good news
is that, as of last month, you can now use
your Android phone as a second-factor security key
to authenticate to your Google account. Now, second-factor
authentication is probably one of the most
important things you can do to secure your online account. And not all second-factor
authentication methods provide the same
security guarantees. And so this integration
here hits a sweet spot in convenience and security. Today it works for
Google accounts. And we’re working on
standardizing the protocol, so that we can bring it to
other websites in the future. All right. So we’ve spent the
last few minutes talking about user
authentication online. We’ve also done a lot of work to
make user authentication really easy in the real world. So I’d like to bring René
onstage to tell us more about that. [APPLAUSE] RENÉ MAYRHOFER: Thank you. XIAOWEN XIN: Hey, René. My six-month-old son just got
his first driver’s license. Unfortunately, his onesies,
they don’t have pockets, so he doesn’t have a great
way to carry this plastic card around with him. So can we do something to
help him out with that? RENÉ MAYRHOFER: Well, I would
say six months may be a bit young to be driving
or carrying a phone, but let’s talk about that,
because I think many of us have that same usability problem– of
having too many things to carry around. So joking aside, I’m very happy
to talk about a few details on exciting upcoming
areas in Android security. The first is what we call
identity credentials. And this is about
an electronic ID. Electronic ID has
been an active topic in research and early
projects for quite a while. And, before coming
to Google, I actually myself have worked for
three years in that space, so please excuse me for being
just a little bit excited about this topic reaching
a level of maturity that allows us to bring to
end users right now. What I’m very happy
to announce is that Android will support
Electronic Identity in the form that we also call identification
in the physical world. That may be the mobile driving
licenses that we just see here. That might also be future
travel documents or simple cloud membership cards. Now, in all of those use
cases, Android Support will focus on strong security
and privacy guarantees. As is typical with Android,
we are designing an open API to allow apps to use such new
hardware and platform support. This new Identity Credential
API will support the development of so-called holder apps. These holder apps
are applications that support a specific
form of Electronic Identity, like, for example, those
mobile driving licenses. Those apps are free to define
their own communication protocols to the
Verifier or Reader apps, for example, through NFC
or other wireless channels as well as their communication
to the respective issuing authority of that credential. Android implements a
new credential store that can be accessed
through this API and manages secure storage
of all such provisioned credentials. Depending on hardware
support, this will be backed by
OEM-specific secure hardware with respective
attestation, as you might know from key master
and Strongbox key attestation. Now, within that
credential store, every app that provisions
such credentials has its own private store
of attributes belonging to this particular document. And the store will transparently
handle their secured persistence and access
control for apps that created those items. Users will, in addition, be
able to view a transaction log of all accesses to
their credential attributes to ensure transparency of
those identity documents in pretty much the
same way that the call log does that for incoming
and outgoing calls. Now, unfortunately, some of
the international standards, including the ISO working
group for mobile driving licenses that Google is
also contributing to, haven’t locked down yet at this
point to a sufficient extent that we were comfortable
merging this API directly into the Q platform. However, in the
very near future, we will be releasing a
new Jetpack compatibility library that implements
the credential store within an app’s
private data directory. This API is not expected to
change significantly, so, as soon as this
library is released, all developers are free to
start developing such Electronic Identity holder apps. The library will be compatible
with the vast majority of Android devices out there
in the field at the moment. In future versions, we expect
a new HAL implementation for OEM-specific back ends
based on secure hardware that will be used by a credential
store system service and made available through new
Framework APIs that will very, very closely match the APIs
that we will soon release in that compatibility library. If the hardware
supports it– and to me, that’s one of the most
exciting parts there. This will also allow what
we call Direct Access. Direct Access is using
your identity credential, your document, even
if the main phone battery is too low
to power the CPU and therefore to boot Android. So just using, for example,
an NFC tap to the reader, you will still be able
to use that document even if the phone no longer boots. That, of course, requires
some hardware support, but support for this
is already in the HAL, in the draft HAL specifications
as well as the API that you will be able to start using. With that secure
hardware support, devices can also
give the highest end certifiable security and
privacy guarantees for users as well as the
issuing authorities. Now, to give a small sneak peek
of what that API looks like, it’s pretty simple, actually. An API would first create an
instance of the credential store and use that
reference to provision a new credential, a new
document, as we also say, which can actually have
multiple, what we call, namespaces in there. One namespace
could, for example, be that draft standard of the
ISO mobile driving license, but could also be extended
within the same document with another namespace that
could add additional attributes to make this document
a real ID travel document within the
United States here. After creating,
after provisioning such a new credential,
an app can also request a proof, an attestation
that all those attributes were provisioned into the secure
hardware exactly as provided by the issuing authority
and sent that proof back to the issuing authority
for verification there. Now I’d like to
change tack a little and move on to the
second upcoming topic that I am very pleased to talk
about, which is how we mitigate against what we call insider
attacks in the Android ecosystem. There are, actually, multiple
efforts towards that goal, but here on this
talk, I would like to primarily speak about
firmware transparency on multiple layers. Now, if I speak about
insiders, what do I actually mean by that? An insider is any person
who has privileged access to information or resources. That is intentionally a
very broad definition. It includes hardware,
and protocol designers, of course software
developers, but also logistics and retail shop personnel. In fact, many of you, most
of you listening to this talk will be insiders in
one way or the other. And that just includes access
to your own app signing key. Now, with so much complexity,
so many stakeholders in the supply chain
contributing to what goes into making a modern mobile
phone, a modern mobile device, the big question is, how
can users actually trust their own device? Our answer to that is focusing
on transparency on many layers, from hardware all the way up to
the apps and the dynamic code those apps actually load. In addition to the app
signing upgrade key feature that Xiaowen mentioned
earlier in her talk, I would like to dive into
two other of those layers. The first layer is
the system layer, which contains the main
operating system itself. Android has always been
among the most transparent OS by being open source. At last year’s
Android Pie, we edited end-to-end,
client-side-encrypted backups to mitigate against insider
attacks on such backups. And that even includes
Google servers, Google server administrators in
that threat model of being considered insiders. Now, we go one step further
towards the transparency of the system by focusing on
the system software that’s running on the device itself. A new version of
ABB tool can now be used to compute the top-level
digest of the Android system image if the device is
using the standard vbmeta format for verified boot. For Pixel 3 and 3A phones, you
can download the latest factory images and independently
compute this digest. Now, when the device boots,
the updated boot loader will verify this vbmeta
digest, and all the associated partitions mentioned
within this vb metadata, and pass on the measured
hash to key master running in TrustZone, as
well as Strongbox running on the Titan M chip. This is true for both
Pixel 3 and Pixel 3A phones as of today. An app can create the private
key in Key Master or Strongbox, request an attestation
certificate for those keys, and that certificate will
now contain a new field with exactly this measured hash
as seen early on in the boot chain by the boot loader itself
before even passing control over to the Android kernel. Now, by matching that hash into
that attestation certificate with the one computed
independently and offline from the
official factory images, it is certain that
this device is actually running one of the official
factory images that has passed all the
checks, that has gone through all the testing. And not one that may
have been modified for an individual or just
a small group of devices. Coming at the second
layer, I would like to point out here
is the firmware that runs below the main
operating system. So if a device is
lost or stolen, how can we make sure that
data is safe even when we assume insider
attacks with access to firmware signing keys? That is where we add what we
call insider attack resistance on the layers below a device. Let me quickly explain
how that works. The first line of defense
is that cryptographic keys are generated and stored
in secure hardware, like the Titan M chip. This is tied into verified boot
and will only make those keys available– for example,
for device-level decryption for the key that is used
for [INAUDIBLE] on device, when the proper user
knowledge factor– that is pin-code,
password, or pattern– is entered by the user. However, an insider with access
to such signing keys leaked, whatever went wrong
there, could potentially create a Trojanized firmware
that, when you update the Titan M or other secure
element to that, would make those
cryptographic keys available without performing
that verification for the user knowledge factor. With Strongbox insider
attack resistance, we take the next
step of mitigating against such attacks. By default, every update
to the Titan M firmware will invalidate all keys
that are stored inside. Only when the user
knowledge factor is available during the
update itself will the keys be migrated to work on the
new version of the firmware. Now, if an attacker has a
correctly signed firmware update but doesn’t have access
to the user pin, password, or pattern, they can still
force-apply that update. To the boot loader, it looks
like a legitimate update. It’s correctly signed, it has
an updated version counter, and so on. They can force that
update to apply. But without having the
user knowledge factor at the same time, this will
make all keys inaccessible and therefore be roughly
equivalent to a factory data reset. Coming back to the
multiple different layers that I talked about,
we have to conclude that every one of those layers
will require different methods to mitigate insider attacks. However, transparency is a
key component to all of them. We are trying hard to make
it possible for developers and users to verify what
is happening on every layer and to audit instead of having
to trust all those parties in that complex supply chain. Whenever reasonably
possible, we take ourselves out of the trust equation,
so that you don’t actually have to take our word for
it but can verify yourself. As app developers,
we recommend you do similar analysis of
what insider attacks on any of the components that are
under your direct control could look like and what you
can do to mitigate against that. We are all in this together,
and the open source nature of Android luckily
makes it easier to build this kind
of transparency. Now, thanks a lot for all
your attention on what was a very dense session
with a lot of detail. And special thanks to all of you
coming in here in the morning after the big party. Highly appreciate it. Thanks. [APPLAUSE] [GOOGLE LOGO MUSIC]

6 thoughts on “Security on Android: What’s Next (Google I/O’19)

  1. 33:15 – He's talking about android transparency. Will new Pixel devices still required closed source binary blobs to function properly? Its been years since you could compile AOSP for nexus/pixel and have a functional phone without pulling in the binary blobs.

  2. It's 2019 and Android still has unrevokable permissions for apps. Not sure what's a bigger joke, Android security or Android privacy.

  3. How about finally rewriting the media framework in a secure language? Fixing individual bugs in the media framework cannot be a longterm solution

  4. How should a firmware hash protect against insider threats? Verified boot does nothing against malicious software developers.

  5. How is it that owning Android makes me feel less secure. I hate Apple, but use an iPhone and iPad and will continue to do so until Android figures out a way to convince me that they are secure. Although, people are now doing what they can to make iPhone/iPad less secure. What a world we live in.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top