Skip to content

Device API Encryption Requirements

Exosite IoT Connector Device APIs only supports secure communication with TLS encryption.

Encrypted TCP connections and IoT Device Security

Exosite's Device API requires encrypted TCP connections. IoT Devices communicate information which must be trusted, may contain strategic information for a business, and/or allow device configuration or control. Data communication over a public network, such as the Internet, has no guarantees of data integrity during the transport. In other words, data from and to your devices could easily be read and changed by anonymous 3rd party.

Supported TLS Version and Ciphers

TLS v1.2

By default, the TLS v1.2 Default policy is selected as that excludes ciphers that have known security weaknesses allowing 3rd parties to impersonate your device and potentially access and compromise transmitted data.

The TLS configuration for device connections is policy based and available on a per IoT Connector basis. Policies include a minimum enforced TLS version and an associated set of supported ciphers.

The following IoT Connector policies are currently available:

TLS v1.2 Default

  • Minimum enforced version: TLS v1.2
  • Includes ciphers introduced with TLS v1.2, excluding those that are no longer considered secure.
  • Ciphers ordered to ensure Forward Secrecy. ECDHE (Elliptic Curve Diffie-Hellman) suites are at the top of the list, followed by DHE (Diffie-Hellman): ECDHE_ECDSA, ECDHE_RSA, DHE_RSA.

TLS v1.0 Legacy

  • Minimum enforced version: TLS v1.0
  • Includes ciphers introduced with TLS v1.0 and later, and for legacy reasons, including ciphers that are no longer considered secure.
  • Ciphers order of preference: alphabetically ordered based on an internal property.

Custom

  • Minimum enforced version: Configurable for TLS v1.0, TLS v1.1 or TLS v1.2.
  • Configurable ciphers include those that are compatible with the selected TLS version. Non-secure ciphers are always excluded.
  • Ciphers order of preference: custom as provided in the IoT Connector configuration. Once configured, it is advisable to check the TLS security settings robustness on SSL Labs (see link below) and fine tuned (by reordering and/or including/excluding ciphers) if deemed necessary.

To further restrict which ciphers can be used by devices or to support legacy hardware, the "custom" policy can be selected and configured with a custom set of ciphers while device maker is made fully aware of the risk.

You can check your TLS security settings robustness on https://www.ssllabs.com/ssltest/.

SNI

When making a secure TLS connection attempt to the API domain, it is required to specify the domain as the SNI field in the TLS connection request.

SNI stands for Server Name Indication, which is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which host-name it is attempting to connect to at the start of the handshaking process. This allows Murano IoT platform to present multiple certificates on the same IP address and provide a dedicated certificate to each of the IoT device products (aka IoT Connectors) for high security. Most of the modern Web browsers and HTTP/MQTT clients have already supported the SNI feature behind the scenes during the TLS handshake process for secure HTTP/MQTT connections.

Additional Reading

More technical details about SNI and TLS handshake can be found in the following references:

SNI is a standard widely supported by most implementations. See for example how to set SNI with OpenSSL or the Exosite tutorial for Cypress WICED dev kit hardware.

Supported TLS Ciphers

A cipher is an encryption algorithm that uses encryption keys to create a coded message. Protocols use several ciphers to encrypt data over the internet. During the connection negotiation process, the client and the server present a list of ciphers and protocols that they each support, in order of preference. By default, the first cipher on the server's list that matches any one of the client's ciphers is selected for the secure connection.

The following table describes the supported cipher suites for Device Connectivity.

TLS Cipher Suites
TLS v1.2 (default) TLS v1.0 Custom
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 1
TLS_DHE_DSS_WITH_AES_128_CBC_SHA 1
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 1
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 1
TLS_DHE_DSS_WITH_AES_256_CBC_SHA 1
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 1
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 1
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 1
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
TLS_RSA_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA 2
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA 2
TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA 3
TLS_RSA_WITH_DES_CBC_SHA 3
TLS_ECDHE_RSA_WITH_RC4_128_SHA 3
TLS_RSA_WITH_RC4_128_MD5 3
TLS_RSA_WITH_RC4_128_SHA 3
TLS_RSA_PSK_WITH_RC4_128_SHA 3

Cipher Notes

1 Not usable with Exosite's currently configured certificates.

2 Not selectable with TLS v1.2.

3 Considered non-secure, therefore not selectable.

Root Server Certificates

The following root server certificates are available to download for establishing secure connections with Murano IoT platform. The Exosite Root CA RSA 2048 certificate is an Exosite managed certificate authority with a 40 year validity period.

Base Name Valid Until Download Link When to Use
Exosite Root CA RSA 2048 Jun. 13, 2058 .der .pem RECOMMENDED Longest validity. Requires download and installation on device (including standard operating systems). Especially use when device cannot remotely replace its certificate. (eg. hardcoded firmware, recommend always planning for a way.)
DigiCert Global Root CA Nov. 10, 2031 .der .pem When device is an operating system with regular security updates (linux/IoS/Android/Windows). In such case you usually also don't need to download & install it.