Tag Archives: Security

Leveraging AI to protect our users and the web

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.

DNS over TLS support in Android P Developer Preview

Posted by Erik Kline, Android software engineer, and Ben Schwartz, Jigsaw software engineer

[Cross-posted from the Android Developers Blog]

The first step of almost every connection on the internet is a DNS query. A client, such as a smartphone, typically uses a DNS server provided by the Wi-Fi or cellular network. The client asks this DNS server to convert a domain name, like www.google.com, into an IP address, like 2607:f8b0:4006:80e::2004. Once the client has the IP address, it can connect to its intended destination.

When the DNS protocol was designed in the 1980s, the internet was a much smaller, simpler place. For the past few years, the Internet Engineering Task Force (IETF) has worked to define a new DNS protocol that provides users with the latest protections for security and privacy. The protocol is called "DNS over TLS" (standardized as RFC 7858).

Like HTTPS, DNS over TLS uses the TLS protocol to establish a secure channel to the server. Once the secure channel is established, DNS queries and responses can't be read or modified by anyone else who might be monitoring the connection. (The secure channel only applies to DNS, so it can't protect users from other kinds of security and privacy violations.)

DNS over TLS in P

The Android P Developer Preview includes built-in support for DNS over TLS. We added a Private DNS mode to the Network & internet settings.
By default, devices automatically upgrade to DNS over TLS if a network's DNS server supports it. But users who don't want to use DNS over TLS can turn it off.

Users can enter a hostname if they want to use a private DNS provider. Android then sends all DNS queries over a secure channel to this server or marks the network as "No internet access" if it can't reach the server. (For testing purposes, see this community-maintained list of compatible servers.)

DNS over TLS mode automatically secures the DNS queries from all apps on the system. However, apps that perform their own DNS queries, instead of using the system's APIs, must ensure that they do not send insecure DNS queries when the system has a secure connection. Apps can get this information using a new API: LinkProperties.isPrivateDnsActive()

With the Android P Developer Preview, we're proud to present built-in support for DNS over TLS. In the future, we hope that all operating systems will include secure transports for DNS, to provide better protection and privacy for all users on every new connection.

DNS over TLS support in Android P Developer Preview

Posted by Erik Kline, Android software engineer, and Ben Schwartz, Jigsaw software engineer

The first step of almost every connection on the internet is a DNS query. A client, such as a smartphone, typically uses a DNS server provided by the Wi-Fi or cellular network. The client asks this DNS server to convert a domain name, like www.google.com, into an IP address, like 2607:f8b0:4006:80e::2004. Once the client has the IP address, it can connect to its intended destination.

When the DNS protocol was designed in the 1980s, the internet was a much smaller, simpler place. For the past few years, the Internet Engineering Task Force (IETF) has worked to define a new DNS protocol that provides users with the latest protections for security and privacy. The protocol is called "DNS over TLS" (standardized as RFC 7858).

Like HTTPS, DNS over TLS uses the TLS protocol to establish a secure channel to the server. Once the secure channel is established, DNS queries and responses can't be read or modified by anyone else who might be monitoring the connection. (The secure channel only applies to DNS, so it can't protect users from other kinds of security and privacy violations.)

DNS over TLS in P

The Android P Developer Preview includes built-in support for DNS over TLS. We added a Private DNS mode to the Network & internet settings.

By default, devices automatically upgrade to DNS over TLS if a network's DNS server supports it. But users who don't want to use DNS over TLS can turn it off.

Users can enter a hostname if they want to use a private DNS provider. Android then sends all DNS queries over a secure channel to this server or marks the network as "No internet access" if it can't reach the server. (For testing purposes, see this community-maintained list of compatible servers.)

DNS over TLS mode automatically secures the DNS queries from all apps on the system. However, apps that perform their own DNS queries, instead of using the system's APIs, must ensure that they do not send insecure DNS queries when the system has a secure connection. Apps can get this information using a new API: LinkProperties.isPrivateDnsActive().

With the Android P Developer Preview, we're proud to present built-in support for DNS over TLS. In the future, we hope that all operating systems will include secure transports for DNS, to provide better protection and privacy for all users on every new connection.

Protecting users with TLS by default in Android P

Posted by Chad Brubaker, Senior Software Engineer Android Security
[Cross-posted from the Android Developers Blog]

Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting all data that enters or leaves an Android device with Transport Layer Security (TLS) in transit. As we announced in our Android P developer preview, we're further improving these protections by preventing apps that target Android P from allowing unencrypted connections by default.

This follows a variety of changes we've made over the years to better protect Android users. To prevent accidental unencrypted connections, we introduced the android:usesCleartextTraffic manifest attribute in Android Marshmallow. In Android Nougat, we extended that attribute by creating the Network Security Config feature, which allows apps to indicate that they do not intend to send network traffic without encryption. In Android Nougat and Oreo, we still allowed cleartext connections.

How do I update my app?

If your app uses TLS for all connections then you have nothing to do. If not, update your app to use TLS to encrypt all connections. If you still need to make cleartext connections, keep reading for some best practices.

Why should I use TLS?

Android considers all networks potentially hostile and so encrypting traffic should be used at all times, for all connections. Mobile devices are especially at risk because they regularly connect to many different networks, such as the Wi-Fi at a coffee shop.

All traffic should be encrypted, regardless of content, as any unencrypted connections can be used to inject content, increase attack surface for potentially vulnerable client code, or track the user. For more information, see our past blog post and Developer Summit talk.

Isn't TLS slow?

No, it's not.

How do I use TLS in my app?

Once your server supports TLS, simply change the URLs in your app and server responses from http:// to https://. Your HTTP stack handles the TLS handshake without any more work.

If you are making sockets yourself, use an SSLSocketFactory instead of a SocketFactory. Take extra care to use the socket correctly as SSLSocket doesn't perform hostname verification. Your app needs to do its own hostname verification, preferably by calling getDefaultHostnameVerifier() with the expected hostname. Further, beware that HostnameVerifier.verify() doesn't throw an exception on error but instead returns a boolean result that you must explicitly check.

I need to use cleartext traffic to

While you should use TLS for all connections, it's possibly that you need to use cleartext traffic for legacy reasons, such as connecting to some servers. To do this, change your app's network security config to allow those connections.

We've included a couple example configurations. See the network security config documentation for a bit more help.

Allow cleartext connections to a specific domain

If you need to allow connections to a specific domain or set of domains, you can use the following config as a guide:
<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

If your app supports opening arbitrary content from URLs over insecure connections, you should disable cleartext connections to your own services while supporting cleartext connections to arbitrary hosts. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.

<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?

If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.

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

Cross-posted from the Google Security Blog.

We previously announced plans to deprecate Chrome’s trust in the Symantec certificate authority (including Symantec-owned brands like Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL). This post outlines how site operators can determine if they’re affected by this deprecation, and if so, what needs to be done and by when. Failure to replace these certificates will result in site breakage in upcoming versions of major browsers, including Chrome.

Chrome 66

If your site is using a SSL/TLS certificate from Symantec that was issued before June 1, 2016, it will stop functioning in Chrome 66, which could already be impacting your users.

If you are uncertain about whether your site is using such a certificate, you can preview these changes in Chrome Canary to see if your site is affected. If connecting to your site displays a certificate error or a warning in DevTools as shown below, you’ll need to replace your certificate. You can get a new certificate from any trusted CA, including Digicert, which recently acquired Symantec’s CA business.

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.


Posted by Devon O’Brien, Ryan Sleevi, Emily Stark, Chrome security team

Android Security 2017 Year in Review

Originally posted by Dave Kleidermacher, Vice President of Security for Android, Play, ChromeOS, on the Google Security Blog

Our team's goal is simple: secure more than two billion Android devices. It's our entire focus, and we're constantly working to improve our protections to keep users safe.

Today, we're releasing our fourth annual Android security year in review. We compile these reports to help educate the public about the many different layers of Android security, and also to hold ourselves accountable so that anyone can track our security work over time.

We saw some really positive momentum last year and this post includes some, but not nearly all, of the major moments from 2017. To dive into all the details, you can read the full report at: g.co/AndroidSecurityReport2017

Google Play Protect

In May, we announced Google Play Protect, a new home for the suite of Android security services on nearly two billion devices. While many of Play Protect's features had been securing Android devices for years, we wanted to make these more visible to help assure people that our security protections are constantly working to keep them safe.

Play Protect's core objective is to shield users from Potentially Harmful Apps, or PHAs. Every day, it automatically reviews more than 50 billion apps, other potential sources of PHAs, and devices themselves and takes action when it finds any.

Play Protect uses a variety of different tactics to keep users and their data safe, but the impact of machine learning is already quite significant: 60.3% of all Potentially Harmful Apps were detected via machine learning, and we expect this to increase in the future.

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 user 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, totalling more than two million dollars since the start of the program. 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 also 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.

Android Security 2017 Year in Review

Posted by Dave Kleidermacher, Vice President of Security for Android, Play, ChromeOS

Our team’s goal is simple: secure more than two billion Android devices. It’s our entire focus, and we’re constantly working to improve our protections to keep users safe.
Today, we’re releasing our fourth annual Android Security Year in Review. We compile these reports to help educate the public about the many different layers of Android security, and also to hold ourselves accountable so that anyone can track our security work over time.
We saw really positive momentum last year and this post includes some, but not nearly all, of the major moments from 2017. To dive into all the details, you can read the full report at: g.co/AndroidSecurityReport2017

Google Play Protect

In May, we announced Google Play Protect, a new home for the suite of Android security services on nearly two billion devices. While many of Play Protect’s features had been securing Android devices for years, we wanted to make these more visible to help assure people that our security protections are constantly working to keep them safe.

Play Protect’s core objective is to shield users from Potentially Harmful Apps, or PHAs. Every day, it automatically reviews more than 50 billion apps, other potential sources of PHAs, and devices themselves and takes action when it finds any.

Play Protect uses a variety of different tactics to keep users and their data safe, but the impact of machine learning is already quite significant: 60.3% of all Potentially Harmful Apps were detected via machine learning, and we expect this to increase in the future.
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.

Cryptography, Cloud and Equality: a Q&A with Google Security expert Maya Kaczorowski

Note from the editor: What do Julie Payette, Indira Samarasekera and Jenni Sidey have in common? They are just some of Canada’s fierce female masterminds who’ve graduated in the field of either science, technology, engineering or mathematics (STEM) and who continue to impact our society. We already have plenty of talent in Canada. However, we are not turning out enough computer science graduates to keep up with demand, especially not enough women. It's never been more critical that we give our young girls the tools they need to become the technology builders of tomorrow. One of the ways we can better equip them, is by exposing young women to how their future studies could directly apply in the real world and make them aware of the exciting career opportunities in STEM. In the hopes of doing just that, we’ve sat down for an interview with one of own trailblazers, Montrealer Maya Kaczorowski, a Product Manager at Google in Security & Privacy. 


Can you tell us about your current role at Google and how you got here? 
Currently, my focus is on securing workloads running in containerized environments – which is a mouthful! To clarify, containers are a relatively new way of running workloads especially in the cloud. Our team uses tools such as Docker and Kubernetes which ultimately make our customer’s applications more portable.

Prior to this, I focused on encryption at rest and encryption key management, and was the Product Manager for Google Cloud Key Management Service (Cloud KMS). Before joining Google, I worked as a management consultant at McKinsey & Company, serving financial, healthcare and insurance customers on a variety of topics, where I discovered my passion for security strategy.
What’s your educational background?
I completed a BA&Sc in Mathematics and Economics at McGill University in Montreal and then pursued a Master in Science in Applicable Mathematics, focusing on cryptography and game theory at the London School of Economics.

Can you tell us what motivated you to pursue a career in science and technology? 
I always liked solving puzzles and when I took a number theory class at McGill, I realized cryptography was a great mesh of puzzles, math, and practical use cases in security. I pursued my interest in cryptography, and ended up doing a Master's degree in the field. It wasn’t a straight path from there to a technical role in the industry, however, by seizing the right opportunities when they arose, I ultimately ended up in role that was meant for me, at Google working with the encryption team. I’m especially excited about working in infrastructure security, which is a huge focus given the uptake of the cloud industry. There’s a lot of opportunity for development, and for innovation in this space.

What challenges did you face as a woman during your studies and then throughout the course of your career?
Being taken seriously has always been difficult. I can remember going to some of my first conferences in security, and people asking me if I was a reporter, or what I ‘really’ worked on, even if I had Google written on my badge. No one will give you the benefit of the doubt, you have to initially prove yourself. I’m lucky that I had the opportunities to do so, and the courage to not let people dismiss me easily.
Why is now a great time for women to pursue careers in tech?
There are two complementary forces at work - it’s a friendlier and more attractive industry for women; and companies are also realizing they need women to be more successful. In general, there are already more women in tech, and more women in leadership roles - mentoring and acting as role models for the next generation of women.

Why are women uniquely qualified to excel in some of these leadership roles? 
Without over-generalizing, women bring different viewpoints to the workplace. Research has shown that more diverse teams lead to better business outcomes, and teams with more women tend to have more individuals actively participating in decision-making processes. In any product, but especially in security, having individuals from a variety of backgrounds leads to building better, more useful products.

What advice would you have for other women considering following a career in science and tech? 
Simply, just go for it. Given how accessible information and tutorials are nowadays, you can teach yourself anything. I often see people falter in their belief that they need to have gone to a particular school, or have a particular degree, or particular life experience, in order to have a particular job. Compared to men, women are less likely to apply to jobs where they don’t meet all the requirements, but there’s really no harm in trying. Ask others in the industry how they got where they are, teach yourself that, ask questions where you don’t understand, and go for it.

Additionally, when I studied mathematics, about half of my class was women - which I know is unusual. We were a headstrong bunch, each taking on leadership roles in student government, research, and other campus activities; and standing up for each other if needed. I would encourage women to support each other and to take on leadership roles either within your program of study, in the community or specific ecosystem they are aiming to persevere in.
What do you think would encourage more women to pursue studies in science and technology? 
I don’t think there’s an easy solution to gender equality in tech, which is why we’re all trying to improve it! I think having more exposure to how your studies are directly applicable in the real world, in the form of internships and co-ops, helps any student get a better idea of whether or not this work interests them, and what’s needed to be successful.

Cryptography Changes in Android P

Posted by Adam Vartanian, Software Engineer

We hope you're enjoying the first developer preview of Android P. We wanted to specifically call out some backward-incompatible changes we plan to make to the cryptographic capabilities in Android P, which you can see in the developer preview.

Changes to providers

Starting in Android P, we plan to deprecate some functionality from the BC provider that's duplicated by the AndroidOpenSSL (also known as Conscrypt) provider. This will only affect applications that specify the BC provider explicitly when calling getInstance() methods. To be clear, we aren't doing this because we are concerned about the security of the implementations from the BC provider, rather because having duplicated functionality imposes additional costs and risks while not providing much benefit.

If you don't specify a provider in your getInstance() calls, no changes are required.

If you specify the provider by name or by instance—for example, Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC") or Cipher.getInstance("AES/CBC/PKCS7PADDING", Security.getProvider("BC"))—the behavior you get in Android P will depend on what API level your application targets. For apps targeting an API level before P, the call will return the BC implementation and log a warning in the application log. For apps targeting Android P or later, the call will throw NoSuchAlgorithmException.

To resolve this, you should stop specifying a provider and use the default implementation.

In a later Android release, we plan to remove the deprecated functionality from the BC provider entirely. Once removed, any call that requests that functionality from the BC provider (whether by name or instance) will throw NoSuchAlgorithmException.

Removal of the Crypto provider

In a previous post, we announced that the Crypto provider was deprecated beginning in Android Nougat. Since then, any request for the Crypto provider by an application targeting API 23 (Marshmallow) or before would succeed, but requests by applications targeting API 24 (Nougat) or later would fail. In Android P, we plan to remove the Crypto provider entirely. Once removed, any call to SecureRandom.getInstance("SHA1PRNG", "Crypto") will throw NoSuchProviderException. Please ensure your apps have been updated.

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

Posted by Devon O’Brien, Ryan Sleevi, Emily Stark, Chrome security team

We previously announced plans to deprecate Chrome’s trust in the Symantec certificate authority (including Symantec-owned brands like Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL). This post outlines how site operators can determine if they’re affected by this deprecation, and if so, what needs to be done and by when. Failure to replace these certificates will result in site breakage in upcoming versions of major browsers, including Chrome.

Chrome 66

If your site is using a SSL/TLS certificate from Symantec that was issued before June 1, 2016, it will stop functioning in Chrome 66, which could already be impacting your users.
If you are uncertain about whether your site is using such a certificate, you can preview these changes in Chrome Canary to see if your site is affected. If connecting to your site displays a certificate error or a warning in DevTools as shown below, you’ll need to replace your certificate. You can get a new certificate from any trusted CA, including Digicert, which recently acquired Symantec’s CA business.
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.