Continuing to Raise the Bar for Verifiable Security on Pixel

Threats	Mitigations
Network Eavesdropping – An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure Network Attack – An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure	Protected Communications – Standard protocols such as IPsec, DTLS, TLS, HTTPS, and Bluetooth to ensure encrypted communications are secure Authorization and Authentication – Secure authentication for networks and backends Mobile Device Configuration – Capabilities for configuring and applying security policies defined by the user and/or Enterprise Administrator
Physical Access – An attacker, with physical access, may attempt to retrieve user data on the mobile device, including credentials	Protected Storage – Secure storage (that is, encryption of data-at-rest) for data contained on the device  Authorization and Authentication – Secure device authentication using a known unlock factor, such as a password, PIN, fingerprint, or face authentication
Malicious or Flawed Application – Applications loaded onto the Mobile Device may include malicious or exploitable code	Protected Communications – Standard protocols such as IPsec, DTLS, TLS, HTTPS, and Bluetooth to ensure encrypted communications are secure Authorization and Authentication – Secure authentication for networks and backends Mobile Device Configuration – Capabilities for configuring and applying security policies defined by the user and/or Enterprise Administrator Mobile Device Integrity – Device integrity for critical functionality of both software and hardware End User Privacy and Device Functionality – Application isolation/sandboxing and framework permissions provide separation and privacy between user activities
Persistent Presence – Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it	Mobile Device Integrity – Device integrity to ensure the integrity of critical functionality of both software and hardware is maintained End User Privacy and Device Functionality – Application isolation/sandboxing and framework permissions provide separation and privacy between user activities

What makes this certification important is the fact that it is a hands on evaluation done by an authorized lab to evaluate the device and perform a variety of tests to ensure that:

1. Every mitigation meets a predefined standard and set of criteria.
2. Every mitigation works as advertised.

At a high level, the target of evaluation (TOE) is the combination of device hardware (i.e. system on chip) and operating system (i.e. Android). In order to validate our mitigations for the threats listed above, the lab looks at the following security functionality:

• Protected Communications (encryption of data-in-transit) – Cryptographic algorithms and transport protocols used to encrypt the Wi-Fi traffic and all other network operations and communications.
• Protected Storage (encryption of data-at-rest) – Cryptography provided by the system on chip, trusted execution environment, and any other discrete tamper resistant hardware such as the Titan M and the Android OS. Specifically looking at things like implementation of file-based encryption, hardware root of trust, keystore operations (such as, key generation), key storage, key destruction, and key hierarchy.
• Authorization and Authentication – Mechanisms for unlocking the user’s devices, such as password, PIN or Biometric. Mitigation techniques like rate limiting and for biometrics, False Acceptance and Spoof Acceptance Rates.
• Mobile Device Integrity – Android’s implementation of Verified Boot, Google Play System Updates, and Seamless OS Updates.
• Auditability – Features that allow a user or IT admin to log events such as device start-up and shutdown, data encryption, data decryption, and key management.
• Mobile Device Configuration – Capabilities that allow the user or enterprise admin to apply security policies to the device using Android Enterprise.

Why this is important for enterprises

It’s incredibly important to ensure Pixel security can specifically support enterprise needs. Many regulated industries require the use of Common Criteria certified devices to ensure that sensitive data is backed by the strongest possible protections. The Android Enterprise management framework enables enterprises to do things like control devices by setting restrictions around what the end user can do and audit devices to ensure all software settings are configured properly. For example, enterprise IT admins wish to enforce policies for features like the camera, location services or app installation process.

Why this is important for consumers

Security isn’t just an enterprise concern and many of the protections validated by Common Criteria certification apply to consumers as well. For example, when you’re connecting to Wi-Fi, you want to ensure no one can spy on your web browsing. If your device is lost or stolen, you want to be confident that your lock screen can reduce the chances of someone accessing your personal information.

We believe in making security & privacy accessible to all of our users. This is why we take care to ensure that Pixel devices meet or exceed these certification standards.. We’re committed to meeting these standards moving forward, so you can rest assured that your Pixel phone comes with top-of-the-line security built in, from the moment you turn it on.

Why this is important to the Android Ecosystem

While certifications are a great form of third party validation, they often fall under what we like to call the 3 C’s:

• Complex – Due to the scope of the evaluation including the device hardware, the operating system and everything in between.
• Costly – Because they require a hands on evaluation by a certified lab for every make/model combination (SoC + OS) which equates to hundreds of individual tests.
• Cumbersome – Because it’s a fairly lengthy evaluation process that can take upwards of 18 months the first time you go through it.

We have been working these last three years to reduce this complexity for our OEM partners. We are excited to tell you that the features required to satisfy the necessary security requirements are baked directly into the Android Open Source Project. We’ve also added all of the management and auditability requirements into the Android Enterprise Management framework. Last year we started publishing the tools we have developed for this on GitHub to allow other Android OEMs to take advantage of our efforts as they go through their certification.

While we continue certifying Pixel smartphones with new Android OS versions, we have worked to enable other Android OEMs to achieve this certification as well as others, such as:

• National Institute of Technology’s Cryptographic Algorithm and Module Validation Programs which is an evaluation of the cryptographic algorithms and/or modules and is something the US Public Sector and numerous other regulated verticals look for. With Android 11, BoringSSL which is part of the conscrypt mainline module has completed this validation (Certificate #3753)
• US Department of Defense’s Security Technical Implementation Guide; STIG for short is a guideline for how to deploy technology on a US Department of Defense network. In the past there were different STIGs for different Android OEMs which had their own implementations and proprietary controls, but thanks to our efforts we are now unifying this under a single Android STIG template so that Android OEMs don’t have to go through the burden of building custom controls to satisfy the various requirements.

We’ll continue to invest in additional ways to measure security for both enterprises and consumers, and we welcome the industry to join us in this effort.