FORENSICS MODULE AND EMBEDDED SYSTEM

Description

[0001] Various embodiments relate to a forensics module, an embedded system and an ATM.

[0002] Critical infrastructures (KRITIS), such as communications, energy, transport, or finance, are based on information technology systems (so-called IT systems). Components of these IT systems include routers, industrial control systems, medical devices, and ATMs. US 10 079 842 B1 describes a block-level forensic service for detecting malicious activity in logs. EP 3 798 883 A1 describes a module for digital forensics that identifies forensic-specific metadata of the computing device from a variety of system metadata of the computing device based on predetermined rules. The forensic-specific metadata is used to detect suspicious digital activity.

[0003] With increasing digitalization, more and more control intelligence is being embedded in physical sensors and actuators, e.g., in a so-called cyber-physical system (CPS), which implements the networking of embedded systems through wired or wireless communication networks. Such a CPS (depicted as a network of information technology, software-based components with mechanical and electronic parts that communicate via a data infrastructure, such as the Internet) consists of specialized hardware and embedded software. This embedded software is also referred to as firmware.

[0004] According to various embodiments, it has been clearly recognized that the traditional view, according to which the firmware of an embedded system is granted an inherently higher level of security due to its low complexity compared to classic application software (e.g., PC software), increasingly reflects less and less reality. Due to this view, however, there are currently no protection concepts for firmware that include attack prevention, detection, and investigation. This circumstance makes it easier for third parties, e.g., in the context of professionally organized data crime, to carry out dedicated manipulation of the firmware. Coordinated manipulation of hardware, sensors, and firmware is typical of such attacks.

[0005] Such targeted attacks (so-called "advanced persistent threats") pose a high risk potential and result in associated economic losses. While an attack on the firmware of a vehicle's CAN bus controller can still be handled with a recall, such an attack in the telecommunications, energy, and healthcare sectors can have far more devastating consequences, for example, on the security of supply to the population.

[0006] In this context, it was recognized that while prompt investigation of such an attack would be beneficial for mitigating its consequences, it is difficult to manage using conventional means, whether by the manufacturer or the authorities. Such investigation is particularly important for preventing future attacks. Conventional investigation techniques are difficult to apply directly due to the embedding of the firmware in the hardware. Furthermore, such investigation also affects the conflicting interests of the parties involved, such as the operator, manufacturer, and investigating authorities, so that these parties are faced with requirements that often conflict with one another. For example, the manufacturer has a strong interest in protecting its corporate secrets, whereas the investigating authorities want to be as comprehensively informed as possible.

[0007] According to various embodiments, these circumstances and requirements are better addressed. Among other things, it is provided that a forensic image of the suspected tampered firmware (also referred to as a firmware image) can be extracted, and this firmware image can be emulated and examined in a suitable environment. The tampered firmware vividly exhibits the original firmware and additional malicious code.

[0008] According to various embodiments, a forensics module is provided, with which an embedded system can be extended, for example, and which extracts the forensic image and provides it in such a way that the requirements of the parties involved are met as much as possible. In line with this, according to various embodiments, an emulation system for emulating an embedded system is provided, by means of which the forensic image can be examined as efficiently and authentically as possible.

[0009] According to various embodiments, the timely processing of an attack on an embedded system (EGS) is simplified, e.g., with greater efficiency and / or greater effectiveness. This improves the clearance rate of such attacks and thus also enables improved crime prevention. This results in significant potential for protecting critical infrastructures and thus increasing security of supply. Improvements in police threat response and increased crime prevention through faster and improved information acquisition can also be achieved.

[0010] Efficient forensic extraction of embedded firmware may involve extracting the suspected tampered firmware from the hardware with bit-accuracy. Investigation in an emulation environment may involve dynamically examining the extracted firmware and fully simulating the incident that triggered the extraction.

[0011] It shows Figure 1 shows an embedded system according to various embodiments in a schematic structural diagram; Figure 2 shows a forensics module according to various embodiments in a schematic structural diagram; Figure 3 shows the forensic extraction of the system state according to various embodiments in a schematic flow diagram; Figure 4 shows a forensics module according to various embodiments in a schematic structural diagram; Figure 5 shows an exemplary implementation of the security mechanisms of the forensics module according to various embodiments in a schematic structural diagram; Figure 6 shows an exemplary implementation of the firewall of the forensics module according to various embodiments in a schematic structural diagram; Figure 7 shows a state diagram of a firewall according to various embodiments in a schematic flow diagram;Figure 8, Figure 9 and Figure 10 each show components of the forensic extraction according to various embodiments in a schematic flow diagram; Figure 11 shows a forensics module according to various embodiments in a schematic structure diagram; Figure 12 shows a software stack of the embedded system according to various embodiments in a schematic structure diagram; Figure 13 shows the software stack of the system according to various embodiments in a schematic flow diagram; Figure 14 shows an emulation system according to various embodiments in a schematic structure diagram; and Figure 15 shows an analysis system according to various embodiments in different views. ;

[0012] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. In this regard, directional terminology such as "top," "bottom," "front," "back," "fore," "rear," etc., will be used with reference to the orientation of the described figure(s). Since components of embodiments may be positioned in a number of different orientations, the directional terminology is for purposes of illustration and is in no way limiting. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention.It is understood that the features of the various exemplary embodiments described herein may be combined with one another unless specifically stated otherwise. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.

[0013] In this description, the terms "connected," "attached," and "coupled" are used to describe both a direct and an indirect connection (e.g., ohmic and / or electrically conductive, e.g., an electrically conductive connection), a direct or indirect connection, and a direct or indirect coupling. In the figures, identical or similar elements are provided with identical reference numerals where appropriate. For example, multiple elements can be coupled to one another along an interaction chain, along which an interaction can be exchanged, e.g., a signal and / or electrical energy. According to various embodiments, "coupled" can be understood in the sense of a mechanical (e.g., physical) coupling, e.g., by means of direct physical contact.

[0014] The state of an entity (e.g. a device, a system or an operation or process) can be understood as the totality of the information that completely describes the variable (e.g. time-dependent) properties of the entity. The actual state of the entity can be understood as the state of the entity that actually exists or can be detected by sensors at a given point in time. The target state of the entity can be understood as the desired state, i.e. a specification. Control can be understood as an intentional influencing of the current state (also referred to as the actual state) of the entity. The current state can be changed according to the specification (also referred to as the target state), e.g. by changing one or more operating parameters (then also referred to as manipulated variables) of the entity, e.g. by means of an actuator.

[0015] Reference is made herein to various information technology (e.g., data processing and / or data storage) components, such as processors, data storage, communications infrastructure (e.g., comprising or formed from a bus system or other network), and the like. The processor-external components of the EGS are also referred to as peripherals or peripheral components. Several data processing and / or data storage components can be coupled to one another via the communications infrastructure (e.g., via a corresponding interface of the component) and, during operation, exchange data (e.g., a digital representation of information) with one another (more generally also referred to as communicating).

[0016] Communication can, for example, be message-based (i.e. based on messages) according to a communication protocol (e.g. a network communication protocol, also referred to as a network protocol for short). Communication can involve transmitting, or at least sending, or at least generating a message containing the data according to the communication protocol. The communication protocol can descriptively describe an agreement according to which communication takes place between two or more components. In its simplest form, the communication protocol can be defined as a set of rules that specify the syntax, semantics, and synchronization of data transmission. The communication protocol(s) used (e.g. one or more network protocols) can, in principle, be selected arbitrarily and can (but do not have to) be configured according to the OSI (Open System Interconnect) reference model.Any protocol can also be used in the respective protocol layers. For example, a fieldbus communication protocol can be used for communication over a fieldbus. For example, a USB communication protocol can be used for communication over a universal serial bus (USB). Of course, other communication protocols can also be used, which could be proprietary, for example.

[0017] The interface coupled to the communication infrastructure may be configured to transmit the data according to the communication protocol, for example to transmit, or at least send, or at least generate a message comprising the data according to the communication protocol.

[0018] According to various embodiments, a system-internal bus system may be configured to provide communication between the components of an EGS. The system-internal bus system may, for example, comprise a processor-internal bus and a processor-external bus.

[0019] According to various embodiments, the system-internal bus system may comprise or be formed from a fieldbus. The fieldbus may be configured as a network for distributed real-time communication, e.g., via a message-based communication protocol. The order and priority of a plurality of messages sent and / or received via the fieldbus is defined by the fieldbus communication protocol. Such a fieldbus communication protocol may be configured for distributed real-time control, e.g., standardized as International Electrotechnical Commission (IEC) 61158 (title "Digital data communications for measurement and control - Fieldbus for use in industrial control systems", e.g., in the version dated May 2, 2017).

[0020] The EGS can communicate with other components via a system-external network, if present. A system-external network described herein can, for example, be a local network (e.g. a Local Area Network (LAN), a Wireless LAN (WLAN), or a Personal Area Network (PAN), such as a Wireless PAN (WPAN), such as a Bluetooth network) or a non-local network (such as a Metropolitan Area Network (MAN), a Wide Area Network (WAN) or a Global Area Network (GAN)), depending on its range, or can be formed from it. The network can, for example, be a radio network (also referred to as a wireless network or cable-free network), such as a cellular network, or a wired network, depending on its transmission type. The network can also, for example, be a cellular radio network (e.g. a WLAN of the IEEE 802.11a / b / g / n type).11 in ad hoc mode, a Bluetooth network, or another cellular mobile network), for example, according to a third-generation (3G), fourth-generation (4G), fifth-generation (5G), or LTE (also referred to as 3.9G) mobile communications standard. The network may also comprise several interconnected subnetworks of different types.

[0021] According to various embodiments, the term "processor" can be understood as any type of entity that allows the processing of data or (e.g., data-representing) signals. The data or signals can, for example, be processed according to at least one (i.e., one or more) specific function performed by the processor. Examples of components of a processor include: an analog circuit, a digital circuit, a mixed-signal circuit, a logic circuit, a microprocessor (e.g., in ARM architecture), a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), an integrated circuit, or any combination thereof. A microprocessor in ARM architecture is also referred to herein as an ARM processor or ARM for short.Any other manner of implementing the respective functions described in more detail below may also be understood as a processor or logic circuit. It is understood that one or more of the processes and / or acts described in detail herein may be executed (e.g., realized) by a processor through one or more specific functions performed by the processor. Similarly, a process or act described herein may be implemented by means of code segments that are configured, when executed by the processor, to cause the processor to perform the process or act.

[0022] According to various embodiments, a data storage device (also referred to as a storage medium or simply as memory) can be a volatile or non-volatile data storage device. Examples of a non-volatile data storage device include, or be formed from, a hard disk, a semiconductor memory such as a read-only memory, a non-volatile random access memory (also referred to as NVRAM - "non-volatile random access memory") and / or a flash memory (also referred to as flash for short). The read-only memory (also referred to as ROM) can be, for example, a programmable ROM or an erasable programmable ROM (can also be referred to as EPROM). The volatile data storage device can be, for example, a volatile random access memory.

[0023] In the context of a cryptographic process (e.g. encryption or signing), a cryptographic key (also simply referred to as a key) is understood to be information (e.g. a character string) that parameterizes the cryptographic process (e.g. its algorithm) and thus influences its output (e.g. independent of the input).

[0024] According to various embodiments, a sensor can be understood as a component which is configured to detect a physical quantity (also referred to as a measured quantity) of its environment, e.g. an actual operating parameter of a system or process as a measured quantity. The sensor can, for example, be part of a measuring chain which has a corresponding infrastructure (e.g. processor, storage medium and / or bus system or the like). The measuring chain can be configured to control the corresponding sensor, to process its detected measured quantity as an input quantity and, based thereon, to provide an electrical signal as an output quantity which represents the actual state of the input quantity at the time of detection. The measuring chain can, for example, be or will be implemented by means of an embedded system.

[0025] An actuator can be understood as a component that is configured to influence a physical variable (also referred to as a manipulated variable) in its environment, e.g. the manipulated variable of a system or process. The actuator can, for example, be part of a control chain that has a corresponding infrastructure (e.g. processor, storage medium and / or bus system or the like). The control chain can be configured to process instructions that represent a target state of the manipulated variable as an input variable and, based thereon, to control the actuator, which influences the actual state of the manipulated variable in accordance with the target state. The actuator can be controlled by means of an electrical signal (also referred to as a control signal). The control chain can, for example, be or will be implemented by means of an embedded system.

[0026] The final control element can, for example, comprise an actuator (also referred to as actuator). The actuator can be configured to generate a mechanical movement (e.g. translation, rotation or vibration, e.g. sound) or to mechanically influence its environment in another way. The actuator, e.g. an electromechanical converter, can, for example, be configured to convert electrical energy into mechanical energy (e.g. through movement) in response to the control. Other types of actuators can also be configured to provide a voltage, a current, a frequency, radiation (e.g. light), a field (e.g. magnetic field) or the like in accordance with the desired state in response to the control.

[0027] The term "embedded system" can be understood as an electronic computing device (also referred to as a calculator or computer) that is embedded (e.g., integrated) in a technical context, e.g., configured to provide one or more functions in the technical context (also referred to as a technical function). Examples of the technical function include: a monitoring function, a control function, and / or a closed-loop control function (where the output of the monitoring function is fed as input to the control function), a data conversion function (or signal conversion function). The monitoring function can, for example, be implemented using a measurement chain. The control function can, for example, be implemented using a control chain.

[0028] Examples of devices comprising one or more than one embedded (e.g., ARM-based) system include: a highly secure smart card, a Bitcoin wallet, an ATM, a self-encrypting hard drive, a facility control device, a utility device (e.g., for energy or water supply), and / or a vehicle (e.g., automobile or drone), e.g., an automotive control device. An exemplary implementation of an embedded system is an ARM-based system (e.g., comprising one or more than one ARM processor), e.g., an ARM-based control device. An ARM-based EGS allows a standardized processor core to be combined on a chip with application-specific peripheral blocks.

[0029] Exemplary components of an ATM that have an EGS, e.g. whose operation is controlled thereby, include: a reading device (e.g. for reading an RFID chip, a credit card, a smart card or the like), a printer, a camera, a network device (e.g. a network card), a transport device (e.g. for transporting banknotes or other valuable documents), a cash cassette (e.g. for holding banknotes or other valuable documents), a validation device (e.g. in an ATM), a dispensing device (e.g. for dispensing banknotes or other valuable documents from an ATM), a deposit device (e.g. for depositing banknotes or other valuable documents in an ATM), a user interface (e.g. having a PIN pad, a keyboard, a touchscreen or the like), e.g. an encrypting PIN keypad.

[0030] The EGS may have one or more interfaces configured according to the technical function (also referred to as functional interfaces), which are configured, for example, to communicate according to a corresponding communication protocol. The functional interface may, for example, be configured to communicate via bus, e.g., CAN bus or LIN bus (also referred to as Local Interconnect Network Bus), ZigBee for wireless communication, or IP over Ethernet. The functional interface may, for example, be configured to communicate with a sensor and / or an actuator, e.g., to control it.

[0031] This document refers, among other things, to an embedded system as part of a cyber-physical system (CPS). It should be understood that the aspects explained with regard to a CPS can apply analogously to the individually deployed embedded system, and vice versa. A CPS descriptively describes the combination of information technology, software components with mechanical and electronic parts that communicate with each other via a communication infrastructure.

[0032] According to various embodiments, reference is made to data (also referred to as state data) that represents a system state of the embedded system. The state data can comprise or at least represent information from one or more than one (e.g., processor-internal and / or processor-external) memory area of ​​the embedded system, e.g., the data contained therein. The processor-internal memory area can, for example, comprise or be formed from a register of a processor (also referred to as a processor register). For example, the state data can comprise an image of the data stored by the EGS (e.g., a memory image or a firmware image) or at least a representation thereof.

[0033] For ease of understanding, various simplified terms are used herein to refer to the affected parties, including: The manufacturer of the EGS or CPS (also referred to as the manufacturer); the operator of the EGS or CPS (also referred to as the operator); the manufacturer's software of the EGS or CPS (also referred to as the firmware); the operator's network (also referred to as the network for short), with which the EGS or CPS is integrated into the operator's infrastructure; the investigative authority (also referred to as the investigator) that is investigating an attack on the firmware and is trying to secure evidence for use in court; a fraudulent party (also referred to as the attacker), e.g. a person or organization that tampers with the firmware of the embedded system or CPS or at least attempts to do so. The tampered firmware can be set up to tamper with the embedded system or CPS.To operate a CPS in a manner that is outside of its manufacturer-intended mode of operation (also referred to as maliciously manipulated), e.g., to the detriment of the operator, the user, and / or the manufacturer. The maliciously manipulated firmware can, for example, give the attacker at least partial access to data and / or the operation of the embedded system or CPS. Additional examples of manipulated firmware enable the attacker to: manipulate program execution, introduce their own functionality, output data from this environment, read and / or modify data en route from the CPS to the manufacturer, and / or selectively view and manipulate data at the manufacturer before passing it on to the investigator.

[0034] According to various embodiments, a forensics module is provided that respects the requirements of the parties involved as much as possible while still enabling the system state of the EGS or the manipulated firmware to be forensically extracted as accurately as possible. The forensics module according to various embodiments prevents the operator, among other things, from undermining the forensic extraction of the system state and thus acting as an attacker themselves. For example, the operator is prevented from gaining insight into confidential data of the CPS to which they normally do not have access, such as the manufacturer's IP. The operator is prevented, for example, from manipulating extracted data, for example, to avert liability claims. Such a fraudulent operator corresponds to an attacker who can read and modify data on the way from the embedded system to the manufacturer.

[0035] The forensics module according to various embodiments also prevents the manufacturer from acting as an attacker, e.g., attacking the authenticity of the state data. The manufacturer is prevented, for example, from manipulating the state data before passing it on to the investigator, for example, to avert liability claims. The manufacturer is prevented, for example, from transmitting data to the investigator that was not extracted from the embedded system in this way, or from falsifying the system state in any other way.

[0036] Fig.110 illustrates an embedded system 150 (EGS) according to various embodiments 100 in a schematic layout diagram, which comprises at least one (i.e., one or more than one) processor 104 (also referred to as embedded processor 104) and one or more than one processor-external component (also referred to as peripheral component). The EGS 150 may, for example, comprise or be formed from a microcontroller.

[0037] Examples of peripheral components of the embedded system 150 include: a memory device 102 (e.g., having one or more data memories 102s, 112s or memory areas 102s, 112s), at least one (e.g., physical) interface 108, and a communication infrastructure 106, e.g., having a bus system, e.g., an "Advanced High-performance Bus" (AHB). The communication infrastructure 106 can couple at least one or more peripheral components (e.g., memory device 102 and / or interface 108) to the embedded processor 104.

[0038] The EGS 150 (e.g., its storage device 102) may, for example, have a trusted storage area (also referred to as a secured storage area) and a non-trusted storage area that are separated from each other (e.g., physically, in terms of their address, and / or by a security mechanism).

[0039] The firmware of the embedded system 150 may be stored on the storage device 102, for example at least partially on the non-trusted memory area (then also referred to as the non-trusted part of the firmware).

[0040] The at least one (e.g. physical) interface 108 (also referred to as functional interface) can be configured to control at least one sensor 110 and / or at least one actuator 112 (e.g. to communicate with them), e.g. by means of a bus system 108b.

[0041] For example, the embedded system 150 can be configured to implement one or more technical functions, e.g., for an automated teller machine (also referred to as a bank machine), using the functional interface 108. Examples of the technical functions of an ATM include: accepting and / or dispensing documents (e.g., cash); reading a chip card; receiving authentication information from a user (e.g., for a PIN entry device); transporting documents within the ATM; storing and / or retrieving documents in / from a safe (e.g., a cash cassette arranged therein) of the ATM, and the like.

[0042] For example, the embedded processor 104 may include or be formed from one or more ARM processors. For example, the embedded processor 104 may include or be formed from one or more microprocessors.

[0043] According to various embodiments, a cyber-physical system (CPS) may include the embedded system 150 (or at least the embedded processor 104) and the at least one sensor 110 and / or at least one actuator 112. Optionally, the CPS may include an additional interface (also referred to as a networking interface). The networking interface may, for example, be configured to communicate according to a communication protocol of the Internet protocol family (then also referred to as an Internet communication protocol), e.g., from the TCP / IP protocol family.

[0044] In an exemplary implementation, the CPS comprises: at least one physical sensor 110 and / or at least one physical actuator 112, one or more than one optional bus system 108b (e.g., comprising a CAN bus), and one or more than one microcontroller (also referred to as MCU) as a component of the embedded system 150. For example, the at least one physical sensor 110 is connected to the MCU directly or via the physical bus system 108b as an interface. Optionally, multiple MCUs of the EGS 150 can be coupled to one another via the bus system 108b and / or integrated into the operator's infrastructure via the networking interface, e.g., connected to a network (e.g., the Internet).

[0045] An MCU may include at least one processor 104 (e.g., one or more CPUs and optionally one or more co-processors), a volatile data memory 102s (e.g., RAM), a non-volatile data memory 112s (e.g., flash, ROM), and one or more additional peripheral components 106, 108. Each peripheral component configured as an interface 108 may couple the MCU to the at least one of the sensors or actuators and / or be addressable via a register mapped into the address range of the MCU.

[0046] An attack on the CPS may result in the attacker manipulating the untrusted part of the CPS's firmware after commissioning. If manipulation of the firmware of an embedded system 150 is detected, it is advantageous for further investigation to extract this manipulated firmware in a verifiable manner (e.g., bit-accurately and / or completely). Conventionally, potential interfaces in a security-critical environment are deactivated to prevent an attack via them. Therefore, the detection of malicious manipulation of the firmware of an embedded component from the outside is traditionally very complex and usually does not provide conclusive information. Conventional concepts for detecting external firmware manipulation are based solely on measurements of the power consumption or the timing behavior of the embedded system. Alternatively, a forensic expert could read the firmware invasively by mechanically opening the chip.This may require detailed knowledge of the chip, for example, netlists, the placement of subcomponents such as memory and crypto modules, and their physical wiring (routing) through so-called reverse engineering. However, all of these concepts require the embedded component to be removed and thus do not allow for efficient investigation, especially during operation. Due to the complexity of today's embedded systems, for example in the case of a standalone complex operating system (e.g. Android) and / or proprietary software on the order of several megabytes, this can only be handled manually. For example, such manual concepts would have to be adapted to the respective hardware architecture by trained specialists. Due to the further development of chip technology, structure sizes are becoming ever smaller, security mechanisms ever more complex, and system designs more compact.Therefore, reverse engineering is time-consuming, difficult to parallelize, and requires very expensive equipment in a dedicated laboratory. In particular, these processes lead to the destruction of the hardware under investigation.

[0047] According to various embodiments, a forensics module is provided, which, for example, enables bit-accurate extraction of the firmware of the embedded system 150 for forensic investigations. The forensics module may have a dedicated interface for reading the firmware or other data of the embedded system 150. Furthermore, the forensics module may implement one or more protection mechanisms (also referred to as safeguards) that inhibit misuse of this interface, e.g., based on cryptographic authentication mechanisms.

[0048] Fig.2illustrates the forensics module 250 (also referred to as extraction module) according to various embodiments 200 in a schematic structural diagram, which may, for example, be at least partially integrated into the embedded system 150 according to embodiments 100.

[0049] The forensics module 250 comprises: at least one memory area 202 (e.g., comprising a secured memory area 202s and / or a non-secured memory area 212s), at least one (i.e., one or more than one) processor 204 (also referred to as forensics processor 204), a communication infrastructure 206. The communication infrastructure 206 may couple at least the at least one memory area 202 and the forensics processor 204 to one another.

[0050] The forensics module 250 further comprises at least one interface 208 (also referred to as forensics interface 208) configured to communicate with the embedded system 150 (e.g., its components), e.g., with the at least one embedded processor 104 and / or with the memory device 102 of the embedded system 150. The communication with the embedded system 150 via the forensics interface 208 may, for example, be privileged to penetrate one or more protection mechanisms of the embedded system 150.

[0051] Reference is made herein, inter alia, to a forensics module which is at least partially (i.e., partially or completely) integrated into an embedded system 150 (e.g., by software), for example when one or more components 102, 104, 108, 106 of the embedded system 150 are configured to additionally provide one or more aspects of the forensics module 250 or functions and / or components thereof. For example, the forensics module 250 may be implemented at least partially as standalone firmware or at least as program code (also referred to as forensics code), which is, for example, integrated into the firmware of the embedded system 150, stored in the memory device 102 of the embedded system, and / or executed by the at least one processor 104 of the embedded system 150.For example, one or more memory areas of the forensics module may be provided in the memory device 102 of the embedded system 150. For example, the functions of the or each forensics processor 204 may be provided by the at least one embedded processor 104 of the embedded system 150, for example, when it executes the forensics code. The forensics interface 208 may be provided by hardware and / or software. For example, the forensics interface 208 may be provided by a communications protocol.

[0052] It can be understood that the aspects or functions and / or components of the forensics module 250 explained with respect to the integrated forensics module 250 can be provided at least partially (i.e., partially or completely) as a (e.g., physically) standalone component (e.g., its memory area, forensics interface, and / or forensics processor), which can, for example, be retrofitted or added to an existing system architecture. For example, the forensics interface 208 can have at least one physical data line, but does not necessarily have to, e.g., if it is implemented via software.

[0053] The at least one forensic processor 204 is configured (e.g., by means of code segments) to forensically extract data (also referred to as state data) representing a system state of the embedded system 150 or CPS by means of the forensic interface 208 (also referred to as extraction for short).

[0054] The state data may represent (e.g., comprise) the contents (e.g., the data) of one or each register of the at least one processor 104 (e.g., the or each CPU and optionally the or each co-processor) and / or the contents of the or each off-processor data memory 102s, 112s of the embedded system or CPS. For example, the state data may represent (e.g., comprise) the contents of RAM, flash, and CPU, co-processor, and peripheral registers.

[0055] Forensic extraction of compromised firmware can meet one or more of the following requirements to extract compromised firmware from the hardware during operation: Coordinated approach: The manufacturer provides operators and investigators with a detailed description of how to proceed in the event of tampering, which information and data will be secured, and which steps will be taken to extract the firmware. Confidentiality: Use of technical means to protect the manufacturer's company secrets (e.g., firmware IP) from unauthorized / unnecessary access, e.g., by the operator. Authenticity: The manufacturer provides technical means to detect any subsequent changes to the content and / or origin (identity of the hardware unit) of the extracted data (e.g., the manipulated firmware). This can be possible not only for the manufacturer but also for the investigator. Partial disclosure: Optionally, the manufacturer can also provide technical means to disclose only dedicated parts of the extracted system state while still ensuring authenticity.

