Methods and systems for providing data security for cross-domain microservices

Abstract

A method in a network element for securely sharing services across domains, the method including: receiving, at the network element, a request to add a first domain and an edge domain to a system; provisioning public keys of the network element to the first domain and the edge domain; receiving a public key of the first domain; entering, at the network element, services provided by the first domain or the edge domain in a table; entering, at the network element, permissions for applications and services for the applications in a second table; and controlling access to the services by the applications.

Description

Technical Field

[0001] The present disclosure relates to distributed systems, and in particular, to data security in distributed systems.

Background Art

[0002] Modern vehicles have many sensors. However, such sensors can be distributed within various computing nodes on the vehicle, and each computing node can have access to zero, one, or more than one sensor driver. Such sensor nodes can further have different manufacturers and can operate using different operating systems. Similarly, other distributed systems can have a plurality of nodes where the nodes need to communicate with each other.

[0003] A sensor or group of sensors can be used to generate information that can be useful to one or more applications. Such information is referred to herein as an insight. In some cases, an insight can be generated based on its own algorithms, machine learning code, or similar processing and can be beneficial. Such insights may need to be shared with an authorized software module that launches in an external domain, and the security in such an external domain can vary.

Summary of the Invention

Means for Solving the Problems

[0004] This disclosure provides a method in a first domain for obtaining at least one insight from a second domain, the method comprising: registering an application with an anchor in the first domain; providing the application with a first message signed by the anchor; sending the signed message from the first domain to a network domain; and receiving at least one signed token from the network domain, each of which at least one signed token is for a synthetic sensor on the second domain, the synthetic sensor providing insight; and sending a request message to the second domain, the request message requesting insight and including at least one token; and receiving insight from the synthetic sensor associated with at least one token.

[0005] The disclosure further provides a computing device having a first domain configured to obtain at least one insight from a second domain, the computing device comprising a processor and a communications subsystem, the computing device being configured to register an application with an anchor in the first domain, to provide a first message signed by the anchor to the application from the anchor, to send a signed message from the first domain to a network domain, and to receive at least one signed token from the network domain, each of the at least one signed tokens being for a synthetic sensor on the second domain, the synthetic sensor being configured to provide insight and to send a request message to the second domain, the request message requesting insight and including at least one token, and to receive insight from the synthetic sensor associated with at least one token.

[0006] The Disclosure further provides a computer-readable medium for storing instruction code, which, when executed by a processor on a computing device having a first domain configured to obtain at least one insight from a second domain, causes the computing device to: register an application with an anchor in the first domain; provide the application with a first message signed by the anchor; send the signed message from the first domain to a network domain; and receive at least one signed token from the network domain, each of which is for a synthetic sensor on a second domain, the synthetic sensor providing insight; and send a request message to the second domain, the request message requesting insight and including at least one token; and receive insight from the synthetic sensor associated with at least one token.

[0007] The disclosure further provides a method in a first domain for obtaining at least one insight from a second domain, the method comprising: synchronizing an authorization table in the first domain with a master authorization table in a network element; receiving a request for insight from an application at a bridge in the first domain; verifying the identity of the application; verifying the application authorization at the bridge using the authorization table in the first domain, the verification being to confirm that the application has authorization to access the insight; sending a request message from the first domain to the second domain, the request message being signed with a private key of the first domain and requesting insight; and receiving insight from the second domain.

[0008] The disclosure further provides a computing device having a first domain for obtaining at least one insight from a second domain, the computing device comprising a processor and a communication subsystem, the computing device configured to synchronize an authorization table in the first domain with a master authorization table in a network element, receive a request for insight from an application in a bridge in the first domain, verify the identity of the application, verify the application authorization in the bridge using the authorization table in the first domain, the verification being to confirm that the application has authorization to access the insight, send a request message from the first domain to the second domain, the request message being signed with a private key of the first domain and requesting insight, and receive insight from the second domain.

[0009] The disclosure further provides a computer-readable medium for storing instruction code, which, when executed by a processor of a computing device having a first domain for obtaining at least one insight from a second domain, causes the computing device to: synchronize an authorization table in the first domain with a master authorization table in a network element; receive a request for insight from an application at a bridge in the first domain; verify the identity of the application; verify the application authorization at the bridge using the authorization table in the first domain, where verification means confirming that the application has authorization to access the insight; send a request message from the first domain to the second domain, the request message being signed with the private key of the first domain and requesting insight; and receive the insight from the second domain.

[0010] This disclosure further provides a method in a network element for securely sharing services across domains, the method comprising: receiving a request in the network element to add a first domain and an edge domain to the system; provisioning the public key of the network element to the first domain and the edge domain; receiving the public key of the first domain; entering the services provided by the first domain or edge domain into a table in the network element; entering the permissions for applications and services related to applications installed in the first domain or edge domain into a second table in the network element; and controlling applications' access to the services.

[0011] This disclosure further provides a network element for securely sharing services across domains, the network element comprising a processor and a communication subsystem, the network element being configured to receive requests to add a first domain and edge domains to the system, provision the network element's public key to the first domain and edge domains, receive the public key of the first domain, enter services provided by the first domain or edge domain into a table, enter permissions for applications and services related to applications installed in the first domain or edge domain into a second table, and control applications' access to services.

[0012] The disclosure further provides a computer-readable medium for storing instruction code, which, when executed by a processor of a network element configured to securely share services across domains, causes the network element to: receive a request to add a first domain and an edge domain to the system; provision the network element's public key to the first domain and the edge domain; receive the public key of the first domain; enter the services provided by the first domain or edge domain into a table; enter the permissions for applications and services related to applications installed in the first domain or edge domain into a second table; and control applications' access to services. The present invention provides, for example, the following: (Item 1) A method in a network element for securely sharing services across domains, wherein the method is: The aforementioned network element receives requests to add a first domain and an edge domain to the system, Provisioning the public key of the network element to the first domain and the edge domain, Receiving the public key of the first domain, In the aforementioned network element, the service provided by the first domain or the edge domain is entered into a table, In the aforementioned network element, the permissions for applications installed in the first domain or edge domain and services related to those applications are entered into the second table. To control the application's access to the service. Methods that include... (Item 2) Controlling the aforementioned access means Receiving a request from an application on the first domain, wherein the request is signed by the first domain, To verify the aforementioned requirements, Based on the verification and the authorization relating to the service relating to the application, provide at least one token relating to the service to the first domain. Includes, The method according to item 1, wherein the at least one token includes an identifier relating to the service and a signature of the network element. (Item 3) The aforementioned token is as described in item 2, further including an expiration time. (Item 4) Controlling the aforementioned access means Receiving a request from a domain bridge on the first domain, wherein the request is signed by the first domain and includes an application identifier, To verify the aforementioned requirements, Based on the verification and the authorization relating to the service for the application associated with the application identifier, provide the domain bridge with at least one token relating to the service. Includes, The method according to item 1, wherein the at least one token includes an identifier relating to the service and a signature of the network element. (Item 5) Controlling the aforementioned access means Receiving a request from the first domain to synchronize the second table, Providing the second table to the first domain The method described in item 1, including the method described in item 1. (Item 6) The table with services is the method described in item 1, further including the delegation of authorization for a portion of the services. (Item 7) The provisioning described herein occurs during the manufacture of a computing device comprising the first domain and the edge domain, as described in item 1. (Item 8) The provisioning described herein occurs in a trusted service center relating to computing devices, including the first domain and the edge domain, as described in Item 1. (Item 9) The method according to item 1, wherein the first domain and the edge domain belong to a vehicle, and the network element is a vehicle fleet manager. (Item 10) A network element for securely sharing services across domains, wherein the network element is Processor and Communication subsystem and Equipped with, The aforementioned network element is The aforementioned network element receives requests to add a first domain and an edge domain to the system, Provisioning the public key of the network element to the first domain and the edge domain, Receiving the public key of the first domain, In the aforementioned network element, the service provided by the first domain or the edge domain is entered into a table, In the aforementioned network element, permissions for applications installed in the first domain or edge domain and services related to said applications are entered into a second table. To control the application's access to the service. A network element configured to perform the following actions. (Item 11) The aforementioned network element is Receiving a request from an application on the first domain, wherein the request is signed by the first domain, To verify the aforementioned requirements, Based on the verification and the authorization relating to the service relating to the application, provide the first domain with at least one token relating to the service, wherein the at least one token includes an identifier relating to the service and a signature of the network element. The network elements described in item 10 are configured to control access. (Item 12) The aforementioned token is a network element as described in item 11, further including an expiration time. (Item 13) The aforementioned network element is Receiving a request from a domain bridge on the first domain, wherein the request is signed by the first domain and includes an application identifier, To verify the aforementioned requirements, Based on the verification and the authorization relating to the service for the application associated with the application identifier, provide the domain bridge with at least one token relating to the service, wherein the at least one token includes the service identifier and the signature of the network element. The network elements described in item 10 are configured to control access. (Item 14) The aforementioned network element is Receiving a request from the first domain to synchronize the second table, Providing the aforementioned second table to the aforementioned first domain, The network elements described in item 10 are configured to control access. (Item 15) The aforementioned table, which includes services, further includes the delegation of authorizations for a portion of the services, as described in item 10, for the network elements. (Item 16) The network element described in item 10 is configured to be provisioned during the manufacture of a computing device having the first domain and the edge domain. (Item 17) The network element described in item 10 is configured to provision when the computing device, which includes the first domain and the edge domain, is located in a trusted service center. (Item 18) The first domain and the edge domain belong to a vehicle, and the network element is a vehicle fleet manager, as described in item 10. (Item 19) A computer-readable medium for storing instruction code, wherein the instruction code is executed by a processor of a network element configured to securely share services across domains. The aforementioned network element receives requests to add a first domain and an edge domain to the system, Provisioning the public key of the network element to the first domain and the edge domain, Receiving the public key of the first domain, In the aforementioned network element, the service provided by the first domain or the edge domain is entered into a table, In the aforementioned network element, permissions for applications installed in the first domain or edge domain and services related to said applications are entered into a second table. To control the application's access to the service. A computer-readable medium that causes the aforementioned network element to perform the action. (Item 20) The aforementioned instruction code is, Receiving a request from an application on the first domain, wherein the request is signed by the first domain, To verify the aforementioned requirements, Based on the verification and the authorization relating to the service relating to the application, provide the first domain with at least one token relating to the service, wherein the at least one token includes an identifier relating to the service and a signature of the network element. A computer-readable medium as described in item 19, which further causes the network element to control access. [Brief explanation of the drawing]

