The role of hardware in IoT security

Now that more and more devices are connected to the Internet and to other devices, collecting data, their influence on our safety is increasing and the importance of securing information systems - IoT systems in particular - is growing. Strong, verifiable device identity is therefore crucial, as protection of confidentiality, integrity and availability of information exchanged within an IoT system hinges on it. Establishing and protecting device identity is paramount, hardware plays a vital part in this.

According to the predictions by Gartner, IDC and McKinsey, there will be 20-50 billion devices connected to the Internet by 2020. Most of them will be collecting private and/or confidential data and will be able to directly access and be accessed by other devices via internet protocols. So far, the focus of information security in general has been mostly on privacy of personal data and confidentiality of business data. However, as stated in a recent paper, there will be more and more connected devices directly influencing our safety and livelihood: connected and autonomous cars, medical devices and critical infrastructure such as smart meters and power grid subsystems. Recent occurrences related to these critical systems - hackers remotely killing a jeep on the highway with the driver in it, Nissan LEAF’s vehicle features controlled across the globe via vulnerable APIs, a team of hackers taking remote control of a Tesla Model S, hacking risk leading to recall of 500,000 pacemakers due to fear of patient death and Ukraine’s power outage being a cyber attack, all show that the threat is serious and real, and its mitigation requires significant attention.

Security in IoT systems

If we follow the common security triad of confidentiality, integrity and availability (as mentioned in the NIST Special Publication ‘An Introduction to Information Security’) , we can define what constitutes security in IoT systems. IoT systems are made up of connected devices, each playing a defined role in the system: collecting environment data via sensors and/or acting upon the environment, based on the system rules. Therefore, integrity of an entire IoT system implies that the system consists only of the right components, meaning there are no rogue devices exchanging information with the system - only authentic devices are part of it.

Once device identity is established, the communication in the system can be made confidential, so that information is exchanged only between intended (authenticated) devices, preventing eavesdropping. Protection of information integrity also follows authentication, because authenticated device identity can be used to sign the exchanged information, securing it from tampering. Finally, availability includes resilience against accepting rogue connection attempts from unauthenticated devices which would hinder their performance and ability to engage in the bona fide communication with the rest of the IoT system.

Device identity

As we have established, strong, verifiable device identity is a crucial element of IoT security, as protection of confidentiality, integrity and availability of information exchanged within an IoT system hinges on it. So how is device identity established and proven? 

In human-to-machine communication, humans often authenticate to machines using a shared secret: a password. A drawback to using a password is that, in addition to the need to be pre-shared, it needs to be transmitted every time the authentication is performed, so it is vulnerable to an attack by an eavesdropper. Thus, to protect the password, the machine used by the human needs to already have established a trusted, confidential communication based on another security primitive.  

Instead, devices use cryptographic methods that indirectly prove the knowledge of a secret: given an input, they perform a computation which can only be done correctly if they possess the right secret. In practice, this can be achieved by using symmetric or asymmetric cryptography. Symmetric cryptography can be used if a secret is pre-shared between the communicating parties. For example, an IoT device and a device hub can mutually authenticate by letting each party decrypt a message encrypted by the other (e.g. using AES). Having established each other’s identity, they can continue to communicate securely using the shared secret. Furthermore, they can protect the integrity of the messages by signing them (e.g. using HMAC). 

Asymmetric cryptography does not require pre-sharing of secrets; instead both parties generate a public/private key pair and publish the public keys while keeping the private key secret. The parties from our example, an IoT device and a hub, could thus perform authentication and establish confidentiality and integrity of their messages using the asymmetric cryptography algorithms (e.g. ECDSA, ECDH) without the need to pre-share a secret. 

Protection of secrets

As we have stated, both in shared secret and public/private key scenarios, there exists a secret key, tightly coupled with the device, which needs to be protected. However, this is proving to be a difficult task, for one particular reason: security of connected devices is implemented in software. This is further complicated by the fact that, just like commodity software industry in the past, the IoT industry has so far been driven by maximising customer-perceived value (features), while minimising cost and time-to-market. This naturally leads the IoT industry to adopting generic, low-cost computing platforms capable of running general purpose, readily available open-source security code, which was originally designed with completely different threat model in mind. Often, such devices store keys in their (generic) permanent storage, together with the firmware and data. In case such a device is compromised by means of exploiting a software vulnerability, secret keys can be easily extracted remotely. In case of physical attack, an attacker can detach the permanent storage of the device and obtain secret keys by reading it directly. 

Device secrets can be protected in software by using white-box cryptography, where the actual implementation of cryptographic primitives (such as AES) is obfuscated together with the secret keys in such a way that makes it difficult to apply standard software reverse engineering techniques, such as disassembly, to attempt to recover the keys. However, the known white-box cryptography implementations have been broken so far

Benefits of secure elements

Secure elements, sometimes called cryptographic elements or “crypto chips” are electronic components (co-processors) designed with dedicated purpose to securely generate and store cryptographic secrets and use them in performing cryptographic operations. Typical implementations (e.g. from Atmel, Gemalto and Maxim)  include a hardware-seeded pseudo-random number generator (PRNG), hash function implementation (e.g. SHA-256), symmetric encryption implementation (e.g. AES), symmetric signature (HMAC), key exchange (ECDH) and asymmetric signature (ECDSA). In addition, secure elements are often made tamper-proof, making it difficult to read the secrets by using silicon reverse engineering techniques, and tamper-evident, having the ability to signal physical intrusion to the rest of the system.  

Properly implemented secure elements also include protection against side-channel cryptanalysis, such as power analysis, timing analysis and analysis of acoustic and electromagnetic emanations that could otherwise be exploited to learn about the stored keys. 

The lifetime of the device identity cryptographic secrets with secure element is as follows: upon device provisioning, the secure element generates the random key. Depending on the choice between the symmetric and asymmetric cryptography, the secret key is either shared between the participants (e.g. between the device and the IoT hub) or never leaves the device and its public counterpart is shared instead. The keys can be revoked during the device lifetime and new ones generated, repeating the process. The secret keys can be derived from a physical unclonable function, an “electronic fingerprint” of the device which uses amplified physical imperfections, unique to each manufactured chip, to derive its identity. 

Further benefits of deploying secure elements in IoT designs include their typical low power consumption, low sleep current, cryptographic throughput and performance (offloading the typically resource-constrained embedded CPU/microcontroller) and the relative ease of integration in existing hardware designs (via SWI or I2C interface). 

Limitations of secure elements

Secure elements are typically manufactured in the way that the cryptographic primitives, as well as their security parameters, such as key length, initialisation vectors, elliptic curve definitions, modes of operation are hardcoded in the chip design. This means that if a particular implementation is found insecure, the devices cannot be easily (remotely) updated to fix the problem.  

Conclusion

Establishment and protection of device identity is paramount to IoT system security. It amounts to secure generation and protection of cryptographic secrets. State-of-the-art techniques for protecting software cipher implementations using software obfuscation (white-box cryptography) have been shown to be insecure. Using secure elements tightly integrated with the device hardware and software provides a viable security foundation, protecting secrets and providing guarantees on device identity, communication confidentiality and integrity, as well as tamper resistance and evidence.  

Would you like to know more about this topic? Sirris has built up extensive experience and knowhow in IoT security. Contact us!

(Source picture: https://www.dreamstime.com/)

Share