Device, method and computer program for securing diagnostic data

Abstract

Embodiments according to the present disclosure include a device for securing diagnostic data relating to the operation of a computing unit, wherein the device comprises an interface and a security unit. The interface is configured to receive the diagnostic data of the computing unit. The security unit is configured as a hardware structure that can be operated separately from the computing unit. Furthermore, the security unit is configured to secure the diagnostic data using session keys and to provide a switch between session keys (re-keying) independent of the operation of the computing unit.

Description

Technical field

[0001] Exemplary embodiments according to the present disclosure include devices, methods and computer programs for securing diagnostic data.

[0002] Exemplary embodiments include, in particular, devices and methods for buffering or storing trace session keys. Background of implementation examples

[0003] Modern microcontrollers feature a comprehensive debug and trace subsystem for system analysis in the event of unexpected behavior. The former provides invasive control of the system with the ability to halt program execution, while the latter offers non-invasive insight into program execution and system internals. Today, the debug and trace subsystems are functionally separated, allowing each to be used independently. This separation enables the use of the trace subsystem even in deployed devices where, in safety-critical applications, an activated debug subsystem would pose a serious security risk and could also compromise security measures implemented in the end system.

[0004] In installed systems, the debug subsystem is either disabled, password-protected, or requires some other form of authentication before it can be activated. This is not necessarily the case for the trace subsystems. Furthermore, the trace data is even transmitted from the device in plaintext. A typical trace subsystem does not use any security features for data transmission.

[0005] Given that a trace system can generate a large amount of data in a very short time, modern microcontrollers utilize existing Ethernet MAC peripherals to transmit trace data with high bandwidth. This can also be implemented in production equipment integrated into an end system operating in the field. The system in question is connected to an internal communication network, which is then accessible externally via a gateway. Currently, this data is not encrypted, meaning anyone with access to the internal network can intercept the transmitted data. This data may contain personal information, system locations, secrets, and other sensitive information where confidentiality is paramount.

[0006] Therefore, there is a need for an improved concept for using trace data, which offers an improved compromise in terms of data security, hardware and computing complexity, and robustness of the concept.

[0007] Such a concept is provided by means of the subject matter of the independent patent claims. Further developments according to exemplary embodiments are defined by reference to the dependent patent claims. Summary of implementation examples

[0008] Embodiments according to the present disclosure comprise a device for securing diagnostic data relating to the operation of a computing unit, wherein the device has an interface and a security unit. The interface is configured to receive the diagnostic data of the computing unit. The security unit is configured as a hardware structure that can be operated separately from the computing unit. Furthermore, the security unit is configured to secure the diagnostic data using session keys and to provide a switch between session keys (re-keying) independent of the operation of the computing unit.

[0009] Diagnostic data can include, in particular, trace data (i.e., data for tracking) and / or debug data (i.e., data for troubleshooting) relating to the operation of the processing unit. Diagnostic data can therefore be, for example, log data or, in particular, on-chip trace data. Diagnostic data includes, for example, raw data that allows conclusions to be drawn about a state or sequence of states of the processing unit, or already processed and, in particular, interpreted data from which diagnostic or troubleshooting information regarding the operation of the processing unit can be derived. Diagnostic data can therefore include, in particular, data for analysis or already analyzed data relating to the operation of the processing unit, for example, in the form of monitoring data.The data may, for example, be automatically generated by the computing unit during operation. The diagnostic data may therefore include data that is not inherently necessary for the operation of the computing unit. This data could, for instance, be a type of metadata used to characterize and / or evaluate the operation of the computing unit.

[0010] The security unit is, for example, designed to authenticate and / or encrypt the diagnostic data. Optionally, the security unit can be designed to authenticate and / or encrypt the diagnostic data only, or to both authenticate and encrypt it. The security measures can include, in particular, "authentication-only" and / or "authenticated encryption (AEAD)" operation.

[0011] These exemplary implementations are based, firstly, on the idea of ​​securing the diagnostic data using session keys. The use of session keys enables reliable authentication and / or encryption of the diagnostic data to prevent unauthorized access and / or ensure its authenticity. Furthermore, it was recognized that diagnostic data, and thus in particular its transmission and evaluation, is of great importance, especially in the event of a failure of the processing unit. It was also recognized that in such a failure, the processing unit can no longer be relied upon to secure the diagnostic data. Therefore, these exemplary implementations include the security unit in the form of a hardware structure that can be operated separately from the processing unit, and thus, optionally, implemented separately.This ensures that diagnostic data remains reliably protected even in the event of an error. Furthermore, it was recognized that, particularly in the context of diagnostic data, switching between individual session keys to secure the data is a key aspect for the secure and robust operation of the protection system.

[0012] Therefore, the security unit is designed to ensure, in particular, that session keys can be switched independently of operation, i.e., independently of the state of the computing unit. Reliable session key switching prevents correlations in the secured diagnostic data that could allow an attacker to deduce the diagnostic data and / or session keys. Specifically, the approach, as described in the exemplary implementations, enables the use of efficient and / or simple authentication and / or encryption mechanisms, such as those based on noncens (one-time use numbers), due to the robust and error-free switching between session keys.For example, a nonce can be provided with a simple counter register, whereby the simplicity of the provisioning does not lead to a vulnerability of the security due to the secure switching between session keys.

[0013] Examples of implementations are based, among other things, on the use of stored diagnostic data session keys, e.g., in the case of trace data, "buffered trace session keys". Character description