[0013] This disclosure will be better understood with reference to the drawings.

[0014] [Figure 1] Figure 1 is a block diagram illustrating an exemplary system having an insight generation side and an insight consumption side.

[0015] [Figure 2] Figure 2 is a block diagram illustrating an exemplary computing system with three domains.

[0016] [Figure 3] Figure 3 is a block diagram illustrating an exemplary computing system in which a cloud or network domain stores permissions for applications and microservices.

[0017] [Figure 4] Figure 4 is a block diagram illustrating an exemplary computing system in which an application on the first domain directly obtains insights from a synthetic sensor on the second domain.

[0018] [Figure 5] Figure 5 is a data flow diagram showing how an application in the first domain directly obtains insights from a synthetic sensor in the second domain.

[0019] [Figure 6] Figure 6 is a block diagram illustrating an exemplary computing system in which an application on the first domain uses a gateway on the second domain to obtain insights from a synthetic sensor on the second domain.

[0020] [Figure 7] Figure 7 is a data flow diagram showing how an application in the first domain uses a gateway in the second domain to acquire insights from a synthetic sensor in the second domain.

[0021] [Figure 8]Figure 8 is a block diagram illustrating an exemplary computing system in which an application on the first domain uses a bridge on the first domain to gain insights from a synthetic sensor on the second domain.

[0022] [Figure 9] Figure 9 is a data flow diagram showing how an application in the first domain uses a bridge in the first domain to acquire insights from a synthetic sensor in the second domain.

[0023] [Figure 10] Figure 10 is a block diagram illustrating an exemplary computing system in which an application on the first domain uses a bridge on the first domain and a gateway on the second domain to gain insights from a synthetic sensor on the second domain.

[0024] [Figure 11] Figure 11 is a data flow diagram showing how an application on the first domain uses a bridge on the first domain and a gateway on the second domain to gain insights from a synthetic sensor on the second domain.

[0025] [Figure 12] Figure 12 is a block diagram illustrating an exemplary computing system in which an application on a first network-based domain uses a bridge on the first domain and a gateway on the second domain to gain insights from a synthetic sensor on the second domain.

[0026] [Figure 13] Figure 13 is a data flow diagram showing how an application on the first network-based domain uses a bridge on the first domain and a gateway on the second domain to gain insights from a synthetic sensor on the second domain.

[0027] [Figure 14]Figure 14 is a simplified block diagram of a computing device that can be used in conjunction with embodiments of the present disclosure. [Modes for carrying out the invention]

[0028] In modern vehicles, information from one or more physical sensors can be processed to create “insights” that may be useful to the system. Such one or more physical sensors and the processing associated with them can logically be referred to as microservices or synthetic sensors (SS). The terms microservices and synthetic sensors are used synonymously herein.

[0029] Synthetic sensors may exist in other types of applications, including, but not limited to, medical applications, manufacturing applications, and Internet of Things applications, and this disclosure is not limited to automotive applications. Automotive applications are provided below for illustrative purposes.

[0030] Insight is a term used herein to describe any computer-generated interpretation of basic sensor data. Insights can be as simple as data aggregation or correlation, or as complex as artificial intelligence and machine learning. For example, a temperature sensor that provides high and low thresholds for notification may be considered an “insight.” In relation to location services, geofencing is an insight. In relation to cameras, occupant recognition may be an insight. The use of a combination of sensors, such as a temperature sensor and a camera, in conjunction with an artificial intelligence model to determine whether a car seat is occupied in a hot vehicle, may be an insight. Many other examples of insights are also possible.

[0031] In one embodiment, a vehicle application may be implemented in a system that provides consistent access to vehicle data and intelligent insights in a manner familiar and accessible to the developer community. Such an environment may enable cloud developers to extend their reach to the edges of the vehicle through the development of synthetic sensors that derive intelligent insights about vehicle data, using common cloud development techniques and paradigms. Such an environment may provide consistent access to vehicle data so that synthetic sensors can be written to and deployed across a broad vehicle base without bespoke customization.

[0032] Insights can be generated based on processors running on a first facility or domain, which often need to be shared with authorized software modules running within an external domain. The first domain controls the installation and communication of modules within it and is therefore capable of determining their identification and authorization. However, the first domain does not have such control over other domains.

[0033] For example, one external domain could be an in-vehicle infotainment (IVI) system in a car that can launch applications to access insights and provide information to the driver.

[0034] The modules or applications that can use the insights are determined by a manager or actor, referred to herein as the Fleet Manager, regardless of whether they are within or outside the first domain. The implementation of such modules or applications and access to their insights may, in some embodiments, be controlled by the Fleet Manager. However, with respect to some insights, the Fleet Manager may delegate the implementation decision to the driver. For example, two insights may provide similar data regarding child seat occupancy. In this case, the Fleet Manager may select or authorize the first insight. In other cases, the Fleet Manager may allow the driver to select the insights to obtain / use.

[0035] In some embodiments, the vehicle manager can change the set of insights available to a module or application at any given time.

[0036] In some embodiments, the system may need to further consider disconnection modes. Specifically, a vehicle may not always have access to the fleet manager, for example, when there is no internet connection to the vehicle. In some embodiments, a vehicle may be disconnected from the fleet manager for potentially long periods, for example, when the vehicle is parked in a rural area without any cellular service.

[0037] Therefore, this disclosure provides a method and system for distributing insights only to authorized modules within external domains.

[0038] (Example of a distributed system)

[0039] Herein, Figure 1 is referenced, which illustrates an exemplary system showing various sources and consumers of insight. The embodiment of Figure 1 is provided solely for illustrative purposes, and in some cases there may be fewer participants in the system. In other cases there may be more participants in the system.

[0040] In the embodiment shown in Figure 1, the vehicle 100 may be equipped with a computing system and a communication system. Part of the computing system may include a domain 110 which may have an application that consumes insights, as described below. Furthermore, part of the computing system on the vehicle 110 may include an edge domain 112. In some embodiments, the edge domain 112 may generate insights. However, in other cases, insights may be generated within domain 110 or consumed within the edge domain 112.

[0041] In the example shown in Figure 1, vehicle 100 communicates with a cellular base station shown in Figure 1 as eNB 120 using a communication system. The base station may communicate with the core network 130, which can then forward the communication to the cloud service provider 140 through network 132. Network 132 may be a wide-area network such as the Internet.

[0042] In other embodiments, any technology associated with a specific cellular or wireless communication protocol, rather than the core network 130, may be used.

