Google Cloud NEXT '17 - News and Updates

Google Security Services for Android : Mobile Protections at Google Scale (Google Cloud Next ’17)

NEXT '17
Rate this post
(Video Transcript)
[MUSIC PLAYING] [VIDEO PLAYBACK] – Did you know Android has built in anti-virus protection that gets more powerful every second? It starts when an Android developer uploads their app to Google Play. A self-learning at-risk analyzer scans and simulates apps, looking for potential security issues. If there's an issue, the app won't appear in Google Play. On Android devices, Verify Apps regularly scans for harmful behavior, warning users, and then sending this information to the analyzer, so it keeps getting smarter. SafetyNet also scans devices for exploits and network vulnerabilities, protecting more than one billion devices daily and, again, sending data back to the analyzer to get more powerful. Android and Google Play– constantly making your mobile device safer at home, work, and everywhere in between. [END VIDEO PLAYBACK] EDWARD CUNNINGHAM: Well, good afternoon. I hope the video has given you a clue as to which session you're in. So this talk is going to be about Google security services for Android.

My name is Edward Cunningham, and I'm a project manager on the Android security team. So I hope that some of you may have caught the talk yesterday by Adrian Ludwig, who leads Android security, talking about the overview of Android security and its position in the ecosystem. If you didn't catch that, I recommend going and checking out the video that will be online. But I'll begin with a bit of an introduction that helps frame Google's services for Android security fit-in. And there'll be lots of time at the end for questions, so I hope we can have a good discussion. Android has become a part of the fabric of our daily lives, and nearly all of us interact with Android in some form each day, whether that's through the phone you use– 85% of smartphones are Android phones– or, perhaps, the phone of someone you communicate with, or maybe the TV you have– that could be running Android– or the point of sale system that you use in a store you visit. And securing all of these devices and different use cases is what many of us at Google on the Android security team get excited by each day as our mission.

But it's not just Google's job. Insuring and driving the security of this ecosystem is something that is performed by our partners, OEMs, enterprises, and developers too, so improving the security of this vast ecosystem is an exciting challenge. In this talk, I'm going to give you an insight into some of Google's many services for Android security and give specific examples of ways that you could take advantage of these services. The Android ecosystem consists of many millions of devices and apps and use cases, but at its core, consists of the people who use them. Android likely has the most diverse set of users of any computing platform today. And the range of threats that they encounter drives their security models and the protections we put in place. At one end of the spectrum, we have those who face, perhaps, the most advanced adversaries, the likes of world leaders, who are investing hundreds of thousands of dollars to protect their communications. And last year, we had that President Obama had started using Android phone for his presidential communications.

And his successor appears to have done likewise. But of course, Android security can't just be about those who can afford to pay a premium for security. Android phones are a critical lifeline for many of the most oppressed groups and persecuted people in the world today, such as refugees, who could be fleeing from oppressive regimes. Android brings them a way to communicate, to navigate, and it includes powerful security protections for those who can't afford to pay an extra dollar, euro, or pound for that security. Another example where the security guarantees in Android are driving new businesses and use cases is in the realm of gaming. Scenes like you see in the middle here were common last summer when the Pokemon Go phenomenon kicked off. The core of Pokemon Go's business model is a sophisticated approach to detecting abuse, and many other games rely on this similarly. Specifically, Pokemon Go uses Google's APIs on Android to detect fraudulent uses and devices, who would be performing fraud in their game.

And you'll have seen at the talk yesterday that all Android devices have a common set of security properties. This is what we describe as the platform security. This is built into the Android open source project, the foundational layers of security. This includes things like application isolation. The key part of this is the sandboxes that protect apps, make sure the data inside apps is for the app to use only, and that another app can't peer into the data from any other app. Device integrity is important. Features like verified boot ensure the integrity of the system partition with cryptographic checks. And data encryption, full disk encryption, makes sure the data, user data, is protected. Android has advanced exploit mitigation features, things like address space layout randomization or integer overflow protection ensure that it's hard to exploit vulnerabilities in the platform, even if they are present. And lastly, management capabilities– Android has built powerful capabilities, such as work profiles or administrative APIs to allow you to manage devices.

