Best Practices for IoT Security in the Cloud

© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
John Rotach
Software Development Engineer – AWS IoT
October 27, 2016
Best Practices for IoT
Security in the Cloud

All things around us are getting connected

Things will proliferate
2013 2015 2020
Vertical Industry
Generic Industry
Consumer
Automotive
Many
Some
Lots

Connected ≠ Smart
Internet 1985 IoT 2016
Gopher HTTP
FTP MQTT
NNTP CoAP
Telnet XMPP
Archie AQMP

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

But my data
isn’t sensitive!

Why do IoT at all?
Changes
happen in
the real
world!

The Risk
Changes
happen in
the real
world!
Bad

Requirements
Secure Communications with Things
Strong Thing Identity
Fine-grained Authorization for:
Things
People

The System
DynamoDB LambdaKinesis

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

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

What are Certs and Keys?
Certificate – Public identity
Private Key – Private proof
Root CA – Validate
rootCA

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)

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"
}

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

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

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":
"certificateId":
"b5a396e…SNIP…400877b"
}

Register your own Certificate Authority

Register your own Certificate Authority
CSR

Provisioning your own certificates
CSR

Provisioning your own certificates

Just-in-time registration
AWS
Lambda

Enhanced Security from Device to Cloud

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

Private Key Protection
Software
chroot
SELinux
Hardware
TPMs
Smartcards
OTP Fuses
FIPS-style hardware

Identity Revocation
$ aws iot list-certificates
{
"certificateDescriptions": [
{
"certificateArn":
"status": "ACTIVE",
"certificateId":
"d7677b0…SNIP…026d9"
"lastModifiedDate": 1443070900.491,
"certificatePem":
"ownedBy": "123456972007",
"creationDate": 1443070900.491
}
]
}

Identity Revocation
$ aws iot update-certificate --certificate-id "d7677b0…SNIP…026d9" --new-status REVOKED
$ aws iot list-certificates
{
"certificateDescriptions": [
{
"certificateArn":
"status": "REVOKED",
"certificateId":
"d7677b0…SNIP…026d9"
"lastModifiedDate": 1443192020.792,
"certificatePem":
"ownedBy": "123456972007",
"creationDate": 1443070900.491
}
]
}

Takeaways
• Many provisioning methods
• Each device gets its own certificate
• Use a certificate authority for offline provisioning

Policy actions
• Connect
• Publish
• Subscribe
• Unsubscribe
• Receive

Connect policy
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
"Action":[ "iot:Connect" ],
"Resource":"arn:aws:iot:us-east-1:123456972007:
client/MY-THING-NAME"
} ]
}

Connect policy
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
client/MY-THING-NAME_*"
} ]
} MY-THING-NAME_Application1
MY-THING-NAME_Application2
MY-THING-NAME_Application3

Publish policy
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
"Action":[ "iot:Publish" ],
topic/$aws/things/MyThing/shadow/update"
} ]
}

Even finer control
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
topic/$aws/things/MyThing/shadow/update"
} ]
}
Allows updating the entire shadow

Even finer control
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
topic/actions/MyThing/open"
} ]
}
Use a different topic

Even finer control
AWS IoT
Direct publishing to shadow

Even finer control
AWS IoT
Use a rule to update specific shadow fields

Takeaways
• Structure topics for permissions
• Make policies as restrictive as possible
• Wildcards can simplify policy management
• Rules can help with fine-grained permissions

Applications

IAM Role policy
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
"Resource":"*"
}, {
"Effect":"Allow",
"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/*"
]
}
]
}

Mobile
AMAZON
COGNITO

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"
}

{
"Effect": "Allow",
"Resource": "*"
}
{
"Effect": "Allow",
}
Amazon
Cognito

{
"Effect": "Allow",
"Resource": "*"
}
{
"Effect": "Allow",
}
AWS IoT

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

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!)

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

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-*"

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

Demo
Creating Certificates
- 1-click
- CSR
Just In Time Registration

Thank you!
John Rotach
@rotach
AWS IoT: https://aws.amazon.com/iot/
Documentation: https://aws.amazon.com/documentation/iot/
AWS Forums: https://forums.aws.amazon.com/forum.jspa?forumID=210

Best Practices for IoT Security in the Cloud

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Best Practices for IoT Security in the Cloud

Similar to Best Practices for IoT Security in the Cloud (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Recently uploaded

Recently uploaded (20)

Best Practices for IoT Security in the Cloud