Establishing trust between distributed services in a software defined vehicle

Abstract

A method includes generating, in a computing system, a key pair for a first trust manager of the first virtual machine, wherein the key pair is bound to a current boot state of processing circuitry, and wherein the key pair is verified by each stage of a compute stack of the first virtual machine. The method further includes sending, by the first trust manager, a public key of the key pair to a second trust manager. The method further includes verifying, by the second trust manager, the first trust manager for the second virtual machine. The method further includes verifying the first trust manager based at least in part on the public key, verifying, by the second trust manager, a first service of the first virtual machine. The method further includes calling, by a second service of the second virtual machine, the first service of the first virtual machine.

Description

ESTABLISHING TRUST BETWEEN DISTRIBUTED SERVICES IN A SOFTWARE DEFINED VEHICLE

[0001] This application is a PCT that claims the benefit of US Provisional Patent Application No. 63 / 586,276, filed 28 September 2023, the entire contents of which is incorporated herein by reference.BACKGROUND

[0002] In many computing systems, identifiers (IDs) are typically used to refer to entities, locations, and / or resources. Identifiers are useful for managing system resources like processor time, memory, and disk space. Trusted identifiers are often used to increase the effectiveness of computer security built into a computing system. In some automotive vehicles, distributed software services are being used to manage functions and / or operations of the vehicle. This technology is sometimes referred to as software defined vehicles (SDV). SDVs are essentially a distributed computing system where system components (such as distributed services) interact with each other within the vehicle.SUMMARY

[0003] In general, various aspects of the techniques of this disclosure are directed to establishing mutual validation and trust between distributed services in a computing system. In an implementation, the computing system is included within a vehicle designed as a software defined vehicle(SDV). As opposed to using secure identifiers for individual services, the techniques of this disclosure may enable a computing system to use a multidimensional trust model that provides trusted identity tokens for both vertical and horizontal establishing of trust among services. The multidimensional trust model includes a vertical aspect along a verifiable chain-of-trust in a computing device of the SDV’s distributed computing system, such as a system on a chip (SoC), from the underlying hardware of the computing device to a software stack running on such hardware. The multidimensional trust model also includes a horizontal aspect between components, such as distributed services, of the SDV’s distributed computing system. The multidimensional trust model allows distributed services of the SDV to be developed with multiple ways to verify system integrity.

[0004] In this way, the techniques of this disclosure enable computing systems to mutually authenticate services within an automobile (or other vehicle) using both vertical and horizontal authentication of trust. The use of horizontal and vertical authentication amongservices may improve security among services by eliminating the need for secure identifiers that can be spoofed by an attacker. The use of horizontal and vertical authentication may also reduce development costs for computing systems with a substantial number of disparate components and services. Further, the use of horizontal and vertical authentication to establish trust may obviate the need for communications outside of the computing system to authenticate services.

[0005] In one example, a method includes generating, in a computing system including processing circuitry configured to execute at least a first virtual machine and a second virtual machine, a key pair for a first trust manager of the first virtual machine, wherein the key pair is bound to a current boot state of the processing circuitry, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; sending, by the first trust manager, a public key of the key pair to a second trust manager; verifying, by the second trust manager, the first trust manager for the second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verifying, by the second trust manager, a first service of the first virtual machine; and calling, by a second service of the second virtual machine and based on the verification of the first service, the first service of the first virtual machine.

[0006] In another example, a computing system comprises a memory and one or more programmable processors in communication with the memory, and configured to generate a first key pair for a first trust manager of a first virtual machine, wherein the key pair is bound to a current boot state of the one or more programmable processors, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; send, by the first trust manger, a public key of the key pair to a second trust manager; verify, by the second trust manager, the first trust manager for a second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verify, by the second trust manager, a first service of the first virtual machine; and call, based on the verification of the first service, the first service of the first virtual machine.

[0007] In another example, a non-transitory computer-readable medium, is encoded with instructions that cause one or more processors of a computing system to generate a first key pair for a first trust manager of a first virtual machine, wherein the key pair is bound to a current boot state of one or more processors, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes thefirst trust manager; send, by the first trust manger, a public key of the key pair to a second trust manager; verify, by the second trust manager, the first trust manager for a second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verify, by the second trust manager, a first service of the first virtual machine; call, based on the verification of the first service, the first service of the first virtual machine.

[0008] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. l is a block diagram illustrating an example computing system in accordance with one or more aspects of the present disclosure.

[0010] FIG. 2 is a block diagram illustrating an example computing system in accordance with one or more aspects of the present disclosure.

[0011] FIG. 3 is a block diagram illustrating an example computing system in accordance with one or more aspects of the present disclosure.

[0012] FIG. 4 is a flowchart illustrating an example process for establishing a multidimensional trust model in a computing system in accordance with one or more aspects of this disclosure.

[0013] FIG. 5 is a flowchart illustrating an example process for establishing trust between distributed services in a computing system in accordance with one or more aspects of this disclosure.

[0014] FIG. 6 is a flowchart illustrating an example process for establishing a multidimensional trust model in a computing system in accordance with one or more aspects of this disclosure.DETAILED DESCRIPTION

[0015] FIG. 1 is a block diagram illustrating computing system 100 in accordance with one or more aspects of the present disclosure.