This is obviously important in being able to deploy Android devices in many different use cases, such as your enterprise. So across all modern Android phones, there's a relatively uniform set of capabilities. In fact, it could be said that across Android and iOS and Chrome OS, all modern mobile operating systems, that set of capabilities is pretty similar. And this is how the future of cloud computing is being shaped. Android is– one of the key parts of Android, I guess, is the research community around it. Being an open source program, we have hundreds of researchers, developers around the world contributing to that security. Last year, Android's vulnerability rewards program paid out over a million dollars to researchers. And as we build this ecosystem of research and development around Android security, we're bringing Android to new heights of security as we grow this protection year on year through the platform releases. On top of this solid foundation, Google builds security services to protect users from the risks they might face.

Building services on top of platforms is at Google's core. Like Google wasn't originally a platform provider, and so this is something that's being built into Android from the very first minute. And this is where SafetyNet comes in. SafetyNet is the collection of services that Google builds and freely deploys to protect users and keep the ecosystem safe. Our mission is to protect Android users with data-driven security apps and services. And this is what we're going to look at in this session. We provide comprehensive endpoint protection out of the box. From the very first moment a user starts using their device, they should have all the necessary protections in place to be and feel safe. The out of the box part is very important to us. We don't think a user should ever need to go and invest more money in security once they've got their device. It's a fundamental part of Android. It would be sad if you'd gone and paid $100, $200, even more for your phone, but then feel the need to pay $10 every month to get security.

But what we have here with SafetyNet offers that built in. So SafetyNet broadly maps into four segments, and this roughly forms the agenda for this talk. And then we're going to look at some of these in detail. First, Verify Apps, and this is what most people's minds jumped to when they think about Google's security services for Android. This is in the realm of harmful app detection, prevention, and removal. I'll show you some new features in Verify Apps and even some APIs, too, that you could use. Then we have the sensor network, which is rather more elusive. and this is our privacy-preserving security, analytics, and telemetry framework built into every Android device. This is how we can see across the Android ecosystem, the health of Android devices. It allows us to monitor the behavior of apps and see when things step out of line. And when something unusual happens on a device, we can use this sensor network to root cause that change, and then go and remediate where we are able.

The sensor network observes things like critical security settings, device integrity, and hundreds of other signals, which we'll look at, and I'll show you some examples of how that's interpreted. Next is SafetyNet developer APIs, and this is an area we've been investing in a lot in the last year. We want to provide ways for all developers to interrogate the state of security devices. It's all well and good for us to say Android is secure, but actually for an app or any code running on the device to be able to make good decisions about that is important. And this is getting more and more important every year. As we see, many of the critical decisions related to security being taken not just at the operating system level, but at the application level, so I'll cover three different APIs in this session, which I think could be of value. And last, we have Android Device Manager. If I was to rank these four in order of importance, this would clearly be at the top. This is addressing the largest risk Android users face when it comes to security, and that risk is, of course, losing a phone.

While we spend a lot of time, and we will in this talk, thinking about harmful apps or those sort of attacks, the reality is that the average Android user will never encounter one of these. But nearly every Android user will at some point misplace, lose, or have their phone stolen. So we need to have a tool to help users out in that occasion. So Android Device Manager is our tool to offer peace of mind in their time of need. And I'll show you a little bit about that towards the end of the talk. So the good news about all of these features is that they are available across most active Android devices. There's no need to have a new version of Android to use them. They're built on top of the platform. They're deployed through Google Play Services and the Google Play Store. And they are constantly updating. So I hope this comes as good news that users don't need to be buying a new phone to get these protections. In fact, a lot of the work we do is making sure that users who are running older versions of the operating system, potentially ones that aren't receiving security updates, will still get the core protections.

Here's the scale at which we operate. We're protecting over 1.4 billion devices all the time. The unique thing about SafetyNet is that we have an unparalleled view into the Android ecosystem to spot when things go wrong and to offer protection. We spot anomalies, and we can see trends that are emerging. We scan devices pretty rigorously. We're currently at about 750 million device scans a day. If I was to have given this talk a couple of months ago, that number would have been 400 million. We're ramping up very aggressively. And I'll show you how that works in a bit. But let's begin by talking about apps. We're scanning over six billion of them daily. The Google Play Store is a cornerstone of security for the Android ecosystem. Google Play allows users to get the most out of their devices by getting apps that they want to use to enable communication or games and so forth. And it's also enabling new business models for developers, giving them access to a vast audience of potential consumers.

With over a million apps on Google Play and 65 billion downloads, ensuring the safe distribution of these apps is imperative. So this diagram describes at a very high level the security lifecycle overlap that is distributed via Play. So we begin in the top left, where apps arrive on the Play Store. This is where a developer will upload an app in the form of an APK file to the Google Play Developer Console. To have been able to do this, the developer will have had to sign up for a publisher account. They'll have accepted the Play developer distribution agreement, and they will have to pay a registration fee. and for that registration to have been verified, details from the Google account that was used and billing information will have been used to process that registration. So once the app's uploaded, before it is actually published, it passes through our comprehensive review and an analysis pipeline. The first step of this is manual policy review. And every app that's published to Google Play is manually reviewed by a human for policy inspection.

So at this point, we'll look to see, does the app adhere to Google Play policies? And we'll check it doesn't contain violating content, things like spam or illegal content or impersonation. So once it's passed through, and it's got past that part of the check, we then enter our security analysis part of the pipeline, which is where automated analysis kicks in. This is in the realm of things like inspecting the code that's inside the app, the file is contained, and also running the app [INAUDIBLE] emulators. I'll give you an in-depth look at what that looks like in a couple of slides. So this analysis is performed on all the apps, and it passes to our score engine. And the score engine is really what makes a decision about whether the app is good or bad. Either the score engine notices some behavior, which is in line with known bad behavior, in which case the app will be rejected, or sometimes it's not sure about the app. It sees something suspicious, and then we pass it for another round of manual review.

And at this point, we end up in manual security review. This is where it's passed to an expert in app security analysis. And they will go and review that app, and then make a determination, either rejecting or approving it. And the decisions that are taken by those human analysts feed back into the score engine's future decision-making. So once it's got through this part of the flow, we end up all being well, as is the case for 99% of apps in the published state. Sometimes there are cases where we've spotted vulnerabilities in the app that aren't intentionally harmful. Perhaps the developer has included a vulnerable version of a library. An example of that would be if you include a version of open SSL that's old and it's vulnerable to the Logjam attack. So we would actually in this pipeline also expose to the developer in the Developer Console the information about that app and say, hey, you should probably go and fix this issue. There are numerous such vulnerabilities that we will alert developers to.

So this process is paralyzed, meaning that most apps going from upload to the published state get there in just a couple of hours or less. But it doesn't end there. Every app is constantly resubmitted through this pipeline, being reanalyzed and rescored every day. And the score engine is augmented with data from the sensor network. This is what I referred to in the previous slide, where the sensor network in Android devices is reporting back how those apps are behaving. So you can think about it, where we have the dynamic sort of analysis happening in Google's Cloud, where we're emulating these apps. We actually have a lot of data coming back from real devices running as apps. We also have Verify Apps, so if an app is determined to be harmful, Verify Apps operating on devices makes sure that no instances of that app are installed. It'll warn users about the app if it's installed already. It'll prompt them to uninstall. And Verify Apps prevents the app from being installed if it's distributed outside of Play as well.

And this is where it gets really exciting, because this process for Google Play is actually applied mostly, as I've shown here, for apps that we find outside of Google Play too. In fact, over 90% of apps that are installed from unknown sources or preloaded app stores or any other source have passed through our security analysis pipelines. So I've alluded to harmful apps. I thought it would be worth us thinking about what actually is a harmful app. At Google, we use the term, Potentially Harmful Apps, to talk about apps that we consider harmful in Android. And a potentially harmful app is an app that poses a potential security risk to users, their device, or their data. And we see these broken down into two main categories– those that abuse APIs and those that exploit vulnerabilities in the platform. With API abuse, we see apps that use Android APIs. They operate within the Android security model to perform a behavior that could be considered harmful. An example of this would be a phishing app.

