R4iDGm3w

1[MUSIC PLAYING] DARREN KRAHN: Welcome to our talk today on device provisioning and authentication with Android Things. My name is Darren. I'm a software engineer. And I work on security for Android Things. WAYNE PIEKARSKI: Cool. So I'm Wayne Piekarski. I'm a developer advocate for Android Things and IoT. And so thanks for coming today to our talk. And today, we're going to talk to you about the strategies of getting your IoT devices connected to the internet, to the cloud, and everything else. So we're going to go through the whole process end to end. And we're going to talk about how Google software platforms, such as Android Things, Firebase, and Cloud IoT Core, help to make this much easier to do. So, as many of you probably know-- and that's why you're here today-- is that IoT is huge. And it's going to be bigger than anything we've seen before. So in the same way that we saw phones were orders of magnitude larger than PCs, I think we're going to see IoT devices being orders of magnitude larger than them. We're going to be surrounded by IoT devices on a day-to-day basis that do all kinds of different tasks for us. And there's not going to be just one device. You're going to have tens or hundreds of them doing all kinds of interesting things. And so today, we're going to give you some hints as to ideas on how to best build these kind of IoT devices and how to connect them, secure them, and so forth. So firstly, let's discuss the basics of Android Things. Hopefully, most of you have seen the intro talk. If you haven't, we have a bunch of talks here at IO that cover what Android Things is. But the core concept of Android Things is that it's based on a system on a module, which is shown in the image over there, which is the little small board. And so the SOM contains the CPU, the Wi-Fi, the memory. And it's supported by what we call a board support package. And this provides the drivers, the kernels, the libraries, and everything. But it also provides updates and security from Google. And, using an Android Thing SOM, it makes it really easy for developers to build IoT devices and also to help ensure that they're secure and that they're kept up to date, because those are the kind of things that consumers need now with their devices. One other thing that makes Android Things unique is that it supports really powerful types of processing on device. So you don't need to do things in the cloud, but you can do video and audio processing, you can do machine learning, and you can do everything on device, because we have phone-level CPU performance on these Android Things SOMs. And the other thing is that it's based on Android. So you can use all of the familiar developer tools that you're used to, such as Android Studio and all the existing code that you have, if you're an Android developer. And so you'll be right at home using Android Things if you've done Android development before. So there are lots of other talks at IO that you can go to learn more about that. But what we're going to focus on today is how we can take advantage of all these things that come with Android Things to make your IoT devices easier and better for you. So with that in mind, let's get into an example that we're going to use throughout this talk to sort of explain what we're talking about. So we're going to build an IoT washing machine, because why not? And everyone's excited about using machine learning and TensorFlow. So therefore, we probably should be using a washing machine that does machine learning on-board. It should have a camera that looks at your laundry. And then, while it's washing your clothes, it does machine learning algorithms to analyze how clean it is. And it can also allow you to see how your laundry is being washed when you're at work, in case you're interested in seeing this kind of thing happen. So I guess we could call our new product "TensorWash." So when we build this "TensorWash" washing machine, most washing machines still have a control panel on the front, because you still want to control it manually. Now, because Android Things supports really powerful devices, you could actually have a screen on the front. It could run OpenGL. You could have videos and audio playing. So that's one option that you could build, maybe in the deluxe model of the machine. However, if you want to reduce the cost to make a cheap IoT washing machine, then you probably want to get rid of the display. And so we're going to leave that out for this example. So the machine is going to be IoT enabled. It's going to have a few buttons on the front. But pretty much everything is going to be controlled via a phone, which we're going to talk about in a bit. So the real magic of a machine like this is when it's connected to the internet. And so you can monitor the machine remotely. You can view what the camera sees. You can trigger off a wash cycle when you're at work, when you're driving home or whatever. So the user is not in the house, and they could be potentially anywhere in the world. So we don't want to restrict it to just being controlled from something that's close by in the house. So we really need to have an internet cloud-based connection with some kind of cloud solution behind that. And we could add all kinds of fun features by having cloud support. So we could have it awarding points for not washing your clothes or not wasting water too much. It could report faults to a service department. And in order to support all this, the machine needs Wi-Fi. And we're not going to cheat by just plugging in an ethernet cable into it. So we have this washing machine. We need it to connect to the cloud. And we need to share state with the cloud so that a phone could control the device. So there are many possible cloud services. We'll talk about a few of them today. But firstly, in order to make this kind of thing work, we need to firstly get the device onto the network. And so many devices these days are Wi-Fi based, so the device requires an SSID and a passphrase to join the network. Many devices don't have a keyboard or a display, like in the case of our washing machine, so everything needs to be handled by the phone. And if we use a phone, then the device needs to spin up a Wi-Fi access point of its own. The phone connects to it. It sends all the login [INAUDIBLE] over. And then the device reconnects to the network and uses that information. And if anything goes wrong for any reason, the phone has no way of knowing what happened. And so it's a very delicate process. And so it can be problematic for some phones or Wi-Fi networks. And so many developers find this challenging to get right. So we're going to go through some hints on how to make this better. And next, the device needs to know who the owners of the device are, so you want to make sure that the device is viewed and controlled only by the owner of the device and anyone else that they trust. So we need some kind of authentication token that needs to be issued by a server that the user then uses to control this token. We put it on the device. And then that's what the device uses to contact the internet and the cloud. If the user factory resets the device, then we need to forget this token and everything else. And then the device should reset itself so that a different user could use the machine, and none of the previous history is preserved. So now, our "TensorWash" is all connected and ready to go. So when the phone, device, and cloud all communicate, we do that over a TLS connection, such as HTTPS. So it's very important that it's secure in that way. We don't want to have eavesdroppers in the middle. Google services generally these days require HTTPS. And we're actually starting to enforce this by default. So we're making it harder now for you to use unencrypted connections because of all the security implications. And it's important that, when you build devices like this, that everyone does security properly, even tiny IoT companies that are making really simple little toys or whatever, because everyone always thinks that their device is not going to be the problem, and then even small problems can have unexpected impacts in ways that you just didn't even dream of later on once your device is out in the world. So that's it. That's the key concepts of what you need to get a washing machine that we're building and get it connecting up to the cloud. So we need to set up Wi-Fi. We need to transfer the credentials. And then we need to connect with encryption. But there's actually a lot more to it. So what I'm going to do is I'm going to let Darren now do a deep dive on some of the key concepts here and a bit more of an explanation as to what's going on. DARREN KRAHN: Cool. So I want to take a step back and talk about a few of these key concepts that we use to establish secure relationships between devices, which is fundamentally what we're doing when we provision devices. These concepts are distinct, but they're very much intertwined in practice, as you'll see. I want to talk about authentication, authorization, and attestation. First, authentication. To authenticate something is simply to prove that it is genuine or valid, that it's authentic. We authenticate works of art, official documents, handwritten signatures. We also authenticate each other, mostly using face recognition. This is very natural to us. It's very intuitive. Computers often authenticate us using passwords. Automobiles often authenticate us using keys. So we use authentication all the time in our daily lives without really even thinking about it. But what about when one computing device needs to authenticate to another computing device? This is less intuitive for us to think about. Often, what it involves is secret data. So the authentic computer has access to secret data, and all the other computers don't. And so there's two forms that this secret data can take that I want to talk about. One is cryptographic keys. And the other is bearer tokens. There are other ways to authenticate. But these are very common, and they'll directly relate to our "TensorWash" example. I'm going to dig into each one of them a little bit. So cryptographic keys and certificates are very common on the web. This is how your web browser would authenticate a web server-- using HTTPS, for example. The authentication involves verifying their certificate, verifying the information in the certificate, verifying it against something you already trust or that you expect, verifying the authority that issued that certificate is something that you trust. We also need to verify the proof of possession of a key. The key itself is not transferred across the network, or at least, not the private part of the key. But we need to check that the other computer has possession of it, and it gives us a proof of that. So doing this right in practice can be really hard. Building these protocols can be really hard. I strongly recommend you don't build this yourself. Find a good library that does it. If you use Android Things, we have support for HTTPS and TLS built in, and so you don't have to implement any of this. So I like to compare this kind of authentication to an airport passport check. If you imagine, you take your passport and you come up to the check, the agent there is going to validate specific information on the passport. They're going to verify that it is from an authority that they trust. And then they're going to do a proof of possession check, which, in the case of the passport, is a match of the picture with the face of the person standing in front of them. I also want to talk about bearer tokens. These work a little bit differently. They're passed from one computer to another in order to verify them. They're often opaque to the computer that sends it, but meaningful, of course, to the computer that verifies it. Authentication of the sender or bearer of the token is implied by the authentication of the token. The verifier looks at the token and makes a decision as to whether it's an authentic token or not. I like to compare this to the example of a movie ticket. You go to the ticket stand, and you buy a movie ticket. That ticket becomes your bearer token. You go into the theater, you present that token, you're allowed in. You pass that ticket to your friend. Your friend is now the bearer of that token, and they can get into the movie. So often, these kinds of tokens are used to represent a more thorough authentication that happened in the past. Here's another good example. On the web, when you have a website that requires a login, you log in with the username and password. And imagine if you had to type your password again for every page within that site. Navigate to a new page, type your password again. It wouldn't be usable. And so often, what happens under the hood is a web server will issue your browser a bearer token. And it will live for a certain amount of time, and it'll have access to your account, whatever that means on that website. And so you don't have to keep entering your password all the time. And it works the same way with an IoT device. You can investigate it thoroughly once, issue it a token, and you get a much lighter authentication mechanism from that point forward. So let's think about authentication in the context of IoT. There's a few aspects that are worth calling out. One is that the authentication needs to go both ways. The services and other devices around a device need to authenticate that device. And that device needs to authenticate the other services, the other devices around it. So for example, a device would authenticate a web service, same way that a browser would authenticate a web service using HTTPS or TLS. Also, authentication does not necessarily mean a verification of identity. Often, we think of it that way, but it doesn't necessarily have to be that way. Take the example of a restricted web service. Suppose you [INAUDIBLE] web service, but it's intended for instances of your product to connect back to that web service. And you want to make sure that all the clients are actually instances of that web service. What you want to do is authenticate that it's one of your devices, but you don't actually care which one. You can actually do an anonymous authentication, in that case. Also, we need to bind authentication to meaningful expectations. We want to make sure that we're authenticating what we're thinking, what we are expecting to authenticate. Let me give you a couple of examples. If there's a device in front of you, and you want to authenticate that device, you bind it to something physical. Find something physical in the device. If the device has a screen and you can display a code both on your phone and on the screen, for example, that's a physical binding of that authentication. That's a common experience when you do a Bluetooth pairing or something like that. But you can also use a sticker on the device or a barcode. And we'll talk about that a little bit more. Same thing goes with an encrypted channel. If you've established an encrypted channel and then you need to authenticate that channel, bind your authentication to that channel. So if you're using a standard protocol like TLS or HTTPS, this is already done for you. You don't have to worry about it. But if you're doing some things between two devices, for example, and they don't support that kind of a protocol, then you need to think about this. So let's go back to our "TensorWash" example and take a look at all the authentication that needs to happen. So we'll start in the completely unprovisioned state. So we just took our "TensorWash" machine out of the box. So let's assume that our smartphone's already set up. Our smartphone is able to authenticate web services using HTTPS, TLS. And also, in our case, let's assume that we have a Google account we've logged into on the phone. And so those web services are able to authenticate the phone. And so there's a two-way authenticated relationship there. The first thing we need to do is we need to authenticate this new device. What we want to do is we want to send it credentials. Those credentials can be valuable-- Wi-Fi passwords, access to cloud services. And we want to make sure we're sending it to the right device before we send it over. And once we've provisioned that, we want to end up in the state where we have two-way authenticated relationships between the "TensorWash" machine and cloud services. So I've given two examples here, Firebase and Cloud IoT Core that we're going to use with "TensorWash." And for both of these, we want a two-way relationship. Again, authenticating web services, we'll use the standard TLS HTTPS. And we'll use different forms, which we'll talk about in more detail a little bit later to authenticate the device. But those credentials are going to be provisioned during this process from the phone. So you may have noticed that there is one authentication that didn't go both ways in my example. What about this one, here in yellow, from "TensorWash" to the phone. Is it OK for the "TensorWash" device to come out of the box and not authenticate the phone that's going to set it up? So we've put it this way, because it's really common for consumer devices. When they come out of the box, they're in a clear state. They don't have any notion of who their owner is or who they trust. They're just available to be set up. And so we wanted to build out this case. And mostly, that's OK. It doesn't come out of the box with credentials that it's going to be giving out. It's receiving credentials, and so it's less important than, for example, the phone that needs to authenticate the "TensorWash" device. But there are cases, for example, in enterprise zero-touch, mass rollout scenarios, where you want that device to come out of the box and get itself set up. It'll have to come out of the box already with a notion of who it trusts. And this can be as simple as just taking an HTTPS URL and embedding it onto the device, so when it wakes up, it knows where it can go. And that can be a registration server that can fill it in with the rest of the credentials or the information it needs to get configured. But we're going to leave that bit out for our talk. And we're going to assume we have a consumer device, "TensorWash" coming out of the box in a clear state. So we've talked about authentication, which is checking whether something is authentic. And now, I want to talk about authorization. Authorization is checking whether something is allowed to do what it's trying to do. Think back to the airport passport check. You arrive at the airport with a valid passport. It doesn't mean you're going to pass the check. For example, they're going to be checking whether you're scheduled for a flight that day. Just because your passport is an authentic passport doesn't mean you pass. There's still an additional authorization. Similarly, with the movie ticket scenario, if you head to the theater with a movie ticket from last year, you may not get into your movie. It's a different time, different date, different showing. And there's an authorization that happens, even though your movie ticket is perfectly authentic. So I want to use the example of OAuth 2.0, which is a very commonly used authorization framework for the web. It's built for the web. It may or may not work for a given IoT use case. But it's a good example, and I want to pull out a few concepts that are important. And even if you don't use OAuth 2.0, you need to think about some of these concepts. The two big ones are token scope and token lifetime. Token scope describes what privileges are associated with a token. So, what can the bearer of this token get access to? Token lifetime describes when the token expires. And there's this notion of refresh tokens versus access tokens. Access tokens are going to be used to access the actual resource you're trying to get to, the protected resource. These tokens are often short-lived, narrowly scoped. And it can be self-contained. So the decision on the resource server can be optimized and quick. And it doesn't need to do any kind of back-end lookups. It just looks at the token that it received, and it can make a decision with the information there. Refresh tokens, on the other hand, are used to get new access tokens when the old access token expires. These tokens are often long-lived. They're more widely scoped, so you may want to go and get access tokens for of a variety of different scopes. And they're not self-contained specifically. And what this enables is this enables the authorization server that's making the decision as to whether it should give a new access token based on the refresh token. It can decide if there's been a revocation of that authorization. And that's what you want to have with IoT as well. You want to have that passive expiration. So if it's revoked, once the current set of access tokens expire, there's no more access. There's no way to go get another access token. You don't want to be in a situation where you have to pull an unused IoT device out of a closet, hope it still boots up, and do some kind of factory reset in order to de-authorize it. You want to be able to do that passively. So this is a snippet from the OAuth spec rfc6749, depicting the refresh token flow. You can see in the middle, the access token is used to access a protected resource and resource server. In steps E and F, that's where the access token's expired. And you'll get an error back. And then down at the bottom, G and H, you can see the refresh token's used to go get another access token from an authorization server. Hopefully, that helps you visualize that a little bit better. So let's think about authorization in the context of IoT, or of an IoT device. We talked about the authentication needs to go both ways. Authorization needs to go both ways as well. Or at least, we need to think about it in both directions. We need to think about who has access to a device, who can send commands to the device, who can read data from the device, and so forth. We also need to think about what does a device have access to? What rights does it have when it connects to a web service, for example? We want to use the principle of least privilege. We don't want to give more privilege than necessary. This is a really common problem with IoT, and I think it's because it's so easy to just give the device total authorization for the service it's connecting to, because then you won't have any more problems. You won't have any authorization errors, and everything will just work. The problem is if the device is only using 10% of that authorization, if your device gets hacked, now the attacker has access to all of it, even though you weren't using it. You also want the expiry. I talked about the passive expiration. You also want to be careful when you're passing your tokens. Tokens are, of course, made to be passed for specific purposes, verification for example. But you want to make sure that you've authenticated the recipient before you send your token. If you're sending it up to a web service for verification, make sure it's over HTTPS. If you're purchasing a new device, like our "TensorWash" case, authenticate that new device before you send over the token. As you'll see in a few minutes, Google services like Firebase on Android Things, the Firebase SDK will manage tokens for you. You don't have to worry about this token management, which is great. So let's go back and look at authorization in our "TensorWash" scenario specifically. We start in this state, where we assume the phone is already authorized to set up new devices with these cloud services. And the phone is implicitly authorized to set up the "TensorWash" device, because it doesn't have any policies about that. And where we want to be after we provision is we want to have a two-way authorization with Firebase. So we're going to use the Firebase Realtime Database. And it can sync down to the device. It can also sync data from the device up to the cloud. And when it syncs down to the device, we can actually use that to issue commands to the device. And so there's an authorization where Firebase is authorized to give commands to the device, and the device is authorized to push data back up into Firebase. For Cloud IoT Core, we put the arrow in just one direction, because what we're going to be using it for is metrics. So as the device is working, it's pushing metrics up into the Cloud IoT Core project. It needs to be authorized to push into that particular project. So we're going to show you the details of how you set this all up. First, I'm want to talk about one more key concept, and that is attestation. Attestation is really proving the integrity of a computing device with state, so including the current operating state of the device. So it's really a special kind of authentication. In order for this to be possible, the device needs to already have some kind of a credential that it can use to prove itself. It often is a provision of the factory. So when the device comes out of the box, it can already prove that it's a genuine instance of that particular product. It's also worth mentioning that attestation is often bound to a cryptographic key. So instead of the attestation assertion from the device, saying, I'm a genuine device running in a secure mode, it's a bit more like, this particular cryptographic key is securely held by a genuine device running in a secure mode. And this is useful, because it allows us to bind the attestation to something else that uses the key-- some other kind of authentication, for instance. And you'll see in the example later that we use a key like this to connect to Cloud IoT Core. So an Android Thing specifically, you can attest various properties. You can attest that it's authentic Android Things device. You can verify that it's an instance of a particular product. You can verify device identity, if you need to do that. You can also verify device state, like I was talking about. And one of the ones that we pull out is the verified boot state. When this device is actually running, they prove software for that device. You can also verify attributes of the cryptographic key. And I won't get into that today. So this is what a certificate chain looks like. Five levels deep. At the top, we have the Android Things CA, Root CA, and Intermediate CA. These are managed by Google. These are the authority for all Android Things attestation certificates. In the middle, level 3, we have the product-specific CA. And this is also managed by Google, but it's in the context of the Android Things developer console. And it's associated with a particular product on that console. Every time you go and create a product on that console, there's going to be an intermediate-level CA that's assigned to that product. So the next level, we have the device-specific CA. And this is provision to each device in the factory. This is unique per device. It contains an ID for that device. And when your device comes out of the box, this is the one that it has. The last level is the application key and certificate. So this was generated on the device. It was generated by your application. And the certificate is generated as well by the device-specifics CA, which is protected by the trusted execution environment on that device. So back in our "TensorWash" example, the attestation happens here with the arrow, from the "TensorWash" device up to the phone. So when we do that verification, remember the phone is going to verify, it's going to authenticate the device. That's where we're using attestation. So a quick review. We talked about authentication, checking that something is genuine or valid; authorization, checking that it is allowed to do what it's trying to do; and attestation, which is checking integrity of a computing device specifically. And now, Wayne is going to show us how to do all of this with Android Things. WAYNE PIEKARSKI: Cool, thanks. So now we've discussed the key concepts. So now let's talk about how we build something like this using the various pieces that are available on Android Things and from other services that Google provides. The first step is we can use something called Nearby Connections. And so Nearby Connections is great, because it provides an abstraction layer that helps to find nearby devices, and it establishes an encrypted communications channel. So under the hood, it uses Bluetooth, BLE, Wi-Fi hotspots. It uses whatever is available to it at the time. And the other nice thing about it, once the connection is established, is it provides a short human readable code on both sides that you can display on screens. Now, many of you have used devices where it shows a little code on the screen. And that's great, in most cases. But we mentioned earlier that the washing machine doesn't have a screen on it. So we don't have quite enough security that we need. And we're going to talk about how to address that in a minute. But Nearby Connections is the first building block that we're going to use. And so if we look at some code snippets, this is just sort of an abbreviated version of a Nearby Connection sample. You can see here that we create a Nearby Connections client at the top. We then specify some discovery options. We just used the default value, P2P cluster. That doesn't matter so much what we use here. And once we start the discovery process, we need to have a service ID. So in this case, it's com dot example dot tensorwash. And that is like our product ID. It's not the name of your app on Android. They call it a service ID. But it's what the name of your device is, or whatever you want to call it. And then we also have an endpoint discovery callback, which Nearby Connections will call your code whenever a new device is discovered. And what you would do is you'd maintain a list view, and you would have a UI that updates, showing all of the devices that have been discovered-- because clearly, we want to be able to support more than one device being available at a time. And then once the user has selected the one they want, they can pick it. And then we can establish a connection. On the device side, Nearby supports a startAdvertising method, where you basically provide a human readable name of the device. And then you put the same service ID in. And then you also set up some callbacks that will be called whenever a connection is established. So when the user has selected the device, so they've picked it on the screen, now we need to use the request connection method, which will handle establishing the connection to the remote endpoint ID that's been passed in. Once again, there are callbacks there. And then onConnectionInitiated is used when the connection is starting to that device. And it fills in a authentication token, which is that short code we mentioned. So Nearby Connections gives you a short human readable value. Once again, we don't have a display, so we'll talk about how to deal with that in a minute. But you can see here, the code's really simple to work with Nearby Connections. And it gets us going quite quickly. The next thing, Darren talked about attestation and verifying the device. So we need to make sure that the device in front of us is the one that we're actually connecting to. So what we do on the phone is we actually create what's called a random challenge. So it's a random number that's unique just for this connection. And then we send that over to the device. And we use this to prevent replay attacks. And the device takes the random challenge. It combines it with the authentication code from Nearby Connections, brings them together, and then it uses this to generate a new key in the Android Keystore with the attestation certificate chain. This certificate chain is then sent back to the phone. And the phone can then check it, which we'll talk about in a minute. And even though we're using a random challenge, the auth code from Nearby is important, because it helps to bind it to the encryption channel that we're using right now. And another thing is that it's also important to rate limit failed connections. So what you don't want is for someone to be able to constantly connect your device and try random codes and try to get it to generate some keys. You're better off rate limiting that to prevent people attacking your device. Here's some of the code that does that. Don't worry about it too much. I just wanted to show you some bits and pieces of what there is. But on the device, we have the authentication token from Nearby. We take in the random challenge that we got earlier. We combine it together. We use this code to generate the signing key here. And the interesting part about when you generate something in the Android Keystore is that it's done in a trusted execution environment. So we don't actually keep the key in our app. We actually keep it in the trusted execution environment. And this is nice, because it means that, even if someone hacks in our app, they don't have the ability to pull out the private key. So that adds extra security to what we're doing. So anyway, we put all this stuff in. All those purple values are all just standard constants that you use. So don't worry about capturing this exactly. Later on, we're going to release a sample that has all of this in it. But I just wanted to walk you through a bit of it. But at the end, you extract out the certificate chain. And that is what you then pass back to the phone for it to check it and do whatever it's going to do. So Darren mentioned earlier the concept of a certificate chain. And so the factory provision attestation key also comes with a certificate chain from this leaf all the way back to the Android Things root certificate. So now we have a full chain for the key we just generated. So right on the bottom, that's what we just created. And it links all the way back to the Android Things root. So now "TensorWash" has generated it's custom attestation key and certificate chain. And we've sent the chain back to the phone. So the phone needs to verify that this is a legitimate device that's untampered with and that it's also the one in front of us. It's actually a pretty tedious process. There's a number of steps. And it's probably something that we should put in a library in the future. But the gist of what you need to do is you need to verify that the certificate chain is connected correctly. You need to verify that the root is the trusted root from Android Things. You need to verify that it's your product ID. You can verify a 128-bit UUID for the device. This is something that, at the factory, you could actually take and print on the box with a code so that the user can verify that they've actually matched it up against the one in front of them. You can verify the boot status. When the key is signed, it's sent over with a flag indicating if the boot loader has been tampered with. You verify the attestation challenge, which we'll talk about in a bit. And then you end up with a public key that you can save. And it'll come in handy when we want to authenticate with Cloud IoT later on. On the phone side, we need to verify that the attestation challenge is correct. So we extract the attestation from that certificate. And then we create a hash of the authentication token from Nearby and the random challenge we generated earlier. And we combine them together, and we generate a hash. And we check that it matches what came from the certificate chain from the device. And this sort of verifies that this whole loop is complete and secure. And it's important, because we never actually sent the authentication to the device directly. It was done by Nearby. And so this checks that everything is done right and that there's no man in the middle attack happening along the way. So now we know that the device is ours. And that helps to deal with all these issues that we've identified. So now the phone has verified it can trust "TensorWash." Now we need to authorize the device on our Wi-Fi network. And the quickest way is just to pop up an activity on your phone and say, what's the Wi-Fi SSID and passphrase? But, of course, users don't want to do that. It's not very user-friendly. And it requires the user to enter their passphrase in. And your app gets to see the passphrase while it's being sent over to the device. And the next thing you do is, on the device side, you then need to use the Wi-Fi Manager to set the SSID and passphrase. So this is a little code snippet that does it. However, Wi-Fi Manager is a little bit more complicated. So if you look at the actual sample, this is the code you need to write to talk to the Wi-Fi Manager. So this is something that we're working on that we want to make a small code library that you could use that skips all this to make it so that you don't have to write that kind of code. And we have some more good news in that we have an API called Nearby Setup that's coming to Google Play services. And the great thing about Nearby Setup, which is coming soon, is that it has the ability to take the Wi-Fi credentials stored on your phone and pass them to another devices, Google Play services. So Android Thing supports Google Play services. You can copy the credentials over without having to deal with anything yourself. The user doesn't need to type them in. And so this is great for user convenience. So this is coming soon. And the details are going to be on developers.google.com/nearby later on when that's ready. So we have internet access on our device, and we have a key. So now, let's quickly talk about how we're going to go about talking and getting cloud services enabled on this device. So we're going to talk about Firebase and Cloud IoT. So the first thing we need to do is, on the phone side, we need to set up Firebase. Firebase is great, because it works on Android, iOS, and web. So the phone app could be on many kinds of devices. You create a Firebase project ID. And we're going to use that on both the phone and the device. And then, we ask the phone user to authenticate with their username and password, pop up a dialog box, and we'll get a token that we then pass down the encrypted pipe that we created earlier. So here is a bit of a code snippet for it. You can see at the top, we're doing the sign-in request. And it's interesting, because we're only requesting scope for the email ID. So we don't want to have full Google access or access to their files or email or anything like that. We're just asking for their identification details, because we're trying to limit scope, like what Darren talked about earlier. We end up getting a JSON web token that we can then pass in to sign in with Firebase, which then allows our device to interact with Firebase as well. But we ship that token. We shipped the previous token off to the device so it can log in to Firebase and do things with that. So on the other side, we take the Google token, pass it to Firebase and authenticate with that. And the device now has access to the Firebase Realtime Database. The code snippet looks very similar on the device as well. Because the Android Things device is regular Android, we use the same code, just like we do on a phone. We get the credential, we pass it in to sign in with credential to Firebase auth, and now we're done. We now have a bi-directional authorization. And our "TensorWash" now can fully participate with the Firebase Realtime Database. So let's switch gears to finish up. We can also talk to Cloud IoT Core. So imagine you're running a laundromat with thousands of machines and thousands of locations, and you want to do predictive breakdown analysis. So we want to push the data from these devices to Cloud IoT for analysis. So in Cloud IoT, we register the devices. You'd have an app on your phone with some credentials. And you would take that public certificate that we've created earlier, and you would give that to Cloud IoT so that it knows the device and that it can trust it. We then use MQTT to send requests to Cloud IoT with our device ID and signed with our key. Cloud IoT can verify that this message is legitimate by verifying this key and checking it with what it received earlier. So then, we send the MQT request using TLS. And we use TLS so that our device knows that it can trust who is sending the data to, because remember, both sides need to check the other side. Here's a very quick little snippet that shows how we put in some of the project IDs and things like that. And we're going to be releasing the sample, too, soon that shows how to do Cloud IoT Core on Android Things. And so the nice thing is that publishDeviceState at the bottom basically takes any binary blob that you want and sends it off to Cloud IoT. And you don't have to worry about generating any of the messages. So we talked very quickly about Cloud IoT and Firebase. What are some other options of things you can do? Well, we also have Smart Home, which is our new way of controlling devices from the Google Assistant. So you can do things like, if you've got light bulbs, you can say, dim the lights a little bit. Or, in the case of our washing machine, if you implement Smart Home, you can do start my washing machine, and it will kick off a load of laundry from the Google Assistant. And so by implementing Firebase, you write a small web hook that plugs into Smart Home. And then your device can be enabled with the Google Assistant. And then finally, you can actually embed the Google Assistant SDK into your device, which means you can actually talk to the washing machine and give it direct commands to the machine directly, which is kind of cool. So what's next? We have a factory key provisioning store coming soon. We're basically going to have a hardware device that's going to allow you to add keys on to Android Things devices. This is something you could do yourself or when they're being produced. And this is how this key is going to get onto the device. So if you have a developer kit, you won't be able to test the key signing correctly, because you won't have an official key from Android Things. But we're going to be releasing the tools to be able to do this soon. And remember that Nearby Setup API is coming soon as well. And that's going to be really nice to make provisioning these things really easy. So, in summary, go visit our site at androidthings.withgoogle.com, which is a great community site with lots of information. We have a G+ community, g.co/iotdev, where you can find out more information, and the Nearby site, where you can keep track of what's coming soon. And also, follow us on social media. If you haven't had a chance, go get yourself one of the IMX7 developer kits that we're giving away here at Google I/O. So make sure you get one of those you can try Android Things out yourself, because it's a really fun development experience. It's great for making prototypes. But it's also great for making production devices. That's it for us, so thanks very much for coming. And we'll see you all around at the conference. Thank you. [MUSIC PLAYING]