SYS.4.3 Embedded Systems

Description

Introduction

Embedded systems are information-processing systems integrated into a larger system or product. They perform control, regulation, and data processing tasks and are often not directly perceived by users. Embedded systems are found in high-technology areas such as aerospace, medical technology, telecommunications, and automotive engineering, as well as in consumer and household appliance sectors.

An embedded system forms a functional unit of hardware and software that fulfills only a defined task. The software of embedded systems is called firmware and is mostly stored in flash memory, EPROM, EEPROM, or ROM and is not exchangeable or only exchangeable by users with special means or functions. It consists essentially of the bootloader, the operating system, and the application. Specialized systems can also operate without an operating system. Embedded systems are specialized devices, but unlike pure hardware implementations (ASIC) they are general-purpose computers. As platforms, different CPU architectures or flexible, highly integrated Field Programmable Gate Array (FPGA) modules come into consideration.

Embedded systems either have no operator interface or use specialized peripherals such as functional buttons, rotary switches, and displays designed for the particular intended use. The spectrum of output units ranges from a simple signal lamp through LCDs to complex cockpit displays. Embedded systems frequently communicate via data buses that are heterogeneously networked in complex systems. Additionally, peripheral components such as sensors and actuators can be connected via multiple different and multi-channel I/O ports. Some types of embedded systems also have a web interface through which they can be configured via a browser.

Objective

The objective of this building block is to inform about typical threats to embedded systems and to demonstrate how these systems can be securely used in institutions.

Scope and Modeling

The building block SYS.4.3 Embedded Systems must be applied once to each embedded system in the information domain.

This building block deals generally with embedded systems. It is applicable to a broad spectrum of different embedded systems. Dedicated security properties, such as those of operator and display systems, or specific hardware and software architectures are not covered in detail. Similarly, security aspects of embedded systems used in industrial control are not specifically addressed. For these, the building blocks of the IND Industrial IT layer must additionally be consulted. Specific security aspects of IoT devices are also not the subject of this building block. As networked devices or objects with additional smart functions, IoT devices — unlike embedded systems — are not integrated into a larger system or product. Due to their wireless connection to data networks, different security requirements apply. They are addressed in SYS.4.4 General IoT Device.

A special application of an embedded system is smart cards. The cards generally have a processor, working memory, and I/O interfaces. For smart cards too, although fundamental security aspects are addressed in this building block, specific aspects are not examined.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block SYS.4.3 Embedded Systems:

Insufficient Security Requirements in the Development of Embedded Systems

For cost reasons, information security often plays a less important role in the development of embedded systems than, for example, performance or reliability. However, if security requirements are not sufficiently taken into account in one or more development phases, the embedded systems can exhibit serious vulnerabilities.

Unsecured Input and Output Interfaces in Embedded Systems

The interfaces of embedded systems are potential attack points. This applies to interfaces at all levels of the OSI layer model and all transmission media used. If access via interfaces is not controlled or the control mechanisms are too weak, an attack could penetrate the system, read and manipulate data without authorization, and initiate follow-on attacks. Espionage or sabotage devices could be connected unnoticed, e.g., miniaturized controllers or data loggers.

At the microcontroller level, when systems are connected to the I/O ports, signals could be fed into I/O registers via the I/O lines, or output signals could be recorded.

If a reset input is present, attackers could activate it and temporarily take the system out of operation.

Insufficient Physical Protection of Embedded Systems

If embedded systems are physically easily accessible, attackers could destroy or damage the systems, e.g., through mechanical force, short circuits, or overvoltages. They could also access the electronic components, e.g., IC pins or contacts, and thereby record electrical signals unnoticed using appropriate measurement and analysis tools, as well as feed in their own signals. If they gain possession of an embedded system, they can read and manipulate data using physical methods or access data that has not been securely deleted. This can lead to violations of the confidentiality, integrity, and availability of information stored on the embedded system.

Hardware Failure and Hardware Errors in Embedded Systems

Environmental influences such as electromagnetic interference, temperature fluctuations, unstable power supply, manufacturing-related material defects, and production variation can cause embedded systems to fail. Normal or premature wear caused by harsh environmental conditions such as dust, sand, or contamination can also result in system failure. This could also severely impair the surrounding systems.

Flashing Manipulated Software Updates onto Embedded Systems

Many embedded systems store their software on flash memories and EEPROMs and offer the ability to update their firmware using a programming device connected via a data interface or network connection. However, attackers can also use this to flash manipulated software updates and thereby modify the function of the system. As a result, the original tasks of the system can be interrupted or manipulated.

