Security Blog
The latest news and insights from Google on security and safety on the Internet
Introducing the Tink cryptographic software library
August 30, 2018
Posted by Thai Duong, Information Security Engineer, on behalf of Tink team
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!
Evolution of Android Security Updates
August 22, 2018
Posted by Dave Kleidermacher, VP, Head of Security - Android, Chrome OS, Play
[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.
A reminder about government-backed phishing
August 20, 2018
Posted by Shane Huntley, Threat Analysis Group
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.
Expanding our Vulnerability Reward Program to combat platform abuse
August 15, 2018
Posted by Eric Brown and Marc Henson, Trust & Safety
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!
Google Public DNS turns 8.8.8.8 years old
August 10, 2018
Posted by Alexander Dupuy, Software Engineer
Once upon a time, we
launched Google Public DNS
, which you might know by its iconic IP address, 8.8.8.8. (Sunday, August 12th, 2018, at 00:30 UTC marks eight years, eight months, eight days and eight hours since the announcement.) Though not as well-known as Google Search or Gmail, the four eights have had quite a journey—and some pretty amazing growth! Whether it’s
travelers in India’s train stations
or
researchers on the remote Antarctic island Bouvetøya
, hundreds of millions of people the world over rely on our free DNS service to turn domain names like wikipedia.org into IP addresses like 208.80.154.224.
Google Public DNS query growth and major feature launches
Today, it’s estimated that about
10% of internet users
rely on 8.8.8.8, and it serves well over a trillion queries per day. But while we’re really proud of that growth, what really matters is whether it’s a valuable service for our users. Namely, has Google Public DNS made the internet faster for users? Does it safeguard their privacy? And does it help them get to internet sites more reliably and securely?
In other words, has 8.8.8.8 made DNS and the internet better as a whole? Here at Google, we think it has. On this numerological anniversary, let’s take a look at how Google Public DNS has realized those goals and what lies ahead.
Making the internet faster
From the start, a key goal of Google Public DNS was to
make the internet faster
. When we began the project in 2007, Google had already made it faster to search the web, but it could take a while to get to your destination. Back then, most DNS lookups used your ISP’s resolvers, and with small caches, they often had to make multiple DNS queries before they could return an address.
Google Public DNS resolvers’ DNS caches hold tens of billions of entries worldwide. And because hundreds of millions of clients use them every day, they usually return the address for your domain queries without extra lookups, connecting you to the internet that much faster.
DNS resolution process for example.org
Speeding up DNS responses is just one part of making the web faster—getting web content from servers closer to you can have an even bigger impact. Content Delivery Networks (CDNs) distribute large, delay-sensitive content like streaming videos to users around the world. CDNs use DNS to direct users to the nearest servers, and rely on
GeoIP maps
to determine the best location.
Everything’s good if your DNS query comes from an ISP resolver that is close to you, but what happens if the resolver is far away, as it is for researchers on Bouvetøya? In that case, the CDN directs you to a server near the DNS resolver—but not the one closest to you. In 2010, along with other DNS and CDN services, we
proposed a solution
that lets DNS resolvers send part of your IP address in their DNS queries, so CDN name servers can get your best possible GeoIP location (short of sending your entire IP address). By sending only the first three parts of users’ IP addresses (e.g. 192.0.2.x) in the EDNS Client Subnet (ECS) extension, CDNs can return the closest content while maintaining user privacy.
We continue to enhance ECS, (now published as
RFC 7871
), for example, by adding
automatic detection of name server ECS support
. And today, we’re happy to report, support for ECS is widespread among CDNs.
Safeguarding user privacy
From day one of our service, we’ve always been serious about user privacy. Like all Google services, we honor the general Google
Privacy Policy
, and are guided by Google’s
Privacy Principles
. In addition, Google Public DNS published a
privacy practice statement
about the information we collect and how it is used—and how it’s not used. These protect the privacy of your DNS queries once they arrive at Google, but they can still be seen (and potentially modified) en route to 8.8.8.8.
To address this weakness, we
launched a public beta
of
DNS-over-HTTPS
on April 1, 2016, embedding your DNS queries in the secure and private HTTPS protocol. Despite the launch date, this was not an April Fool’s joke, and in the following two years, it has grown dramatically, with millions of users and support by another major public DNS service. Today, we are working in the IETF and with other DNS operators and clients on the
Internet Draft for DNS Queries over HTTPS
specification, which we also support.
Securing the Domain Name System
We’ve always been very concerned with the integrity and security of the responses that Google Public DNS provides. From the start, we
rejected
the practice of
hijacking nonexistent domain (NXDOMAIN) responses
, working to provide users with accurate and honest DNS responses, even when attackers tried to corrupt them.
In 2008, Dan Kaminsky publicized a major security weakness in the DNS protocol that left most DNS resolvers vulnerable to spoofing that poisoned their DNS caches. When we launched 8.8.8.8 the following year, we not only used industry best practices to mitigate this vulnerability, but also developed an
extensive set of additional protections
.
While those protected our DNS service from most attackers, they can’t help in cases where an attacker can see our queries. Starting in 2010, the internet started to use
DNSSEC security
in earnest, making it possible to protect cryptographically signed domains against such
man-in-the-middle
and
man-on-the-side
attacks. In 2013, Google Public DNS became the first major public DNS resolver to
implement DNSSEC validation
for all its DNS queries,
doubling the percentage of end users protected by DNSSEC from 3.3% to 8.1%
.
In addition to protecting the integrity of DNS responses, Google Public DNS also works to block DNS denial of service attacks by
rate limiting
both our queries to name servers and
reflection or amplification attacks
that try to flood victims’ network connections.
Internet access for all
A big part of Google Public DNS’s tremendous growth comes from free public internet services. We make the internet faster for hundreds of these services, from free WiFi in San Francisco’s parks to LinkNYC internet kiosk hotspots and the
Railtel partnership in India‘s train stations
. In places like Africa and Southeast Asia, many ISPs also use 8.8.8.8 to resolve their users’ DNS queries. Providing free DNS resolution to anyone in the world, even to other companies, supports internet access worldwide as a part of Google’s
Next Billion Users initiative
.
APNIC Labs
map of worldwide usage (
Interactive Map
)
Looking ahead
Today, Google Public DNS is the largest public DNS resolver. There are now about a dozen such services providing value-added features like content and malware filtering, and recent entrants Quad9 and Cloudflare also provide privacy for DNS queries over TLS or HTTPS.
But recent incidents that used BGP hijacking to attack DNS are concerning. Increasing the adoption and use of DNSSEC is an effective way to protect against such attacks and as the largest DNSSEC validating resolver, we hope we can influence things in that direction. We are also exploring how to improve the security of the path from resolvers to authoritative name servers—issues not currently addressed by other DNS standards.
In short, we continue to improve Google Public DNS both behind the scenes and in ways visible to users, adding features that users want from their DNS service. Stay tuned for some exciting Google Public DNS announcements in the near future!
Mitigating Spectre with Site Isolation in Chrome
July 11, 2018
Posted by Charlie Reis, Site Isolator
Speculative execution side-channel attacks like Spectre are a newly discovered security risk for web browsers. A website could use such attacks to steal data or login information from other websites that are open in the browser. To better mitigate these attacks, we're excited to announce that Chrome 67 has enabled a security feature called
Site Isolation
on Windows, Mac, Linux, and Chrome OS. Site Isolation has been optionally available as an experimental enterprise policy since Chrome 63, but many known issues have been resolved since then, making it practical to enable by default for all desktop Chrome users.
This launch is one phase of our overall Site Isolation project. Stay tuned for additional security updates that will mitigate attacks beyond Spectre (e.g., attacks from fully compromised renderer processes).
What is Spectre?
In January, Google Project Zero disclosed a set of
speculative execution side-channel attacks
that became publicly known as Spectre and Meltdown. An
additional variant of Spectre
was disclosed in May. These attacks use the speculative execution features of most CPUs to access parts of memory that should be off-limits to a piece of code, and then use timing attacks to discover the values stored in that memory. Effectively, this means that untrustworthy code may be able to read any memory in its process's address space.
This is particularly relevant for web browsers, since browsers run potentially malicious JavaScript code from multiple websites, often in the same process. In theory, a website could use such an attack to steal information from other websites, violating the Same Origin Policy. All major browsers have already
deployed some mitigations
for Spectre, including reducing timer granularity and changing their JavaScript compilers to make the attacks less likely to succeed. However, we believe the
most effective mitigation
is offered by approaches like Site Isolation, which try to avoid having data worth stealing in the same process, even if a Spectre attack occurs.
What is Site Isolation?
Site Isolation
is a large change to Chrome's architecture that limits each renderer process to documents from a single site. As a result, Chrome can rely on the operating system to prevent attacks between processes, and thus, between sites. Note that Chrome uses a specific definition of "site" that includes just the scheme and registered domain. Thus, https://google.co.uk would be a site, and subdomains like https://maps.google.co.uk would stay in the same process.
Chrome has always had a
multi-process architecture
where different tabs could use different renderer processes. A given tab could even switch processes when navigating to a new site in some cases. However, it was still possible for an attacker's page to share a process with a victim's page. For example, cross-site iframes and cross-site pop-ups typically stayed in the same process as the page that created them. This would allow a successful Spectre attack to read data (e.g., cookies, passwords, etc.) belonging to other frames or pop-ups in its process.
When Site Isolation is enabled, each renderer process contains documents from at most one site. This means all navigations to cross-site documents cause a tab to switch processes. It also means all cross-site iframes are put into a different process than their parent frame, using "
out-of-process iframes
." Splitting a single page across multiple processes is a major change to how Chrome works, and the Chrome Security team has been
pursuing this for several years
, independently of Spectre. The first uses of out-of-process iframes shipped last year to
improve the Chrome extension security model
.
A single page may now be split across multiple renderer processes using out-of-process iframes.
Even when each renderer process is limited to documents from a single site, there is still a risk that an attacker's page could access and leak information from cross-site URLs by requesting them as subresources, such as images or scripts. Web browsers generally allow pages to embed images and scripts from any site. However, a page could try to request an HTML or JSON URL with sensitive data as if it were an image or script. This would normally fail to render and not expose the data to the page, but that data would still end up inside the renderer process where a Spectre attack might access it. To mitigate this, Site Isolation includes a feature called
Cross-Origin Read Blocking
(CORB), which is now part of the
Fetch spec
. CORB tries to transparently block cross-site HTML, XML, and JSON responses from the renderer process, with almost no impact to compatibility. To get the most protection from Site Isolation and CORB,
web developers should check that their resources are served with the right MIME type and with the nosniff response header
.
Site Isolation is a significant change to Chrome's behavior under the hood, but it generally shouldn't cause visible changes for most users or web developers (beyond a few
known issues
). It simply offers more protection between websites behind the scenes. Site Isolation does cause Chrome to create more renderer processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 10-13% total memory overhead in real workloads due to the larger number of processes. Our team continues to work hard to optimize this behavior to keep Chrome both fast and secure.
How does Site Isolation help?
In Chrome 67, Site Isolation has been enabled for 99% of users on Windows, Mac, Linux, and Chrome OS. (Given the large scope of this change, we are keeping a 1% holdback for now to monitor and improve performance.) This means that even if a Spectre attack were to occur in a malicious web page, data from other websites would generally not be loaded into the same process, and so there would be much less data available to the attacker. This significantly reduces the threat posed by Spectre.
Because of this, we are planning to re-enable precise timers and features like SharedArrayBuffer (which can be used as a precise timer) for desktop.
What additional work is in progress?
We're now investigating how to extend Site Isolation coverage to Chrome for Android, where there are additional known issues. Experimental enterprise policies for enabling Site Isolation will be available in Chrome 68 for Android, and it can be enabled manually on Android using chrome://flags/#enable-site-per-process.
We're also working on additional security checks in the browser process, which will let Site Isolation mitigate not just Spectre attacks but also attacks from fully compromised renderer processes. These additional enforcements will let us reach the
original motivating goals
for Site Isolation, where Chrome can effectively treat the entire renderer process as untrusted. Stay tuned for an update about these enforcements! Finally, other major browser vendors are finding related ways to defend against Spectre by better isolating sites. We are collaborating with them and are happy to see the progress across the web ecosystem.
Help improve Site Isolation!
We offer cash rewards to researchers who submit security bugs through the
Chrome Vulnerability Reward Program
. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards levels, up to twice the usual amount for information disclosure bugs. Find out more about
Chrome New Feature Special Rewards
.
Compiler-based security mitigations in Android P
June 27, 2018
Posted by Ivan Lozano, Information Security Engineer
[Cross-posted from the
Android Developers Blog
]
Android's switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security posture. In the past couple of releases, we've rolled out additional compiler-based mitigations to make bugs harder to exploit and prevent certain types of bugs from becoming vulnerabilities. In Android P, we're expanding our existing compiler mitigations, which instrument runtime operations to fail safely when undefined behavior occurs. This post describes the new build system support for Control Flow Integrity and Integer Overflow Sanitization.
Control Flow Integrity
A key step in modern exploit chains is for an attacker to gain control of a program's control flow by corrupting function pointers or return addresses. This opens the door to code-reuse attacks where an attacker executes arbitrary portions of existing program code to achieve their goals, such as
counterfeit-object-oriented
and
return-oriented
programming. Control Flow Integrity (CFI) describes a set of mitigation technologies that confine a program's control flow to a call graph of valid targets determined at compile-time.
While we first supported LLVM's CFI implementation in select components in Android O, we're greatly expanding that support in P. This implementation focuses on preventing control flow manipulation via indirect branches, such as function pointers and virtual functions—the 'forward-edges' of a call graph. Valid branch targets are defined as function entry points for functions with the expected function signature, which drastically reduces the set of allowable destinations an attacker can call. Indirect branches are instrumented to detect runtime violations of the statically determined set of allowable targets. If a violation is detected because a branch points to an unexpected target, then the process safely aborts.
Figure 1
. Assembly-level comparison of a virtual function call with and without CFI enabled.
For example,
Figure 1
illustrates how a function that takes an object and calls a virtual function gets translated into assembly with and without CFI. For simplicity, this was compiled with -O0 to prevent compiler optimization. Without CFI enabled, it loads the object's vtable pointer and calls the function at the expected offset. With CFI enabled, it performs a fast-path first check to determine if the pointer falls within an expected range of addresses of compatible vtables. Failing that, execution falls through to a slow path that does a more extensive check for valid classes that are defined in other shared libraries. The slow path will abort execution if the vtable pointer points to an invalid target.
With control flow tightly restricted to a small set of legitimate targets, code-reuse attacks become harder to utilize and some memory corruption vulnerabilities become more difficult or even impossible to exploit.
In terms of performance impact, LLVM's CFI requires compiling with
Link-Time Optimization (LTO)
. LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.
For more technical details about CFI and how other forward-control checks are handled, see the
LLVM design documentation
.
For Android P, CFI is
enabled by default
widely within the media frameworks and other security-critical components, such as NFC and Bluetooth.
CFI kernel support
has also been introduced into the Android common kernel when building with LLVM, providing the option to further harden the trusted computing base. This can be tested today on the HiKey reference boards.
Integer Overflow Sanitization
The UndefinedBehaviorSanitizer's (UBSan) signed and unsigned integer overflow sanitization was first utilized when
hardening the media stack
in Android Nougat. This sanitization is designed to safely abort process execution if a signed or unsigned integer overflows by instrumenting arithmetic instructions which may overflow. The end result is the mitigation of an entire class of memory corruption and information disclosure vulnerabilities where the root cause is an integer overflow, such as the original Stagefright vulnerability.
Because of their success, we've expanded usage of these sanitizers in the media framework with each release. Improvements have been made to LLVM's integer overflow sanitizers to reduce the performance impact by using
fewer
instructions
in ARM 32-bit and removing
unnecessary
checks
. In testing, these improvements reduced the sanitizers' performance overhead by over 75% in Android's 32-bit libstagefright library for some codecs. Improved Android build system support, such as better diagnostics support, more sensible crashes, and globally sanitized integer overflow targets for testing have also expedited the rollout of these sanitizers.
We've prioritized enabling integer overflow sanitization in libraries where complex untrusted input is processed or where there have been security bulletin-level integer overflow vulnerabilities reported. As a result, in Android P the following libraries now benefit from this mitigation:
libui
libnl
libmediaplayerservice
libexif
libdrmclearkeyplugin
libreverbwrapper
Future Plans
Moving forward, we're expanding our use of these mitigation technologies and we strongly encourage vendors to do the same with their customizations. More information about how to enable and test these options will be available soon on the
Android Open Source Project
.
Acknowledgements: This post was developed in joint collaboration with Vishwath Mohan, Jeffrey Vander Stoep, Joel Galenson, and Sami Tolvanen
Better Biometrics in Android P
June 21, 2018
Posted by Vishwath Mohan, Security Engineer
[Cross-posted from the
Android Developers Blog
]
To keep users safe, most apps and devices have an authentication mechanism, or a way to prove that you're you. These mechanisms fall into three categories: knowledge factors, possession factors, and biometric factors.
Knowledge
factors ask for something you know (like a PIN or a password),
possession
factors ask for something you have (like a token generator or security key), and
biometric
factors ask for something you are (like your fingerprint, iris, or face).
Biometric authentication mechanisms are becoming increasingly popular, and it's easy to see why. They're faster than typing a password, easier than carrying around a separate security key, and they prevent one of the most common pitfalls of knowledge-factor based authentication—the risk of
shoulder surfing
.
As more devices incorporate biometric authentication to safeguard people's private information, we're improving biometrics-based authentication in Android P by:
Defining a better model to measure biometric security, and using that to functionally constrain weaker authentication methods.
Providing a common platform-provided entry point for developers to integrate biometric authentication into their apps.
A better security model for biometrics
Currently, biometric unlocks quantify their performance today with two metrics borrowed from machine learning (ML): False Accept Rate (FAR), and False Reject Rate (FRR).
In the case of biometrics, FAR measures how often a biometric model accidentally classifies an incorrect input as belonging to the target user—that is, how often another user is falsely recognized as the legitimate device owner. Similarly, FRR measures how often a biometric model accidentally classifies the user's biometric as incorrect—that is, how often a legitimate device owner has to retry their authentication. The first is a security concern, while the second is problematic for usability.
Both metrics do a great job of measuring the accuracy and precision of a given ML (or biometric) model when applied to random input samples. However, because neither metric accounts for an active attacker as part of the threat model, they do not provide very useful information about its resilience against attacks.
In Android 8.1, we
introduced two new metrics
that more explicitly account for an attacker in the threat model: Spoof Accept Rate (SAR) and Imposter Accept Rate (IAR). As their names suggest, these metrics measure how easily an attacker can bypass a biometric authentication scheme. Spoofing refers to the use of a known-good recording (e.g. replaying a voice recording or using a face or fingerprint picture), while impostor acceptance means a successful mimicking of another user's biometric (e.g. trying to sound or look like a target user).
Strong vs. Weak Biometrics
We use the
SAR/IAR metrics
to categorize biometric authentication mechanisms as either strong or weak. Biometric authentication mechanisms with an SAR/IAR of 7% or lower are strong, and anything above 7% is weak. Why 7% specifically? Most fingerprint implementations have a SAR/IAR metric of about 7%, making this an appropriate standard to start with for other modalities as well. As biometric sensors and classification methods improve, this threshold can potentially be decreased in the future.
This binary classification is a slight oversimplification of the range of security that different implementations provide. However, it gives us a scalable mechanism (via the tiered authentication model) to appropriately scope the capabilities and the constraints of different biometric implementations across the ecosystem, based on the overall risk they pose.
While both strong and weak biometrics will be allowed to unlock a device, weak biometrics:
require the user to re-enter their primary PIN, pattern, password or a strong biometric to unlock a device after a 4-hour window of inactivity, such as when left at a desk or charger. This is in addition to the 72-hour timeout that is enforced for both strong and weak biometrics.
are not supported by the forthcoming
BiometricPrompt API
, a common API for app developers to securely authenticate users on a device in a modality-agnostic way.
can't authenticate payments or participate in other transactions that involve a KeyStore auth-bound key.
must show users a warning that articulates the risks of using the biometric before it can be enabled.
These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.
BiometricPrompt API
Starting in Android P, developers can use the
BiometricPrompt API
to integrate biometric authentication into their apps in a device and biometric agnostic way. BiometricPrompt only exposes strong modalities, so developers can be assured of a consistent level of security across all devices their application runs on. A support library is also provided for devices running Android O and earlier, allowing applications to utilize the advantages of this API across more devices .
Here's a high-level architecture of BiometricPrompt.
The API is intended to be easy to use, allowing the platform to select an appropriate biometric to authenticate with instead of forcing app developers to implement this logic themselves. Here's an example of how a developer might use it in their app:
Conclusion
Biometrics have the potential to both simplify and strengthen how we authenticate our digital identity, but only if they are designed securely, measured accurately, and implemented in a privacy-preserving manner.
We want Android to get it right across all three. So we're combining secure design principles, a more attacker-aware measurement methodology, and a common, easy to use biometrics API that allows developers to integrate authentication in a simple, consistent, and safe manner.
Acknowledgements: This post was developed in joint collaboration with Jim Miller
End-to-end encryption for push messaging, simplified
June 5, 2018
Posted by Giles Hogben, Privacy Engineer and Milinda Perera, Software Engineer
[Cross-posted from the
Android Developers Blog
]
Developers already use HTTPS to communicate with Firebase Cloud Messaging (FCM). The channel between FCM server endpoint and the device is encrypted with SSL over TCP. However, messages are not encrypted end-to-end (E2E) between the developer server and the user device unless developers take special measures.
To this end, we
advise
developers to use keys generated on the user device to encrypt push messages end-to-end. But implementing such E2E encryption has historically required significant technical knowledge and effort. That is why we are excited to announce the
Capillary open source library
which greatly simplifies the implementation of E2E-encryption for push messages between developer servers and users' Android devices.
We also added functionality for sending messages that can only be decrypted on devices that have recently been unlocked. This is designed to support for decrypting messages on devices using
File-Based Encryption
(FBE): encrypted messages are cached in Device Encrypted (DE) storage and message decryption keys are stored in
Android Keystore
, requiring
user authentication
. This allows developers to specify messages with sensitive content, that remain encrypted in cached form until the user has unlocked and decrypted their device.
The library handles:
Crypto functionality and key management across all versions of Android back to
KitKat
(API level 19).
Key generation and registration workflows.
Message encryption (on the server) and decryption (on the client).
Integrity protection to prevent message modification.
Caching of messages received in unauthenticated contexts to be decrypted and displayed upon device unlock.
Edge-cases, such as users adding/resetting device lock after installing the app, users resetting app storage, etc.
The library supports both RSA encryption with ECDSA authentication and
Web Push encryption
, allowing developers to re-use existing server-side code developed for sending E2E-encrypted Web Push messages to browser-based clients.
Along with the library, we are also publishing a demo app (at last, the Google privacy team has its own messaging app!) that uses the library to send E2E-encrypted FCM payloads from a gRPC-based server implementation.
What it's not
The open source library and demo app are not designed to support peer-to-peer messaging and key exchange. They are designed for developers to send E2E-encrypted push messages from a server to one or more devices. You can protect messages between the developer's server and the destination device, but not directly between devices.
It is not a comprehensive server-side solution. While core crypto functionality is provided, developers will need to adapt parts of the sample server-side code that are specific to their architecture (for example, message composition, database storage for public keys, etc.)
You can find more technical details describing how we've architected and implemented the library and demo
here
.
Insider attack resistance
June 1, 2018
Posted by Shawn Willden, Staff Software Engineer
[Cross-posted from the
Android Developers Blog
]
Our smart devices, such as mobile phones and tablets, contain a wealth of personal information that needs to be kept safe. Google is constantly trying to find new and better ways to protect that valuable information on Android devices. From partnering with
external researchers
to find and fix vulnerabilities, to adding new features to the Android platform, we work to make each release and new device safer than the last. This post talks about Google's strategy for making the encryption on Google Pixel 2 devices resistant to various levels of attack—from platform, to hardware, all the way to the people who create the signing keys for Pixel devices.
We encrypt all user data on Google Pixel devices and
protect the encryption keys in secure hardware
. The secure hardware runs highly secure firmware that is responsible for checking the user's password. If the password is entered incorrectly, the firmware refuses to decrypt the device. This firmware also limits the rate at which passwords can be checked, making it harder for attackers to use a brute force attack.
To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.
In the past, device makers have focused on safeguarding these keys by storing the keys in secure locations and severely restricting the number of people who have access to them. That's good, but it leaves those people open to attack by coercion or social engineering. That's risky for the employees personally, and we believe it creates too much risk for user data.
To mitigate these risks,
Google Pixel 2 devices
implement
insider attack resistance
in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user's cooperation. Specifically, it is not possible to upgrade the firmware that checks the user's password unless you present the correct user password. There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it.
The Android security team believes that insider attack resistance is an important element of a complete strategy for protecting user data. The Google Pixel 2 demonstrated that it's possible to protect users even against the most highly-privileged insiders. We recommend that all mobile device makers do the same. For help, device makers working to implement insider attack resistance can reach out to the Android security team through their Google contact.
Acknowledgements: This post was developed in joint collaboration with Paul Crowley, Senior Software Engineer
Labels
android
big data
blackhat
spyware
targeted spyware
Archive
2018
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Google
on
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow