System and method for confidential multi-party software in circuit emulation

Abstract

The present disclosure relates to systems and methods for confidential multi-party software in loop simulation. A software-in-the-loop (SiL) system and method is disclosed that can include a simulator operable to provide an environment to simulate a dynamic system, enabling rapid development, verification, and testing of complex systems. The system and method can include assembling one or more unprotected models operable to simulate a real-world system. The system and method can then encrypt and generate at least one protected model from the one or more unprotected models using a first cryptographic key. The at least one protected model can be decrypted using a sealed decryption key. The decrypted protected model can then be executed within one or more TEEs. The at least one protected model can be operable to process incoming data and outgoing data.

Description

Technical Field

[0001] This disclosure relates to systems and methods for using confidential multi-party software in loop simulation. Background Technology

[0002] Software-in-the-loop (SiL) systems can include test setups where factory models and electronic control unit (ECU) software run and are tested in a purely “virtual” computing or IT environment. In fact, SiL systems can be designed to eliminate the need for even physical components (e.g., sensors, actuators) or target ECU hardware (e.g., vehicle controllers). SiL simulations can even represent the integration of compiled production source code into a mathematical model simulation, providing engineers with a practical virtual simulation environment for developing and testing detailed control strategies for large and complex systems. While various types of SiL systems are known to exist, they are typically employed in limited testing areas. However, with the increasing complexity of systems and software across various industries (e.g., the automotive industry), a SiL verification and validation system and methodology that can be implemented to reduce development cycle times and handle the significant increase in distributed software functionality under test is desirable. Summary of the Invention

[0003] A system and method for protecting software-in-the-loop simulation of a real-world system using one or more Trusted Execution Environments (TEEs) are disclosed. Those skilled in the art will understand that the TEE may include a secure enclave. The system and method may include assembling one or more unprotected models operable to simulate a real-world system. The system and method then encrypt and generate at least one protected model from the one or more unprotected models using a first cryptographic key. The at least one protected model can be decrypted using a sealed decryption key. The decrypted protected model can then be executed within one or more TEEs. The at least one protected model is operable to process incoming and outgoing data.

[0004] SiL simulation can also be operable to exchange unprotected data over one or more unprotected communication networks. It is envisioned that one or more unprotected communication networks are operable to transmit unprotected data from an external source, at least one protected model, or one or more unprotected models. TEE can also be operable to encrypt and exchange protected data over one or more protected communication networks using at least a second cryptographic key. One or more protected communication networks are operable to transmit protected data from an external source or at least one protected model. Finally, the integrity of the protected data can be verified using one or more proof digests, which are transmitted when the software terminates the loop simulation. The proof digests can also be used to verify the integrity of protected data transmitted from at least one protected model.

[0005] The TEE can also be operable to encrypt one or more sub-components of a protected model using a secure enclave. Alternatively, a multi-model secure enclave can be generated by encrypting at least two of one or more unprotected models. Protected data may include parameters used by at least one protected model to simulate a real-world system. The secure enclave can be compiled into a dynamic signature library and may include an enclave conversion function operable to protect internal interfaces within at least one protected model. The enclave conversion function can also be operable to protect external interfaces between at least one protected model and one or more protected communication networks. It is further envisioned that an auxiliary secure enclave can be generated to request a sealed decryption key from a key supply host. The sealed decryption key can be obtained from the key supply server to decrypt the secure enclave. Finally, the enclave can be encrypted using a symmetric encryption key (e.g., an AES-128 security key). However, it is envisioned that other types of cryptographic keys can be used to encrypt the enclave.

[0006] The TEE is operable to isolate the execution state of at least one protected model and protect the execution state of at least one protected model from access without enclave access control or logical approval. A second cryptographic key can be exchanged between the TEE and another TEE to verify the integrity of the protected data. Alternatively, the second cryptographic key can be obtained by an external system from the TEE for communication with the TEE or between TEEs. During external exchange, the external system can ingest the protected data into its own TEE environment. Attached Figure Description

[0007] Figure 1 This is an illustrative example of a SiL system.

[0008] Figure 2 This is an illustrative example of a SiL system that includes a Secure Trusted Execution Environment (TEE) architecture.

[0009] Figure 3 This is an exemplary illustration of a distributable model.

[0010] Figure 4 An alternative embodiment of the model supply is illustrated.

[0011] Figure 5 The illustration shows alternative embodiments of how communication within a SiL system can be protected across various models.

[0012] Figure 6 The diagram illustrates how the TEE architecture of the SiL system can protect the processing of each model. Detailed Implementation

[0013] Embodiments of this disclosure are described herein. However, it is to be understood that the disclosed embodiments are merely examples, and other embodiments may take various and alternative forms. The figures are not necessarily to scale; some features may be enlarged or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art to employ the embodiments in different ways. As will be understood by those skilled in the art, various features illustrated and described with reference to any of the figures may be combined with features illustrated in one or more other figures to produce embodiments not explicitly illustrated or described. The combinations of illustrated features provide representative embodiments of typical applications. However, various combinations and modifications of features consistent with the teachings of this disclosure are desired for particular applications or implementations.