Side-Channel Attacks on Embedded Cryptosystems

Attackers could break encryptions or signatures via a side-channel attack by exploiting observable properties of the physical implementation of a cryptosystem. For example, they could draw conclusions about executed operations and keys from the power consumption of a microprocessor during cryptographic calculations. They could also perform timing attacks, microarchitectural attacks, or (semi-) invasive attacks. For example, researchers were in the past able to determine the secret key of a TLS/SSL server using the Digital Signature Algorithm (DSA) with elliptic curve cryptography. The attack was based on the fact that the time required for a multiplication allows conclusions about its operands.

Intrusion and Manipulation via the Communication Interface of Embedded Systems

Embedded systems are often constrained with respect to code size, timing, energy consumption, cost, and size and weight. They are therefore frequently not equipped with sufficient security functions such as strong cryptography. Modern embedded systems are increasingly networked using widely used technologies and protocols and are therefore potentially vulnerable.

In an attack, an attempt could be made to manipulate data or software on an embedded system by trying to misuse the communication interfaces and protocols standardly provided for one’s own purposes. For example, if the IP communication or Ethernet, WLAN, Bluetooth, and cellular or digital radio interfaces are not sufficiently secured, attackers can take over connections, forge messages, or penetrate a system and carry out follow-on attacks. Additionally, an attempt can be made to penetrate the system via other available communication interfaces, e.g., USB ports.

Use of Counterfeit Components

During the production process or when components are replaced in a service case, counterfeit components can be installed in embedded systems. Since counterfeits are in circulation for many components, this can also happen unintentionally. Counterfeit parts often work less reliably than the original parts. This could cause functions to fail or operate only with errors. Attackers can also deliberately develop a device or component that looks the same as the original but has manipulated functionality. Such a component could, for example, install backdoors, manipulate individual functions, or restrict availability.

Requirements

The following are the specific requirements of the building block SYS.4.3 Embedded Systems. The ISO is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many people should fill these roles.

Basic Requirements

The following requirements MUST be met with priority for this building block.

SYS.4.3.A1 Regulations for Handling Embedded Systems (B)

All users and administrators MUST be informed about behavioral rules and reporting channels in the event of failures, malfunctions, or suspected security incidents.

All embedded systems including interfaces MUST be recorded. Embedded systems MUST be securely preconfigured. The configuration applied SHOULD be documented. Furthermore, rules SHOULD be defined to test the integrity and functionality of the embedded systems.

SYS.4.3.A2 Deactivation of Unused Interfaces and Services in Embedded Systems (B)

It MUST be ensured that only required interfaces can be accessed. All other interfaces MUST be deactivated. In addition, ONLY required services MAY be activated. Access to application interfaces MUST be protected by secure authentication.

SYS.4.3.A3 Logging of Security-Relevant Events in Embedded Systems (B)

Security violations MUST be logged (see OPS.1.1.5 Logging). If electronic logging is not or only very limitedly feasible, alternative, organizational rules SHOULD be created and implemented.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.

SYS.4.3.A4 Creation of Procurement Criteria for Embedded Systems (S) [Procurement Office]

Before embedded systems are procured, a requirements list SHOULD be created against which the candidate systems or components are evaluated. The requirements list SHOULD include at a minimum the following security-relevant aspects:

• Aspects of material security,
• requirements for the security properties of hardware,
• requirements for the security properties of software,
• support for a Trusted Platform Module (TPM) by the operating system,
• security aspects of the development environment, and
• organizational security aspects.

SYS.4.3.A5 Protection Against Harmful Environmental Influences in Embedded Systems (S) [Developers, Planners]

It SHOULD be ensured that embedded systems are adequately protected against harmful environmental influences in accordance with their intended type and location of use. The requirements for this SHOULD already be analyzed during the planning phase. It SHOULD also be ensured that the precautions to protect individual components from dust, heat, moisture, and contamination do not cause problems with the requirements of the superior system.

SYS.4.3.A6 Prevention of Debugging Options in Embedded Systems (S) [Developers]

Any debugging options SHOULD be removed as completely as possible from embedded systems. If on-chip debugging is used, it MUST be ensured that debugging functions cannot be used or activated without authorization.

Furthermore, it SHOULD be ensured that no input interfaces for test signals and measurement points for connecting analyzers are activated and usable by unauthorized persons. Additionally, all hardware debugging interfaces SHOULD be deactivated.

