Search

EP-4305835-B1 - METHOD AND SYSTEM FOR PERFORMING IDENTITY CHECKS IN A DISTRIBUTED SYSTEM

EP4305835B1EP 4305835 B1EP4305835 B1EP 4305835B1EP-4305835-B1

Inventors

  • MUKHERJEE, BISWAROOP
  • Wurster, Glenn Daniel

Dates

Publication Date
20260506
Application Date
20220311

Claims (15)

  1. A method performed by a remote proxy on a first node, wherein the remote proxy is provisioned with manifests for other nodes within a computer system that may communicate with the first node, and the manifests for the other nodes indicate types of services or hardware abstraction layers provided by said other nodes and include keys for secure communication with the other nodes; the method comprising: receiving a first message from a first module on the first node, the first message containing a user identifier of the first module and appearing local in terms of an Application Program Interface at the remote proxy, said first message being directed to a second module on a second node; - verifying the first message utilizing an operating system verification using the user identifier of the first module; - determining the second node, by performing a lookup for a service or hardware abstraction layer requested in the first message in the manifests at the remote proxy; - signing, using a private key for the first node, the first message; and - sending the signed first message to the second node.
  2. The method of claim 1, further comprising: receiving a second message, the second message being directed to the first module on the first node and being signed using a private key of the first module; verifying the second message using a public key for the second node found in the manifest; and after verifying the second message, forwarding said second message to the first module as a local message containing a group identifier or user identifier of the remote proxy and allowing for use of operating system verification for the remote proxy.
  3. The method of claim 2, wherein the verifying further comprises checking a source module for the second message against the manifest for the second node to ensure the source module is part of the second node.
  4. The method of claim 1, wherein: the first node and the second node use different operating systems.
  5. The method of claim 1, wherein the first message is further encrypted by the remote proxy using a public key for the second node found in the manifest prior to the sending of the first message.
  6. The method of claim 1, wherein the first node is a computing unit in the computer system, and wherein the first module is one of a hardware abstraction layer or a service for a sensor in the computer system.
  7. The method of claim 6, wherein the first node includes a plurality of hardware abstraction layers, a plurality of services, or a combination of at least one hardware abstraction layer and at least one service; and wherein a plurality of remote proxies exist on the first node, each of the plurality of remote proxies being associated with a subset of hardware abstraction layers and/or services.
  8. A first computing node within a computer system, the first computing node comprising: a processor; a communications subsystem, and a remote proxy provisioned with manifests for other nodes within the computer system that may communicate with the first computing node, the manifests for the other nodes indicating types of services or hardware abstraction layers provided by said other nodes and including keys for secure communication with the other nodes, wherein the remote proxy is configured to: receive a first message from a first module on the first computing node, the first message containing a user identifier of the first module and appearing local in terms of an Application Program Interface at the remote proxy, said first message being directed to a second module on a second computing node; verify the first message utilizing an operating system verification using the user identifier of the first module; determine the second computing node, by performing a lookup for a service or hardware abstraction layer requested in the first message in the manifests at the remote proxy; sign, using a private key for the first computing node, the first message; and send the first signed message to the second computing node.
  9. The first computing node of claim 8, wherein the remote proxy is further configured to: receive a second message, the second message being directed to the first module on the first computing node and being signed using a private key of the first module; verify the second message using a public key for the second computing node found in the manifest; and after verifying the second message, forward the second message to the first module as a local message containing a group identifier or user identifier of the remote proxy and allowing for use of an operating system verification for the remote proxy.
  10. The first computing node of claim 9, wherein the remote proxy is configured to verify by checking a source module for the second message against the manifest for the second computing node to ensure the source module is part of the second computing node.
  11. The first computing node of claim 8, wherein: the first computing node and the second computing node use different operating systems.
  12. The first computing node of claim 8, wherein the first message is further encrypted by the remote proxy using a public key for the second computing node found in the manifest prior to the sending of the first message.
  13. The first computing node of claim 8, wherein the first module is one of a hardware abstraction layer or a service for a sensor in the computer system.
  14. The first computing node of claim 13, wherein the first computing node includes a plurality of hardware abstraction layers, a plurality of services, or a combination of at least one hardware abstraction layer and at least one service; and wherein a plurality of remote proxies exist on the first computing node, each of the plurality of remote proxies being associated with a subset of hardware abstraction layers and/or services.
  15. A computer readable medium for storing instruction code which, when executed by a processor of a remote proxy on a first computing node within a computer system cause the remote proxy to: receive a first message from a first module on the first computing node, the first message containing a user identifier of the first module and appearing local in terms of an Application Program Interface at the remote proxy, said first message, said first message being directed to a second module on a second computing node, wherein the remote proxy is provisioned with manifests for other nodes within the computer system that may communicate with the first node, and the manifests for the other nodes indicate types of services or hardware abstraction layers provided by said other nodes and include keys for secure communication with these other nodes; - verify the first message utilizing an operating system verification using the user identifier of the first module; - determine the second computing node, by performing a lookup for a service or hardware abstraction layer requested in the first message in the manifests at the remote proxy; sign, using a private key for the first computing node, the first message; and send the first signed message to the second computing node.

