Archive for August, 2018

Introducing the Tink cryptographic software library

August 30th, 2018


At Google, many product teams use cryptographic techniques to protect user data. In cryptography, subtle mistakes can have serious consequences, and understanding how to implement cryptography correctly requires digesting decades' worth of academic literature. Needless to say, many developers don’t have time for that.

To help our developers ship secure cryptographic code we’ve developed Tink—a multi-language, cross-platform cryptographic library. We believe in open source and want Tink to become a community project—thus Tink has been available on GitHub since the early days of the project, and it has already attracted several external contributors. At Google, Tink is already being used to secure data of many products such as AdMob, Google Pay, Google Assistant, Firebase, the Android Search App, etc. After nearly two years of development, today we’re excited to announce Tink 1.2.0, the first version that supports cloud, Android, iOS, and more!

Tink aims to provide cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Tink is built on top of existing libraries such as BoringSSL and Java Cryptography Architecture, but includes countermeasures to many weaknesses in these libraries, which were discovered by Project Wycheproof, another project from our team.

With Tink, many common cryptographic operations such as data encryption, digital signatures, etc. can be done with only a few lines of code. Here is an example of encrypting and decrypting with our AEAD interface in Java:

import com.google.crypto.tink.Aead;
   import com.google.crypto.tink.KeysetHandle;
   import com.google.crypto.tink.aead.AeadFactory;
   import com.google.crypto.tink.aead.AeadKeyTemplates;


   // 1. Generate the key material.
   KeysetHandle keysetHandle = KeysetHandle.generateNew(
       AeadKeyTemplates.AES256_EAX);


   // 2. Get the primitive.
   Aead aead = AeadFactory.getPrimitive(keysetHandle);


   // 3. Use the primitive.
   byte[] plaintext = ...;
   byte[] additionalData = ...;
   byte[] ciphertext = aead.encrypt(plaintext, additionalData);

Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and nonce reuse makes it insecure, then Tink does not allow the user to pass nonces. Interfaces have security guarantees that must be satisfied by each primitive implementing the interface. This may exclude some encryption modes. Rather than adding them to existing interfaces and weakening the guarantees of the interface, it is possible to add new interfaces and describe the security guarantees appropriately.

We’re cryptographers and security engineers working to improve Google’s product security, so we built Tink to make our job easier. Tink shows the claimed security properties (e.g., safe against chosen-ciphertext attacks) right in the interfaces, allowing security auditors and automated tools to quickly discover usages where the security guarantees don’t match the security requirements. Tink also isolates APIs for potentially dangerous operations (e.g., loading cleartext keys from disk), which allows discovering, restricting, monitoring and logging their usage.

Tink provides support for key management, including key rotation and phasing out deprecated ciphers. For example, if a cryptographic primitive is found to be broken, you can switch to a different primitive by rotating keys, without changing or recompiling code.

Tink is also extensible by design: it is easy to add a custom cryptographic scheme or an in-house key management system so that it works seamlessly with other parts of Tink. No part of Tink is hard to replace or remove. All components are composable, and can be selected and assembled in various combinations. For example, if you need only digital signatures, you can exclude symmetric key encryption components to minimize code size in your application.

To get started, please check out our HOW-TO for Java, C++ and Obj-C. If you'd like to talk to the developers or get notified about project updates, you may want to subscribe to our mailing list. To join, simply send an empty email to tink-users+subscribe@googlegroups.com. You can also post your questions to StackOverflow, just remember to tag them with tink.

We’re excited to share this with the community, and welcome your feedback!

Posted in Uncategorized | Comments (0)

Evolution of Android Security Updates

August 22nd, 2018


[Cross-posted from the Android Developers Blog]

At Google I/O 2018, in our What's New in Android Security session, we shared a brief update on the Android security updates program. With the official release of Android 9 Pie, we wanted to share a more comprehensive update on the state of security updates, including best practice guidance for manufacturers, how we're making Android easier to update, and how we're ensuring compliance to Android security update releases.

Commercial Best Practices around Android Security Updates

As we noted in our 2017 Android Security Year-in-Review, Android's anti-exploitation strength now leads the mobile industry and has made it exceedingly difficult and expensive to leverage operating system bugs into compromises. Nevertheless, an important defense-in-depth strategy is to ensure critical security updates are delivered in a timely manner. Monthly security updates are the recommended best practice for Android smartphones. We deliver monthly Android source code patches to smartphone manufacturers so they may incorporate those patches into firmware updates. We also deliver firmware updates over-the-air to Pixel devices on a reliable monthly cadence and offer the free use of Google's firmware over-the-air (FOTA) servers to manufacturers. Monthly security updates are also required for devices covered under the Android One program.
While monthly security updates are best, at minimum, Android manufacturers should deliver regular security updates in advance of coordinated disclosure of high severity vulnerabilities, published in our Android bulletins. Since the common vulnerability disclosure window is 90 days, updates on a 90-day frequency represents a minimum security hygiene requirement.

Enterprise Best Practices

Product security factors into purchase decisions of enterprises, who often consider device security update cadence, flexibility of policy controls, and authentication features. Earlier this year, we introduced the Android Enterprise Recommended program to help businesses make these decisions. To be listed, Android devices must satisfy numerous requirements, including regular security updates: at least every 90 days, with monthly updates strongly recommended. In addition to businesses, consumers interested in understanding security update practices and commitment may also refer to the Enterprise Recommended list.

Making Android Easier to Update

