The time to secure the Internet of Things starts now! Or can we let the zombie invasion begin?

Internet of Things

The IoT, these little ‘things’ with communication capabilities will expand massively and shape the Internet over the next decade. Analysts [McKinsey] predict that 30 billions devices will come in widespread use in 2020.


We’re not even close to these numbers, yet there is reason for concern. As researchers and security experts have noticed, most devices are poorly designed with regard to security standards. It has become especially easy to tamper with the devices and remotely take control. Internet hackers have already seized the potential to synchronise several devices (or ‘bots’) remotely and trigger massive and targeted cyber attacks. The most recent exemple being the Mirai botnet with over 100,000 slave devices. This a tiny part of the Internet and we can expect similar events to spread widely.


When zombies (or fridges) come to us with numbers, it will be too late – the sooner we can stop them the better it will allow to preserve human access to the Internet! Like anyone who has witnessed a Robert Rodriguez movie, we know that zombies will be hard to contain. The only true hope is to find a cure and inoculate a vaccine to every IoT vendor. This is the real opportunity to prevent Pandora boxes from spreading within the next 4 years.


With increased awareness raised, last month, over the ‘things’ that connect to the Internet, the European commission is now looking at industry alternatives to find the right vaccine. It is worth noting though, that the Internet is global and that threats don’t stop at the European border. Any device connected anywhere can be remotely controlled and target anything within reach: public Internet services – or private and internal IT infrastructure. Yes, internal IT is exposed to intrusion risks and data theft too.


Every device is insecure. We are still living in the 1980’s computing paradigm: ‘build (your code) once, run everywhere’. While convenient in the beginning in order to spread technology in every home, we are no longer living in the same world. We have to change this paradigm in order to avoid unintended technology from spreading. The current model is a ‘1 to many’: any application, built once for a selected architecture (ARM, MIPS, Intel, …) can run on every processor that understands the ‘byte-code’. A hacker will easily install his/her ‘toolset’ to un-secure devices, tampering with the original code and intended use.


The security industry’s is working on it. In 2003, Metasploit developer Matt Miller, who was using the hacker moniker Skape at the time, proposed an ELF signature tool. ELF is a format for storing programs on disk. Matt realized that applications were missing ‘trust’ – i.e. how can we know whether applications have been issued by a ‘trusted’ vendor or by an any other unknown party? The general principle is to use asymmetric RSA cryptography to digitally ‘sign’ applications (ELF binaries). With this technique, the vendor holds the private key and is the only party with the ability to produce signatures that say ‘this application is truly mine’. What is missing in this scheme? Well, operating system and drivers (the interface that controls the hardware) need authentication too. Significant work and literature have been produced in this area, leading to the release of UEFI secure boot and asymmetric private/public keys with direct built-in support to the OS. Vivek Goyal, security researcher at Red Hat Inc, proposed to extend the OS signature support to every ELF applications (as Matt Miller proposed in 2003). ELF signature would be verified by a trusted component: the OS kernel. As I’m writing these lines, Goyal’s work still hasn’t been included in the mainstream Linux kernel.


Miller and Goyal’s vision can become reality. Adding RSA digital signatures to applications is an excellent match in the embedded world. An embedded device is not a personal computer – the ‘build once run everywhere’ paradigm does not apply in this case. A vendor who is releasing code for its embedded devices has control over all drivers and applications which it built. A trivial way to ensure the device has not been tampered with, is therefore to digitally sign every binary it contains. This is exactly what we propose and release to the public in the Linux kernel patch below. This work is based on CentOS7 environment and Linux kernel version 3.10, with asymmetric keys support.


How does it work and how to use it ?

  1. As soon as kernel 3.7 Linux introduced asymmetric RSA keys support and the ability to digitally sign ‘modules’ (drivers). You will need either Linux kernel version >=3.7 – or otherwise merge crypto support into your own kernel version
  2. Generate a public and private key pair, and a digital certificate
  3. Embed this certificate in your Linux kernel version. During boot, the kernel loads X.509 keys into the system key from a set of persistent key stores.
  4. Apply this patch [download] to your Linux kernel version. This patch is adding RSA signature support in the ELF binary loader
  5. Re-build your Linux kernel image with the above security additions
  6. Use the sign-module command (embedded in Linux kernel tree sources) to sign all your drivers, and all (really _all_) ELF executables, contained inside your firmware


With the above work in place, the Linux kernel will control the signature of every application loaded in its memory. Any unsigned application will fail to load. Any application signed by an unknown (untrusted) party will also fail to load. This will will not prevent system intrusions, however it will prevent system tampering: the system will only execute trusted code and therefore will be less exposed to unintended use.


As the open-source community noted while reviewing Goyal and Miller’s proposal the main limitation is: interpreters. Python, Bash, Perl and other script languages will not verify whether a given hand-written script is trusted or not. Either interpreters have to be avoided completely (the best), or they will need to support a trust mechanism similar to the above. A nice alternative is LUA that compiles into ELF, and therefore can be digitally signed and authenticated at run time, using the above Linux kernel patches. Please be aware that hackers already produce malware using LUA to target ARM systems. That’s another good reason to digitally sign your binaries if you intend to use LUA into your production firmwares! Let us hear about how you are using the Yocto Project in your embedded project, we are keen to help you out with advanced security integration.

The IoT security can be improved and we are optimistic about it. Yet, there is no such thing as zero risks and we know the consequences that new technologies and exponential data growth can have over IT security and data security. You can get in touch with us to learn more about our security solutions. We love a good query !

– Auteur: Sébastien Léger – CEO.

The CentOS Marks are trademarks of Red Hat, Inc. (“Red Hat”).

Intel® is a registered trademark of Intel Corporation. 

Linux® is a Registered Trademark of Linus Torvalds