April 8, 2019
One of the most surprising things in the discussion about IoT security is how it tends to form around encryption, authentication and over-the-air updates. True, crypto is an extremely important part of security in general, but there’s another hard truth that can not be avoided: having crypto implemented in a device does not necessarily mean that the device is secure. To debunk the myth that crypto is the be-all and end-all of IoT security, we are pleased to present a two-part blog series on the matter.
In part one of this blog post, we will examine security in connected devices from a different angle. We will explain the difference between crypto and security and demonstrate why having crypto is not nearly enough to secure a connected device.
In part two, we’ll dive into more advanced issues by looking into real-world vulnerabilities where security of a device was or could have been compromised without any relation to its encryption. We will jump into a more technical explanation of such vulnerabilities and shed some light on the OTA update process.
By the end of this blog post series, you’ll see that regardless of some best practices, such as PKI and OTA updates, IoT devices might remain unprotected and exposed.
But first, let’s define crypto.
Crypto – What it is and What it is Not
From a security standpoint, crypto has three major values that cannot be disputed:
- Data encryption allows transferring data from point A to point B in such a way that any system between those 2 points, cannot access the raw, unencrypted data. Simply: it mitigates Man-In-The-Middle attacks.
- Authentication, typically using asymmetric encryption, allows system A to verify that data received from system B was indeed sent from system B. The most common use of authentication in the realm of IoT is seen in firmware update mechanisms. The new firmware is typically “signed” by the company (with a private key – which is secret), and authenticated and verified by the device that receives the new firmware (using a public key). This method prevents an attacker from crafting a custom-made firmware and fooling the device into installing it.
- Obfuscation is another common use of crypto in embedded devices. Many manufacturers encrypt their firmware – the device needs to decrypt the firmware before it can verify and install it. We can only speculate that this technique is used to separate between attackers with motivation from those without. As attackers, if we managed to get our hands on a physical device, there are many techniques we could employ to extract the decrypted firmware. For example – we could read the flash memory or reverse engineer the obfuscation mechanism to de-obfuscate the firmware. Due to complexity, such an operation would be avoided by an attacker who is looking for a quick-win.
Sounds like all of the security you can ever need, right? Well, wrong. Especially in IoT devices, crypto is often misused or bypassed.
Imagine the following example: a device’s communication with the outside world, let’s say - with a mobile app on a smartphone, is encrypted. Assuming that the encryption cannot be penetrated, once a message has been decrypted successfully the device blindly trusts the data inside the message. Why waste the time and check boundaries when dealing with the data, if it had to be encrypted? But this data, of course, might be of malicious origin, for the following simple reason:
Crypto is bypassed, not penetrated
“Cryptography is usually bypassed. I am not aware of any major world-class security system employing cryptography in which the hackers penetrated the system by actually going through the cryptanalysis […] usually there are much simpler ways of penetrating the security system.” — Adi Shamir
This statement, proclaimed by the renowned cryptographer Adi Shamir, preceded a somewhat gloomy suggestion which later became to be known as Shamir’s Law: “Every 18 months, computer security gets 50% worse.”
Although most likely modeled on the famous Moore’s Law, this law doesn’t seem to share Moore’s enthusiasm for people-made technology. The fact that it was said back in 2007 by not only a great cryptographer, but one of the inventors of the famous RSA cryptosystem, makes you wonder where we are today in terms of security.
Looking back at our previous example through this lens produces a slightly grimmer picture: the device trusts the smartphone by relying solely on the phone’s crypto capabilities. This relationship of unjustified trust is problematic and results in a vulnerability.
Since the smartphone must be able to encrypt messages for the device, an attacker can simply reverse engineer the encryption mechanism on the phone and determine how to craft custom messages. At this stage, they can send messages to the device which will pass the decryption stage and be deemed trustworthy. Since the device doesn’t check the boundaries of the decrypted data, as stated above, the attacker can overwrite some of the system memory of the device by overflowing it with controlled data. Typically, that will mean that the attacker can take total control over the device, but sometimes even invoking a small, precise action will be enough to carry out an efficient attack (E.g. slam the brakes of the car or inject a lethal dosage of insulin).
On one hand, encrypting the data made it difficult for an attacker to hijack an existing communication channel between a device and a smartphone, which is exactly what crypto should be used for. At the same time, it was also used as some sort of “authenticator for the intended use,” which left the developers with a false sense of security and resulted in a vulnerability and an exploitable device. The encryption was, indeed, bypassed.
But does this kind of attack really happen? And why isn’t encryption enough for OTA updates? In part two of this series, we will look into some real-world examples, understand the type of vulnerabilities that can be exploited to bypass encryption and share some recommendation for implementing security in IoT devices.
Better Performance with Autonomous Observability
Gain complete visibility by monitoring and analyzing events in your device or across an entire fleet, from the first line of code and until post-deployment maintenance.
Diagnose software bugs and vulnerabilities by using instrumentation, to pinpoint flaws, gain dynamic profiling and analysis of the software, including third-party code.Learn about Sternum observability >>