[0014] Similarly, Software-in-the-Loop (SiL) systems can include test settings where factory models and electronic control unit (ECU) software run and are tested in a purely “virtual” computing or IT environment. In fact, SiL systems can be designed to eliminate the need for even physical components (e.g., sensors) or target ECU hardware (e.g., vehicle controllers). SiL simulations can even represent the integration of compiled production source code into a mathematical model simulation, providing engineers with a practical virtual simulation environment for developing and testing detailed control strategies for large and complex systems. While various types of SiL systems are known to exist, they are typically employed in limited testing areas. However, with the increasing complexity of systems and software across various industries (e.g., the automotive industry), a SiL verification and validation system and methodology that can be implemented to reduce development cycle times and handle the significant increase in distributed software functionality under test is desirable.

[0015] Furthermore, as the automotive industry moves towards automation / autonomous driving, the need for real-world testing and continuous iteration may increase to design systems that can be approved for commercial deployment. Traditional vehicle testing methods (e.g., the traditional requirement of miles of real-world road testing) may not be feasible. Development chains and testing methods may need to be modified to incorporate SiL systems and methodologies. And as SiL systems become more sophisticated to handle testing of complex systems, collaborative development efforts from multiple parties (e.g., automotive OEMs, technology providers, automotive suppliers, integrators) may be required. Further expectations for SiL systems may arise because they have the ability to test prototypes using system components under development.

[0016] For system integrators, such as automotive OEMs or suppliers, SiL systems can effectively decouple the hardware development cycle from the continuous software development process. Therefore, SiL systems enable related components to be developed in parallel and tested independently. Consequently, SiL systems may reduce the requirements for test equipment (such as test vehicles) and custom hardware needed for system verification.

[0017] A potential drawback of SiL systems is that the models and simulation data utilized may consist of proprietary technology, which has significant commercial value to the provider and therefore requires strong safeguards. For example, testing a complete automotive system might require control systems provided by both the automotive OEM and its suppliers. If an OEM supplier uses a SiL system for testing, the OEM may require stringent security safeguards to ensure that confidential and proprietary aspects of its controllers (e.g., source code) remain undiscovered. Consequently, sharing a SiL platform among parties could create an environment where a certain level of protection is difficult to guarantee.

[0018] Figure 1 This is an illustrative example of a SiL system 100 that can be deployed in a commercial environment (e.g., an automotive vehicle). The SiL system 100 may include one or more software representations of various systems, including: a factory model 102, an actuator model 104, a sensor model 106, an environmental model 108, and a driver model 110. The SiL system 100 may further include ECU hardware and software in the form of one or more virtual ECU models 112, 114.

[0019] It is envisioned that models 102-114 can be connected via a virtualized communication network 116 (i.e., a bus), which operatively provides data and control flow paths for implementing system-specific protocols. It is also envisioned that system 100 may include a virtualized power network 118, which includes other virtualized parameters affecting system functionality. Finally, a virtualized control network 120 may also be included for providing virtualized control signals to the various models 102-114.

[0020] System 100 can be operationally run on an integrator's premises or a virtual cloud platform. It is envisioned that the model integrator (or user) has full access to data transmitted across networks 116-120 and the code of models 102-114 (or data stored within the code of models 102-114). When System 100 is used on a third-party cloud provider, the provider's infrastructure hosts can also access the data transmitted across networks 116-120 and the code of models 102-114 (or data stored within the code of models 102-114). Therefore, the security of such System 100 can be based on the trust relationship between the model provider and the integrator, or between the integrator and the cloud provider.

[0021] Therefore, a SiL system and method are desired, comprising a simulator operable to provide an environment for simulating dynamic systems, enabling rapid system development, verification, and testing of complex systems. The SiL system and method can also provide reductions in development time and cost associated with traditional iterative and distributed design methodologies in various applications. For example, a SiL system can provide reduced development time and cost for different applications, such as automotive and aerospace system design.

[0022] The SiL system further enhances operability by protecting models 102-114 during SiL simulations. This protection allows model providers (e.g., the designer of sensor model 106) complete control over the confidentiality of the IP of a given model. Confidentiality and control provide security and privacy for sensitive components. Such security and privacy enable risk-free collaboration among multiple parties. Additionally, this architecture allows integrators to leverage third-party cloud services without relying on the security infrastructure of cloud providers. The SiL system enhances traditional protection models, enabling model protection during simulation runtime, model storage, and data ingestion.

[0023] It is envisioned that SiL systems can operate using one or more privacy-preserving computation techniques (PPCT) capable of protecting the confidentiality of model IP and simulation data while allowing the utilization of existing processing chains and capabilities. SiL systems may include protected environments or protected regions within a processor (e.g., trusted execution environments or "TEEs") to provide a high level of trust, including security and privacy, when executing simulation code, executing code, accessing data within the model, or executing code or transferring data between models. For example, this environment could be implemented using an Intel SGX or ARM TrustZone processor with a secure region within the processor implementing the TEE. Alternatively, it is also envisioned to implement the TEE using a combination of a TEE and a field-programmable gate array (FPGA), a separate FPGA, or even one or more application-specific integrated circuits (ASICs) or processors (such as graphics processing units (GPUs), intelligent processing units (IPUs), or tensor processing units (TPUs)). Therefore, it is envisioned that the TEE is not specific to a particular architecture or processing unit and can be tailored to a given application.