[0016] Computing system 100 may include one or more computing devices such as automotive head units, engine control units (ECUs), engine control module (ECM), control systems, servers, computing devices, drone swarms that each include a plurality of drones, full authority digital engine controls (FADECs), automotive computing modules, dynamicinternet of things (loT) networks, Al-pins, Al-enabled glasses / goggles, virtual reality (VR) / augmented reality (AR) glasses / goggles, and other computing devices. Computing system 100 may include a plurality of components that are interconnected to form a computing network of a vehicle such as an automobile. Computing system 100 may provide the functionality of a software-defined vehicle (SDV). Computing system 100 includes system on a chip (SoC) 104 A and 104B (hereinafter “SoCs 104”), trusted execution environment (TEE) / trusted platform module (TPM) 106 A and 106B (hereinafter “TEE / TPMs 106”), and VM 102A and 102B (hereinafter “VMs 102”).

[0017] Computing system 100 includes one or more processors and systems on chips such as SoCs 104. SoCs 104 may each include one or more processing cores and chiplets on a single chip. For example, SoC 104A may include multiple processing cores in addition to memory and security chiplets. SoCs 104 may each include one or more security components such as TEE / TPMs 106. Although described with respect to SoCs 104, various aspects of the techniques may be executed by different hardware processors or processing circuitry, including display processors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), computing processors, etc.

[0018] TEE / TPMs 106 may include one or more security components or environments. For example, TEE / TPMs 106 may include a secure cryptographic processor that stores a root of trust for the SoC. In another example, TEE / TPMs 106 includes tamper-proof secure hardware. In yet another example, TEE / TPMs 1065 are provisioned at time of manufacture or installed into computing system 100 with secure cryptographic materials. Further, TEE / TPMs 106 may include a secure execution environment for SoC 104 and 132. TEE / TPMs 106 may additionally provide secure hardware (that may be tamper-resistant) for secure cryptographic processes for generating, protecting, and managing secure information (e.g., keys).

[0019] SoCs 104 may use TEE / TPMs 106 to provide a basis for a root-of-trust chain from the TEE / TPMs for components running in the SoCs. For example, SoC 104A may use TEE / TPM 106 A to provide a root-of-trust chain from SoC 104 up through one or more VMs executed by SoC 104 such as VM 102. SoC 104A may provide a root-of-trust chain that provides a chain of trust from a secured physical module up through the various software components of computing system 100.

[0020] Computing system 100 may execute one or more virtual machines such as VMs 102. Computing system 100 may execute a virtual machine to provide an execution environment for services and applications of computing system 100. VMs 102 may be virtual machines, pods, or containerized workloads, among other types of virtualized computingenvironments. VMs 102 may provide an execution environment for one or more processes such as OS kernels 108A and 108B (hereinafter “OS kernels 108”), trust managers 110A and HOB (hereinafter “trust managers 110”), and applications 112, 118, 136, and 142.

[0021] VMs 102 may execute OS kernels 108. VMs 102 may execute OS kernels 108 that include one or more types of operating system kernel such as a Linux® kernel, Windows NT kernel, Unix-based kernel, hybrid kernel, or one or more proprietary operating system kernels. OS kernels 108 may propagate a root-of-trust chain up from TEE / TPMs 106 through to one or more processes executing within VMs 102 such as trust manager 110A.

[0022] VMs 102 provide an execution environment for trust managers such as trust managers 110A and HOB (hereinafter “trust managers 110”). Although only shown as executing a single trust manager, each of VMs 102 may execute a plurality of trust managers. Trust managers 110 may be an application, plugin, component of OS kernels 108, or other type of software component executing within VMs 102. Trust managers 110 may manage keys generated by computing system 100, manage and assign identity tokens ITs to services, and synchronize and verify these ITs anywhere across computing system 100, and use the ITs (and keys) to perform authentication and authorization. In some examples, trust managers110 may store ITs that include a human readable name of the service to which the IT is assigned and enable specification of access control lists using human readable names of services.

[0023] Trust managers 110 include keys 111 A and 11 IB (hereinafter “keys 111”). Trust managers 110 may execute keys 111 as repositories and managers for pairs of keys associated with applications and services executing within VMs 102, as well as key pairs of trust managers 110. Keys 111 may store and maintain pairs of keys that include a private key, and a public key that is shared with other services and applications. Keys 111 may store keys that are generated by computing system 100. For example, key 111 A may store and manage a private key and a public key for service 114.

[0024] Trust managers 110 may mutually validate each other using keys stored in keys111 and using vertical-horizontal attestation. Trust managers 110 may mutually validate each other and establish trust between each other. Trust managers 110 may establish trust to enable secure communications between applications and services of VMs 102 to securely communicate and interact. In addition, trust managers 110 may perform remote attestation to establish trust between the trust managers.

[0025] Trust managers 110 may mutually validate each other using key pairs. Trust managers 110 may use pairs of keys that are bound to a current boot state of SoC 104 andvalidated by layers of the compute stack originating at SoC 104. In an example, computing system 100 generates a pair of keys that includes a public key and a private key. Computing system 100 binds the keys to a current boot state of SoC 104 A. SoC 104 A, TEE / TPM 106 A, and OS kernel 108 A, in progression, verify the pair of keys for trust manager 110 in stages. Trust manager 110A may cause each of SoC 104A, TEE / TPM 106A, and OS kernel 108 A to verify the pair of keys in turn and retain a root-of-trust propagated upwards from SoC 104 A to trust manager 110A.

[0026] Trust managers 110 may exchange public keys of trust managers 110 amongst each other for validation. Trust managers 110 may exchange public keys and mutually authenticate. In an example, trust manager HOB provides the public key of a pair of keys to trust manager 110A. Trust manager 110A, based on receiving the public key from trust manager HOB, verifies trust manager 110B. Trust managers 110 may use remote attestation to verify each other. For example, trust manager 110A may perform remote attestation with trust manager 110B via attestation 150. Trust managers 110 may perform remote attestation in which a remote computing system component (e.g., a remote device’s hardware and software stacks, the stack from SoC 104B up through trust manager 110B) are verified by a local computing system component (e.g., a local device’s hardware and software, the stack from SoC 104A to up through trust manager 110A). Trust managers 110, when the components share the same root-of-trust, may verify any other of trust managers 110 through mutual validation of identities and integrity measurements.

[0027] VMs 102 may provide an execution environment for a plurality of applications. For example, VM 102 A may provide an environment for application 112 which includes services 114 and 116. In another example, VM 102A may execute application 118 that provides an automotive infotainment system, while VM 102B executes application 142 that manages an emissions management system. VMs 102 may execute applications that include one or more services.

[0028] VMs 102 may provide an execution environment for a plurality of services that execute within the plurality of applications. The plurality of services, such as services 116, 122, and 146, may provide functionality of the applications within VMs 102. For example, one or more services may provide the functionality of a distributed application that includes the one or more services. One or more of the services may communicate with services executing on different VMs of VMs 102. For example, service 120 may call service 140 via communications 152.

[0029] Trust managers 110 may verify services based on ITs associated with the services. Trust managers 110 may assign a unique IT to each service and periodically cycle the unique ITs. For example, trust managers 110A may assign IT 121 to service 120 and IT 123 to service 122. Trust managers 110 may assign ITs to services and enable verification and secure communications among services executing on different VMs. Trust managers 110 may verify services executing on other VMs based on the identity tokens of the services. Trust managers 110 may, for each registered service, generate an IT that is cryptographically bound to the package name of the service, the digital signature of the package, and the trust manager that issues the IT. Accordingly, an attacker would need to compromise both the package’s digital signature and the secure hardware (e.g., from the root-of-trust) in the computing system 100. Once services are registered and cryptographically validated, any service may communicate with any other server, anywhere in the computing system 100 (e.g., the service is discoverable). In some examples, trust managers 110 may perform mutual authentication based on the extended triple Diffie-Hellman (X3DH) protocol using X25519 cryptographic keys. The X3DH key agreement protocol allows two parties to mutually authenticate each other using an asynchronous key exchange, where the two parties exchange a session key without having to be connected to a communications interface at the same time. X25519 cryptographic keys are elliptic-curve cryptographic (ECC) keys allowing sharing of a secret over an insecure channel. Successful mutual authentication proves the authenticity of the services and the integrity of the host hardware and software stack (from the hardware root-of- trust to the application services). Additional information regarding mutual authentication based on X3DH protocol is found in “The X3DH Key Agreement Protocol”, 2016, Marlinspike, et al., Signal Foundation, which is incorporated by reference herein in its entirety.

[0030] Trust managers 110 may perform authentication, scalable cross-SoC, cross-host verification and trust establishment for computing system 100, which may be resident in a SDV. In some examples, trust managers 110 may perform the authentication without communication with external computing systems (e.g., cloud servers). For example, trust managers 110 may perform authentication while only communicating within computing system 100 and without the aid of authentication software or components external to computing system 100. Trust managers 110 may perform authentication across multiple computing devices within an SDV that share a verifiable root-of-trust at each layer of a computing stack of computing system 100.

[0031] The techniques of this disclosure include one or more practical advantages. For example, instead of relying upon secure identifiers that can be compromised by an attacker, trust managers 110 improve security through reliance upon a chain of trust that originates from physical hardware of computing system 100. In another example, trust managers 110, through reliance upon the physical hardware and chain of trust, avoid the requirement of connecting to an external network to update secure identifiers and conduct verification of services within computing system 100. In yet another example, trust managers 110 may enable trust and mutual authentication between components that are not consistently operable.

[0032] FIG. 2 illustrates further details of an example computing system in accordance with one or more aspects of the present disclosure. For the purposes of clarity, one or more components of computing system 200 are described below as an example of computing system 100 as illustrated in FIG. 1. Computing system 200 may be a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, a mainframe, a set-top box, a television, a wearable system, an automation system or system, a gaming system, a media player, an e-book reader, a mobile television platform, an automobile navigation or infotainment system, vehicle control system, drone swarm that includes one or more drones, dynamic loT network with one or more loT devices, Al pin, Al glasses / goggles, VR / AR glasses / goggles, or any other type of mobile, non-mobile, wearable, and non-wearable computing system. FIG. 2 illustrates only one example of computing system 200, and many other examples of computing system 200 may be used in other instances and may include a subset of the components included in example computing system 200 or may include additional components not shown in FIG. 2. For example, computing system 200 may be included within an SDV and provide one or more types of functionalities for the SDV.

[0033] As shown in the example of FIG. 2, computing system 200 includes SoC 204, user interface component 212 (hereinafter “UIC 212”), one or more processors 240, one or more input components 242, one or more communication units 244, one or more output components 246, TPM 206, and one or more storage components 248. SoC 204 may be an entire system on a chip, where each component of SoC 204 is a chiplet of SoC 204. In other examples, SoC 204 may include one or more packages combined to form a package on a package chipset. For example, storage components 248 may be physically separate components from SoC 204 and communicate with SoC 204 via communication channels 260.

[0034] Communication channels 260 (illustrated as “COMM. CHANNELS 260” in FIG. 2) may interconnect each of the components 206, 212, 240, 242, 244, 246, and 248 for inter-component communications (physically, communicatively, and / or operatively). In some examples, communication channels 260 may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data. For example, communication channels 260 may interconnect storage components 248 to other components for computing system 200. In another example, communication channels 260 interconnect input components 242 to other components of computing system 200.

[0035] One or more input components 242 of computing system 200 may receive input. Input components 242 may receive input such as tactile, audio, and video input. Input components 242 of computing system 200, in one example, includes a presence-sensitive display, touch-sensitive screen, mouse, keyboard, voice responsive system, video camera, microphone or any other type of system for detecting input from a human or machine.