[0043] As described below, cloud service 140 can provide security for insights generated within the domain.

[0044] In some embodiments, the cloud domain 150 may generate or consume insights. The cloud domain 150 may communicate with the cloud service provider 140 through the network 132 and, in some cases, with other domains such as the domain 112 on the vehicle 100.

[0045] Furthermore, it is not the vehicle, but the device 160 that can generate or consume insights. The device 160 may be any computing device capable of generating or consuming such insights, and may include, among other options, an Internet of Things device, a mobile device, a medical device, a vehicle, or equipment associated with a vehicle. The device 160 communicates through a network 132 that implements a variety of wired or wireless technologies, including, but not limited to, Ethernet®, fiber, cellular, Wi-Fi, and satellite.

[0046] In some embodiments, device 160 may include a domain 162 that can consume insights. Furthermore, device 160 may, in some cases, include an edge domain 164 that can generate insights. However, in other cases, domain 162 may generate insights, and edge domain 164 may consume insights.

[0047] Furthermore, while the embodiment in Figure 1 shows only two domains within the vehicle 100 or device 160, in practice, one or more domains may reside within the vehicle 100 or device 160, and this disclosure is not limited to having only two domains within any particular device. In particular, device 160 may be used solely to generate insights, in which case it would have only a single domain. In other cases, device 160 may only consume insights, and again it may have only one domain. In other cases, device 160 or vehicle 100 may have multiple domains, along with the edge domain 112.

[0048] This disclosure will describe an automotive system with distributed nodes. However, it is provided solely for illustrative purposes, and the methods and systems described herein may be used equally with any other distributed system.

[0049] Here, Figure 2, which shows a simplified distributed system, is referenced.

[0050] In the example in Figure 2, the cloud service domain 210 may be associated with the vehicle manager. The cloud service domain 210 includes a primary anchor module 212. One purpose of the primary anchor module is related to security for insights within the system.

[0051] The cloud service domain 210 further includes a certificate or key store 214. In embodiments herein, as described below, the system may be securely installed within a vehicle and a backend information technology infrastructure. Installation may include provisioning keys in a confidential store in the vehicle, which can be verified from outside the vehicle by a fleet manager using the information technology infrastructure. The confidential store may use hardware key encryption keys (KEKs) to protect the provisioned keys and prevent other software modules from accessing the confidential information. A public / private key pair may be generated in the vehicle, and the public key may be shared via a trusted link. Alternatively, a symmetric confidential key may be deposited into the vehicle by the fleet manager using a trusted connection, and a copy may be stored in the information technology infrastructure. In either case, a means of authenticating the identification of the provisioned system in the field is achieved.

[0052] In the example in Figure 2, the certificate or keystore 214 stores a certificate relating to the primary anchor 212 and a private key relating to the primary anchor 212. The certificate or keystore 214 may further store various domain certificates relating to the domain anchor, as described below.

[0053] In the embodiment shown in Figure 2, a first domain, referred to as edge domain 220, may be used to provide insights from a synthetic sensor. The domain is referred to as an edge domain based on cloud perspective, indicating that it lies at the edge of the cloud. Edge domain 220 is installed on a vehicle having a vehicle identifier. While the embodiment in Figure 2 shows a single edge domain, in practice, multiple edge domains may exist within a vehicle.

[0054] The edge domain 220 includes, among other functionalities, an edge anchor 222 used for security for insights.

[0055] The edge domain 220 further includes a certificate or keystore 223 which may be used to store certificates relating to the primary anchor 212.

[0056] In the example in Figure 2, these composite sensors, namely SS224, SS226, and SS228, are part of edge domain 220. Although three composite sensors are shown, in practice, fewer or more composite sensors may exist within an edge domain.

[0057] Furthermore, in the example in Figure 2, a secondary domain 230 is shown. Domain 230 may be associated with, for example, an infotainment system within a vehicle. However, domain 230 may also be associated with other aspects of the vehicle and is not limited to an infotainment system.

[0058] Domain 230 includes, among other functionalities, a domain anchor 232 used to provide security for insights.

[0059] Domain 230 further includes a certificate or key store 233. In this case, the certificate or key store 233 may include a storage device for the key for the primary anchor 212, along with a storage device for the certificate associated with the domain anchor 232.

[0060] In the example in Figure 2, domain 230 includes three applications: application 234, application 236, and application 238. However, the number of applications associated with a domain is not limited to three; fewer or more applications may be associated with a particular domain.

[0061] Furthermore, although the embodiment in Figure 2 shows only a single secondary domain, in practice, multiple secondary domains may exist within the vehicle, and the illustration of a single domain 230 is provided only as an example.

[0062] Regarding connectivity between the various domains in Figure 2, edge domains 220 and 230 can be connected internally within the vehicle using any wired or wireless technology. For example, the connection may use a bus, short-range wireless communication, or other similar communication technology.

[0063] Communication with the cloud service 210 may be via wireless technologies such as cellular connectivity, satellite connectivity, and wide area networks (WANs) such as Wi-Fi, among other options. Furthermore, in some cases, communication may be via wired connections, such as when the vehicle is being manufactured and provisioned, or when the vehicle is in a service center and connected through a secure channel.

[0064] The failure of a domain to connect to an edge domain for control messages would also mean a failure to gain insights. Typically, domains inside a vehicle are connected by an onboard network. However, these links cannot be assumed to be secure from eavesdropping. Furthermore, not all modules or applications connected to the network can be assumed to be trustworthy. Therefore, the integrity and confidentiality of messages are not guaranteed when communicating between domains, and defenses against DoS attacks may be employed at any time.

[0065] Furthermore, in some cases, connectivity from the internet to the vehicle may be intermittent. Therefore, the vehicle fleet manager and information technology infrastructure may not always be connected to the edge domain 220. When a vehicle becomes disconnected, only the domains connected within the vehicle can obtain insights from the edge domain 220. According to some embodiments of this specification, the last state of authorization synchronized between the edge domain and the vehicle fleet manager may be respected when the edge domain becomes disconnected from the cloud service 210.

[0066] (provisioning)

[0067] Certain reliability factors may be provisioned within the vehicle environment during vehicle manufacturing, or subsequently at a trusted service center.

[0068] For example, a car leaving the factory may be provisioned with at least an edge domain 220, a secondary domain 230 such as an infotainment system, and a trust anchor application (domain anchor 232) within the secondary domain 230.

[0069] In one embodiment, a trusted computer, which is part of the information technology infrastructure controlled by the vehicle owner, is connected to the factory via a secure link. This trusted computer, referred to as the primary anchor 212, identifies keys and certificates and associates them with one or more vehicle identifiers as part of the provisioning process.

[0070] Modules within edge domain 220 that have access to a secure storage device such as a certificate or key store 223 are designated as trust anchors (edge ​​anchors 222) for edge domain 220. Edge anchors 222 receive and store at least one public key (and certificate) from primary anchor 212, and edge anchors 222 use at least one public key (and certificate) along with various SSs within the edge domain to check whether a message was signed using the private key of primary anchor 212. These are shown as the public key "PA" and private key "pa" in the embodiment of Figure 2.

[0071] The domain trust anchor application (domain anchor 232) is installed within the vehicle's domain 230 facility.

[0072] In one embodiment, the domain anchor 232 uses a certificate or keystore 233 to generate an asymmetric key pair. For example, this is shown as the public / private key pair DA / da in the example in Figure 2. In other embodiments, other forms of cryptography, such as symmetric key pairs, may also be used.

[0073] In one embodiment, a certificate request containing the public key is sent to the information technology infrastructure, while the private key of domain anchor 232 remains secure within the certificate or keystore 233. The information technology infrastructure returns a certificate signed with the private key of primary anchor 212.

[0074] In this embodiment, the domain anchor 232 and the primary anchor 212 have the ability to authenticate and securely share information with each other. Such secure sharing of information may, for example, use a hypertext transfer protocol secure (HTTP) protected endpoint provided by the domain anchor 232 to reach the primary anchor 212 when connectivity is available.

[0075] The above discusses provisioning during manufacturing, but in other embodiments, provisioning may occur later. For example, service center installation and provisioning may be used in conjunction with the embodiments described herein.

[0076] Furthermore, instead of the public / private key pair-based provisioning described above, some original equipment manufacturers (OEMs) may prefer to inject a shared (symmetric) private key from primary anchor 212 into a certificate or keystore 233 for domain 230. Subsequent provisioning steps can be adapted to work with such a symmetric key.