[0024] It is envisioned that a TEE (Transmission Equipment) can utilize hardware guarantees to protect functional execution from unauthorized inspection, probing, or intrusion. By ensuring TEE operability, the executing functions can be trusted to be secure, and their integrity can be guaranteed. Furthermore, data can be stored outside an enclave encrypted with a generated secret and accessible only within the TEE. This envisions long-term secure data storage.

[0025] Figure 2 This is an illustrative example of a SiL system 200 that can be used to provide a safety architecture. The SiL system 200 may include one or more software representations of various systems, including: a plant model 202, an actuator model 204, a sensor model 206, an environment model 208, and a driver model 210.

[0026] The SiL system 200 can additionally provide various forms of security and model protection. Security and model protection can be designed to enhance the confidentiality and integrity of the model. Security and model protection can be implemented by encrypting the model code (or binary) using a key available only to the provider. The model provider can transmit the key directly to the TEE for decryption and model operation. Such protection can be applied to the entire model (e.g., driver model 210 or sensor model 206), or it can be applied to a sub-component of a given model (e.g., a LiDAR sensor within sensor model 206).

[0027] The SiL system 200 can also connect models 102-114 via a virtualized communication network 216 (i.e., a bus), which operatively provides data and control flow paths for implementing system-specific protocols. The system 200 may include a virtualized power network 218, which includes other virtualized parameters affecting system functionality. Finally, it may also include a virtualized control network 220 for providing virtualized control signals to the various models 202-214.

[0028] The SiL system 200 may include various communication security and protection measures. For example, security and communication protection can be applied to data provided to the simulation as input or parameters, as well as data exchanged between models (e.g., between sensor model 206 and ECU model 212) via the secure virtual communication bus 222. Security and communication protection can be implemented by encrypting transmitted data using a key that is only available to the TEE operating or using the data.

[0029] The SiL system 200 may further include ECU hardware and software in the form of one or more ECU models 212, 214. As illustrated by virtual ECU model 214, the SiL system 200 may include various security and protection measures for each virtual processor. Protection for the virtual ECU models executed on the SiL system 200 may be implemented using a TEE framework.

[0030] Finally, the SiL system 200 can further include a result integrity guarantee to provide additional security and protection. For example, some systems may require a guarantee of result integrity, i.e., ensuring that the output or processing has not been modified. TEE-based implementations can provide such a guarantee using proofs of the separate model TEE or proofs of the input data.

[0031] It is envisioned that the SiL system 200 incorporates a TEE architecture that may include hardware-based isolation and protection of the execution software modules themselves. Such security and protection can be provided by the processor used. However, it is also envisioned that, in order to incorporate the TEE architecture, the SiL system 200 may further require: (1) isolation of modules 202-214 to protect execution state (registers, memory, and operations) from external observation or tampering; (2) sealed operability implemented by the TEE using internal secret materials to protect data stored on storage media (i.e., volatile or non-volatile memory types, such as hard disks, RAM, etc.); and (3) proof that can demonstrate the execution of specific functions within the TEE (protected by the TEE). For example, proof could be used to exchange keys between multiple TEEs or to send a public key to an external party to ingest data into the TEE.

[0032] It is also envisioned that the SiL system 200 can be implemented using a virtualized environment. For example, one or more virtual operating systems (OS) or virtual machines could be allowed to operate the SiL system 200 using hypervisor software or hardware architecture. Alternatively, the SiL system 200 could be operated using OS-level virtualization to deliver the SiL system 200 as a package or container using a Docker Platform as a Service (PaaS) product (e.g., an OS on a hypervisor, Docker containers within an OS, or a Kubernetes cluster). Finally, other container orchestration systems could be used to deliver the SiL system 200 to automate the deployment of SiL system 200 on platforms like Kubernetes. When executing the SiL system 200 using a virtualized environment, the TEE architecture may require security guarantees extending from the hardware to the virtualization layer.

[0033] SiL system 200 may also include software modules that can be executed using hardware extensions to provide security functions (i.e., TEEs). These software modules may need to be prepared in a predefined specified format. Software modules (e.g., “enclaves”) may also be operable to perform a restricted set of operations and require additional metadata or interfaces that can be used to load, execute, and translate between the software module and the regular operations being performed by SiL system 200. For example, SiL system 200 may include one or more enclaves (e.g., Intel SGX enclaves) compiled into a dynamic signature library. SiL system 200 may be designed to translate to enclaves using defined interface functions (e.g., “ECALLS” and “OCALLS”) that execute specific low-level processor instructions.

[0034] The envisioned TEE-based architecture (i.e., a purely TEE-based architecture) includes a model provisioning process. During this process, models 202-214 of the SiL system 200 can interact with the simulation environment and tools through defined interfaces. For example, these interfaces could be standards-based, such as the Functional Prototype Interface (FMI) for developing complex cyber-physical systems, or they could be tool-specific interfaces.

[0035] It is envisioned that, during the model supply process, model providers (i.e., OEMs, suppliers, or resellers) may be additionally required to implement additional aspects for each model supplied (e.g., models 202-214). For example, the model provider may need to identify sub-components within the model that require protection, which could be referred to as "model-IPs." Exemplary model-IP components may include specific implementation logic, data paths, embedded parameters, or the entire model itself. The model provider may also need to identify interfaces for interacting with the model-IPs. For example, the model provider for actuator model 204 might need to identify virtual ECU model 214 and sensor model 206 for interaction with model 204.

[0036] The model provider may also need to create an enclave that includes the model-IP. This enclave could be processor-based hardware-level isolation or memory encryption, isolating application code and data to prevent access by unauthorized individuals. The model provider may need to create the enclave so that it is operable to extend the required interface functionality to include transitions into and out of the enclave execution environment. The model provider may further need to include any additional special functionality required to handle enclave data. For example, the model provider may need to include the ability to encrypt or decrypt communications or to create and report interface data summaries.

[0037] The model provider may further require the use of hardware or cryptographic metadata required by the hardware vendor to protect the confidentiality and integrity of the enclave. For example, the confidentiality of the enclave could be protected by encrypting the enclave image using a cryptographic key and then signing the encrypted image with a key that can be verified by the hardware vendor. It is envisioned that such cryptographic keys could be obtained from a key supply server containing a set of keys (e.g., asymmetric or symmetric keys) designed to encrypt and decrypt transmitted data and messages.

[0038] Model providers can also create additional systems and methods for decrypting model enclaves. For example, additional systems and methods may include auxiliary enclaves that request decryption keys or encrypted (sealed) decryption keys. Model providers may further need to create distributable general models, which may include remaining model components and extended interface functionality. Finally, model providers may need to package the general model, model parts, and enclave images to obtain a secure, distributable model package. The model integrator can then utilize such a secure, distributable package during the simulation process of the SiL System 200.

[0039] Figure 3This is an exemplary illustration of a model distributable package 300. Model distributable package 300 may represent models 202-214. As illustrated, model distributable package 300 may include one or more sub-components 304-314. For model distributable package 300, sub-components 312-314 and accessibility function 310 will need to be identified as model-IPs (i.e., privacy-sensitive components) that will need to be protected within enclave 324.

[0040] External interfaces 320 and 322 will also need to be identified as external interfaces (i.e., communication) that can interact with the distributable model 302 and, more specifically, with sub-components 304-314. As shown, external interface 320 will be identified as an interface that does not require interface functionality to include transitions into and out of the enclave execution environment. Accordingly, interface 320 may be provided across a non-secure interface communication channel, such as a virtual communication bus 216, a virtual power line 218, or a virtual control network 220.

[0041] Alternatively, external interface 322 will be identified as the interface that actually interacts with enclave 314, and therefore requires interface functionality to include transitions into and out of the enclave execution environment (i.e., enclave transition functionality). Similarly, internal interfaces 316, 318 between sub-components 304-308 and sub-components 312-314, as well as auxiliary function 310, will also require interface functionality to include transitions into and out of the enclave execution environment (i.e., enclave transition functionality). Accordingly, interface 322 can be provided across a secure interface communication channel, such as a secure virtual communication bus 222, a secure virtual power line 224, or a secure virtual control network 226.

[0042] Enclave 324 is envisioned to be designed using Intel SGX hardware extensions. It is also envisioned that the model-IP can be decoupled initially, ensuring it does not contain any system calls. Interfaces 316-318, 322 are operable to allow transitions into and out of Enclave 324. For example, wrapper code is operable to use ECALLS and OCALLS, generated using tools that verify several input-output security conditions before executing hardware instructions to enter or exit Enclave 324. Enclave 324 can be further protected using symmetric encryption keys (e.g., AES-128 or AES-256 security keys) and by signing encrypted data using a public and private key pair (e.g., an RSA key pair) identified by a key provided by the hardware owner.

[0043] Figure 4 An alternative embodiment of the model supply is illustrated, which may include an enclave 402 protecting two or more models 406-408. It is envisioned that models 406-408 may be... Figure 2Model 202-214 shown in the diagram Figure 3 Model 302 is shown in the diagram.

[0044] Enclave 402 can be designed when the model provider (i.e., the OEM providing model 406) can provide the integrator with the original, unprotected model. This can be based on an existing trust or business relationship between the provider and the integrator. The integrator (e.g., an OEM supplier or reseller) can choose to protect model(s)404 or 406 from the execution infrastructure (e.g., a third-party cloud provider) by encapsulating model(s)404 or 406 within the TEE enclave 402. Because the integrator has an overview of the system architecture and connectivity, it can choose to encapsulate multiple models 404, 406 and their communication interfaces 408, 416-418 within a single TEE enclave 402. By including them within a single enclave 402, it is envisioned that the simulation efficiency of the SiL system 202 can be improved.

[0045] However, it is also envisioned that software or machine learning algorithms could be used to automatically combine two or more models 406-408 into enclave 402 based on analysis of system 200. For example, the algorithm could analyze various communication patterns between model nodes. Based on this analysis, the algorithm could determine the communication between the inputs and outputs of a given model (i.e., models 406-408), indicating that including both in the combined TEE (i.e., enclave 402) would be optimal. Alternatively, the algorithm could determine, based on the communication between the first and second enclaves, that a first set of models (e.g., models 206 and 210) should be combined into the first enclave, and a second set of models (e.g., models 212 and 214) should be combined into the second enclave.

