Google Online Security Blog

End-to-end encryption for push messaging, simplified

June 5, 2018

[Cross-posted from the Android Developers Blog]adviseCapillary open source libraryFile-Based EncryptionAndroid Keystoreuser authentication

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.

Web Push encryption 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.)

here

Insider attack resistance

June 1, 2018

Posted by Shawn Willden, Staff Software Engineer[Cross-posted from the Android Developers Blog]external researchersprotect the encryption keys in secure hardwareGoogle Pixel 2 devicesinsider attack resistanceAcknowledgements: This post was developed in joint collaboration with Paul Crowley, Senior Software Engineer

Keeping 2 billion Android devices safe with machine learning

May 24, 2018

Posted by Sai Deep Tetali, Software Engineer, Google Play Protect[Cross-posted from the Android Developers Blog]Google Play Protect Security at scale

Training our machines

malicious behavior

Doubling down on securitysecurity experts and researchersPlay ProtectAcknowledgements: This work was developed in joint collaboration with Google Play Protect, Safe Browsing and Play Abuse teams with contributions from Andrew Ahn, Hrishikesh Aradhye, Daniel Bali, Hongji Bao, Yajie Hu, Arthur Kaiser, Elena Kovakina, Salvador Mandujano, Melinda Miller, Rahul Mishra, Damien Octeau, Sebastian Porst, Chuangang Ren, Monirul Sharif, Sri Somanchi, Sai Deep Tetali, Zhikun Wang, and Mo Yu.

Google CTF 2018 is here

May 8, 2018

Posted by Jan Keller, Security TPMGoogle CTF 2017

Congratulations (for the second year) to the team pasten, from Israel, for scoring first place in both the quals and the finals. Also, for everyone who hasn’t played yet or wants to play again, we have open-sourced the 2017 challenges in our GitHub repository.

Hence, we are excited to announce Google CTF 2018:

Date and time: 00:00:01 UTC on June 23th and 24th, 2018
Location: Online
Prizes: Big checks, swag and rewards for creative write-ups

The winning teams will compete again for a spot at the Google CTF Finals later this year (more details on the Finals soon).

For beginners and veterans alike
Based on the feedback we received, we plan to have additional challenges this year where people that may be new to CTFs or security can learn about, and try their hands at, some security challenges. These will be presented in a “Quest” style where there will be a scenario similar to a real world penetration testing environment. We hope that this will give people a chance to sharpen their skills, learn something new about CTFs and security, while allowing them to see a real world value to information security and its broader impact.
We hope to virtually see you at the 3rd annual Google CTF on June 23rd 2018 at 00:00:01 UTC. Check g.co/ctf, or subscribe to our mailing list for more details, as they become available.

Why do we host these competitions?
We outlined our philosophy last year, but in short: we believe that the security community helps us better protect Google users, and so we want to nurture the community and give back in a fun way.
Thirsty for more?
There are a lot of opportunities for you to help us make the Internet a safer place:

Our Vulnerability Rewards Program: Report vulnerabilities in our infrastructure and get rewarded
(AutoFuzz) Patch Rewards Program: Fix vulnerabilities in open-source software to build your reputation and make an impact in the security community
Vulnerability Research Grants Program: Apply for a research grant to extensively test a component of our infrastructure at your own pace.

Leveraging AI to protect our users and the web

April 20, 2018

Posted by Elie Bursztein, Anti-Abuse Research Lead - Ian Goodfellow, Adversarial Machine Learning Research Leadfirst talksecond talkre-recordingthe slidesslides

DNS over TLS support in Android P Developer Preview

April 17, 2018

Posted by Erik Kline, Android software engineer, and Ben Schwartz, Jigsaw software engineer[Cross-posted from the Android Developers Blog]DNSIETFRFC 7858DNS over TLS in P

community-maintained listLinkProperties.isPrivateDnsActive()

Protecting users with TLS by default in Android P

April 12, 2018

Posted by Chad Brubaker, Senior Software Engineer Android Security[Cross-posted from the Android Developers Blog]announcedandroid:usesCleartextTrafficNetwork Security ConfigHow do I update my app?
Why should I use TLS?
blog postDeveloper Summit talkIsn't TLS slow?
No, it's not.How do I use TLS in my app?
SSLSocketFactorySocketFactorySSLSocketgetDefaultHostnameVerifier()HostnameVerifier.verify()I need to use cleartext traffic to
network security configAllow cleartext connections to a specific domain
<network-security-config> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">insecure.example.com</domain> <domain includeSubdomains="true">insecure.cdn.example.com</domain> </domain-config> </network-security-config>Allow connections to arbitrary insecure domains
<network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">example.com</domain> <domain includeSubdomains="true">cdn.example2.com</domain> </domain-config> <base-config cleartextTrafficPermitted="true" /> </network-security-config>
How do I update my library?isCleartextTrafficPermitted

Android Security 2017 Year in Review

March 15, 2018

Posted by Dave Kleidermacher, Vice President of Security for Android, Play, ChromeOSg.co/AndroidSecurityReport2017
Google Play Protectannounced

Protecting users' devices Play Protect automatically checks Android devices for PHAs at least once every day, and users can conduct an additional review at any time for some extra peace of mind. These automatic reviews enabled us to remove nearly 39 million PHAs last year.
We also update Play Protect to respond to trends that we detect across the ecosystem. For instance, we recognized that nearly 35% of new PHA installations were occurring when a device was offline or had lost network connectivity. As a result, in October 2017, we enabled offline scanning in Play Protect, and have since prevented 10 million more PHA installs.

