The state of Android Security Update | Google IO 2021

Hello and welcome to this year’s State of Android Security at I/O 2021. My name is Eugene Liderman. I’m part of the Android security and privacy team here at Google. In this session, we’ll provide a quick introduction to our team and our mission. Like every year, we’d like to share some statistics & efforts we think help measure the security of Android, followed by some of our big initiatives and new launches. Before diving into this year’s update, I wanted to discuss our mission and strategy. Our mission is to protect the billions of Android devices out there. Regardless if it’s a high-end device or a low-end device, our goal is to provide the same level of security. The Android security model relies on a Defense in Depth approach. In Android, you’ll find multiple independent layers of security architecture & mechanisms designed to work together seamlessly and effectively. Transparency is key to our philosophy. Android is open source. We publish a quarterly ecosystem transparency report and blog frequently about upcoming features and capabilities. Google has a tremendous team of security experts and privacy experts. The Android team partners with many of these experts when it comes to things like anti-phishing, account security, and many other initiatives. In 2020, we paid out 1.7 million in rewards as part of our Android vulnerability rewards program. In addition, the Google Play Security Rewards and the Developer Data Protection Rewards programs awarded over $270,000. While we’ve provided built-in anti-malware capabilities for years, in 2017, we officially branded our client side and backend anti-malware solution Google Play Protect. Google Play Protect scans over a hundred billion apps every day and leverages both static and dynamic analysis as well as machine learning and numerous other techniques to keep users safe. In 2020, we prevented 54,000 malicious applications from being published. Also, our machine learning detection capabilities and enhanced app review process prevented over 962,000 policy-violating application submissions from getting published to Google Play. In the first quarter of 2021, 95% of Android 11 devices were running a security update from the last 90 days. A lack of transparency results in a distrust and a deep sense of insecurity. As I mentioned earlier, transparency is at the heart of Android and specifically from a security perspective, we strongly believe that good transparency breeds trust. We’ve talked about how Android is open source, a great thing for the security community since they can assess and evaluate our implementation of various security capabilities. A great way to further build upon our transparency efforts is to go through an independent security evaluation, thus ensuring the independent authorities, not just Google or OEMs, are evaluating the security of Android and validating Android’s commitment in transparency and exploit mitigation. Some of these independent certifications are: common criteria mobile device fundamentals, which evaluates the cryptography, authentication, integrity and auditability that mobile devices provide. NIST FIPS 140-2, which evaluates cryptographic modules and the Department of Defense’s Security Technical Implementation Guide, which provides predefined guidelines on how a device gets deployed on a U.S. Department of Defense network. Over the last few years, we have been working diligently to implement the various security features and controls into the Android operating system. Last year we said we’ve been working hard to help our ecosystem. This year we’re happy to report not only were we able to get Pixel certified as a reference implementation faster than any other smartphone this year, our investment also helped numerous OEM partners complete some of these rigorous certifications as well. Many certification programs can be costly, cumbersome and complex, making it difficult for all vendors to participate. We’re excited to be one of the 300+ members participating in the Internet of Secure Things Alliance. The mission of the ioXt Alliance is to build confidence in internet-of-things products through multi-stakeholder international, harmonized, and standardized security and privacy requirements, product compliance programs, and public transparency of those requirements and programs. With so many companies involved, ioXt covers a wide range of devices including smart lighting, smart speakers, webcams, Android smartphones, and mobile applications. The goal of ioXt’s approach is to enable consumers, enterprises and other stakeholders to understand the security and connected products to drive better awareness towards how these products are protecting the security and privacy of users. ioXt focuses on eight pledge items split across three pillars: security, upgradability, and transparency. We commend the ioXt Alliance and its members, including a wide range of Android device manufacturers and mobile app developers who have begun the process of regularly certifying against ioXt security and privacy standards. All major operating systems in use today leverage a large amount of C/C++ for its implementation. The OS implementation language is completely distinct from the language supported by app developers for Android that’s primarily Java and Kotlin. Most vulnerabilities in these operating systems are caused by memory errors, such as buffer overflows, due to the lack of memory safety built into C/C++. Rust is a rapidly growing language that provides efficiency and flexibility required by systems programming but with a huge boost of memory safety. While it is not practical to simply translate all existing OS code into Rust, Android has embarked on a multi-year effort to introduce Rust into the most sensitive areas of Android and over time, convert more and more of C++ implementations to Rust. For Android 12, the critical Android Keystore component was completely rewritten in Rust. Google has integrated Rust tools and C++ interoperability bridges into Android letting Android device manufacturers to use Rust for their own Android systems programming needs. You can’t spell trust without Rust. Over time, as the use of Rust expands across Linux and Android, we expect that the impact in vulnerability reduction will be massive. There also remains a constant need to improve production runtime memory error detection. Capabilities like ASAN have been an Android production for some time, but they can only be used sparingly due to their performance overhead. KFence is a new Linux memory safety capability that uses sampling of kernel heat to detect memory errors. KFence provides important error detection mitigation while ensuring near-zero performance overheads, specifically tuned for production environments. Android 12 incorporates Linux KFence support. As mobile devices are used for increasingly sensitive functions like banking and digital keys to open doors, many of these functions benefit from the enhanced physical security provided by Secure Elements. Even if an attacker has physical possession of your device, the SE provides state-of-the-art protection against both logical and physical attacks. Secure Elements are common on flagship devices, such as Titan M and Pixel, but have been mostly absent from low-cost devices. Android Ready SE enables Android device manufacturers to choose and more easily integrate SEs for a wide range of Secure Element products that support Android APIs that leverage this form of advanced physical security. For example, Android APIs enable bank, healthcare, gaming, and other app developers to store keys in the SE by declaring the key as an Android StrongBox key. And Android Ready SEs already support StrongBox protocol natively. In the future, Android Ready SE will come with off-the-shelf applets for additional Android functions, such as digital car key APIs developed by the Car Connectivity Consortium and mobile driver’s license credential APIs following the ISO specification. For each Android release, we look at what we can do to help our developers utilize great new features in Android. For Android 12, we’ve released the following new and updated Jetpack security libraries. Jetpack Security Crypto, or JetSec, is now 1.0. it provides developers with drop-in safe-to-use implementations for encrypting files and shared preferences. App-to-app authentication assists developers with multiple apps handling the trust chain in a safe manner, simply specifying XML configuration file, including the signatures of the apps that are trusted, and app-to-app authentication handles the rest. Identity Credential implements the ISO standard for mDL or mobile driver’s license for long. Alpha 02 has been released, which provides developers with a fully compatible implementation of Part 5 of ISO 1830-5 mDL standard. We also plan to release a native Jetpack Security Keystore library to provide lower level Android Keystore access for developers, which includes error handling hints on how to deal with lower level exceptions, implementations of commonly used features such as encryption, signatures, HMAC, and more, including support for Jetpack Biometric Prompt, Crypto object-level Keystore authorizations. With the new Keystore library, an encrypted DataStore extension will be available for the new data store Jetpack library. Jetpack Security is a great example of how we’re trying to make it easier for Android developers to build secure apps. We also provide numerous other security APIs, such as SafetyNet Attestation, which is an anti-abuse API that allows app developers to assess the Android device the app is running on; SafetyNet Safe Browsing, which enables app developers to implement our anti-phishing safe browsing technology into their mobile applications. And recently we also announced the Perspective API, a free product offered by Jigsaw which uses machine learning to identify toxic language like insults and profanity or identity-based attacks, making it easier to host healthier conversations in your apps. With every Android release we also introduced new security-oriented platform APIs. For example, to give developers more control over what users see when they interact with the developer’s apps, Android 12 introduces the ability to hide overlay windows for apps that have been granted the system alert window permission. Android 12 also adds new set authentication required flag to Notification.Action.Builder. This flag lets you add extra granular layer of security to notifications on locked devices. This concludes this year’s State of Android Security update. Please look at some of our resources such as our brand new Security by Design Play Academy courses, as well as our security best practices checklist. Thank you for watching and enjoy the rest of I/O 2021.

Leave a Reply

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

Sundar Pichai's Notifications    Yes No thanks