Google Security Blog

How we fought bad apps and malicious developers in 2018

Google Security Blog - Wed, 02/13/2019 - 3:16pm

Posted by Andrew Ahn, Product Manager, Google Play
[Cross-posted from the Android Developers Blog]

Google Play is committed to providing a secure and safe platform for billions of Android users on their journey discovering and experiencing the apps they love and enjoy. To deliver against this commitment, we worked last year to improve our abuse detection technologies and systems, and significantly increased our team of product managers, engineers, policy experts, and operations leaders to fight against bad actors.
In 2018, we introduced a series of new policies to protect users from new abuse trends, detected and removed malicious developers faster, and stopped more malicious apps from entering the Google Play Store than ever before. The number of rejected app submissions increased by more than 55 percent, and we increased app suspensions by more than 66 percent. These increases can be attributed to our continued efforts to tighten policies to reduce the number of harmful apps on the Play Store, as well as our investments in automated protections and human review processes that play critical roles in identifying and enforcing on bad apps.
In addition to identifying and stopping bad apps from entering the Play Store, our Google Play Protect system now scans over 50 billion apps on users' devices each day to make sure apps installed on the device aren't behaving in harmful ways. With such protection, apps from Google Play are eight times less likely to harm a user's device than Android apps from other sources.
Here are some areas we've been focusing on in the last year and that will continue to be a priority for us in 2019:
Protecting User PrivacyProtecting users' data and privacy is a critical factor in building user trust. We've long required developers to limit their device permission requests to what's necessary to provide the features of an app. Also, to help users understand how their data is being used, we've required developers to provide prominent disclosures about the collection and use of sensitive user data. Last year, we rejected or removed tens of thousands of apps that weren't in compliance with Play's policies related to user data and privacy.
In October 2018, we announced a new policy restricting the use of the SMS and Call Log permissions to a limited number of cases, such as where an app has been selected as the user's default app for making calls or sending text messages. We've recently started to remove apps from Google Play that violate this policy. We plan to introduce additional policies for device permissions and user data throughout 2019.
Developer integrityWe find that over 80% of severe policy violations are conducted by repeat offenders and abusive developer networks. When malicious developers are banned, they often create new accounts or buy developer accounts on the black market in order to come back to Google Play. We've further enhanced our clustering and account matching technologies, and by combining these technologies with the expertise of our human reviewers, we've made it more difficult for spammy developer networks to gain installs by blocking their apps from being published in the first place.
Harmful app contents and behaviorsAs mentioned in last year's blog post, we fought against hundreds of thousands of impersonators, apps with inappropriate content, and Potentially Harmful Applications (PHAs). In a continued fight against these types of apps, not only do we apply advanced machine learning models to spot suspicious apps, we also conduct static and dynamic analyses, intelligently use user engagement and feedback data, and leverage skilled human reviews, which have helped in finding more bad apps with higher accuracy and efficiency.
Despite our enhanced and added layers of defense against bad apps, we know bad actors will continue to try to evade our systems by changing their tactics and cloaking bad behaviors. We will continue to enhance our capabilities to counter such adversarial behavior, and work relentlessly to provide our users with a secure and safe app store.
How useful did you find this blog post?


Categories: Google Security Blog

Open sourcing ClusterFuzz

Google Security Blog - Thu, 02/07/2019 - 4:00pm
Posted by Abhishek Arya, Oliver Chang, Max Moroz, Martin Barbella and Jonathan Metzman (ClusterFuzz team)

[Cross-posted from the Google Open-Source Blog]

Fuzzing is an automated method for detecting bugs in software that works by feeding unexpected inputs to a target program. It is effective at finding memory corruption bugs, which often have serious security implications. Manually finding these issues is both difficult and time consuming, and bugs often slip through despite rigorous code review practices. For software projects written in an unsafe language such as C or C++, fuzzing is a crucial part of ensuring their security and stability.

In order for fuzzing to be truly effective, it must be continuous, done at scale, and integrated into the development process of a software project. To provide these features for Chrome, we wrote ClusterFuzz, a fuzzing infrastructure running on over 25,000 cores. Two years ago, we began offering ClusterFuzz as a free service to open source projects through OSS-Fuzz.

Today, we’re announcing that ClusterFuzz is now open source and available for anyone to use.
We developed ClusterFuzz over eight years to fit seamlessly into developer workflows, and to make it dead simple to find bugs and get them fixed. ClusterFuzz provides end-to-end automation, from bug detection, to triage (accurate deduplication, bisection), to bug reporting, and finally to automatic closure of bug reports.

ClusterFuzz has found more than 16,000 bugs in Chrome and more than 11,000 bugs in over 160 open source projects integrated with OSS-Fuzz. It is an integral part of the development process of Chrome and many other open source projects. ClusterFuzz is often able to detect bugs hours after they are introduced and verify the fix within a day.

Check out our GitHub repository. You can try ClusterFuzz locally by following these instructions. In production, ClusterFuzz depends on some key Google Cloud Platform services, but you can use your own compute cluster. We welcome your contributions and look forward to any suggestions to help improve and extend this infrastructure. Through open sourcing ClusterFuzz, we hope to encourage all software developers to integrate fuzzing into their workflows.
Categories: Google Security Blog

Introducing Adiantum: Encryption for the Next Billion Users

Google Security Blog - Thu, 02/07/2019 - 12:00pm
Posted by Paul Crowley and Eric Biggers, Android Security & Privacy Team

