Method and system for indirect sharing of sensor insights - Patent Application 20070122997

Abstract

A method in a first domain for obtaining at least one insight from a second domain, the method including: 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 an identity of the application; verifying at the bridge application authorization using the authorization table in the first domain, where verifying confirms 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, requesting the insight; and receiving the insight from the second domain.

Description

[Technical Field]

[0001] The present disclosure relates to distributed systems, and more particularly to data security in distributed systems. [Background technology]

[0002] Modern vehicles have many sensors. However, such sensors may be distributed among various computing nodes on the vehicle, and each computing node may have access to zero, one, or more sensor drivers. Such sensor nodes may even have different manufacturers and operate using different operating systems. Similarly, other distributed systems may have multiple nodes that 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 insight. In some cases, insights can be generated based on proprietary algorithms, machine learning code, or similar processes and can be useful. Such insights may need to be shared with authorized software modules running in external domains, where security may vary. Summary of the Invention [Means for solving the problem]

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

[0005] The present 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 configured to: register an application with an anchor in the first domain; provide a first message from the anchor to the application, the first message being signed by the anchor; send the signed message from the first domain to a network domain; receive at least one signed token from the network domain, each of the at least one signed token being for a synthetic sensor on the second domain, the synthetic sensor providing the insight; send a request message to the second domain, the request message requesting insight and including at least one token; and receive the insight from the synthetic sensor associated with the at least one token.

[0006] The present disclosure further provides a computer-readable medium for storing instruction code that, 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 a first message from the anchor to the application, the first message being signed by the anchor; send the signed message from the first domain to a network domain; receive at least one signed token from the network domain, wherein each of the at least one signed token is for a synthetic sensor on the second domain, the synthetic sensor providing the insight; send a request message to the second domain, the request message requesting insight and including the at least one token; and receive the insight from the synthetic sensor associated with the at least one token.

[0007] The present disclosure further provides a method in a first domain for obtaining at least one insight from a second domain, the method including: 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 an identity of the application; verifying, at the bridge, application authorization using the authorization table in the first domain, where verifying confirms that the application has authorization to access the insight; sending a request message from the first domain to a second domain, the request message being signed with a private key of the first domain, requesting the insight; and receiving the insight from the second domain.

[0008] The present 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 being configured to: synchronize a permission table in the first domain with a master permission table in a network element; receive a request for insight from an application at a bridge in the first domain; verify an identity of the application; verify, at the bridge, application permissions using the permission table in the first domain, where verifying confirms that the application has permission to access the insight; send a request message from the first domain to a second domain, the request message being signed with a private key of the first domain, requesting the insight; and receive the insight from the second domain.

[0009] The present disclosure further provides a computer-readable medium for storing instruction code that, 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 a permission table in the first domain with a master permission table in a network element; receive a request for insight from an application at a bridge in the first domain; verify an identity of the application; verify, at the bridge, application permissions using the permission table in the first domain, where verifying confirms that the application has permission to access the insight; send a request message from the first domain to a second domain, the request message being signed with a private key of the first domain, requesting the insight; and receive the insight from the second domain.

[0010] The present disclosure further provides 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 the public key of the first domain; entering, at the network element, services provided by the first domain or the edge domain into a table; entering, at the network element, permissions for applications and services for the applications installed in the first domain or the edge domain into a second table; and controlling access to the services by the applications.

[0011] The present 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 configured to: receive, at the network element, a request to add a first domain and an edge domain to a system; provision a public key of the network element to the first domain and the edge domain; receive the public key of the first domain; enter, at the network element, services provided by the first domain or the edge domain into a table; enter, at the network element, permissions for applications and services for the applications installed in the first domain or the edge domain into a second table; and control access to the services by the applications.

[0012] The present disclosure further provides a computer-readable medium for storing instruction code that, when executed by a processor of a network element configured for securely sharing services across domains, causes the network element to: receive a request to add a first domain and an edge domain to a system; provision a public key of the network element to the first domain and the edge domain; receive the public key of the first domain; enter, at the network element, services offered by the first domain or the edge domain into a table; enter, at the network element, permissions for applications and services for the applications installed in the first domain or the edge domain into a second table; and control access to the services by the applications. The present invention provides, for example, the following items. (Item 1) 1. 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 application permissions at the bridge using the permission table in the first domain, wherein the verifying confirms that the application has permission 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, requesting the insight; receiving the insight from the second domain; and A method comprising: (Item 2) Item 10. The method of item 1, wherein a trust relationship exists between the bridge and the network element. (Item 3) Item 3. The method of item 2, wherein the trust relationship is established based on secure provisioning of the bridge. (Item 4) 2. The method of claim 1, wherein sending the request message to the second domain includes sending the request message to a gateway associated with a synthetic sensor on the second domain, the synthetic sensor providing the insight. (Item 5) Item 10. The method of claim 1, wherein the permission table stored in the first domain has an expiration time. (Item 6) Item 6. The method of item 5, wherein the first domain and the second domain are provided with a rule when the first domain and the second domain are not communicating with the network domain and the permission table stored in the first domain expires. (Item 7) The rule is that the permission table: valid until the next reconnection with said network domain; Valid until an absolute time when reconnection is not possible, If unable to reconnect, it is valid for a specified time since the last connection with said network domain; or Valid for a specified number of refreshes when unable to reconnect to said network domain. Item 7. The method according to item 6, wherein (Item 8) Item 10. The method of claim 1, wherein the first domain and the second domain are domains within a vehicle. (Item 9) 9. The method of claim 8, wherein the first domain is an in-vehicle infotainment system within the vehicle. (Item 10) 1. A computing device having a first domain for obtaining at least one insight from a second domain, the computing device comprising: a processor; Communication subsystem and Equipped with the computing device, 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 application permissions at the bridge using the permission table in the first domain, wherein the verifying confirms that the application has permission 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, requesting the insight; receiving the insight from the second domain; and 1. A computing device configured to: (Item 11) Item 11. The computing device of item 10, wherein a trust relationship exists between the bridge and the network element. (Item 12) Item 12. The computing device of item 11, wherein the trust relationship is established based on secure provisioning of the bridge. (Item 13) Item 11. The computing device of item 10, wherein the computing device is configured to send the request message to the second domain by sending the request message to a gateway associated with a synthetic sensor on the second domain, the synthetic sensor providing the insight. (Item 14) Item 11. The computing device of item 10, wherein the permission table stored in the first domain has an expiration time. (Item 15) Item 15. The computing device of item 14, wherein the first domain and the second domain are provided with a rule when the first domain and the second domain are not in communication with the network domain and the permission table stored in the first domain expires. (Item 16) The rule is that the permission table: valid until the next reconnection with said network domain; Valid until an absolute time when reconnection is not possible, If unable to reconnect, it is valid for a specified time since the last connection with said network domain; or Valid for a specified number of refreshes when unable to reconnect to said network domain. Item 16. The computing device of item 15, (Item 17) Item 11. The computing device of item 10, wherein the first domain and the second domain are domains within a vehicle. (Item 18) Item 18. The computing device of item 17, wherein the first domain is an in-vehicle infotainment system within the vehicle. (Item 19) 1. A computer-readable medium for storing instruction codes that, when executed by a processor of a computing device having a first domain for obtaining at least one insight from a second domain, 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 application permissions at the bridge using the permission table in the first domain, wherein the verifying confirms that the application has permission 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, requesting the insight; receiving the insight from the second domain; and A computer-readable medium that causes the computing device to perform the steps of: (Item 20) 20. The computer-readable medium of claim 19, wherein a trust relationship exists between the bridge and the network element. [Brief explanation of the drawings]