[0036] One or more output components 246 of computing system 200 may generate output. Output components 246 may generate output such as tactile, audio, and video output. Output components 246 of computing system 200, in one example, includes a presencesensitive display, sound card, video graphics adapter card, speaker, liquid crystal display (LCD), organic light-emitting diode (OLED) display, a light field display, haptic motors, linear actuating systems, or any other type of system for generating output to a human or machine.

[0037] UIC 212 of computing system 200 may be hardware that functions as an input and / or output system for computing system 200. For example, UIC 212 may include a display component, which may be a screen at which information is displayed by UIC 212 and a presence-sensitive input component that may detect an object at and / or near the display component.

[0038] One or more communication units 244 of computing system 200 may communicate with external systems via one or more wired and / or wireless networks by transmitting and / or receiving network signals on the one or more networks. Communication units 244 may include a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of system that can send and / or receive information. Communication units 244 may also include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers. In some examples, computing system 200 may communicate using only internal communications when communication units 244 lose connectivity to external networks. For example, due to the mobile nature of a vehicle in which computing system 200 is integrated, computing system 200 may enter areas with little to no cellular or wireless internet access.Communication units 244 may then be unable to provide external connectivity to one or more components of computing system 200 such as processors 240.

[0039] Computing system 200 includes TPM 206. TPM 206 may be a type of trusted platform module or other secure chipset that provides security resources. For example, TPM 206 may store keys for use by virtual machines. TPM 206 may act as a step in securing chain of trust or root-of-trust chain from SoC 204 up through to various components of computing system 200.

[0040] Computing system 200 includes processors 240. Processors 240 may be one or more types of processors such as application-specific integrated circuit (ASIC), field- programmable gate array (FPGA), reduced instruction set computer (RISC) processor, general-purpose processor, or other type of processor. Processors 240 may include one or more cores and / chiplets configured to implement functionality and / or execute instructions within computing system 200. For example, one or more processors 240 on computing system 200 may receive and execute instructions stored by one or more storage components 248 that execute the functionality of VMM 209, OS kernel 208, trust manager 210, one or more applications 218, and one or more services 220. The instructions executed by one or more processors 240 may cause computing system 200 to store information within one or more storage components 248 during program execution. Examples of one or more processors 240 include application processors, display controllers, sensor hubs, and any other hardware configured to function as a processing unit. One or more processors 240 may execute instructions of VMM 209, OS kernel 208, trust manager 210, one or more applications 218 and one or more services 220 to perform actions or functions.

[0041] Computing system 200 includes storage components 248. Storage components 248 may include one or more types of storage such as solid state storage, random access memory (RAM), hard disk drives, eMMC memory, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories, and other types of storage. Storage components 248 may store data for one or more programs and processes. Storage components 248 of computing system 200 also includes VM 202, OS kernel 208, virtual machine manager (VMM) 209, trust manager 210 (including keys 211), and one or more applications 218, which include one or more services 220. Storage components 248 may include a computer program product that includes instructions of one or more software components of computing system 200 that are executed by processors 240. For example, storage components 248 may include the instructions of VMM 209.

[0042] Computing system 200 may execute VMM 209. VMM 209 may be a program, plugin, hypervisor, or other type of process. VMM 209 may manage one or more virtual machines executed by computing system 200 such as VM 202. VMM 209 may manage the execution of the one or more virtual machines and verify the integrity of an operating system image, such as an image of OS kernel 208, before booting the operating system within the virtual machine. In some examples, VMM 209 may implement secure booting using Device Identifier Composition Engine (DICE). Additional information regarding DICE secure booting is found at DICE specification “Trusted Platform Architecture Hardware Requirements for a Device Identifier Composition Engine”, family 2.0, level 00, revision 69, dated December 16, 2016, or later versions.

[0043] Computing system 200 may execute one or more virtual machines such as VM 202. Computing system 200 may execute virtual machines to provide execution environments for various applications within computing system 200. For example, computing system 200 may execute a virtual machine that provides an execution environment for a vehicle infotainment system and a virtual machine for safety functions of an SVD (e.g., door locks, airbag system, collision avoidance system, self-driving capabilities, etc.).

[0044] VM 202 includes OS kernel 208. OS kernel 208 may be an operating system kernel of a first host (e.g., SoC 104 as illustrated in FIG. 1) and associated hardware and software stack). OS kernel 208 may provide a step in a root-of-trust from SoC 204 up through applications such as application 218. OS kernel 208 may provide an operating system in which applications such as application 218 execute.

[0045] VM 202 includes application 218. VM 202 may execute one or more applications that provide functionality for different elements of computing system 200. For example, VM 202 may execute application 218 that may be a vehicle infotainment system and provide functionality such as media playback, vehicle information, and other functions. In another example, application 218 provides vehicle diagnostics functions and analyzes data generated by components of an SDV in which computing system 200 is incorporated. In yet another example, application 218 manages self-driving functionality of the SDV. Application 218 may include one or more services such as service 220 that provide functionality of application 218. For example, application 218 may be a distributed application composed of services that call other services and provide the functionality of application 218. Application 218 may execute services that call other services executing in a different application and / or different application executing within a different VM from VM 202.

[0046] Service 220 includes identity token (IT) 221. IT 221 may be a unique identifier of a service such as service 220. Trust manager 210 may assign IT 221 to service 220. Trust manager 210 may cause one or more components of a compute stack of computing system 200 to verify IT 221 at each layer of the compute stack. For example, trust manager 210 may cause SoC 204, TPM 206, and OS kernel 208 to verify the integrity of IT 221.

[0047] VM 202 includes trust manager 210. Trust manager 210 may be a service or application executing within VM 202 that manages keys 211 for one or more applications and services within VM 202. For example, trust manager 210 may maintain pairs of public and private keys for applications and services. Trust manager 210 may maintain pairs of keys that are based on a root-of-trust that originates from SoC 204 and propagates upwards to trust manager 210. For example, trust manager 210 may assign and maintain keys that are bound to the state of SoC 204 and are verified in part by the root-of-trust originating from SoC 204.

[0048] Trust manager 210 may authenticate other virtual machines of computing system 200 and perform remote attestation of other virtual machines, trust managers, and services of the virtual machines. In an example, trust manager 210 sends a public key of a key pair associated with trust manager 210 to a second trust manager executing within a second VM of computing system 200. The second trust manager performs remote attestation and verifies trust manager 210 for the second VM. Based on verifying trust manager 210, the second trust manager verifies one or more services of VM 202 such as service 220. In another example, trust manager 210 authenticates other trust managers and services of other VMs and enables secure communications between the authenticated services. In addition, trust manager 210 may exchange ITs with other trust managers and services to enable mutual authentication and the establishing of trust among the trust managers and services.

[0049] Trust manager 210 includes IT manager 261. IT manager 261 may manage ITs of one or more services. IT manager 261 may be a plugin or module of trust manager 210. In some examples, IT manager 261 may operate alongside keys 211. In some examples, IT manager 261 may establish trustworthiness of ITs of one or more services. IT manager 261 may generate and manage the ITs of services such as IT 221. IT manager 261 may generate IT that are tamper-proof service identifiers. IT manager 261 may generate ITs such as IT 221. IT manager 261 may generate an IT for each service of VM 202 that is registered with IT manager 261. IT manager 261 may generate ITs that are cryptographically bound to the package name of the service and the digital signature of the package.

[0050] IT manager 261 may execute in a consensus mode with IT managers executing within other VMs and on other SoCs. IT manager 261, responsive to a change in theconfiguration of IT manager 261, may cause the change to occur in the configuration of other IT managers. IT manager 261 may execute in a distributed mode across one or more SDV computing systems.

[0051] FIG. 3 is a block diagram illustrating computing system 300 in accordance with one or more techniques of this disclosure. Computing system 300 includes communications interface 324 and SoCs 304A and 304B (hereinafter “SoCs 304”).

[0052] Computing system 300 includes one or more systems on chips such as SoCs 304. SoCs 304 may be systems on chips that include one or more components and / or chiplets and chipsets such as processors, memory, secure components, and other components. SoCs 304 may execute one or more instructions of software of computing system 300. SoCs 304 may communicate with each other via communications interface 324.

[0053] Computing system 300 includes communications interface 324. Communications interface 324 may be one or more types of interconnect or communication interfaces between one or more components of computing system 300. For example, communications interface 324 may enable communications between VM 302A and VM 302B.

[0054] SoCs 304 execute VMs 302A, 302B, and 302C (hereinafter “VMs 302”). VMs 302 may include one or more virtual machines or virtualized computing environments. VMs 302 may provide an execution environment for one or more applications and services. For example, VMs 302 may provide an execution for applications of an SDV such as an infotainment system and an engine management system. VMs 302 may communicate via communications interface 324. VMs 302 may communicate via communications interface 324 and enable communications between one or more services executing within each VM and communication with services and components logically lower on a computing stack such as SoCs 304. For example, VMs 302 enable trust managers such as trust managers 310A and 310B to communicate. In another example, VMs 302 may enable trust manager 310 to communicate with SoC 304 A and generate key pairs bound to the boot state of SoC 304 A.

[0055] Trust managers 310 may verify each other and establish trust between each other. Trust managers 310 may perform remote attestation to verify each other. In an example, trust manager 310B seeks to verify trust manager 310A and enable secure communications with trust manager 310A. Trust manager 310A sends a public key of a key pair associated with trust manager 310A via communications interface 324. Trust manager 310B receives the public key and verifies trust manager 310A based on the public key. In some examples, trust manager 310B verifies the trust manager based on the public and confirming that the public key is part of a root-of-trust originating from SoC 304A.

[0056] VMs 302 include trust managers 310A, 310B, and 3 IOC (hereinafter “trust managers 310”). Trust managers 310 may manage authentication of applications and services of different virtual machines of VMs 302. Trust managers 310 may generate pairs of keys that include a private key and a public key. Trust managers 310 may bind the key pair to a current boot state of SoCs 304. Trust managers 310 may bind the keys to the current boot state of SoC 304 and cause each stage of a compute stack of computing system 300 to verify the pairs of keys.

[0057] VMs 302 may include services 315, 317, 339, and 360. Each VM of VMs 302 may execute a service that provides functionality for one or more applications. For example, VM 302A includes services 315 and service 317. In another example, VM 302B includes service 339. One or more services executed by VMs 302 may communicate with and call other services.

[0058] Trust managers 310 may verify services executing on other VMs of VMs 302. Trust managers 310 may verify services responsive to a request from a service. For example, service 315 executing on VM 302A wishes to call service 339 executing on VM 302B. Service 315 requests that trust manager 310A verify service 339. Trust manager 310B, responsive to verification by trust manager 310A, provides an IT of service 339 to trust manager 310A. Trust manager 310B may provide ITs of each service executing within VM 302B to trust manager 310A in response to an initial verification of trust manager 310B by trust manager 310A. Trust manager 310B may provide ITs that include a unique identifier of each service of VM 302B. Trust manager 310B may provide ITs of services executing within VM 302B to trust manager 310A in response to a request by trust manager 310B and / or one or more services executing within VM 302B. Trust manager 310A verifies the IT of service 339. Responsive to the verification of the IT of service 339, service 315 call service 339. Service 315 may communicate via a secure communication session over communications interface 324.

[0059] FIG. 4 is a flowchart illustrating example authentication process 400 for establishing a multidimensional trust model in a computing system in accordance with one or more aspects of this disclosure. For the purposes of clarity, FIG. 4 is described in the context of FIG. 1.

[0060] A computing system, such as computing system 100, may boot a system on a chip such as SoC 104A (402). Computing system 100 may boot SoC 104A that includes one or more chipsets such as memory, one or more processors, and secure components. SoC 104 A may boot and execute instructions of one or more programs. SoC 104A may provide the basisfor a root-of-trust that propagates upward through the compute stack of SoC 104 A. SoC 104A may verify a key pair that is bound to the boot state of SoC 104A and provide it to a secure component of computing system 100.

[0061] Computing system 100 boots a trusted execution environment (TEE) and / or a trust platform module (TPM) such as TEE / TPM 106A (404). Computing system 100 boots TEE / TPM 106 A to provide a secure computing environment for one or more services executed by computing system 100. TEE / TPM 106A may be a standalone component that provides the secure components. For example, TEE / TPM 106A may provide a secure, independent component that stores information for one or more components of computing system 100. TEE / TPM 106A may act as a stage in a root-of-trust originating from SoC 104A as part of the compute stack of computing system 100. TEE / TPM 106A may receive a key pair bound to the boot state of SoC 104 A and verify the key pair. TEE / TPM 106 A may provide the verified key pair to an operating system of computing system 100.

[0062] Computing system 100 boots and verifies an operating system kernel such as OS kernel 108 A (406). OS kernel 108 A may provide an operating system for an execution environment for a virtual machine of computing system 100 such as VM 102 A. Computing system 100, responsive to booting OS kernel 108 A, verifies OS kernel 108 A. Computing system 100 may verify OS kernel 108 A to maintain a root-of-trust originating from SoC 104 A and propagated upwards through TEE / TPM 106 A.

[0063] Computing system 100 generates a key pair bound to a current boot state of SoC 104 A for each trust manager for each VM of computing system 100 (408). Computing system 100 executes one or more trust managers such as trust managers 110. Trust managers 110 manage key pairs and may communicate amongst each other. Trust managers may also maintain ITs for one or more services executed by a VM.

[0064] Trust managers 110 may exchange public keys of pairs of keys (410). Trust managers 110 may exchange public keys of key pairs to perform remote attestation and to mutually authenticate each other to establish trust between trust managers 110. For example, trust manager 110A provides a key of keys 111 A to trust manager HOB.

[0065] Each trust manager of trust managers 110 verifies the integrity and authenticity of other trust managers (412). Trust managers 110 may verify the integrity and authenticity of other trust managers and, by extension, verify the VMs associated with the trust managers. In an example, trust manager HOB verifies trust manager 110A based on the public key of the key pair that has been verified at each stage of the compute stack executing trust manager 110A. Trust managers 110 may establish trustworthiness of trusted identifiers betweencomponents of computing system 100 that includes components of distributed SDV computing systems. Trust managers 110 may establish the trustworthiness of the trusted identifiers using an identifier module.

[0066] Trust managers 110 in each VM verifies the integrity of each service and generates an identity token (IT) for each service (414). VMs 102 may execute multiple applications and services. Trust managers 110 may verify the applications and services of each VM 102 and enable the services to securely communicate with each other. Trust managers 110 may verify services such as service 122 and generate a unique IT for each service.

[0067] FIG. 5 is a flowchart illustrating example process 500 for establishing trust between distributed services in a computing system in accordance with one or more aspects of this disclosure. For the purposes of clarity, FIG. 5 is described in the context of FIG. 1.

[0068] A computing system, such as computing system 100, starts a first service, such as service 121, and gets a first identity token (IT), such as IT 121, from a trust manager such as trust manager 110A (502). Computing system 100 may start service 121 executing within VM 102 A as a service providing functionality for an application executing within VM 102 A. Trust manager 110A may automatically generate IT 121 as a unique, secure identifier responsive to computing system 100 starting service 120. Trust manager 110A may generate IT 121 using a root-of-trust to ensure the security and integrity of IT 121.

[0069] Computing system 100 starts a second service, such as service 140, and gets a second IT, such as IT 141, from a second trust manager, such as trust manager HOB (504). Trust manager HOB may generate IT 141 responsive to computing system 100 starting service 140. Trust manager 110B may generate IT 141 using a root-of-trust originating from SoC 104B to ensure the integrity and security of IT 141.

[0070] Service 121 and service 140 exchange ITs (506). Service 121 and service 140 may exchange ITs via trust managers 110A and 110B. For example, service 121 may provide an indication to trust manager 110A to share IT 121 to trust manager 110B. In another example, service 121 may provide IT 121 to service 140 via communications 152.

[0071] Service 121 and service 140 respectively validate IT 141 and IT 121 using trust managers 110 (508). For example, service 121 may cause trust manager 110A to verify IT 141 received from service 140. In another example, trust manager 110A may verify IT 141 responsive to receiving IT 141 from VM 102B. Trust managers 110 may validate the ITs based on the root-of-trust established by the other respective trust managers 110.

[0072] Trust managers 110 may determine whether the ITs were validated (510). Trust managers 110 may determine whether the validation succeeded based on whether the ITs included a root-of-trust chain that was validated by every layer of a compute stack underlying the respective service. In an example, trust manager 110A, responsive to receiving IT 141, determines whether a root-of-trust of IT 141 included verification at SoC 104B, TEE / TPM 106B, and OS kernel 108B.