Most phishing apps aren't exploiting the platform. They're using standard Android APIs and UI widgets to draw a convincing-looking login screen to phish for credentials. And this category of app in the realm of API abuse is by far the most common. Over 90% of PHAs that we see are in the realm of API abuse and social engineering. The other category would be described as exploits. This is where you're taking advantage of a gap or a hole that has been unpatched in Android. An example of this would be rooting, where people root their device, or privilege escalation, where you might break outside of the application sandbox in some other way. And this is less common, as I say– fewer than 10%. And if you're running an Android device that has got the latest security patches, typically, these sorts of PHAs are ineffective. Nearly every PHA we see is trying to make money in some way, and so it's frankly much simpler to do that as a malware offer by going down the API abuse path.

And the unique thing about our security team is that, of course, we're not just looking at what's going wrong and then trying to go and catch those apps, but we're able to effect change in the Android platform. So when we see API abuse, we can go and improve the APIs in the future versions of Android. An example of that would be we'd seen quite a lot of malware that abuses the device admin APIs to try and take the device hostage, prevent themselves from being uninstalled. And so in Android N, there were some improvements to those APIs to remove that sort of behavior it that was being commonly abused. So with that in mind, I'll now dive into more detail here about this app analysis. This is really looking at the core of our app risk analyzer. I'll talk about just a few of the specifics, so we begin with static analysis. This is where we go and essentially decompile the app, look at the static code, and we match that against the known patterns that are considered harmful.

We extract features and just look at everything that's contained within the APK file. The next part, dynamic analysis, is a lot more exciting. This is where we run the applications in our emulators. Every app we get hold of runs in our emulators in the cloud in a real Android environment. This is how we detect behavior that couldn't be seen through static analysis alone. We monitor things like network connections or interaction with other services on the device to come to a determination about behavior that could be considered harmful. I mentioned third party reports here. We would never claim that we were catching 100% of all bad apps. We're always trying to improve it. And one of the things that the Android security team has built out is very active relationships with the research community, as well as being provided with information that helps us improve this detection. So we have academic institutions, security companies, independent researchers, who are all tipping us off about new types of bad apps they find.

We build the protections into this analyzer service. And so fostering those relationships is very important. Developer relations, developer relationships– this is where, of course, when we see apps, either through Play or even outside of Play, we try and map the link between those developers. Through Play, it's, of course, a little bit easier, because we have Google accounts, and we'll try and find the relationships between those accounts, other activity they've performed on Google properties, and we find the link between apps. Even outside of Play, features of the app, such as the signing certificate or even the structure of the app itself give us a clue as to the link between developers and helps us incriminate apps based on other apps from the same developer. Next, we have the sensor network, and this is what I mentioned. This is the feedback loop for devices on the field. This really is the unique thing about our analysis. We're really able to augment what we see with the behavior apps for real.

This feedback comes into the risk analyzer and helps us identify apps that maybe weren't exhibiting that harmful behavior in the emulators. And similarity analysis– of course, most harmful apps we see are not brand new. They're not unique strategies that have been taken, and so we're able to compare the features of the code to see if they look like other ones we've previously flagged. And we're not doing this on a whim. We have 20,000 dedicated CPUs running 24 hours a day, seven days a week operating this pipeline. Each day, we're analyzing over half a million apps. As I mentioned, we get apps not just from Google Play, and in the last 30 days, we've crawled apps from over 100,000 different websites. And increasingly, we're able to turn to new forms of analysis. Machine learning models operating in our app risk analyzer have caught over 50% of harmful apps that were submitted to Play in the last month alone. I'll show you an example of that later on.

So with that in mind, what's the end result? This would be useless if we didn't think it was having an effect. At most conferences in the technology world, you're led to expect that all charts should be going up and to the right. So I'm sorry to disappoint you that this one is looking rather flat, but that's for good reason. Contrary to many of the reports in the media, mobile malware is not the next major threat to civilization. So this chart shows the percentage of Android devices, which have a known potentially harmful app installed over the last couple of years. And you'll see at the end of 2016, we're hovering and, in fact, declining a little bit around 0.69%. So that's less than 1% of devices that we've detected have a potentially harmful app installed. And that's the overall PHA rate for the ecosystem. We can break it down in many ways that give us a little bit more nuance into that figure. For example, there's huge geographic variation here.

