India - Flag India

Please confirm your currency selection:

Indian Rupee
Incoterms:FCA (Shipping Point)
Duty, customs fees and taxes are collected at time of delivery.
Payment accepted in Credit cards only

US Dollars
Incoterms:FCA (Shipping Point)
Duty, customs fees and taxes are collected at time of delivery.
All payment options available

Bench Talk for Design Engineers

Bench Talk


Bench Talk for Design Engineers | The Official Blog of Mouser Electronics

Securing IoT and IIoT Environments, Part 2 Michael Camp

Security consultants have long advocated “layers of security” for both physical and data systems. The strategy still applies when you are protecting the remote IoT and IIoT devices that are outside of your immediate control. In Part 1 of this series, we looked at protecting the MCU and boot process. In Part 2, we’ll look at protecting data and physical devices.

Protecting Data

A determined attacker with much to gain from a hack will gladly disassemble even the most rugged device to find its vulnerabilities. Shipping production hardware with debug interfaces is a great way to make the hacker’s lives easier. It is well within the resources of hackers to purchase JTAG or SWD probes to read and write RAM, or re-flash on-chip memory. Peripheral TPM chips generally use an I2C or SPI interface directly to the MCU to prevent easy bus snooping, but are still vulnerable. The TPM hardware is delivered with a pre-programmed key that is never exposed to the rest of the system, and additional keys are typically derived from the factory-installed key, and never leave the module itself.

Eliminating debug interfaces provides an additional deterrent to malicious tampering.

Protecting Physical Devices

It may be impractical to keep an eye on your sensing devices 24/7, particularly if you have deployed thousands of them. For this reason, it makes sense for your devices to keep an eye on themselves, and let you know if something undesirable happens.

Desktop computers have included intrusion detection switches for years that are capable of reporting when the enclosure is opened, but software to actually take action on such an event is relatively rare. Cover open alarms are more common in a server environment where out of band management software is much more widely used.

The principle is easily extended to IoT devices, where reporting the open/closed state of a switch is fairly trivial. Adding software to send an immediate alarm when the enclosure is opened provides a minimal degree of assurance that the device has not been tampered with. At the very least, the operations team that monitors the alarm can disregard data received from the sensor that was interfered with.

Up next in Part 3, we’ll look at protecting the network.

« Back

Michael Camp's Blog

All Authors

Show More Show More
View Blogs by Date