Wednesday, October 3, 2018

Aws IoT - Device Connectivity

Devices connect to Aws IoT core using one of the supported protocols. Data from the device is transported to the Aws IoT as JSON document.

Protocols

The message broker supports the use of the MQTT protocol to publish and subscribe and the HTTPS protocol to publish. The message broker also supports MQTT over the WebSocket protocol.
  • MQTT, Client Certificate, 8883, 443
  • HTTP, Client Certificate, 8443
  • HTTP, SigV4, 443
  • MQTT + WebSocket, SigV4, 443

Connectivity from Device using Client Certificate

Resources on Device

  1. x509 Certificate specific to the device (establishes device identity; equivalent to username in classic authentication). An X.509 certificate is a document that is used to prove ownership of a public key embedded in the cert. CA creates a certificate and signs it with a private key. Anyone can now validate your device certificate by checking its digital signature with the CA’s public key. (.pem.cer file)
  2. Private key corresponding to device's x509 (for signing communication)
  3. Root certificate for Aws IoT server (to verify the authenticity of certificate returned by Aws IoT to the device; Answers question: Am I talking to the real Aws IoT Server?). On Aws IoT Button, this certificate is already baked in. (.pem file)
  4. Client connectivity to Internet: WIFI SSID, password
  5. Aws IoT Server endpoint (region-specific, endpoint for multiple devices). For example: abc.iot.us-east-1.amazonaws.com

Resources on Aws IoT Server

  1. x509 Certificate specific to the device with an associated Certificate Id.
Each connected device is represented as thing. It has unique arn. For example:
arn:aws:iot:us-east-1:995042574424:thing/iotbutton_G030MD045XXXXX

Communication Flow

Two step process.

1) Establish secure communication between the device and Aws IoT server. This is just like connecting to a secure website. The Server sends it's certificate to Client. Client wants to make sure it is talking to the real AWS IoT. Client verifies that server cert is authentic by using the AWs IoT Service root certificate present on the device. The public key that’s embedded in the root certificate is used to validate the digital signature on the Server provided certificate. Client and Server then negotiate and use a shared secret to encrypt communication.

2) Next device identifies itself to Aws IoT server. Device sends a copy of its device certificate to the server. Device calculates a hash over the data sent to Server with its private key and sends it as the digital signature. AWS IoT is now in possession of the devices’ public key (which was in the device certificate) and the digital signature. It uses the device’s public key to check the accuracy of the digital signature. By using the unique identifier of the certificate, it knows exactly which device is establishing a MQTT session. From then on, all messages between the device and AWS IoT are secured using the shared secret (for efficiency).

Aws Resource Access

Aws resources that are allowed to be accessed by a device are specified by associating a policy with Device's certificate on the Aws IoT Server.

For example, the following policy publishes the data received from a device to an SNS topic.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "iot:Publish",
      "Effect": "Allow",
      "Resource": "arn:aws:iot:us-east-1:995042574424:topic/iotbutton/G030MD045XXXXX"
    }
  ]
}

1. Messages are published to a device specific SNS topic

2. Rules engine picks up the message from the SNS topic and then publishes the data to configured destination (under Act tab).

Data Flow

Data received from device by the Message Broker on Aws IoT Server and can be routed to another Aws resource by Aws IoT Server's Rule engine.
  1. DynamoDB
  2. Kinesis
  3. Lambda
  4. S3
  5. SNS
  6. SQS