[0046] It is also envisioned that enclave 402 could be designed such that communication interface 408 (including enclave switching functionality) could be internally divided into separate internal communication interfaces 410-412, which would then be provided to both models 406 and 404. Alternatively, enclave 402 could be designed such that models 406 and 404 could communicate with each other using internal communication / power / control buses 410-412.

[0047] To encapsulate a single model 402 within the TEE, the process remains the same as that defined for the model provider. To encapsulate multiple models that communicate with each other (e.g., models 406 and 404), the integrator may first need to identify the models that need protection (e.g., models 406 and 404), and these models may be referred to as subsystem-IPs. The integrator can then identify communication buses (e.g., communication buses 216-22 or secure communication buses 222-226) and interfaces (e.g., interfaces 408 and 416-418), which may be required for intra-model communication within the subsystem-IP. Next, the integrator can identify inter-model interfaces (e.g., interfaces 410-412) or direct interfaces with a given model (e.g., interfaces 316-318) for interacting with subsystem-IP components.

[0048] The integrator can then create an enclave 402 that includes subsystem-IPs (e.g., models 404-406) and communication interfaces between subsystem-IP components (i.e., interfaces 408, 416-418). The integrator may also need to extend interface functionality, as well as inter-model and direct interfaces, to include transitions into and out of the enclave 402 execution environment. To protect the confidentiality and integrity of the enclave 402, cryptographic metadata may be included. Such confidentiality and integrity can be implemented by encrypting the enclave 402 using a cryptographic key and then signing the encrypted image using a key that can be verified by the hardware vendor. Similarly, cryptographic keys can be obtained from a key supply server containing a set of keys derived for such purposes. Finally, the models (e.g., models 406 and 404), communication interfaces (both encrypted communication interfaces 222-226 and unencrypted communication interfaces 216-220), and the enclave (enclave 402) acquire a deployable secure system. Such deployment can typically be used by the SiL system 200 (i.e., a cloud simulation platform), which is operable to run simulations and obtain results from them.

[0049] Figure 5The illustration shows how communication within the SiL system 200 can be protected between various models 202-206 and 210-214. As shown, the SiL system 200 may include one or more communication interfaces (i.e., virtual communication bus 216, virtual power line 218, or virtual control network 220) that can be used for unprotected communication between the various modules 202-214. It is further envisioned that secure communication interfaces (i.e., secure virtual communication bus 222, secure virtual power line 224, or secure virtual control network 226) can be used for secure communication between the various modules 202-214. It is also envisioned that communication between models 202-206 and 210-214 can occur via direct connection links, standardized data buses (e.g., virtual CAN bus for automotive systems), or as inputs / outputs of the SiL system 200. Since the input / output data of SiL system 200 can reveal a given structure or detail of a model (e.g., model 202), protecting the interfaces for data exchange and data input / output of SiL system 200 may be necessary to protect each of models 202-206, 210-214.

