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
54. Takeaways
• Structure topics for permissions
• Make policies as restrictive as possible
• Wildcards can simplify policy management
• Rules can help with fine-grained permissions
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
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
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.
What is shown here is a reference architecture from Intel on using built-in hardware level security to authenticate the hardware using Intel’s Helix Device Cloud and then using mutual authentication with AWS IoT. More information on this architecture can be found on our developer resources page.
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.