Storage encryption protects your data if your phone falls into someone else's hands. Adiantum is an innovation in cryptography designed to make storage encryption more efficient for devices without cryptographic acceleration, to ensure that all devices can be encrypted.
Today, Android offers storage encryption using the Advanced Encryption Standard (AES). Most new Android devices have hardware support for AES via the ARMv8 Cryptography Extensions. However, Android runs on a wide range of devices. This includes not just the latest flagship and mid-range phones, but also entry-level Android Go phones sold primarily in developing countries, along with smart watches and TVs. In order to offer low cost options, device manufacturers sometimes use low-end processors such as the ARM Cortex-A7, which does not have hardware support for AES. On these devices, AES is so slow that it would result in a poor user experience; apps would take much longer to launch, and the device would generally feel much slower. So while storage encryption has been required for most devices since Android 6.0 in 2015, devices with poor AES performance (50 MiB/s and below) are exempt. We've been working to change this because we believe that encryption is for everyone.
In HTTPS encryption, this is a solved problem. The ChaCha20 stream cipher is much faster than AES when hardware acceleration is unavailable, while also being extremely secure. It is fast because it exclusively relies on operations that all CPUs natively support: additions, rotations, and XORs. For this reason, in 2014 Google selected ChaCha20 along with the Poly1305 authenticator, which is also fast in software, for a new TLS cipher suite to secure HTTPS internet connections. ChaCha20-Poly1305 has been standardized as RFC7539, and it greatly improves HTTPS performance on devices that lack AES instructions.
However, disk and file encryption present a special challenge. Data on storage devices is organized into "sectors" which today are typically 4096 bytes. When the filesystem makes a request to the device to read or write a sector, the encryption layer intercepts that request and converts between plaintext and ciphertext. This means that we must convert between a 4096-byte plaintext and a 4096-byte ciphertext. But to use RFC7539, the ciphertext must be slightly larger than the plaintext; a little space is needed for the cryptographic nonce and message integrity information. There are software techniques for finding places to store this extra information, but they reduce efficiency and can impose significant complexity on filesystem design.
Where AES is used, the conventional solution for disk encryption is to use the XTS or CBC-ESSIV modes of operation, which are length-preserving. Currently Android supports AES-128-CBC-ESSIV for full-disk encryption and AES-256-XTS for file-based encryption. However, when AES performance is insufficient there is no widely accepted alternative that has sufficient performance on lower-end ARM processors.
To solve this problem, we have designed a new encryption mode called Adiantum. Adiantum allows us to use the ChaCha stream cipher in a length-preserving mode, by adapting ideas from AES-based proposals for length-preserving encryption such as HCTR and HCH. On ARM Cortex-A7, Adiantum encryption and decryption on 4096-byte sectors is about 10.6 cycles per byte, around 5x faster than AES-256-XTS.
Unlike modes such as XTS or CBC-ESSIV, Adiantum is a true wide-block mode: changing any bit anywhere in the plaintext will unrecognizably change all of the ciphertext, and vice versa. It works by first hashing almost the entire plaintext using a keyed hash based on Poly1305 and another very fast keyed hashing function called NH. We also hash a value called the "tweak" which is used to ensure that different sectors are encrypted differently. This hash is then used to generate a nonce for the ChaCha encryption. After encryption, we hash again, so that we have the same strength in the decryption direction as the encryption direction. This is arranged in a configuration known as a Feistel network, so that we can decrypt what we've encrypted. A single AES-256 invocation on a 16-byte block is also required, but for 4096-byte inputs this part is not performance-critical.
Cryptographic primitives like ChaCha are organized in "rounds", with each round increasing our confidence in security at a cost in speed. To make disk encryption fast enough on the widest range of devices, we've opted to use the 12-round variant of ChaCha rather than the more widely used 20-round variant. Each round vastly increases the difficulty of attack; the 7-round variant was broken in 2008, and though many papers have improved on this attack, no attack on 8 rounds is known today. This ratio of rounds used to rounds broken today is actually better for ChaCha12 than it is for AES-256.
Even though Adiantum is very new, we are in a position to have high confidence in its security. In our paper, we prove that it has good security properties, under the assumption that ChaCha12 and AES-256 are secure. This is standard practice in cryptography; from "primitives" like ChaCha and AES, we build "constructions" like XTS, GCM, or Adiantum. Very often we can offer strong arguments but not a proof that the primitives are secure, while we can prove that if the primitives are secure, the constructions we build from them are too. We don't have to make assumptions about NH or the Poly1305 hash function; these are proven to have the cryptographic property ("ε-almost-∆-universality") we rely on.
Adiantum is named after the genus of the maidenhair fern, which in the Victorian language of flowers (floriography) represents sincerity and discretion.
Additional resourcesThe full details of our design, and the proof of security, are in our paper Adiantum: length-preserving encryption for entry-level processors in IACR Transactions on Symmetric Cryptology; this will be presented at the Fast Software Encryption conference (FSE 2019) in March.
Generic and ARM-optimized implementations of Adiantum are available in the Android common kernels v4.9 and higher, and in the mainline Linux kernel v5.0 and higher. Reference code, test vectors, and a benchmarking suite are available at https://github.com/google/adiantum.
Android device manufacturers can enable Adiantum for either full-disk or file-based encryption on devices with AES performance <= 50 MiB/sec and launching with Android Pie. Where hardware support for AES exists, AES is faster than Adiantum; AES must still be used where its performance is above 50 MiB/s. In Android Q, Adiantum will be part of the Android platform, and we intend to update the Android Compatibility Definition Document (CDD) to require that all new Android devices be encrypted using one of the allowed encryption algorithms.

Acknowledgements: This post leveraged contributions from Greg Kaiser and Luke Haviland. Adiantum was designed by Paul Crowley and Eric Biggers, implemented in Android by Eric Biggers and Greg Kaiser, and named by Danielle Roberts.
Categories: Google Security Blog

Protect your accounts from data breaches with Password Checkup

Google Security Blog - Wed, 02/06/2019 - 8:59pm
Posted by Jennifer Pullman, Kurt Thomas, and Elie Bursztein, Security and Anti-abuse research

Update (Feb 6): We have updated the post to clarify a protocol used in the design is centered around private set intersection.

