Edge Security: Safeguarding the Network Against Mass Attacks

They say a chain is only as strong as its weakest link. In much the same way, a network is also only as secure as its weakest node. With the advent of cloud-connected devices, the risk of network exposure through end node attack has become a very real concern. A Gartner study estimates that by 2021, 21 billion IoT devices, could translate into potential threats, which can penetrate and infect the worldwide network.

An “edge device” is a hardware device that performs data acquisition, actuation, processing, and monitoring functions at the endpoint of an IoT network. Edge security deals with protecting devices against physical and cyber threats, thus making networks more safe and secure.

Identifying security threats

Devices usually connect to the cloud by using any wired/wireless communication technology. They can upload data to the server, either directly through Wi-Fi or LTE, or by using an intermediary gateway. This data is then processed to provide meaningful information to users. It also enables users to monitor and control their smart devices like smart bulbs, TV, speakers, etc. through cloud applications.

Model of a typical connected ecosystem

Usually, all communication between gateways, servers, and applications is well-secured by using SSL (Secure Sockets Layer), Rivest–Shamir–Adleman (RSA), or customized crypto algorithms. However, the end nodes remain exposed.

Threats with remote access:

1. Changing functionality and behavior of a device using Over-the-Air (OTA) firmware updates.
2. Damaging the device by overclocking, overheating, etc.
3. Performing battery-draining operations to kill the battery – especially in medical implants.
4. Using the end node to retrieve sensitive information from the server.

Security threats on physical access to a device:

1. Analysis of communication port data – USB, UART, JTAG to emulate fake devices
2. Firmware readout and binary modification
3. Patching bootloader if write-protection is not enabled.
4. Crashing the device by sending random data through ports
5. Timing attacks on access patterns for computation of encrypted payload
6. Glitching the hardware by disrupting power
7. Analysis of the chip’s power consumption during encryption
8. Analysis of electromagnetic radiation

… and many more.

Apart from these threats, attackers can also create a cloned device which uses the data extracted from vulnerable end nodes to bring down entire networks. All it takes is a dedicated hacker who understands these unfortified devices.

Understanding the risks

A simple device, like a temperature sensor, can bring down an entire network. The risks become more daunting as one considers human safety in the automotive and medical domain or national security in defense and mass transportation domains. Lack of security precautions has led to devastating breaches worldwide.  

In a recent smart home security breach, Forbes confirmed the leakage of over 2 billion data records. The compromised data included sensitive information like passwords, account reset codes, geographic locations, and video clips – exposing thousands of people to cyber as well as physical threats.

So, how do we ensure that deploying such devices does not compromise network security and user privacy?

Protection against threats

For a long time, edge security was a concern of only a handful of companies. The archaic assumption that security precautions are not required in simple devices is not applicable anymore. Today, end nodes must have security by default, and privacy by design.

With that in mind, let’s look at some best practices to secure end nodes against threats:

• Hardware Protection

Device engineers are now addressing the issue of hardware security. End nodes are now read/write-protected, extra communication channels are disabled, and the device has been made more robust to identify hardware fuzzing.

• Firmware/Software Protection

A secure firmware should execute predictably and operate correctly. It should have minimal exploitable vulnerabilities and no malicious logic. Additionally, it should resist or tolerate known attacks and should recover quickly from such attacks. It is recommended to follow a coding standard such as MISRA C, AUTOSAR, etc. and review the software. Static code analysis and dynamic testing tools come in handy for such tasks. Safe software practices, like the ones mentioned above, can protect hardware devices which are prone to physical attacks.

• Managing Encryption

Today, many device brochures often boast of AES-128 payload encryption. But is this enough? Despite all sorts of encryption, security can be breached.

This video shows how a $100 kit is being used to retrieve AES keys stored in the device, by analyzing the clock glitches and power consumption analysis.  

It is always recommended to use an asymmetric encryption algorithm over a symmetric one.

AES or Advanced Encryption Standard is one such example of symmetric encryption. In AES, a single key is used for both encryption and decryption. If there is a security breach on the device and the key gets exposed, this may lead to a security breach at the server-end as well.

On the other hand, asymmetric encryption uses two keys (public and private) to boost security. RSA (Rivest–Shamir–Adleman) uses this type of encryption. It should also be noted that the method of implementing the encryption on the device is as important as the type of encryption itself. Several security ICs with dedicated AES/TLS (Transport Layer Security)/RSA encryption hardware are available today, to provide additional security against side-channel attacks.

• Managing Keys

No matter how strong your encryption is, if the keys are exposed, the system will be compromised. Keys should always be stored in a secure location of the memory. In the absence of such a feature in the selected processor, an embedded secure element (eSE) can be used. With the launch of Arm Cortex M33 secure processors, TrustZone security technology is now accessible to more and more Original Equipment Manufacturers (OEMs). Trusted Execution Environment (TEE) can be used to run sensitive portions of the code like payload encryption and Personal Identifiable data processing.

• Individually Identifiable Devices

The unique identity of each device in the network should be managed well, and single-use tokens should be allocated to the device for communication. Firmware Over-the-Air updates should be digitally signed and verified before being flashed.

Conclusion

Device security is no longer an optional, add-on feature. Devices should be developed to provide security by default and privacy by design. Threat modeling and security tests should be incorporated into the architectural design and development cycle. It is also important to remember that a system is never 100% secure. It can always be hacked.

Therefore, it is imperative to constantly review all the threats and corresponding security measures, when deploying cloud-connected devices. Every day, thousands of new devices become a part of this ecosystem. From location trackers to industrial actuators, IoT is the future, but good security practices are a must to protect it very well.