[0050] Enabling protection for the communication interface requires a "secure" communication network (i.e., secure virtual communication bus 222, secure virtual power line 224, or secure virtual control network 226), as illustrated, which operates in parallel with a conventional, unprotected communication network (i.e., virtual communication bus 216, virtual power line 218, virtual control network 220). It is envisioned that secure networks 222-226 may include any point-to-point link or standardized system bus. It is also envisioned that model interfaces requiring secure input / output functionality (e.g., Figure 3 Interface 322 or Figure 4 Interfaces 408, 416-418 can be connected to a secure network (i.e., secure virtual communication bus 222, secure virtual power line 224, or secure virtual control network 226). Alternatively, as previously explained, unprotected interfaces (e.g., interface 320) can be connected to a conventional network (i.e., virtual communication bus 216, virtual power line 218, or virtual control network 220). It is envisioned that data protection may depend on the integrator's requirements. The model provider can ensure these protections by enabling secure interfaces during the supply phase. However, it is also envisioned that communication 322 can be connected to a conventional network (i.e., virtual communication bus 216, virtual power line 218, or virtual control network 220) because not all connections entering a given enclave (e.g., enclave 324) need to be secure. Instead, only connections from the secure network (i.e., secure virtual communication bus 222, secure virtual power line 224, or secure virtual control network 226) need to enter the secure enclave (e.g., enclave 324).

[0051] Furthermore, it is envisioned that secure communication interfaces 222-226 can implement local proofs (between models) to establish / verify correctness and establish a shared key for each point-to-point link, thereby providing protection for the exchanged data and information. The system and method for establishing the shared key can depend on the functionality supported in the TEE. For example, security can be designed using systems and methods for securely exchanging cryptographic keys over public channels, such as Diffie-Hellman key exchange negotiation.

[0052] For each secure system bus (i.e., secure virtual communication bus 222, secure virtual power line 224, or secure virtual control network 226) shared among multiple nodes (e.g., nodes 502 and 504), models 206 and 210 may need to verify their identity using local authentication. Models 206 and 210 can then use a group key negotiation protocol to establish a shared bus key. Similarly, an example approach could be a group Diffie-Hellman key exchange protocol. Finally, when sending data to the secure interface bus (i.e., secure virtual communication bus 222, secure virtual power line 224, or secure virtual control network 226), the model sending the secure data (e.g., model 206) can first encrypt it using the interface's shared key. When a data frame is received from the sending model (e.g., model 206), the corresponding model (e.g., model 214) can use the shared key to decrypt the data. It is envisioned that the encryption and decryption of data transmitted between models can be implemented using one or more advanced encryption standards (e.g., AES-128) or lightweight or ultralight block ciphers (e.g., SIMON).

[0053] It is envisioned that alternative communication protection embodiments may include: key negotiation between nodes (e.g., nodes 506, 508) may be modified such that models 206, 214 include one or more secure interfaces to perform remote authentication of the integrator using the interface description. It is envisioned that after verifying the correctness of the authentication digest (model), the integrator may then check whether a key for the link associated with the requested model interface has been generated. If the answer is no, the integrator may generate a new encryption key. The integrator may then provide the key to the model (i.e., model 206 or 214) via an established secure channel (e.g., secure virtual communication bus 222). If a key has already been generated, the integrator may provide the key to the model (i.e., model 206 or 214) via the secure channel (i.e., secure virtual communication bus 222). It is envisioned that for secure transmission between channels that can be implemented using such a secure channel, a protocol for establishing authenticated and decrypted links may be used, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

[0054] It is also envisioned that the use of the key remains the same as described in the previous embodiments. However, since the integrator has access to the provided key, it is operable to view the data by obtaining a copy from the SiL system 200 and decrypting the data using the key. Therefore, it is envisioned that the adversary model of this alternative embodiment may include only the computing infrastructure and not the integrator.

[0055] A second alternative communication protection embodiment may include models (e.g., models 206 and 214) utilizing the “sealing” capability of an enclave (e.g., enclave 324) to protect data transmitted via a secure virtual communication bus 222, a secure virtual power line 224, or a secure virtual control network 226. It is envisioned that this second embodiment may require all communication nodes to be operable to derive the same sealing key. Accordingly, the enclave may be operable to derive the sealing key based on the identity (signing key) of the enclave creator.

[0056] Reference Figure 4 In the explained model deployment scenario, all TEEs may need to be signed by the integrator, and therefore the same sealing key can be derived. The use of the sealing key for communication protection can be similar to a link-specific key (e.g., model 206 can use the sealing key to encrypt any data output on interface 222 and decrypt any data received from interface 222 that was transmitted by model 214).

[0057] Figure 6The diagram illustrates how the TEE of the SiL system 200 can protect the processing of each model 202-214. Secure processing may require implementing model provisioning and communication protection. For securely provided models (e.g., model 214), it may be necessary to provide integrators with sufficient metadata, such as interface descriptions for a given model, so that connectivity and configuration can be implemented.

[0058] First, integrators can assemble one or more simulation binary 602 packages by including the provided model 202-214 and connecting it using the necessary secure interfaces 222-226 and insecure interfaces 216-220. The complete simulation binary 602 can then be packaged as a deployable package for simulating the SiL system 200.

[0059] When SiL system 200 performs a simulation for each of models 202-214, the simulation environment can trigger a function to load a given model (e.g., model 202) and prepare it for execution. This can be accomplished using an initialization routine within the model. For secure models (e.g., model 206), the initialization routine can also be responsible for initiating the model's TEE. At block 618, SiL system 200 can obtain a decryption key. This decryption key can be used to decrypt the model enclave image (i.e., model enclave 604) and initiate the model TEE. It is envisioned that the specific systems and methods used to decrypt the model enclave image can be based on details of the platform's TEE initiation capabilities.

[0060] For example, if the functionality is provided by the Protected Code Loader (PCL) capability of an Intel Startup Enclave (LE), a TEE architecture (e.g., Intel SGX) can be used. Boxes 608-614 illustrate an example of how a TEE can start a secondary enclave that performs remote authentication to a model supply entity. At box 606, a secondary enclave can be created based on one or more model enclaves 604 as part of an emulation binary 602. Next, the security of the secondary enclave can be measured. If the security measures of the enclave are verified, the enclave can be initialized at box 612. At box 614, the secondary enclave can perform remote authentication to a model supply entity. After verifying the authentication digest and executing the requirements, the supply entity can return the key (i.e., at box 618). Alternatively, as illustrated in box 620, the key can be sealed by the secondary enclave. At box 622, the sealed key can be provided to the LE simultaneously with the startup of the encrypted model enclave.

[0061] At box 624, the SiL system 200 can initiate the simulation environment and perform simulation steps (i.e., execute the model). For each call to a protected model function, the simulator can first invoke the wrapper function using the input data. The wrapper can then switch functions to model enclave 604 and provide the input data to model enclave 604. The data is processed within model enclave 604, and the model output is updated. Provided the communication link is secure, the model input is decrypted within model enclave 604 before processing and encrypted before updating the output.

[0062] Upon simulation termination, the SiL System 200 simulation environment can invoke the model termination wrapper. The model termination wrapper can invoke platform functions to terminate the safe enclave and preserve any state data that may be needed during future simulations. If the integrity of the results is required, the termination wrapper can also compute any necessary metadata or summary.

[0063] It is also envisioned that the integrity of simulation results is necessary to ensure the absence of malicious behavior by unauthorized parties. This integrity is envisioned to include the integrity of model functionality, data inputs, or data outputs. Furthermore, it is envisioned that packaging the model as a signed enclave (e.g., model 404 or 406) can provide sufficient cryptographic guarantees that the enclave code cannot be modified. Additionally, hardware platform-guaranteed protections for TEE execution may be sufficient to ensure that a given model (e.g., model 206) cannot be modified during runtime. With the model protected, the integrity of data transferred between different nodes and the configuration parameters used for the model may be a final aspect that the SiL system 200 may need to be protected.

[0064] It is conceivable that various methods can be used to verify data integrity. First, each input and output interface of a given model may be required to maintain a summary of the data transmitted through the interface (e.g., data transmitted by model 206 through interface 222). A paradigmatic summary of the interface may include a hash of the data sequence observed on the interface, as shown in equation (1) below:

[0065] Abstract = H(Abstract || New Data) (Equation 1)

[0066] H is a function that satisfies the properties of a cryptographic hash function, such as SHA1, SHA3, or HMAC.

[0067] Furthermore, it is envisioned that upon invoking the termination routine, the given model function can send a digest of each interface to the model integrator who possesses model proof. The method of providing the integrator with the cryptographically signed interface digests can vary or be modified depending on the functionality supported by the TEE platform. For each link, it is further envisioned that the integrator can verify the proof digest from each model. The integrator can then verify the digests of all connected interfaces (e.g., interfaces 222-226) of the link (i.e., models 206 and 214). If all digests match, the integrator can provide a guarantee that the data has not been tampered with by an unauthorized party.

[0068] For the parameter interface, the integrator can calculate a digest of the parameters used as model settings. The integrator can then verify the digest calculated against the received digest. If the digests match, the integrator can be confident that the parameters have not been altered by an unauthorized individual. Finally, for system inputs and outputs, the integrator can calculate local digests of the input and output data. The integrator can then verify the digest reported by the model, which uses this data against the local digests to validate the correctness of the system inputs / outputs.

[0069] An alternative embodiment for ensuring the integrity of the results is envisioned, which may include each node (e.g., node 502 or 504) having a shared node authentication key in addition to the shared encryption key used for the links between models (i.e., models 206 and 210). This shared node authentication key can be derived independently of the encryption key for the links between models. The shared node authentication key can use the same process as the encryption key for the links between models, but with different input randomness. Alternatively, the shared node authentication key can be derived using the master shared key via a hash function. For example, the shared node authentication key can be derived using the following equation (2):

[0070] key_enc = H(shared_key || 00), key_auth = H(shared_key || 11) (Equation 2)

[0071] Where H is a cryptographic hash function, such as SHA1 or SHA3. Although the keys can be different as described above, it is also conceivable that the shared node authentication key and the shared encryption key used for links between models can be the same.

[0072] Alternative methods for ensuring integrity results can further include encrypting the data at each node before sending it over a given link. A given model (e.g., model 206) can then use a shared authentication key to compute a cryptographic message authentication code (MAC) on the encrypted data. For example, model 206 can compute the cryptographic MAC using a function such as a hash-based message authentication code (HMAC) employing the SAH-1 hash function. Integrity results at each node (e.g., node 502) can be guaranteed when data is received on the link by first verifying the MAC of the received data. This is done by computeding the locally expected MAC using the authentication key and checking the received MAC against it. Finally, if data is found to have been tampered with or accessed by an unauthorized party, the model can request the termination of the ongoing simulation by providing an appropriate signal to the simulation environment (i.e., SiL system 200).

[0073] The architecture is envisioned to include container orchestration solutions (e.g., Kubernetes) for scalability and fault tolerance. These solutions could also replace the aforementioned master-enclave process by providing support for the integrity of the orchestrated cluster of proven nodes as a whole, ensuring that only proven nodes can be part of the cluster. Based on SiL System 200 operating environments (e.g., automotive versus aerospace), different TEEs can be used to implement the described architecture.

[0074] The processes, methods, or algorithms disclosed herein are deliverable to or can be implemented by a processing device, controller, or computer, which may include any existing programmable electronic control unit or dedicated electronic control unit. Similarly, the processes, methods, or algorithms may be stored in a variety of forms as data and instructions executable by a controller or computer, including but not limited to information permanently stored on non-writable storage media such as ROM devices and information reproducibly stored on writable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media. The processes, methods, or algorithms may also be implemented as software executable objects. Alternatively, the processes, methods, or algorithms may be implemented wholly or partially using suitable hardware components—such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), graphics processing units (GPUs), intelligent processing units (IPUs), tensor processing units (TPUs), state machines, controllers—or other hardware components or devices, or a combination of hardware, software, and firmware components.