One of the big focus areas for our team has been looking at PHA campaigns operating in the Southeast Asia region, especially on very low end phones, where, perhaps, they're not certified Android devices. Some of them are even coming with malware preloaded on the device out of the store. And so that's something we're working really hard to tackle. In fact, of the uncertified, unapproved Android devices, they have a 500% higher chance of seeing a potentially harmful app installed. So if we split into those users, who are installing from Google Play and those who are not and using other sources, we see another stark contrast. The Google Play figure is the line at the bottom here, where we see that just 0.05% of devices have encountered a potentially harmful app. And if you're operating inside a managed environment, of course, you can inform where your users end up on this sort of chart. You can decide to restrict your users to install from the Play Store. You can even go a step further if you're in a managed profile by using the managed Play features to restrict the apps that are available.

So I hope this is reassuring in that the instances of malware that we see are really quite rare. In the next– in a few weeks time, we're going to be releasing our 2016 annual Android security year-end review. so I'd encourage you to come check that out, because actually, it's many more insights like these and lots of other data from last year. So based on having identified harmful apps, what actually happens on devices? This screen on the right is what you'd see if you were trying to install a known PHA from an unknown source or from a third party store. As a reminder, of course, if we detect any PHA, that app will no longer be distributed through Google Play. So at install time, a user would never need to be worried about installing a harmful app from the Play Store. So we verify every installation that happens outside of Google Play. That includes any OEM store that's pre-loaded, any carrier store, or unknown sources that installs from third party app stores that the user might have downloaded or from file sharing, peer to peer, or the web.

And the result of this is that Verify Apps will either warn, block, or approve the install. This dialog is showing what happens when we warn to user. There are some types of harmful apps that we allow the user to proceed with the installation. In fact, if you were to click More Details here, you'd see there is a button that allows you to go and install the app. And sometimes we get asked, well, why do we allow users to install harmful apps? And the answer to that is that not every potentially harmful app is not wanted by the user. The most clear example of that would be rooting apps, where there are some number of Android users who would like to try and root their device to try and get new capabilities. And so our warning dialogs are mindful of that. We're not restricting that sort of behavior in the ecosystem. We perform a lot of US experiments with these dialogs. In fact, we reshuffled the screen that you see here at the end of 2015 to hide that Install Anyway button under the More Details, and we instantly saw a 50% reduction in the number of harmful apps being installed.

So we are trying very hard to make sure that users do the right thing. And we're not just warning on apps that we know to be harmful. Sometimes we'll have other clues that help us identify whether this install might be of concern. An example of that would be if we know it's been installed by an unusual UID, a Linux UID– it's not coming from an app or process that we expect to have the permission to install an app. Or maybe we see the install being triggered by another harmful app. We would warn the user in that case. And to give you a sense of scale, you might be wondering, how often do we show these things? So I looked up the numbers. For the length of time that I'm talking today, for yesterday, at the same time of day, we showed 1,000 of these warnings to people in the US. So it is not disproportionately large, but I hope that gives you an idea of how frequently we're having to warn about harmful apps. On the flip side of Verify Apps is the periodic scans. All installed apps, regardless of origin, are routinely checked for PHAs.

When we find a PHA, we put it into the stop state and make sure the app isn't running anymore. And then we either warn the user or remove the app entirely. And this notification on the right is what happens when we warn a user about a PHA that's been found. There's an Uninstall button there, or they can tap for the notification to find out more. And uninstalling PHAs is made easy by the application sandbox. The fact that apps are contained within an application sandbox means that uninstalling apps is not a very complicated task. We're able to very cleanly remove them from devices. For the last year and a half, we've been scanning every device in Russia daily for PHAs. That was to tackle some very persistent SMS forward campaigns, and we saw a huge improvements in the PHA rates for Russia in doing so. And so we're excited at the start of this year to now be expanding that coverage to every Android device in the world. So every device will be checking for installed PHAs daily in just a few weeks time.

And so Verify Apps isn't just operating there behind the scenes without you knowing as an application developer. So I'm excited to show you some new APIs that are coming in the forthcoming release of Google Play Services that you could inspect for the state of Verify Apps and take control. So we have an API called isVerifyAppsEnabled. It essentially does what it says on the tin. Verify Apps is enabled by default for anyone who signs into an Android device with a Google account or uses the Google Play Store. And for anyone who doesn't fall into either of those groups, but who side loads apps, installs from unknown sources, they'll be prompted to enable Verify Apps at each time that they install. So you can check if Verify Apps is enabled. If not, you can call the enableVerifyApps API. That will prompt the user to enable Verify Apps. And we have the listHarmfulApps API. That will tell you about any known harmful apps a user has willingly installed on that device. I'll give you a code example in a second.

I'll mention, finally, that today already, the platform has a restriction that you can put in place if you are able to use the DevicePolicyManager APIs for a managed device to ensure that Verify Apps is enabled. That forces Verify Apps to be turned on. The user couldn't choose to go and turn it off. So this is the listHarmfulApps API. It's incredibly straightforward to use, and it removes the need for you to necessarily build your own hacky solutions based on blacklisting, package names, or other sort of app matching or sending that back to your server. A use case here you could consider is if your enterprise app, you might want to be auditing for any harmful apps that are installed on users' devices. So you could call this API and send the results back to your server. As I mentioned, this API is part of Google Play Services, and you will use it by connecting to the SafetyNet API client through the Google API classes. So it returns the time of the last scan with the last scan time function.

That'll always be within the last 24 hours. We ensure that when you're calling this API that that is a fresh scan available. If for some reason, Verify Apps was not enabled, of course, at this stage, you could then go and call the enableVerifyApps API to make sure it was turned on. And then we have getHarmfulAppsList. This is a very underwhelming API call. 99.5% of the time, it will return absolutely nothing at all. It'll be an empty list, but let's take a look at what happens if there was to be something there. So there's a list of harmful apps data objects, and it contains information about an app to identify the harmful one. You can send this back to your server, for example. So first, we have a category. And this is used to define what type of harmful app it is. An example of this could be phishing or Trojan or SMS fraud or rooting. We published our classifications of PHAs online. You can search for our white paper, and it's also documented in the API documentation.

And then to identify the specific app, we include the package name of the app, as well as the Sha256# of the APK file. And then we include an example at the bottom here of what that could look like. Here we have a phishing app and its package name and digest. The digest is a way of uniquely identifying that APK file. So with that covered, let's talk about the sensor network. I think this is one of the more exciting parts, because it operates so behind the scenes, people don't typically know about it. So I'm glad to share some of that with you today. On the right, you see a warning dialog would pop up when a user– when an app tries to send a message to a premium rate SMS number. We ask the user, do you really want to send this? And the responses to that dialog are fed back into the sensor network, which help us to identify apps that could be performing SMS fraud. This is one example of the sort of data that the sensor network picks up, allowing us to identify bad apps. So the sensor network is fundamentally this feedback loop that pipes back into our app risk analyzer, helping us to identify new threats.

In a sense, SafetyNet is looking and keeping an eye on what happens on our device after the app is installed to make sure it doesn't step out of line. And the changes in state on that device can be attributed back to the app that was just installed. There are hundreds of signals. Some of them are listed here. For example, exploit attempt logging, system integrity checks, SELinux enforcement, network probes, which [INAUDIBLE] man in the middle attacks, that sort of thing that, SMS denials, and the core system security settings. So let's see one example. We perform statistical analysis on top of this, and, of course, operating at such huge scale across over a billion Android devices allows us to spot anomalies when they crop up. So this is one scorer that features in the scorer engine called the dead or insecure score. And what this tracks is how often devices disappear off our radar once an app is installed. Typically, we expect that when you install an app, that device should carry on checking back in with the sensor network the next day and the next day and the next day.