[0014] Exemplary embodiments according to the present disclosure are explained in more detail below with reference to the accompanying figures. With regard to the schematic figures shown, it should be noted that the functional blocks depicted are to be understood both as elements or features of the device according to the disclosure and as corresponding process steps of the disclosed method, and corresponding process steps of the disclosed method can also be derived from them. The figures show: Fig. 1 a schematic view of a device for securing diagnostic data according to exemplary embodiments; Fig. 2 a schematic view of a system according to exemplary embodiments; Fig. 3 a schematic overview of use cases from the automotive sector regarding debug and / or tracing functionality according to exemplary implementations; Fig. 4 a schematic view of a microcontroller, MCU, according to exemplary embodiments; Fig. 5 schematic views for securing diagnostic data according to exemplary implementations in the form of authenticated encryption with associated data; Fig. 6 schematic views of possible attacks on a security system, which can be countered by means of exemplary implementations; Fig. 7. An example of a sequence diagram for the acquisition of diagnostic data, as an example in the form of trace data, according to exemplary implementations; Fig. 8 a schematic view of an ECU system according to exemplary embodiments; and Fig. 9 A schematic view of a sequence diagram for capturing trace data. Detailed description of the embodiments according to the figures

[0015] Before the following exemplary embodiments are explained in detail with reference to the drawings, it should be noted that identical, functionally equivalent or equivalent elements, objects and / or structures in the different figures are provided with the same or similar reference numerals, so that the description of these elements shown in different exemplary embodiments is interchangeable or can be applied to each other.

[0016] Fig. Figure 1 shows a schematic view of a device for securing diagnostic data according to exemplary embodiments. Fig. Figure 1 shows the device 100 for securing diagnostic data relating to the operation of a computing unit 200. The device has an interface 110 and a security unit 120.

[0017] Interface 110 is configured to receive information 101 regarding diagnostic data from the processing unit 200 and forward it to the security unit 120 in the form of information 121, which may be identical to information 101 or correspond to a processed form (e.g., a decoded form) of information 101. Information 121 may therefore be in a form of data 101 that has been preprocessed by interface 110, for example, converted. Furthermore, information 101 and / or 121 may also be the diagnostic data itself.

[0018] The security unit 120 is designed as a hardware structure that can be operated separately from the computing unit 200. Furthermore, the security unit 120 is designed to secure the diagnostic data using session keys and to provide a switch between session keys independent of the operation of the computing unit 200.

[0019] As previously explained, the diagnostic data in information 101 and 121 can, for example, be trace data and / or debug data relating to the operation of the computing unit 200. Securing this data using the security unit includes, for example, authentication, encryption, or both authentication and encryption.

[0020] It should be noted at this point that in Fig. One further optional feature, which will be explained below, is shown with a dashed line.

[0021] Optionally, the security unit 120 is configured to pre-calculate and maintain session keys independently of the operation of the computing unit 200, for example, using an OTP approach (OTP = One-Time Pad), or to calculate them. In other words, the security unit 120 can be configured not only to perform a session key change to secure the diagnostic data, but also to determine the session keys themselves. Thus, the calculation of the session keys and the securing of the diagnostic data can be performed independently of the computing unit's state, specifically regardless of whether the computing unit is in an error state or not. This enables robust protection of the diagnostic data.

[0022] In such an optional configuration, the security unit 120 can also be configured, for example, to calculate the session keys during the generation of diagnostic data. This calculation can be performed, for example, using a key derivation function (KDF). Thus, the session keys can be calculated robustly and without errors during the operation of the computing unit 200.

[0023] If calculating the keys is too time-consuming or resource-intensive, session keys can also be pre-calculated and stored securely in non-volatile memory. This can be done, for example, during the development phase in the lab or during production.

[0024] As an optional feature, the device 100 in the example of Fig. 1. Additionally, a memory 130 is provided. Memory 130 can be configured to store the session keys, e.g., exchanged via information 131, for securing the diagnostic data. Furthermore, the security unit 120 can, in this case, be configured to read the session keys from memory 130 independently of the operation of the processing unit 200. Accordingly, interface 110 can, for example, be configured to obtain the session keys before generating the diagnostic data or, for example, before securing the diagnostic data, e.g., via information 102 and forwarding them via information 121, and to provide them to memory 130 for storage.

[0025] The security unit 120 can, for example, retrieve session keys from memory 130, including information 131. In an optional configuration, the security unit 120 can be designed to store session keys calculated by the security unit 120 in memory 130, for example, for later use. Using memory 130 enables efficient storage of session keys, particularly independent of when the session keys are generated and also independent of whether the session keys are provided by the device 100 itself or by an external unit, such as the computing unit 200, for example, before the diagnostic data is generated.

[0026] Optionally, the security unit 120 can be specifically designed to calculate the session keys before the start of the generation of the diagnostic data to be secured concerning the operation of the computing unit 200 and to store them in the memory 130.

[0027] As a further optional feature, interface 110 can be configured to receive additional information from the processing unit 200, for example, as part of information 101, or from an external unit, for example, as part of optional information 102. This additional information can include, for example, information about the duration and / or volume of the diagnostic data. Optionally, the security unit 120 can be configured to determine or calculate the session keys based on such additional information, specifically information about the duration and / or volume of the diagnostic data. This information can, for example, be used to determine the number of session keys to be calculated.

[0028] Examples of this implementation optionally include security using incrementally generated noncens. In other words, the security unit 120 is optionally configured to encrypt the diagnostic data using incrementally generated values ​​from a limited range of numbers, where the values ​​serve, for example, as noncens for encryption. The security unit 120 is then optionally configured to perform a switch between session keys before or when the incrementally generated values ​​reach an end of the limited range of numbers or would exceed the end of the limited range through incrementing.

[0029] For example, if the security measures involve the use of a nonce generated by cyclic incrementing, the duration and / or volume of diagnostic data can be used to determine how often the nonce incrementing leads to an overflow, thus requiring a key change to prevent the duplicate use of a nonce key pair. Furthermore, this additional information can include at least one piece of information concerning the start of diagnostic data recording, a diagnostic data configuration, the content of the diagnostic data, and / or the type of diagnostic data. Such information, for example, 102, can be provided by a debug interface. This could be, in particular, a debug host system interface that provides such additional information.The debug interface can therefore be used, in particular, to determine what is "written out".

[0030] As a further optional feature, the interface 110 can be configured to provide the computing unit 100 with a signal 103 to start recording the diagnostic data.

[0031] The following section discusses exemplary embodiments, including their integration into systems as disclosed. Furthermore, additional optional functionalities and details of embodiments are also explained. In other words, a device can be configured accordingly. Fig. 1. For example, it may be part of one of the systems described below and / or have one or more of the functionalities described below. The following explanations focus particularly on diagnostic data in the form of debug and / or tracing data (also referred to herein as trace data), but are not limited to one or the other data form. This means that, for example, corresponding functionalities explained in the context of trace data should be understood equally or analogously with regard to debug data. The same applies conversely to explanations regarding functionalities with respect to debug data for functionalities with respect to trace data.

[0032] The same applies to security, which, as explained above, can include authentication and / or encryption. This means that device features discussed in the context of encryption, for example, should be understood equally in terms of the functionality of security, i.e., generally any combination of authentication and encryption.

[0033] Fig. Figure 2 shows a schematic view of a system according to exemplary embodiments, in which, for example, a device according to Fig. 1 can be embedded. Such a system includes, for example, a host interface 210, for example JTAG, a host-controlled bus master 220, an on-chip trace 230, a CPU 240, buses 250, and a direct memory access (DMA) 260. The CPU 240, buses 250, and DMA 260 include, for example, observation blocks 270.

[0034] Based on Fig. 2. The following section will explain the fundamentals of debugging and tracing functionalities using examples: Debugging describes, for example, the invasive control and observation of system resources. Tracing describes, for example, the non-invasive observation of system resources, such as without influencing program execution.

[0035] Key components for such a system, for example a debug and / or tracing system, include those described above. Fig. 2, namely the three main components: • Host system interface (Host system interface) 210, for example in the form of a debug interface, such as JTAG (Joint Test Action Group), SWD (Single Wire Debug from ARM) or DAP (Debug Access Port from Infineon), • Host-controlled access method, for example Cerberus (CBS) or DAP-AP (Debug access port of ARM) as well as • one or more observation blocks 270, for example OCDS (On-Chip Debug Support).

[0036] Additionally, reference should be made here to the on-chip Trace 230.

[0037] A key feature, at least in some implementations, for example in modern automotive microcontrollers, is a comprehensive debug and trace subsystem that is functionally separated to allow independent use. Such a trace subsystem can therefore be used, for example, in a deployed device, even in safety-critical applications.

[0038] Fig. Figure 3 shows a schematic overview of use cases from the automotive sector with regard to debug and / or tracing functionality according to exemplary implementations. Fig. Figure 3 shows, as an example, debugging and / or tracing processes in different development phases of software and / or hardware. Early software development (e.g., pre-silicon) can be carried out, for example, using a microcontroller (e.g., AURIX®) emulator (e.g., ZeBu or Virtualizer from Synopsys) 310.

[0039] For example, subsequent standard software development can be carried out using evaluation and development kits (Development Kit) 320 and a test bench.

[0040] In field use, for example with a corresponding vehicle (Vehicle) 330, diagnostic processes (e.g. Remote Vehicle Diagnosis) can then be carried out remotely or even exclusively remotely in a subsequent development stage.

[0041] For debugging and / or tracing, the debug / trace tool 340 can be used, which can optionally have a Tool Access Service (TAS) interface or a corresponding server. Communication with a corresponding emulator 310 can be provided, for example, via an Ethernet connection 311.

[0042] With regard to debugging and / or tracing for a corresponding development kit 320, it is also possible, as optional features in Fig. Figure 3 shows that an exchange of information with a debugging probe 322 is implemented using a debug access port and / or a JTAG (Joint Test Action Group) 321 and a USB connection 323.

[0043] In a corresponding vehicle 330, for example as a final product, a corresponding hardware component 331, for example corresponding to the development kit 320, can be permanently installed and be connected to a central server 333 via an Ethernet connection 332 in order to provide corresponding data via a TCU 334 (TCU = Telematic Control Unit) via a wireless connection 335.