[0075] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms covered by the claims. The terms used in this specification are descriptive and not limiting, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. As previously stated, features of various embodiments may be combined to form other embodiments of the invention that may not be explicitly described or illustrated. Although various embodiments have been described as providing advantages or being preferred relative to other embodiments or prior art implementations, those skilled in the art will recognize that one or more features or characteristics may be compromised to achieve desired overall system properties depending on the specific application and implementation. These properties may include, but are not limited to, cost, strength, durability, lifecycle cost, merchantability, appearance, packaging, size, maintainability, weight, manufacturability, ease of assembly, etc. Accordingly, to the extent that any embodiment is described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics, these embodiments are not outside the scope of this disclosure and may be desirable for a particular application.

Claims

1. A method for protecting software-in-the-loop simulation of a real-world system using one or more Trusted Execution Environments (TEEs), comprising: Assemble one or more unprotected models that can be used to simulate real-world systems. Encrypt one or more unprotected models using the first cryptographic key and generate at least one protected model; Decrypt the at least one protected model using a sealed decryption key; as well as The at least one protected model is executed within one or more TEEs, wherein the at least one protected model is operable to process incoming and outgoing data; The at least one protected model is operable to exchange unprotected data over one or more unprotected communication networks; and the TEE is also operable to encrypt and exchange protected data over one or more protected communication networks using at least a second cryptographic key; and The one or more protected communication networks operate in parallel with the one or more unprotected communication networks.

