While embedded devices have been a part of our daily lives for some time now, the importance of keeping them secure is still a fresh topic.
In recent years, more focus has been put on the security of such devices, and it’s become an issue that the tech community has shown great interest in.
This article talks in depth about the security of embedded devices – how to ensure it, how to manage vulnerabilities, and how to protect the data from possible vectors of attacks.
The evolution of embedded device security
In the early 2000s, people first began to use embedded devices on a larger scale – but those devices were not as secure as they should be.
In terms of security, the most we could get was usually a simple login and password. There was no cryptography, no secure channels for exchanging the data, and a general lack of care for the security of the data.
The first technology that made it possible to connect devices was ZigBee, which allowed for a simple pairing with 4-digit pins, so security was not really accounted for.
Embedded devices were presented as MVPs that could show the functionalities to potential users. Startups wanted to create their devices as fast as possible, but security was an afterthought since it takes time to account for all the possible vectors of the attack.
Big Tech’s influence on security
The issue of security started to become important around the late 2010s when hackers took an interest in the devices that were on the market. It was then discovered that a lot of connected devices were open to various types of attacks, and breaking into them wasn’t difficult.
At the time, people also started constructing tools to search for such devices. An example of such a tool would be Shodan – a search engine that’s able to search through IP addresses and collect information about devices that are currently connected to the internet and accessible.
Those factors made companies like Google, Apple and Amazon work on creating a complete environment for such devices with the same security level on each of them; that’s to be sure that each device is secure to the same degree, the environment is safe and the device can be used by a customer.
Google now has its own environment to which IoT devices can be connected – but a range of different tests, such as the security level of the device in question, need to be passed in order to use it.
Vulnerability management
When the most prominent IT companies started to think about the safety of our houses and other places where connected devices are used, security finally started to be taken seriously.
It’s still a fairly new topic but as of now, we do have some ways of managing embedded devices’ vulnerabilities.
First, let’s go through the most common vectors of attacks.
Types of attacks
Hackers approach these attacks in various ways, with the most common reason also being the simplest one – they will try to break the devices for fun, or just to prove that they can. The most common ones when it comes to embedded devices are:
Man-in-the-middle – when someone’s trying to get in between the communication of two systems (i.e. the device and the mobile phone).
Attack on the software – when we have a device connected to infrastructure (like the cloud, for example), and the security is low (because of a poor encryption method or a lack of it altogether), a hacker can break into either the device or the cloud. This often happens through an open communication port that a developer forgot to delete.
Physical attack – meaning the hacker is trying to physically open the device, learn how it works, and, for example, try to get the credentials or security keys from it to attack other pieces of the device owned by other people.
The effects of those attacks vary. Hackers may try to destroy the infrastructure via the device’s connection to a mobile phone, they may simply try to rob the owner of the device through a link between a credit card and the application or try to extract personal information in exchange for ransom.
Prevention & security standards
Every prevention tactic is different for each device as some are connected via a cable, and others use wireless communication.
The most crucial tip here is to start thinking about security as a whole from the very beginning. Aside from having a cybersecurity-oriented person consider the different vectors of attacks at the earliest stage, it’s vital to keep to existing security standards.
At Intent, we specialize in developing connected devices that use Bluetooth. In this case, the standards to use come from organizations like Bluetooth Special Interest Group (SIG), which lists the best security practices.
Additionally, treat silicon providers themselves as a source of information on security. If, for example, you’re using Nordic components, they provide libraries for Bluetooth connection.
It’s always a safer bet to use standardized solutions rather than custom ones. As an example, we have encryption: SSL, which is an open standard and was compared to many custom solutions of the past. Thanks to a shared community effort for removing any backdoors in the code, SSL became a solid, secure solution.
As of now, it would take a supercomputer to break through SSL, and a lot of time would still be needed to do that. My opinion as a hardware developer is that standards are the better option because they are public, and there is a huge community behind them.
Security level
Maintaining security throughout the device’s lifecycle is not an easy task. First off, there’s a balance to keep: the one between the level of security and the cost it takes to get to that level.
Reaching a security level of 100% is impossible to achieve, not to mention it wouldn’t be feasible. That said, you could reach a very high level of security – say, 90% – but then the cost of the device would simply be too high to sell it.
You need to agree on the level that you’d like to achieve early on. This will vary depending on the device you’re selling; a higher security level will be needed for a health-related device that can potentially save a person’s life and a lower one for a smartwatch collecting data about heart rate (that is not related to personally identifiable information).
Third-party components
When it comes to ensuring security, third-party components in your device need to be treated as a potential vulnerability.
The general rule here is that each component of your network can be potentially dangerous – that includes third-party libraries, as they can also have some backdoors. This is why you should always put special care into protecting sensitive data, and transmit it in a secure way using encryption.
Protecting sensitive data
Needless to say, sensitive data is a top priority in terms of keeping the device secure. First, it’s a good idea to have a safe place on your hardware to save such data. Whether the data is saved over the air, over the cable, etc. it should be encrypted – and the level of encryption should always be relevant to the data that is being sent.
The rule here is that you shouldn’t use simple encryption for highly sensitive data and vice versa; it makes no sense to establish very high strong security for information about, for example, calories burned that’s not linked in any way to the person the data relates to.
Secure boot & encryption
A device that is equipped with secure boot prevents hackers from reading the firmware. That is because it’s encrypted at the beginning, so the firmware cannot be read.
In short, secure boot is there to make sure that the device allows the code to run and checks if it is signed by the developer of the device - it then permits the device to run a given application. It ensures that the software is valid and nothing has been maliciously altered – even if one bit is changed in this application, the device simply will not allow it to run as it’s not authorized.
The second important thing is related to encryption itself. In the process of encryption, if the code is authorized, the device will first try to decrypt this code and run it. This way, even if a hacker downloads it, they will not be able to decrypt it as they would need the keys to do it.
Summary
Ensuring the security of an embedded device should never be an afterthought.
Think about the potential vectors of attacks from the very beginning of the development cycle, agree on the security level you’d like to maintain and, as a rule of thumb, keep to known security standards rather than coming up with your own, custom ones.
As additional advice, engage the help of consultancies specializing in cybersecurity to check or improve the security of your device. Your device will be hacked in a manageable environment – which, of course, is an additional cost, but it’s a very solid way of checking how secure your device actually is.
If you’re looking for guidance on the security of your device, don’t hesitate to contact Intent – we have years of experience in the development of connected devices!
Przemysław Łagód
Head of Hardware
