Secure Embedded Software

The most important information in brief

What does Secure Embedded Software mean?

Secure embedded software encompasses all measures in device software intended to prevent an embedded system from being unintentionally controlled, altered, read, or disrupted. The term refers not only to individual encryption functions but to the interplay of software architecture, interface behavior, update mechanisms, access control, data storage, and diagnostic access.

In an embedded project, secure embedded software begins with the question of which functions a device performs and what the consequences of manipulation would be. A control unit has different security requirements than an HMI system, a measuring device, or a gateway. For a gateway, communication paths, protocol transitions, and access rules are often the focus. For a measuring device, measured data, configuration values, and calibration information may be the focus. For a networked machine, operating states, remote access, service functions, and potential effects on connected components are additionally important.

PICKPLACE views secure embedded software as a technical part of the development process. This involves clarifying which attack surfaces exist, which interfaces need to be secured, and which security functions can be implemented in the software. These include, for example, authentication, authorization, integrity checking, signed firmware packages, secured communication channels, and controlled handling of confidential data.

A typical project can begin with an analysis of existing software. This involves examining interfaces, boot behavior, update procedures, memory areas, configuration files, service functions, and debug access. Subsequently, a decision is made on which measures are feasible on the existing platform and what changes are necessary for the software structure, build process, or device architecture. For new developments, the need for protection can be considered earlier, for example, by separating roles, clearly defining responsibilities for security-related components, and establishing defined state transitions.

Secure embedded software is also closely linked to hardware and operating context. Software can only protect what the platform supports and what remains controllable during later operation. If a device is physically accessible, different assumptions must be made than for an enclosed control unit. If maintenance is planned via USB or network, these pathways must be included in the security concept. If updates are to be carried out in the field, the software must be able to detect whether an update package matches the device variant and is installed unchanged.

Why must software be protected in a device?

Software in a device needs to be protected because it controls the device's functions, processes data, and often has access to externally accessible interfaces. As soon as a device can be accessed via network, USB, radio, diagnostics, or service access, an attack surface is created. Interfaces intended only for maintenance or manufacturing can also pose a risk later if they are not controlled.

An unprotected device can be affected in different ways. Configuration values can be changed, causing the device to make incorrect decisions or process data differently than intended. Firmware can be replaced or modified, making it impossible to trace which software is actually running. Access can be misused if passwords, keys, or tokens are inadequately managed. Communication data can be intercepted or manipulated if protocols do not use appropriate security mechanisms.

For a project, this means that the protection of the software must be derived from the concrete functions and interfaces. It is not enough to add individual functions afterward if the fundamental assumptions in the architecture are not suitable. If a device supports multiple roles, such as operator, service, manufacturing, and development, it must be determined which role is allowed to perform which actions. If a device stores data, it must be decided which data needs to be protected from alteration, reading, or reuse. When a device is updated, it must be clear how the origin and integrity of the update files are verified.

In such projects, PICKPLACE also clarifies organizational dependencies. Security features do not only affect the source code. They have an impact on build processes, key management, test procedures, manufacturing, service, and documentation. A signed update, for example, requires clear regulations on who generates update packages, how signatures are created, and how the software in the device verifies these signatures. A rights concept requires the description of roles, credentials, and service procedures. Access protection for diagnostic functions requires a holistic view of diagnostic tools, interface protocols, and authorizations.

Another reason for protective measures lies in the lifespan of embedded systems. Many devices remain in use for extended periods and are not constantly replaced. This necessitates consideration of update capability, error correction, and later modifications. If a device can be updated in the field, the update process must be secured against incorrect or manipulated packets. At the same time, the software must be able to handle interruptions, power loss, or incomplete transmissions without entering uncontrolled states.

Spoofing, Tampering, Denial-of-Service – what kinds of attacks are there?

In secure embedded software, various attack patterns are considered because they require different protective measures. Spoofing means an attacker impersonates a legitimate participant, service, device, or user. In an embedded system, this could be, for example, a fake communication partner on the network, an unauthorized service tool, or a device using a foreign identity. Authentication, verified device identities, access controls, and protocols that do not rely solely on easily copied identifiers help protect against such attacks.

Tampering describes the modification of software, data, messages, or configuration values. In embedded devices, this can be a manipulated firmware file, changed parameterization, altered measurement values, or a subsequently modified message. Countermeasures include integrity checks, signatures, checksums with appropriate protection contexts, protected memory areas, and clear rules about which data can be changed and when. The project must define where integrity is checked: during booting, during updates, when loading configuration data, when receiving messages, or during security-relevant state changes.

Denial-of-Service attacks aim to make a device or service unavailable. In embedded systems, this can be caused by too many requests, malformed data packets, blocking communication states, or repeated connection setups. Even small microcontrollers or embedded Linux systems can be affected if resources like CPU time, memory, network buffers, or file system accesses are not limited. Protective measures can include input validation, request limiting, defined timeouts, state machines with error paths, and controlled handling of erroneous messages.

In addition to these three well-known patterns, there are other attack vectors that are frequently tested in embedded projects. These include unprotected debug interfaces, open service access points, hard-coded credentials, insecure default configurations, insufficiently tested update packages, and memory handling errors. Diagnostic functions also deserve attention because they can often interfere deeply with the device. If diagnostic commands change configuration values, read memory, or influence operating states, they must be incorporated into the rights and access concept.

PICKPLACE does not consider such attack patterns abstractly, but rather in relation to the specific device. A device without a radio module has different attack vectors than a gateway with multiple network segments. An HMI system with user management has different requirements than a measuring module without local operation. For implementation, it is therefore clarified which interfaces are actually present, which remain accessible in the field, which are only used in production or service, and which functions can have critical consequences in case of incorrect operation or misuse.

Typical starting situations in secure embedded software projects

Secure embedded software projects often arise in different phases of a product lifecycle. In new developments, the focus is on integrating protection functions into the architecture and implementation from the outset. For existing devices, the evaluation of the current software is often the main focus. This involves examining which access points exist, which security assumptions have been made so far, and which parts of the software need to be adapted.

Another starting point is the connection of a previously isolated device to a network or service platform. If a device was previously only operated locally and is later intended to receive remote access, data transmission, or central updates, the requirements change. Functions that were uncritical in isolated operation may need to be re-evaluated when externally accessible. This includes configuration interfaces, protocol services, log outputs, and diagnostic commands.

Redesigns or platform changes also lead to security concerns. When software is transferred from one microcontroller to another platform, or when an existing system is supplemented with a gateway, memory layout, boot process, update mechanisms, and communication paths must be re-evaluated. Security features cannot always be adopted unchanged in this process because hardware functions, bootloaders, operating systems, and toolchains have different characteristics.

Sample Software

• Security Stack Mbed TLS
• Security Stack wolfSSL
• Bootloader MCUboot
• RTOS SafeRTOS
• Software Update RAUC

Technical dependencies and interfaces

Secure embedded software depends on several technical layers. The lowest layer includes bootloaders, memory areas, hardware functions, and interface controllers. Above this are the operating system, drivers, communication stacks, application logic, and service functions. Each layer can support or limit security features.

For secure updates, for example, it must be clarified how firmware packages are transferred, stored, checked, and activated. The software must recognize whether a package is complete, whether it matches the device variant, and whether it is unaltered. For secure communication, protocols, key material, certificates, or other identity information must be managed. For access protection, roles and permissions must be checked not only in an interface, but also in the underlying services.

Interfaces are a central part of the consideration. Network, USB, wireless, serial diagnostics, internal buses, and service ports differ in range, usability, and risk. An interface that is openly used during development should be evaluated for later operation. This will determine whether it needs to be disabled, restricted, authenticated, or logged.

Our Services

PICKPLACE supports projects for Secure Embedded Software with secure hardening, software development, and security concepts. The scope of services depends on the existing system, project phase, and the device's accessible interfaces.

In secure hardening, we analyze existing software and device interfaces. This includes communication paths, service access, diagnostic functions, update processes, authorization checks, and configuration mechanisms. Concrete adjustments are derived from the results, such as stricter input validations, restricted access, deactivated development functions during operation, checks of firmware packages, or clearer error paths for invalid data.

In software development, we implement security-related functions for embedded systems or extend existing components. This can involve secure communication, signature verification, access control, role logic, update handling, integrity checks, or handling faulty messages. We take into account the resources of the target system and which functions need to be implemented at the bootloader, operating system, or application level.

In security concepts, we structure requirements, attack surfaces, and technical measures. We describe which interfaces are protected, which roles are planned, how updates are checked, which data must be protected, and what the system's limitations are. Such a concept serves as the basis for development, review, testing, and handover to implementation.

Additionally, we support with error analysis and debugging when security-relevant functions do not work as intended. This includes failed update checks, permission problems, unexpected disconnections, inexplicable diagnostic access, or incorrect states after invalid inputs. The analysis combines code, interface behavior, and device status to narrow down causes and implement targeted changes.