Preventing PHA downloads Devices that downloaded apps exclusively from Google Play were nine times less likely to get a PHA than devices that downloaded apps from other sources. And these security protections continue to improve, partially because of Play Protect’s increased visibility into newly submitted apps to Play. It reviewed 65% more Play apps compared to 2016.
Play Protect also doesn’t just secure Google Play—it helps protect the broader Android ecosystem as well. Thanks in large part to Play Protect, the installation rates of PHAs from outside of Google Play dropped by more than 60%.

Security updates

While Google Play Protect is a great shield against harmful PHAs, we also partner with device manufacturers to make sure that the version of Android running on users' devices is up-to-date and secure.
Throughout the year, we worked to improve the process for releasing security updates, and 30% more devices received security patches than in 2016. Furthermore, no critical security vulnerabilities affecting the Android platform were publicly disclosed without an update or mitigation available for Android devices. This was possible due to the Android Security Rewards Program, enhanced collaboration with the security researcher community, coordination with industry partners, and built-in security features of the Android platform.

New security features in Android Oreo

We introduced a slew of new security features in Android Oreo: making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, and more.
We highlighted many of these over the course of the year, but some may have flown under the radar. For example, we updated the overlay API so that apps can no longer block the entire screen and prevent you from dismissing them, a common tactic employed by ransomware.

Openness makes Android security stronger

We’ve long said it, but it remains truer than ever: Android’s openness helps strengthen our security protections. For years, the Android ecosystem has benefitted from researchers’ findings, and 2017 was no different.
Security reward programs We continued to see great momentum with our Android Security Rewards program: we paid researchers $1.28 million dollars, pushing our total rewards past $2 million dollars since the program began. We also increased our top-line payouts for exploits that compromise TrustZone or Verified Boot from $50,000 to $200,000, and remote kernel exploits from $30,000 to $150,000.
In parallel, we introduced Google Play Security Rewards Program and offered a bonus bounty to developers that discover and disclose select critical vulnerabilities in apps hosted on Play to their developers.
External security competitions Our teams also participated in external vulnerability discovery and disclosure competitions, such as Mobile Pwn2Own. At the 2017 Mobile Pwn2Own competition, no exploits successfully compromised the Google Pixel. And of the exploits demonstrated against devices running Android, none could be reproduced on a device running unmodified Android source code from the Android Open Source Project (AOSP).

We’re pleased to see the positive momentum behind Android security, and we’ll continue our work to improve our protections this year, and beyond. We will never stop our work to ensure the security of Android users.

Distrust of the Symantec PKI: Immediate action needed by site operators

March 7, 2018

Posted by Devon O’Brien, Ryan Sleevi, Emily Stark, Chrome security teampreviously announced
Chrome 66
Chrome Canarytrusted CA

An example of a certificate error that Chrome 66 users might see if you are using a Legacy Symantec SSL/TLS certificate that was issued before June 1, 2016.

The DevTools message you will see if you need to replace your certificate before Chrome 66.

Chrome 66 has already been released to the Canary and Dev channels, meaning affected sites are already impacting users of these Chrome channels. If affected sites do not replace their certificates by March 15, 2018, Chrome Beta users will begin experiencing the failures as well. You are strongly encouraged to replace your certificate as soon as possible if your site is currently showing an error in Chrome Canary.

Chrome 70

Starting in Chrome 70, all remaining Symantec SSL/TLS certificates will stop working, resulting in a certificate error like the one shown above. To check if your certificate will be affected, visit your site in Chrome today and open up DevTools. You’ll see a message in the console telling you if you need to replace your certificate.

The DevTools message you will see if you need to replace your certificate before Chrome 70.

If you see this message in DevTools, you’ll want to replace your certificate as soon as possible. If the certificates are not replaced, users will begin seeing certificate errors on your site as early as July 20, 2018. The first Chrome 70 Beta release will be around September 13, 2018.

Expected Chrome Release Timeline

The table below shows the First Canary, First Beta and Stable Release for Chrome 66 and 70. The first impact from a given release will coincide with the First Canary, reaching a steadily widening audience as the release hits Beta and then ultimately Stable. Site operators are strongly encouraged to make the necessary changes to their sites before the First Canary release for Chrome 66 and 70, and no later than the corresponding Beta release dates.

Release	First Canary	First Beta	Stable Release
Chrome 66	January 20, 2018	~ March 15, 2018	~ April 17, 2018
Chrome 70	~ July 20, 2018	~ September 13, 2018	~ October 16, 2018

For information about the release timeline for a particular version of Chrome, you can also refer to the Chromium Development Calendar which will be updated should release schedules change.

In order to address the needs of certain enterprise users, Chrome will also implement an Enterprise Policy that allows disabling the Legacy Symantec PKI distrust starting with Chrome 66. As of January 1, 2019, this policy will no longer be available and the Legacy Symantec PKI will be distrusted for all users.

Special Mention: Chrome 65

As noted in the previous announcement, SSL/TLS certificates from the Legacy Symantec PKI issued after December 1, 2017 are no longer trusted. This should not affect most site operators, as it requires entering in to special agreement with DigiCert to obtain such certificates. Accessing a site serving such a certificate will fail and the request will be blocked as of Chrome 65. To avoid such errors, ensure that such certificates are only served to legacy devices and not to browsers such as Chrome.