Posted by Janis Danisevskis, Information Security Engineer, Android Security

[Cross-posted from the Android Developers Blog]

In Android Pie, we introduced Android Protected Confirmation, the first major mobile OS API that leverages a hardware protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. This Trusted UI protects the choices you make from fraudulent apps or a compromised operating system. When an app invokes Protected Confirmation, control is passed to the Trusted UI, where transaction data is displayed and user confirmation of that data's correctness is obtained.
Once confirmed, your intention is cryptographically authenticated and unforgeable when conveyed to the relying party, for example, your bank. Protected Confirmation increases the bank's confidence that it acts on your behalf, providing a higher level of protection for the transaction.
Protected Confirmation also adds additional security relative to other forms of secondary authentication, such as a One Time Password or Transaction Authentication Number. These mechanisms can be frustrating for mobile users and also fail to protect against a compromised device that can corrupt transaction data or intercept one-time confirmation text messages.
Once the user approves a transaction, Protected Confirmation digitally signs the confirmation message. Because the signing key never leaves the Trusted UI's hardware sandbox, neither app malware nor a compromised operating system can fool the user into authorizing anything. Protected Confirmation signing keys are created using Android's standard AndroidKeyStore API. Before it can start using Android Protected Confirmation for end-to-end secure transactions, the app must enroll the public KeyStore key and its Keystore Attestation certificate with the remote relying party. The attestation certificate certifies that the key can only be used to sign Protected Confirmations.
There are many possible use cases for Android Protected Confirmation. At Google I/O 2018, the What's new in Android security session showcased partners planning to leverage Android Protected Confirmation in a variety of ways, including Royal Bank of Canada person to person money transfers; Duo Security, Nok Nok Labs, and ProxToMe for user authentication; and Insulet Corporation and Bigfoot Biomedical, for medical device control.
Insulet, a global leading manufacturer of tubeless patch insulin pumps, has demonstrated how they can modify their FDA cleared Omnipod DASH TM Insulin management system in a test environment to leverage Protected Confirmation to confirm the amount of insulin to be injected. This technology holds the promise for improved quality of life and reduced cost by enabling a person with diabetes to leverage their convenient, familiar, and secure smartphone for control rather than having to rely on a secondary, obtrusive, and expensive remote control device. (Note: The Omnipod DASH™ System is not cleared for use with Pixel 3 mobile device or Protected Confirmation).
This work is fulfilling an important need in the industry. Since smartphones do not fit the mold of an FDA approved medical device, we've been working with FDA as part of DTMoSt, an industry-wide consortium, to define a standard for phones to safely control medical devices, such as insulinSince smartphones do not fit the mold of an FDA approved medical device, we've been working with FDA as part of DTMoSt, an industry-wide consortium, to define a standard for phones to safely control medical devices, such as insulin pumps. A technology like Protected Confirmation plays an important role in gaining higher assurance of user intent and medical safety.
To integrate Protected Confirmation into your app, check out the Android Protected Confirmation training article. Android Protected Confirmation is an optional feature in Android Pie. Because it has low-level hardware dependencies, Protected Confirmation may not be supported by all devices running Android Pie. Google Pixel 3 and 3XL devices are the first to support Protected Confirmation, and we are working closely with other manufacturers to adopt this market-leading security innovation on more devices.

Posted by James Wagner, Chrome Extensions Product Manager

[Cross-posted from the Chromium blog]

Incredibly, it’s been nearly a decade since we launched the Chrome extensions system. Thanks to the hard work and innovation of our developer community, there are now more than 180,000 extensions in the Chrome Web Store, and nearly half of Chrome desktop users actively use extensions to customize Chrome and their experience on the web.

The extensions team's dual mission is to help users tailor Chrome’s functionality to their individual needs and interests, and to empower developers to build rich and useful extensions. But, first and foremost, it’s crucial that users be able to trust the extensions they install are safe, privacy-preserving, and performant. Users should always have full transparency about the scope of their extensions’ capabilities and data access.

We’ve recently taken a number of steps toward improved extension security with the launch of out-of-process iframes, the removal of inline installation, and significant advancements in our ability to detect and block malicious extensions using machine learning. Looking ahead, there are more fundamental changes needed so that all Chrome extensions are trustworthy by default.

Today we’re announcing some upcoming changes and plans for the future:

User controls for host permissions

Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.

