Best Practices for IoT Security in the Cloud



welcome to today's webinar best practices for IOT security in the cloud our presenter is John rota John has 40 years of experience in IOT services working for startups and AWS he has spent much of his time helping customers get their devices connected to the cloud and building out IOT applications with their data John is currently a software engineer on the AWS IOT service team today with us we also have Daniel Austin and Ramiz roll Atia be our webinar moderators today answering your questions throughout the presentation John welcome the floor is now yours thanks Jerry hi is he said I'm John wrote I'm a software engineer on AWS IOT and this presentation is best practices for security with IOT the presentation today is going to be three sections the first one is going to be about five minutes of why security is important in IOT the story around that the second section is going to be what what do we mean by security in AWS IOT that the mechanisms for security and what we're talking about the last section I'm going to go through a demo create some certificates create a policy just give you a walkthrough of creating those things so you can go away from this and get started with it so let's just jump right in and I plan to leave some time at the end to answer some questions so go ahead during the presentation submit questions and I'll try to get to them at the end of the presentation IOT is taking normal normal things normal devices and making them smart getting them connected to the cloud and some examples of things like this are connected cars we've heard of examples car companies like Tesla and other companies are delivering new features to customers electronically updating them what while they're just sitting in your garage smartwatches some connector to your cell phone some actually have their own internet connectivity things like notifications but even being able to control the environment around you from your watch that thermostat that looks like a nest thermostat is representing household items that there's a lot of home automation and household items that are being connected just giving you some cool functionality where you can control the environment in your home from anywhere in the world that last the last windmills is representing industrial use cases there's a lot of businesses that have their processes connected to IOT fleet tracking and asset tracking controlling industrial processes there's a lot of business value to be gained by having things connected and having them working together you take a look at this chart you've probably seen something like this before the projections of the number of things that'll be connected what I wanted to highlight here is even at AWS we're expecting anything that can be connected will be we're going to be surrounded by connected things but connected doesn't necessarily mean smart if you take a look at where the internet was in the early days everyone was talking to each other transferring files using clear text protocols the only thing that really held it together as no one was really out to get each other it was kind of a campus system people were kind to each other obviously not the case today and we've built security mechanisms around that but if you take it look at i/o T especially in recent history all the IOT protocols you can see some application for a calls for IOT there they also are inherently insecure there's no security mechanism like full full full layer security that's built into any of those I mean so we need to do something about that even if we look down down the OSI level down to the lower levels of networking there's nothing necessarily built into these that handle security end to end all of them do have or most of them have some sort of security mechanism but it doesn't handle it in the end so we can't really rely on just one protocol or something like that to handle it but my data isn't sensitive I've heard that ever since being an AI tea and people say things like well this is just the ambient temperature everybody knows what that is why you why protect data like that and I think the answer to that question is why are you doing IOT at all obviously you're putting in plenty of resources you know developer time actual physical capital costs to buy devices and install them there's some value you're expecting to get out of that IOT installation and it's a it's important to protect that value otherwise why are you doing it and I think you have to ask yourself the question what kind of business decisions you're going to drive off of that data and how expensive those decisions are going to be and you also have to keep in mind that changes they're always going to happen you're gonna you know a best practice would be if you've got a sensor out in the field and it has a bunch of different sensor values it can capture why not send them all to the cloud you may realize in nine months that you know one of those values actually is important and you want to start making decisions on it you can imagine a scenario in which you're collecting ambient temperature and then nine months down the road you actually realized that that actually is a good correlation for when a machine would break down now all of a sudden that thing that you thought maybe wasn't valuable you're starting to make decisions based on it and and that's why it's important to you know even just from the start protect all the data you're sending you never know when things are gonna change you'll actually end up using it but this slide shows devices connecting you can see they're sending data to a service that that data could be used by users you know either users of your service or maybe your employees if you're managing your assets they go into applications that that box at the top is representing things like machine learning or analytics jobs you're running on it and then what's a little bit unique to IOT is that data not only just runs applications and it's presented to users but it can actually cause changes to happen in the real world right all rightie devices are they can actually actuate things things they can control manufacturing processes they can cause changes to actually happen in the real world and I bring that up because we bring in that last device that wasn't connected if that's a bad actor type device not only does that bad data get to your you know to your users your your employees and maybe into your machine learning things your your algorithms but that can cause bad changes bad actual changes to happen in real world some of our I Oh team deployments are you know like I alluded to you're making pretty expensive business decisions on them and it can cause changes like that bad things to happen for that but it there's also safety critical installations as well and that's another reason why once we can start causing changes that happen in the real world we really need to protect that data so that really the simple goal is just a secure connection between the device in the cloud and what do we mean by that it's not just sprinkling some locks on this connection right wait let's dive into what we're what we mean by security from device to cloud and there's there's three main requirements I'm going to talk through the first is secure communications with things and that that's highlighting the that securing that communication channel well what you know just the traditional encryption preventing eavesdropping things like that there's strong thing identity we're going to talk about authentication and how we know that when truck 3 is that is connecting that's actually truck 3 there's no device spoofing that that that truck and once you have a strong story around authentication and you can prove the identity of a thing then you can start to do things with authorization and fine-grained authorization meaning once you know exactly that this is truck free connecting you can scope it – what exactly truck 3 is supposed to do right and there's the obvious use cases our truck 3 probably shouldn't be able to put input data into truck fours buckets and it also shouldn't be able to maybe delete data right your devices probably never really actually should delete and so once we once we can have a strong identity story then we can start to wrap around authorization around that an authorization applies to things so your device is connecting what they're allowed to do but also to people so you'll have applications interacting with your data or you know maybe you have a mobile app to control on some of your home automation things you'll want authorization stories around that too so so we'll talk about both of those first let's just real quick define the system we're talking about on the left you can see these devices there's only four of them hopefully in your eye o T installation if things are going well there's more than four they they end up connecting to a device ayat Ian's sending and interacting that way um you're most likely using it either side of team because you have workloads on AWS you're using dynamo DB to store data and maybe you have lambda functions that process things so from a device IOT you're sending that device data into those AWS resources and then you've got users and applications that interact with that maybe they take a real-time data stream from one of the devices or maybe they're just interacting you know doing a list of DynamoDB things to get history from a device and this is just an overview of what we're talking about when we when I start talking about an IOT deployment so let's let's talk a little bit more about secure communications with things this this slide shows some just kind of hex nonsense right nobody really could make make sense out of what this looks like and the truth of the matter is to make sense out of it it only took me just a couple seconds to download Wireshark and just open that that that hex data and it was able to discern that this is an MQTT message it's a published message it was a message just into the topic fubar and the temperatures 83 degrees Fahrenheit this is just highlighting that Network tools are really sophisticated today and people are using them for you know obviously for good purposes for debugging but people are also using them to try to try to sniff data or interact and in systems they're not supposed to so to to start this conversation the security story for securing that communication is TLS and more specifically its TLS mutual lock and let's just talk a little bit of what TLS means when you're just a user using a web browser you're going to go to amazon.com and maybe do some shopping amazon.com presents your browser with the certificate saying it's amazon.com and that's just public data right every single connection that comes to amazon.com is presented with that certificate and in what's special about that is Amazon also has a private key that goes at that certificate and that's something that's most certainly not public data that's something that we're going to guard closely and what that private key is it does is a cryptographically allows us to prove that were the owner of that certificate so when we're passing that certificate around the internet we can use that private key in that connection sign some data with that private key and send it to your web browser and then your browser can reverse that calculation and say ok you are the rightful owner of that certificate the mechanism we're using for IOT and AWS IOT is that exact same mechanism right same security mechanism that we've used for you know protection in the Internet previously we just applied that to IOT and then added another stuff on the end so in the same way device connects to a device IOT AWS IOT presents a certificate signed some data with its private key proves that it owns that certificate the device is able to verify that says ok great this this caption is from a today s IOT then we reverse that the mutual part of it is the device also has a certificate so it sends a certificate to AWS IOT saying I'm truck number 3 and it uses that private key and signed some data and sends it over improves that yes indeed I'm the rightful owner of truck number 3 certificate and that now we have that that identity we know that who we're talking to and that's the first start of building first step of building up a TLS connection once we go from there there's other things that happen in a handshake like negotiating session keys and in what what algorithms we're going to use but at that point we've secured the connection and it's a TLS connection specifically TLS 1.2 which is that the highest version of the TLS spec since we are a new service we were able to launch and not support a lot of the tls cipher suites that were less secure so we're only supporting the most secure cipher suites and so that ends up being that that's how we secure that connection so now we're both a TLS session in we're preventing eavesdropping in you know message replays and things like that let's talk a little bit more about how we how we what the story is for identity of our things I talked a little bit about certs and private keys and just to recap that a little bit a certificate is it contains you know when we when we're proving identity we have a public key and a private key that public key lives in a public certificate that you're passing around as your identity again that private key is is that key if you will to to this this trust it's what allows you to prove that you know me presenting the certificate I'm actually the rightful owner of that certificate what I glossed over a little bit in that that simplification of the amazon shopping story was anybody if you've ever done something with self-signed certificates maybe setting up your own web server you realized that you can create a certificate and a private key and you know anybody can create those and pass them around and in what would establish it what allows you to trust that that certificate actually came from who you're talking to whether it be amazon.com when you're shopping or AWS IOT when your device is connecting is the fact that that certificate we're passing around wasn't something we we necessarily generated right it was a certificate that was signed by someone above us in the in the internet world that's called a certificate authority and those authorities they actually do the legwork of saying yes you know almost like knocking on doors and saying yes you do have a business license to say that your amazon.com I'm going to sign the certificate and allow you to have the text amazon.com in there and then when your browser gets that certificate from amazon.com it actually can use a root CA certificate and see that okay the signature is valid someone above you know in this chain of trust someone above Amazon verified that that that's who they are and I bring that up in this story because the device needs to do the exact same thing there needs to be a piece of data called a root CA certificate on your device and that's what your device will use when AWS iot presents its server certificate identifying itself your that your device will need to use that root CA and verify that you know validate that certificate that yes indeed it was signed by it it was signed by a certificate authority and indeed we're talking to the right place so just highlighting another piece of data in addition to a private key and a certificate another thing on your device will need to be a root CA so you can do that validation a little bit about elliptical curve cryptography when I was talking through those motions of a client or a server signing some data with its private key and then reversing that on the other end to do the validation net algorithm typically is an RSA algorithm and that the foundation of that is it's computationally expensive so for certain key sizes it would take a lot of computation you know more than more than what we have in the world today over a certain amount of time it would take a lot of computation to be able to brute force that that key and that's great right that proves that that's a good thing to lean on when we're using this this public key mechanism but in the IOT world when we're talking about these devices that are constrained computationally that becomes kind of a bad thing it ends up being something where we're burning battery power or you know computation time just doing the algorithm to authenticate ourselves and I bring up a little ipped achill curve cryptography because this is an algorithm that takes the place of the RSA algorithm and provides the same amount of security a key strength for smaller key sizes and less computation power and I bring it up because AWS IOT supports elliptical curve cryptography certificates for identity and at the bottom is this slide I showed to pls cipher suites in a cipher suite is just a way of identifying what algorithms were using in that TLS connection things like how are we going to encrypt data and what we're using for message digests algorithms but the thing to highlight there is those two cipher suites are exactly the same except you can see one is ECDSA which is elliptical curve digital signature and one is RSA and it just shows the difference between the cipher suites one using art the RSA other algorithm for identity and one using elliptical curves and just to take away from this is elliptical curves are a good thing for IOT because it allows these smaller unconstrained devices to have the same level of security without the computation required so we've talked through certificates and private keys in how they're used in this interaction so so great how do you get your hands on them how do you provision the device get a certificate and start to use it with AWS IOT and there's a few different ways to do this I'm going to walk through each one on the slides here and highlight the differences between them and why we would want to use one versus the other and keep in mind I'll show a demo of some of this stuff at the end too so so you'll be able to see it actually happen the first and easiest way to get a key and certificate is there's an API called create keys and certificate and what that does is the on the server on AWS IOT we create a private key and a certificate and then just return it in it they're written the response to an API call and then you can take that key in certificate put it on your device put it on your laptop use it right away for for interacting with AWS IOT and this is I'll go to the next slide here you can see this is what the API looks like when it's invoked and you can see in the response there is a key pair it shows here's the public here's the private key and here's the certificate so real simple just one API call call it and you get the you get everything you need the key in the certificate back to to start a connection with AWS IOT so why wouldn't you Saul the time that seems really simple the first thing is the private key actually ends up getting generated on a machine that you don't own it has to current get transmitted over the network even though that API is TLS secure it's still a best practice not to have the private key in multiple places at once right ideally it would be just in one place and never leave there this API so why do we have this API this is a great one for I just want to get started just give me a key and certificate I'm going to be testing on my laptop I'm not going to use this for anything even approaching production just get me started quickly and this is just a great way one you know in our console it's just one click give me a key and certificate so great for getting started for testing but as you move toward a production deployment this this isn't the way that you should this it wouldn't be a best practice and provisioning a device so then wait then what do you do what's what's the next step toward production and what that is is you're either going to generate a private key yourself you know on your laptop or some devices actually come with a crypto chip that has a private key in it already and that would be a best-case scenario where the private key never even has to be put on the device it's only on the device and it's only lived there and then what you do is something called a CSR um you generate a CSR from that private key a CSR essentially is you saying talking to a certificate authority in this case it's database IOT where the authority for the certificates used in our service and you say something like I'd really like a certificate that identifies me as truck number three and here's a here's a use this public key and if you could sign that certificate and make it valid in your service that it would be great and I'm gonna sign it with the private key and there's send some data that proves that I own the private key for that certificate so you would generate a CSR and a CSR is is public data just like a certificate if someone was to able to get ahold of a CSR the worst thing they could do with it is actually turn it into certificate but then again they don't have the private key for that certificate so they couldn't use it anyway so CSRs are perfectly fine to pass around on pass to the service and so after you generate that CSR there's an API called crate certificate from CSR so you pass to a Davis IOT that's that signing request eight of F's IOT signs that turns it into a device certificate and then that's returned in the response and then you can put that certificate on your device is what you're using to connect what it looks like to do that this is just on a laptop I'll show a demo of this in a bit there's the open ssl command to generate a private key here's here's the open ssl command that you would use to generate a csr from that private key you can see that you put in some information that you would like in the certificate when you present it to the CA and here's what that API call looks like when you when you create that certificate you can see it's create certificate from CSR you give it the file the CSR file and then in the response you'll notice here's the certificate that we created but there's no private key right that that didn't that wasn't involved in this in this API call so that's good way we've made a step we you were not present passing the private key around it's that much more secure but one thing I want to talk to is in in both of those cases every time we wanted a new device every time we were approving a device we made an API call to a device IO T instead give me a new certificate give me a new certificate you can imagine a scenario when you have a manufacturing line and devices are rolling by and your staff and new identities into them that you wouldn't want to be coupled to API calls for every single device going through and so how would we handle that and we handle that by you're able to create your own intermediate intermediate signing certificate so you can become an intermediate CA in with a nativist IOT and that allows you to stamp out your own device certificates using that CA those certificates then can be used with AWS IOT but you didn't have to have us sign them you signed them with your intermediate certificate so the flow of that looks like you first do an API call to a device IOT and get a verification code this is a long-lived code that lives as long and you know until you delete it it's unique to your account once you get that verification code back then you create a CSR when you're creating a CSR for your signing certificate it's the same mechanism you'll have a private key that you're going to use in signing with that with that intermediate certificate you use that to create a CSR you put that registration code you got back into that CSR so then your signing certificate will have your unique code in it then you submit that CSR through an API called register CA certificate and that lets abbs IOT know that I'm we're going to be using this certificate to create new device certificates ABS IOT will take that CSR turn it into an intermediate signing certificate and then you bring that back and put it into your process and now you have what you need to create device certificates on behalf of eight of us IOT and so then what it looks like to provision a device is we've got our device again with its if it with its private key it would same mechanism it's gonna we're gonna create a CSR with that private key we're gonna submit it to our our own process and sign it with our intermediate signing certificate that creates a device certificate that can be used with database IOT and then we'll put that certificate on the device and then now the device can actually connect to a device IO T using that certificate that we sign there so but one thing that inherent in this transaction that we do have to do in this case is we still need to register that certificate with database IO T so in this case manufacturing line is running we're stamping out new identities at the end of the day maybe in some off time wherever you have it working into your process you would just make a call and say AWS IOT I stamped out these certificates here's here's a list of the certificates I've made that watch for these devices to connect that they're valid in the system now we've talked to customers about this one of the things that drove us for this feature was talking to customers about how they would do manufacturing we talked to iRobot and they said it was necessary for them to do to get couple their manufacturing line from creating these identities I mean so that that's what drove us through this feature and you can see that there's customers we already have that are using this in their manufacturing so you'll notice we still did even though we made it asynchronous we still did end up having to call to the service for every certificate we had to register each one of those certificate in wouldn't it be great if we didn't have to do that and in there actually is a mechanism to handle that called just-in-time registration and what that means is you can you can create device certificates with your intermediate signing certificate and then on first connected the service before ever seeing it ADA BIOS IOT knows to use that certificate and knows to provision it at that time so just in time that that certificate is is made valid in the in the service and what that looks like is let's suppose that we've created a device certificate using our intermediate signing certificate that device has never been seen we haven't done a register call and it connects for the first time and when that happens when it connects dataview SI t for the first time two things are going to happen the first is we're going to disconnect that connection and we do that because at that point we don't know what policy should be applied to that certificate we know it's we know it's a certificate that we should honor but we don't know if you want it to be active or not we don't know if it should be able to connect or not or publish to what messaging topics we don't really know the usage of that device how it should be authorized and so the safest thing to do in that case is just disconnect it on first connect but then what we also do is we omit an events and we see a new certificate that we haven't seen before and what that allows you to do is hook into that event and then run whatever you need to do to provision that device things like here I'm going to apply a policy to that device it should be able to do these actions I'm going to activate it because it's going to start in pending activation so you can do things like activate the certificate on that event maybe you want to do some things like some bookkeeping things around it like create a thing for that that certificate or update its its shadow if you know AWS IOT you can have shadows that are states of devices so you could do something like here's its initial state and so in that case then after we've done those things then when the device connects for the next time it's all set up and provisioned in the service and so you'll notice from the manufacturing line we didn't have to do anything to register that certificate it's all handled on first connecting and we give you a mechanism for rapid and automation around that this slide is meant to highlight that device manufacturers are getting better and better about having security features right into hardware there's things like enclaves for storing private key data there's things that they have cryptographic modules that accelerate these these calculations so things even doing things like RSA factorizations are done in Hardware on a dedicated chip rather than on your microcontroller so again I'm not consuming cycles from you but don't efficiently in a chip this is just highlighting that hardware manufacturers are making these things easier as you move to production so let's talk a little bit said boy we're gonna we're gonna keep that private key secret what does that mean what do I mean by we're gonna keep it secret this first slide shows maybe you're in a test environment or just you know developing your laptop maybe that's just as simple as just making the file not world readable right right it's not going to be used in a production environment you don't expect people trying to use that certificate or take over that device when it's just your laptop so maybe security in that case of protecting that key is just make it not readable to the world as these devices migrate audio control and they're used in the real world they're gonna face more challenges than what they would just internally there are there definitely are documented cases of you know the hardware hacking if you will where people will take apart a device and try to extract key data from it using debuggers and so there are definitely are protections you need to place around a private key is it leaves you know in your device out in the world there's software protections if you're in a Linux in a Linux world there are ways to do jails or security enhance Linux to further protect that file from access if you're on Hardware where you have dedicated hardware for that there's things like trusted platform modules that have private key data inside of them I'm storing them out of the view of other processes there's things like one-time programmable memory where you can put key data in and not be able to extract it and only be able to do some of this Hardware has things where there's a private key inside of it and you can't actually there's no verb in the hardware the API to pull the key out you only can do things like sign data with it so that private key can't be extracted this is just highlighting that as your devices go out into the real world you need to take more precautions against protecting them and here's some examples that you can research on you know things that would make sense for your use case and what you see is your threats I'm going this far without without bringing up probably one of the most important best practices of of security in a diversity and that is each device should have its own identity and I'm guilty of this in you know in just in testing of sharing a certificate across a couple devices but definitely when you move toward production a best practice is to have each device have its own identity and where that becomes important is when you end up having some sort of compromise of a device if you're sharing that identity across multiple devices that the blast radius is pretty high if you have to disable your entire fleet because one device was compromised that's that's bad news and if you have one you know one certificate or one identity for each device then you limit that you limit that effect to just being able to disable that device and revoke that certificate what it looks like the revoke a certificate is you can see here we listed our certificates you can see this one is listed as active there's an API call that can update it to say it's revoked now you can see it's revoked and that certificate is no longer honored when connecting in again if this was one device we just disabled one device if the certificate was shared across multiple devices then we just disabled potentially a big part of our fleet so best practice definitely one one certificate per device in production so take takeaways from strong identity there's many methods of provisioning we're making it easier for manufacturing by doing just-in-time things and being able to be your own intermediate CA definitely a best practice is every device you have its own certificate and I just mentioned that you can use a certificate authority for offline provisioning so you don't have to be connected to the internet to make new device identities so now that now we've built a story around authentication what are we doing for authorization what does that look like first four things whenever something connects and presents a certificate there's going to be a policy associated with that certificate and that policy describes the authorization story it describes what actions it can take what resources it can act upon the bugs we have in policies are things like can it connect or not can it publish or not into what topics Canada unsubscribed that that seems like a pretty insidious way of attacking a device is connecting as it unsubscribing and then disconnecting and then now the device is no longer getting messages it'd be pretty I'm sure there are use cases but I think it would be a rare use case for a device to be unsubscribe to maybe its messaging topic so we allow you to limit that and then receiving messages and what a policy looks like is you list out it looks just like the policies you're used to in AWS you specify an action and then a resource for that action so this particular one says allow allow this device to connect and allow to connect as this thing name this is the client ID in MQTT so this did whatever this is applying this policy whatever it's using this policy can only connect as this device you can use wildcards in these policies if you maybe want to apply the policy and open it up a little bit apply it to multiple devices you can do things like wildcards here's an example of what a published policy looks like you can see a topic and then the topic specified is an iron you can do even finer control so you can do something like this and then publish to just one topic and then have a rule in a TBS IOT that only updates a specific part of a document so this is an interesting way to use the rules engine to have finer grain access takeaways for thing authorization our topics can be structured for permissions definitely make policies of security but best practice is making policies as restrictive as they need to be you can use wildcards and policies if you want to open it up a little bit more and there's an interesting use case for using rules to make it even more fine-grained now let's talk about what authorization looks like for people when you have people or applications interacting with IOT the first use case is going to be an application maybe you have a web app or you know a client app you've developed up Janet's can interact those same policies can be used in Identity and Access Management policies in AWS so just the same kind of policies you would use to restrict users for you know dynamodb or something like that you can use the same thing for a vs IOT knowns and say things like allowed to publish or allow to subscribe so it's the same thing that you're used to and in other other policies in AWS for the mobile use case for users there's a product called Amazon Cognito in that that's a way to vend temporarily AWS credentials to things like mobile apps so you don't have to put AWS credentials into your apps you can just make an API a call and get some short-lived credentials those support the same sort of policies as connect and publish and then you can actually so these this what Cognito supports you can even then you can scope those down further and add an IOT policy to them so you can scope down what your mobile app can actually do I'm gonna skip over this slide it's just talking through the pairing workflow for Cognito to highlight this is the highlight of this slide is this applies to authentic container users if you're aware of Cognito you can have unauthenticated users and authenticated users I think the key point of this slide is these policies only apply when the users are authenticated managing fine great permissions can be hard and so there's ways of adding wildcards so you can put in wildcards and have open those policies up also incognito takeaways from authorization four people are saying I am roles and policies you're used to can be applied to IOT kognito is the service to use when you when you're using a mobile app yep humans interacting IOT scoped known policies allows allows you to scope it down to the topic of the device connecting in there ways of using naming conventions to make it simpler you can do things like wildcards to simplify the management so now we're going to jump into the demo I'm going to demo creating certificates in a few different ways and also demo creating a policy and then I'll show you a just-in-time registration example all right so this is the ADA vs IOT console you can see I've got three certificates here me refresh the page here to make sure we're starting starting from scratch and the first thing I'm going to do is go through that one-click creation of a certificate what does it look like just for the you know that that's simple interaction and I'm going to go to create a resource and then create a certificate you can see on this page we're presented with here's a button to one-click create so I'm just going to click on that and in the background on the server it created a private key for me and a certificate for me and then it presents me with the links where I can download those so I can just pull those those certificates in and keys down down to my computer and use them one thing to highlight from this to when I talked about private keys this is the only place that you'll present be presented with an ability to get that private key in order to follow best practices for security if we're creating private keys for you on our service we're not going to log them we're not going to store them this is the only time you would have access to them and so keep in mind that going forward from here after I closed this page there's no API call I can make to say give me that private key again and so that's just something to highlight when you're creating it this way go ahead and download these and use them and you won't be able to get the private key again so now you can see here I just created this one it's inactive I could click on this and activate it apply a policy to it and use it but just one click I got got what I needed to connect to a wsit the second way I'm going to do this I'm going to show you what it looks like to create a CSR I'm going to have the private key just on my laptop and not actually send it to the service so the way we do that I'll go over here and I'll just enter here is the OpenSSL come in to make a private key so let's just do that and you can see now I've got my private key I'm going to here's the command to generate a CSR from that private key here's where we enter information and what we want to have in a certificate I'm just gonna make some stuff up for now and you can see now we've got our private key and we've got a CSR that corresponds to that private key and so now I'm going to invoke that create certificate with CSR API called by just going to the same certificate create page then you'll notice over here there's a button that says create with CSR and it's got a little upload arrow showing that we're up at CSR so I'll click on that click on my CSR and then when I say upload it says I've created your new certificate and at this point your you might say well wait a minute where's the the link to download that certificate and private key and the first thing to say is you'll notice we never actually ended up having to send the private key there's there's an that wasn't part of that transaction and then when we go down here and we click on the certificate we just created you can see that there is a link that this is how we can go and download that certificate to use it and so in that case we never ended up having to transmit the private key we're able to just create submit that CSR and then download the certificate later so that shows the two ways of creating it that way now I'd like to go through the just-in-time example before I do that I'm going to clean these up and now you can see we're back to three certificates I'm going to go over here really quick I'm going to connect this is an mqtt client in in the console so I'm going to connect and I'm going to subscribe to that event topic where you can see where we emit the event when we want a new device is seen so I'm going to subscribe to that event topic which is and subscribe let's go back here you can see I only have three certificates in my account right now let's go back to the certificates page and then I'm going to go out here and what what I have out here is a simple example I created with our embedded CS DK and this is going to connect with a certificate that I had created I created the certificate with my intermediate signing certificate I've never registered it with AWS and now when I connect you're gonna see this is going to happen fairly quickly so I'll describe it a little bit before I do it when I connect we're going to go back to that MQTT client you'll see on registration event to be admitted that that's how you could hook in and put some automation around this I haven't put in automation for this so what I'm going to do is I'm going to go back to my certificates page and I'll see a new certificate I'll see the fourth one show up here that certificate is going to be created in a pending activation state so I'm going to click on it and activate it and then I'm going to apply a policy to it that says allow that device to connect and over here in my terminal window the first thing you'll see is the device is going to try to connect and it's going to be disconnected I talked about how that flow works and so then I just wrote this sample to just wait for 10 seconds and then try to connect again and hopefully if I'm handy with the computer I'll be able to activate that certificate and apply that policy and so then in 10 seconds when this tries to connect again you'll see it connects successfully so let's go ahead let's go back to the MQTT client we're still waiting for those registration events I am going to run that sample there's our registration event go back to my certificates page here's up here's my pending activation certificate so I'm going to go ahead and activate it and then I'm going to attach a policy to it that allows it to connect and now it's active and it's been registered with a system we'll go back here you can see there it was my SDK was disconnected because that certificate wasn't active and now it goes to a tree Connect loop and now it's connected now we go back here let's go back to our MQTT client just to prove that we did that let's just let's publish a message to that application so and now you can see it's connected it's interacting with this system so in that example we took a certificate that had never been seen by a WSI ot yet connected we applied a policy to it activated it and now it's interacting as a device without intervention so now we can go back to the slides and let's just wrap up do a summary of what we talked about and then we'll open up the questions highlighting what we went over today we talked about secure communications with things how we secure that communication channel on what TLS means what the handshake looks like we talked through strong thing identity so how do we prove that when our devices connect we know each device and it's only that device once we have that identity we've shown that we can build authorization around it and that authorization applies to our things as they connect but also to people as they interact so applications and you know maybe mobile apps from users and that that's it for today thank you so much for attending the webinar and I have some links here for where documentation can be found there's one link there at the bottom is the AWS IOT forum this is this is a forum that engineers on the service team actually answer questions so if you have questions that's a great place to get answers and then just database IOT landing page at the top and now will will open up for some questions well thank you John thanks for the great presentation and Danielle and Ramiz thank you for engaging the audience throughout the presentation with our QA on your screen you'll see our live poll questions you'll see three at the bottom and there's one at the top of the screen for more feedback you'll also see on the left side of the screen the Q&A – over there – on we actually have looked into that um it's still certainly early days for a technology like that but that's that's definitely an interesting application of having some sort of peer peer trust to – to build out a dedication story for IOT devices especially when they're out in the field they maybe it's maybe an easier interaction for them to do to talk to their peers rather than a central service so I'm certainly have started to think about things like that but it's still really early one of the questions says what what is the cost implications for applying security certificates at scale one thing I can highlight there is there is no cost associated with provisioning certificates you can provision as many is you use in your account one of the reasons we chose certificates in us being the CA is being able to apply that and scale that to the same you know the same number of devices we expect in IOT so there's no cost use of using certificates all right it has to be okay here's one like to hear about anti-malware an anti-virus software for use on AWS cloud typically something like that we run the security story of our services in the same way that any other service AWS presents there's no specific application and there's no uniqueness of IOT when it comes to anti anti Mountain malware software virus software there's more information on security practices for AWS on the ETS website as far as software that could be running on devices that's kind of application specific certainly if your if your device was running an OS that was susceptible and things like that you would have to do a security review and see are there ways that any kind of malware would get on to a device typically devices like this aren't susceptible to things manat a general-purpose OS they're not as targeted is as highly but there definitely are if you do searches you can see companies that that help with security posture for devices could help recommend software if that was applicable for that use case but there's no really general guidance we have for something like that it looks like there's a question yeah our CA certificates in AWS IOT free and yes they are you don't pay for creating your own intermediate signing certificate this question elaborating on establishing that you're the owner of the private key after you send the CSR to AWS after you generate your own cert let me take a look at that again in case you generate your own cert I'm gonna assume that means when you create your own sign signing certificate in that case it's the same that same mechanism you your signing certificate would have a private key when you create a CSR you use that private key – that's that's part of the transaction that happens when you create a CSR and so that's when when you register that CSR to be used as a signing are that intermediate certificate to be used as a signing certificate in AWS IOT you would use that private key and that's how we that's how we determine that we're able to sign that for you and it looks like that that's the last of the questions for today thank you so much for attending like us extend a special thank you to your presenter today John for his time and the great presentation and the Daniel and Ramiz for the great answers for our Q&A questions if you have any comments on our previous or upcoming webinars or suggestions on the topics you wish AWS to cover in future webinars please feel free to e-mail at AWS – webcasts at amazon.com your feedback will help us to improve our webinar programming thank you to our audience for taking the time to join us today enjoy the rest of your day

Be First to Comment

Leave a Reply

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