[0013] The present disclosure may be better understood with reference to the drawings.

[0014] [Figure 1] FIG. 1 is a block diagram illustrating an example system having an insight producer and an insight consumer.

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

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

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

[0018] [Figure 5] FIG. 5 is a data flow diagram in which an application on a first domain obtains insights directly from synthetic sensors on a second domain.

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

[0020] [Figure 7] FIG. 7 is a data flow diagram in which an application on a first domain utilizes a gateway on a second domain to obtain insights from synthetic sensors on the second domain.

[0021] [Figure 8] FIG. 8 is a block diagram illustrating an example computing system in which an application on a first domain utilizes a bridge on the first domain to obtain insights from synthetic sensors on a second domain.

[0022] [Figure 9] FIG. 9 is a data flow diagram in which an application on a first domain utilizes a bridge on the first domain to obtain insights from a synthetic sensor on a second domain.

[0023] [Figure 10] FIG. 10 is a block diagram illustrating an example computing system in which an application on a first domain utilizes a bridge on the first domain and a gateway on a second domain to obtain insights from synthetic sensors on the second domain.

[0024] [Figure 11]FIG. 11 is a data flow diagram in which an application on a first domain utilizes a bridge on the first domain and a gateway on a second domain to obtain insights from a synthetic sensor on the second domain.

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

[0026] [Figure 13] FIG. 13 is a data flow diagram in which an application on a first network-based domain utilizes a bridge on the first domain and a gateway on a second domain to obtain insights from synthetic sensors on the second domain.

[0027] [Figure 14] FIG. 14 is a block diagram of a simplified computing device that can be used with embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0028] In modern vehicles, information from one or more physical sensors may be processed to create "insights" that may be useful in the system. Such one or more physical sensors and their associated processing may be logically referred to as a microservice or synthetic sensor (SS). The terms microservice and synthetic sensor are used interchangeably herein.

[0029] Synthetic sensors may exist in other types of applications, including, but not limited to, medical applications, manufacturing applications, Internet of Things applications, among others, and the present disclosure is not limited to vehicle applications, a vehicle application being 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 providing high and low reference values ​​for notifications can be considered an "insight." With respect to location services, geofencing is an insight. With respect to cameras, occupant recognition can be an insight. The use of a combination of sensors, such as a temperature sensor and a camera, can be used with an artificial intelligence model to determine if a car seat is occupied in a hot vehicle, which can be an insight. Many other examples of insights are possible.

[0031] In one embodiment, vehicle applications can be implemented in a system that provides consistent access to vehicle data and intelligent insights in a manner that is familiar and accessible to the developer community. Such an environment can enable cloud developers to extend their reach to the edge within 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 can provide consistent access to vehicle data so that synthetic sensors can be written and deployed across a broad vehicle base without bespoke customization.

[0032] While insights may be generated based on processors running on a first facility or domain, they often need to be shared with authorized software modules running in external domains. The first domain controls the installation and communication of modules within it and is therefore able to determine their identity and authorization. However, the first domain does not have such control over other domains.

[0033] For example, one external domain may be an automobile's in-vehicle infotainment (IVI) system, which may access insights and launch applications that provide information to the driver.

[0034] The modules or applications that can use the insights, whether they are within the first domain or outside the first domain, are determined by a manager or actor referred to herein as the fleet manager. The implementation of such modules or applications and their access to insights may, in some embodiments, be controlled by the fleet manager. However, for 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. The fleet manager, in this case, may select or approve the first insight. In other cases, the fleet manager may allow the driver to select which insights to obtain / use.

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

[0036] In some embodiments, the system must also consider disconnected modes. Specifically, a vehicle may not always have access to the fleet manager, such as 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 of time, such as when the vehicle is parked in a rural area without any cellular service.

[0037] Thus, the present disclosure provides a method and system for distributing insights only to authorized modules within an external domain.

[0038] (Example Distributed System)

[0039] Reference is now made to Figure 1, which illustrates an exemplary system showing various producers and consumers of insights. The embodiment of Figure 1 is provided solely for illustrative purposes; in some cases, there will be fewer participants in the system. In other cases, there will be more participants in the system.