While host permissions have enabled thousands of powerful and creative extension use cases, they have also led to a broad range of misuse - both malicious and unintentional - because they allow extensions to automatically read and change data on websites. Our aim is to improve user transparency and control over when extensions are able to access site data. In subsequent milestones, we’ll continue to optimize the user experience toward this goal while improving usability. If your extension requests host permissions, we encourage you to review our transition guide and begin testing as soon as possible.

Changes to the extensions review process

Going forward, extensions that request powerful permissions will be subject to additional compliance review. We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring. Your extension’s permissions should be as narrowly-scoped as possible, and all your code should be included directly in the extension package, to minimize review time.
New code reliability requirements

Starting today, Chrome Web Store will no longer allow extensions with obfuscated code. This includes code within the extension package as well as any external code or resource fetched from the web. This policy applies immediately to all new extension submissions. Existing extensions with obfuscated code can continue to submit updates over the next 90 days, but will be removed from the Chrome Web Store in early January if not compliant.

Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.

Additionally, since JavaScript code is always running locally on the user's machine, obfuscation is insufficient to protect proprietary code from a truly motivated reverse engineer. Obfuscation techniques also come with hefty performance costs such as slower execution and increased file and memory footprints.

Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed, including the following techniques:

• Removal of whitespace, newlines, code comments, and block delimiters
• Shortening of variable and function names
• Collapsing the number of JavaScript files

Posted by Elie Bursztein, Anti-Abuse Research Lead - Ian Goodfellow, Adversarial Machine Learning Research Lead

Recent advances in AI are transforming how we combat fraud and abuse and implement new security protections. These advances are critical to meeting our users’ expectations and keeping increasingly sophisticated attackers at bay, but they come with brand new challenges as well.

This week at RSA, we explored the intersection between AI, anti-abuse, and security in two talks.

Our first talk provided a concise overview of how we apply AI to fraud and abuse problems. The talk started by detailing the fundamental reasons why AI is key to building defenses that keep up with user expectations and combat increasingly sophisticated attacks. It then delved into the top 10 anti-abuse specific challenges encountered while applying AI to abuse fighting and how to overcome them. Check out the infographic at the end of the post for a quick overview of the challenges we covered during the talk.

Our second talk looked at attacks on ML models themselves and the ongoing effort to develop new defenses.

It covered attackers’ attempts to recover private training data, to introduce examples into the training set of a machine learning model to cause it to learn incorrect behaviors, to modify the input that a machine learning model receives at classification time to cause it to make a mistake, and more.

Our talk also looked at various defense solutions, including differential privacy, which provides a rigorous theoretical framework for preventing attackers from recovering private training data.

Hopefully you were to able to join us at RSA! But if not, here is re-recording and the slides of our first talk on applying AI to abuse-prevention, along with the slides from our second talk about protecting ML models.

Posted by Matt Linton, Senior Security Engineer and Pat Parseghian, Technical Program Manager