[0077] (permission)

[0078] To represent the security expected from protocol insights, one or more insights are linked to authorizations. Figure 3 is referenced here.

[0079] In the embodiment shown in Figure 3, the cloud service 310 includes a primary anchor 312 and a certificate or key store 314. The cloud service further includes an authorization table, which includes a table that associates a specific vehicle platoon identifier with a specific authorization, as shown in table 316.

[0080] Furthermore, Table 317 includes identifiers for the edge domain, including vehicle identifiers, along with the licenses provided for that edge domain and the types of licenses to which authority is delegated with respect to that edge domain, as described below.

[0081] The application table 318 associates permissions and applications on a particular domain with whether or not that application is activated within the domain.

[0082] The permission table in the example in Figure 3 is provided merely as an example and is not limiting. In some cases, more information may be provided in one of tables 316, 317, or 318. In other cases, the information may be modified, or the tables may be combined in some embodiments.

[0083] At least one edge domain 320 may be associated with a vehicle. The edge domain 320 includes an edge anchor 322 and a certificate or key store 323.

[0084] In the example shown in Figure 3, the edge domain 320 includes three composite sensors, namely SS A324, SS B326, and SS C328.

[0085] Furthermore, Domain 330 is also located on the vehicle. Domain 330 may, for example, comprise an infotainment system on the vehicle. However, other examples of domains are also possible.

[0086] Domain 330 includes a domain anchor 332, along with a certificate or key store 333.

[0087] In the example in Figure 3, domain 330 includes applications 334, 336, and 338. However, the number of applications on a domain is not limited to three; fewer or more applications may be provided on domain 330.

[0088] In embodiments of this disclosure, authorization is defined comprehensively and scoped to be enforced within an edge domain by one specific SS.

[0089] A set of permissions is deployed on the vehicle at any given time, and this set is known and constitutes an information technology infrastructure domain within the cloud service 310.

[0090] Entities such as OEMs may have ultimate control over all permissions. Such entities may delegate some control over permissions to other trusted entities. For example, a vehicle driver may be a trusted entity. The driver may, among other options, modify the status of these delegated permissions using the in-vehicle network or the internet.

[0091] For example, one vehicle manufacturer might decide that all insights should be provided from synthetic sensors approved only by that vehicle manufacturer. In this case, no delegation of authority is provided. In another case, a second vehicle manufacturer might permit certain types of insight sources to be selected by the vehicle's driver, and these would be referred to as delegated authorizations.

[0092] In one embodiment, if the vehicle becomes disconnected from the internet, the authorization works with the most current control entity or agent input available at the time of enforcement.

[0093] Therefore, according to the embodiment of Figure 3, a control entity such as a vehicle fleet manager may authorize the installation and associated permission of the synthetic sensors on the vehicle assembly. The synthetic sensors, such as sensors 324, 326, or 328 that generate insights, may then be installed on the edge domain 320.

[0094] (A mechanism for sharing insights)

[0095] As described above, in embodiments of this disclosure, modules (also referred to as applications) may enable the reception of insights. However, applications ultimately represent the author, i.e., a person or organization. Modules further represent a point in time indicated by their versions.

[0096] Accordingly, according to the embodiments described herein, an end-to-end system may use cryptographic signatures to provide authorization to receive insights to an application defined by a name and version certified by a trusted author. The trust imposed on the author is that they produce software that complies with the system's terms of use. The system may also require a mechanism to revoke such authorization when required.

[0097] Where available, such a system may use security mechanisms from other domains to determine the authenticity of an application's name and version. For example, if the domain is an Android® domain, attributions of the name, version, and signature of an Android® application may be used. Similar attributions may be found in domains that run different operating systems.

[0098] In this disclosure, it is assumed that synthetic sensors are responsible for their own interests and are unlikely to transfer their insights to other SSs. It is also expected that most applications authorized to receive SS insights will not voluntarily violate the system's terms of use and therefore will not indiscriminately share authorized insights, data, or metadata.

[0099] However, SS and applications are not opposed to gaining more insights than they are authorized to. Therefore, it is expected that they will use all the insights and metadata available to them.

[0100] Accordingly, according to embodiments of the present disclosure, the system can limit the scope of insights and metadata to the minimum set of applications represented by the fleet manager, thereby limiting the exposure of insights resulting from any security incidents that may occur at any given time.

[0101] Based on this, the following sections describe various ways to achieve the goal of securely sharing insights outside the edge domain. Alternatives discussed the trade-off distribution of complexity and security responsibilities with performance and fault tolerance.

[0102] (Independent application requirements for insights)

[0103] An embodiment is provided herein in which an application in an external domain may securely request insights from SS using provisioned certificates and permissions. Figure 4 is referenced here.

[0104] In the embodiment shown in Figure 4, the exemplary permissions and domains from Figure 3 are used with similar numbering. However, they are provided merely for illustrative purposes, and in other embodiments, different domains, SSs, applications, or connections are also possible.

[0105] In the example in Figure 4, application 334 desires to gain insights from SS B326.

[0106] In this regard, an internal communication path exists within domain 330 between application 334 and domain anchor 332. Such a communication path is indicated by connection 420 and could be any internal process or communication path within the operating system of the computing devices in domain 330. For example, domain anchor 332 may have an application program interface used to request or provide data to the domain anchor. Other options are also possible.

[0107] Similarly, application 336 may have a connection 422 with domain anchor 332, and application 338 may have a connection 424 with domain anchor 332.

[0108] In the embodiment shown in Figure 4, application 334 may further be able to communicate with primary anchor 312, as shown using connection 430.

[0109] Furthermore, application 334 may be able to communicate with the composite sensor 326, as shown using connection 440.

[0110] Connections 430 and 440 may utilize communication subsystems within domain 330 for actual communication. For example, domain 330, in particular application 334, may utilize a cellular communication module associated with domain 330 to send Internet Protocol requests to primary anchor 312, if any. Similarly, domain 330 and edge domain 320 may enable communication via wired or wireless connections such as Bluetooth®, Bluetooth® Low Energy, CANBus, Ethernet®, among other options.

[0111] Using the embodiment shown in Figure 4, the application may employ a token-based approach to gain insights. See Figure 5.

[0112] Once a new application is registered in the information technology infrastructure, it is also authorized to gain insights using the permission-based model described with respect to Figure 3.

[0113] Once application 334 is installed on the vehicle's domain 330, the application requests to be registered with domain anchor 332, which is installed within domain 330. Such a registration request is indicated by message 520.

[0114] In some embodiments, application 334 may check the signature of an application package that provides a domain anchor in an Android® automotive instance. For example, in an Android® system, application 334 may check the signature of an Android® package kit (APK) that provides a domain anchor in an Android® automotive instance.

[0115] In block 522, a component within domain anchor 332 uses the operating system platform to determine the application name, version, and package signature hash of the requested package. It can then append a vehicle identifier, sign this information, and leverage the domain anchor secret key (DA) to generate a locally authenticated application message.

[0116] For example, such a locally authenticated application message may be generated using the command Sign(da,{vi2234,app.a,app.a.sig,timeOfDay+validity,··}). In this case, the locally authenticated application message may include the vehicle identifier, application identifier, and the private key of the domain anchor for signing the message with the application signature, and other factors such as the time and validity duration of the authenticated application message, among other information.

[0117] The application message is returned to application 334 in message 524.

[0118] Locally authenticated application messages may then be sent to the primary anchor 312 in message 530, along with the vehicle identifier. Connections relating to locally authenticated application messages may, if applicable, be encrypted to ensure that the information is not exposed to eavesdroppers.

[0119] The primary anchor 312 can receive message 530 and verify the message. Specifically, the message can be verified using the public key of domain anchor 332 to ensure that it is properly signed.

[0120] During verification, the primary anchor 312 reads out the sets of permissions available to the application on the specific vehicle in block 532, creates a token for them, signs the token using the primary anchor private key (pa), and its corresponding public key is used to verify the token on the vehicle's edge domain 320.

[0121] For example, such a token can be generated using the command tkn_auth_ins_B_pa = Sign(pa,{SS.B,timeOfDay+validity}). In this case, the token includes allowing access to insight B. The token includes SS, which in some embodiments may include the time and validity duration. The token is signed using the private key "pa" of the primary anchor.

[0122] These tokens are returned to the requesting application in message 534. The connection regarding the return of the tokens may, if applicable, be encrypted to ensure that the tokens are not exposed to eavesdroppers.