2. The method according to claim 1, further comprising: Encrypting one or more sub-components within at least one protected model includes the use of secure enclaves.

3. The method according to claim 2, wherein, The incoming and outgoing data include parameters used by the at least one protected model to simulate a real-world system.

4. The method according to claim 2, wherein, The secure enclave is compiled into a dynamic signature library.

5. The method of claim 2, further comprising: in, The secure enclave includes at least one enclave switching function, which is operable to protect internal interfaces within the at least one protected model.

6. The method of claim 5, further comprising: in, The at least one enclave switching function is operable to protect the external interface between the at least one protected model and one or more protected communication networks.

7. The method of claim 2, further comprising: Obtain a sealed decryption key from the key supply server to decrypt the secure enclave image.

8. The method of claim 7, further comprising: Create an auxiliary security enclave that is operable to request a sealed decryption key from a key supply host.

9. The method of claim 2, further comprising: Isolate and protect the execution state of at least one protected model from access without the approval of the access control mechanism of the secure enclave.

10. The method of claim 2, further comprising: Use one or more proof digests to verify the integrity of incoming and outgoing data transmitted from the secure enclave.

11. The method of claim 1, further comprising: Exchanging unprotected data on one or more unprotected communication networks, wherein the one or more unprotected communication networks are operable to transmit unprotected data from an external source, the at least one protected model, or the one or more unprotected models; and Protected data is encrypted and exchanged on one or more protected communication networks using at least a third cryptographic key provided from one or more TEEs, wherein the one or more protected communication networks are operable to transmit the protected data from an external source or at least one protected model.

12. The method of claim 11, further comprising: A third cryptographic key is exchanged between at least the first of the one or more TEEs and at least the second of the one or more TEEs to verify the integrity of incoming and outgoing data.

13. The method of claim 12, further comprising: The third cryptographic key is obtained by an external system from at least the third of the one or more TEEs; And the protected data is ingested from a third of the one or more TEEs into an external system.

14. The method according to claim 1, wherein, The software-in-the-loop simulation is implemented using a virtualized operating environment.

15. The method according to claim 14, wherein, The one or more TEEs are operable to provide security guarantees between the virtualized operating environment and one or more external hardware components.

16. The method of claim 1, further comprising: One or more proof digests are used to verify the integrity of incoming and outgoing data, said proof digests being transmitted by the software upon termination of loop simulation, wherein said proof digests are used to verify the integrity of incoming and outgoing data transmitted from said at least one protected model.

17. The method of claim 1, further comprising: A multi-model security enclave is generated by encrypting at least two of the one or more unprotected models.

18. The method of claim 1, further comprising: The first cryptographic key is provided using the Diffie-Hellman key exchange.

19. A system for protecting software-in-the-loop (SiL) simulation of a real-world system using one or more Trusted Execution Environments (TEEs), comprising: Memory; as well as Processor, operable to: Assemble one or more unprotected models that can be used to simulate real-world systems. Encrypt one or more unprotected models using the first cryptographic key and generate at least one protected model; Decrypt the at least one protected model using the second cryptographic key; and The at least one protected model is executed within one or more TEEs, wherein the at least one protected model is operable to process incoming and outgoing data; The at least one protected model is operable to exchange unprotected data over one or more unprotected communication networks; and the TEE is also operable to encrypt and exchange protected data over one or more protected communication networks using at least a second cryptographic key. The one or more protected communication networks operate in parallel with the one or more unprotected communication networks.

20. A method for protecting a real-world system using one or more Trusted Execution Environments (TEEs) for software-in-the-loop (SiL) simulation, comprising: Assemble one or more unprotected models that can be used to simulate real-world systems. Encrypting from the one or more unprotected models using at least a first cryptographic key and generating two or more protected models, wherein the two or more protected models are included within at least one of the one or more TEEs; Decrypt the two or more protected models using the second cryptographic key; and Execute the two or more protected models, wherein the two or more protected models are operable to process incoming and outgoing data; The protected model is operable to exchange unprotected data over one or more unprotected communication networks; and the TEE is also operable to encrypt and exchange protected data over one or more protected communication networks using at least a second cryptographic key; and The one or more protected communication networks operate in parallel with the one or more unprotected communication networks.

Images