[0040] 1, vehicle 100 may be equipped with a computing system and a communication system. Portions of the computing systems may include domains 110, which may have applications that consume insights, as described below. Additionally, portions of the computing systems on vehicle 110 may include edge domains 112. In some embodiments, edge domains 112 may generate insights. However, in other cases, insights may be generated within domains 110 or consumed within edge domains 112.

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

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

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

[0044] In some embodiments, insights may be generated or consumed by cloud domain 150. Cloud domain 150 may communicate with cloud service provider 140 through network 132 and, in some cases, with other domains, such as domain 112 on vehicle 100.

[0045] Furthermore, devices 160, rather than vehicles, may generate or consume insights. Devices 160 may be any computing device capable of generating or consuming such insights and may include Internet of Things devices, mobile devices, medical equipment, vehicles, or equipment associated with vehicles, among other options. Devices 160 communicate through networks 132 implementing various wired or wireless technologies, including, but not limited to, Ethernet, fiber, cellular, Wi-Fi, and satellite, among other options.

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

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

[0048] The present disclosure will be described with respect to an automotive system with distributed nodes, however, that is provided merely for illustrative purposes and the methods and systems described herein may be equally used with any other distributed system.

[0049] Reference is now made to Figure 2, which shows one simplified distributed system.

[0050] 2, a cloud services domain 210 may be associated with the fleet manager. The cloud services domain 210 includes a primary anchor module 212. One purpose of the primary anchor module relates to security for insight into the system.

[0051] Cloud services domain 210 further includes a certificate or key store 214. As described below, in embodiments herein, the system may be securely installed in a vehicle and back-end information technology infrastructure. Installation may include provisioning of a key in a secret store in the vehicle that can be verified by the fleet manager from outside the vehicle using the information technology infrastructure. The secret store may use a hardware key encryption key (KEK) to protect the provisioned key and prevent other software modules from accessing the secret. A public / private key pair may be generated in the vehicle, and the public key may be shared over a trusted link. Alternatively, a symmetric secret key may be injected into the vehicle using a trusted connection by the fleet manager, and a copy may be stored in the information technology infrastructure. In either case, a means of authenticating the identity of the provisioned system in the field is achieved.

[0052] 2, certificate or key store 214 stores a certificate for primary anchor 212 and a private key for primary anchor 212. Certificate or key store 214 may further store various domain certificates for domain anchors, as described below.

[0053] In the embodiment of FIG. 2, a first domain, referred to as edge domain 220, may be used to provide insights from synthetic sensors. The domain is referred to as an edge domain based on the cloud's perspective, which indicates that it is on the edge of the cloud. Edge domain 220 is installed on a vehicle with a vehicle identifier. While the embodiment of FIG. 2 shows a single edge domain, in practice, multiple edge domains may exist in a vehicle.

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

[0055] The edge domain 220 further includes a certificate or key store 223 that can be used to store certificates for the primary anchors 212 .

[0056] 2, these composite sensors, i.e., SS 224, SS 226, and SS 228, are part of edge domain 220. Although three composite sensors are shown, in practice, fewer or more composite sensors may be present within the edge domain.

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

[0058] Domain 230 includes a domain anchor 232 that is used to provide security for insight, among other functionality.

[0059] Domain 230 further includes a certificate or key store 233, which may include storage for the certificate associated with domain anchor 232 as well as storage for the key for primary anchor 212.

[0060] 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, and fewer or more applications may be associated with a particular domain.

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

[0062] 2, edge domain 220 and domain 230 may 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 cloud service 210 may be through wireless technologies such as cellular connections, satellite connections, wide area networks (WANs) such as Wi-Fi, among other options. Additionally, in some cases, communication may be through a wired connection, 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] Failure of a domain to connect to an edge domain for control messages would also mean failure to gain insight. Typically, domains inside a vehicle are connected by an on-board 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 trusted. Therefore, message integrity and confidentiality cannot be guaranteed when communicating between domains, and optional DOS defenses, if any, can be employed.

[0065] Furthermore, in some cases, connectivity from the Internet to the vehicle may be intermittent. Thus, the fleet manager and information technology infrastructure may not always be connected to the edge domain 220. When the vehicle is disconnected, only the connected domains inside the vehicle can obtain insights from the edge domain 220. According to some embodiments herein, the last state of authorizations synchronized between the edge domain and the fleet manager may be respected when the edge domain is disconnected from the cloud service 210.

[0066] (Provisioning)

[0067] A trusted element may be provisioned within the vehicle environment during vehicle manufacture or subsequently at a trusted service center.

[0068] For example, a vehicle leaving a 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 that is part of the fleet owner-controlled information technology infrastructure is connected to the factory via a secured link. This trusted computer, called the primary anchor 212, identifies and associates keys and certificates with one or more vehicle identifiers as part of the provisioning process.

[0070] A module within edge domain 220 that has access to secured storage, such as certificate or key store 223, is designated as a trust anchor (edge ​​anchor 222) for edge domain 220. Edge anchor 222 receives and stores at least one public key (and certificate) from primary anchor 212, and edge anchor 222, along with various SSs within the edge domain, uses the at least one public key (and certificate) to check whether a message was signed using the private key of primary anchor 212. This is shown in the embodiment of FIG. 2 as public key "PA" and private key "pa."

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

[0072] Domain anchor 232, in one embodiment, uses certificate or key store 233 to generate an asymmetric key pair, for example, shown as public / private key pair DA / da in the example of 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 including the public key is sent to the information technology infrastructure while the private key of the domain anchor 232 remains secure in the certificate or key store 233. The information technology infrastructure returns a certificate signed by the private key of the primary anchor 212.

[0074] In this embodiment, domain anchor 232 and primary anchor 212 now 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 by domain anchor 232 to reach primary anchor 212 when connectivity is available.

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

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

[0077] (permission)

[0078] To express the security expected from a protocol insight, one or more insights are bound to a permission. Reference is now made to FIG.