[0123] The requesting application can, in this case as shown in message 540, request the SS to retrieve insights. The request is accompanied by a scoped token with respect to the specific insight being requested, in the embodiment shown in Figure 5.

[0124] Once SS B326 verifies the token, it may then provide insights to return to application 334, as indicated in message 542.

[0125] Therefore, in the embodiment shown in Figure 5, the communication model between the application and the SS is assumed to be direct. Since the transport crosses the operating system (OS) boundary, it can use Transport Layer Security (TLS).

[0126] For example, an SS sharing insights can register each of its remote procedure call (RPC) endpoints for TLS protection. These endpoints can then communicate with application 334 along with a token.

[0127] When an application is targeted, it can call an RPC endpoint and register the target for SS insights along with an authorization token.

[0128] When SS generates an insight, it can share it with the requesting application using a valid token.

[0129] Alternatively, a publish / subscribe transport with TLS security can be used in a similar manner.

[0130] The embodiments in Figures 4 and 5 thus enable a communication model that leverages the microservices nature of the platform to efficiently share insights without a single point of failure. This uses a domain anchor as a trust anchor to validate the reliability of application 334.

[0131] (Independent application request regarding insights using gateways)

[0132] In some embodiments, it may be undesirable to have an SS directly function as a server or communication endpoint. For example, an SS may be written by a third party that may be considered to have a lower level of security awareness. In these scenarios, communication may occur through an Application Programming Interface (API) gateway. The gateway may act as a reverse proxy for the external requesting side of insights, perform authorization checks, and even combine the results of two or more SSs.

[0133] The gateway address can be sent to application 334 when application 334 sends the token, or it can be made public within domain 330. Figure 6 is referenced here.

[0134] In the embodiment of Figure 6, the exemplary permissions and domains from Figure 3 are used with similar numbering. However, they are provided merely for illustrative purposes, and in other embodiments, different domains, SSs, applications, or connections are also possible.

[0135] Furthermore, in the example in Figure 6, the gateway 610 is provided for the application to gain insights from the SS.

[0136] In the example in Figure 6, application 334 desires to gain insights from SS B326.

[0137] In this regard, an internal communication path exists within domain 330 between application 334 and domain anchor 332. Such a communication path is indicated by connection 620 and could be any internal process or communication path within the operating system of the computing devices in domain 330. For example, domain anchor 332 may have an application program interface used to request or provide data to the domain anchor. Other options are also possible.

[0138] In the embodiment shown in Figure 6, application 334 may further be able to communicate with primary anchor 312, as shown using connection 630.

[0139] Furthermore, application 334 may be able to communicate with gateway 510, as shown using connection 640.

[0140] The gateway communicates internally with the SS within edge domain 320, and the connection with SS B326 is indicated as connection 650.

[0141] Connections 630 and 640 may utilize communication subsystems within domain 330 for actual communication. For example, domain 330, in particular application 334, may utilize a cellular communication module associated with domain 330 to send Internet Protocol requests to primary anchor 312, if any. Similarly, domain 330 and edge domain 320 may enable communication via wired or wireless connections such as Bluetooth®, Bluetooth® Low Energy, CANBus, and Ethernet®, among other options.

[0142] Using the embodiment shown in Figure 6, the application may employ a token-based approach to gain insights. See Figure 7.

[0143] Once a new application is registered in the information technology infrastructure, it is also authorized to gain insights using the permission-based model described with respect to Figure 3.

[0144] Once application 334 is installed on the vehicle's domain 330, the application requests registration with the domain anchor 332 installed within domain 330. Such a registration request is indicated by message 720.

[0145] In some embodiments, application 334 may check the signature of an application package that provides a domain anchor in an Android® automotive instance. For example, in an Android® system, application 334 may check the signature of an Android® package kit (APK) that provides a domain anchor in an Android® automotive instance.

[0146] In block 722, a component within domain anchor 332 uses the operating system platform to determine the application name, version, and package signature hash of the requested package. It can then append a vehicle identifier, sign this information, and leverage the domain anchor secret key (DA) to generate a locally authenticated application message.

[0147] For example, such a locally authenticated application message may be generated using the command Sign(da,{vi2234,app.a,app.a.sig,timeOfDay+validity,··}). In this case, the locally authenticated application message may include the vehicle identifier, application identifier, and the private key of the domain anchor for signing the message with the application signature, and other factors such as the time and validity duration of the authenticated application message, among other information.

[0148] The application message is returned to application 334 in message 724.

[0149] Locally authenticated application messages may then be sent to the primary anchor 312 in message 730, along with the vehicle identifier. Connections relating to locally authenticated application messages may, if applicable, be encrypted to ensure that the information is not exposed to eavesdroppers.

[0150] The primary anchor 312 can receive message 730 and verify the message. Specifically, the message can be verified using the public key of domain anchor 332 to ensure that it is properly signed.

[0151] During verification, the primary anchor 312 reads out the sets of permissions available to the application on the specific vehicle in block 732, creates a token for them, signs the token using the primary anchor private key (pa), and its corresponding public key is used to verify the token on the vehicle's edge domain 320.

[0152] For example, such a token can be generated using the command tkn_auth_ins_B_pa = Sign(pa,{SS.B,timeOfDay+validity}). In this case, the token includes allowing access to insight B. The token includes SS, which in some embodiments may include the time and validity duration. The token is signed using the private key "pa" of the primary anchor.

[0153] These tokens are returned to the requesting application in message 734. The connection regarding the return of the tokens may, if applicable, be encrypted to ensure that the tokens are not exposed to eavesdroppers.

[0154] The requesting application can, in this case, request to retrieve insights by utilizing the gateway 610, as indicated in message 740. The request is accompanied by a scoped token with respect to the specific insight being requested, as in the embodiment of Figure 7.

[0155] Once Gateway 610 validates the token, it may then request insights from SS B326, as indicated in message 750. Since the source of message 750 is known to SS B, no further verification is required to return the insights in message 752 to Gateway 610.

[0156] Gateway 610 may then provide insights to return to application 334, as indicated in message 760.

[0157] Therefore, in the embodiment shown in Figure 7, the communication model between the application and the gateway uses a gateway. The transport between the application and the gateway can use Transport Layer Security (TLS) because it crosses the operating system (OS) boundary.

[0158] When an application is targeted, it can call an RPC endpoint to the gateway and register the target for SS insights along with an authorization token.

[0159] When SS generates an insight, it may notify the gateway. Gateway 610 can then share it with the requesting application using a valid token.

[0160] Alternatively, a publish / subscribe transport with TLS security can be used, although it utilizes a gateway.

[0161] The SS Gateway 610 introduces a single point of failure to the vehicle, but one of its advantages is that requests from different heterogeneous domains can be adapted by adding adapters within the gateway.

[0162] In some cases, the insight gateway can be further reverse-proxyed, and a higher-level gateway in the cloud can be used to scale insights across vehicles and fleets.

[0163] (Insights via Domain Bridge)

[0164] In a further embodiment, a bridge module may be deployed within an external domain to function as a proxy for insights. Cryptographic keys from a trust anchor activated within the external domain are shared with the specific domain. For example, see Figure 8.

[0165] In the example in Figure 8, domain anchors share public keys / certificates with edge domains via their mutual trust within the primary anchor. This certificate may need to be rewritten periodically. Messages signed with the private key corresponding to that certificate are trusted by the SS, enabling external TLS connections to the insight generation interface. Rewriting may occur within the vehicle when disconnected from the network, for a configured number of times to ensure continuity of service.

[0166] In the embodiment shown in Figure 8, the exemplary permissions and domains from Figure 3 are used with similar numbering. However, they are provided solely for illustrative purposes, and in other embodiments, different domains, SSs, applications, or connections are also possible.

[0167] In the example in Figure 8, application 334 desires to gain insights from SS B326.

[0168] In this regard, an internal communication path exists within domain 330 between application 334 and domain anchor / bridge 810. Such a communication path is indicated by connection 820 and could be any internal process or communication path within the operating system of the computing devices in domain 330. For example, domain anchor / bridge 810 may have an application program interface used to request or provide data to the domain anchor. Other options are also possible.

[0169] The domain anchor / bridge 810 can communicate with the primary anchor 312 using connection 830.

[0170] Furthermore, the domain anchor / bridge 810 may be able to communicate with the composite sensor 326, as shown using connection 840.

