Hello. Welcome to "11 Weeks of Android."
My name is Sudhi Herle.
I lead Android Platform Security.
I'm very sorry we couldn't do Google I/O this year.
I trust you and your loved ones are safe and healthy.
Security means different things to different people.
For us in the Android team, we look at security
as the careful software engineering discipline
necessary to keep our users, their devices and their data
safe from accidental or intentional abuse from bad actors.
Our security approach is built on three pillars.
One: Principle of Least Privilege.
Number two: Isolation and Containment.
And three: Defense in Depth.
What does Principle of Least Privilege mean?
It means that every component in the system
must have the least possible privilege
and permission surface for its operation.
Isolation Containment means that system components and apps
must be isolated from each other
such that vulnerabilities in one don't end up
becoming system-wide exploits.
Furthermore, we focus a lot on making sure
that any exploits are appropriately contained.
In a sense, we work very hard to limit the blast radius.
Finally, Defense in Depth means that
we shouldn't rely on a single component in the system
to reason about the security of the entire platform.
We believe in engineering the platform such that
we have multiple defenses to keep our users safe.
Android is the most popular
and most secure consumer OS in the world today.
But this didn't happen all at once.
It took us and the ecosystem almost a decade
to get to a point
where we could have high confidence in the security of Android devices.
What did we do to get here?
Let's take a quick look at the past.
Many years ago, we brought SELinux to Android
as a fundamental building block
for compartmentalization of various apps and services in Android.
This has continued to pay dividends
in making it difficult to escape the Android Security Sandbox.
To keep our users' data safe
we introduced encryption of the user data partition.
We extended this to cover SD cards and invested a lot
to make it highly performant.
To protect our users' pass phrases and key material
we shrunk our data center Titan security chip
and added it to Pixel 3.
All Pixel devices since then have the security co-processor
that is distinct from the main CPU.
We made the underlying APIs available to the ecosystem
via the StrongBox HAL.
Recognizing that mobile devices are increasingly
the primary compute device for a large majority of our users
we made sure that beginning P
TLS is enabled by default for all outbound traffic.
We also made sure that all DNS lookups are done over TLS
so that rogue access points or middlemen cannot compromise
the user's DNS traffic.
Also in P, we introduced
end-to-end encrypted backups for Android.
This backup is encrypted with the key derived
from the user's primary lock screen credentials or password.
What this means, is that our users can now fully trust Google
with their stored backups
because we simply have no way to decrypt them.
Only the user owning the backup can decrypt on their device.
We continued our investment
in this core security infrastructure through Android Q.
We added Adiantum light-weight cryptography
for low-end devices
so that those users can also enjoy full disk encryption.
We believe that security and privacy should be accessible
to all devices and all users.
Security is a journey
and we try very hard to be disciplined about the things
that we add to the platform.
We find ways to implement an ounce of prevention
rather than struggle to do several pounds of cure.
We are very glad today
that Android is the most widely adopted and secure
personal computing OS.
Let's take a look at Android R
and what are some key security features we've invested in.
Over the past year
we've tried to make Android safe for our users out of the box.
Broadly, the work we've done fall into three buckets.
Hardening, safe by default
and finding new ways to enable new use cases.
Hardening the platform
to increase the cost of exploitation
and reducing the impact of vulnerabilities pays dividends
over and over again.
In addition to the various checks
we've added in the kernel and systems services
we've also made it difficult to leak persistent identifiers
that compromise user privacy.
We've significantly expanded coverage
of compiler-aided mitigations, such as control flow integrity
bounds sanitizer, in-sanitizers, etcetera
for several system services in the kernel.
We have started to look at various places
where the platform can adopt a more safe-by-default stance.
For example, we added one-time permissions for location
camera and microphone.
This is a huge win for users' privacy.
We've continued to invest in Project Mainline
to bring regular security updates
of the core platform components to the entire ecosystem.
In R, we've expanded coverage of Mainline
to include 12 new updatable modules.
For example, DNS Resolver, Neural Network API
Wi-Fi Stack Permissions Controller, etcetera.
We will continue to add more modules into Mainline
in the future, so that our users and their devices
are always up to date and safe.
Finally, security is often an invisible feature.
We only feel its impact when it fails.
This year, we've started to seek opportunities to make security
more visible to our users.
The platform today is safe enough
for us to begin thinking of our everyday experiences
and exploring which of those would be easier on a mobile.
When you think about building trust around a device's security stance
certifications are a great form of third-party validation.
Unfortunately, oftentimes these certifications fall
under what I like to call, the three C's.
Complexity, cost, and cumbersomeness.
For those not familiar with these certifications
Common Criteria on mobile device fundamental protection profile
is the most comprehensive
smartphone security certification in the world.
It is recognized in 31 countries
and it focuses on encryption, integrity, auditability, and control.
National Institute of Standards and Technology
has a standard called FIPS 140-2.
It's an evaluation of the cryptographic modules themselves
and is something that US public sector and numerous other regulated verticals
insist on having.
Finally, the US DOD Security Technology Implementation Guide
or STIG, is a guideline for how to deploy devices
on the US Department of Defense network.
Using Pixel as a reference implementation
we have been able to really streamline these certifications
for our OEM partners.
For example, for Common Criteria in Android 9 and 10
we have addressed a lot of the gaps
so an OEM should be able to go through this evaluation
without making any custom changes in the platform.
For FIPS, in Android 11
BoringCrypto as part of conscript
is now in process for FIPS 140-2.
If you're interested in leveraging this
you can piggyback off of our certification
for a very small cost, do a rebrand
and get your own certificate.
For DISA STIG, in the past, there were different STIGs
for different OEMs
but we worked very hard to unify this under a single Android STIG
so that OEMs can benefit
from not having to go through the STIG all by themselves.
To recap, over the last few years, we've been working hard
to address the three C's from our partners
which at the end of the day, I believe, helps all of us,
and most importantly, our customers.
The SafetyNet Attestation API is
an anti-abuse API that allows app developers
to assess the Android device that app is running on.
We encourage you to use this API as part of your abuse detection system
to help determine whether your servers are interacting
with your genuine app or running on a genuine Android device.
SafetyNet Attestation API is used by more than 350 million devices today.
We are seeing more than 800 million API calls per day.
And last year, we saw over 300 billion API calls.
Developers often use community forums on the internet
to implement common security constructs
such as file encryption.
We've discovered that there is a lot of incorrect cryptographic constructs
recommended by the community
many of whom are not cryptography experts.
We created the Jetpack Security Library to simplify these common workflows
and create opinionated, cryptographically secure constructs
for common operations.
We're very proud to announce the availability
of 1.0 release of our Jetpack Security Library.
Already we're seeing massive adoption of this library
by our developer community.
More than 6,000 developers are using this today
including major companies.
Beginning Android R, developers can use the BiometricPrompt API
to specify the type of authentication the app needs for unlocking
or accessing sensitive parts of the app.
But we'll soon add this to Jetpack
to make it easy for developers to incorporate BiometricPrompt
to their apps.
A big shout out to the Jetpack developers
for landing this important library.
We're excited to bring Identity Credential Capability to Android.
This will unlock new use cases
such as mobile driver's license, national ID, digital ID, etcetera.
Our Jetpack Security Library now has the APIs needed
for developing identity credential apps.
We are working with various government agencies
and industry partners to make this happen.
The point is
Android R is now ready
for such digital-first identity experience.
Let's take a look ahead and see
where else we're planning to continue
to continue to invest, so that we raise the security bar
for all Android devices.
We've heard loud and clear from all over the world
that users have concerns about preloaded software
and especially software
which has sensitive permissions pre-granted.
We're investigating the best way
to making the most secure and safe platform for our users.
And we're developing ways to reduce some of these risks
across the entire ecosystem.
A fundamental tenet of any security is transparency.
We're investing in a range of technologies
that will allow for independent verification
of a given system's integrity.
One of the major steps will be providing tools and infrastructure
to allow Android devices to be verified
as being identical to what OEMs ship.
This makes it easy to identify
supply chain attacks, and allow users to feel confident
in the integrity of the devices they use.
Many of you know about our efforts
in certificate transparency.
One of the building blocks was Project Trillion.
We're partnering with the Trillion team to build a similar public database
of system image cryptographic hashes.
Finally, we invest a lot of effort in hardening the system.
We believe that hardening is a fundamental Defense in Depth mechanism
from increasing use of SELinux's separate privileged apps
and to expanding compiler instrument hardening
across kernel and user space.
We're collaborating with our ecosystem partners
to bring hardware-backed hardening
via MTE Pack and VTI.
These newer hardware features available
in upcoming SoCs based on the Arm V9 architecture
have significant advantages in mitigating
common memory-related errors
and catch them before they become exploits.
As long as developers write code, there will be bugs.
Across the wider software industry
as much as 70% of the vulnerability reports are
directly tied to memory on safety
in traditional C, C++ programs.
We lost ourselves.
Can we make it difficult to introduce these sorts of common errors?
Can we make this entire class of errors go away?
We're excited to talk about Rust in Android today.
Rust is a relatively new systems-prone language
that promises to completely eliminate memory safety errors.
The language has features in it that make it very hard to write
incorrect programs
while running as-good-as or better than equivalent C++ code.
We believe that over time
Rust will become a game changer
for doing deep systems-level programming.
Rust today is a supported tool chain in Android
and over time, we will continue to invest in Rust
and see which system components are better off
being written in Rust.
We believe that Rust will end up fundamentally making the platform safe
for all of our users.
Thank you.