We've also been working to make Android easier to update, overall. A key pillar of that strategy is to improve modularity and clarity of interfaces, enabling operating system subsystems to be updated without adversely impacting others. Project Treble is one example of this strategy in action and has enabled devices to update to Android P more easily and efficiently than was possible in previous releases. The modularity strategy applies equally well for security updates, as a framework security update can be performed independently of device specific components.
Another part of the strategy involves the extraction of operating system services into user-mode applications that can be updated independently, and sometimes more rapidly, than the base operating system. For example, Google Play services, including secure networking components, and the Chrome browser can be updated individually, just like other Google Play apps.
Partner programs are a third key pillar of the updateability strategy. One example is the GMS Express program, in which Google is working closely with system-on-chip (SoC) suppliers to provide monthly pre-integrated and pre-tested Android security updates for SoC reference designs, reducing cost and time to market for delivering them to users.

Security Patch Level Compliance

Recently, researchers reported a handful of missing security bug fixes across some Android devices. Initial reports had several inaccuracies, which have since been corrected. We have been developing security update testing systems that are now making compliance failures less likely to occur. In particular, we recently delivered a new testing infrastructure that enables manufacturers to develop and deploy automated tests across lower levels of the firmware stack that were previously relegated to manual testing. In addition, the Android build approval process now includes scanning of device images for specific patterns, reducing the risk of omission.

Looking Forward

In 2017, about a billion Android devices received security updates, representing approximately 30% growth over the preceding year. We continue to work hard devising thoughtful strategies to make Android easier to update by introducing improved processes and programs for the ecosystem. In addition, we are also working to drive increased and more expedient partner adoption of our security update and compliance requirements. As a result, over coming quarters, we expect the largest ever growth in the number of Android devices receiving regular security updates.
Bugs are inevitable in all complex software systems, but exploitability of those bugs is not. We're working hard to ensure that the incidence of potentially harmful exploitation of bugs continues to decline, such that the frequency for security updates will reduce, not increase, over time. While monthly security updates represents today's best practice, we see a future in which security updates becomes easier and rarer, while maintaining the same goal to protect all users across all devices.

Posted in Android Security | Comments (0)

A reminder about government-backed phishing

August 20th, 2018


TLDR: Government-backed phishing has been in the news lately. If you receive a warning in Gmail, be sure to take prompt action. Get two-factor authentication on your account. And consider enrolling in the Advanced Protection Program.

One of the main threats to all email users (whatever service you use) is phishing, attempts to trick you into providing a password that an attacker can use to sign into your account. Our ​improving ​technology has enabled ​us to ​significantly ​decrease ​the ​volume ​of ​phishing ​emails that ​get ​through to our users. ​ Automated ​protections, ​account ​security ​(like ​security ​keys), ​and specialized ​warnings give ​Gmail users industry-leading ​security.

Beyond phishing for the purposes of fraud, a small minority of users in all corners of the world are still targeted by sophisticated government-backed attackers. These attempts come from dozens of countries. Since 2012, we've shown prominent warnings within Gmail notifying users that they may be targets of these types of phishing attempts; we show thousands of these warnings every month, even if we have blocked the specific attempt.

We also send alerts to G Suite administrators if someone in their corporate network may have been the target of government-backed phishing. And we regularly post public advisories to make sure that people are aware of this risk.

This is what an account warning looks like; an extremely small fraction of users will ever see one of these, but if you receive this warning from us, it's important to take immediate action on it.
We intentionally send these notices in batches to all users who may be at risk, rather than at the moment we detect the threat itself, so that attackers cannot track some of our defense strategies. We have an expert team in our Threat Analysis Group, and we use a variety of technologies to detect these attempts. We also notify law enforcement about what we’re seeing; they have additional tools to investigate these attacks.

We hope you never receive this type of warning, but if you do, please take action right away to enhance the security of your accounts.

Even if you don’t receive such a warning, you should enable 2-step verification in Gmail. And if you think you’re at particular risk of government-backed phishing, consider enrolling in the Advanced Protection Program, which provides even stronger levels of security.

Posted in Uncategorized | Comments (0)

Expanding our Vulnerability Reward Program to combat platform abuse

August 15th, 2018


Since 2010, Google’s Vulnerability Reward Programs have awarded more than $12 million dollars to researchers and created a thriving Google-focused security community. For the past two years, some of these rewards were for bug reports that were not strictly security vulnerabilities, but techniques that allow third parties to successfully bypass our abuse, fraud, and spam systems.

Today, we are expanding our Vulnerability Reward Program to formally invite researchers to submit these reports.

This expansion is intended to reward research that helps us mitigate potential abuse methods. A few examples of potentially valid reports for this program could include bypassing our account recovery systems at scale, identifying services vulnerable to brute force attacks, circumventing restrictions on content use and sharing, or purchasing items from Google without paying. Valid reports tend to result in changes to the product’s code, as opposed to removal of individual pieces of content.

This program does not cover individual instances of abuse, such as the posting of content that violates our guidelines or policies, sending spam emails, or providing links to malware. These should continue to be reported through existing product-specific channels, such as for Google+, YouTube, Gmail, and Blogger.

Reports submitted to our Vulnerability Reward Program that outline abuse methods are reviewed by experts on our Trust & Safety team, which specializes in the prevention and mitigation of abuse, fraud, and spam activity on our products.

We greatly value our relationship with the research community, and we’re excited to expand on it to help make the internet a safer place for everyone. To learn more, see our updated rules.

Happy hunting!

Posted in Uncategorized | Comments (0)