[0079] 3, cloud service 310 includes primary anchor 312 and certificate or key store 314. The cloud service further includes a permissions table, as shown in table 316, which includes a table that associates particular fleet identifiers with particular permissions.

[0080] Additionally, table 317 includes identifiers for edge domains, including vehicle identifiers, along with the types of permissions provided for and delegated with respect to that edge domain, as described below.

[0081] An application table 318 associates applications on a particular domain with permissions and whether the application is activated in the domain.

[0082] The permission table in the example of Figure 3 is provided merely as an example and not as a limitation. In some cases, more information may be provided in any 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 the vehicle. The edge domain 320 includes an edge anchor 322 and a certificate or key store 323.

[0084] In the example of FIG. 3, edge domain 320 includes three composite sensors: SS A 324, SS B 326, and SS C 328.

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

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

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

[0088] In an embodiment of the present disclosure, permissions are defined globally and are scoped to be enforced within an edge domain by one particular SS.

[0089] A set of permissions is deployed on the vehicle at any point in time, this set is known and configured in the information technology infrastructure domain within cloud services 310.

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

[0091] For example, one vehicle manufacturer may decide that all insights should be provided from synthetic sensors approved only by that vehicle manufacturer. In this case, no delegation of permissions is provided. In another case, a second vehicle manufacturer may allow the source of certain types of insights to be selected by the vehicle driver; these would be referred to as delegated permissions.

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

[0093] 3, a controlling entity, such as a fleet manager, may approve the installation and associated permissions of a synthetic sensor on a set of vehicles. The insight-generating synthetic sensor, such as sensors 324, 326, or 328, may then be installed on edge domain 320.

[0094] (Mechanism for sharing insights)

[0095] As described above, in embodiments of the present disclosure, modules (also referred to as applications) may be enabled to receive insights. However, applications ultimately represent authors, i.e., humans or institutions. Modules further represent a point in time, as indicated by their versions.

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

[0097] If available, such a system may use security mechanisms of other domains to determine the authenticity of the application name and version. For example, if the domain is an Android® domain, then Android® application name, version, and signature attestations may be used. Similar attestations may be found in domains running different operating systems.

[0098] Synthetic sensors are assumed in this disclosure to be in charge of their own interests and unlikely to hand over their insights to other SSs. It is also expected that most applications that are authorized to receive SS insights will not willingly 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 insight than they are authorized for, and therefore it is expected that they will use all of the insight and metadata available to them.

[0100] Thus, according to embodiments of the present disclosure, the system may limit the scope of insights and metadata to a minimum set of applications represented by the fleet manager, limiting the exposure of insights resulting from occasional security incidents.

[0101] Based on this, the following sections describe different ways to achieve the goal of securing insight sharing outside the edge domain. Alternatives are discussed that trade off complexity and security responsibilities with performance and fault tolerance.

[0102] (Independent application request for insights)

[0103] An embodiment is provided herein in which an application in an external domain may securely request insights from an SS using provisioned credentials and permissions. Reference is now made to FIG. 4.

[0104] In the embodiment of Figure 4, the example permissions and domains from Figure 3 are used with similar numbers, however, that is provided merely for illustration purposes, and in other embodiments, different domains, SS, applications, or connections are possible.

[0105] In the example of FIG. 4, application 334 desires to gain insight from SS B 326 .

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

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

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

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

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

[0111] Utilizing the embodiment of Figure 4, applications may use a token-based approach to gain insights. See Figure 5.

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

[0113] When that application 334 is installed on the vehicle's domain 330, the application requests to be registered with the domain anchor 332 installed within the 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 automobile 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® automobile instance.

[0115] In block 522, a component within the domain anchor 332 uses the operating system platform to determine the application name, version, and package signature hash of the requested package. It may then append a vehicle identifier, sign this information, and leverage the domain anchor private 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 includes the vehicle identifier, the application identifier, and the domain anchor's private key for signing the message with the application signature, and may include other factors such as the time of day and validity duration for the authenticated application message, among other information.

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

[0118] The locally authenticated application message may then be sent to the primary anchor 312 along with the vehicle identifier in message 530. The connection for the locally authenticated application message may, in some cases, be encrypted to ensure that the information is not exposed to eavesdroppers.

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

[0120] During validation, the primary anchor 312, in block 532, retrieves the set of permissions available to the application on the particular vehicle, creates a token for them, and signs the token with the primary anchor private key (pa), whose corresponding public key is used to validate the token on the vehicle's edge domain 320.

[0121] For example, such a token may be generated using the command tkn_auth_ins_B_pa = Sign(pa,{SS.B,timeOfDay+validity}). In this case, the token contains the insight B that allows it to be accessed. The token contains SS, and in some embodiments may contain the time of day and validity duration. The token is signed with the primary anchor's private key "pa".

[0122] These tokens are returned to the requesting application in message 534. The connection for returning the tokens may, in some cases, be encrypted to ensure that the tokens are not exposed to eavesdroppers.

[0123] The requesting application can now make a request to the SS to retrieve insights, as shown in message 540. The request is accompanied by a token that, in the embodiment of Figure 5, is scoped to the particular insight requested.

[0124] Once the SS B 326 validates the token, it may then provide the insight back to the application 334 as shown in message 542 .

[0125] Therefore, in the embodiment of Figure 5, the communication model between the application and the SS is assumed to be direct. The transport may use Transport Layer Security (TLS) since it crosses Operating System (OS) boundaries.

[0126] For example, insight-sharing SSs can register their respective remote procedure call (RPC) endpoints with TLS protection, which can be communicated to the application 334 along with a token.

[0127] When an application becomes interested, it can call the RPC endpoint and register its interest in SS insights along with an authorization token.

[0128] Once the SS generates an insight, it can share it with the application that requested it using a valid token.

[0129] Alternatively, publish / subscribe transport with TLS security can be used as well.