[0056] The coordinated approach ensures that no important information for analysis is lost on-site in the absence of the manufacturer. Confidentiality serves to protect the manufacturer's company secrets (e.g., intellectual property (IP)). This protection, in turn, forms the basis of trust for implementing further mechanisms to clarify the incident. Authenticity ensures that the image can be used as evidence for criminal prosecution and to clarify liability issues after the manufacturer has disclosed (e.g., made public) the image or parts of it. Partial disclosure allows the manufacturer to disclose only those parts of the extracted system state relevant to the attack. It should be noted that larger parts or even the entire system state can also be made available to investigators to rule out fraud by the manufacturer in case of doubt.Partial disclosure can, above all, minimize the amount of data to be published in order to protect the manufacturer's trade secrets (e.g., IP). A court can then rely on the analysis of investigators who have a complete record of information, while at the same time, relevant parts of the malicious code (e.g., malware) can be made public while preserving the authenticity of the data.

[0057] The forensic extraction of the system state can be configured to deprive the attacker of the opportunity to compromise the confidentiality, authenticity, and / or availability of the extraction. For example, the malicious code (e.g., malware) could be designed to output confidential CPS data in connection with its extraction. Furthermore, the CPS state could be manipulated by the malicious code during extraction, for example, to complicate analysis or prevent admissibility in court. Furthermore, the malicious code could attempt to prevent the extraction of the system state.

[0058] This forensic extraction of the system state will be discussed in more detail below.

[0059] Fig.3illustrates the forensic extraction 350 of the system state according to various embodiments 300 in a schematic flow diagram, as it can be or will be implemented, for example, by means of the forensics module 250 (also referred to as extraction module 250) according to the embodiments 200.

[0060] The forensic extraction 350 can be performed within the forensics module 250 and / or the embedded system 150, and optionally started (initiated) from outside the embedded system 150 (e.g., by a so-called extraction trigger). The extraction trigger can, for example, be a party or a device, e.g., the investigator or another party. For example, the result of the extraction 350 can be output to the extraction trigger in response to the extraction trigger starting the extraction 350. Communication between the extraction trigger and the embedded system 150 can take place via a dedicated interface (not shown, also referred to as an extraction interface) of the forensics module 250.

[0061] Forensic extraction 350 can be started, for example, by freezing the embedded system 150, e.g., its system state. For this purpose, the embedded system 150 can be stopped.

[0062] The forensic extraction 350 may comprise, in 301, a (e.g., bit-accurate) readout of the state data 302 (e.g., comprising a memory image) by means of the forensics interface 208. For example, the state data may comprise one or more data records mk (k = 1...n, n>1). The reading of the state data 302 of a processor register (e.g., CPU register) and / or peripheral register may be performed by means of a routine dependent on the architecture of the embedded system 150 (also referred to as an architecture-dependent routine), which is implemented, for example, by means of the forensics interface.

[0063] The read-out status data 302 can, for example, be stored in a (e.g., secured) memory area of ​​the forensics module 250, e.g., in the form of one or more files (also referred to as a status file).

[0064] Reading the state data 302 may, for example, involve reading one or more processor registers (e.g., of the CPU, also referred to as CPU registers). Reading each processor register may involve saving a memory image of the or each processor register in the (e.g., secured) memory area of ​​the forensics module 250. This makes it possible to save the context of the running application immediately upon starting the forensic extraction 350. This facilitates the precise extraction of the context of an application, including any potential malware.

[0065] In an exemplary implementation, reading one or more CPU registers of the EGS 150 can occur. Each CPU register can be part of the system state of the EGS 150 (or CPS). During malicious code execution, the CPU registers contain information that could be relevant for further analysis. If the CPU register is not addressable (for example, unlike the rest of the memory), reading one or more CPU registers can result in: Mapping (e.g., saving) each CPU register in a state file (then also referred to as a register file) within a reserved memory area of ​​the forensics module 250; and reading the register file as part of the remaining memory reading of the forensics module 250 or the embedded system 150.

[0066] In order to create the most accurate image possible, it is advantageous if no information in the non-trusted memory area of ​​the embedded system 150 (or CPS) is modified.

[0067] If the extraction 350 is triggered by an exception handling (also called an exception), the reading 301 of the system state can have the following: Placing the exception frame on the stack; mapping the one or more CPU registers into the register file of the forensics module 250; setting the stack pointer (SP) into the memory area of ​​the forensics module 250; reading the memory of the embedded system 150 (e.g., including the register file); and restoring the stack pointer.

[0068] To meet one or more of the above requirements (authenticity, confidentiality, and / or partial disclosure), the state data 302 (e.g., a memory image of the embedded system 150) may be cryptographically processed before output (e.g., by the MCU), as explained in more detail below.

[0069] The forensic extraction 350 may include, at 303, determining a commitment 310 (also referred to as a commitment statement) based on the state data 302 and using a cryptographic commitment process 304 (e.g., a vector commitment process). For example, the state data 302 may be mapped to the commitment 310 using the commitment process 304. An exemplary algorithm (also referred to as a commitment algorithm) for implementing the commitment process 304 will be described in more detail later.

[0070] The commitment process 304 can be configured such that each data set mk can be verified individually, for example, based on the commitment and / or an opening value dk individually assigned to the data set mk. This ensures that the possibility of partial disclosure exists.

[0071] The forensic extraction 350 may include, in 305, encrypting (also referred to as encryption 305) the state data 302 and the opening values ​​dk using a key 305s (e.g., symmetric key 305s). The result of the encryption 305 comprises data 312 (also referred to as ciphertext, cryptogram, ciphertext, or ciphertext) comprising the encrypted state data and optionally encrypted opening values ​​dk. The key 305s (also referred to as first key 305s or encryption key 305s) may be implemented by means of data (also referred to as key data or key-implementing data) in the secured memory area 202s of the forensics module, as will be explained in more detail later. The encryption 305 of the state data and optionally the opening values ​​dk can be carried out by means of an (e.g. symmetric) encryption process 306.

[0072] For example, the encryption process 306 may be an authenticated encryption process 306 that enables the encryption and authentication of the state data using the encryption key 305s unique to the embedded system 150. The encryption key 305s may, for example, be known (e.g., only) to the manufacturer.

[0073] The forensic extraction 350 can optionally include, in 307, signing the state data 302. The result of the signing 307 comprises the so-called signature 314 of the state data 302. The signing 307 can be performed, for example, using a signature process 308 and / or a (e.g., asymmetric) second key 307s (also referred to as a signature key or signing key). The signing of the state data 302 enables a unique identification of the state data 302 using the signature key 307s that is unique to the embedded system.

[0074] Encryption 305 can promote the confidentiality of the manufacturer's trade secrets (e.g., IP) as part of the system state vis-à-vis the operator and / or the investigator. Nevertheless, the manufacturer can reveal the system state, for example, after signing a confidentiality agreement. Through the commitment 310, the embedded system (e.g., CPS) commits to the content of the state data 302, e.g., the encrypted memory image, at the time of extraction 350 (also referred to as the extraction time). This allows the manufacturer, despite encryption 305, to later prove to the operator and / or the investigator that the revealed system state corresponds to the previously extracted state data 302.

[0075] By using a vector commitment process 304 (also referred to as a VC process), subsets (e.g., one or more than one individual data set mk ) can also be uncovered, e.g., only the flash memory area if it contains the malicious code. The signature method, together with the unique identifier of the state data 302, makes it possible to prove that the state data 302 was created by the embedded system 150 at the time of extraction and was not subsequently modified (e.g., by the manufacturer). The functionality for decrypting, uncovering, and verifying the state data 302 is performed later using an emulation system (also referred to as a processing module), which will be described in more detail later.

[0076] The extraction module 250 (e.g., its forensic interface 208) implements a function for the extraction 350, which reads the system state of the EGS 150 (e.g., CPS) and outputs the result of the extraction 350 via a suitable interface, e.g., the networking interface.

[0077] If the addresses of the data read from the EGS 150 are relevant for the extraction 350 and are read as part of the system state, the state data 302 can be encoded in the Intel Hex format (also known as IHEX encoding). The Intel Hex format is particularly simple, offers widespread support, and is easy to read. Furthermore, the Intel Hex format also allows the encoding of the state data 302 in the stream, which makes it easier to output the encoded and secured state data 302 directly, in order to minimize memory requirements. Logically, in this case, the state data 302 is available as ASCII strings after IHEX encoding. The state data thus created can, for example, be used as a vector. m with n components m = (m 1 ,... ,mn ). However, any other suitable coding can of course be used, and coding of the state data 302 is not necessarily required.

[0078] It is advantageous if the size of the internal state of the extraction 350 is constant in size with the extracted system state. This achieves a lower memory requirement of the extraction 350, which will be provided exclusively for the extraction 350 and prevents the system state from being extracted only incompletely. This is facilitated by two or more components 303, 305, 307 (e.g., comprising: determining 303 the commitment 310, encrypting 305 and / or signing 307) of the extraction 350 (e.g., cryptographic processes) running in parallel. For example, the system state to be read out, e.g., the state data 302, is processed iteratively word by word or at least data record by data record.

[0079] Fig.4illustrates the EGS 150 according to various embodiments 400 in a schematic structure diagram (for example, configured according to embodiments 100), which can be transferred in particular to a plurality of embedded systems (or CPS), for example with regard to the implemented security mechanisms.

[0080] The basis of the forensics module 250 according to embodiments 400 is an STM32L4 MCU as part of the embedded system 150, whose at least one processor 104 comprises a Cortex-M4 CPU. The Cortex-M4 CPU has a 32-bit architecture for data and instructions. Registers and buses therefore have a width of 32 bits. The Cortex-M4 CPU further has a so-called thumb instruction set or implements a so-called thumb mode. In this thumb mode, a reduced instruction set, the so-called thumb instruction set, is available, in which only 16 bits are required for encoding instructions.

[0081] The following table provides an overview of the processor registers of the Cortex-M4 CPU. The Cortex-M4 CPU has two stack pointers: the main stack pointer (MSP) and the process stack pointer (PSP). Which of these stack pointers is accessed by register R13 can be controlled by a bit in the control register (CONTROL). The program status register (PSR) contains one or more of the following registers: an application program status register (APSR), an interrupt program status register (IPSR), and / or an execution program status register (EPSR). name type Access mode Description R0-R12 read-write all General Purpose Register MSP (R13) read-write privileged Main Stack Pointer PSP (R13) read-write all Process Stack Pointer LR (R14) read-write all Link Register PC (R15) read-write all Program Counter PSR read-write privileged Program Status Register APSR read-write all Application Program Status Register IPSR read-only privileged Interrupt program status register EPSR read-only privileged Execution Program Status Register PRIMASK read-write privileged Priority Mask Register FAULTMASK read-write privileged Fault Mask Register BASEPRI read-write privileged Base Priority Mask Register CONTROL read-write privileged Control Register

[0082] The link register (also known as the "link register" or "LR" for short) is used to store the return address when calling a function. Using the "BL" instruction, the CPU writes the current value of the program counter (or PC for short) to the link register (LR) before jumping to the target address. This allows the called function to be returned to later by setting the program counter to the value stored in the link register (a so-called "function return").

[0083] The Cortex-M4 CPU operates either in thread mode or in handler mode. Exceptions are executed in handler mode. For example, execution in handler mode is always privileged. All other execution occurs in thread mode. For example, execution in thread mode can be either privileged or unprivileged. In unprivileged mode, the Cortex-M4 CPU cannot access all registers and memory areas (see the table above). The transition from thread mode to handler mode occurs by raising an exception. Examples of exceptions include an external interrupt, a timer interrupt, and an access error.The Supervisor Call instruction (SVC instruction) also triggers an exception and allows a software switch to handler mode. Upon encountering an exception, the Cortex-M4 CPU automatically performs several steps, including: 1. Create an exception frame on the active stack (also called the stack). 2. Set the LR to a specific EXC_RETURN value. 3. Context switch to handler mode.

[0084] The exception frame for the Cortex-M4 CPU is shown in the following table, which depicts the Cortex-M4 stack frame when the exception occurs. The "Address Offset" column indicates the address offset relative to the value of the stack pointer (SP) before the exception occurs. Address offset register -4 PSR -8 PC -12 LR -16 R12 -20 R3 -24 R2 -28 R1 -32 R0

[0085] Accordingly, the registers R0-R3 and R12 can be overwritten in the exception handler, since they are reconstructed from the stack by the CPU when the handler is exited.

[0086] The exception frame also contains the value of the program counter before the exception was encountered. This allows the CPU to reset the program counter to its state before the exception was encountered at the end of the exception handler. To exit the exception handler, the program counter is set to the EXEC_RETURN value that was in the LR when the exception was encountered. EXEC_RETURN encodes information about the structure of the exception frame and the mode into which the exception should be exited (handler mode or thread mode). This causes the CPU to exit the exception into the correct mode and restore the exception frame registers.

[0087] Various options for implementing the forensics module 250 in the embedded system 150 are explained below.

[0088] To meet the confidentiality and integrity requirements, one or more security mechanisms are implemented to inhibit or prevent malicious code (e.g., malware) from accessing a secured memory area of ​​the embedded system 150 (e.g., CPS). The embedded system 150 (e.g., its memory device 102) has a secured memory area 402 (also referred to as trusted memory area 402) and a non-secured memory area 404 (also referred to as untrusted memory area 404).

[0089] In general, the trusted memory area 402 requires higher privileges (also referred to as permissions or authorization levels) to access it than the untrusted memory area 404. Hardware-based implementations of the trusted memory area 402 or its isolation from the untrusted memory area 404 include: a memory protection unit (the so-called "Memory Protection Unit" or MPU for short), a trusted runtime environment (the so-called "Trusted Execution Environment" or TEE for short), or a security element (the so-called "Secure Element" or SE for short).

[0090] In an EGS 150, the MPU is typically controlled by a real-time operating system (RTOS). The RTOS implements memory access control and separation between processes and between processes in thread mode and the RTOS in handler mode.

[0091] When using a TEE, all resources of the EGS 150 are separated into a secure and an insecure part. This enables the isolation of security-critical components, for example, from components with access to critical assets such as keys. This separation can also be achieved within the privileged RTOS. This allows security-critical functionalities to be separated from the complex part of the RTOS. When using an SE, security-critical functionalities are outsourced to a completely separate hardware component, the SE. Examples include a smart card or a trusted platform module (the so-called "Trusted Platform Module," or TPM for short). This provides a high level of isolation but complicates integration on the application MCU side.

[0092] The following refers to the implementation of the forensics module 250 in a TEE. Compared to implementation using the MPU, this has the advantage that, from a forensic perspective, the complex operating system controlling the MPU does not have to be located in the trusted part of the CPS. It should be understood that the aspects explained in this regard can apply analogously to another implementation of the forensics module 250 and are not necessarily limited to the TEE.

[0093] For the implementation of the trusted memory area 402, it may be important whether it should be accessed only once after system startup, or whether re-entry should occur at runtime, allowing extraction at any time. For runtime access, additional privileges can be granted upon entry. This case places higher demands on the hardware for implementing the trusted memory area 402. The impact of re-entry on the functionality of the forensics module 250 is shown in the table below. No re-entry Re-entry Detection Only on reboot, persistent manipulation, boot attestation Anytime, persistent and volatile manipulations, remote attestation in general extraction Only on reboot, persistent state Anytime, overall condition

[0094] However, secure re-entry into the trusted memory area 402 places greater demands on the hardware than entry via reboot, since the privileges must be elevated when transitioning from the untrusted to the trusted memory area 402 upon re-entry.

[0095] Since malicious code may be executed at the time of re-entry, it may be the case that forensic extraction 350 is executed in parallel with the malicious code. Otherwise, the attacker could undermine the availability of forensic extraction 350. Entry into forensic module 250 (illustratively, the activation of forensic module 250) then occurs via an exception of sufficiently high priority. Examples of exceptions for starting (triggering) forensic extraction 350 include: A timer: A timer as part of the root of the security chain (the so-called "Root of Trust" or RoT for short) can be used to periodically interrupt the malicious code and then, depending on possible additional conditions, start the extraction 350. The timer for starting the extraction 350 is suitable, for example, when the operating system is part of the RoT, since the operating system usually gains control over the control flow through a timer interrupt. External interrupt: An interrupt triggered by external events interrupts the malicious code. Here, too, it is advantageous if the interrupt configuration is part of the RoT, so that masking by the attacker is inhibited (e.g., prevented). The external interrupt is suitable, for example, when the extraction is to be triggered by the environment of the embedded system 150 (or CPS), for example, by pressing a button of the extraction trigger.Fault handler: Extraction 350 can also be implemented as part of a fault handler. In this case, extraction 350 is triggered when the malicious code causes a fault (e.g., an error) that is not otherwise handled. The fault handler is also suitable if extraction 350 is to be used generally for error analysis.

[0096] To promote availability, each of these exceptions can be configured in such a way that the interrupt cannot be suppressed by the attacker. This can be achieved, for example, by configuring the embedded system 150 in which both the interrupt handler itself and the interrupt controller configuration are located within the RoT. The specific implementation depends on the type and architecture of the respective embedded system 150 (or CPS), its MCU, and the available access control mechanisms. Possible implementation concepts include: an ARM security zone (the so-called "Arm TrustZone"), the firewall, or the MPU.

[0097] In a preferred, easy-to-implement implementation, the extraction 350 is triggered by an external interrupt (illustratively an interrupt instruction).

[0098] Below, various examples for the implementation of security mechanisms are explained, which are, for example, static, ie, are not necessarily configured until the system starts up of the embedded system 150: Read protection (RDP for short) protects data on an MCU from external system access. Proprietary code read-out protection (PCROP for short) provides additional protection of the executable code against unintentional internal readout. For example, PCROP can be used to protect security-critical data, such as one or more cryptographic keys. Write protection (WRP for short) protects a memory area from unwanted internal system write access.

[0099] The static protection mechanisms can, for example, be implemented interlockingly and / or supplemented by one or more of the following dynamic protection mechanisms. an MPU that is configured to isolate multiple memory areas from one another; a firewall that is configured to implement a secure, e.g. encapsulated, environment (also referred to as an enclave), e.g. providing a secured memory area, in which particularly security-critical data, such as one or more cryptographic keys, can be stored and / or critical functions can be executed on this data in isolation.

[0100] The so-called option bytes allow one or more static security mechanisms of the EGS 150 (e.g., microcontroller) to be configured. Both flash banks of the EGS 150 (e.g., microcontroller) each contain 40 option bytes for this purpose. If the contents of the option bytes are stored redundantly, only 20 bytes per flash bank are actually usable. The majority of the option bytes are not used.

[0101] The specific addresses of the individual registers depend on the architecture and / or application. The respective security mechanisms for the following registers will be discussed in more detail below. Let the index x ∈ {1,2} represent flash bank 1 or 2. If the index x is omitted in the following, this setting applies only to flash bank 1. RDP (1 byte) allows you to configure write protection; PCROPx_STRT and PCROPx_END (2 bytes each) allow you to define one or more memory areas protected by PCROP (also called PCROP areas); PCROP_RDP (1 bit) specifies whether the PCROP area is deleted when the RDP level is reduced; WRPxA_STRT, WRPxA_END as well as WRPxB_STRT, WRPxB_END (1 byte each) allow you to specify two areas per flash bank that are protected from write access. BOOT0 and BOOT1 bits together specify the boot mode.

[0102] According to various embodiments, it is provided that the option bytes can no longer be changed when RDP Level 2 is enabled, not even by the application on the MCU. The firewall is not necessarily part of the static security mechanisms and is therefore not configured or enabled via the option bytes.

[0103] According to various embodiments, the embedded system 150, e.g., its processor 104, is configured (e.g., as one of the first steps) to verify the configuration of the (e.g., static) security mechanisms (also referred to as a security check). The security check may include determining whether the option bytes satisfy a stored specification (as explained below) and optionally (e.g., if the specification is not satisfied) programming the option bytes (e.g., according to the specification). The security check may be provided by a so-called security engine module of the MCU. The functions of the security engine described herein may optionally also be provided by the forensics processor 204.

[0104] According to various embodiments, the embedded system 150, e.g., its processor 104, is configured to continue the boot process (also referred to as system startup) only if it has been determined that the option bytes are configured according to the specification. This reduces the risk that the booted embedded system 150 will be faulty if an attacker succeeds in manipulating the configuration of the option bytes (e.g., through a physical attack).

[0105] According to various embodiments, the security function unit may also provide the functionality for configuring the dynamic security mechanisms (e.g. firewall).

[0106] Read protection (RDP) is configured to protect the data of the embedded system 150 from external access. For example, RDP is configured to protect one or more of the following memory areas from external access: flash memory, option bytes, backup registers, and SRAM2 (SRAM1 is not necessarily protected). The access rights for the application and the possible accesses via a debug interface are summarized in the table below. Area Level User application Debug Read Write Erase Read Write Erase Flash (main) memory 1 Yes Yes Yes No No No 2 Yes Yes Yes N / A) N / A N / A Option bytes 1 Yes Yes Yes Yes Yes Yes 2 Yes No No N / A N / A N / A

[0107] There are 3 possible settings (also called levels) for RDP: Level 0 specifies that the RDP security mechanism is disabled; Level 1 specifies that the RDP security mechanism is enabled, but can be disabled because the option bytes can still be reprogrammed. However, disabling it erases the memory contents; Level 2 specifies that the RDP security mechanism is enabled and cannot be disabled because only read access to the option bytes is permitted from the application, while the debug interface is disabled. In this case, all static security mechanisms are immutable.

[0108] To enable RDP, the RDP option byte can be programmed accordingly, followed by a system reboot. If RDP is set to level 1, it can be reprogrammed, e.g., deactivated. To do this, the option bytes are reprogrammed, e.g., using the debug interface and / or the application. When reprogramming RDP from level 1 to RDP level 0, the entire memory is automatically erased.

[0109] Fig.5 illustrates an exemplary implementation of various security mechanisms of the forensics module 250 according to various embodiments 500 in a schematic structure diagram (for example implemented by means of the embedded system according to embodiments 100 or 400), which can be transferred particularly easily to a plurality of embedded systems (or CPS).

[0110] With RDP at Level 1, the debug interface can still be used. In this case, it may be possible to completely reprogram the embedded system 150. Nevertheless, there are use cases where RDP at Level 1 may be suitable even in application-oriented operation, for example, if access to the flash memory is restricted. The debug interface, in particular, can be used to circumvent the firewall. Therefore, RDP at Level 1 together with the firewall cannot necessarily be reliable, nor can the firewall necessarily meet the security requirements. Furthermore, the debug interface can be used to change the boot configuration so that the embedded system 150 boots from SRAM1 or from the ST boot loader. This opens up a potential attack surface when RDP Level 1 is used.

[0111] If the embedded system 150, such as the STM32L4 microcontroller, additionally supports PCROP, additional protection can be provided for one or more cryptographic keys of the embedded system 150 (e.g., a root attestation key, the encryption key 305s, and / or the signing key 307s). For example, PCROP is configured to configure one or more memory areas of the non-volatile memory as "executable only" (also referred to as NA memory area). In this case, accesses, e.g., direct memory access (DMA), debug access, write access, read access, and / or erase access, to this NA memory area are blocked. This area cannot even be addressed via the debug interface, except for execution.

[0112] According to various embodiments, it has been recognized that PCROP makes it possible to better secure a key that would otherwise be difficult to secure. For this purpose, data (also referred to as key-implementing data) is stored in the NA memory area, e.g., comprising executable program code (e.g., an assembly function) or other code segments that are configured such that, when executed by the processor, they cause the processor to write the key (e.g., its bytes) directly to an address specified in the data of another memory area (also referred to as the key target area) of the embedded system 150 (then also referred to as a PCROP-secured key). The key-implementing data can, of course, also implement the key differently, e.g., if PCROP is not supported or undesired.

[0113] For example, the key-implementing data can be executed from the RoT, which is protected by the firewall, to write the key. After the key has been used, the key is deleted from the memory, e.g., the key target area, of the embedded system 150.

[0114] The PCROP-protected key ensures that the key is available only as executable code most of the time and is only made available for read access by a cryptographic process when the key is actually needed. This makes an attack on the key more difficult.

[0115] For this PCROP-protected key, the PCROP_RDP bit can be set to 1 to delete the key in this area. Otherwise, the attacker could set RDP to level 0 and simultaneously disable the protection of the NA memory area using RCROP. In this case, the memory blocks (e.g., flash blocks) containing the key (e.g., as key-implementing data) would not be deleted, and the attacker could read the key.

[0116] According to various embodiments, the entire memory area designated for one or more keys can be secured using PCROP. This memory area can, in turn, be located behind the firewall (i.e., in its enclave), specifically in the code region.

[0117] Write protection (WRP) can be configured to protect or secure a memory area from unwanted (system-internal) write access. If RDP is set to level 2, and thus the debug interface is deactivated, WRP can provide a purely internal and, above all, static security measure. For example, option bytes and thus WRP settings cannot be changed. For example, memory areas in flash can be protected forever from changes using WRP. This makes WRP inflexible as a security mechanism, but can be practical for keys, especially if they should not or must not be changed for the lifetime of the embedded system 150. If RDP is set to level 1, e.g., in a productive environment, WRP can also be reconfigured, allowing the security mechanism to be temporarily deactivated (e.g., for a firmware update).If a memory area is secured using PCROP, an additional WRP security mechanism can be redundant.

[0118] While a statically secured memory area (e.g., the flash memory) can be provided using RDP, PCROP, and WRP (or a static security mechanism), a dynamically secured memory area can be provided using a firewall (or a dynamic security mechanism). The firewall allows the provision of a secured enclave (e.g., having one or more memory areas) that, for example, has its own code, its own address range in the flash memory, and / or its own address range in the RAM. Each memory area of ​​the enclave is isolated from the rest of the environment and equipped with very strict access mechanisms, which are provided, for example, by the hardware of the embedded system 150.

[0119] The firewall can, for example, be implemented as a trusted runtime environment. If the firewall is deactivated (e.g., unlike the static security mechanisms) during a system reset (system reboot), it can be activated as part of the initialization process of the embedded system 150. However, the firewall may not yet be activated at system startup, which opens the door to an attack (e.g., a side-channel attack) that could prevent the firewall from being activated and thus circumvent this security mechanism. This can be the case if the embedded system does not have a hardware-based RoT, such as a TPM. In this case, it may be useful to protect the code segments (or instructions) that activate the firewall with WRP (including the interrupt table). Together with RDP at Level 2, this prevents these code segments from being modified, so that the integrity of the forensics module 250 or the TEE can be guaranteed.

[0120] Fig.6 illustrates an exemplary implementation of the firewall 612 of the forensics module 250 according to various embodiments 600 in a schematic layout diagram of the MCU as part of the EGS 150 (e.g., configured according to embodiments 400), which can be transferred in particular to a variety of other embedded systems (or CPS).

[0121] The embedded system 150, e.g., its storage device 102, may have at least one memory area 651 (also referred to as FW memory area 651) secured by the firewall. The at least one FW memory area 651 may have one or more than one (e.g., more than two) of the following memory areas: a first flash memory area 602 in which the firmware is stored, a second flash memory area 604 in which data is stored, and a RAM memory area 606, which may be exclusive or shared. The embedded system 150, e.g., its storage device 102, may further have a DMA controller 608 (also referred to as DMA control device), which may, for example, be configured to perform memory access (either to the main memory itself or to a peripheral component) independently of the processor 104 (e.g., the Cortex-M4 CPU), e.g., without requiring the processor 104.

[0122] The at least one FW memory area 651 can be specified using a starting address and the length of each memory area. For example, a granularity of 256 bytes is enforced for the flash memory areas and / or a granularity of 64 bytes for the RAM segment.

[0123] The firewall 612 can be configured to detect (e.g., monitor) all memory accesses to the at least one FW memory area 651 (e.g., to flash and RAM), which occur, for example, via the communication infrastructure 106, e.g., its Advanced High-performance bus (AHB bus), and / or, for each of the memory accesses, to determine whether the memory access is permitted (also referred to as legal), e.g., if it is privileged to do so, or impermissible (also referred to as illegal), e.g., if it is not privileged to do so (also referred to as unprivileged). To this end, the firewall can be configured, for example, to detect where the memory access originates from and, based on this, determine whether this memory access is privileged. For example, an authentication sequence, which will be described in more detail later, can be privileged to access the FW memory area (also referred to as penetrating the firewall).

[0124] The firewall 612 can, for example, be configured to block unauthorized memory access to the at least one FW memory area 651 (e.g., from outside the protected at least one FW memory area 651) (also referred to as a blocking response). Alternatively or additionally, the firewall 612 (then also referred to as a closed firewall) can, for example, be configured to reset the embedded system 150 in response to the unauthorized memory access to the at least one FW memory area 651 (also referred to as a reset response). The reset response and / or the blocking response can, for example, be implemented using hardware. The reset response can, for example, comprise the firewall not triggering an interrupt, but instead directly resetting the embedded system 150.

[0125] The firewall 612 can be configured to determine memory access as permissible (e.g., only) if it occurs via an interface configured for this purpose, the so-called call gate (also referred to as a call gate). For example, the call gate can be configured to increase the permission level of the memory access if it meets a predefined criterion. The call gate can be implemented, for example, as a processor function of the forensics processor 204. The call gate can be configured to cause a dynamic change in the permission level of the forensics processor 204 when a specific instruction that meets the criterion is used. In this way, code and programs with fewer permissions can temporarily operate as if they were programs with higher permissions.

[0126] For example, using the call gate, isolated functions can be called in the enclave. This transfers control to the code behind the firewall.

[0127] At the logical level, the call gate can be implemented using a function that receives the input parameters for the enclave behind firewall 612 and returns a response. These input parameters can, for example, address a specific function behind the firewall and return the parameters for this function. At the technical level, the call gate can be configured or configured to correspond to firewall 612.

[0128] Fig.7 illustrates a state diagram of a firewall 612 (for example, configured according to embodiments 600) according to various embodiments 700 in a schematic flow diagram, which can in particular be transferred to a plurality of other embedded systems (or CPS).

[0129] By calling the call gate, the code behind the firewall can be executed. Passing through the call gate opens the firewall, allowing it to be penetrated. In this state, the code stored in at least one FW memory area 651 is executed normally, for example, as if there were no firewall at all.

[0130] For example, the firewall can be configured to either execute the reset response or close the firewall in response to a jump from within the at least one FW memory area 651 to an address outside the at least one FW memory area 651 ("irregular exit from the protected area"). The firewall can make this decision based on an indication (also referred to as a flag) in a predefined register located in the at least one FW memory area 651 and which can be adjusted (e.g., Firewall Pre Arm Flag in the FW_CR register). This is an additional safeguard mechanism to prevent such jumps. Before a regular exit from the code behind the firewall ("regular exit from the protected area"), this flag is set, and then control is transferred to the application (via a normal return from the function).If this flag is not set and the code leaves the protected area, the firewall interprets this as irregular behavior and resets the embedded system. Interrupts can also be conveniently disabled for this security mechanism.

[0131] The firewall can be used to secure one or more algorithms used to implement a cryptographic process and / or one or more cryptographic keys. Alternatively or additionally, security-critical processes, such as a firmware update (also known as a firmware upgrade), can be secured. An algorithm secured in this way is executed in isolation, and only the result is returned. This ensures, for example, that any intermediate results remain securely behind the firewall, which can be important for cryptographic functions. Furthermore, it ensures on a technical level that only dedicated functions can directly access a secured key.

[0132] In various embodiments, the firewall is configured to check (e.g., block and / or, e.g., release, if permitted) all accesses to the FW memory area 651 (e.g., from the MCU and / or DMA).

[0133] Exemplary implementations of the forensic extraction 750 and its components are explained below.

[0134] Fig.8 800 illustrates the determination 303 of the commitment 310 (for example, configured according to embodiments 300) by means of a cryptographic vector commitment process (VC process) according to various embodiments 800 in a schematic flowchart. The VC process 304 denotes a special commitment process that allows for the individual disclosure of dedicated parts of the extracted system state without violating their authenticity.

[0135] Illustratively, a commitment process allows a party to commit to a piece of information (e.g., status data) without having to disclose it (also referred to as the confidentiality property). The information thus remains confidential for the time being. In addition, the commitment process provides the ability to reveal the information at a later point in time, ensuring that the information remains unchanged (also referred to as the binding property), e.g., that it cannot be modified. For this purpose, cryptographic measures are used to provide proof (the so-called commitment), which enables the verification of the disclosed information.

[0136] A commitment process can have two phases (also called first phase and second phase), each of which can be implemented, for example, using an individual algorithm.

[0137] In the first phase (also referred to as the binding phase), the commitment 310 can be determined, for example, by means of a first algorithm (also referred to as a commitment algorithm or commit). The commitment algorithm can be configured to output the commitment c and optionally an opening value d as output data based on input data m (e.g., a message or the state data). Expressed as a relation, this can be written as Commit(m) → (c, d). The opening value d is kept secret, and the commitment c is published. The opening value d can, for example, be a random number or other random character string, for example, determined by means of a random generator (also referred to as RAND), and / or can be determined or specified by means of another mechanism. For example, the opening value can be used as a key that parameterizes the commitment process and thus the output commitment c (e.g.,independent of the input data m).

[0138] In the second phase (also called the opening phase), based on the commitment c, it can be determined whether a claim m' (illustratively the claimed input data) corresponds to the original input data m based on the commitment c and the opening value d (also called verification), for example using a second algorithm (also called verification algorithm or ComVrfy). The verification algorithm can be set up to determine whether m' matches the commitment c based on the claim m' as input data and the opening value d (e.g. without knowing m). Expressed as a relation, this can be written as ComVrfy(c, d, m) → b, where m = m' if b = 1 (or if b meets another criterion). The output b can, for example, only take the value 1 or 0.

[0139] A simple implementation of the commitment process can be achieved using a cryptographic hash function H as part of the commitment algorithm. The commitment algorithm generates a random number d and calculates c = H(d, m). The random value d is then the opening value and is initially kept secret. The hash function H can be configured such that the hash value or commitment c, due to the random choice of d, reveals nothing about the input data m. Once d is known, it can be verified for any assertion m' whether c = H(d, m'). If c = H(d, m'), this implies that m' = m.

[0140] The binding property can be enhanced, for example, if the hash function H is collision-resistant, e.g., weakly collision-resistant, preferably strongly collision-resistant, or further preferably perfectly collision-resistant. For example, the hash function H can be a collision-resistant one-way function and / or belong to the class of secure hash algorithms.

[0141] The VC process 304 is a special commitment process in which the input data m is multi-component, e.g., having n components. This can be written, for example, in the easily understandable vector notation, although it should be understood that any other notation for multi-component input data can also be used. Accordingly, the aspects explained with regard to the vector notation can apply analogously to any other notation for multi-component input data.

[0142] In vector notation, the multi-component input data m write as m =(m 1 ,... ,mn ). The special feature of the VC process 304 is that not necessarily the entire vector m has to be uncovered, but individual components mk , with k ∈[1, n], can also be uncovered without violating the binding property. The commitment algorithm of the VC process can then be written as Commit(m) → (c, d).

[0143] The opening phase of the VC process 304 may include first (illustratively as an intermediate step) determining one or more than one bound pair of I ∈ {1, n} and opening value d I , e.g., by means of a third algorithm (also referred to as a partial close algorithm or PartClose). For example, the partial close algorithm may be configured based on the opening value d, the input data mand the value I∈[1, n] to determine the opening value dk. Expressed as a relation, this can be written as PartClose(d,(m 1 ,... ,mn ),I) → (d I ,m I ), with m I = (m' 1 ,... ,m' n ), where ∀i ∈ I : m'i = mi , ∀i∉I:m'i = 1.

[0144] This partial close algorithm can be used to calculate opening values ​​d I for an index set I ⊆ [n].

[0145] Each aperture value di can, for example, be determined in advance using a random generator (also called RAND).

[0146] The corresponding verification algorithm can then be written as ComVrfy(c ,d I ,m I ) → b. This verification algorithm verifies the partially opened data against the commitment c.

[0147] A less complex implementation of the VC process 304 can be achieved using a cryptographic hash function H as part of the commitment algorithm. The commitment algorithm generates a first commitment (also referred to as an intermediate commitment ci or commitment component) ci = H(di , mi ) for each i (i=1, ..., i=n). The random values ​​di together then form the opening value d, which is kept secret. The intermediate commitments are combined to form a hash value or second commitment c (also referred to as the final commitment), for example, according to the following relation: c = H(c 1 ,..., cn ).

[0148] The partial close algorithm is designed to reveal a di for each i∈I, while for the remaining i the ci are computed and revealed as part of d I. Thus, during verification, the final commitment c can be reconstructed or verified from the intermediate commitments ci and the pair (di , mi ).

[0149] The low-complexity implementation of the VC process 304 using a cryptographic hash function H further ensures that the extraction 350 can be performed in a single pass and with the smallest possible memory requirements. The hash function can be instantiated, for example, with SHA-256 from the SHA-2 family (SHA denotes a secure hash algorithm). The data is then processed in 64-byte blocks, which corresponds to the internal state of SHA-256. With regard to the exemplary choice of SHA-256, it can be understood that what is described herein in this regard can apply analogously to any other SHA.

[0150] Another exemplary implementation will be discussed in more detail below. The starting point for extraction 350 is a configurable specification of which memory areas of the embedded system 150 are to be read. Logically, this specification can be written as a list of tuples, each of which specifies a memory address of the corresponding memory area and the length of the corresponding memory area. The memory areas are optionally grouped (also referred to as memory grouping), which is configurable depending on the application. This memory grouping can be relevant for later opening of the data and corresponds to the individual components mk (also referred to as data records) of the input data. mfor the VC process. This requires that either all memory areas of a group (also referred to as a memory group) or none of the group's memory areas are exposed. The larger the number n of memory groups, the finer the grid and the more selectively information can be exposed.

[0151] Each section (also called a group section or "section") of a memory group comprises one or more (e.g., contiguous) memory areas, which may, for example, also have a certain logical relationship to one another. The register file (e.g., of the CPU), for example, forms its own memory group.

[0152] The memory grouping clearly partitions the system state into memory groups, each of which has one or more group sections and / or corresponds to one of the data sets mk. In the exemplary implementation of the memory grouping, a number of n memory groups are formed, each of which has an individual number of lk group sections. The k-th memory group, for example, has lk group sections, where, for example, lk > 1 and / or lk ≠ lk+1 can be, but need not be, the case.

[0153] Once the i-th data set mi (e.g., corresponding to the i-th memory group) has been processed, the i-th intermediate commitment ci is calculated (e.g., using the hash function), which is processed in the vector commitment state (VC_State). If, for example, SHA-256 is used for this purpose, only an additional 64 bytes are required. Such an instantiation of the VC process requires only 128 bytes. Additionally, a constant overhead can be provided for the specific implementation of the SHA-256 function.

[0154] For example, an initial vector commitment state is provided (e.g., using a function V_Init) and updated based on the first determined intermediate commitment c 1 (e.g., using a function VC_Update). The thus updated vector commitment state can be iteratively updated based on each individual determined intermediate commitment ci . The final commitment c is determined based on the last updated vector commitment state and the last determined intermediate commitment cn (e.g., using a function VC_Final).

[0155] Fig.9 illustrates the encryption 305 according to various embodiments 900 in a schematic flow diagram, which may be configured, for example, according to embodiments 300.

[0156] Encryption 305 may, but need not necessarily, run in parallel with determining commitment 310 (e.g., according to embodiments 800). This is particularly useful when both encryption 305 and determining commitment 310 process the same data sets mk or are based on the same storage grouping.

[0157] Optionally, each individual group section can be encoded in such a way that it is a standalone and valid block (e.g., an IHEX block), for example, apart from the missing end-of-file record. For example, each block (e.g., an IHEX block) starts with an extended address so that all information from mi can be uniquely assigned to the respective memory addresses, e.g., without having to see / know other blocks (e.g., IHEX blocks). This approach makes it easier to combine the state data into a complete (e.g., IHEX) encoded state when decrypting it later.

[0158] The encryption 305 or the encryption process 306 is configured to output the system state in encrypted form 312 (also referred to as a cryptogram 312). Together with the state data 302, the plurality of determined opening values ​​d = (d 1 , d 2 ,..., dn ) of the VC process can optionally be encrypted so that they can be transmitted confidentially using the cryptogram 312. Then, the encryption 305 can encrypt the state data 302 and the plurality of opening values ​​into the cryptogram 312.

[0159] As shown, encryption 305 can be performed using encryption process 306. In an exemplary implementation, encryption process 306 or encryption 305 can use Authenticated Encryption with Associated Data (AEAD), for example, the so-called Galois / Counter Mode (GCM) with AES (Advanced Encryption Standard) as the block cipher. This simultaneously ensures the authenticity of the state data and protects its integrity. Authenticity can be verified, for example, by the manufacturer, who has access to the device-specific (e.g., symmetric) encryption key 305s. For public authenticity verification, for example, by an investigator or a court, a signature can optionally be calculated from the read state data (also referred to as signing 307), as will be explained in more detail later.

[0160] According to various embodiments, the encryption key 305s may be a system-specific (e.g., symmetric) key, for example, a key uniquely assigned to and / or stored within the embedded system 150. This may be provided by determining the encryption key 305s based on a master key (e.g., of the manufacturer) and the identity of the embedded system 150, for example, using a key derivation function ("Key Derivation Function" or KDF for short).

[0161] An exemplary implementation of the encryption process 306 can be performed using a (e.g., symmetric) encryption algorithm. The encryption algorithm can, for example, be configured to process the state data 302 block by block, where the state data 302 can optionally be input byte by byte or even bit by bit. Given a complete block, it is processed and the result is returned (e.g., using the AEAD_Update function). Similarly and in parallel, the authentication tag (also referred to as "tag") is calculated, with the associated data initially being included in the calculation, and no intermediate results need to be output.In this case, the associated data has a so-called (e.g., random) moment information (also referred to as "Nonce" or one-time information), which is determined at the start of extraction 350, for example, by means of a random generator (also referred to as RAND).

[0162] For example, an initial AEAD state (AEAD_State) is provided (e.g., via an AEAD_Init), optionally based on the nonce and / or the encryption key 305s. This initial AEAD state is updated based on the first encrypted data record m 1 (e.g., via an AEAD_Update) and subsequently updated with the first encrypted open value d 1 (e.g., via an AEAD_Update). The AEAD state updated in this way can be iteratively updated based on each tuple (mi , di ). The final AEAD state (AEAD_Final) is determined based on the last updated AEAD state. Based on the final AEAD state, the cryptogram 312 and / or the tag can be determined.

[0163] For example, the encryption process 306 is configured to require a number of bytes equal to twice the block length (32 bytes in the case of AES). A constant overhead, which may depend on the precise implementation of the GCM mode, can optionally be additionally provided. In addition, if used, the memory requirement for the encoding (e.g., IHEX encoding) is added. In the case of IHEX encoding, the data is encoded in lines of configurable length. For example, 32 bytes can be encoded per line, resulting in 11 + 64 bytes per line. As with GCM, a constant overhead can also be additionally provided by the specific implementation of the IHEX encoding.

[0164] According to various embodiments, the system state or state data is maintained in the memory area of ​​the embedded system 150 reserved for the forensics module 250, which prevents parts of the system state from being overwritten by the embedded system 150.

[0165] Fig.10 illustrates the signing 307 according to various embodiments 1000 in a schematic flow diagram, which can be configured, for example, according to the embodiments 300. Optionally, the signing 307 can run in parallel with the encryption 305 and / or in parallel with the determination 303 of the commitment 312.

[0166] Unlike encryption 305 (e.g., using AEAD), signature 314 can be publicly verified so that it can be used, for example, by investigators and / or in court. According to various embodiments, signing 307 is configured such that signature 314 enables authentication of extracted state data 302, for example, when it is publicly verified, so that the entire state data 302 does not have to be opened. Optionally, e.g., in contrast to VC process 304, signing 307 can be based on encrypted and / or compressed state data 302 (e.g., a cryptogram ct i based thereon).

[0167] An exemplary implementation of the signature process 308 may include first compressing the state data 302 (e.g., using a hash function H) (also referred to as compression), and then determining the signature 314 based on the result of the compression. For example, an SHA-256 hash function with the 64-byte internal state can be used for compression. Initially, the specified nonce optionally enters the signature process 308. Then, each cryptogram ct i (e.g., ciphertext formed using AEAD) is entered as a block into the calculation of the signature process 308 (e.g., including the finally calculated tag). Finally, the determined commitment 310 is processed. The hash value calculated from it is then signed (e.g., using a "Sign" function).At this point, all data has already been processed, so that the internal state for the actual signing 307 does not have to be added to the memory requirements of the extraction 350.

[0168] For example, an initial hash state (HASH_State) is provided (e.g., using a HASH_Init function), optionally based on the nonce. The initial hash state is updated based on a first determined cryptogram ct 1 (e.g., using a HASH_Update function), which is based on the first data set m 1 . The hash state updated in this way can be iteratively updated based on each determined cryptogram ct i . The final hash value h (HashValue) is determined based on the last updated hash state and the commitment 310. The signature 314 is determined based on the final hash value h and the signature key 307s.

[0169] To promote the authenticity and public verifiability of the state data 302, a key pair (e.g., consisting of a private signature key 307s and a public key) may be provided for signing 307. The public key of the embedded system 150 may, for example, be made available to the investigator.

[0170] Fig.11 1100 illustrates the forensics module 250 according to various embodiments in a schematic configuration diagram (e.g., configured according to embodiments 100 and / or 400). As explained above, the encoding, if performed at all, does not necessarily have to be performed using IHEX.

[0171] The forensics module 250 has the trusted storage area 402, which has first key data implementing the encryption key 305s and / or second key data implementing the signature key 307s. The first key data and / or second key data can comprise the respectively implemented key as plaintext or an executable program code that causes the processor 104, upon execution of the program code, to write the implemented key to the key target area (e.g., provided in the trusted storage area 402). The encryption key 305s ("key", see Fig.9 ) can be used for authenticated encryption 305. The signature key 307s ("sk", see Fig.10 ) can be used for signing 307.

[0172] The encryption 305 provides confidentiality for the state data 302, which makes it possible to keep parts of the system state or the state data 302, for example trade secrets (e.g. IP) of the manufacturer therein, secret.

[0173] In addition, the opening value of the commitment process is also encrypted to maintain the confidentiality of the commitment process.

[0174] The nonce, together with the encrypted state data 302, can be additionally authenticated using AEAD mode. Unlike the signature 314, for example, only the manufacturer can verify the correctness of the tag. The signature 314 is calculated, for example, based on the ciphertext 312 and the commitment 310, as well as optionally the nonce. The signature 314 is primarily used for integrity verification by a third party, such as a court or investigator.

[0175] The manufacturer does not necessarily have to verify the signature 314 because the nonce is already authenticated by AEAD and because the commitment 310 can be recalculated. This is the reason why the nonce can be used as associated data in AEAD.

[0176] The VC process 304 is a particularly advantageous function of the forensics module 250. The VC process 304 enables, for example, protection against a malicious and / or compromised manufacturer. The VC process 304 makes it possible, alternatively or additionally, to publish only individual parts of the system state or the state data 302 (e.g., a single data set), e.g., as needed, e.g., in the event of a legal dispute. Thus, the VC process 304 also indirectly serves to protect the manufacturer's trade secrets as well as the public interest.

[0177] Fundamentally, however, it is also possible, for example in cooperation with the investigator, to disclose the entire system state or the entire state data 302. The investigator can verify whether the state data 302 really originates from the data packet extracted by him from an embedded system 150 (or investigation case) identified by the nonce, e.g., without having to use the manufacturer's secret keys. By partially opening the system state, it is also possible to publish important data pieces, such as malicious code (e.g., malware from the attacker), in court and to cryptographically prove that the state data 302 belongs to the embedded system 150 or the investigation case.

[0178] The forensics module 250 further comprises an additional interface 1102 (also referred to as output interface 1102), wherein the at least one processor 104 is configured to transmit the result of the extraction 350 by means of the output interface 1102 to a system-external destination 1104 (i.e., outside the embedded system 150), e.g., to another computing device. The result of the extraction 350 may comprise the commitment 310, the cryptogram 312, and / or the signature 314. The destination 1104 may, for example, be the extraction trigger and / or be stored by the embedded system 150 (illustratively as a default setting). The output interface 1102 may, for example, be configured as a networking interface, as explained above.

[0179] Extraction 350, which can be initiated during operation, was explained above. A similar process for system startup (also referred to as boot attestation) is explained below.

[0180] Fig.12 illustrates a software stack 1250 of the EGS 150 according to various embodiments 1200 in a schematic structural diagram. The software stack 1250 represents the system state to be determined and has several layers (also referred to as software layers), of which a lowest (e.g., first) layer provides a secured area 1202 of the RoT (also referred to as RoT layer 1202). Furthermore, the memory area 1204 in which the respective software layers are stored is indicated. Each of the software layers can, for example, have parameters (also referred to as program parameters, such as program data) and / or program code.

[0181] The boot attestation described herein allows the reading of the status data 302 to be separated from the attestation (also referred to as authentication). The reading of the status data 302 can occur during the system startup of the EGS 150 (or CPS). The attestation can then be performed as a protocol between the verifier and the EGS 150 at any later time using an application ("app").

[0182] The forensic extraction 350 according to the boot attestation can comprise the (e.g., bit-accurate) reading 301 of the state data 302 (e.g., comprising a memory image) by means of the forensic interface 208, wherein the state data 302 comprises a plurality of data records mk (k = 1...n). In the example shown, n=4. The i-th data record mi can represent the i-th software layer si, e.g., comprising its parameters and / or program code (also referred to as code for short). For example, the i-th data record can comprise the complete content of the i-th software layer si.

[0183] In the exemplary implementation shown here, the lowest (or very first) software layer s 0 (k=0) comprises the RoT layer 1202. The topmost (or very last) software layer sn (k=n) comprises, for example, the system application (also referred to as an "app"), e.g., an EGS application or CPS application. Examples of intermediate layers (n>i>0) include: the bootloader ("BL") or the operating system (e.g., an RTOS). The RoT layer 1202 comprises a so-called root attestation key RK (also referred to as the root attestation key or "root key"), which can be used as the initial attestation key "AK 0 " (also referred to as the reference key AK 0).

[0184] In various embodiments, the root attestation key can be secured by the firewall and / or PCROP. For example, PCROP allows the root attestation key to be protected from internal access in addition to the firewall.

[0185] The system start-up of the EGS 150 can occur in stages according to a corresponding sequence (also referred to as the system start-up sequence). Illustratively, the system start-up sequence can comprise several successively executed stages, of which the i-th stage starts or executes exactly the i-th software layer and / or transfers control of the EGS 150 to it. For example, the system start-up sequence can be implemented by the i-th software layer being configured (e.g., having instructions thereto) to execute the (e.g., immediately) subsequent i+1-th stage of the system start-up sequence (e.g., starting the i+1-th software layer). Of course, the instructions implementing the system start-up sequence can also be provided separately from the software stack 1250.

[0186] The EGS 150 (e.g., the forensics processor 204) is configured to perform an attestation sequence (also referred to as an authentication sequence) during the system boot sequence. The authentication sequence can be implemented as a separate sequence from the system boot sequence or integrated into the system boot sequence and / or the software stack (e.g., as part of the system boot sequence). In an exemplary implementation of the attestation sequence, the i-th software layer is configured to read the (e.g., immediately) subsequent i+1-th software layer and, based thereon, to determine an i+1-th key (also referred to as the i+1-th attestation key). More generally, the i-th software layer can, for example, have instructions to determine the i+1-th attestation key AK i . Of course, the instructions implementing the attestation sequence can also be provided separately from the software stack 1250.

[0187] Later, the application can perform an attestation with the verifier at any time based on the derived nth attestation key AK n, thereby verifying whether the system state was tampered with during the last system boot. The verifier can also, for example, initiate a new system boot (e.g., using the extraction trigger) before an attestation is performed.

[0188] Using the attestation sequence, the software stack 1250 of the EGS 150 can be read during system startup and beginning with a secure RoT, for example, with low requirements for each of the software layers si (i > 0). The attestation itself is then performed by the application, for example, without this functionality having to be specially secured (although this may well be the case). The cryptographic processing ensures that the attestation can be successfully performed (for example, only) if the system state was not tampered with during system startup. Furthermore, if the verifier initiates a system startup (also referred to as a boot process), the attestation can be successfully completed (for example, only) if the boot process is actually performed.

[0189] An example implementation of the authentication sequence or system boot sequence is explained below. The authentication sequence can receive, for example, a nonce NB (also called a boot nonce) as input, which is used as a verification key. The boot nonce can be a number (e.g., a random number) or other random character string that is used only once.

[0190] This boot nonce NB ensures that the auditor can detect if the system restart (also referred to as the reboot process) is suppressed by an attacker. Initially, e.g., when the EGS 150 (or a CPS) is put into operation, a standardized (e.g., stored) nonce can be used as the boot nonce. Before the very first boot attestation, the boot nonce NB can optionally be updated, e.g., set to a new value. Updating the boot nonce can, e.g., be performed using the forensic processor 204 and / or based on information received by the EGS 150 (e.g., specified from outside the system, e.g., by the auditor). The root attestation key may be stored in the RoT layer 1202 as a secret key RK (e.g., on a ROM), which is used individually for the EGS 150 (or a series of EGS 150) and is written during the manufacture of the EGS 150.This root key may be known to the auditor who will perform the attestation.

[0191] The RoT layer 1202 is configured, for example, to instruct the forensics module 250 (e.g., the forensics processor 204) to instruct or even perform the reading of the (e.g., immediately) subsequent software layer (in this example, BL).

[0192] For example, as an intermediate step, a hash value h 1 can be determined using a cryptographic hash function H based on the read data set m 1 of the BL (e.g., comprising code and / or parameters of the BL), for example according to the relation h 1 := H(m 1 ). The data set m 1 of the BL can optionally contain sensor data from the EGS 150.

[0193] Before the RoT layer 1202 transfers control to BL, the first attestation key AK 1 is calculated. The first attestation key AK 1 is based on the root key, optionally the boot nonce, and the first data record m 1 (e.g., the hash value h 1 ), for example, according to the relation AK 1 := KDF(RK,NB,m 1 ) or AK 1 := KDF(RK,NB,h 1 ), where NB can optionally be omitted. KDF can, for example, be a cryptographic key derivation function. The first attestation key AK 1 is now stored for access by the BL, access to the root key is blocked, and control is transferred to the BL.

[0194] This status of the authentication sequence is shown below.

[0195] Fig.13 illustrates the state 1350 of the software stack 1250 (software stack) of the system 150 according to various embodiments 1300 in a schematic flow diagram during the attestation sequence, according to which the first attestation key AK 1 was determined and subsequently additional attestation keys are determined.

[0196] More generally, the extraction 350 may comprise, in 1301, determining, prior to executing the first stage (i=1) of the system boot sequence, a first attestation key AK 1 (also referred to as "Attestation Key 1") using a cryptographic process (e.g., comprising a hash function and / or a KDF) based on the data set m 1 of the first stage (i=1), the reference key AK 0 , and optionally the verification key BN. The cryptographic process may, for example, be the cryptographic key derivation function.

[0197] The attestation sequence may further comprise, in 1303, determining, before executing the i-th stage of the system startup sequence i ∈ {2, ..., n}, an i-th attestation key

[0198] AK i (e.g., denoted by Attestation Key 2 or 3) using the cryptographic process based on the data set mi of the i-th level and the (i-1)-th attestation key AK i-1 .

[0199] In an exemplary implementation, each i-th software layer si (with i ∈ {1, ..., n}, e.g., n = 3 as shown) is configured similarly to RoT. However, for i>2, the i-th attestation key AK i is determined based on the (i-1)-th attestation key AK i-1 instead of the root key, whereupon the (i-1)-th attestation key AK i-1 is securely deleted or overwritten, for example, before being passed to the i-th software layer. The BN is no longer necessarily processed for i>2.

[0200] The determination of the attestation keys can be written similarly to the above relation as: hi := H(mi ), AK i := KDF(AK i-1 ,hi ), or if H is not used as: AK i := KDF(AK i-1 ,mi ).

[0201] The BN ensures that each boot process is unique and that temporary secrets on various software layers that may have been corrupted are rendered useless. This BN is generated, for example, by the extraction trigger (e.g., the verifier) ​​and transmitted to the EGS 150. This ensures that the value of the BN is reset with each extraction.

[0202] After the boot process is complete (e.g., with a freshly selected BN), the software stack 1250 of the EGS 150 can now be verified (e.g., by the verifier). For this purpose, a challenge-response protocol can be implemented between the application and the verifier. The verifier selects a random challenge NV (also referred to as a verifier nonce or PN) and sends it to the EGS 150 as a knowledge request.

[0203] The application responds to this challenge by issuing a proof of knowledge (also called a proof of knowledge) for the attestation key as response r, e.g., in the form of a message authentication code (also called a MAC), e.g., according to the relation r ← MAC(AK n , NV). In addition to this value, the application can transmit both the boot nonce and the results h 1 , ..., h n to the verifier. This can be useful if multiple valid software versions of the EGS 150 exist, and the verifier needs to quickly identify the current version.

[0204] For example, these results h 1 , ..., hn do not necessarily have to be separately secured against manipulation, since the verifier can only use the results h 1 , ..., hn for the assignment, whereas the system state is guaranteed by the cryptographically secured response r to the challenge. Knowing the answer r, the verifier can now, based on its copy of the root key RK, the boot nonce NB and the expected device state (m' 1 , ... ,m' n ) or (h' 1 , ... ,h' n ), perform the same calculations that were performed during the boot process to calculate an AK' n and validate the answer based on this, for example according to the relation Vrfy(AK' n ,NV , r) → b, where AK' n = AK n or (m' 1 , ..., m' n ) = (m 1 , ..., mn ) if b = 1 (or if b fulfills another criterion). The output b can, for example, only take the value 1 or 0.

[0205] The security property of the attestation sequence allows (m' 1 , ..., m' n ) = (m 1 , ..., mn ) if r has been correctly calculated. This security property is favored if one or more than one (e.g., all) of the following criteria are met: H is a collision-resistant hash function; KDF is a (e.g., secure) cryptographic key derivation function; Π = (KeyGen, Mac, Vrfy) is a (e.g., secure) cryptographic MAC process; access to the key RK ← KeyGen (1 λ< ) is exclusive to the RoT; each attestation key AK i-1 is deleted before transferring control to the i-th software layer.

[0206] In an exemplary implementation, the attestation sequence is executed on the selected microcontroller. Furthermore, a firewall is used to protect the root key. For example, before being handed over to the application, the firewall is configured and switched on and set up in such a way that any attempt to access the memory area of ​​the root key is immediately answered by the embedded system 150 being reset by the firewall (e.g., by means of a hardware reset by the firewall), e.g., by executing the reset response. If the functionality of the firewall is fully implemented, e.g., to place code segments that implement the extraction 350 behind the firewall or in the enclave, the root key can still be placed behind the firewall.Optionally, the root key can be additionally secured with a PCROP, which could protect against unintentional access when using the firewall in this way. Alternatively or additionally, the RoT layer (e.g., containing the root key) can be stored in the ROM of the EGS 150 and / or secured by the firewall.

[0207] Examples of input data for the attestation sequence include: the root key (e.g. individual for the EGS 150) for the EGS 150 to be verified, a freshly generated boot nonce, the state data 302 representing the expected firmware, and optionally additional data to be verified by the attestation sequence.

[0208] As an example, the option bytes can be used as additional data.

[0209] The input data of the attestation sequence is used to derive the attestation key. Once the very last attestation key AK n has been generated, it can be verified. For this purpose, a challenge is generated for the EGS 150. Before attestation can be performed, the previously generated boot nonce can be sent to the EGS 150. The EGS 150 receives the instruction to restart the software along with the boot nonce (in practice, this can be done differently). During the restart, the boot nonce is used to determine the attestation key AK n, and after the restart is complete, the application reports, for example, with the new boot nonce. The actual attestation is performed after the restart. The new challenge is sent to the EGS 150.For example, the EGS 150 can only answer the challenge correctly if a reboot with the specified boot nonce was performed beforehand and the actual system state of the EGS 150 (also referred to as the actual system state) corresponds to the expected system state (also referred to as the target system state).

[0210] The emulation system is discussed in more detail below.

[0211] Fig.14 illustrates an emulation system 1450 according to various embodiments 1400 in a schematic configuration diagram. The emulation system 1450 is configured to emulate the EGS 150 system, which includes the embedded processor 104 and the at least one sensor 110 and / or at least one actuator 112.

[0212] The emulation system 1450 has a digital interface 1410 for receiving the (e.g., decrypted) status data 302, a (physical) communication interface 1408 (also referred to as a peripheral interface) to at least one sensor 1408s (also referred to as an emulation sensor 1408s) and / or at least one actuator 1408a (also referred to as an emulation actuator). The or each emulation sensor can be identical to the respective sensor 110 of the EGS 150 or at least an emulated representation thereof. The or each emulation actuator 1408a can be identical to the respective actuator 112 of the EGS 150 or at least an emulated representation thereof. For example, one or more than one sensor 110 and / or one or more than one actuator of the EGS 150 can be emulated as emulation actuator 1408a or emulation sensor 1408s, respectively. For example, the emulation actuator can represent a motor of the EGS 150 (e.g., identical to orat least an emulated representation of it).

[0213] The emulation system 1450 further comprises at least one processor 1404 (also referred to as an emulation processor) configured to emulate the EGS 150. For example, the emulation system 1450 or the emulation processor may be configured to emulate a component of an ATM as the EGS 150, e.g., one of the following components of the ATM: a cassette (e.g. cash cassette), a reading device (e.g. for reading an RFID chip, a credit card, a smart card or similar), a printer, a camera, a network device (e.g. a network card), a transport device (e.g. for transporting banknotes or other valuable documents), a validation device (e.g. in an ATM), a dispensing device (also called a dispensing module), a deposit device, a user interface (e.g. having a PIN pad, a keyboard, a touchscreen or similar), e.g. an encrypting PIN keypad.

[0214] The emulation processor 1404 is further configured to communicate by means of the communication interface 1408 in the same way as the embedded processor 104 communicates by means of the functional interface 108, e.g., with the at least one sensor 110 or at least one actuator 112 of the EGS 150.

[0215] The emulation system 1450 further comprises a storage device 1402 (e.g., comprising one or more than one data memory 102s, 112s).

[0216] The emulation system 1450 further comprises a communication infrastructure 1406 (e.g., comprising a CAN bus or other field bus) which couples at least the memory device 1402, the emulation processor 1404, the digital interface 1410, and / or the communication interface 1408 to one another.

[0217] Optionally, the emulation system 1450 may be configured to reconstruct the system state based on the state data 302 (also referred to as reconstruction or recovery), e.g., in handler mode. Reconstruction may, for example, include reconstructing the processor register (e.g., CPU register) and / or peripheral register.

[0218] Reconstruction in handler mode provides extended privileges that are beneficial for the execution of certain instructions and can occur, for example, if the CPU registers were also saved in handler mode. To continue the code at this point after reconstruction, the CPU can be in the same mode. This ensures that reconstruction with the appropriate code to exit handler mode is executed correctly. The corresponding exception to enter handler mode can be triggered (e.g., instructed) by writing the interrupt control and state register (ICSR), either by software from thread mode or by the debugger.

[0219] For this purpose, the forensics module 250 can install the corresponding interrupt handler. Writing the ICSR triggers a non-maskable interrupt (NMI).

[0220] For example, the reconstruction may include one or more of the following: Resetting the protection mechanisms; reconstruction of the persistent flash memory; reconstruction of the volatile RAM memory; reconstruction of one or more peripheral registers; reconstruction of one or more processor registers.

[0221] To reconstruct and read the flash memory, the option bytes can first be activated at RDP Level 0. This automatically erases the flash memory when transitioning from Level 1 to Level 0. In the EGS 150, the option bytes can be at Level 2 to completely deactivate the debug interface. If the debug interface of the emulation system 1450 is to be activated, Level 2 can also be emulated by Level 1. This may require a patch of the corresponding option bytes before they are programmed in the next step. The contents of the flash memory according to the state data 302 can then be programmed into the emulation system 1450. This can be done, for example, using OpenOCD. For example, the flash memory can be partitioned in such a way that the functionality for reconstructing the processor register (e.g.CPU Core Register) as part of the Forensics Module 250 is located in a flash memory area that does not necessarily have to be physically present in the MCU of the EGS 150. Thus, programming the memory image does not overwrite the Forensics Module 250.

[0222] According to the state data, the RAM can contain the following data, which can be automatically reconstructed by loading the RAM background: stack, heap, register file (e.g., CPU register file). The RAM can be written directly by a debugger, for example. The emulation system 1450 can be configured in advance so that after reconstructing the RAM and peripheral registers, the code for reconstructing the processor register (e.g., CPU register) is executed immediately. Writing the ICSR can trigger an NMI, thus setting the CPU into handler mode. This jumps to the NMI exception handler that the forensics module 250 has installed accordingly. This makes it easier for the CPU to continue in handler mode after reconstruction if the memory dump was executed within an interrupt handler in handler mode. The RAM contents can then be reconstructed using a restore command.

[0223] The peripheral registers are mapped into the MCU's address space. Like flash memory and RAM, they can initially be mapped from the extracted state into a separate file. An exception to this is the status registers, which in some cases cannot always be written via the software interface; their contents can only be modified by manipulating the hardware. For example, the input register of an IO pin reflects the state of the pin and can often only be modified by applying a corresponding potential to the pin itself. A peripheral emulator can be used to reconstruct the state of such registers.

[0224] Unlike peripheral registers, processor registers cannot necessarily be written directly. In this case, they are written using dedicated processor instructions (e.g., CPU instructions).

[0225] After the processor registers have been reconstructed, the exception handler can be exited and the system state can be set to the correct program code address. This can be done, for example, by loading an exception return or return address. This causes the CPU to exit handler mode and load the exception frame from the stack.

[0226] An exemplary emulation system 1450 is configured to emulate relevant components of the EGS 150, including, for example, the memory device 102, the embedded processor 104, the communication infrastructure 106, and / or the interface 108. For example, at least the embedded processor 104 and the interface 108 may be emulated.

[0227] The following explains the emulation of the EGS 150 using the EGS 150 MCU as an example. It should be understood that the description can apply analogously to a differently implemented EGS 150. The MCU of the 1450 emulation system (also referred to as the emulation MCU) emulates the EGS 150 MCU. The emulation MCU can, for example, be a development version of the EGS 150 MCU, as used for functional error analysis. The emulation MCU includes, for example, one or more of the following components: A debug port. The EGS 150 MCU often does not have an enabled debug port; for example, it is omitted or disabled for security reasons. The emulation MCU, on the other hand, has an enabled debug port. Optionally, the emulation MCU can have extended debug functionality, such as a trace module. Random access memory (RAM): The RAM of the emulation MCU is at least as large as the RAM of the EGS 150 MCU. If the emulation MCU has more random access memory than the EGS 150 MCU, this RAM can be hidden for emulation or not used. The flash memory of the emulation MCU is at least as large as the flash memory of the EGS 150 MCU.If the emulation MCU has more flash memory than the EGS 150 MCU, this can be used to implement additional emulation functionality, such as additional interrupt handlers and CPU register reconstruction. One or more 1408 peripheral interfaces: The peripheral blocks of the EGS 150 MCU are often tailored to the specific application for cost reasons. The emulation MCU can have additional peripheral blocks. This allows for more flexible use of the emulation for different hardware configurations and applications.

[0228] The emulation MCU can be controlled from the analysis PC via a debug adapter. This allows for step-by-step execution of the program code, setting breakpoints, memory analysis, and more.

[0229] The peripheral emulator 1502 (also referred to as a peripheral emulator or "peripheral emulation") includes hardware for controlling the hardware interfaces of the emulation MCU. Depending on the target system, the peripheral emulator may include, for example, one or more bus systems (e.g., multiple different bus systems), one or more digital inputs, and / or one or more analog inputs. In a specific instantiation, the peripheral emulator includes one or more of the following components: A control unit configured as an interface (also referred to as an analysis interface) to the analysis PC. The control unit may, for example, have an additional MCU running a real-time operating system. A real-time module configured as a port extension and / or for implementing time-critical processes. The real-time module is implemented, for example, by an FPGA ("Field Programmable Gate Array") and can thus respond precisely to signals from the emulation MCU and simulate case-specific attacks. Furthermore, an FPGA offers greater flexibility for dynamically implementing EGS 150 components. The real-time module can, for example, be controlled by the control unit. Optionally, the real-time module can be supplemented by a function generator for emulating analog signals. The outputs are configured directly by the analysis PC.Synchronization is achieved, if desired, by a signal from the control unit or the FPGA. One or more interfaces may have special interface modules, such as a CAN bus controller ("Controller Area Network Bus Controller") or a USB controller ("Universal Serial Bus Controller"), for example, if these are not implemented by the control unit's MCU. This allows them to be synchronized with other signals by the real-time-capable MCU of the peripheral emulator and does not need to be implemented separately in the FPGA.

[0230] An exemplary implementation of the emulation system 1450 for a generic EGS 150 (e.g., for an STM32L476-based CPS) may include, for example, an STM32L476 Nucleo development board with an STM32L4 MCU. An exemplary implementation of the emulation system 1450 for a manufacturer-specific EGS 150 may include, for example, a manufacturer-specific development board with a Cortex M4 MCU and

[0231] peripheral emulator. These two exemplary implementations are compared below: Komponente Generische Emulation Auszahl Emulation CPU Core Arm Cortex-M4 Arm Cortex-M4 Debug Schnittstelle SWD JTAG Debug Probe ST-LINK V2 Green Hills Probe Debugger Gnu Debugger (GDB) Green Hills TimeMachine Debugger Peripherie Emulator Funktionsgenerator Rigol DG4162 FPGA und Rigol DG4162

[0232] In a more complex implementation, the emulation system 1450 may be configured to perform an automatic analysis of the result of the extraction 350. This is explained below.

[0233] The 1450 emulation system can be configured: Import the (e.g., decrypted) state data 302, e.g., comprising a register file, into "Ghidra" or another reverse engineering module; specify the architecture of the EGS 150 to be emulated (e.g., comprising an Arm v8 CPU core, little endian). Perform an automatic analysis of the state data 302 using "Ghidra," e.g., comprising a static analysis of the program code.

[0234] Fig.15 illustrates an analysis system 1550 according to various embodiments 1500 in a schematic structural diagram and a detailed view 1501, which comprises the emulation system 1450 according to the embodiments 1400 (e.g., a CPS emulation system, CPS emulation for short).

[0235] The emulation system 1450 can be provided, for example, via an emulation board. The emulation system 1450 emulates, for example, the MCU of the EGS 150 (or CPS) and its peripherals (e.g., having one or more sensors and / or actuators). The emulation system 1450 is used to execute the malicious code to be analyzed, if present, and offers extended functionalities, such as one or more debug interfaces and peripheral components.

[0236] The system PC of the analysis system 1550 (more commonly referred to as an environment emulation device) emulates the system PC of the attacked device (e.g., an ATM) that has the EGS 150 or CPS. In addition to the actual functionality of a "normal" system PC, the system PC of the analysis system 1550 is configured to execute additional analysis software.

[0237] The analysis PC is configured to control the remaining components of the analysis system 1550. For example, the required software for incident analysis is executed on the analysis PC and the result of the extraction 350 (e.g., the status data 302) is stored.

[0238] The USB analyzer (also referred to as USB analysis device) is configured to analyze the USB communication between the components of the analysis system 1550, for example, the system PC and the emulation system 1450. The USB analyzer may, for example, be configured to record, manipulate, and / or play one or more messages of the USB communication.

[0239] The CAN bus analyzer is configured to analyze CAN bus communication (or more generally, communication via the communication infrastructure 1406 of the emulation system 1450). The analyzer offers the ability to record, manipulate, and / or externally import one or more messages transmitted via the communication infrastructure 1406.

[0240] The function generator is configured for synchronous emulation of sensor signals. For example, the analysis PC is configured to use the function generator to specifically input a signal synchronously with the CPS program flow.

[0241] The optional oscilloscope is set up to analyze peripheral and bus signals and to synchronously control the function generator.

[0242] An (optionally controllable) laboratory power supply (not shown) is configured to supply power to the 1450 emulation system. If the laboratory power supply is controllable, a power failure or other power-related attack can be emulated by controlling the laboratory power supply (e.g., using the analysis PC).

[0243] The debug probe implements the debug protocols of the EGS 150 MCU (for example, a so-called Joint Test Action Group (JTAG) or Single Wire Debug (SWD)) and connects the MCU of the 1450 emulation system to the analysis PC.

[0244] An exemplary implementation shows the instantiation of the USB analyzer using "ellisys USB Explorer 200", the instantiation of the oscilloscope using "Lecroy

[0245] WaveRunner 640Zi", the instantiation of the function generator using "Rigol DG4162", the instantiation of the CAN bus analyzer using "Ixxat USB-to-CAN" and the instantiation of the debug probe using "STLink 2, Greenhills Probe".

[0246] In addition to the hardware components, the analysis system 1550 also has one or more of the following software components for controlling the hardware and for analyzing the malicious code in interaction with the hardware: An interactive disassembler (IDA) is configured to statically analyze the binary code. This includes converting it into program code, displaying the execution graph, or analyzing references between program code and program data. In this example implementation, "Hexrays IDA Pro" and / or "Ghidra" can be used. A so-called "binwalk" is a tool for statically analyzing binary data, for example, to extract embedded certificates or program code. An analysis tool (also referred to as a wariness analysis tool) implements various utilities for analyzing a malware image. A debugger is configured to control the execution of the firmware in the emulation system 1450 (e.g., CPS emulation). The debugger is coupled to the MCU of the emulation system 1450 via the debug probe.This allows, for example, step-by-step execution of the program, setting breakpoints, and inspecting and modifying the MCU's memory contents. Depending on the application, a GNU debugger in combination with "Open OCD" or the "Green Hills Time Machine" can be used.

[0247] The debug interface of the 1450 emulation system can be used for reconstruction. This allows programming of FLASH memory and writing to and reading from RAM and registers. The peripheral registers are memory-addressable. Processor registers, for example, can only be accessed indirectly via special instructions.

Claims

1. Forensics module (250) for an embedded system (150), the forensics module (250) comprising: • a protected storage area (202s) comprising first data which implement a key (305s); • an interface (208) for reading out (301) second data (302) representing a system state of the embedded system (150); and • one or more than one processor (204) which is configured to: • read out (301) the second data (302) by means of the interface (208), wherein the second data (302) comprise multiple data sets; • determine (303) a commitment (310) to multiple opening values, each of which opening values is assigned exactly to one of the multiple data sets, based on the second data (302) and using a cryptographic commitment process configured in such a way that each data set can be verified individually using the commitment (310) and the respectively associated opening value; • encrypt (305) the second data (302) and the multiple opening values using the key (305s).

2. Forensic module (250) according to Claim 1, wherein the commitment process implements a cryptographic, preferably collision-resistant, hash function, by means of which the commitment (310) is determined.

3. Forensic module (250) according to Claim 1 or 2, wherein the commitment process is a vector commitment process.

4. Forensic module (250) according to any one of Claims 1 to 3, wherein the commitment (310) is bound to the multiple opening values and / or the second data (302).

5. Forensic module (250) according to any one of Claims 1 to 4, further comprising: • an additional interface (208), • wherein the one or more than one processor (204) is further configured to output the encrypted second data (302) and the commitment (310) by means of the additional interface (208).

6. Forensic module (250) according to any one of Claims 1 to 5, wherein the encryption is performed using the key (305s) by means of a symmetric encryption process.

7. Forensic module (250) according to any one of Claims 1 to 6, wherein the encryption is performed using the key (305s) by means of an authenticated encryption process.

8. Forensic module (250) according to any one of Claims 1 to 7, wherein the encryption includes using the key (305s) to iteratively encrypt the multiple data sets.

9. Forensic module (250) according to any one of Claims 1 to 8, wherein the storage area is protected by means of one or more than one of the following: • a firewall; • a storage protection unit • write protection; and / or • read protection.

10. Forensic module (250) according to any one of Claims 1 to 9, wherein the determination (303) of the commitment (310) includes determining the multiple opening values, preferably by means of a random value generator.

11. Forensic module (250) according to any one of Claims 1 to 10, wherein the interface (208) is configured to read out a processor register of the embedded system (150), wherein the second data (302) are preferably read out (301) from the processor register by means of the interface (208).

12. Forensic module (250) according to Claim 11, wherein the second data (302) comprise an image of the processor register of the embedded system (150).

13. Forensic module (250) according to any one of Claims 1 to 12, wherein the commitment and the encryption (305) of the second data are determined (303) simultaneously.

14. Forensic module (250) according to any one of Claims 1 to 13, wherein the interface (208) is further configured to stop the embedded system (150), preferably the processor (204) thereof, and the second data (302) are read out from the stopped embedded system (150).

15. Embedded system (150), comprising: • the forensic module (250) according to any one of Claims 1 to 14; and • one or more than one additional storage area (102s, 112s), wherein the interface (208) is configured to read out the second data (302) from the one or more than one additional storage area (102s, 112s); • wherein preferably the one or more than one additional storage area (102s, 112s) comprises a processor register.

16. Embedded system (150) according to Claim 15, further comprising: • an actuator (112) and / or a sensor (110); and • preferably firmware for controlling the sensor and / or the actuator, wherein the firmware is stored on the one or more than one additional storage area (102s, 112s).

17. Cash machine, which comprises the embedded system (150) according to Claim 15 or 16.

18. Cash machine according to Claim 17, wherein the embedded system (150) is configured to provide a function of the cash machine • in connection with a deposit, holding and / or withdrawal of a document of value, and / or • in conjunction with the authentication of a person.

19. Method for an embedded system (150), the method comprising: • reading out (301) data (302) representing a system state of the embedded system (150) by means of an interface (208) which is configured to read out the data, wherein the data (302) comprise multiple data sets; • determining (303) a commitment (310) to multiple opening values, each of which opening values is assigned exactly to one of the multiple data sets, based on the data (302) and using a cryptographic commitment process, which is configured in such a way that each data set can be verified individually using the commitment and the respectively associated opening value; • encrypting (305) the data (302) and the multiple opening values using a key (305s) which is implemented by means of additional data stored in a secured storage area (202s).

20. Non-volatile storage medium comprising code segments which are configured, when executed by a processor (104, 204), to cause the processor (104, 204) to carry out the method according to Claim 19.