Description

FIELD OF THE DISCLOSURE The present disclosure relates to distributed systems, and in particular relates to communications security in a distributed system. BACKGROUND Modern vehicles have many sensors. However, such sensors may be distributed within the various computing nodes on the vehicle, where each computing node may have access to zero, one or more sensor drivers. Such sensor nodes may further have different manufacturers, and operate using different operating systems. Similarly, other distributed systems could have a plurality of nodes where the nodes need to communicate with each other. Determining an identity of interacting software entities is an important underpinning for the security of a software system. For example, a request for some data or action may or may not be granted, depending on the identity of the software module that made to the request. In modern, large, software systems, modules interact with each other by making requests as above. As such, it is vital to determine the identity of the requester in a secure, but efficient, manner. US 2014/195808 A1 discloses a system that includes a host processor and a bus controller firmware. The firmware receives an unfiltered message from the processor to be sent to a vehicle ECU through a bus. The firmware filters the message based on filtering rules it stores in a database. Based on the rules, unauthorised and/or potentially malicious messages are not sent to the bus. The firmware has a signing key to verify new rules received. US 2018/004964 A1 discloses a proxy interface input that receives a message and forwards it to a rule selector that selects a rule suitable for the message. Based on the rule, the message is sent to a proxy interface output. BRIEF DESCRIPTION OF THE DRAWINGS The present disclosure will be better understood with reference to the drawings, in which: Figure 1 is a block diagram showing an example computing node within a computer system.Figure 2 is a block diagram showing two computer nodes which each use a remote proxy to present blocks on other nodes as local to modules within their respective nodes.Figure 3 is a dataflow diagram showing messages being sent between one module and a second module.Figure 4 is a block diagram showing two computer nodes which use remote proxies on each module within the node to present blocks on other nodes as local such module.Figure 5 is a block diagram of a simplified computing device capable of being used with the embodiments of the present disclosure. DETAILED DESCRIPTION OF THE DRAWINGS The present invention is defined in the independent claims. Preferred embodiments are defined in the dependent claims. The present disclosure provides a method at a remote proxy on a first node, the method comprising: receiving, at the remote proxy, a first message from a first module on the first node, the first message being directed to a second module on a second node; verifying the first message at the remote proxy utilizing operating system verification; determining, based on a manifest at the remote proxy, the second node; signing, using a private key for the first node, the first message; and sending the first message to the second node. The present disclosure further provides a first computing node within a computer system, the first computing node comprising: a processor; and a communications subsystem, wherein the first computing node is configured to: receive, at a remote proxy on the first computing node, a first message from a first module on the first computing node, the first message being directed to a second module on a second computing node; verify the first message at the remote proxy utilizing operating system verification; determine, based on a manifest at the remote proxy, the second computing node; sign, using a private key for the first computing node, the first message; and send the first message to the second computing node. The present disclosure further provides a computer readable medium for storing instruction code which, when executed by a processor of a first computing node within a computer system cause the first computing node to: receive, at a remote proxy on the first computing node, a first message from a first module on the first computing node, the first message being directed to a second module on a second computing node; verify the first message at the remote proxy utilizing operating system verification; determine, based on a manifest at the remote proxy, the second computing node; sign, using a private key for the first computing node, the first message; and send the first message to the second computing node. It is important in a software system to determine the identity of the requester in a secure but efficient manner. Modern operating systems (OSs) have mechanisms to identify software components to enforce security policies. For example, most desktop operating systems have a way to identify the user on whose behalf the program is running, so that one user