[Google Cloud, G Suite, and Chrome customers can visit the Google Cloud blog for details about those products]
[For more technical details about this issue, please read Project Zero's blog post]

Last year, Google’s Project Zero team discovered serious security flaws caused by “speculative execution,” a technique used by most modern processors (CPUs) to optimize performance.

The Project Zero researcher, Jann Horn, demonstrated that malicious actors could take advantage of speculative execution to read system memory that should have been inaccessible. For example, an unauthorized party may read sensitive information in the system’s memory such as passwords, encryption keys, or sensitive information open in applications. Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.

As soon as we learned of this new class of attack, our security and product development teams mobilized to defend Google’s systems and our users’ data. We have updated our systems and affected products to protect against this new type of attack. We also collaborated with hardware and software manufacturers across the industry to help protect their users and the broader web. These efforts have included collaborative analysis and the development of novel mitigations.

We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming (update: this has been published; see above).

Mitigation status for Google products

A list of affected Google products and their current status of mitigation against this attack appears here. As this is a new class of attack, our patch status refers to our mitigation for currently known vectors for exploiting the flaw. The issue has been mitigated in many products (or wasn’t a vulnerability in the first place). In some instances, users and customers may need to take additional steps to ensure they’re using a protected version of a product. This list and a product’s status may change as new developments warrant. In the case of new developments, we will post updates to this blog.

• All Google products not explicitly listed below require no user or customer action.
• Android
• Devices with the latest security update are protected. Furthermore, we are unaware of any successful reproduction of this vulnerability that would allow unauthorized information disclosure on ARM-based Android devices.
• Supported Nexus and Pixel devices with the latest security update are protected.
• Further information is available here.
• Google Apps / G Suite (Gmail, Calendar, Drive, Sites, etc.):
• No additional user or customer action needed.
• Google Chrome
• Some user or customer action needed. More information here.
• Google Chrome OS (e.g., Chromebooks):
• Some additional user or customer action needed. More information here.
• Google Cloud Platform
• Google App Engine: No additional customer action needed.
• Google Compute Engine: Some additional customer action needed. More information here.
• Google Kubernetes Engine: Some additional customer action needed. More information here.
• Google Cloud Dataflow: Some additional customer action needed. More information here.
• Google Cloud Dataproc: Some additional customer action needed. More information here. 
• All other Google Cloud products and services: No additional action needed.
• Google Home / Chromecast:
• No additional user action needed.
• Google Wifi/OnHub:
• No additional user action needed.

Posted by Ben McIlwain, Google Registry
The security of the Web is of the utmost importance to Google. One of the most powerful tools in the Web security toolbox is ensuring that connections to websites are encrypted using HTTPS, which prevents Web traffic from being intercepted, altered, or misdirected in transit. We have taken many actions to make the use of HTTPS more widespread, both within Google and on the larger Internet.

We began in 2010 by defaulting to HTTPS for Gmail and starting the transition to encrypted search by default. In 2014, we started encouraging other websites to use HTTPS by giving secure sites a ranking boost in Google Search. In 2016, we became a platinum sponsor of Let’s Encrypt, a service that provides simple and free SSL certificates. Earlier this year we announced that Chrome will start displaying warnings on insecure sites, and we recently introduced fully managed SSL certificates in App Engine. And today we’re proud to announce that we are beginning to use another tool in our toolbox, the HTTPS Strict Transport Security (HSTS) preload list, in a new and more impactful way.

The HSTS preload list is built in to all major browsers (Chrome, Firefox, Safari, Internet Explorer/Edge, and Opera). It consists of a list of hostnames for which browsers automatically enforce HTTPS-secured connections. For example, gmail.com is on the list, which means that the aforementioned browsers will never make insecure connections to Gmail; if the user types http://gmail.com, the browser first changes it to https://gmail.com before sending the request. This provides greater security because the browser never loads an http-to-https redirect page, which could be intercepted.

The HSTS preload list can contain individual domains or subdomains and even top-level domains (TLDs), which are added through the HSTS website. The TLD is the last part of the domain name, e.g., .com, .net, or .org. Google operates 45 TLDs, including .google, .how, and .soy. In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

The use of TLD-level HSTS allows such namespaces to be secure by default. Registrants receive guaranteed protection for themselves and their users simply by choosing a secure TLD for their website and configuring an SSL certificate, without having to add individual domains or subdomains to the HSTS preload list. Moreover, since it typically takes months between adding a domain name to the list and browser upgrades reaching a majority of users, using an already-secured TLD provides immediate protection rather than eventual protection. Adding an entire TLD to the HSTS preload list is also more efficient, as it secures all domains under that TLD without the overhead of having to include all those domains individually.

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Posted by Stephan Somogyi, Safe Browsing Emeritus and Allison Miller, Security & Privacy

[Cross-posted from The Keyword]

In 2007, we launched Safe Browsing, one of Google’s earliest anti-malware efforts. To keep our users safe, we’d show them a warning before they visited a site that might’ve harmed their computers.
Computing has evolved a bit in the last decade, though. Smartphones created a more mobile internet, and now AI is increasingly changing how the world interacts with it. Safe Browsing also had to evolve to effectively protect users.

And it has: In May 2016, we announced that Safe Browsing was protecting more than 2 billion devices from badness on the internet. Today we’re announcing that Safe Browsing has crossed the threshold to 3 billion devices. We’re sharing a bit more about how we got here, and where we’re going.

What is Safe Browsing?

You may not know Safe Browsing by name, since most of the time we’re invisibly protecting you, without getting in the way. But you may have seen a warning like this at some point:
This notification is one of the visible parts of Safe Browsing, a collection of Google technologies that hunt badness—typically websites that deceive users—on the internet. We identify sites that might try to phish you, or sites that install malware or other undesirable software. The systems that make up Safe Browsing work together to identify, analyze and continuously keep Safe Browsing’s knowledge of the harmful parts of the internet up to date.

This protective information that we generate—a curated list of places that are dangerous for people and their devices—is used across many of our products. It helps keep search results safe and keep ads free from badness; it’s integral to Google Play Protect and keeps you safe on Android; and it helps Gmail shield you from malicious messages.

And Safe Browsing doesn’t protect only Google’s products. For many years, Safari and Firefox have protected their users with Safe Browsing as well. If you use an up-to-date version of Chrome, Firefox or Safari, you’re protected by default. Safe Browsing is also used widely by web developers and app developers (including Snapchat), who integrate our protections by checking URLs before they’re presented to their users.

Protecting more people with fewer bits

In the days when web browsers were used only on personal computers, we didn’t worry much about the amount of data Safe Browsing sent over the internet to keep your browser current. Mobile devices changed all that: Slow connections, expensive mobile data plans, and scarce battery capacity became important new considerations.

So over the last few years, we’ve rethought how Safe Browsing delivers data. We built new technologies to make its data as compact as possible: We only send the information that’s most protective to a given device, and we make sure this data is compressed as tightly as possible. (All this work benefits desktop browsers, too!)

We initially introduced our new mobile-optimized method in late 2015 with Chrome on Android, made it more broadly available in mid-2016, when we also started actively encouraging Android developers to integrate it. With the release of iOS 10 in September 2016, Safari began using our new, efficient Safe Browsing update technology, giving iOS users a protection boost.

Safe Browsing in an AI-first world

The internet is at the start of another major shift. Safe Browsing has already been using machine learning for many years to detect much badness of many kinds. We’re continually evaluating and integrating cutting-edge new approaches to improve Safe Browsing.

Protecting all users across all their platforms makes the internet safer for everyone. Wherever the future of the internet takes us, Safe Browsing will be there, continuing to evolve, expand, and protect people wherever they are.

Posted by Devon O’Brien, Ryan Sleevi, Andrew Whalley, Chrome Security

This post is a broader announcement of plans already finalized on the blink-dev mailing list.

At the end of July, the Chrome team and the PKI community converged upon a plan to reduce, and ultimately remove, trust in Symantec’s infrastructure in order to uphold users’ security and privacy when browsing the web. This plan, arrived at after significant debate on the blink-dev forum, would allow reasonable time for a transition to new, independently-operated Managed Partner Infrastructure while Symantec modernizes and redesigns its infrastructure to adhere to industry standards. This post reiterates this plan and includes a timeline detailing when site operators may need to obtain new certificates.

On January 19, 2017, a public posting to the mozilla.dev.security.policy newsgroup drew attention to a series of questionable website authentication certificates issued by Symantec Corporation’s PKI. Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements. During the subsequent investigation, it was revealed that Symantec had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight, and had been aware of security deficiencies at these organizations for some time.

This incident, while distinct from a previous incident in 2015, was part of a continuing pattern of issues over the past several years that has caused the Chrome team to lose confidence in the trustworthiness of Symantec’s infrastructure, and as a result, the certificates that have been or will be issued from it.

After our agreed-upon proposal was circulated, Symantec announced the selection of DigiCert to run this independently-operated Managed Partner Infrastructure, as well as their intention to sell their PKI business to DigiCert in lieu of building a new trusted infrastructure. This post outlines the timeline for that transition and the steps that existing Symantec customers should take to minimize disruption to their users.

Information For Site Operators

Starting with Chrome 66, Chrome will remove trust in Symantec-issued certificates issued prior to June 1, 2016. Chrome 66 is currently scheduled to be released to Chrome Beta users on March 15, 2018 and to Chrome Stable users around April 17, 2018.

If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.

Additionally, by December 1, 2017, Symantec will transition issuance and operation of publicly-trusted certificates to DigiCert infrastructure, and certificates issued from the old Symantec infrastructure after this date will not be trusted in Chrome.

Around the week of October 23, 2018, Chrome 70 will be released, which will fully remove trust in Symantec’s old infrastructure and all of the certificates it has issued. This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.

Site operators that need to obtain certificates from Symantec’s existing root and intermediate certificates may do so from the old infrastructure until December 1, 2017, although these certificates will need to be replaced again prior to Chrome 70. Additionally, certificates issued from Symantec’s infrastructure will have their validity limited to 13 months. Alternatively, site operators may obtain replacement certificates from any other Certificate Authority currently trusted by Chrome, which are unaffected by this distrust or validity period limit.
Reference Timeline

The following is a timeline of relevant dates associated with this plan, which distills the various requirements and milestones into an actionable set of information for site operators. As always, Chrome release dates can vary by a number of days, but upcoming release dates can be tracked here.