[0073] Trust managers 110 may determine that one or more ITs were not validated (NO branch of 510). Trust managers 110, responsive to the failure of the validation, do not allow communication with the service whose IT was not validated and provide an error indication (512). For example, trust manager 110A determines that IT 141 of service 140 was not successful. Trust manager 110A, responsive to the failure of the verification, does not allow service 120 to communicate with service 140. In another example, trust manager HOB determines that authentication of trust manager 110A failed. Trust manager HOB, responsive to the determination, generates an alert that includes information regarding the failed authentication. Trust manager 110B may generate an alert that includes a human-readable name of the service that failed to be authenticated. Trust manager 110B may cause computing system 100 to output the alert to a user.

[0074] Trust managers 110 may determine that the one or more ITs were validated (YES branch of 510). Services 120 and 140 establish a trust between each other based on the success of the validation (514). Services 120 and 140 establish a trust based on the mutual authentication between each other. Services 120 and 140, based on establishing the trust, may call each other. For example, service 120 may call service 140 as part of providing the functionality of an application underpinned by service 120.

[0075] FIG. 6 illustrates example process 600 for establishing a multidimensional trust model in a computing system in accordance with one or more aspects of this disclosure. For the purposes of clarity, FIG. 6 will be discussed in the context of FIG. 1.

[0076] A computing system, such as computing system 100, generates a key pair for a first trust manager, such as trust manager 110A, of a first virtual machine, such as VM 102 A, wherein the key pair is bound to a current boot state of processing circuitry such as SOC 104A, and wherein the key pair is verified by each stage of one or more stages of a compute stack of VM 102 that executes trust manager 110A (602). For example, computing system 100 may generate a key pair that is verified, in turn, by SoC 104A, TEE / TPM 106A and OS kernel 108 A. Computing system 100 may cause each layer of a compute stack underpinningVM 102 to ensure the integrity and security of the pair of keys generated for trust manager 110A.

[0077] Trust manager 110A sends a public key of the key pair to a second trust manager, such as trust manager HOB (604). Trust manager 110A may send the public key as part of a remote attestation processing between trust manager 110A and trust manager HOB. Further, trust manager 110A may send the public key to establish mutual validation between trust manager 110A and trust manager 110B.

[0078] Trust manager 110B verifies trust manager 110A for VM 102B (606). Trust manager 110B may verify trust manager 110A such that any service executed by VM 102 is verified by trust manager 110B for calls by services associated with trust manager 110-1 are verified.

[0079] Trust manager 110B, responsive to verifying trust manager 110A based at least in part on the public key, verifies a first service, such as service 114 of VM 102A (608). Trust manager 110B may verify one or more services of VM 102 in response to verifying VM 102. For example, trust manager 110B may not need to verify VM 102 each time a service of VM 102 is called, as VM 102 has already been verified. A second service, such as service 146 of VM 102B, may call, based on the verification of service 114, service 114 of VM 102A (610). Service 146 may call the first service via a secure communication session established between the two services. Service 146 may call via the secure communication session established based on the mutual verification.

[0080] In this way, various aspects of the techniques described in this disclosure may enable the following examples.

[0081] Example 1 : A method includes generating, in a computing system including processing circuitry configured to execute at least a first virtual machine and a second virtual machine, a key pair for a first trust manager of the first virtual machine, wherein the key pair is bound to a current boot state of the processing circuitry, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; sending, by the first trust manager, a public key of the key pair to a second trust manager; verifying, by the second trust manager, the first trust manager for the second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verifying, by the second trust manager, a first service of the first virtual machine; and calling, by a second service of the second virtual machine and based on the verification of the first service, the first service of the first virtual machine.

[0082] Example 2: The method of example 1, wherein the second trust manager verifies the first trust manager while communicating within the computing system.

[0083] Example 3 : The method of any of examples 1 and 2, further includes in response to verifying the first service of the first virtual machine, generating, by the first trust manager, an identity token for the first service of the first virtual machine; providing, by the first trust manager, the identity token to the second service; and validating, by the second service, the identity token; and establishing, by the second service, a mutual validation between the first service and the second service.

[0084] Example 4: The method of any of examples 1-3 includes executing the first virtual machine on a first system on a chip of the processing circuitry of the computing system; and executing the second virtual machine on a second system on a chip of the processing circuitry of the computing system.

[0085] Example 5: The method of any of examples 1-4, further comprising executing the first virtual machine and the second virtual machine on a same system on a chip of the processing circuitry of the computing system.

[0086] Example 6: The method of any of examples 1-5, wherein the current boot state of the processing circuitry comprises hardware root of trust data of a trusted platform module of the processing circuitry.

[0087] Example 7: The method of any of examples 1-6, wherein the computing system is included within a software defined vehicle.

[0088] Example 8: The method of any of examples 1-7, further includes in response to establishing the mutual validation, establishing, by the first and second services, a secure communication session between the first and second services.

[0089] Example 9: The method of any of examples 1-8, further includes responsive to establishing mutual validation, calling, by the first service, the second service.

[0090] Example 10: The method of any of examples 1-9, wherein the identity token comprises a unique identifier of a service of one or more services.

[0091] Example 11 : The method of any of examples 1-10, wherein the first virtual machine executes at least one application configured to perform at least one or more services and the second virtual machine executes at least one application configured to perform the second service.

[0092] Example 12: A computing system includes a memory; and one or more programmable processors in communication with the memory, and configured to: generate a first key pair for a first trust manager of a first virtual machine, wherein the key pair is boundto a current boot state of the one or more programmable processors, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; send, by the first trust manger, a public key of the key pair to a second trust manager; verify, by the second trust manager, the first trust manager for a second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verify, by the second trust manager, a first service of the first virtual machine; and call, based on the verification of the first service, the first service of the first virtual machine.

