Best Practices of IoT in the Cloud
•
2 likes•4,572 views
Introduction to best practices for IoT security in the cloud and the access control mechanisms used by AWS IoT.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Best Practices of IoT in the Cloud
Similar to Best Practices of IoT in the Cloud (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Best Practices of IoT in the Cloud
- 1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. John Rotach Software Development Engineer – AWS IoT September 27, 2016 Best Practices for IoT Security in the Cloud
- 2. All things around us are getting connected
- 3. All things around us are getting connected
- 4. Things will proliferate 2013 2015 2020 Vertical Industry Generic Industry Consumer Automotive Many Some Lots
- 5. Connected ≠ Smart Internet 1985 IoT 2016 Gopher HTTP FTP MQTT NNTP CoAP Telnet XMPP Archie AQMP
- 6. In reality, it is even more complex Layer Standards Application HTTP, MQTT, AMQP, CoAP, XMPP Network IPv4, IPv6, 6LoWPAN, ZigBee, Z-Wave, Insteon Physical Ethernet, CAN, USB, 802.11, Bluetooth, 802.15.4, SPI
- 7. But my data isn’t sensitive!
- 8. Why do IoT at all? Changes happen in the real world!
- 9. The Risk Changes happen in the real world! Bad
- 10. A Simple Goal
- 11. Requirements Secure Communications with Things Strong Thing Identity Fine-grained Authorization for: Things People
- 16. Requirements Secure Communications with Things Strong Thing Identity Fine-grained Authorization for: Things People
- 17. Network Traffic Is Complex 04:07:18.045065 IP 85.119.83.194.1883 > 10.0.0.67.51210: Flags [P.], seq 1586864891:1586864913, ack 820274045, win 227, options [nop,nop,TS val 2390025928 ecr 577393885], length 22 0x0000: 4500 004a 3694 4000 2d06 639e 5577 53c2 0x0010: 0a00 0043 075b c80a 5e95 a2fb 30e4 637d 0x0020: 8018 00e3 66cd 0000 0101 080a 8e74 e6c8 0x0030: 226a 54dd 3214 0007 666f 6f2f 6261 7200 0x0040: 0454 656d 703a 2038 3346
- 18. Network Tools Are Up To It MQ Telemetry Transport Protocol Publish Message 0011 0010 = Header Flags: 0x32 (Publish Message) 0011 .... = Message Type: Publish Message (3) .... 0... = DUP Flag: Not set .... .01. = QOS Level: Acknowledged deliver (1) .... ...0 = Retain: Not set Msg Len: 20 Topic: foo/bar Message Identifier: 1 Message: Temp: 83F
- 19. Mutual Auth TLS
- 20. Mutual Auth TLS
- 21. Mutual Auth TLS
- 22. Requirements Secure Communications with Things Strong Thing Identity Fine-grained Authorization for: Things People
- 23. What are Certs and Keys? Certificate – Public identity Private Key – Private proof Root CA – Validate rootCA
- 24. Elliptical Curve Cryptography (ECC) ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 Elliptical curve logarithm vs RSA integer factorization Smaller key sizes for same security ECDHE – key exchange algorithm (forward secrecy with ephemeral keys) ECDSA – signature algorithm with EC private keys (authentication)
- 26. Actual Commands $ aws iot create-keys-and-certificate --set-as-active { "certificateArn": "arn:aws:iot:us-east-1:123456972007:cert/d7677b0…SNIP…026d9", "certificatePem": "-----BEGIN CERTIFICATE-----…SNIP…-----END CERTIFICATE-----", "keyPair": { "PublicKey": "-----BEGIN PUBLIC KEY-----…SNIP…-----END PUBLIC KEY-----", "PrivateKey": "-----BEGIN RSA PRIVATE KEY-----…SNIP…-----END RSA PRIVATE KEY-----" }, "certificateId": "d7677b0…SNIP…026d9" }
- 29. Certificate Signing Request Dear Certificate Authority, I’d really like a certificate for %NAME%, as identified by the keypair with public key %PUB_KEY%. If you could sign a certificate for me with those parameters, it’d be super spiffy. Signed (Cryptographically), - The holder of the private key
- 31. Actual Commands $ openssl genrsa –out ThingKeypair.pem 2048 Generating RSA private key, 2048 bit long modulus ....+++ ...+++ e is 65537 (0x10001) $ openssl req -new –key ThingKeypair.pem –out Thing.csr ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:NY Locality Name (eg, city) [Default City]:New York Organization Name (eg, company) [Default Company Ltd]:ACME Organizational Unit Name (eg, section) []:Makers Common Name (eg, your name or your server's hostname) []:John Smith Email Address []:jsmith@acme.com
- 32. Actual Commands $ aws iot create-certificate-from-csr --certificate-signing-request file://Thing.csr --set-as-active { "certificateArn": "arn:aws:iot:us-east-1:123456972007:cert/b5a396e…SNIP…400877b", "certificatePem": "-----BEGIN CERTIFICATE-----…SNIP…-----END CERTIFICATE-----", "certificateId": "b5a396e…SNIP…400877b" }
- 33. Register your own Certificate Authority
- 34. Register your own Certificate Authority CSR
- 35. Provisioning your own certificates CSR
- 36. Provisioning your own certificates
- 40. Private Key Protection – Test & Dev $ openssl genrsa -out ThingKeypair.pem 2048 Generating RSA private key, 2048 bit long modulus ......................+++ .................................+++ e is 65537 (0x10001) $ ls -l ThingKeypair.pem -rw-rw-r-- 1 ec2-user ec2-user 1679 Sep 25 14:10 ThingKeypair.pem $ chmod 400 ThingKeypair.pem ; ls -l ThingKeypair.pem -r-------- 1 ec2-user ec2-user 1679 Sep 25 14:10 ThingKeypair.pem
- 41. Private Key Protection Software chroot SELinux Hardware TPMs Smartcards OTP Fuses FIPS-style hardware
- 42. Identity Revocation $ aws iot list-certificates { "certificateDescriptions": [ { "certificateArn": "arn:aws:iot:us-east-1:123456972007:cert/d7677b0…SNIP…026d9", "status": "ACTIVE", "certificateId": "d7677b0…SNIP…026d9" "lastModifiedDate": 1443070900.491, "certificatePem": "-----BEGIN CERTIFICATE-----…SNIP…-----END CERTIFICATE-----", "ownedBy": "123456972007", "creationDate": 1443070900.491 } ] }
- 43. Identity Revocation $ aws iot update-certificate --certificate-id "d7677b0…SNIP…026d9" --new-status REVOKED $ aws iot list-certificates { "certificateDescriptions": [ { "certificateArn": "arn:aws:iot:us-east-1:123456972007:cert/d7677b0…SNIP…026d9", "status": "REVOKED", "certificateId": "d7677b0…SNIP…026d9" "lastModifiedDate": 1443192020.792, "certificatePem": "-----BEGIN CERTIFICATE-----…SNIP…-----END CERTIFICATE-----", "ownedBy": "123456972007", "creationDate": 1443070900.491 } ] }
- 44. Takeaways • Many provisioning methods • Each device gets its own certificate • Use a certificate authority for offline provisioning
- 45. Requirements Secure Communications with Things Strong Thing Identity Fine-grained Authorization for: Things People
- 46. Policy actions • Connect • Publish • Subscribe • Unsubscribe • Receive
- 47. Connect policy { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:Connect" ], "Resource":"arn:aws:iot:us-east-1:123456972007: client/MY-THING-NAME" } ] }
- 48. Connect policy { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:Connect" ], "Resource":"arn:aws:iot:us-east-1:123456972007: client/MY-THING-NAME_*" } ] } MY-THING-NAME_Application1 MY-THING-NAME_Application2 MY-THING-NAME_Application3
- 49. Publish policy { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:Publish" ], "Resource":"arn:aws:iot:us-east-1:123456972007: topic/$aws/things/MyThing/shadow/update" } ] }
- 50. Even finer control { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:Publish" ], "Resource":"arn:aws:iot:us-east-1:123456972007: topic/$aws/things/MyThing/shadow/update" } ] } Allows updating the entire shadow
- 51. Even finer control { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:Publish" ], "Resource":"arn:aws:iot:us-east-1:123456972007: topic/actions/MyThing/open" } ] } Use a different topic
- 52. Even finer control AWS IoT Direct publishing to shadow
- 53. Even finer control AWS IoT Use a rule to update specific shadow fields
- 54. Takeaways • Structure topics for permissions • Make policies as restrictive as possible • Wildcards can simplify policy management • Rules can help with fine-grained permissions
- 55. Requirements Secure Communications with Things Strong Thing Identity Fine-grained Authorization for: Things People
- 57. IAM Role policy { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "iot:Connect" ], "Resource":"*" }, { "Effect":"Allow", "Action":[ "iot:Publish" ], "Resource":["arn:aws:iot:us-east-1:123456972007: topic/$aws/things/MyThing/shadow/update"] }, { "Effect":"Allow", "Action":[ "iot:Subscribe", "iot:Receive" ], "Resource":["arn:aws:iot:us-east-1:123456972007: topicfilter/$aws/things/MyThing/shadow/*" ] } ] }
- 59. Policy for Cognito with IoT Cognito authenticated user identity pool role policy: { "Effect": "Allow", "Action": [ "iot:Connect", "iot:Publish", "iot:Subscribe", "iot:Receive", "iot:GetThingShadow", "iot:UpdateThingShadow" ], "Resource": "*" } Specific policy for Joe IoT Cognito user: { "Effect": "Allow", "Action": "iot:UpdateThingShadow", "Resource": "arn:aws:iot:…:thing/joe-sprinkler123" }
- 60. Policy for Cognito with IoT Cognito authenticated user identity pool role policy: { "Effect": "Allow", "Action": [ "iot:Connect", "iot:Publish", "iot:Subscribe", "iot:Receive", "iot:GetThingShadow", "iot:UpdateThingShadow" ], "Resource": "*" } Specific policy for Joe IoT Cognito user: { "Effect": "Allow", "Action": "iot:UpdateThingShadow", "Resource": "arn:aws:iot:…:thing/joe-sprinkler123" } Amazon Cognito
- 61. Policy for Cognito with IoT Cognito authenticated user identity pool role policy: { "Effect": "Allow", "Action": [ "iot:Connect", "iot:Publish", "iot:Subscribe", "iot:Receive", "iot:GetThingShadow", "iot:UpdateThingShadow" ], "Resource": "*" } Specific policy for Joe IoT Cognito user: { "Effect": "Allow", "Action": "iot:UpdateThingShadow", "Resource": "arn:aws:iot:…:thing/joe-sprinkler123" } AWS IoT
- 62. Overall Cognito “pairing” workflow 1. Create a Cognito identity pool 2. Customer signs in using mobile app 3. Associate their user with their devices 4. Create a scope-down policy in IoT for their user 5. Attach that policy to their Cognito user in IoT
- 63. Overall Cognito “pairing” workflow 1. Create a Cognito identity pool 2. Customer signs in using mobile app 3. Associate their user with their devices 4. Create a scope-down policy in IoT for their user 5. Attach that policy to their Cognito user in IoT Important: These steps apply to authenticated Cognito users only. (NOT to unauthenticated!)
- 64. Managing fine-grained permissions • One user may need permissions to many things • "arn:aws:iot:…:thing/sprinkler123abc" • "arn:aws:iot:…:thing/sprinkler456def" • … • Listing each is tedious
- 65. Best practice: Thing name prefixing • Prefix thing name with logical owner • sensor123abc -> joe-sensor123abc • Aspen policy supports wildcards • "arn:aws:iot:…:thing/sensor123abc" • "arn:aws:iot:…:thing/sensor123abc" • "arn:aws:iot:…:thing/sensor456def" • … • "arn:aws:iot:…:thing/joe-*"
- 66. Takeaways • Application access is done through IAM roles/policies • Cognito enables secure human control over IoT devices • IoT scope-down policy supports fine-grained control • Naming conventions simplify policy management
- 67. Demo Creating Certificates - 1-click - CSR Just In Time Registration
- 68. Requirements Secure Communications with Things Strong Thing Identity Fine-grained Authorization for: Things People
- 69. Thank you!
Editor's Notes
- Everyone has their own predictions for how the population of Things will grow. They’re all over the place, but one thing they agree on is that the population is going to grow. It’s our belief that over time everything that can be internet connected will be. That’s “lots” of things, even by Amazon standards.
- Clear text protocols – the foundation of the internet Security isn’t one of these protocols
- Temperatures, fuel levels, vibration amounts, noise levels, etc, etc.
- IoT isnt free. You must have some business goal in mind when you did this, something you wanted to achieve. In addition to protecting your data, that’s what you’re protecting, the decisions that are driven by your data. Keep in mind the world changes. You are most likely collecting data that isn’t “valuable” to make a decision today. When that changes a year down the road you’re going to forget the security decisions you made on this data. Always assume this data will eventually be valuable.
- The extent to which you protect your IoT deployment should be driven by the most expensive decision that you could make based on your IoT data, in addition to the native sensitivity of the data itself. Even if they only gain access to eavesdrop on the data, without altering or removing any of it, they’ll still have significant insight into your business.
- Total of 6 locks.
- A bunch of Things talking to AWS IoT. In reality, this will be millions or billions, but I got tired of cutting and pasting. Blue arrows are things talking to AWS IoT. Green arrows are other clients talking to AWS IoT. Zoom in on the service, look inside. We have Shadows of your Things. This is our control plane representation of your thing. This is where we store the metadata associated with all the Things you’ve registered with the service. Shadows maintain state on your things. Intermittently connected things can still be queried when disconnected, you can still set state on them, and the service will take care of propagating the changes when the Thing reconnects.
- A bunch of Things talking to AWS IoT. In reality, this will be millions or billions, but I got tired of cutting and pasting. Blue arrows are things talking to AWS IoT. Green arrows are other clients talking to AWS IoT. Zoom in on the service, look inside. We have Shadows of your Things. This is our control plane representation of your thing. This is where we store the metadata associated with all the Things you’ve registered with the service. Shadows maintain state on your things. Intermittently connected things can still be queried when disconnected, you can still set state on them, and the service will take care of propagating the changes when the Thing reconnects.
- A bunch of Things talking to AWS IoT. In reality, this will be millions or billions, but I got tired of cutting and pasting. Blue arrows are things talking to AWS IoT. Green arrows are other clients talking to AWS IoT. Zoom in on the service, look inside. We have Shadows of your Things. This is our control plane representation of your thing. This is where we store the metadata associated with all the Things you’ve registered with the service. Shadows maintain state on your things. Intermittently connected things can still be queried when disconnected, you can still set state on them, and the service will take care of propagating the changes when the Thing reconnects.
- A bunch of Things talking to AWS IoT. In reality, this will be millions or billions, but I got tired of cutting and pasting. Blue arrows are things talking to AWS IoT. Green arrows are other clients talking to AWS IoT. Zoom in on the service, look inside. We have Shadows of your Things. This is our control plane representation of your thing. This is where we store the metadata associated with all the Things you’ve registered with the service. Shadows maintain state on your things. Intermittently connected things can still be queried when disconnected, you can still set state on them, and the service will take care of propagating the changes when the Thing reconnects.
- Hex gobbeldygook
- This is not the result of me being a wizard. This is the result of me being able to download wireshark. Tools to intercept, alter, spoof, or otherwise fold, spindle, or mutilate MQTT messages are trivial to build. MQTT is explicitly a lightweight protocol that does not address security. There is nothing in this message that authenticates the caller, provides any integrity, or confidentiality. We need a mechanism outside of MQTT to help out here.
- Anyone in this room can download the amazon.com certificate. It really is public data. Not just "not sensitive", but public. We send a copy of it to your browser every time you log in to Amazon. But that private key, that we’re going to protect very carefully. Possession of that key allows you to cryptographically prove your identity as Amazon.com. In the AWS IoT world, everything MQTT is TLS 1.2, and with a restricted set of strong cipher suites. Now that we’ve got TLS established and the server is authenticated, we have message integrity and confidentiality, but we have absolutely no idea who the client is. That’s why you have to sign in to your account when you go to amazon.com. Mutual auth….
- Anyone in this room can download the amazon.com certificate. It really is public data. Not just "not sensitive", but public. We send a copy of it to your browser every time you log in to Amazon. But that private key, that we’re going to protect very carefully. Possession of that key allows you to cryptographically prove your identity as Amazon.com. In the AWS IoT world, everything MQTT is TLS 1.2, and with a restricted set of strong cipher suites. Now that we’ve got TLS established and the server is authenticated, we have message integrity and confidentiality, but we have absolutely no idea who the client is. That’s why you have to sign in to your account when you go to amazon.com. Mutual auth….
- Anyone in this room can download the amazon.com certificate. It really is public data. Not just "not sensitive", but public. We send a copy of it to your browser every time you log in to Amazon. But that private key, that we’re going to protect very carefully. Possession of that key allows you to cryptographically prove your identity as Amazon.com. In the AWS IoT world, everything MQTT is TLS 1.2, and with a restricted set of strong cipher suites. Now that we’ve got TLS established and the server is authenticated, we have message integrity and confidentiality, but we have absolutely no idea who the client is. That’s why you have to sign in to your account when you go to amazon.com. Mutual auth….
- What do we need? Certificate – identity, contains the public key Private key – used to prove ownership of the certificate Root CA
- TLS Cipher Suites Key exchange authentication (keypairs) Block cipher Message digest
- This is the quick and easy way to generate a cert for use with a Thing.
- The private key has moved around the network. We will forget it. That’s an important point. There is no API to download the private key again. We do not retain it. Some hardware comes with the capability to generate a private key but that key can never leave the device. This interaction with our service is done over TLS, this transaction is well protected, but the private key is still moving around. It’s on the disk on your laptop or whatever client you’re using, it must be handled carefully.
- This is a standard mechanism used across the Internet. The CSR format is defined in PKCS#10, this is standard stuff, we didn’t make it up. Note that the CSR includes the public key that we want to use. It does not contain the private key, it just contains cryptographic proof that we have the private key. This means that the CSR is not a sensitive document. It can be moved across the network without concern for reducing the security of the system. A malicious attacker in possession of the CSR could at worst turn it into a valid certificate, which we’ve already said is public and can be freely distributed.
- This dance is more complicated, but the end result is the same. The Thing has a cert and a private key, it’s ready to be a part of the AWS IoT ecosystem. But, as a result of the extra complexity in this protocol, the private key has never moved from where it was generated. That makes it more likely that we’ll get the protocol right, that we won’t expose the private key. The ultimate version of this protocol is one where the private key is stored in some cryptographic hardware key store on the Thing, and the private key cannot be extracted. In at least some cases, this keypair will be burned into the device in the factory. Because we own the CA that is used for AWS IoT, and all certificate operations occur over authenticated AWS APIs, this is very amenable to automation, even at very high scale.
- Fun fact: CAs are under no obligation to use any of the data included in your CSR. They can fill in anything they want to fill in. We’re using certificates here because the librarys and software available work with certs. We don’t actually use any of the fields in the cert other than the DN (Distinguished Name), and we set that ourselves when we sign the cert.
- Fortunately AWS IoT offers several different approaches for certificate registration. One approach leverages something called an Intermediate Signing Certificate to provision device certificates locally during the manufacturing process. This way your devices can leave the factory without the factory needed to be connected to the internet, and then periodically the certs can get registered by the factory to AWS IoT – as long as it happens before the devices actually end up turning on for the first time.
- This dance is more complicated, but the end result is the same. The Thing has a cert and a private key, it’s ready to be a part of the AWS IoT ecosystem. But, as a result of the extra complexity in this protocol, the private key has never moved from where it was generated. That makes it more likely that we’ll get the protocol right, that we won’t expose the private key. The ultimate version of this protocol is one where the private key is stored in some cryptographic hardware key store on the Thing, and the private key cannot be extracted. In at least some cases, this keypair will be burned into the device in the factory. Because we own the CA that is used for AWS IoT, and all certificate operations occur over authenticated AWS APIs, this is very amenable to automation, even at very high scale.
- This dance is more complicated, but the end result is the same. The Thing has a cert and a private key, it’s ready to be a part of the AWS IoT ecosystem. But, as a result of the extra complexity in this protocol, the private key has never moved from where it was generated. That makes it more likely that we’ll get the protocol right, that we won’t expose the private key. The ultimate version of this protocol is one where the private key is stored in some cryptographic hardware key store on the Thing, and the private key cannot be extracted. In at least some cases, this keypair will be burned into the device in the factory. Because we own the CA that is used for AWS IoT, and all certificate operations occur over authenticated AWS APIs, this is very amenable to automation, even at very high scale.
- This pattern of using intermediate CAs works well in the real-world. iRobot told us that this ability to have intermediate certificates deployed to their factories improves their security and logistics around manufacturing. For example, logistics are improved because internet connectivity blips between the factory and AWS IoT don’t hold up the assembly line. In general, customers have told us about a variety of manufacturing processes and constraints that they have, so we have been adding additional provisioning processes over time to give that flexibility that they people need.
- This dance is more complicated, but the end result is the same. The Thing has a cert and a private key, it’s ready to be a part of the AWS IoT ecosystem. But, as a result of the extra complexity in this protocol, the private key has never moved from where it was generated. That makes it more likely that we’ll get the protocol right, that we won’t expose the private key. The ultimate version of this protocol is one where the private key is stored in some cryptographic hardware key store on the Thing, and the private key cannot be extracted. In at least some cases, this keypair will be burned into the device in the factory. Because we own the CA that is used for AWS IoT, and all certificate operations occur over authenticated AWS APIs, this is very amenable to automation, even at very high scale.
- This dance is more complicated, but the end result is the same. The Thing has a cert and a private key, it’s ready to be a part of the AWS IoT ecosystem. But, as a result of the extra complexity in this protocol, the private key has never moved from where it was generated. That makes it more likely that we’ll get the protocol right, that we won’t expose the private key. The ultimate version of this protocol is one where the private key is stored in some cryptographic hardware key store on the Thing, and the private key cannot be extracted. In at least some cases, this keypair will be burned into the device in the factory. Because we own the CA that is used for AWS IoT, and all certificate operations occur over authenticated AWS APIs, this is very amenable to automation, even at very high scale.
- Fortunately hardware companies are making this easier. Earlier this month, Microchip announced a new end-to-end security solution that handles the process of provisioning these keys and securely storing them in hardware: The AWS-ECC508 This solution comes pre-configured with certificates and keys in hardware and is ready to be recognized by AWS IoT’s Just In Time Registration. Take a look at the press release on Microchip’s website for more information. You simply connect the chip over I2C to your host microcontroller which runs an SDK to talk to the chip. Once this is in place, there is no need to load unique keys and certificates required for authentication during the manufacturing of the device as this chip is pre-configured to be recognized as one of your product’s devices in your AWS account without any intervention. Your business logic gets called when the device tries to connect to AWS IoT for the first time once it’s out in the field through AWS IoT’s new just-in-time registration feature, which completes the registration process and set up permissions for the device. At the beginning of the talk I was saying how IoT devices are generally constrained for compute power and battery power. To make security easier computationally for devices, this chip offloads some of that crypto responsibility from the rest of your constrained device. The device even has strong resistance against environmental and physical tampering including countermeasures against expert intrusion attempts. For more information, visit Microchip Technology’s website. http://www.prnewswire.com/news-releases/microchip-releases-industrys-first-end-to-end-security-solution-for-iot-devices-connected-to-amazon-web-services-cloud-300312193.html
- The level of protection that you go to depends on the threats that you face and the value of the data and the system that you’re protecting. As always, security is not an absolute, stop spending when it’s no longer worth spending.
- There’s great variety in hardware capability between Things of different types, makes, etc. Some are full-fledged Linux boxes, and the techniques that have been developed over the years for desktops, laptops, and servers can be applied here. Some are much more constrained systems, some have interesting hardware (some of which we inherited from DRM efforts). This talk can’t address all the possibilities here, but the point is that if you are concerned about software threats that originate from being on a network with potentially hostile actors, there’s a set of mechanisms that you can use to improve the protection of the private key.
- Side note: It’s important that every one of your Things have a unique certificate. If they don’t, they will appear to our service to all be the same Thing. You won’t be able to differentiate between them in policy or in the data that they publish. It’s also important that every one of your things have a unique keypair. While it is possible to put the same keypair on each thing and generate different certs for them, if you have a key exposure and need to rotate keys, your entire product line will be at risk.
- Topic: $aws/events/certificates/