143 captures
10 Jun 2017 - 24 Jul 2026
Apr
MAY
Jun
25
2021
2022
2023
success
fail
About this capture
COLLECTED BY
Collection:
Common Crawl
Web crawl data from Common Crawl.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20220525222245/https://security.googleblog.com/2016/11/
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
]
Encryption protects your data if your phone falls into someone else's hands. The new Google Pixel and Pixel XL are encrypted by default to offer strong data protection, while maintaining a great user experience with high I/O performance and long battery life. In addition to encryption, the Pixel phones debuted running the Android Nougat release, which has even more
security improvements
.
This blog post covers the encryption implementation on Google Pixel devices and how it improves the user experience, performance, and security of the device.
File-Based Encryption Direct Boot experience
One of the security features introduced in Android Nougat was
file-based encryption
. File-based encryption (FBE) means different files are encrypted with different keys that can be unlocked independently. FBE also separates data into device encrypted (DE) data and credential encrypted (CE) data.
Direct boot
uses file-based encryption to allow a seamless user experience when a device reboots by combining the unlock and decrypt screen. For users, this means that applications like alarm clocks, accessibility settings, and phone calls are available immediately after boot.
Enhanced with TrustZone® security
Modern processors provide a means to execute code in a mode that remains secure even if the kernel is compromised. On ARM®-based processors this mode is known as TrustZone. Starting in Android Nougat, all disk encryption keys are stored encrypted with keys held by TrustZone software.
This secures encrypted data in two ways:
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.
SHA-1 Certificates in Chrome
November 16, 2016
Posted by Andrew Whalley, Chrome Security
We’ve previously made
several
announcements
about Google Chrome's deprecation plans for SHA-1 certificates. This post provides an update on the final removal of support.
The SHA-1 cryptographic hash algorithm first
showed signs of weakness
over eleven years ago and
recent research
points to the imminent possibility of attacks that could directly impact the integrity of the Web PKI. To protect users from such attacks, Chrome will stop trusting certificates that use the SHA-1 algorithm, and visiting a site using such a certificate will result in an interstitial warning.
Release schedule
We are planning to remove support for SHA-1 certificates in Chrome 56, which will be released to the stable channel
around the end of January 2017
. The removal will follow the
Chrome release process
, moving from Dev to Beta to Stable; there won't be a date-based change in behaviour.
Website operators are urged
to check
for the use of SHA-1 certificates and immediately contact their CA for a SHA-256 based replacement if any are found.
SHA-1 use in private PKIs
Previous posts made a distinction between certificates which chain to a public CA and those which chain to a locally installed trust anchor, such as those of a private PKI within an enterprise. We recognise there might be rare cases where an enterprise wishes to make their own risk management decision to continue using SHA-1 certificates.
Starting with
Chrome 54
we provide the
EnableSha1ForLocalAnchors
policy
that allows certificates which chain to a locally installed trust anchor to be used after support has otherwise been removed from Chrome. Features which
require a secure origin
, such as geolocation, will continue to work, however pages will be displayed as “neutral, lacking security”. Without this policy set, SHA-1 certificates that chain to locally installed roots will not be trusted starting with Chrome 57, which will be released to the stable channel in March 2017. Note that even without the policy set, SHA-1 client certificates will still be presented to websites requesting client authentication.
Since this policy is intended only to allow additional time to complete the migration away from SHA-1, it will eventually be removed in the first Chrome release after January 1st 2019.
As Chrome makes use of certificate validation libraries provided by the host OS when possible, this option will have no effect if the underlying cryptographic library disables support for SHA-1 certificates; at that point, they will be unconditionally blocked. We may also remove support before 2019 if there is a serious cryptographic break of SHA-1. Enterprises are encouraged to make every effort to stop using SHA-1 certificates as soon as possible and to consult with their security team before enabling the policy.
A new site for Safe Browsing
November 9, 2016
Posted by Mike Castner and Brooke Heinichen, Safe Browsing Team
Since
launching in 2007
, the Safe Browsing team has been dedicated to our mission of protecting users from phishing, malware, and unwanted software on the web. Our coverage currently extends to more than two billion internet-connected devices, including
Chrome users on Android
. As part of our commitment to keep our users both protected and informed, we’ve recently launched
several
improvements
to the way we share information.
Today, we’re happy to announce
a new site for Safe Browsing
that makes it easier for users to quickly report malicious sites, access our developer documentation, and find our policies. Our new site also serves as a central hub for our tools, including the
Transparency Report
,
Search Console
, and
Safe Browsing Alerts
for Network Administrators.
The new
Safe Browsing website
will be a platform for consolidated policy and help content. We’re excited to make this new, single source of information available to users, developers, and webmasters.
Protecting users from repeatedly dangerous sites
November 8, 2016
Posted by Brooke Heinichen, Safe Browsing Team
Since 2005, Safe Browsing has been protecting users from harm on the Internet, and has evolved over the years to adapt to the changing nature of threats and user harm.
Today, sites in violation of Google’s
Malware
,
Unwanted Software
,
Phishing, and Social Engineering Policies
show warnings until Google verifies that the site is no longer harmful. The verification can be triggered automatically, or at the request of the webmaster via the
Search Console
.
However, over time, we’ve observed that a small number of websites will cease harming users for long enough to have the warnings removed, and will then revert to harmful activity.
As a result of this gap in user protection, we have adjusted our policies to reduce risks borne by end-users. Starting today, Safe Browsing will begin to classify these types of sites as “
Repeat Offenders
.” With regards to Safe Browsing-related policies, Repeat Offenders are websites that repeatedly switch between compliant and policy-violating behavior for the purpose of having a successful review and having warnings removed. Please note that websites that are hacked will not be classified as Repeat Offenders; only sites that purposefully post harmful content will be subject to the policy.
Once Safe Browsing has determined that a site is a Repeat Offender, the webmaster will be unable to request additional reviews via the Search Console for 30 days, and warnings will continue to show to users. When a site is established as a Repeat Offender, the webmaster will be notified via email to their registered Search Console email address.
We continuously update our policies and practices to address evolving threats. This is yet another change to help protect users from harm online.
Here’s to more HTTPS on the web!
November 3, 2016
Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team
Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It’s happening now, with secure browsing becoming standard for users of Chrome.
Today, we’re adding a
new section to the HTTPS Report Card in our Transparency Report
that includes data about how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.
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!
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome security
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2022
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
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
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow