Security Blog
The latest news and insights from Google on security and safety on the Internet
Learning statistics with privacy, aided by the flip of a coin
October 30, 2014
Cross-posted on the
Research Blog
and the
Chromium Blog
At Google, we are constantly trying to improve the techniques we use to
protect our users' security and privacy
. One such project, RAPPOR (Randomized Aggregatable Privacy-Preserving Ordinal Response), provides a new state-of-the-art, privacy-preserving way to learn software statistics that we can use to better safeguard our users’ security, find bugs, and improve the overall user experience.
Building on the concept of
randomized response
, RAPPOR enables learning statistics about the behavior of users’ software while guaranteeing client privacy. The guarantees of
differential privacy
, which are widely accepted as being the
strongest form of privacy
, have almost never been used in practice despite
intense research in academia
. RAPPOR introduces a practical method to achieve those guarantees.
To understand RAPPOR, consider the following example. Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that,
on the Internet, nobody should know you’re a dog
. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless. Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails.
RAPPOR builds on the above concept, allowing software to send reports that are effectively indistinguishable from the results of random coin flips and are free of any unique identifiers. However, by aggregating the reports we can learn the common statistics that are shared by many users. We’re currently testing the use of RAPPOR in Chrome, to learn statistics about how
unwanted software
is
hijacking
users’ settings.
We believe that RAPPOR has the potential to be applied for a number of different purposes, so we're making it freely available for all to use. We'll continue development of RAPPOR as a standalone
open-source project
so that anybody can inspect test its reporting and analysis mechanisms, and help develop the technology. We’ve written up the technical details of RAPPOR in a
report
that will be published next week at the
ACM Conference on Computer and Communications Security
.
We’re encouraged by the
feedback
we’ve received so far from academics and other stakeholders, and we’re looking forward to additional comments from the community. We hope that everybody interested in preserving user privacy will review the technology and share their feedback at
rappor-discuss@googlegroups.com
.
Posted by Úlfar Erlingsson, Tech Lead Manager, Security Research
Strengthening 2-Step Verification with Security Key
October 21, 2014
2-Step Verification
offers a strong extra layer of protection for Google Accounts. Once enabled, you’re asked for a verification code from your phone in addition to your password, to prove that it’s really you signing in from an unfamiliar device. Hackers usually work from afar, so this second factor makes it much harder for a hacker who has your password to access your account, since they don’t have your phone.
Today we’re adding even stronger protection for particularly security-sensitive individuals.
Security Key
is a physical USB second factor that only works after verifying the login site is truly a Google website, not a fake site pretending to be Google. Rather than typing a code, just insert Security Key into your computer’s USB port and tap it when prompted in Chrome. When you sign into your Google Account using Chrome and Security Key, you can be sure that the cryptographic signature cannot be phished.
Security Key and Chrome incorporate the open
Universal 2nd Factor (U2F)
protocol from the
FIDO Alliance
, so other websites with account login systems can get FIDO U2F working in Chrome today. It’s our hope that other browsers will add FIDO U2F support, too. As more sites and browsers come onboard, security-sensitive users can carry a single Security Key that works everywhere FIDO U2F is supported.
Security Key works with Google Accounts at no charge, but you’ll need to buy a compatible USB device directly from a U2F participating vendor. If you think Security Key may be right for you, we invite you to
learn more
.
Posted by Nishit Shah, Product Manager, Google Security
This POODLE bites: exploiting the SSL 3.0 fallback
October 14, 2014
Today we are publishing
details
of a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. I discovered this issue in collaboration with Thai Duong and Krzysztof Kotowicz (also Googlers).
SSL 3.0 is nearly 18 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.
Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response is to support
TLS_FALLBACK_SCSV
. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.
Google Chrome and our servers have supported TLS_FALLBACK_SCSV since February and thus we have good evidence that it can be used without compatibility problems. Additionally, Google Chrome will begin testing changes today that disable the fallback to SSL 3.0. This change will break some sites and those sites will need to be updated quickly.
In the coming months, we hope to remove support for SSL 3.0 completely from our client products.
Thank you to all the people who helped review and discuss responses to this issue.
Posted by Bodo Möller, Google Security Team
[
Updated
Oct 15
to note that SSL 3.0 is nearly 18 years old, not nearly 15 years old.]
News from the land of patch rewards
October 9, 2014
It’s been a year since we
launched
our
Patch Reward
program, a novel effort designed to recognize and reward proactive contributions to the security of key open-source projects that make the Internet tick. Our goal is to provide financial incentives for improvements that go beyond merely fixing a known security bug.
We started with a modest scope and reward amounts, but have gradually expanded the program over the past few months. We’ve seen some great work so far—and to help guide future submissions, we wanted to share some of our favorites:
Incorporation of a
variety of web security checks
directly into Django to help users develop safer web applications.
A support for
seccomp-bpf sandboxing
in BIND to minimize the impact of remote code execution bugs.
Addition of
Curve25519
and several other primitives in OpenSSH to strengthen its cryptographic foundations and improve performance.
A set of patches to reduce the
likelihood of ASLR info leaks
in Linux to make certain types of memory corruption bugs more difficult to exploit.
And, of course, the recent
attack-surface-reducing
function prefix patch in bash that helped mitigate a flurry of “Shellshock”-related bugs.
We hope that this list inspires even more contributions in the year to come. Of course, before participating, be sure to
read the rules page
. When done, simply send your nominations to
security-patches@google.com
. And keep up the great work!
Posted by Michal Zalewski, Google Security Team
An update to SafeSearch options for network administrators
October 2, 2014
Security and privacy are top priorities for Google. We’ve invested a lot in making our products secure, including
strong SSL encryption
by default for Search, Gmail and Drive. We’re working to further extend encryption across all our services, ensuring that your connection to Google is private.
For some time, we’ve offered network administrators the ability to require the use of SafeSearch by their users, which filters out explicit content from search results; this is especially important for schools. However, using this functionality has meant that searches were sent over an unencrypted connection to Google. Unfortunately, this has been the target of abuse by other groups looking to snoop on people’s searches, so we will be removing it as of early December.
Going forward, organizations can require SafeSearch on their networks while at the same time ensuring that their users’ connections to Google remain encrypted. (This is in addition to existing functionality that allows SafeSearch to be set on individual browsers and to be enabled by policy on
managed devices
like Chromebooks.) Network administrators can read more about how to enable this new feature
here
.
Posted by Brian Fitzpatrick, Engineering Director
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
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
2024
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
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