[0130] 4 and 5 thus enables a communication model that leverages the microservices nature of the platform to efficiently share insights without a single point of failure. It uses domain anchors as trust anchors to establish the trustworthiness of applications 334.

[0131] (Independent application requests for insights using the gateway)

[0132] In some embodiments, it may not be desirable to have the SS directly act as a server or communication endpoint. For example, the SS may be written by a third party that may be considered less security-conscious. For these scenarios, communication may be through an application program interface (API) gateway. The gateway may act as a reverse proxy for external requesters of insights; the gateway may perform authorization checks and even combine the results of two or more SSs.

[0133] The addresses of the gateways can be sent to the application 334 when the application 334 is sent with the token, or they can be published so that they are well known within the domain 330. Reference is now made to Figure 6.

[0134] In the embodiment of Figure 6, the example permissions and domains from Figure 3 are used with similar numbers, however, that is provided merely for illustration purposes, and in other embodiments, different domains, SS, applications, or connections are possible.

[0135] Additionally, in the example of FIG. 6, a gateway 610 is provided for applications to gain insight from the SS.

[0136] In the example of FIG. 6, application 334 desires to gain insight from SS B 326 .

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

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

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

[0140] The gateway communicates internally with SSs within edge domain 320 , and the connection with SS B 326 is shown as connection 650 .

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

[0142] Utilizing the embodiment of Figure 6, applications may use a token-based approach to gain insights. See Figure 7.

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

[0144] When that application 334 is installed on the vehicle's domain 330, the application requests registration with the domain anchor 332 installed within the 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 automobile 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® automobile instance.

[0146] In block 722, a component within the domain anchor 332 uses the operating system platform to determine the application name, version, and package signature hash of the requested package. It may then append a vehicle identifier, sign this information, and utilize the domain anchor private 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 includes the vehicle identifier, the application identifier, and the domain anchor's private key for signing the message with the application signature, and may include other factors such as the time of day and validity duration for the authenticated application message, among other information.

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

[0149] The locally authenticated application message may then be sent to the primary anchor 312 along with the vehicle identifier in message 730. The connection for the locally authenticated application message may, in some cases, be encrypted to ensure that the information is not exposed to eavesdroppers.

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

[0151] During validation, the primary anchor 312, in block 732, retrieves the set of permissions available to the application on the particular vehicle, creates a token for them, and signs the token with the primary anchor private key (pa), whose corresponding public key is used to validate the token on the vehicle's edge domain 320.

[0152] For example, such a token may be generated using the command tkn_auth_ins_B_pa = Sign(pa,{SS.B,timeOfDay+validity}). In this case, the token contains the insight B that allows it to be accessed. The token contains SS, and in some embodiments may contain the time of day and validity duration. The token is signed with the primary anchor's private key "pa".

[0153] These tokens are returned to the requesting application in message 734. The connection for returning the tokens may, in some cases, be encrypted to ensure that the tokens are not exposed to eavesdroppers.

[0154] A requesting application can now request to retrieve insights as shown in message 740 by utilizing gateway 610. The request is accompanied by a token that, in the embodiment of Figure 7, is scoped to the particular insight requested.

[0155] Once the gateway 610 validates the token, it may then request insight from SS B 326, as shown in message 750. Because the origin of message 750 is known to SS B, no validation may be required to return the insight in message 752 to the gateway 610.

[0156] The gateway 610 may then provide the insight back to the application 334 as shown in message 760 .

[0157] 7, the communication model between the application and the SS uses a gateway, and the transport between the application and the gateway can use Transport Layer Security (TLS) because it crosses an operating system (OS) boundary.

[0158] When an application becomes interested, it can call an RPC endpoint to the gateway and register its interest in the SS insights along with an authorization token.

[0159] When the SS generates an insight, it may inform the gateway 610, which can then share it with the application that requested it using a valid token.

[0160] Alternatively, publish / subscribe transport with TLS security can be used as well, but using a gateway.

[0161] Although the SS gateway 610 introduces a single point of failure into the vehicle, one of the benefits is that requirements from different heterogeneous domains can be accommodated by adding adapters within the gateway.

[0162] In some cases, the insight gateway can be further reverse proxied 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 the foreign domain to act as a proxy for insights, where cryptographic keys from a trust anchor running within the foreign domain are shared with the particular domain. For example, see now FIG. 8.

[0165] In the example of Figure 8, the domain anchor shares a public key / certificate with the edge domain through their mutual trust in the primary anchor. This certificate may need to be renewed periodically. Messages signed by the private key corresponding to that certificate are trusted by the SS to enable external TLS connections to the insight generation interface. Renewal may occur in the vehicle upon disconnection from the network for a configured number of times to allow service continuity.

[0166] In the embodiment of Figure 8, the example permissions and domains from Figure 3 are used with similar numbers, however, that is provided merely for illustration purposes, and in other embodiments, different domains, SS, applications, or connections are possible.

[0167] In the example of FIG. 8, application 334 desires to gain insight from SS B 326 .

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

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

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

[0171] Connections 830 and 840 may utilize communication subsystems within domain 330 for the actual communication. For example, domain 830, and in particular domain anchor / bridge 810, may utilize a cellular communication module associated with domain 330 to transmit Internet Protocol requests to primary anchor 312, in some cases. Similarly, domain 330 and edge domain 320 may enable communication through wired or wireless connections such as Bluetooth, Bluetooth low energy, CANBus, Ethernet, among other options.

[0172] Utilizing the embodiment of Figure 8, applications may use a token-based approach to gain insights. See Figure 9.

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

[0174] When that application 334 is installed on the vehicle's domain 330, the application requests registration with the domain anchor / bridge 810 installed within the 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 automobile 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® automobile instance.

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

[0177] The locally authenticated application message may then be sent to the primary anchor 312 along with the vehicle identifier in message 930. The connection for the locally authenticated application message may, in some cases, be encrypted to ensure that the information is not exposed to eavesdroppers.

