Embedded software security issues

Cyberattacks would lead to an interruption in the functioning of embedded systems, which may have some catastrophic consequences. Embedded devices have a much longer lifespan as compared to PCs. One can easily spot embedded devices in the field that are a decade old, still running on the same system. So, when a manufacturer plans to develop an embedded system, they need to consider the potential threats that may arise in the next two decades.

On top of developing a system that is secure against current threats, manufacturers need to match the security requirements of the future, which is a great challenge in itself. Embedded systems follow some set of industrial protocols that are not protected or recognized by enterprise security tools. Enterprise intrusion detection system and firewalls can save the organizations from enterprise specific threats, but are not capable of providing security against industrial protocol attacks.

Numerous embedded devices are deployed in the field, outside the enterprise security perimeter. Therefore, these remote or mobile devices may be directly connected to the internet, without the security layers provided in the corporate environment.

All the above-mentioned challenges need to be addressed during the embedded device design and development , considering both hardware and firmware aspects. Only if the embedded device is secure, it will be able to run the intended tasks. Model-Based Design for Embedded Software. DRM content arrives encrypted. Therefore, the DRM process concludes when the system obtains the content decryption key. Once the content decryption key is available, it is possible to decrypt the protected content.

The security aspects of the content decryption process involve Secure Storage of the content decryption key when not used, using some Key Management functions to retrieve the content decryption key and applying the appropriate cryptographic algorithm to the content.

At any point in time, all key material must be protected from potential attackers for example, by using a hardware-based decryption engine, where any key material never leaves the hardware environment. DRM Key material protection is required not only for the content decryption key, but also for any other DRM-related keys. An example of such key material is the device key, which is used by the licensing entity to uniquely identify the device.

Key material protection involves not only using a Secure Storage Secure Communication mechanism, but also a secure provisioning solution, which is able to securely inject the device key into the system. First, ROs must be stored securely in a Secure Storage database. Since a DRM-enabled system can hold numerous ROs, a full-blown database must be used, enabling unlimited number of data items to be stored securely with an efficient search mechanism.

Secure Storage is mandatory as opposed to regular storage , since ROs contain enforcement parameters, such as the remaining usage counter, or the expiration date. The SEE must handle two aspects of security — parsing the RO correctly and keeping track of secure time.

Secure RO parsing is necessary as some RO fields are not fail-safe in nature. Secure Time is necessary in order to be able to enforce any time-related usage. The use-case discussed here is of a single central security engine that provides security services to multiple CPUs. The first step to establish distrust between CPUs is to enable the central security engine to distinguish which CPU is addressing it at any point in time.

Identification must be robust and therefore should be based on hardware signals. As an example, many advanced bus architectures today provide the transaction source indication as an integrated part of the transaction, using side-band signals. Once the CPU accessing the central security engine is identified, there is a need to prevent that CPU from accessing security-related material belonging to another CPU. Assuming lack of dedicated RAM per each CPU, the best method to provide such access separation is by means of cryptography.

These keys are kept protected using a Secure Storage mechanism. All security related material belonging to a given CPU is encrypted using its dedicated random key and is therefore inaccessible to other CPUs. Additional mechanisms can be added on top of the basic separation mechanism just described.

For example, if two CPUs need to share information in a secure manner, then a random inter-CPU communication key can be defined, which is accessible only to the two CPUs. If more than one CPU needs to execute security related software, then it makes sense to use a central security software execution space. Generally speaking two types of algorithms are utilized: symmetric cryptography and public key cryptography.

Symmetric algorithms are used mainly for data encryption and data integrity, due to their high performance characteristic. Public key cryptography is used mainly for key exchange, attestation and authentication, due to its asymmetric nature and lower performance characteristics.

Systems can instantiate a cryptographic algorithm either as a hardware cryptographic engine or a software cryptographic engine. The advantages of a hardware-based engine are security and obviously faster performance. Security is more robust as key material is only present in hardware registers inaccessible to the software and never in relatively easy-to-access RAM.

The disadvantage of a hardware-based engine is the silicon footprint. The advantages of a software-based engine is flexibility, while the downside is that a software-based engine takes considerable MIPS from the processor on which it is running, which is likely to need the computation power for other tasks.

Cryptographic algorithms require keys as their basis for operation. Since the algorithms are published and known to all, including to potential attackers, protecting the secrecy of the key is an important issue for security. Secure Storage essentially deals with protecting access to keys and other pieces of data. Secure Storage also needs to be persistent, such that items are not lost during power cycles.

On-chip storage has the advantage in that it can be more easily hooked to the security solution, while having the disadvantage of larger silicon footprint and lack of flexibility.

Off-chip storage is very flexible, but requires employing more careful access control schemes. The first step in order to protect access to plain keys or any other data items on an external flash is to encrypt the keys prior to their storage. Such encryption is able to thwart basic attacks techniques of simply reading flash content or probing the bus signals passing between the flash chip and the CPU chip.

Adding integrity protection for each key also prevents the attacker from utilizing replacement attacks. Once the encrypted key is within the chip boundary, it is still prone to attacks.

