Zenseio Blog

Key considerations for IoT sensor devices: 4 – Security
A padlock and key connected to a chain

Executive Summary:

  • Security is critical for IoT
  • End application defines security policy requirements
  • Security is weak if device crypto key are not well protected in IoT devices
  • Best-in-class security policies for IoT sensors are achieved with tamper-proof hardware crypto key management


These days, there is hardly any mention in the media about IoT without security concerns being mentioned in the same sentence. The harsh critique of the status quo is well justified. Security is a must in great majority of IoT applications. However, security is a very loaded word, so let’s plainly clarify how it applies to industrial IoT sensor devices, without getting into the complexities of this involved topic.

What we mean here by security is the practice of defending information from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction.

Security objectives and practices are defined by an end application. Security is a whole system concern, and, thus, it is only as good as its weakest link. Since sensor devices are part of a much larger IoT system, there is no meaning in saying whether the devices themselves are secure or not. For instance, if a device can securely handle its sensor data without being compromised, but a cloud service receiving this data has security holes, the overall IoT application is still insecure and easy to exploit.

On the other hand, what is important is to require that the devices can support security policies as defined for the system. Depending on application requirements, the security policies can be of various levels from lax to very stringent. For example, security policies for a radiation monitoring system around a nuclear reactor are very different than security policies for a public service weather station. The level of stringent-ness is always driven by an application’s criticality due to the trade off of exponential increase in cost and system complexity for better protection.

Security policies for IoT sensor devices typically deal with the requirements of authenticity, authorization, integrity, confidentiality, and adaptability/resistance of the underlying hardware system. In plain language, devices may be required to uniquely and securely identify themselves to the connecting cloud service (and vice versa), to provide restricted data access only to the users/services that have explicit authorization to do so, to protect the restricted data from being eavesdropped or hacked, and to enable on-going security bug fixes as they are discovered.

For IoT sensor devices to support such security requirements, the relevant security firmware has to be implemented in the device and the embedded hardware has to be able to run complex cryptographic algorithms in real time. This, in itself, has been a technological challenge as the embedded hardware has been often too resource constrained to run anything by the simplest crypto algorithms, if any at all.

Additionally, the security firmware is typically based on well-tested, open source cryptographic protocols. These protocols follow the best practice of separating the cryptographic operations, which are well publicized, from randomized secret keys which are the basis for all these cryptographic operations. As long as a hacker has no physical access to a sensor device, the system provides excellent security for communication link even if these crypto keys are not fully protected in hardware. However, once a hacker can gain physical access to the device (which should be assumed true for unsecured perimeter deployments) and can manage to extract the secret keys (for example via a debug access port or by monitoring electrical current signature on power supply), all the security goes out through the window and the system is compromised. What makes the matter worse is that majority of IoT communication radio standards use Pre-Shared Key cryptography (PSK). PSK combined with lax security implementation of using the same secret key for many devices (perhaps due to ignorance or laziness of personnel) results in large scale security breach. Once one device is compromised, all other devices with the same pre-shared secret key are compromised too. As the result, a deceptively secure system could be used to steal or manipulate restricted data or to stage further attacks on other parts of the system – a disaster scenario known too well from recent media headlines.

To help resist such security breaches, an effective practice is to protect secret keys and unique device identifiers within specialized hardware crypto coprocessors. They are designed to resist even sophisticated physical attacks such as reading electromagnetic signatures radiated by device or visually inspecting non-volatile memory state of the decapped IC chips. Once programmed during the sensor device commissioning, the secret keys are never again revealed externally, instead they are used by cryptographic algorithms internally within hardware, revealing only a securely encrypted output.

The concept is analogous to a hardware-based Trusted Platform Module (TPM) in many enterprise-grade PC’s which creates a “root of trust” for the security software to rely on to implement stringent security policies. Similar crypto technology that is used in multi-thousand dollar equipment is now feasible to be used in ultra low cost IoT sensor devices. However, few sensor devices implement any hardware-based protection for the secret crypto keys today.