Device security

Security is a critical concern when deploying and managing IoT devices. ClearBlade IoT Core offers these security features:

• Per-device public/private key authentication using JSON Web Tokens (JWTs, RFC 7519).

  • This limits an attack’s surface area because a compromised key would affect only a single device and not the whole fleet.

  • JWTs are valid for a limited duration, so any compromised keys will expire.

• Support for RSA or elliptic curve algorithms to verify signatures, with enforcement for strong key sizes.

• Support to rotate keys per device by allowing concurrent keys to be registered and support for expiration time per credential.

• TLS 1.2 connection, using root certificate authorities (required for MQTT).

• User accounts with limited roles and permissions control ClearBlade IoT Core API access.

Provisioning credentials

The following diagram summarizes the process for provisioning device credentials. The authenticated provisioner, often the user configuring the device, is assumed to have created a project and registry and has permission to create devices. The provisioner uses the ClearBlade IoT Core API or Console to create a logical device in the cloud.

Open

1. The provisioner generates the public-private key pair.

2. The provisioner creates the device using the ClearBlade IoT Core API or Console, specifying the public key just created. This will be used to verify the device's identity.

3. The ClearBlade IoT Core device manager stores the device resource and public key.

4. The device manager responds to the provisioner, indicating the device was created.

5. The private key is stored on the device to use later for authentication. The hardware Trusted Platform Module (TPM) can be used for this step.

The order of steps is not prescriptive. For example, the key can be stored on the device before the device has been registered in ClearBlade IoT Core.

For information on creating keys, see Creating key pairs.

Authentication

This diagram summarizes authentication in ClearBlade IoT Core using MQTT:

Open

1. The device prepares a JSON Web Token (JWT), as described in Using JSON Web Tokens. The JWT is signed with the private key from the authentication flow.

2. When connecting to the MQTT bridge, the device presents the JWT as the password in the MQTT CONNECT message. The username content is ignored; however, some MQTT client libraries will not send the password unless the username is specified. For best results, set the username to an arbitrary value like unused or ignored.

3. The MQTT bridge verifies the JWT against the device's public key.

4. The MQTT bridge accepts the connection.

5. The connection is closed when the JWT expires (after accounting for the allowed clock drift).

Security standards

ClearBlade IoT Core uses digital signature–based authentication for RSA and elliptic curve signed tokens. These algorithms are supported:

• JWT RS256 (RSASSA-PKCS1-v1_5 using SHA-256 RFC 7518 sec 3.3)

• JWT ES256 (ECDSA using P-256 and SHA-256 RFC 7518 sec 3.4), defined in OpenSSL as the prime256v1 curve

The RSA algorithm is commonly used and is widely supported by client libraries. However, the generated keys and signatures can be large (one to two kilobytes). Additionally, RSA can use a significant amount of resources (regarding key length and CPU), affecting devices with limited resources.

The elliptic curve algorithm is well supported but is less widely used than RSA. You may have to install additional dependencies in your client library to use the elliptic curve. However, the generated keys and signatures are significantly smaller than those generated by RSA, which can be useful for devices with limited resources.

Key strength

A 112-security bit minimum is required by ClearBlade IoT Core, following NIST recommendations (Section 5.6.2, pages 55-56). This translates to a minimum 2048-bit key size for RS256 (see Table 2 in the NIST recommendations, page 53).

ES256 has a 128-security bit preset level (fixed key size).

Public key format

When registering a device’s public key, it must be in one of these formats:

The RSA_PEM and ES256_PEM keys begin with -----BEGIN PUBLIC KEY----- and end with -----END PUBLIC KEY-----. The RSA_X509_PEM and ES256_X509_PEM keys begin with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.

For information on creating keys, see Creating public/private key pairs.

Key rotation

ClearBlade IoT Core supports multiple active keys (up to 3 per device) to allow uninterrupted rotation. The service will try to verify JWTs with each active key and will accept a connection if any active key matches.

The API allows you to define an expirationTime for each device credential (public key). After it expires, the key will be ignored, but it will not be automatically deleted. A 10-minute clock-skew allowance applies, and a key will never expire if no expiration time is specified.

Device security recommendations

ClearBlade IoT Core does not enforce these security recommendations but will help you secure your devices and connections:

• Keep the private key secret.

• Use TLS 1.2 when communicating with mqtt.googleapis.com or mqtt.2030.ltsapis.goog on ports 8883 and 443. To maintain TLS connections:

  • Verify that the server certificate is valid using a Google root CA certificate.

  • Perform regular security-related firmware updates to keep server certificates up-to-date.

• Each device should have a unique public/private key pair. If multiple devices share a single key and one is compromised, an attacker could impersonate the devices configured with that one key.

• Keep the public key secure when registering it with ClearBlade IoT Core. If an attacker can tamper with the public key and trick the provisioner into swapping it and registering the wrong one, the attacker can authenticate on the device’s behalf.

• The key pair to authenticate the device to ClearBlade IoT Core should not be used for other purposes or protocols.

• Depending on the device's ability to store keys securely, key pairs should be rotated periodically. When practical, all keys should be discarded when the device is reset.

• If your device runs an operating system, update it securely. For devices that don't have an operating system, ensure that you can securely update the device's software if security vulnerabilities are discovered after deployment.

• Ensure that you have a way to update root certificates.

• Ensure that the device clock is not tampered with. If it is compromised, an attacker can trick the device into issuing tokens that will be valid in the future, circumventing the token's expiration time. For best results, use the Google Public NTP server.