And so we measure for each app what the probability of that device checking back in the next day is, and so we look and compare that with the ecosystem average. Of course, there is some drop-off every day from normal device usage. Maybe I'm going to go and buy a new phone. But for apps where that differs significantly from the norm, we can go and investigate that app or very clearly identify that the app was doing something anomalous. And so this is what we use to go and flag new apps that cause devices to go dark, maybe because they try and turn off SafetyNet, or maybe they break the device so fundamentally that the user has to go and factory reset it. This has been very effective at detecting new rooting campaigns that we've looked at, such as Hummingbad or Ghost Push. And we published a blog post about this, so if you want to go and search for it, you can just search for dead or insecure score. Of course, we're not just limited to conventional statistical analysis. Machine learning is playing an increasingly key role in how we find harmful apps.

What you see here is a clustering of apps, of harmful apps based on their install patterns generated with a neural network using TensorFlow. This uses the technique called word embeddings, which has pioneered in the field of natural language processing, but applying it to apps instead. In a sense, the order in which apps are installed is quite similar to the order in which words are constructed in sentences. And so we can use the ordering an app installs to discern something about the apps themselves. So the result of this neural network is a vector for every app. And app vectors are positioned in vector space, such that apps that share common contacts or attributes or patterns show up in a similar area or vector space. So for example, we'd expect to find all the messaging apps showing up in one part of vector space or all of the gaming apps in another cluster. And this is true for PHAs too. So in this 2D embedding, you see here we've colored in all of the potentially harmful apps and their different categories.

And you see that they cluster in sometimes quite tight groups. For example, in the top left, we have a light blue section. Those are all SMS fraud apps. So hopefully, you can see how we're able to use this very powerfully to detect new types of harmful behavior for a new app that we haven't yet been able to classify. If we see that it's embedding, and vector space shows up within that cluster, we can begin to highly suspect that app is also being part of an SMS fraud campaign. Approaches like these are greatly improving our ability to detect new types of harm. So let's take a look at the attestation API. This is one of the most frequent APIs that I discussed with enterprises and developers. I think it could be powerful to use maybe for some of your use cases too. This screen here shows Android Pay deciding that it hasn't been able to determine the device security sufficiently to be able to run. They use the attestation API to determine this. Many apps have questions, such as, is the app talking to my server?

Is it actually my app? Can I trust the platform APIs? Is it a genuine device? Is my app running on a rooted phone? It is the SafetyNet attestation API that allows you to assess the security and compatibility of the Android environments in which your apps are running. So I'll briefly talk you through how this works. At a high level, what happens is you'll call the attestation API on a device, and then we all run through SafetyNet a series of checks to come to a decision about the device state. The result will come back from a Google server as a signed statement as to the device integrity and compatibility. And then you can inspect that signed statement on a device you trust– that's normally your server– to decide whether or not you're going to trust that app or that device. So you need both client and server side implementations. So you begin by calling the attest method of SafetyNet API, also in Google Play Services, with a single use token that identifies that request.

That token will have been sent by your server. And then that's the end of what you're going to do on your device. When you get the result back, you send that to your server. As you're using the attestation to decide if you trust the device, you don't want to be doing any checks on the device itself. So now on the server side, you pass back this result. It's in the form of adjacent web signature. And first, you want to validate the JWS. So the first step is validating the SSL certificate chain and checking that the leaf certificate matches what was issued to you at And then you'll verify that that certificate was used to sign the JWS. Now you can look at the actual contents of the JWS, which I'm showing on the right here. So you'll check the nonce matches the one that you requested. You'll check the timestamp is acceptably close to your request time. And then you can check the details about the app itself, so you can check, does the package name of the app match my own app?

Does the signing certificate hash match my own app? Even does the digest of the APK file itself match the APK that I produced? And this helps you determine on your server whether the Android app that is talking to you is really yours. Sometimes we won't include the APK information, and that's because we can't determine with any reliability that that is your app. Maybe it's a random script that is not even running on Android at all. And then you can look at the last two fields. We have CTS profile match and basic integrity, and those are really the key results here. CTS profile match is telling you, is this device definitely a device that has been approved and certified? All devices that are published or produced with Google services on them have to go through some rigorous certification. So you can check. Is it a certified device? And you can restrict the operation of your app to those devices. And then we have the basic integrity field, which is a slightly weaker check than CTS profile match.