[0171] Connections 830 and 840 may utilize communication subsystems within domain 330 for actual communication. For example, domain 830, in particular domain anchor / bridge 810, may utilize a cellular communication module associated with domain 330 to send Internet Protocol requests to primary anchor 312, if any. Similarly, domains 330 and edge domain 320 may enable communication via wired or wireless connections such as Bluetooth®, Bluetooth® Low Energy, CANBus, and Ethernet®, among other options.

[0172] Using the embodiment shown in Figure 8, the application may employ a token-based approach to gain insights. See Figure 9.

[0173] Once a new application is registered in the information technology infrastructure, it is also authorized to gain insights using the permission-based model described with respect to Figure 3.

[0174] Once application 334 is installed on the vehicle's domain 330, the application requests registration with the domain anchor / bridge 810 installed within domain 330. Such a registration request is indicated by message 920.

[0175] In some embodiments, application 334 may check the signature of an application package that provides a domain anchor / bridge in an Android® automotive instance. For example, in an Android® system, application 334 may check the signature of an Android® package kit (APK) that provides a domain anchor / bridge in an Android® automotive instance.

[0176] In block 922, a component within domain anchor 332 uses the operating system platform to determine the application name, version, and package signature hash of the requested package. It can then sign this information and leverage the domain anchor secret key (DA) to generate a locally authenticated application message.

[0177] Locally authenticated application messages may then be sent to the primary anchor 312 in message 930, along with the vehicle identifier. Connections relating to locally authenticated application messages may, if applicable, be encrypted to ensure that the information is not exposed to eavesdroppers.