[0044] Examples of implementation, for example in an implementation according to Fig. 1 (with or without the optional ones, in Fig. The features shown in Figure 1 enable the use of the same software infrastructure for diagnostic applications from early development phases (see, for example, Emulator 310) up to wireless monitoring or wireless diagnostics in the final product, such as Vehicle 330, including field applications. These implementation examples also allow access to and / or the use of software from suppliers and / or original equipment manufacturer (OEM) software for prototypes. In other words, software from different manufacturers can be used on the same device.

[0045] Reference is made to Fig. 4. Fig. Figure 4 shows a schematic view of a microcontroller (MCU) according to exemplary embodiments. The microcontroller 400 comprises a CPU 410 (e.g., with virtual cores VM), and a unit 420 (e.g., a tracing unit, for example, for Highest Active Labeled Event System Trace) comprising a multicore debug solution unit 421, a security unit (crypto) 422, here, for example, an encryption unit, and a memory (TBUF) 424. Furthermore, the microcontroller 400 includes a debug access port 430 and a media access control unit 440. As a further optional feature, the MCU includes a standard interface, e.g., an SGBT unit 450.

[0046] Based on Fig. Section 4 below will explain the problem of a trace subsystem according to the following examples. A trace subsystem can generate a large amount of trace data in a very short time. Such data can, for example, be forwarded from the CPU 410 to the MCDS (MultiCore Debug Solution) 421. To output the data (e.g., in the form of a data stream), an existing Ethernet MAC 440 can be used, as shown in the examples. To secure the trace data, encryption methods can be used, which usually require a nonce. Such a nonce could, for example, be a timestamp of a trace message.

[0047] However, there is a risk that such a timestamp may be part of the same set of trace data, due to the nature of timestamp generation (e.g., using a cyclic counter) and trace data generation based on the configuration of the trace subsystem and the program flow.

[0048] Accordingly, without a corresponding security unit as described in the examples, there would be a certain probability that the same key-nonce pair would be used to secure the same data.

[0049] This problem will be addressed below using the following examples. Fig. 5 will be explained in detail. Fig. Figure 5 shows schematic views for securing diagnostic data according to exemplary implementations in the form of authenticated encryption with associated data (AEAD). Fig. Figure 5 shows in particular the parameters used for this purpose. Fig. Figure 5 on the left shows a schematic view of encryption and authentication according to exemplary implementations. A function E is used for this purpose. K , which receives as input data associated data A (Associated Data), a nonce N and the diagnostic data to be secured, here "plain text" (Klartet) P, and provides a result in the form of secured diagnostic data, here cipher text C, as well as a tag T. Fig. Figure 5 on the right shows the case of decryption and verification. This is done using a function D. K Based on the associated data A, nonce N, and verified diagnostic data C, the diagnostic data P and a tag T' are determined. Authentication can be provided by comparing the tag T with the determined tag T'.

[0050] The problem of multiple use of a nonce or a nonce key pair will be discussed below using the following examples: Fig. Section 6 explains this in more detail. It should be noted that the AES-GCM (Advanced Encryption Standard-Galois / Counter Mode) algorithm, for example, can be used for securing and, in particular, authenticating and encrypting diagnostic data.

[0051] The attacks discussed below relate in particular (but not exclusively) to such an implementation. Fig. Figure 6 shows a schematic view on the left of an attack in which the diagnostic data itself, i.e., the "plaintext," is recovered. For example, an attacker might have obtained two different sets of secure diagnostic data, here using ciphertexts C and C', which were generated with the same nonce N and the same secret key K2. The attacker can compromise confidentiality by restoring the underlying plaintext. This is possible through the cancellation property of the XOR operation.

[0052] Fig. Figure 6 on the right shows a schematic view of an attack to obtain the key. For example, an attacker might have obtained two different MAC tags, T and T', which were generated with the same nonce N and the same secret key K2. The attacker can then compromise the authenticity or integrity of the message by determining the hash key K1 and then using that key to send a message (e.g., a Joux Forbidden attack).

[0053] With regard to the Fig. 5 and Fig. In summary, section 6 states that, assuming the diagnostic data, and in particular trace data, is secure, cryptography typically requires a nonce (a unique number), which could conveniently be, for example, the timestamp of a corresponding trace message. However, due to the nature of the timestamp and the corresponding trace data generated based on the configuration of the trace subsystem and the program flow, this timestamp could be part of the same trace data. Therefore, without using examples, there is a certain probability that the same key and nonce are used to secure the same data.

[0054] For this purpose, a device according to exemplary embodiments, e.g. a device as in Fig. Figure 1 shows that the security unit 120 can be configured to provide a key derivation function. For example, the security unit 120 can be configured as a hardware block to provide a corresponding key derivation function (KDF).

[0055] Such implementation examples can therefore be based in particular on the idea of ​​using a key provisioning function (KDF) in the form of such a small hardware block, either additionally or as part of a MACsec hardware IP (e.g., MACsec IP), for example, in an Ethernet MAC. The hardware block can optionally calculate session keys (SK), for example, trace session keys, at runtime.

[0056] Optionally, according to the exemplary implementations, a set of pre-calculated session keys can also be provided, e.g. pre-calculated by the hardware block or by an external unit or the computing unit to be traced, for storage in the hardware block.

[0057] The calculation can be performed, for example, using one or more predefined trigger points. With a set of pre-calculated session keys, a corresponding trace system can be implemented as a non-invasive system, as shown in the examples, which is an important aspect of any trace system.

[0058] In other words, exemplary embodiments allow for the provision of a set of pre-calculated session keys. As previously explained, the session keys can be pre-calculated and stored internally, for example, by the device 100 itself, or they can be provided as the result of a calculation by an external unit of the interface 110 for storage in an optional memory 130. However, as also previously explained, exemplary embodiments also allow, for example, as an alternative to pre-calculating session keys, for the calculation of session keys during the generation of diagnostic data. For example, new session keys can also be calculated at the beginning of a new trace session using the KDF. One advantage of this is that the acquisition of trace data remains non-invasive.

[0059] A number of corresponding session keys can be predetermined or predefined, for example, based on information regarding a trace duration and / or a set of tracing data, such as information regarding a configuration, e.g., the tracing configuration, for generating the diagnostic data. As an optional feature, the KDF can be based on a previously exchanged key, such as a long-term key (LTK).

[0060] The long-term key may have been established beforehand between the two endpoints Tracer (unit that performs trace / debug) and Tracee (unit that is traced / debugged).

[0061] The following refers to Fig. 7. Fig. Figure 7 shows an example of a sequence diagram for acquiring diagnostic data, as an example in the form of trace data, according to the implementation examples. As in Fig. As shown in Figure 7, a trace client and a trace target can, for example, share a previously exchanged long-term key (LTK). The trace client can, for instance, request trace data from the target using an INIT1 message. A corresponding start signal for beginning the recording of trace data can, for example, be sent from interface 110, as shown in Figure 7. Fig. As shown in Figure 1, the INIT1 signal can be provided. This signal can contain information about the configuration of the trace data, based on which, for example, the required number of session keys can be determined to ensure secure protection of the trace data. In the example of... Fig. 7. Based on the INIT1 signal, for example, a session key SK1 can be determined based on the previously discussed KDF. In this case, a single key may suffice to secure the requested set of trace data. Similarly, an interface 110, as in Fig. As shown in Figure 1, it may, for example, be designed to output the secured diagnostic data (see, for example, Figures 104 and 122). Interface 110 can therefore, in particular, have an Ethernet interface. In the example of Fig. Figure 7 shows the diagnostic data, which may also include debug data, as trace data (TD), and the corresponding protected output is labeled ENC. SK1 (TD) is the designation.

[0062] Fig. Figure 7 also shows a second request for diagnostic data in the form of the INIT2 signal. As shown, based on configuration information contained in INIT2, it can be concluded, for example, that due to a noncene overflow, a single key is insufficient to secure the data, so the generation of two SK keys is necessary. 2a and SK 2b shown.

[0063] As already mentioned in the context of Fig. As explained in section 1, exemplary implementations enable a key change independent of the operation of the computing unit, i.e., for example, the diagnostic data-generating target.

[0064] According to some examples, secure diagnostic data, especially trace data, can be achieved or provided by using a hardware implementation instead of a software-based one. As explained earlier, the hardware implementation can relate, for example, to key exchange, but also to key provisioning or calculation. In particular, the provision of secure trace data can be achieved by using a hardware implementation based on MACsec, for example, instead of a software-based implementation based on TLS (Transport Layer Security) and TCP (Transmission Control Protocol) or DTLS (Datagram Transport Layer Security) and UDP (User Datagram Protocol).Thus, exemplary implementations enable non-invasive acquisition of diagnostic data, such as trace data, even with security mechanisms activated.

[0065] As previously explained, due to the amount of potentially generated diagnostic data, it may be necessary to implement key changes (for example, to perform re-keying) to avoid nonce collisions when the same session key, SK, is used or would be used. According to specific examples, such as when an internal timestamp of a diagnostic message, such as a trace message, is used as a nonce, a new session key can be used, generated, and / or calculated with each overflow of the timestamp timer. It should be noted again that, in addition to recalculating a new key due to such an overflow, a change based on a previously stored set of keys is also possible, for example, using memory 130, as described in [reference missing]. Fig. Figure 1 shows that, as explained previously, some of these examples are based on a long-term key previously exchanged between a trace client and a target.

[0066] According to the exemplary implementations, the determination of a new session key, which is based, for example, on the key determination function described below, can be carried out, for example, by means of a one-step (i.e., so that, for example, a key is derived directly from an initial value or key, e.g., LTK, without additional intermediate steps or transformations) or a two-step (e.g., 1. VAR = f1(LTK, "Config") and then 2. SK = f2(VAR, "Config2")) key determination function, as defined, for example, in the NIST document SP 800-56C Rev. 2. [1,p.19.24] be performed: SK=KDF(Z,OtherInput), where Z: a byte string representing the shared secret (in this case, for example, LTK); OtherInput (other inputs): salt, L, FixedInfo (fixed information), where salt: A non-null byte string (secret or non-secret). For example, a value calculated from a nonce, L: Length (in bits) indicating the length of the derived key material, FixedInfo: A bit sequence of context-specific data

[0067] With regard to the previous explanation, it should be noted again that, for example, a security unit 120 is optionally configured to encrypt the diagnostic data using incrementally generated values ​​from a limited range of numbers. In this case, the security unit 120 can also be configured to switch between session keys before or when the incrementally generated values ​​reach the end of the limited range or would exceed the end of the limited range through incrementing. The incrementally generated values ​​can therefore serve as noncens for security. As previously explained, timestamps of the diagnostic data can also be used for this purpose.Thus, by changing the key before an overflow, such as an arithmetic overflow, occurs, the multiple use of a nonce key pair can be avoided.

[0068] In summary, it shows Fig. 7. For example, a predefined implementation where a trace client configures the trace subsystem of a target and triggers the start of a trace session. The target can then generate one or more session keys (or optionally retrieve them from a memory location, e.g., 130) to secure the trace data, for example, by encrypting it. A key change, i.e., the use of a new session key, can be performed whenever the internal timestamp timer overflows, see [reference]. Fig. 7.

[0069] Reference is made to Fig. 8. Fig. Figure 8 shows a schematic view of an ECU system according to exemplary embodiments. In particular, it shows Fig. 8. An example of a trace data flow using MACsec and KDF. Fig. Figure 8 shows an electronic control unit 800 comprising a microcontroller (MCU) 810 and a physical layer transceiver 820. The microcontroller 810 further includes an interface 811, a MACsec hardware block 813, a key derivation function hardware block 812, a MAC 814, RAM (remote access memory) 815, a CPU (central processing unit) 816, and a trace system 817. The system also includes a network 960, for example an in-vehicle network (INV), which provides a connection to other electronic control units 910, 920, and 930. Furthermore, the system includes a gateway 940, which communicates with a remote trace acquisition unit 950 via TLS 951.

[0070] In particular, according to the exemplary embodiments, a corresponding interface, e.g. 110, can be used. Fig. 1, e.g., according to 811, be configured as an Ethernet interface, or have one.

[0071] In other words, it shows Fig. 8 An example ECU application (here with multiple ECUs) in which an on-chip trace can be used for remote diagnostics, according to an exemplary embodiment.

[0072] Hardware block 812 can, for example, be used for the security unit 120. Fig. 1 correspond. Interface 110 can, for example, be part of block 813. In other words, the device, for example device 100, can be made from Fig. 1. It may be part of a Media Access Control security hardware architecture. Optionally, part of interface 110 can also be formed by interface 811. Alternatively, the device, or at least the security unit, can also be designed as a hardware structure that can be operated separately from the Media Access Control security hardware architecture. The trace system 817, for example, corresponds to the computing unit 200 from Fig. 1. As optionally shown, the device and the computing unit can, for example, be implemented on a common system on-chip, e.g., 810. In particular, the common system on-chip can be part of an electronic control unit 800, for example, an ECU (Electronic Control Unit).

[0073] In the Fig. In the embodiment shown in Figure 8, the device according to exemplary embodiments is furthermore implemented as an optional feature on a common system on chip (SoC, here MCU), 810, with the computing unit 817.

[0074] With regard to Fig. 8. It should be noted again that a device according to exemplary embodiments, e.g., as in Fig. As discussed in section 1, this is not limited to a single implementation. For example, parts of interface 110 can be configured using element 811, for instance, for information 102 and / or 104, whereas a part of interface 110 for information 101 and / or 103 can be part of block 814. In other words, further elements can also be arranged between device 100 and computing unit 200.

[0075] In other words, it shows Fig. 8. An example application where a corresponding mechanism according to exemplary embodiments for session keys is advantageous or even necessary, namely in the application area of ​​an electronic control unit (ECU) for a vehicle. Exemplary embodiments may be particularly advantageous or even necessary when on-chip trace data is used as part of remote diagnostic data, i.e., in other words, for remote diagnostic applications, such as wireless diagnostic applications. The on-chip trace subsystem, for example, unit 812, can be used to generate diagnostic data, such as program and / or trace data of a target application. This data can then be transmitted via an Ethernet MAC, see [reference]. Fig. 8.

[0076] For example, in Fig. As shown in Figure 8, a debug host management server can be used in a central processing unit (e.g., Gateway 940) for the purpose of trace data acquisition. This server is capable of communicating with the target device, for example, 817. A trace client requests the acquisition of trace data, and the request is then forwarded by the debug host management server to the corresponding target, which is identified based on information provided in the request. The generated trace data is then transmitted from the corresponding device to the corresponding trace client. Mapping can be performed within the debug host management server. Further details are provided in Figure 8. Fig. 9 referred.

[0077] Fig.Figure 9 shows a schematic view of a sequence diagram for acquiring trace data by the debug host management server according to the examples. In a simplified form, LTK1=LTK2 can be considered, for example. This allows diagnostic data to be provided and communicated to a large number of computing units.

[0078] As explained above, these implementation examples can be particularly useful in the automotive sector. With the increasing number of autonomous functions in current and future vehicles, the need for improved software observability of the devices used is growing. Secure diagnostic data, as described in these implementation examples, is therefore advantageous or even necessary for many applications, for example, to prevent the disclosure of proprietary information, personal data, cryptographic keys, and other device data.

[0079] In summary, these implementation examples can be used in all areas of cybersecurity in the automotive industry, Internet of Things applications, and especially for microcontrollers and microprocessors.

[0080] The following are examples of implementation: The following describes exemplary embodiments and aspects of the disclosure that can be used individually or in combination with any of the features, functionalities and details described herein.

[0081] A first aspect concerns a device for securing diagnostic data, e.g., log data, e.g., on-chip trace data, relating to the operation of a computing unit (e.g., data for the analysis and / or monitoring of the computing unit, e.g., data which is automatically generated by the computing unit during operation), wherein the device has the following features: an interface designed to receive the diagnostic data of the computing unit; a security unit designed as a hardware structure that can be operated separately from the computing unit and is designed to secure the diagnostic data using session keys and to provide a switch between session keys, e.g., a re-keying, independent of the operation, e.g., independent of a state, of the computing unit.

[0082] According to a second aspect, referring to the first aspect, the diagnostic data includes trace data and / or debug data relating to the operation of the computing unit.

[0083] According to a third aspect, referring to the first or second aspect, the security unit is trained to authenticate and / or encrypt the diagnostic data.

[0084] According to a fourth aspect, referring to one of aspects one to three, the security unit is designed to calculate the session keys independently of the operation of the computing unit, so that, for example, the calculation of the session keys and the safeguarding of the diagnostic data are enabled independently of the state of the computing unit, i.e., regardless of whether the computing unit is in an error state or not.

[0085] According to a fifth aspect with reference to the fourth aspect, the security unit is designed to calculate the session keys during the generation of diagnostic data, e.g. by means of a Key Derivation Function (KDF) which is designed to calculate the session keys, e.g., during the operation of the computing unit.

[0086] According to a sixth aspect with reference to one of aspects one to five, the device has a memory configured to store the session keys for securing the diagnostic data, and the security unit is configured to read the session keys from the memory independently of the operation of the computing unit, wherein the device is configured, for example, by means of the interface, to obtain the session keys before the generation and / or start of the securing of the diagnostic data and to store them in memory.

[0087] According to a seventh aspect with reference to the sixth aspect, the security unit is designed to calculate the session keys before the generation of the diagnostic data to be secured begins and to store them in memory.

[0088] According to an eighth aspect, referring to one of aspects one through seven, the security unit is designed to secure the diagnostic data using incrementally generated values ​​from a limited range of numbers, for example, by encrypting them. These values ​​serve, for example, as nonces for the encryption. Furthermore, the security unit is designed to switch between session keys before or when the incrementally generated values ​​reach the end of the limited range of numbers or would exceed the end of the limited range through incrementing. This occurs, for example, when or before an overflow, such as an arithmetic overflow, takes place or would take place, thus preventing the multiple use of a nonce with the same key.

[0089] According to a ninth aspect, referring to the seventh aspect, the values ​​are nonces in the form of timestamps of the diagnostic data.

[0090] According to a tenth aspect, referring to one of aspects one to nine, the device is part of a Media Access Control Security hardware architecture, e.g. IEEE802.1AE MACsec.

[0091] According to an eleventh aspect, referring to one of the aspects one to ten, the device or at least the security unit is designed as a hardware structure that can be operated separately from a Media Access Control Security hardware architecture and which, for example, serves the predefined interfaces (APIs) of the IEEE802.1AE MACsec hardware.

[0092] According to a twelfth aspect with reference to one of the aspects one to eleven, the interface is designed to obtain information about the duration and / or amount of diagnostic data, and the security unit is designed to determine the session keys based on the information about the duration and / or amount of diagnostic data, i.e., for example, in particular, the number of session keys.

[0093] According to a thirteenth aspect, referring to one of aspects one to twelve, the security unit is trained to determine the session keys based on a long-term key.

[0094] According to a fourteenth aspect, referring to one of aspects one through thirteen, the security unit is trained to determine the session keys using the key determination procedure according to NIST SP 800-56C Rev. 2.

[0095] According to a fifteenth aspect, referring to one of the aspects one to fourteen, the device and the computing unit are implemented on a common system on chip.

[0096] According to a sixteenth aspect, referring to one of aspects one to fifteen, the common system on chip is part of an electronic control unit, e.g. ECU = Electronic Control Unit.

[0097] According to a seventeenth aspect, with reference to one of the aspects one to sixteen, the interface provides an Ethernet interface to output the secured diagnostic data.

[0098] According to an eighteenth aspect, with reference to one of the aspects one to seventeen, the interface is designed to provide the computing unit with a signal to begin recording the trace data.

[0099] According to a nineteenth aspect with reference to aspect eighteen, the interface is designed to receive from a debug interface, e.g., a Debug Host System Interface, information concerning the start of diagnostic data recording; a configuration of diagnostic data; a content of diagnostic data; and / or a type of diagnostic data.

[0100] A twentieth aspect concerns a procedure for securing diagnostic data relating to the operation of a computing unit, wherein the procedure comprises the following steps: obtaining the diagnostic data of the computing unit via an interface; securing the diagnostic data using session keys; and providing a switch between session keys, independent of the operation of the computing unit, by means of a security unit designed as a hardware structure that can be operated separately from the computing unit.

[0101] A twenty-first aspect concerns a computer program with program code for carrying out the procedure according to the twentieth aspect, when the program runs on a computer.

[0102] The following is a summary of the acronyms used: KDF: Key Derivation Function, LTK: Long Term Key, MAC: Media Access Control, SK: Session Key, ECU: Electronic Control Unit, TCP: Transmission Control Protocol, TLS: Transport Layer Security, UDP: User Datagram Protocol, DTLS: Datagram Transport Layer Security.

[0103] All the materials, environmental influences, electrical properties and optical properties listed herein are to be regarded as examples and not as exhaustive.

[0104] Although some aspects have been described in connection with a device, it is understood that these aspects also constitute a description of the corresponding process, so that a block or component of a device can also be understood as a corresponding process step or as a feature of a process step. Similarly, aspects described in connection with or as a process step also constitute a description of a corresponding block, detail, or feature of a corresponding device. Some or all of the process steps can be performed by (or using) a hardware apparatus, such as a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, some or more of the key process steps can be performed by such an apparatus.

[0105] Depending on specific implementation requirements, exemplary implementations can be carried out in hardware or software. The implementation can be performed using a digital storage medium, such as a floppy disk, DVD, Blu-ray disc, CD, ROM, PROM, EPROM, EEPROM, FLASH memory, hard disk, or other magnetic or optical storage medium, on which electronically readable control signals are stored. These signals can interact with, or interact with, a programmable computer system to execute the respective procedure. Therefore, the digital storage medium can be computer-readable.

[0106] Some embodiments therefore include a data carrier that has electronically readable control signals capable of interacting with a programmable computer system in such a way as to carry out one of the methods described herein.

[0107] In general, embodiments can be implemented as a computer program product with a program code, wherein the program code is effective in carrying out one of the methods when the computer program product runs on a computer.

[0108] The program code can also be stored on a machine-readable medium, for example.

[0109] Other embodiments include the computer program for carrying out one of the methods described herein, wherein the computer program is stored on a machine-readable medium.

[0110] In other words, an embodiment is thus a computer program that includes program code for performing one of the procedures described herein when the computer program is run on a computer.

[0111] Another embodiment is thus a data carrier (or a digital storage medium or a computer-readable medium) on which the computer program for carrying out one of the methods described herein is recorded. The data carrier, the digital storage medium, or the computer-readable medium is typically tangible and / or non-perishable or non-temporary.

[0112] Another embodiment is thus a data stream or a sequence of signals that represents the computer program for carrying out one of the methods described herein. The data stream or sequence of signals can be configured, for example, to be transferred via a data communication connection, such as the Internet.

[0113] Another embodiment comprises a processing device, for example a computer or a programmable logic device, which is configured or adapted to perform one of the methods described herein.

[0114] Another embodiment comprises a computer on which the computer program for performing one of the procedures described herein is installed.

[0115] Another embodiment comprises a device or system designed to transmit a computer program for carrying out at least one of the methods described herein to a receiver. The transmission can be, for example, electronic or optical. The receiver can be, for example, a computer, a mobile device, a storage device, or a similar device. The device or system can, for example, include a file server for transmitting the computer program to the receiver.

[0116] In some embodiments, a programmable logic device (for example, a field-programmable gate array, an FPGA) can be used to perform some or all of the functionalities of the methods described herein. In some embodiments, a field-programmable gate array can interact with a microprocessor to perform one of the methods described herein. Generally, in some embodiments, the methods are performed by any hardware device. This can be general-purpose hardware such as a computer processor (CPU) or method-specific hardware such as an ASIC.

[0117] The devices described herein can be implemented, for example, using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0118] The devices described herein, or any components of the devices described herein, may be implemented at least partially in hardware and / or in software (computer program).

[0119] The methods described herein can be implemented, for example, using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0120] The methods described herein, or any components thereof, may be executed at least partially by hardware and / or by software.

[0121] The embodiments described above merely illustrate the underlying principles. It is understood that modifications and variations of the arrangements and details described herein will be obvious to other people skilled in the art. Therefore, it is intended that the scope of protection is not limited by the specific details presented herein by way of description and explanation of the embodiments. References:

[0122] [1] 1 (see page 5) E. Barker, L. Chen, and R. Davis, “Recommendation for Key-Derivation Methods in Key-Establishment Schemes,” National Institute of Standards, techreport, Aug. 2020. doi: 10.6028 / NIST.SP.800-56Cr2. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited non-patent literature

[0000] E. Barker, L. Chen, and R. Davis, “Recommendation for Key-Derivation Methods in Key-Establishment Schemes,” National Institute of Standards, techreport, Aug. 2020. doi: 10.6028 / NIST.SP.800-56Cr2

[0122]

Claims

[1] Device (100, 420, 812, 813) for securing diagnostic data (101, 121) relating to the operation of a computing unit (100, 410, 817), wherein the device has the following features: an interface (110, 811, 814) designed to receive the diagnostic data (101) of the computing unit; a backup unit (120, 422, 812) which is designed as a hardware structure that can be operated separately from the computing unit, and which is designed to to secure the diagnostic data using session keys (121, 131), and to provide a switch between session keys independently of the operation of the computing unit. [2] Device (100, 420, 812, 813) according to claim 1, wherein the diagnostic data (101) comprise trace data and / or debug data relating to the operation of the computing unit (100, 410, 817). [3] Device (100, 420, 812, 813) according to claim 1 or 2, wherein the security unit (120, 422, 812) is configured to authenticate and / or encrypt the diagnostic data (101, 121). [4] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the safeguarding unit (120, 422, 812) is configured to calculate the session keys (131) independently of the operation of the computing unit (100, 410, 817). [5] Device (100, 420, 812, 813) according to claim 4, wherein the safeguarding unit (120, 422, 812) is configured to calculate the session keys (131) during the generation of diagnostic data. [6] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the device has a memory (130, 424) configured to store the session keys (102, 131) for securing the diagnostic data (101, 121), and wherein the security unit (120, 422, 812) is designed to read the session keys from memory independently of the operation of the computing unit (100, 410, 817). [7] Device (100, 420, 812, 813) according to claim 6, wherein the safeguarding unit (120, 422, 812) is configured to calculate the session keys (131) before the generation of the diagnostic data (101) to be safeguarded begins and to store them in the memory (130, 424). [8] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the security unit (120, 422, 812) is designed to encrypt the diagnostic data (101) using incrementally generated values ​​from a limited range of numbers, and wherein the safeguard unit (120, 422, 812) is configured to perform a switch between session keys (131) before or when the incrementally generated values ​​reach an end of the limited number range or would exceed the end of the limited number range by means of incrementing. [9] Device (100, 420, 812, 813) according to claim 8, wherein the values ​​are noncens in the form of timestamps of the diagnostic data (101). [10] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the device is part of a Media Access Control Security hardware architecture (813). [11] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the device or at least the security unit (120, 422, 812) is designed as a hardware structure (812) that can be operated separately from a Media Access Control Security hardware architecture (813). [12] Device (100, 420, 812, 813) according to any one of the preceding claims, wherein the interface (110, 811, 814) is designed to obtain information (101, 102) about a duration and / or a data volume of the diagnostic data (101), and wherein the safeguarding unit (120, 422, 812) is designed to determine the session keys (131) based on information about the duration and / or amount of diagnostic data (101). [13] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the safeguarding unit (120, 422, 812) is configured to determine the session keys (131) based on a long-term key. [14] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the safeguarding unit (120, 422, 812) is configured to determine the session keys (131) using the key determination method according to NIST SP 800-56C Rev.

2. [15] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the device and the computing unit (100, 410, 817) are implemented on a common system on chip (810). [16] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the common system on chip is part of an electronic control unit (800). [17] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the interface (110, 811, 814) has an Ethernet interface to output the secured diagnostic data (101). [18] Device (100, 420, 812, 813) according to one of the preceding claims, wherein the interface is configured to provide a signal to the computing unit (100, 410, 817) to begin recording the diagnostic data. [19] Device (100, 420, 812, 813) according to claim 18, wherein the interface (110, 811, 814) is designed to receive information (102) concerning a debug interface Start of recording of diagnostic data (101); a configuration of the diagnostic data; a content of the diagnostic data; and / or a type of diagnostic data to obtain. [20] Method for securing diagnostic data relating to the operation of a computing unit (100, 410, 817), wherein the method comprises the following steps: Receiving the diagnostic data (101) of the computing unit via an interface (110, 811, 814); Securing the diagnostic data (101, 121) using session keys (131) and providing a switch between session keys, independent of the operation of the computing unit, by means of a security unit (120, 422, 812) which is designed as a hardware structure that can be operated separately from the computing unit. [21] Computer program with program code for carrying out the method according to claim 20, when the program runs on a computer.

Images