Not all IoT devices are equal when it comes to data sensitivity and fidelity. When a device is used to collect, analyze and transmit sensitive data to SAMI for further research and analysis, a number of security-related requirements must be met. The most important ones are arguably related to reliable device identification and authentication.
The following scenarios and negative effects must be avoided:
- Device spoofing, e.g., by using a generic HTTP client that is mimicking a real device.
- Lack of proper device authentication, which can lead to transmitting data from an unknown, uncertified or counterfeited device.
- Unreliable or insufficient information about the device type, which can lead to corrupted data stored in an analytical cloud.
What is our solution?
We’ve looked at few solutions to address all these problems and eventually chose a traditional, proven approach based on public/private key cryptography. We also use two-factor authentication to securely pair a device with a device owner.
This is how Secure Device Registration (SDR) looks at the high level: Simband uses a “Secure Element” chip to securely store the client’s private key used in an SSL handshake with mutual client server authentication. More specifically, Simband devices use NXP’s Secure Element, but it’s not a requirement—any chip with a similar functionality can be used as well.
The SAMI server will verify a client certificate’s signing authority before it establishes a secure connection. The device will also validate the server’s identity to make sure that it talks to a trusted server.
After a secure connection is established, SAMI will generate a one-time password (PIN) and send it to the device. A user will read the PIN from the device’s screen and enter it to a device registration page on SAMI Portal. If the PIN is correct, SAMI will issue an authentication token and send it back to the device.
The device will securely store the token in the Secure Element and use the token in all subsequent communications with SAMI.
We take security seriously. We use standards that do not cause serious performance problems for the client, while delivering high-level security that would be difficult to break.
As you probably noticed in the first diagram above, we support TLS1.2 protocol only. We have also thoroughly reviewed ciphers used in SSL handshake and have chosen the one that is not vulnerable to various SSL attacks. Our preferred SSL cipher is ECDHE-ECDSA-AES128-GCM-SHA256. Since it’s based on Elliptic Curve Cryptography (ECC), we also had to pick up a curve to use.
To avoid possible cryptographic backdoors and Double_EC_DBRG effects, we’ve decided to stay away from OpenSSL default and NIST-P256 standard. We’ve chosen the brainpoolP256r1 curve instead, which is a very popular European standard when it comes to ECC. The major benefit of our choice is that selection of all domain parameters is clearly defined by the Brainpool standard, which doesn’t leave a room for cryptographic backdoors.
Using relatively new block ciphers such as Galois Counter Mode (GCM) instead of more traditional CBC allows us to avoid known CBC vulnerabilities leading to dangerous and well-known exploits such as “BEAST”.
Finally, our symmetric cipher selection (AES-128) has been motivated by both efficiency of implementation and security. Since AES-128 and AES-256 are considered equally secure, we’ve decided to stick to the former and decrease the computational load on IoT devices (30-40% if compared with AES-256, according to some tests).
Implementation considerations for device developers
If you use OpenSSL on a client, you shouldn’t have any problems, because its latest version (1.0.2) supports all ciphers and protocols described above, including Brainpool curves.
If you use Java on a client, meeting our security requirements could be more difficult, but still doable. You should remember that Java 1.7 doesn’t support TLS 1.2 ciphers and Java 1.8 doesn’t support Brainpool curves.
Nevertheless, supporting all our requirements in Java 1.8 is possible with Bouncy Castle (BC) APIs. You can use BC’s TlsProtocol and other related classes to connect to our SDR’s endpoint.
If you want to use Java’s HTTP clients that rely on a traditional SSL Java stack (SSLConnection, SSLConnectionFactory, etc.), you might want to consider writing a wrapper around BC’s TlsProtocol. We’ll write about this in details in the next blog if there is an interest.
We’re not saying that each and every IoT device in the world should use SDR to connect to SAMI, but when it comes to really sensitive data that you want to protect well, we would strongly recommend the described approach.