Google Online Security Blog: November 2016

Security Blog

The latest news and insights from Google on security and safety on the Internet

Pixel Security: Better, Faster, Stronger

November 17, 2016

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer[Cross-posted from the Android Developers Blog]security improvements

File-Based Encryption Direct Boot experiencefile-based encryptionDirect boot
Enhanced with TrustZone® security

TrustZone enforces the Verified Boot process. If TrustZone detects that the operating system has been modified, it won't decrypt disk encryption keys; this helps to secure device encrypted (DE) data.

TrustZone enforces a waiting period between guesses at the user credential, which gets longer after a sequence of wrong guesses. With 1624 valid four-point patterns and TrustZone's ever-growing waiting period, trying all patterns would take more than four years. This improves security for all users, especially those who have a shorter and more easily guessed pattern, PIN, or password.

Encryption on Pixel phones
Protecting different folders with different keys required a distinct approach from full-disk encryption (FDE). The natural choice for Linux-based systems is the industry-standard eCryptFS. However, eCryptFS didn't meet our performance requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked with the ext4 maintainer, Ted Ts'o, to add encryption natively to ext4, and Android became the first consumer of this technology. ext4 encryption performance is similar to full-disk encryption, which is as performant as a software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which gives them the ability to write encrypted data at line speed to the flash memory. To take advantage of this, we modified ext4 encryption to use this hardware by adding a key reference to the bio structure, within the ext4 driver before passing it to the block layer. (The bio structure is the basic container for block I/O in the Linux kernel.) We then modified the inline encryption block driver to pass this to the hardware. As with ext4 encryption, keys are managed by the Linux keyring. To see our implementation, take a look at the source code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with inline encryption benefits Pixel users, FBE is available in AOSP and ready to use, along with the other features mentioned in this post.

Google

SHA-1 Certificates in Chrome

November 16, 2016

Posted by Andrew Whalley, Chrome Securityseveralannouncementsshowed signs of weaknessrecent researchRelease schedulearound the end of January 2017Chrome release processto checkSHA-1 use in private PKIsChrome 54EnableSha1ForLocalAnchorspolicyrequire a secure origin

Google

A new site for Safe Browsing

November 9, 2016

Posted by Mike Castner and Brooke Heinichen, Safe Browsing Teamlaunching in 2007Chrome users on Androidseveralimprovementsa new site for Safe BrowsingTransparency ReportSearch ConsoleSafe Browsing AlertsSafe Browsing website

Google

Protecting users from repeatedly dangerous sites

November 8, 2016

Posted by Brooke Heinichen, Safe Browsing TeamMalwareUnwanted SoftwarePhishing, and Social Engineering PoliciesSearch ConsoleRepeat Offenders

Google

Here’s to more HTTPS on the web!

November 3, 2016

Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Teamnew section to the HTTPS Report Card in our Transparency Report

Percentage of pages loaded over HTTPS in Chrome

As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP. As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.

We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented: “We were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience: “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”

Webmasters that include ads on their sites also should carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense, or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”

As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by default. Don’t hesitate to start planning your HTTPS migration today!