The European Cyber Resilience Act (CRA)
The European Cyber Resilience Act (CRA) imposes strict cyber security standards on SMEs and improves their ability to protect digital products throughout their lifecycle. By preparing for compliance and ensuring transparent communication and regular updates, SMEs can gain the trust of their customers and gain a competitive advantage in the changing digital landscape.
Security in Embedded Systems
This article on security in embedded systems provides an overview and insights into the challenges of software development. This knowledge will help you to ensure the security and integrity of your products in a rapidly evolving threat landscape, right from the planning stage of your products.
RTOS in Context of Cyber Security
This article describes how we ensure compliance with the IEC62443 standard for our Flexible Safety RTOS. For the cyber security requirements resulting from the European Cyber Resilience Act, we chose the industrial security standard IEC62443. All suppliers of software components and electronic equipment must verify their products according to the European Cyber Resilience Act and adapt the documentation to succeed in future approvals.
Security Threat Awareness
This article provide a small exemplary list of threats to help your discussions of why security is significant for upcoming developments in Embedded Systems.
Today, companies rarely train their embedded software developers in IT security. Unsurprisingly, these developers have difficulty imagining the efforts the attackers now routinely take to detect and exploit weaknesses in a system. This missing knowledge leads them to underestimate the impact that even seemingly trivial bugs can have.
The discussed attacks below are not a complete checklist of attacks to protect from. Instead, the intention is to raise security awareness with these examples and provide a helpful list as an argumentative aid. When talking with coworkers, managers, or customers who can not imagine how an attacker could exploit your product, these examples might help.
Message Forgery
An attacker with access to the communication channel (like Ethernet, CAN, SPI, UART,…) forges a valid message.
For example: in an electronic door lock system with a fingerprint reader, the attacker sends an “open the door” message to the door lock instead of the fingerprint reader.
You prevent this attack by authenticating all messages. For example, the door lock checks an electronic signature or message authentication code to ensure that the received message comes from the fingerprint reader.
Replay Attack
The attacker records a valid message during an authorized fingerprint and injects that message at a later point in time to open the door while none is looking.
You may try to prevent this attack with a simple message counter that constantly increases. The idea is that the door lock detects the forged message if you receive a message counter with the same or lower value than a previous one.
If the attacker can prevent the original message from reaching the receiver, the counter method no longer works. Instead, each transmission could include a timestamp, and all systems need to have synchronized clocks.
Denial of Service Through Division by Zero
Imagine a protocol definition with an integer field where the possible values exclude zero. The attacker sends a zero in such a protocol message.
If you do not check the received value and use it in a division, the CPU triggers an exception. Then, the system enters a safe state and stops responding.
Information Loss Through Buffer Over‑Read
In 2014 the Heartbleed bug (CVE‑2014‑0160) was found. To exploit it, an attacker sets a length field to a higher number than the protocol allows in this situation.
A missing check in faulty OpenSSL implementations leads to reading and sending the attacker more bytes from a buffer on the heap than the buffer was large. This additional data often leaked secret keys in other objects on the heap to the attacker.
Remote Code Execution Through Buffer Overflow
The CPU stores the return address of a function call on the stack and works with a descending stack (like ARM or x86).
Imagine a function is called and allocates a fixed‑sized communication buffer on the stack. The address of the communication buffer is always lower than that of the stored return address.
A faulty protocol implementation copies an incoming message to that buffer without validating the length of the message. As a result, if the message length is larger than the allocated buffer, the return address gets overwritten with data from the message content.
The overwritten return address is loaded from the stack and executed when the function returns. Then, through guesswork or analyzing the firmware, the attacker causes the CPU to execute the instructions he sent.
Timing Attack Against RSA Implementation
Without details of the RSA encryption scheme, there is an easy‑to‑understand attack against poor implementations of the private key operation (generating a signature or decrypting a message). At its core, there is an algorithm step where we raise the message data to the power of the private key:
m ^ k
(there are a lot of modulo operations that do not matter here)
The following algorithm efficiently implements this exponentiation:
x = 1
for every bit in k:
x = x * x
if bit:
x = x * m
The time that this operation takes to complete is directly proportional to the number of bits equal to 1 in the private key. An attacker can use this information when searching for the key.
Deliberate Power Off
An insecure update mechanism receives an update file, stores it in flash memory, and validates the signature. If the signature is invalid, the update mechanism erases the flash memory again.
An attacker could cut off the power supply while the verification checks the signature, before the update mechanism erases the flash memory. Then, on the next boot, the insecure software is exe‑ cuted.
Abuse Non‑Standard Encoding
In unicode, the forward‑slash (/) has the code point U+002F. In UTF‑8 it should be represented as the single byte 0x2F. A naive UTF‑8 decoder might also decode the two‑byte sequence 0xC0 0xAF as the same forward slash. This is called overlong encoding and decoders should not accept such a byte sequence according to RFC 3629 (released in 2003, there were no such requirements in RFC 2269).
Imagine a system that serves some files from a file system. Only files from one directory may be served. The file system expects filenames to be encoded using UTF‑8. In an attempt to reduce computation time and software complexity, it does not check for overlong encoding.
To enforce that all requested files come from a specific directory, the communication endpoint rejects all requests where the file name contains a forward‑slash. It does so by scanning for the byte 0x2F. Any request which does not contain this byte is accepted.
Because the communication endpoint and the file system do not precisely agree on the API contract, an attacker can use the byte sequence ‘0xC0 0xAF’ to sneak a slash past the protocol validation into the file system and access any file on the filesystem.
A similar bug (CVE‑2008‑2938) was found in Apache Tomcat.
The European Cyber Resilience Act (CRA)
The European Cyber Resilience Act (CRA) imposes strict cyber security standards on SMEs and improves their ability to protect digital products throughout their lifecycle. By preparing for compliance and ensuring transparent communication and regular updates, SMEs can gain the trust of their customers and gain a competitive advantage in the changing digital landscape.
Security in Embedded Systems
This article on security in embedded systems provides an overview and insights into the challenges of software development. This knowledge will help you to ensure the security and integrity of your products in a rapidly evolving threat landscape, right from the planning stage of your products.
RTOS in Context of Cyber Security
This article describes how we ensure compliance with the IEC62443 standard for our Flexible Safety RTOS. For the cyber security requirements resulting from the European Cyber Resilience Act, we chose the industrial security standard IEC62443. All suppliers of software components and electronic equipment must verify their products according to the European Cyber Resilience Act and adapt the documentation to succeed in future approvals.