The basic question is which root key is used to encrypt all other keys residing in the Secure Storage database. The best practice here is to use a hardware-based solution for this root key: on-chip OTP bits. Using OTP bits provides the chip manufacturer with the flexibility to program a different random root key for each and every chip, which in turn leads to a Secure Storage database which is encrypted with a different key for every chip.

The other option is to use a software-based root key, where the root key is stored somewhere in the software image on flash. Breaking a Secure Storage database with a root key that is hardware-based requires the attacker to decap the chip and attempt to read the OTP value. Such an attack is not scalable, since the attacker needs to repeat the same attack for every chip.

On the other hand, using a software-based root key provides a scalable attack pattern: once an attacker manages to analyze the software image and find the root key, the attacker is able to easily distribute the attack and reveal every root key in every chip. Assuming that the root key is indeed hardware based, it should still be used in a secure manner.

The best practice here is to use a dedicated hardware module which reads the root key directly from OTP bits and decrypts encrypted keys fetched from the Secure Storage on flash. Using such a dedicated hardware module means that the root key is contained in a defined hardware block and is never exposed in more attack-prone locations such as CPU RAMs.

The dedicated hardware module can range from a single dedicated engine up to a full Secure Execution Environment — depending on the type of assets available on the chip. The final aspect of access protection is to limit the CPU applications which are accessing Secure Storage keys. A robust Secure Storage solution is able to use cryptographic measures to uniquely identify each CPU application and ascertain whether this application is allowed to use the root key in order to decrypt Secure Storage data.

Additional features are required in order to provide a complete Secure Storage solution. Primarily, the Secure Storage database should be able to recover from unexpected power-loss as well as unexpected application errors — neither one should render the database useless.

There might be some security challenges for the developers to build these embedded systems as their sizes are small and are limited to compute resources. An embedded system is a computing system built into a larger system, designed for dedicated functions. It consists of a combination of hardware, software, and optionally mechanical parts. Security is an important issue because of the roles of embedded systems in many mission and safety-critical systems.

Attacks on cyber systems are proved to cause physical damages. Embedded security systems are generally found in pharma, industries, daily life needs like home appliances, medical centers, or military components.

Below is the list of challenges faced in maintaining an embedded security system in recent times. They are:. The embedded security system is done with the following steps.

These steps are followed to maintain the security challenges faced earlier. Because modern home appliances like electric cookers, refrigerators and washing machines have connectivity feature integrated by default, Internet of Things now is exposed to a serious risk of hacking attacks. Time-to-market and time-to-revenue have always been tough indicators in embedded software development , especially in the IoT segment. Fabrication of hardware components housing embedded software requires extreme integration and flexibility due to very fast development of IoT industry.

In addition, taking into account longer IoT device lifespan, future updates and releases become an issue for component designers. The challenges in design of embedded software have always been in the same limiting requirements for decades:. The market demands from designers to pack more processing power and longer battery life into smaller spaces, which is often a tradeoff.

Finally, depending on applications in IoT, there is a growing demand for manufacture of very scalable processor families ranging from cheap and ultra-low-power to maximum performance and highly configurable processors with forward-compatible instruction set.

With all their probable expertise in software development, many of them lack hands-on experience in implementing and updating their applications in IoT environment specifically, especially with regard to security. Further expansion of IoT devices on the background of their connectivity puts more pressure on their adaptability. Users must be capable of administering the app through a simple user interface via all available channels including over-the-air firmware updates , which needs extreme compatibility across the entire ecosystem.

Integrity becomes a function of security. To protect the IoT from malicious attacks or compromising, security must be implemented within each device at every level: the end node, gateway, cloud, etc. Whether we like it or not, the number of connected devices worldwide grows expotentially each year, according to Statista.

Embedded solution developers are facing many specific issues along this way. We do not intend covering all of them in detail; let us have a look at a few of them. There are so many different ways to connect device to the internet. Leaving apart their pros and cons, the fact is each of them is created with a different technology stack, which means that developers have to have expertise in all of them. Pre-engineered software stacks partially resolve this complexity, but the issue remains for developers to have enough knowledge to understand a problem if something breaks or requires modification.

The issue standing next to connection to the internet is remote updates of the firmware. In case of standalone device, it is enough to send update to a secure site and notify users to download and install it.

Now imagine an alternative: even a small IoT deployment involves a few thousand devices. Then, developers have to fulfill the following tasks: generate a firmware update, save it to the devices, validate that they are delivered from a trusted source, run the update on the devices at appropriate time, and be ready to roll back the update if there is an issue.

This job is fairly tough and time-consuming, requires a lot of skill from developers, who have to be experienced in deploying the updates in the IoT environment. Debugging is a general issue growing together with the number of connected devices — time and effort for debugging grows in parallel.

Along with the process of open source software integration, there occurs more unexpected behaviors in a system adopting innumerous free flow devices than in the one, which was specifically designed to interact with them from the start. For a few decades, technologies used for embedded software were almost the same with some new higher capacity processor to come out once a year. Then things eventually began speeding up. In the last 5 years, we witness fast development of emerging technologies including artificial intelligence.

It creates a problem for developers, because available technologies are changing faster than they can get hold of them.