This is the first post in a new series – Embedded Security!
Over the past few years, the deployment of cryptography in embedded systems has accelerated. Companies like Arm, Qualcomm, Intel, Google, Apple and many more have started coming out with their own custom chips to provide a hardware root of trust or a secure world implementation or a cryptographic safe-house and much more! Popular suppliers like Microchip, NXP, Infineon, Maxim, etc. have secure elements and TPMs in their catalog that help secure embedded systems. Some products have been around longer than others – but sales, application notes, use cases and discussions for almost all of these are on the upswing.
Needless to say – the need for security in embedded systems is REAL! Let us take a look at some popular IoT attacks.
Popular IoT Attacks
Although the number of attacks on unprotected IoT systems increases by a substantial every year, some of these attacks and the vulnerabilities that enabled them have become a part of folklore for the volume and/or the nature of their impact on the large corporate and governments of the world. Here are some of them – not in any specific order.
The Mirai Botnet
The Mirai Botnet is perhaps the most famous examples of IoT attacks wreaking havoc. Mirai is japanese for “the future”. Botnet is a group of computers or embedded systems that are infected with malicious software and controlled as a group without the owner’s knowledge. At its heart, the Mirai malware was a block scanner which would scan the internet for open Telnet ports (port 23) and try to log in using 61 known username-password combinations. Once logged in, one could transfer the malware.
The author of the Mirai source code was a young undergrad at Rutgers and wrote the Mirai presumably for the thrill of bringing down his school’s systems using DDOS attacks.
This undergraduate student’s code brought down Dyn (a large DNS service infrastructure company) that provides service to Amazon, Netflix, Comcast, Reddit, Visa, Spotify and MANY such companies. Let this sink in.
The Stuxnet
Although not a strictly embedded malware, Stuxnet was a game-changer as far as cyber attacks are concerned. It was (supposedly) a joint venture between USA and Israel with the primary goal of disrupting the Iran nuclear program and delaying it so as to bring Iran to the negotiating table.
The modus operandi was pretty elegant. They would infect the computers and pen-drives of some scientists of the Iran nuclear program. Once these computers and pen-drives would connect to the nuclear stations’ computer network, the malware would spread itself so as to target only the Siemens PLC and SCADA systems. The interesting part was that the malware was designed to have a unique impact on each uranium enrichment reactor so as to not raise eyebrows. The primary reason for the computer and pen-drive approach was that the Iranian nuclear computer network was air-gapped i.e. it did not have any connectivity to the external internet.
The wikipedia page on Stuxnet is pretty detailed…do give it a read if interested.
Heartbleed Attack
Looks dramatic, right? It is. Heartbleed is a bug in the implementation of the Heartbeat protocol in OpenSSL. Remember – it is only an implementation bug, not a bug in the standard itself.
In a nutshell, during a heartbeat handshake, the server would not do a sanity check on the length of data it sends. If the request asks for more number of bytes than it should, IT WOULD JUST SEND THEM OVER! This leads to leakage of data that might contain private keys, usernames, passwords, etc.
Heartbleed is now a known CVE and the simplest way to fix this is to upgrade the version of OpenSSL being used on the server side. OpenSSL versions 1.0.1 to 1.0.1f are vulnerable (both inclusive). Not using these versions should ensure you are not affected.
But if you have a node already deployed with the affected version without the possibility of an update – oops!
The Target Hack
Another popular hack that had created an uproar and caused sizeable damage to the reputation and (more importantly) the market value of a company was the Target hack. Target Corporation is a big retail chain based in the USA. Back in 2013, millions of credit card details were stolen from the Target database. The entry point for the hackers was the HVAC system! Credentials for the Target network were stolen from a little HVAC vendor named Fazio Mechanical.
What is astounding is that an external company had blanket access to Target’s network and what is even more astounding is that the credit card details were stored unprotected and unencrypted in the database. The share prices plummeted, the revenues and profits for the coming quarters plunged, hefty amounts were paid as penalties to customers and courts and the reputation took a big hit!
That would be the costliest HVAC job in the history, no?
The Jeep Hack
The Jeep is one of the most iconic cars. The Jeep Cherokee boasts of an advanced internet-connected infotainment system that uses a platform called uconnect. Ethical hackers were able to find out and successfully exploit vulnerabilities (read unintentionally exposed services) that could allow hackers to control vital functions on the car like kill the engine, turn the volume up full blast, turn up the fans, etc.
Don’t trust me – check out this cool (and scary) video by WIRED.
What Do I Need To Implement Security?
Although there is no exhaustive list for the things you need to put in your system (and there never will be!), there are a few things you can do to ensure your embedded system is able to withstand common methods of attacking embedded systems.
Some good practices are discussed below.
Hardware Root Of Trust
A root of trust can be loosely defined as the entity or artifact from where trust in the system propagates downward. A good analogy in the real world is our banking system.
We trust our government as an entity. Our government trusts the federal reserve of our country. The federal reserve in turn trusts a number of banks who are registered with them and have a license to operate. With such a trust structure in place, when you and I want to go open a bank account, we simply go to one of these banks with relative trust that our money would be safe there.
In such a system, the root of trust is the government of our country. And the banks in which we have our accounts can be our embedded systems with the intermediate entities being a manufacturer, a production line or both.
Also, the entire chain from the government to the bank of your choice is referred to as the chain of trust.
The below illustrates the concepts of root and chain of trust and how they can be understood in the embedded systems world.
In the embedded systems world, the most common implementation of trust is done using X509v3 certificates. This is an industry-standard and the backbone of the entire internet ecosystem. It is becoming more and more commonplace to use X509v3 certificates in your embedded system for the purposes of establishing trust and secure communication links in offline as well as online systems.
Immutable Boot Code
Most popular microcontrollers today have a pretty simple boot flow. After a POR (power-on-reset), the CPU looks for boot code at a particular address in the non-volatile memory address space. For example: in Cortex M architectures, the PC (Program Counter) jumps to the (base address + 4) location. Hence if an attacker is able to modify the code located in the address space, it allows them to completely take over the system and misuse the system.
Immutability implies that the boot code cannot be changed. It is also recommended that the code should also not be readable by a debug probe.
Having an immutable boot code alone is not sufficient. This boot code should be able to authenticate the application binary before passing control to it. This way, it is possible to make malware injection very difficult in the system.
The below graphic explains the suggested approach.
Some simple methods to authenticate the application binary are comparing with a golden hash value, verifying the signature of the application binary, reading a golden location in the firmware binary, etc. A future blog post will shed more light on ways to achieve this.
Diversification (For The Win!)
One of the key things that decide the impact of the attack is its scalability. For instance – executing a script remotely so as to compromise N number of nodes in one go is a scalable attack and is very dangerous. However if the attack is not scalable and requires customization in order to compromise each unique end node, it renders this particular mode of attack infeasible and is considered less harmful.
In the modern world of embedded system, it is assumed that vulnerabilities will exist in some form or the other due to reduced development and testing cycle periods. Also, the growing adoption of open source and community driven software also leads to bugs and vulnerabilities creeping in.
One of the most elegant measures to ensure that the attacks are not scalable and the attack vector is restricted to only one or a few nodes in one go is diversification. In a nutshell, diversification is a key operation in your development ecosystem that allows targeted delivery of software and credentials to the end node. In simpler words, every end node has an irrefutably unique identifier and this identifier is used to communicate with it uniquely. Below is an example of targeted firmware delivered to an end node that has a unique 8-byte serial number. The immutable boot code in the system has the ability to authenticate this targeted firmware using the mechanism chosen (hash calculation in this case).
The above is just one simple technique. More techniques will be discussed in a future post.
Isolated and Strong Cryptography
This is one of the most under-appreciated and often overlooked mantras for an embedded system. If there is any sort of cryptography or key-ing material required for cryptography in the system, it is a good idea to keep it isolated from the main application. The simple rationale is that today – any firmware stored in any kind of non volatile memory like internal/external flash or EEPROM is readable using basic, intermediate or advanced tools. Hence, storing your keys in such memories is a strict no-no!
Instead if the keys are stored in a lock-box or a secret vault like a secure element or a TPM (Trusted Platform Module), the system becomes that much reliable since these chips are tested and certified for the purpose of storing secrets without leaking or exposing them through the use of tools known today.
More importantly, they also integrate strong cryptography algorithms since it is not prudent to just store stuff here AND transmit it over the lines when it comes to using these secrets.
Solutions based on secure elements and TPMs ensure that the cryptography in the system is sand-boxed and the application interacts only with the results of cryptography rather than cryptography itself. More on this in a future post.
Summary
This was a basic introduction to the vast field of embedded security. Future posts will dive deeper into some of the topics discussed here and many more!
Please let me know what you think about the post…see you next time!
One thought on “Embedded Security #1 – The Basics”