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. |