[0093] Example 13: The computing system of example 12, wherein the second trust manager verifies the first trust manager while communicating within the computing system.

[0094] Example 14: The computing system of any of examples 12-13, wherein the one or more programmable processors are further configured to in response to verifying the first service of the first virtual machine, generate, by the first trust manager, an identity token for the first service of the first virtual machine; provide, by the first trust manager, the identity token to the second service; validate, by the second service, the identity token; and establish, by the second service, a mutual validation between the first service and the second service.

[0095] Example 15: The computing system of any of examples 12-14, wherein the one or more programmable processors are further configured to execute the first virtual machine on a first system on a chip of the one or more programmable processors; and execute the second virtual machine on a second system on a chip of the one or more programmable processors.

[0096] Example 16: The computing system of any of examples 12-15, wherein the one or more programmable processors are further configured to execute the first virtual machine and the second virtual machine on a same system on a chip of the one or more programmable processors.

[0097] Example 17: The computing system of any of examples 12-16, wherein the current boot state of the one or more programmable processors comprises hardware root of trust data of a trusted platform module of the one or more programmable processors.

[0098] Example 18: The computing system of any of examples 12-17, wherein the computing system is included within a software defined vehicle.

[0099] Example 19: The computing system of any of examples 12-18, wherein the one or more programmable processors are further configured to in response to establishing the mutual validation, establish, by the first and second services, a secure communication session between the first and second services.

[0100] Example 20: A non-transitory computer-readable medium encoded with instructions that cause one or more processors to generate a first key pair for a first trust manager of a first virtual machine, wherein the key pair is bound to a current boot state of the one or more processors, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; send, by the first trust manger, a public key of the key pair to a second trust manager; verify, by the second trust manager, the first trust manager for a second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verify, by the second trust manager, a first service of the first virtual machine; and call, based on the verification of the first service, the first service of the first virtual machine.

[0101] Example 21 : A computer program product comprising instructions that, when executed, cause one or more processors to perform any of the methods of examples 1-12.

[0102] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer- readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0103] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer- readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxialcable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage mediums and media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to nontransient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of a computer-readable medium.

[0104] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used herein may refer to any of the foregoing structures or any other structures suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.

[0105] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0106] Various embodiments have been described. These and other embodiments are within the scope of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: generating, in a computing system including processing circuitry configured to execute at least a first virtual machine and a second virtual machine, a key pair for a first trust manager of the first virtual machine, wherein the key pair is bound to a current boot state of the processing circuitry, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; sending, by the first trust manager, a public key of the key pair to a second trust manager; verifying, by the second trust manager, the first trust manager for the second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verifying, by the second trust manager, a first service of the first virtual machine; and calling, by a second service of the second virtual machine and based on the verification of the first service, the first service of the first virtual machine.

2. The method of claim 1, wherein the second trust manager verifies the first trust manager while communicating within the computing system.

3. The method of any of claims 1 and 2, further comprising: in response to verifying the first service of the first virtual machine, generating, by the first trust manager, an identity token for the first service of the first virtual machine; providing, by the first trust manager, the identity token to the second service; validating, by the second service, the identity token; and establishing, by the second service, a mutual validation between the first service and the second service.

4. The method of any of claims 1-3, comprising:executing the first virtual machine on a first system on a chip of the processing circuitry of the computing system; and executing the second virtual machine on a second system on a chip of the processing circuitry of the computing system.

5. The method of any of claims 1-4, further comprising executing the first virtual machine and the second virtual machine on a same system on a chip of the processing circuitry of the computing system.

6. The method of any of claims 1-5, wherein the current boot state of the processing circuitry comprises hardware root of trust data of a trusted platform module of the processing circuitry.

7. The method of any of claims 1-6, wherein the computing system is included within a software defined vehicle.

8. The method of any of claims 1-7, further comprising: in response to establishing the mutual validation, establishing, by the first and second services, a secure communication session between the first and second services.

9. The method of any of claims 1-8, further comprising: responsive to establishing mutual validation, calling, by the first service, the second service.

10. The method of any of claims 1-9, wherein the identity token comprises a unique identifier of a service of one or more services.

11. The method of any of claims 1-10, wherein the first virtual machine executes at least one application configured to perform at least one or more services and the second virtual machine executes at least one application configured to perform the second service.

12. The method of any of claims 1-11, wherein the computing system includes at least one of: one or more drone swarms, wherein each drone swarm of the one or more drone swarms includes a plurality of drones, orone or more dynamic internet of things networks.

13. A computing system, comprising: a memory; and one or more programmable processors in communication with the memory, and configured to: generate a first key pair for a first trust manager of a first virtual machine, wherein the key pair is bound to a current boot state of the one or more programmable processors, and wherein the key pair is verified by each stage of one or more stages of a compute stack of the first virtual machine that executes the first trust manager; send, by the first trust manger, a public key of the key pair to a second trust manager; verify, by the second trust manager, the first trust manager for a second virtual machine; responsive to the second trust manager verifying the first trust manager based at least in part on the public key, verify, by the second trust manager, a first service of the first virtual machine; and call, based on the verification of the first service, the first service of the first virtual machine.

14. The computing system of claim 12, comprising means for performing any of the methods of claims 2-12.

15. A non-transitory computer-readable medium, encoded with instructions that cause one or more processors of a computing system to perform any of the methods of claims 1-12.

16. A computer program product comprising instructions that, when executed, cause one or more processors to perform any of the methods of claims 1-12.

Images