That's now ignoring whether or not the device was certified and just checking, does the basic integrity of this device look like it is a compatible real Android environment that's not being tampered with in any way? So we got– I'll help you out with this, if you want to go check it out. I encourage you to go and see if this answers some of your questions that you might have. Like many apps are using their own basic rooting checks or integrity checks on device, which are trivially bypassed. And so SafetyNet attestation is the solution for that. We're obviously paying close attention to how well was this working, looking at researchers who are trying to bypass such restrictions. And as far as we can tell, it's holding up pretty well. In fact, one of the challenges you may face if you're operating a service that crosses many different platforms is that you're always limited by the weakest client that is going to talk to your server. So we start to see maybe Android apps that start to impersonate iOS apps or Windows apps or web clients to try and communicate with your server end points.

Another API that we expose is Safe Browsing. Safe Browsing is a Google service that's operated for many years but lets applications check whether a given URL is potentially harmful. With it, you can check pages against Safe Browsing different threat blacklists. You could warn users before they click on a link, or you could prevent users from sharing unsafe links. And on the right, you see the Chrome browser, which integrates with the SafetyNet Safe Browsing API for every URL that is loaded in Chrome. And here, they're warning the user, because it looks like this page distributes malware. The Safe Browsing API is very straightforward. It's pretty much the code I've shown here. You first have to register an API key, which you can get on the Google Cloud console. And then you call look up URI with the URL and the threat types that you are concerned about. At the moment, we have social engineering and potentially harmful apps. And then we give you a result, which is whether or not that URL matched any of the known threat types.

This is a case where most of the time, you will also return an empty list, in which case that's good news. And the Safe Browsing API is designed to be privacy-preserving and bandwidth-efficient. The URL that you're checking with the Safe Browsing API is never sent off the device. And so this is a really great way of maintaining the privacy of that link. We're also frequently syncing the blacklist on device in a very efficient way, so it's not consuming resources or bandwidth unnecessarily for the user. So last, we're going to jump to Android Device Manager. If you haven't used it, I'd encourage you to go and check it out. Android Device Manager is this tool that allows you to find, locate, ring, wipe any Android device. And it's built into every Android device running Google services by default. There's no setup needed. All you need to do is sign into the Google account, and that then it's enabled. It's active. You don't even have to have an app installed on your device.

You're able to go and load it up off the website or install the Android app to go and ring, lock, or erase any devices that your account is signed into. And we have integrations with Google search, so if you were signed into your Google account or Google search, and you go and search Find My Phone, we'll show you a one-box result showing where your phone is. Or maybe you have an Android Wear watch, and you've misplaced your phone, but you can use your watch to ring your phone too. That's all part of Android Device Manager. And this works from Android 2.3 up, so it's enabled for pretty much every device that is active today. We're locating hundreds of thousands of phones every single day. So with that, that's brought us to the end of my survey of all the components of SafetyNet. We talked about Verify Apps, which is harmful app detection and removal, the sensor network, which is providing security analysis and telemetry, helping us to identify harmful apps, powerful developer APIs allowing you to inspect the security of a device and make decisions, and Android Device Manager, lost device protection.

And the exciting thing about this is that it's updating all the time. Whenever we come and present what's going on, there's always something new to add. We're working every day to develop these and deploy new versions to offer better protection to users without them having to pay for anything. So before I take any questions, just a reminder that if you're interested in knowing more about how either Android or Chrome or Google Cloud fits into your enterprise environment, you can go and visit this not particularly easy to pass link to learn more about our connected workspace information and sign up to get advanced access, perhaps, to some of our upcoming reports, such as the Android security year review. With that, I'd like to thank you for attending, and I'll be around for any questions. [APPLAUSE] [MUSIC PLAYING]


Read the video

Google SafetyNet and Verify Apps protects over 1 billion Android devices with built-in endpoint security services, anti-virus, and protection for lost and stolen devices. Watch this video to learn about how these systems work, and how to best incorporate them into your enterprise and applications.

Missed the conference? Watch all the talks here:
Watch more talks about Mobility & Devices here:

Leave a Comment

Your email address will not be published. Required fields are marked *

1Code.Blog - Your #1 Code Blog