[0178] For example, such a message could be a request for a token and could be generated using the command getAuthTokensFor(Sign(da,{app.a,app.a.sig,Nonce,··}). In this case, a signature using the private key of domain 330, an authenticated application message, and a nonce to prevent reflection attacks are provided.

[0179] The primary anchor 312 can receive message 930 and verify the message. Specifically, the message can be verified using the public key of domain anchor 332 to ensure that it is properly signed.

[0180] During verification, the primary anchor 312 reads out the sets of permissions available to the application on the specific vehicle in block 932, creates a token for them, signs the token using the primary anchor private key (pa), and its corresponding public key is used to verify the token on the vehicle's edge domain 320.

[0181] These tokens are returned to the requesting application in message 934. The connection regarding the return of the tokens may, if applicable, be encrypted to ensure that the tokens are not exposed to eavesdroppers.

[0182] The domain anchor / bridge 810 can request the SS to retrieve insights, as shown here in message 940. The request is accompanied by a scoped token with respect to the specific insight being requested, in the embodiment of Figure 9.

[0183] Once SS B326 verifies the token, it may then provide insights to return to the domain anchor / bridge 810, as indicated in message 942.

[0184] Therefore, in the embodiment shown in Figure 9, the communication model between the application and the SS flows through the bridge. Since the transport crosses the operating system (OS) boundary, Transport Layer Security (TLS) can be used.

[0185] For example, an Insight Sharing Service (SS) can register each of its Remote Procedure Call (RPC) endpoints for TLS protection. These endpoints, along with tokens, can then communicate with the bridge.

[0186] The bridge can then call the RPC endpoint and register the focus on SS insights along with the authorization token.

[0187] When SS generates an insight, SS can share it with the bridge that requested it using a valid token.

[0188] Alternatively, a publish / subscribe transport with TLS security can be used in a similar manner.

[0189] Using a domain bridge approach allows applications to remain simple because it eliminates the need to implement any of the details of security mechanisms. Specifically, an application can call another application, i.e., a domain bridge / anchor, as if the insights were local. That module functions as a data bridge for domain 330. Also, since tokens are never shared, there is no risk of an application leaking tokens. Tokens can still be used to check authorization at the source of insights.

[0190] (Insights via domain bridges and gateways)

[0191] Further embodiments utilize both domain bridges and gateways. Domain bridges may be used to simplify internal interactions with applications. Gateways may be used to simplify external interactions with SS.

[0192] In some cases, the need for a token can be eliminated in this embodiment, as it is possible to rely on a local trust anchor to determine the identity of the requester. However, in other cases, the token can be retained in this embodiment.

[0193] In this embodiment, the role of the domain anchor is to verify identification, while the role of the gateway is to check authorization. The domain anchor and gateway can therefore synchronize the latest set of authorizations when connected to the primary anchor.

[0194] Figure 10 is referenced. In the embodiment of Figure 10, the exemplary permissions and domains from Figure 3 are used with similar numbering. However, they are provided merely for illustrative purposes, and in other embodiments, different domains, SSs, applications, or connections are also possible.

[0195] Furthermore, in the example in Figure 10, a domain anchor / bridge 1010 and a gateway 1012 are provided for the application to gain insights from the SS.

[0196] In the example in Figure 10, application 334 desires to gain insights from SS B326.

[0197] In this regard, an internal communication path exists within domain 330 between application 334 and domain anchor 332. Such a communication path is indicated by connection 1020 and could be any internal process or communication path within the operating system of the computing devices in domain 330. For example, domain anchor / bridge 1010 may have an application program interface used to request or provide data to the domain anchor. Other options are also possible.

[0198] The domain anchor / bridge 1010 may be able to communicate with the primary anchor 312, as shown using connection 1022.

[0199] Furthermore, the domain anchor / bridge 1010 may be able to communicate with the gateway 1012, as shown using connection 1030.

[0200] The gateway communicates internally with the SS within edge domain 320, and the connection with SS B326 is indicated as connection 1050.

[0201] Connections 1022 and 1030 may utilize communication subsystems within domain 330 for actual communication. For example, domain 330, in particular domain anchor / bridge 1010, may utilize a cellular communication module associated with domain 330 to send Internet Protocol requests to primary anchor 312, if any. Similarly, domain 330 and edge domain 320 may enable communication via wired or wireless connections such as Bluetooth®, Bluetooth® Low Energy, CANBus, and Ethernet®, among other options.

[0202] Using the embodiment shown in Figure 10, the application may employ a validation approach to gain insights. See Figure 11.

[0203] In the embodiment shown in Figure 11, the domain anchor / bridge 1010 will communicate with the primary anchor 312 and synchronize the authorization periodically or on an ad-hoc basis, as indicated by the arrow 1120. Specifically, while the embodiment in Figure 11 shows only a single synchronization of authorization, in practice, the domain anchor / bridge 1010 may synchronize the authorization with the primary anchor 312 based on various options. For example, synchronization may occur when an internet connection, such as connection 1022, is established. In other cases, if the vehicle is out of range for a period of time, and then the authorization is synchronized when the range is restored. In other cases, the authorization may be synchronized after a timer expires. In other cases, the authorization may be synchronized on the first occasion after a specific date and time has elapsed. Other options are also possible.

[0204] In this way, a local instance of table 318 is stored in the vehicle. This further speeds up the process by providing access to insights while the vehicle is outside the communication range of cloud service 310 and by eliminating the delay in obtaining permission from cloud service 310.

[0205] Similar synchronization may occur in the edge anchor (not shown) so that it also has a local copy of the permissions. In other cases, synchronization may occur only in the edge anchor and primary anchor, and the edge anchor may then provide access to the local table to the domain anchor / bridge. Other options are also possible.

[0206] When application 334 is installed on the vehicle's domain 330, the application requests registration with the domain anchor / bridge 1010 installed within domain 330. Such a registration request is indicated by message 1130. In this case, message 1130 may indicate that the application is requesting insight for the first time.

[0207] In some embodiments, application 334 may check the signature of an application package that provides a domain anchor / bridge in an Android® automotive instance. For example, in an Android® system, application 334 may check the signature of an Android® package kit (APK) that provides a domain anchor / bridge in an Android® automotive instance.

[0208] In block 1132, a component within the domain anchor / bridge 1010 extracts the application signature from message 1130. It then checks the permissions in the local instance of table 318 to determine whether application 334 has permission to access the insights from the synthetic sensor from which the request was made. In this way, the domain anchor / bridge can verify the identity of application 334 and verify that application 334 is a valid client application authorized to request insights about the vehicle.

[0209] Based on the verification in block 1132, the domain anchor / bridge may then send a request for insight to the gateway 1012, as shown in message 1140. For example, the request in message 1140 may be reqInsightFor(sign(da,{app.a,params})). In this message, the application identifier and parameters are signed using the private key of domain 330. Since the gateway and the domain anchor / bridge are authenticated with each other, no tokens are required for such communication. In particular, in block 1142, an authorization status check is performed at the gateway 1012, and based on the check, insight may be returned.

[0210] Specifically, gateway 1012 may request insights from SS B326, as indicated in message 1150, and receive insights back as message 1152. Since the gateway is known to SS B, no checks may be required for message 1150.

[0211] Gateway 1012 may then return the insights in message 1160 to domain anchor / bridge 1010.

[0212] The domain anchor / bridge 1010 may then provide insights to application 334 using message 1162.

[0213] Therefore, in the embodiment shown in Figure 11, the communication model between the application and the SS uses both a gateway and a bridge. Transport between the bridge and the gateway can use Transport Layer Security (TLS) because it crosses the operating system (OS) boundary.

[0214] (Cloud application for accessing insights)

[0215] While in-vehicle applications request insights from synthetic sensors, as in the embodiments described above, web-based or other network-based applications may also request similar data.

[0216] Here, Figure 12 is referenced, illustrating the use of both domain bridges and gateways for web or network-based applications. Cloud bridges can be used to simplify internal interactions with applications. Gateways can be used to simplify external interactions with SS.

[0217] In some cases, the need for a token can be eliminated in this embodiment, as it is possible to rely on a local trust anchor to determine the identity of the requester. However, in other cases, the token may be retained in this embodiment.

[0218] In this embodiment, the role of the cloud anchor is to verify identification, while the role of the gateway is to check authorization. The cloud anchor and gateway can therefore synchronize the latest set of authorizations when connected to the primary anchor.

[0219] Figure 12 is referenced. In the embodiment of Figure 12, the exemplary permissions and domains from Figures 3 and 10 are used with similar numbering. However, they are provided merely for illustrative purposes, and in other embodiments, different domains, SSs, applications, or connections are also possible.

[0220] In the embodiment shown in Figure 12, a cloud domain 1210 is provided. The cloud domain 1210 includes a cloud anchor / bridge 1220, along with a certificate or key store 1223. The certificate or key store 1223 may be provisioned using the public key of the primary anchor 312. Furthermore, the certificate or key store may be used to create or store a public / private key pair for the cloud anchor, referred to as "CA" with respect to the public key and "ca" with respect to the private key, in the embodiment shown in Figure 12.

[0221] In the embodiment shown in Figure 12, three applications, namely applications 1224, 1226, and 1228, are shown as cloud applications. However, the use of these three applications is provided for illustrative purposes only and is not limiting. Fewer or more applications than three may exist in practice.

[0222] Furthermore, in the example in Figure 12, the gateway 1212 is provided within the edge domain so that the application can gain insights from the SS.

[0223] In the example in Figure 12, application 1224 desires to gain insights from SS B326.

[0224] In this regard, an internal communication path within the cloud domain 1210 exists between the application 334 and the domain anchor 332. Such a communication path is indicated by connection 1222 and can be any internal process or communication path within the operating system of the computing devices of the cloud domain 1210. For example, the cloud domain anchor / bridge 1220 may have an application program interface that is used to request data from or provide data to the cloud domain anchor / bridge. Other options are also possible.

[0225] The cloud domain anchor / bridge 1220 may be able to communicate with the primary anchor 312, as shown using connection 1240.

[0226] Furthermore, the cloud domain anchor / bridge 1220 may be able to communicate with the gateway 1230, as shown using connection 1242.

[0227] The gateway 1230 communicates internally with the SS within the edge domain 320, and the connection to the SS B 326 is shown as connection 1250.

[0228] Connections 1240 and 1242 may utilize the communication subsystem within the cloud domain 1200 for actual communication. For example, the cloud domain 1210, particularly the cloud domain anchor / bridge 1220, may in some cases utilize the cellular communication module associated with the cloud domain 1210 to send Internet protocol requests to the gateway 1230 on the edge domain 320. Similarly, the cloud domain 1210 may enable communication through wired or wireless connections such as fiber, Ethernet®, cellular, satellite, etc., among other options with the cloud service 310.

[0229] Using the embodiment of FIG. 12, the application may use a verification approach to obtain insights. FIG. 13 is referenced.

[0230] In the embodiment shown in Figure 13, the cloud domain anchor / bridge 1210 communicates with the primary anchor 312 and may periodically update the authorization as indicated by the arrow 1320. Specifically, while the embodiment in Figure 11 shows only a single synchronization of authorizations, in practice, the cloud domain anchor / bridge 1210 may synchronize based on expiration time or periodically.

[0231] In other cases, since cloud domain 1210 is a constantly connected network element, local tables may not be necessary.

[0232] Furthermore, in some embodiments, the edge anchor 322 may periodically update the local table using the primary anchor 312 (not shown). For example, synchronization may occur when an internet connection with the vehicle is established. Otherwise, if the vehicle is out of range for a period of time, permission may be synchronized when the range is restored. Otherwise, permission may be synchronized after a timer has expired. Otherwise, permission may be synchronized on the first occasion after a specific date and time has elapsed. Other options are also possible.

[0233] Thus, local instances of table 318 may be stored in the cloud domain 1210, and in some cases, in the vehicle as well.

[0234] When application 1324 is installed on cloud domain 1210, the application requests registration with the cloud anchor / bridge 1220 installed within cloud domain 1210. Such a registration request is indicated by message 1330. In this case, message 1330 may be accompanied by the application requesting insights for the first time.

[0235] In some embodiments, application 1324 may check the signature of the application package that provides the cloud domain anchor in the cloud instance.

[0236] In block 1332, a component within the cloud domain anchor / bridge 1220 extracts the application signature from message 1330. It then checks the permissions in the local instance of table 318 (or, in some embodiments, it may check using the primary anchor) to determine whether application 1324 has permission to access the insights from the synthetic sensor from which the request was made. In this way, the domain anchor / bridge can verify the identity of application 1324 and verify that application 1324 is a valid client application authorized to request insights about the vehicle.

[0237] Based on the verification in block 1332, the cloud domain anchor / bridge may then send a request for insights to gateway 1230, as shown in message 1340. For example, the request in message 1340 may be reqInsightFor(sign(ca,{webapp.a,params})). In this message, the application identifier and parameters are signed using the private key of cloud domain 1210. Since the gateway and domain anchor / bridge are authenticated with each other, no tokens are required for such communication. In particular, in block 1342, an authorization status check is performed at gateway 1230, and based on the check, insights may be returned.

[0238] Specifically, gateway 1230 may request insights from SS B326, as indicated in message 1350, and receive insights returned as message 1352. Since gateway 1350 is known to SS B326, no checks on message 1350 may be required.

[0239] Gateway 1230 can then return the insights in message 1360 to domain anchor / bridge 1220.

[0240] The domain anchor / bridge 1220 may then provide insights to application 1224 using message 1362.

[0241] Therefore, in the embodiment shown in Figure 13, the communication model between the application and the SS uses both a gateway and a bridge, with the bridge residing on a network or cloud element. Transport between the bridge and the gateway can use Transport Layer Security (TLS) because it traverses an operating system (OS) boundary.

[0242] From the embodiments shown in Figures 12 and 13, the authentication step includes deploying a cloud anchor certificate during initial provisioning. The anchor can then be synchronized with the primary anchor to obtain authorization. No tokens are required in this case.

[0243] Cloud anchors can then verify application identification by ensuring that the calling web / network application is a valid client application authorized to request insights about the vehicle.

[0244] The gateway and cloud bridge authenticate each other. Authorization status checks are performed at the gateway, and responses are provided appropriately.

[0245] (Disconnection mode)

[0246] In all of the above embodiments, the vehicle can be disconnected from the cloud server. For this reason, when the vehicle is disconnected from the cloud, there may be configurable policies to ensure the validity of entries in the shared table or to ensure the validity of tokens.

[0247] In some cases, the OEM or agent can assign configurations as follows: a. Valid until the next reconnection; b. Valid until an absolute time when reconnection is not possible (this will typically need to be reset upon connection); c. Valid until a specified time after the last connection when reconnection is not possible; Or, d. Valid for a specified number of refreshes when reconnection is not possible.

[0248] Other options regarding the duration of validity of configurations are also possible.

[0249] In the above, connection implies the ability to securely read changes from the corresponding cloud service when applicable. When an entry or token in the shared table is not valid based on the above configuration, access requests based on it can be rejected.

[0250] The above domains, network elements, cloud services, nodes, and other computing platforms can be implemented using any computing device. A simplified schematic of one computing device is shown with respect to FIG. 14. The computing device of FIG. 14 can be any fixed or mobile computing device.

[0251] In Figure 14, device 1410 includes a processor 1420 and a communication subsystem 1430, the processor 1420 and the communication subsystem 1430 cooperating to carry out the methods of the embodiments described above. The communication subsystem 1430 enables device 1410 to communicate with other devices or network elements and may vary depending on the type of communication to be carried out. Furthermore, the communication subsystem 1430 may comprise multiple communication technologies, including any wired or wireless communication technologies.

[0252] The processor 1420 is stored on the device 1410 along with data and is configured to execute programmable logic, which may be shown in the example in Figure 14, as memory 1432. Memory 1432 may be any tangible, non-transient, computer-readable storage medium that, when executed by the processor 1420, stores instruction code that causes the device 1410 to perform the method of the present disclosure. The computer-readable storage medium may be tangible or transient / non-transient media such as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

[0253] Alternatively, or in addition to memory 1432, device 1410 may access data or programmable logic from an external storage medium, for example, through the communication subsystem 1430.

[0254] In the example in Figure 14, one or more sensors 1440 may be associated with a computing device. However, this is optional, and in some cases, the computing device 1410 may not be associated with any sensors.

[0255] In one embodiment, communication between the various elements of device 1410 may occur via the internal bus 1460. However, other forms of communication are also possible.

[0256] The embodiments described herein are examples of structures, systems, or methods having elements corresponding to elements of the technique of the present application. This description may enable a person skilled in the art to construct and use embodiments having alternative elements similarly corresponding to elements of the technique of the present application. The intended scope of the technique of the present application therefore includes other structures, systems, or methods that are not different from the technique of the present application as described herein, and further includes other structures, systems, or methods that have non-substantial differences from the technique of the present application as described herein.

[0257] While the actions are depicted in a specific order in the diagrams, this should not be understood as requiring that such actions be performed in a specific or sequential order to achieve the desired result, or that all illustrated actions be performed. In some situations, multitasking and parallel processing may be employed. Furthermore, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together within a single software product or packaged within multiple software products.

[0258] Furthermore, techniques, systems, subsystems, and methods described and illustrated in various implementations, either separately or distinctly, may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as being coupled, directly coupled, or communicating with one another may be indirectly coupled or communicated through some interface, device, or intermediate component, whether electrical, mechanical, or otherwise. Other examples of modifications, substitutions, and alterations are verifiable and may be made by those skilled in the art.

[0259] While the above detailed description illustrates, explains, and points out fundamental novel features of this disclosure applicable to various implementations, it should be understood that various omissions, substitutions, and modifications in the form and details of the illustrated system can be made by those skilled in the art. In addition, the order of the method steps is not implied by the order in which they appear in the invoice.

[0260] When messages are sent to and from electronic devices, such actions may not be immediate to or directly from a server. They may be delivered synchronously or asynchronously from servers or other computing system infrastructure supporting the devices / methods / systems described herein. The aforementioned steps may, in whole or in part, involve synchronous / asynchronous communication to and from devices / infrastructure. Furthermore, communication from electronic devices may be to one or more endpoints on a network. These endpoints may be serviced by servers, distributed computing systems, stream processors, etc. Content delivery networks (CDNs) may also provide communication to electronic devices. For example, rather than a typical server response, a server may provision or indicate data for a content delivery network (CDN) to await later download by an electronic device, such as subsequent activity on the electronic device. Thus, data may be sent directly from a server, or other infrastructure such as a distributed infrastructure, or a CDN, either as part of a system or separately.

[0261] Typically, storage media can include any or a combination of the following: semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed, floppy disks, and removable disks; other magnetic media including tapes; optical media such as compact discs (CDs) or digital video discs (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed within a large system potentially having multiple nodes. Such computer-readable or machine-readable storage media or multiple media are considered part of an article (or product). An article or product may refer to any single or multiple manufactured components. The storage medium or multiple mediums may be located either within the machine that invokes the machine-readable instructions, or at a remote location from which the machine-readable instructions can be downloaded over a network for execution.

[0262] Numerous details are provided in the foregoing description to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. The attached claims are intended to cover such modifications and variations.

Claims

1. A method in a network element for securely sharing a service across multiple domains, wherein the method is executed by a processor of the network element, In the aforementioned network element, the processor receives a request to add a first domain and an edge domain to the system, In the aforementioned network element, the processor inputs service information into a table, wherein the service information is provided by the first domain or the edge domain. In the network element, the processor enters authorization information into a second table that corresponds to a subset of applications and service information installed in the first domain or the edge domain. The processor controls the application's access to the service information based on the authorization information. Methods that include...

2. Controlling the aforementioned access means The processor receives a request from an application on the first domain, and the request is signed by the first domain. The processor verifies the request, The processor provides, based on the verification and based on the authorization information relating to the application, to return at least one token relating to the service to the first domain. Includes, The method according to claim 1, wherein the at least one token includes an identifier relating to the service and a signature of the network element.

3. The method according to claim 2, wherein the token further includes an expiration time.

4. Controlling the aforementioned access means The processor receives a request from a domain bridge on the first domain, the request being signed by the first domain and including an application identifier. The processor verifies the request, The processor provides, based on the verification and based on the authorization information relating to the application associated with the application identifier, to return at least one token relating to the service to the domain bridge. Includes, The method according to claim 1, wherein the at least one token includes an identifier relating to the service and a signature of the network element.

5. Controlling the aforementioned access means The processor receives a request from the first domain to synchronize the second table, The processor provides the second table to the first domain. The method according to claim 1, including the method described in claim 1.

6. The method according to claim 1, wherein the table containing service information further includes authorization delegation information relating to at least one of the service information.

7. The method according to claim 1, wherein the first domain and the edge domain belong to a vehicle, and the network element is a vehicle fleet manager.

8. A network element for securely sharing services across multiple domains, wherein the network element is: Processor and Communication subsystem and Equipped with, The aforementioned processor, The aforementioned network element receives requests to add a first domain and an edge domain to the system, In the aforementioned network element, service information is entered into a table, wherein the service information is provided by the first domain or the edge domain. In the network element, permission information corresponding to a subset of applications and service information installed in the first domain or the edge domain is entered into a second table. Based on the permission information, the application's access to the service information is controlled. A network element configured to perform the following actions.

9. The aforementioned processor, The processor receives a request from an application on the first domain, and the request is signed by the first domain. The processor verifies the request, The processor provides, based on the verification and based on the authorization information relating to the application, to return to the first domain at least one token relating to the service, wherein the at least one token includes an identifier relating to the service and a signature of the network element. The network element according to claim 8, configured to control access by

10. The network element according to claim 9, wherein the token further includes an expiration time.

11. The aforementioned processor, The processor receives a request from a domain bridge on the first domain, the request being signed by the first domain and including an application identifier. The processor verifies the request, The processor provides, based on the verification and based on the authorization information relating to the application associated with the application identifier, to return to the domain bridge at least one token relating to the service, wherein the at least one token includes an identifier relating to the service and a signature of the network element. The network element according to claim 8, configured to control access by

12. The aforementioned processor, The processor receives a request from the first domain to synchronize the second table, The processor provides the second table to the first domain, The network element according to claim 8, configured to control access by

13. The network element according to claim 8, wherein the table containing service information further includes authorization delegation information relating to at least one of the service information.

14. The network element according to claim 8, wherein the processor is configured to be provisioned during the manufacture of a computing device having the first domain and the edge domain.

15. The network element according to claim 8, wherein the processor is configured to provision when the computing device, which includes the first domain and the edge domain, is located in a trusted service center.

16. The network element according to claim 8, wherein the first domain and the edge domain belong to a vehicle, and the network element is a vehicle fleet manager.

17. A non-transient, computer-readable medium for storing instruction code, wherein the instruction code is executed by a processor of a network element configured to securely share services across multiple domains. The aforementioned network element receives requests to add a first domain and an edge domain to the system, Provisioning the public key of the network element to the first domain and the edge domain, Receiving the public key of the first domain, In the aforementioned network element, service information is entered into a table, wherein the service information is provided by the first domain or the edge domain. In the network element, permission information corresponding to a subset of applications and service information installed in the first domain or the edge domain is entered into a second table. Based on the permission information, the application's access to the service information is controlled. A non-transient, computer-readable medium that causes the processor of the network element to perform the following action.

18. The aforementioned instruction code is, Receiving a request from an application on the first domain, wherein the request is signed by the first domain, To verify the aforementioned requirements, Based on the verification and based on the authorization information relating to the service relating to the application, provide to return to the first domain at least one token relating to the service, wherein the at least one token includes an identifier relating to the service and a signature of the network element. The computer-readable medium according to claim 17, wherein the processor of the network element further controls access by means of the medium.

Images