How To Address IoT Security Across Multiple Layers

The Internet of Things (IoT) has been a hot topic of discussion in technology in recent years and with good reason. The IoT provides a completely new market for innovative technology companies to explore. The future will see countless IoT devices that will transform our lives. Smart cities have the potential to improve citizens’ quality of life while energy saving technologies could lead to reduced bills for individuals and more efficient use of grid capacity.

A key challenge in building this future is the security of these new technologies. We have seen a number of major security issues in our existing Internet infrastructure in recent years (Heartbleed, Apple’s goto fail;, POODLE) which have left consumers with questions over how the IoT will protect the potentially sensitive data it will expose. Clearly a key requirement for any successful IoT company is a robust security architecture. This post will outline five key considerations any developer should acknowledge while building and designing their IoT system.

1. Include Security in the Development Process From Day One

Appropriate security is important in the development of any good technology but is particularly important in the development of IoT products. IoT products expose potentially highly sensitive information (such as health data from a personal monitor or occupancy data from your smart home) both over wireless networks and to the Internet. Protecting this data is vital to an IoT product’s success.

Complicating matters further is the fact that many IoT devices are designed with constrained computational resources. These constraints have benefits - low cost of manufacture and low power operation - but they also make it difficult to include security as a late or post development consideration. Simply put, if you delay planning your security you may find those limited resources are being completely consumed by your application with none left for your security measures.

Early planning will allow you to avoid these complications and also allow you to choose the most appropriate security measure for your device. As we’ll see, there are quite a range of possible measures.

2. Hackers Will Attack Every Security Measure

For every security technology there is someone trying to crack it. Some security measures (for example, Wi-Fi’s Wired Equivalent Privacy (WEP)) can be broken due to inherent flaws; specifically the fact that WEP keys have a 50% chance of repeating every 5,000 packets means the Encryption can be easily cracked. It goes without saying that such weak security measures or flawed protocols should not be used. But even the more robust protocols (such as AES, Triple-DES, RSA or DSA) have opponents looking to break them.

AES is a very robust encryption scheme that provides protection to everything from web traffic to WPAN (Wireless Personal Area Network) networks. As such it makes an ideal candidate to demonstrate how a strong encryption scheme can still be attacked. The best way to attack AES encrypted data is to acquire the encryption keys. This might initially sound difficult but can be very achievable for someone with ample knowledge and the right opportunity.

AES is a symmetric-key algorithm. This means that the same key is used to encrypt and decrypt data, which in turn means that both the sending and receiving parties must have this key. Establishing a common key is referred to as “key exchange”. Weaknesses in the key exchange can allow a third-party to intercept the key and so decrypt any future AES encrypted transmissions.

In WPAN networks such as ZigBee and Classic Bluetooth such key exchange attacks are possible. ZigBee uses link and network keys to encrypt data transmissions and the exchange of these keys is encrypted with a master key. However, the master key must be agreed upon first. A poor choice of key exchange algorithm can lead to a complete compromise of your network’s security.

Classic Bluetooth Legacy Pairing included a key exchange algorithm that was successfully attacked to recover the pairing PIN (see the paper by Yaniv Shaked and Avishai Wool Cracking the Bluetooth PIN) and it’s worth noting that Classic Bluetooth Legacy Pairing did not use AES but the concerns about key exchange methods and protocols are still valid. In later versions of the Bluetooth specification, Elliptic Curve Diffie-Hellman (ECDH) key exchange was introduced to mitigate an attacker from passively eavesdropping on key exchanges to recover keys.

However, even with a strong key exchange algorithm such as ECDH, the keys can be recovered. A number of the available SSL/ TLS cipher suites use ECDH to exchange keys but the Heartbleed bug in OpenSSL (a widely used SSL/TLS Library) allowed attackers to potentially recover keys after key exchange. Specifically, the bug leaked application memory to an attacker and with enough attacks, important information such as session keys—or even worse, server private keys—can be obtained.

Be sure to read the next Security article: Cisco Releases Vulnerability Disclosure API