Google helps keep your account safe from hijacking with a defense in depth strategy that spans prevention, detection, and mitigation. As part of this, we regularly reset the passwords of Google accounts affected by third-party data breaches in the event of password reuse. This strategy has helped us protect over 110 million users in the last two years alone. Without these safety measures, users would be at ten times the risk of account hijacking.

We want to help you stay safe not just on Google, but elsewhere on the web as well. This is where the new Password Checkup Chrome extension can help. Whenever you sign in to a site, Password Checkup will trigger a warning if the username and password you use is one of over 4 billion credentials that Google knows to be unsafe.

Password Checkup was designed jointly with cryptography experts at Stanford University to ensure that Google never learns your username or password, and that any breach data stays safe from wider exposure. Since Password Checkup is an early experiment, we’re sharing the technical details behind our privacy preserving protocol to be transparent about how we keep your data secure.

Key design principles

We designed Password Checkup with three key principles in mind:

  • Alerts are actionable, not informational: We believe that an alert should provide concise and accurate security advice. For an unsafe account, that means resetting your password. While it’s possible for data breaches to expose other personal data such as a phone number or mailing address, there’s no straightforward next step to re-securing that data. That’s why we focus only on warning you about unsafe usernames and passwords.
  • Privacy is at the heart of our design: Your usernames and passwords are incredibly sensitive. We designed Password Checkup with privacy-preserving technologies to never reveal this personal information to Google. We also designed Password Checkup to prevent an attacker from abusing Password Checkup to reveal unsafe usernames and passwords. Finally, all statistics reported by the extension are anonymous. These metrics include the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the web domain involved for improving site compatibility.
  • Advice that avoids fatigue: We designed Password Checkup to only alert you when all of the information necessary to access your account has fallen into the hands of an attacker. We won’t bother you about outdated passwords you’ve already reset or merely weak passwords like “123456”. We only generate an alert when both your current username and password appear in a breach, as that poses the greatest risk.
Settling on an approach
At a high level, Password Checkup needs to query Google about the breach status of a username and password without revealing the information queried. At the same time, we need to ensure that no information about other unsafe usernames or passwords leaks in the process, and that brute force guessing is not an option. Password Checkup addresses all of these requirements by using multiple rounds of hashing, k-anonymity, and private set intersection with blinding.
Our approach strikes a balance between privacy, computation overhead, and network latency. While single-party private information retrieval (PIR) and 1-out-of-N oblivious transfer solve some of our requirements, the communication overhead involved for a database of over 4 billion records is presently intractable. Alternatively, k-party PIR and hardware enclaves present efficient alternatives, but they require user trust in schemes that are not widely deployed yet in practice. For k-party PIR, there is a risk of collusion; for enclaves, there is a risk of hardware vulnerabilities and side-channels.
A look under the hood
Here’s how Password Checkup works in practice to satisfy our security and privacy requirements.


Protecting your accounts
Password Checkup is currently available as an extension for Chrome. Since this is a first version, we will continue refining it over the coming months, including improving site compatibility and username and password field detection.
Acknowledgements
This post reflects the work of a large group of Google engineers, research scientists, and others including: Niti Arora, Jacob Barrett, Borbala Benko, Alan Butler, Abhi Chaudhuri, Oxana Comanescu, Sunny Consolvo, Michael Dedrick, Kyler Emig, Mihaela Ion, Ilona Gaweda, Luca Invernizzi, Jozef Janovský, Yu Jiang, Patrick Gage Kelly, Nirdhar Khazanie, Guemmy Kim, Ben Kreuter, Valentina Lapteva, Maija Marincenko, Grzegorz Milka, Angelika Moscicki, Julia Nalven, Yuan Niu, Sarvar Patel, Tadek Pietraszek, Ganbayar Puntsagdash, Ananth Raghunathan, Juri Ranieri, Mark Risher, Masaru Sato, Karn Seth, Juho Snellman, Eduardo Tejada, Tu Tsao, Andy Wen, Kevin Yeo, Moti Yung, and Ali Zand.
Categories: Google Security Blog