SYS.4.3.A7 Hardware Implementation of Embedded System Functions (S) [Developers, Planners, Procurement Office]

If embedded systems are developed in-house, security aspects SHOULD be taken into account in the design decision regarding hardware and software implementation. Security aspects SHOULD also be taken into account when deciding which hardware technology to implement.

SYS.4.3.A8 Use of a Secure Operating System for Embedded Systems (S) [Developers, Planners, Procurement Office]

The operating system used and the configuration of the embedded system SHOULD be suitable for the intended operation. The operating system SHOULD have sufficient security mechanisms for the intended task. The required services and functions SHOULD be activated. The operating system SHOULD support the use of a Trusted Platform Module (TPM).

SYS.4.3.A9 Use of Cryptographic Processors or Coprocessors in Embedded Systems (S) [Developers, Planners, Procurement Office]

If an additional microcontroller is used for cryptographic calculations, its communication with the system microcontroller SHOULD be adequately secured. The necessary trust anchors SHOULD be realized for the embedded system. A trust chain (Chain of Trust) SHOULD also be implemented.

SYS.4.3.A10 Recovery of Embedded Systems (S)

Embedded systems SHOULD have rollback capabilities.

SYS.4.3.A11 Secure Decommissioning of an Embedded System (S)

Before embedded systems are decommissioned, all data on the system SHOULD be securely deleted. If this is not possible, the system SHOULD be destroyed. The deletion or destruction SHOULD be documented.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered when there is a higher need for protection. The concrete definition is made in the context of an individual risk analysis.

SYS.4.3.A12 Selection of a Trustworthy Delivery and Logistics Chain and Qualified Manufacturers for Embedded Systems (H) [Procurement Office]

Effective controls SHOULD be performed in the logistics chain to ensure that:

• embedded systems do not contain manipulated, counterfeit, or exchanged components,
• the systems conform to specifications and no hidden functions were implemented during manufacture, and
• unauthorized parties cannot gain access to confidential information about the embedded system.

The companies involved SHOULD demonstrably be qualified.

SYS.4.3.A13 Use of a Certified Operating System (H) [Developers, Planners, Procurement Office]

The operating system SHOULD be evaluated according to a recognized standard at an appropriate level.

SYS.4.3.A14 Secured and Authenticated Boot Process in Embedded Systems (H) [Developers, Planners, Procurement Office]

The boot process of an embedded system SHOULD be secured by having the bootloader verify the integrity of the operating system and only load it if it has been rated as correct. Conversely, the operating system SHOULD also verify the integrity of the bootloader.

A multi-stage boot concept with cryptographically secure verification of individual steps SHOULD be implemented. Secure hardware trust anchors SHOULD be used. For an ARM-based embedded system, ARM Secure Boot SHOULD be used. For a Unified Extensible Firmware Interface (UEFI), Secure Boot SHOULD be used.

SYS.4.3.A15 Memory Protection in Embedded Systems (H) [Developers, Planners, Procurement Office]

Memory protection mechanisms SHOULD already be taken into account during the design of embedded systems. The type of memory protection as well as the number and size of protection zones SHOULD be appropriate for the intended use.

SYS.4.3.A16 Tamper Protection for Embedded Systems (H) [Planners]

A tamper protection concept SHOULD be developed for embedded systems. Appropriate mechanisms SHOULD be established to detect, record, and prevent tamper attacks. Finally, appropriate procedures SHOULD be established for how to respond to a tamper attack.

SYS.4.3.A17 Automatic Monitoring of Module Functions (H) [Planners, Procurement Office]

All modules of an embedded system with increased requirements for availability and integrity SHOULD have integrated built-in self-test facilities (Built-in Self-Test, BIST). Tests SHOULD verify the integrity of the system during the power-up process and at appropriate time intervals during operation. Where possible, the self-test functions SHOULD also check the security functions and security properties of the module.

At regular intervals, the integrity of memories and I/O components SHOULD be checked within the BIST. Existing BIST functions SHOULD be supplemented with the required functions where possible.

SYS.4.3.A18 Resistance of Embedded Systems to Side-Channel Attacks (H) [Developers, Procurement Office]

Appropriate precautions SHOULD be taken against non-invasive and (semi-)invasive side-channel attacks.

Additional Information

Good to Know

The BSI provides guidance for testing ICS components and presents measures to avoid and detect vulnerabilities in its document “ICS Security Compendium — Test Recommendations and Requirements for Component Manufacturers”.