Protect Against Cyber Attacks by Securing Your IoT Devices

The damage a hacker could achieve through compromising a connected home security system, a vehicle, printer, or even a medical device is immense. IoT devices can act as a “back door” to the network that hosts them, enabling a multitude of attacks. The stakes are high and protecting an always-on IoT network is essential. 

Security by design, identity management, physical attack security and, critically, trust are among the key ingredients of an effective IoT solution. 

Security by Design

Successful security by design takes a holistic view of what happens when a device is attached to a network. By thinking like an attacker, we can identify vulnerabilities and layer appropriate defenses. Pre-embedded keys and credentials are crucial for simplified integration in IoT cloud platforms. However, simplicity poses threats to the device IDs and credentials being stored at rest (information securely stored in the roots of devices during the manufacturing process).

For extra-sensitive IoT applications, including automotive, healthcare, and smart infrastructure grids, it is prudent to store IDs and credentials in a tamper-resistant Electronic Secure Element (eSE) to protect both physical and digital access. Before being shipped, the eSE is loaded with a secure, tamper-resistant operating system and a set of secure applications chosen by the device manufacturer. When end-users purchase a device that embeds an eSE, they have to first activate the eSE and then can securely download and personalize any application.

Identity Management

Machine identities can be protected with device X.509 digital certificates, which are used in place of passwords to authenticate trusted connections between network endpoints. Unlike passwords, certificates can’t be stolen. A certificate is an assurance of identity and authorization using a secret private key (stored in Client Side) validated with a known public key (stored in Server side). 

The private key never leaves the device side and isn’t sent to the server. Proper hardware measures must be in place to ensure the private key is stored in a secured partition. Firmware and secure storage partitions must be decoupled, thus allowing for separation of firmware and certificates provisioning. 

Physical Attack Security

Although remote attacks are the most common security threats, physical security of IoT devices is also important. To hinder physical attacks, the IoT device should prevent attackers from easily reading everything in memory. For example, JTAG ports should not be open for use on a production device. The IoT device must store security credentials and code images should be encrypted. Rendering them in memory poses threats since attackers might find a way to read or write from/to memory.

Trust

Pre-embedded IDs and encryption keys are essential elements for secure data encryption, the digital signature of messages, and the over-the-air (OTA) device and security updates. To enable a truly trusted ecosystem, each device must be authenticated with an embedded and cryptographically provable identity. If you can’t trust the identity of the device, then you can’t trust the data you receive from the device. Once a device has a trusted identity, then all the other services and communications from it can be protected. 

Mutual Transport Layer Security (mTLS) is a method for mutual authentication, with each side of a communications channel verifying the other's identity, instead of only one side verifying the other. This method ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. It is often used in a Zero Trust security framework, in which no user, device or network traffic is trusted by default. 

This approach helps eliminate many security vulnerabilities. For instance, mTLS can prevent various kinds of attacks, including man-in-the-middle, spoofing, phishing and so forth. It is highly useful for individual organizations on a small scale, especially when those organizations employ a Zero Trust approach to network security. 

Regarding mTLS authentication flow, the organization implementing mTLS acts as its own certificate authority. This contrasts with standard TLS, in which the certificate authority is an external organization. A "root" TLS certificate is necessary for mTLS. This enables an organization to be its own certificate authority. The certificates used by authorized clients and servers have to correspond to this root certificate. The root certificate is self-signed, meaning that the organization creates it themselves.

Typically, clients and servers establish secure, authenticated communications using a cryptographic handshake, such as the TLS 1.3 protocol. This ensures that a connection is authenticated, so that the communicating parties know who they are speaking to, and encrypted, so that their data is private. 

The exchange in such protocols goes as follows, and is illustrated in the diagram below:

1. The client device makes a connection to a server.
2. The server presents its identity to the client and cryptographically verifies that it owns the identity. The client confirms that it trusts the server’s identity.
3. The client device sends its own identity and cryptographic verification back to the server. The server confirms that it trusts the client’s identity.
4. An encrypted channel is established so the client and the server can communicate privately.

IoT Device Authentication and Provisioning

There are some security caveats with TLS authentications around server (IoT core) communication and the client-server (IoT device).

Server-side issues

With certificate-based mTLS, we have to trust the organization that issued the digital certificate. Therefore, we need to develop a mechanism to verify the Certificate Authority (CA) issuing organization or a dedicated server storing CA in case of self-signed certificate.

For the server side to trust a device, the solution is to program the client device’s firmware with a predefined server’s endpoint to which IoT devices will connect. Also, the device needs to safely store its private key (paired with the server’s public key used to sign a transferred certificate). This is a means to verify received CA’s signature on the server’s certificate. The IoT devices are programmed to trust this server certificate. When the server presents its identity (signed certificate), the IoT device knows to trust it.

The manufacturer establishes a unique device identity by extracting a unique ID from each device and storing it in a dedicated corporate database white-listing trusted devices. The client IoT device simply sends its identity to the server, which confirms the identity is listed in its database. The server has then established trust in the device without having to handle certificates. This solution can be costly for a manufacturer to extract identity from every device, especially if there are millions of them. It may also be challenging to secure and manage the device identities on the server side. However, storing a database of valid device identities is a practical solution to device authentication. 

IoT device (client-side) issues

mTLS protocol and CAs are not suitable for authenticating IoT devices. For example, in many cases devices operate in private networks and therefore have no access to publicly available internet-based CA. So, it is necessary to assign a unique identity and find a way to prove it is legitimate without having to reference a public CA.

You can do this by establishing something unique about each device while it is being manufactured or its firmware is being programmed. This process is known as “provisioning.” It can be accomplished in one of two ways. The first is to extract a unique serial number and store it in the server’s database to verify device’s identity – a somewhat arduous process.

The second approach is to inject a signed certificate into the device during manufacturing or later, by a trusted user in the field. In this approach, the manufacturer would inject each device with an authentication ID that is presented by a generated-signed (signed by server side artificial self-signed CA) device certificate. The signed certificate plays the role of an identification card. In this way, during manufacturing, each device is encountered as an anonymous thing without an explicit, distinct attribute like a serial number. 

For the device manufacturer, this authentication method is quick to implement and simplifies the manufacturing process by eliminating complexities associated with the explicit serial number provisioning flow needed in the first approach outlined.

But there are significant disadvantages. This approach lacks identity tracking for the shipped device since the customer who bought the device cannot be identified by an explicit bound ID number. Also, the server treats the devices indifferently to their owners, which means that any involuntary change of ownership (i.e. theft) could result in a now-untrusted device on the network. In addition, this method hinders tracking and control of the customer’s devices once they are provisioned. 

Clearly, device provisioning is a complex topic and it warrants a closer look. In part 4 in our IoT fleet management series, we’ll delve a little deeper into device provisioning, including providing some examples to bring the concept to life.

If you’d like to delve deeper into cybersecurity, check out this whitepaper, which covers various aspects of safe IoT fleet management design. And if you missed the last installment in our series, in which we covered OTA updates, you can read it here.