[0178] For example, such a message may be a request for tokens and may be generated using the command getAuthTokensFor(Sign(da, {app.a, app.a.sig, Nonce,}), where a signature using the private key of the domain 330, the authenticated application message, and a nonce to prevent replay attacks are provided.

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

[0180] During validation, the primary anchor 312, in block 932, retrieves the set of permissions available to the application on the particular vehicle, creates a token for them, and signs the token with the primary anchor private key (pa), whose corresponding public key is used to validate the token on the vehicle's edge domain 320.

[0181] These tokens are returned to the requesting application in message 934. The connection for returning the tokens may, in some cases, be encrypted to ensure that the tokens are not exposed to eavesdroppers.

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

[0183] Once the SS B 326 validates the token, it may then provide insight back to the domain anchor / bridge 810 as shown in message 942 .

[0184] 9, the communication model between the application and the SS flows through a bridge. The transport can use Transport Layer Security (TLS) because it crosses operating system (OS) boundaries.

[0185] For example, SSs sharing insights can register their respective remote procedure call (RPC) endpoints with TLS protection, and these endpoints, along with a token, can be communicated to the bridge.

[0186] The bridge can then call the RPC endpoint and register its interest in the SS insight along with the authorization token.

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

[0188] Alternatively, publish / subscribe transport with TLS security can be used as well.

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

[0190] (Insights via Domain Bridges and Gateways)

[0191] Further embodiments use both a domain bridge and a gateway. A domain bridge may be used to simplify internal interactions with applications. A gateway may be used to simplify external interactions with SSs.

[0192] In some cases, in this embodiment, the need for tokens can be eliminated because a local trust anchor can be relied upon to determine the identity of the requestor, however, in other cases, tokens can be maintained in this embodiment.

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

[0194] Reference is made to Figure 10. In the embodiment of Figure 10, the example permissions and domains from Figure 3 are used with similar numbers. However, this is provided merely for illustration purposes, and in other embodiments, different domains, SSs, applications, or connections are possible.

[0195] Additionally, in the example of FIG. 10, a domain anchor / bridge 1010 and gateway 1012 are provided to allow applications to gain insight from the SS.

[0196] In the example of FIG. 10, application 334 desires to gain insight from SS B 326 .

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

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

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

[0200] The gateway communicates internally with SSs within the edge domain 320 , and the connection with SS B 326 is shown as connection 1050 .

[0201] Connections 1022 and 1030 may utilize communication subsystems within domain 330 for the actual communication. For example, domain 330, and in particular domain anchor / bridge 1010, may utilize a cellular communication module associated with domain 330 to transmit Internet Protocol requests to primary anchor 312, in some cases. Similarly, domain 330 and edge domain 320 may enable communication over wired or wireless connections such as Bluetooth, Bluetooth low energy, CANBus, Ethernet, among other options.

[0202] Utilizing the embodiment of Figure 10, an application may use a validation approach to gain insight. See Figure 11.

[0203] In the embodiment of FIG. 11 , domain anchor / bridge 1010 will communicate with primary anchor 312 and synchronize permissions periodically, as indicated by arrow 1120, or from time to time. Specifically, while the embodiment of FIG. 11 shows only a single synchronization of permissions, in practice domain anchor / bridge 1010 may synchronize permissions with 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 cellular coverage for a period of time, then permissions may be synchronized when cellular coverage is restored. In other cases, permissions may be synchronized after a timer expires. In other cases, permissions may be synchronized at the first opportunity after a specific date and time has passed. Other options are possible.

[0204] In this way, a local instance of table 318 is stored in the vehicle, which provides access to insights while the vehicle is out of communication coverage of cloud service 310, further expediting the process by eliminating delays in obtaining authorization from cloud service 310.

[0205] Similar synchronization can occur at the edge anchor (not shown) so that the edge anchor has a local copy of the permissions as well. Alternatively, synchronization can occur only at the edge anchor and primary anchor, and the edge anchor can then provide access to the local table to the domain anchor / bridge. Other options are possible.

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

[0207] In some embodiments, application 334 may check the signature of an application package that provides a domain anchor / bridge in an automobile 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® automobile instance.

[0208] In block 1132, a component within the domain anchor / bridge 1010 extracts the application signature from the message 1130. It may then check the permissions in its local instance of table 318 to determine whether the application 334 has permission to access insights from the synthetic sensor for which the request was made. In this way, the domain anchor / bridge may verify the identity of the application 334 and verify that the 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's identification and parameters are signed with the private key of the domain 330. Because the gateway and domain anchor / bridge are mutually authenticated, no token is required for such communication. In particular, in block 1142, an authorization status check may be performed in the gateway 1012, and based on the check, insight may be returned.

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

[0211] The gateway 1012 may then return the insight in message 1160 to the domain anchor / bridge 1010 .

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

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

[0214] (Cloud application for accessing insights)

[0215] While in-vehicle applications request insights from synthetic sensors, as in the above embodiment, it is also possible that web-based or other network-based applications request similar data.

[0216] Reference is now made to Figure 12, which illustrates the use of both a domain bridge and a gateway for web or network-based applications. The cloud bridge can be used to simplify internal interactions with the application. The gateway can be used to simplify external interactions with the SS.

[0217] In some cases, in this embodiment, the need for tokens can be eliminated because a local trust anchor can be relied upon to determine the identity of the requestor, however, in other cases, tokens can be maintained in this embodiment.

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

[0219] Reference is made to Figure 12. In the embodiment of Figure 12, the example permissions and domains from Figures 3 and 10 are used with similar numbers. However, this is provided merely for illustration purposes, and in other embodiments, different domains, SSs, applications, or connections are possible.

[0220] In the embodiment of 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 with the public key of the primary anchor 312. Additionally, the certificate or key store may be used to create or store a public / private key pair for the cloud anchor, referred to in the embodiment of Figure 12 as a "CA" for the public key and a "ca" for the private key.

[0221] 12, three applications are shown as cloud applications: application 1224, application 1226, and application 1228. However, the use of three applications is provided for illustration only and not limitation. Fewer or more than three applications may be present in practice.

[0222] Additionally, in the example of FIG. 12, a gateway 1212 is provided in the edge domain for applications to gain insight from the SS.

[0223] In the example of FIG. 12, application 1224 desires to gain insight from SS B 326 .

[0224] In this regard, an internal communication path within cloud domain 1210 exists between application 334 and domain anchor 332. Such a communication path is represented by connection 1222 and may be any internal process or communication path within the operating system of a computing device in cloud domain 1210. For example, 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 possible.

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

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

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

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

[0229] Utilizing the embodiment of Figure 12, an application may use a validation approach to gain insight. See Figure 13.

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

[0231] In other cases, the cloud domain 1210 is a network element that is always connected, so a local table may not be needed.

[0232] Additionally, edge anchor 322 may, in some embodiments, periodically update the local table with primary anchor 312 (not shown). For example, synchronization may occur when an Internet connection is established with the vehicle. In other cases, if the vehicle is out of cellular coverage for a period of time, then permissions may be synchronized when cellular coverage is restored. In other cases, permissions may be synchronized after a timer expires. In other cases, permissions may be synchronized at the first opportunity after a specific date and time has passed. Other options are possible.

[0233] In this manner, a local instance of the table 318 may be stored in the cloud domain 1210 and, in some cases, may also be stored in the vehicle.

[0234] When that application 1324 is installed on cloud domain 1210, the application requests to register with a cloud anchor / bridge 1220 installed in cloud domain 1210. Such a registration request is indicated by message 1330. In this case, message 1330 may involve the application requesting insight for the first time.

[0235] In some embodiments, the application 1324 may check the signature of the application package providing 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 the message 1330. It may then check the permissions within its local instance of table 318 (or it may check with the primary anchor, in some embodiments) to determine whether the application 1324 has permission to access insights from the synthetic sensor for which the request was made. In this way, the domain anchor / bridge may verify the identity of the application 1324 and verify that the 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 insight to the 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's identification and parameters are signed with the private key of the cloud domain 1210. Because the gateway and domain anchor / bridge are mutually authenticated, no token is required for such communication. In particular, in block 1342, an authorization status check may be performed in the gateway 1230, and based on the check, insight may be returned.

[0238] Specifically, the gateway 1230 may request insight from SS B 326, as shown in message 1350, and receive the insight back as message 1352. Because the gateway 1350 is known to SS B 326, no checking of message 1350 may be required.

[0239] The gateway 1230 may then return the insight in message 1360 to the domain anchor / bridge 1220 .

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

[0241] 13, the communication model between the application and the SS uses both a gateway and a bridge, where the bridge resides on a network or cloud element. The transport between the bridge and the gateway can use Transport Layer Security (TLS) because it crosses an operating system (OS) boundary.

[0242] 12 and 13, the authentication step involves installing a cloud anchor certificate during initial provisioning. The anchor can then synchronize with the primary anchor to obtain authorization. No tokens are required in this case.

[0243] The cloud anchor may then verify the application identity by ensuring that the invoking web / network application is a valid client application authorized to request insights about the vehicle.

[0244] The gateway and cloud bridge authenticate each other: an authorization status check is performed at the gateway and the response is provided appropriately.

[0245] (Disconnected mode)

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

[0247] In some cases, the OEM or its agents may assign configurations as follows: a.Valid until next reconnection; b. Valid until absolute time when unable to reconnect (this would typically need to be reset upon connection); c. If unable to reconnect, valid for a specified time since the last connection; or d. Effective for a specified number of refreshes when unable to reconnect.

[0248] Other options regarding the duration of validity for a configuration are also possible.

[0249] In the above, connectivity implies the ability to securely read changes from the cloud service, if applicable. When an entry or token in the sharing table is not valid based on the above configuration, access requests based thereon may be denied.

[0250] The above domains, network elements, cloud services, nodes, and other computing platforms may be implemented using any computing device. A simplified diagram of one of the computing devices is shown with reference to Figure 14. The computing device of Figure 14 may be any fixed or mobile computing device.

[0251] 14, the device 1410 includes a processor 1420 and a communication subsystem 1430, which cooperate to perform the methods of the embodiments described above. The communication subsystem 1430 enables the device 1410 to communicate with other devices or network elements and may vary based on the type of communication being performed. Furthermore, the communication subsystem 1430 may comprise multiple communication technologies, including any wired or wireless communication technology.

[0252] The processor 1420 is configured to execute programmable logic that may be stored with data on the device 1410 and illustrated in the example of Figure 14 as memory 1432. The memory 1432 may be any tangible, non-transitory computer-readable storage medium that stores instruction codes that, when executed by the processor 1420, cause the device 1410 to perform the methods of the present disclosure. The computer-readable storage medium may be a tangible or transitory / non-transitory medium, 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 communications subsystem 1430.

[0254] 14, one or more sensors 1440 may be associated with the computing device, however, that is optional and in some cases the computing device 1410 will not be associated with any sensors.

[0255] Communication between the various elements of device 1410 may, in one embodiment, be through an internal bus 1460. However, other forms of communication are possible.

[0256] The embodiments described herein are examples of structures, systems, or methods having elements that correspond to elements of the present technique. This written description may enable one skilled in the art to make and use embodiments having alternative elements that similarly correspond to elements of the present technique. The intended scope of the present technique therefore includes other structures, systems, or methods that do not differ from the present technique as described herein, and further includes other structures, systems, or methods with insubstantial differences from the present technique as described herein.

[0257] Although operations are depicted in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or in a sequential order, or that all of the illustrated operations be performed, to achieve desirable results. 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 program components and systems described may generally be integrated together in a single software product or packaged within multiple software products.

[0258] Furthermore, techniques, systems, subsystems, and methods described and illustrated in various implementations as separate or distinct may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as being coupled or directly coupled or in communication with each other may be indirectly coupled or communicate through some interface, device, or intermediate component, whether electrical, mechanical, or otherwise. Other examples of changes, substitutions, and alterations will be ascertainable and may be made by those skilled in the art.

[0259] While the foregoing detailed description illustrates, describes, and points out the basic novel features of the present disclosure as applied to various implementations, it should be understood that various omissions, substitutions, and changes in the form and details of the illustrated systems may be made by those skilled in the art. Additionally, the order of method steps is not implied by the order in which they appear in the claims.

[0260] When messages are sent to / from an electronic device, such operations may not be immediately adjacent to or directly from a server. They may be delivered synchronously or asynchronously from a server or other computing system infrastructure supporting the devices / methods / systems described herein. The foregoing steps may involve, in whole or in part, synchronous or asynchronous communication to / from the device / infrastructure. Furthermore, communications from the electronic device may be to one or more endpoints on a network. These endpoints may be serviced by a server, a distributed computing system, a stream processor, or the like. A content delivery network (CDN) may also provide communications to the electronic device. For example, rather than a typical server response, a server may also provision or indicate data for the content delivery network (CDN) to await later download by the electronic device, such as subsequent electronic device activity. Thus, data may be sent directly from a server or other infrastructure, such as a distributed infrastructure, or a CDN, as part of or separate from the system.

[0261] Typically, the storage medium may include any one or some 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, and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or another type of storage device. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed, potentially in a larger system having multiple nodes. Such computer-readable or machine-readable storage medium or media are considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The storage medium or media may be located either within a machine that executes the machine-readable instructions, or may be located at a remote location from which the machine-readable instructions can be downloaded over a network for execution.

[0262] In the foregoing description, numerous details are set forth 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 appended claims are intended to cover such modifications and variations.

Claims

1. 1. A method in a first domain for obtaining at least one insight from a second domain, the method comprising: synchronizing a permission table in the first domain with a master permission table in a network element, the permission table comprising permissions for at least one application, the permission table having an expiration time; receiving a request for insight from an application at a bridge in the first domain; verifying the identity of the application; verifying application permissions at the bridge using the permissions table and the identification of the application in the first domain, wherein the verifying confirms that the application has permission 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 the insight; receiving the insight from the second domain; and Including, The first domain and the second domain have a rule when the first domain and the second domain are not communicating with the network element and the permission table stored in the first domain expires; The rule is that the permission table: valid until the next reconnection with said network element; Valid until an absolute time when reconnection is not possible, If reconnection is not possible, it is valid for a specified time since the last connection with the network element; or Valid for a specified number of refreshes when unable to reconnect to said network element. A method for providing

2. The method of claim 1 , wherein a trust relationship exists between the bridge and the network element.

3. The method of claim 2 , wherein the trust relationship is established based on secure provisioning of the bridge.

4. 2. The method of claim 1, wherein sending the request message to the second domain includes sending the request message to a gateway associated with a synthetic sensor on the second domain, the synthetic sensor providing the insight.

5. The method of claim 1 , wherein the first domain and the second domain are in-vehicle domains.

6. The method of claim 5 , wherein the first domain is an in-vehicle infotainment system within the vehicle.

7. 1. A computing device having a first domain for obtaining at least one insight from a second domain, the computing device comprising: a processor; Communication subsystem and Equipped with the computing device, synchronizing a permission table in the first domain with a master permission table in a network element, the permission table comprising permissions for at least one application, the permission table having an expiration time; receiving a request for insight from an application at a bridge in the first domain; verifying the identity of the application; verifying application permissions at the bridge using the permissions table and the identification of the application in the first domain, wherein the verifying confirms that the application has permission 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 the insight; receiving the insight from the second domain; and and The first domain and the second domain have a rule when the first domain and the second domain are not communicating with the network element and the permission table stored in the first domain expires; The rule is that the permission table: valid until the next reconnection with said network element; Valid until an absolute time when reconnection is not possible, If reconnection is not possible, it is valid for a specified time since the last connection with the network element; or Valid for a specified number of refreshes when unable to reconnect to said network element. a computing device that provides

8. The computing device of claim 7 , wherein a trust relationship exists between the bridge and the network element.

9. The computing device of claim 8 , wherein the trust relationship is established based on secure provisioning of the bridge.

10. 8. The computing device of claim 7, wherein the computing device is configured to send the request message to the second domain by sending the request message to a gateway associated with a synthetic sensor on the second domain, the synthetic sensor providing the insight.

11. The computing device of claim 7 , wherein the first domain and the second domain are domains within a vehicle.

12. The computing device of claim 11 , wherein the first domain is an in-vehicle infotainment system within the vehicle.

13. 1. A non-transitory computer-readable medium for storing instruction code, the instruction code, when executed by a processor of a computing device having a first domain for obtaining at least one insight from a second domain, comprising: synchronizing a permission table in the first domain with a master permission table in a network element, the permission table comprising permissions for at least one application, the permission table having an expiration time; receiving a request for insight from an application at a bridge in the first domain; verifying the identity of the application; verifying application permissions at the bridge using the permissions table and the identification of the application in the first domain, wherein the verifying confirms that the application has permission 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 the insight; receiving the insight from the second domain; and causing the computing device to perform The first domain and the second domain have a rule when the first domain and the second domain are not communicating with the network element and the permission table stored in the first domain expires; The rule is that the permission table: valid until the next reconnection with said network element; Valid until an absolute time when reconnection is not possible, If reconnection is not possible, it is valid for a specified time since the last connection with the network element; or Valid for a specified number of refreshes when unable to reconnect to said network element.

1. A non-transitory computer-readable medium providing:

14. The non-transitory computer-readable medium of claim 13 , wherein a trust relationship exists between the bridge and the network element.

Images