Locking down an IoT design requires more than encrypted messaging. Developers need to extend security from the underlying secret keys through authentication, secure sessions and secure messaging. Yet, the complexity of the design, implementation, and functional aspects of an intact security chain leads many projects to compromise security for the sake of cost and schedules.
This need to compromise is diminishing, however, in large part due to devices that developers can use to easily implement comprehensive security features in IoT devices and other deeply embedded systems. One such device is the MAXQ1061 from Maxim Integrated.
This feature will describe how IoT security systems work before introducing the MAXQ1061 and showing how it can be used to quickly solve for security at the transport layer.
Security is fundamental to the IoT
Underlying the vision of the IoT, users expect applications to process data streams to provide detailed information about the user, their environment, and their equipment. The ability to protect these applications and ensure the integrity and authenticity of data is inherent in this vision. Yet, well-publicized attacks on systems and data continue to call into question that ability. Accordingly, interest has grown rapidly for more effective solutions for securing data and systems.
At the device level, designers can already find MCUs that integrate hardware accelerators for encrypting and decrypting data using a wide variety of ciphers including AES, SHA, and 3DES, among others. Yet, data encryption/decryption is only one piece of a larger set of capabilities required to secure IoT applications using standard security protocols such as TLS (Transport Layer Security).
TLS provides a standard protocol for secure communications across networks between servers and clients such as Web browsers and IoT devices. In this protocol, communications occur as a series of individual secure sessions that include security parameters that are typically established uniquely for each individual session. It’s noteworthy that TLS also includes methods of reusing session security parameters from one session to the next, but those methods can expose IoT applications to additional security threats and are not included in this discussion.
In using TLS, clients and servers begin a TLS session by using the TLS handshake protocol (Figure 1). This authenticates each device-to-server connection and creates a “master secret” – a private cryptography key used in common during the TLS record protocol for encrypting and decrypting data exchanged during that session. At each step within this handshake protocol, clients and servers ensure the security of the process by using several fundamental security mechanisms including private key storage, true random number generation, and standard encryption/decryption algorithms.
When a client such as an IoT device needs to connect to a server, it begins the TLS handshake by sending a client_hello message, which includes information about the client’s ability to support specific TLS methods as well as a random number. The server responds with the selection of TLS methods to be used, its certificate (server public key), and other details that depend on the nature of the cipher suite and security policy being used.
For example, although Web applications typically authenticate the server alone, secure IoT applications demand that both client devices and servers authenticate each other to mitigate threats such as man-in-the-middle attacks. Without client authentication, unauthorized devices could pretend to be legitimate devices and connect to the IoT network to provide an entry point for bad actors. To implement mutual authentication, the server adds a request for the client certificate to this particular phase.
In the next phase of the handshake negotiation, the client sends its certificate as well as a signature hash of the previous set of messages created using its private key. The server uses the client certificate (device public key) and signature hash to verify that the requesting client device actually possesses its private key. In doing so, it also verifies the device’s ownership of the client certificate. In some cases, the client might also send a pre-master secret created using the server’s certificate (server public key).