IoT Security using AWS

IoT Security using AWS

AWS IoT core service is used by devices to connect and send messages to AWS cloud. Its main components are 

message broker – receive and transmit messages, 

device shadow – manage current state and update state changes

rules – process incoming messages based on some pattern,

registry – keep track of device properties and device groups

security – Certificates and policy

When using AWS IoT authentication, the message broker authenticates and authorizes all actions in your account. The message broker is responsible for authenticating your devices, securely ingesting device data, and adhering to the access permissions. 

Transport security

The AWS IoT message broker and Device Shadow service encrypt all communication with TLS version 1.2. TLS is used to ensure the confidentiality of the application protocols (MQTT, HTTP) supported by AWS IoT and is widely supported in all programming languages and operating systems. This means no one eavesdropping on the network can understand the messages.

There are three types of entities who communicate with message broker

1. Devices – They are identified by x509 certificates and access is determined by the IoT Policy provided

2. AWS Users – They are identified by their credentials and access is determined by IAM policies

3. Cognito identity – Cognito is a user management service from AWS that allows the user to login directly or via federated option. Cognito service allows authenticated users specific IAM roles which allow them access to AWS IoT service. IoT policies can be further used to restrict access.

Identity of Broker and devices using X509 certificates

Server certificates allow your devices to verify that they’re communicating with AWS IoT and not another server impersonating it. Service certificates must be copied onto your device and referenced when devices connect to AWS IoT. AWS IoT server certificates are signed by one of the following CA certificates: Legacy VeriSign certified CA, Amazon Trust Services Endpoints which has RSA and ECC based option.

Each device is required to have an x.509 certificate. X.509 certificates are more secure than other authentication mechanisms such as user name and password or bearer tokens as it uses asymmetric cryptography, so you can burn private keys into secure storage on a device. Sensitive cryptographic material never leaves the device.

We can get a certificate from AWS IoT directly from console or CLI. We can also upload our custom CA(certification authority) certificate to AWS and AWS automatically accepts all certificates signed by CA. AWS IoT authenticates X.509 certificates using the TLS protocol’s client authentication mode.

Certificates are attached to devices in AWS IoT. Policies are also attached to certificates. When a device attempts to connect presenting certificate the policy is checked before allowing connection.

IoT policy for fine-grained control

An AWS IoT policy is a JSON document that contains one or more policy statements. Each statement contains an Effect, an Action, and a Resource. The Effect specifies whether the action is allowed or denied. This can be used to restrict access to topics which are resources. An IoT Policy looks like this:

{

    “Version”: “2012-10-17”,

    “Statement”: [

      {

        “Effect”: “Allow”,

        “Action”:[“iot:Publish”],

        “Resource”: [“arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}”]

      },

      {

        “Effect”: “Allow”,

        “Action”: [“iot:Connect”],

        “Resource”: [“arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}”]

      }

    ]

}

This allows a registered device to connect with client id corresponding to thingname and publish to topic thingname.

Access as AWS Users

If we want to subscribe or publish data to AWS IoT message broker as AWS user, the user would need AWSIoTFullAccess or AWSIoTDataAccess IAM policies. For management tasks, there are specific policies. User is authenticated by username password or access key credentials. This includes all access from the management console and also access from standalone servers invoking AWS APIs.

In case of mobile apps etc, we cannot pass the access key credentials in the app code. Here we use temporary credentials with the help of Cognito identity to get/publish data. 

Custom authorizer

There is also an option for custom authorizer when we work with HTTP API. Here user can provide a custom function in AWS Lambda to return a policy.