A communication method, apparatus, system, and mobile carrier

Abstract

This application provides a communication method, apparatus, system, and mobile carrier. The method may include: receiving a first request message from a first node, the first request message including a requested node type and a first digital identity of the first node; determining a first digital identity container associated with the first digital identity based on the first digital identity, the first digital identity container storing attribute information of the first node; determining at least one candidate node corresponding to the requested node type based on the first digital identity container; and sending a first feedback message to the first node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the digital identity list including a second digital identity corresponding to a second node to which the first node wishes to connect. This reduces the complexity of vehicle communication and thus improves the security of vehicle communication.

Description

Technical Field

[0001] This application relates to the field of security, and more specifically, to a communication method, apparatus, system, and mobile carrier. Background Technology

[0002] With the development of intelligent technology, the security of in-vehicle and external vehicle communication has received increasing attention. Vehicles comprise numerous hardware and software components that work together to ensure their proper functioning. Hardware components may include, for example, gateways, mobile data centers (MDCs), cockpit domain controllers (CDCs), vehicle integration units (VIUs), resource-constrained electronic control units (ECUs), sensors, and actuators. Software components may include, for example, services, applications, and processes within each application.

[0003] Currently, at the hardware level, different hardware may come from different manufacturers, and the interoperability between hardware from different manufacturers is poor. This is not conducive to tracing the source node of the attack in a network attack incident. In addition, it also increases the complexity of access control, permission management and identity authentication steps for some hardware devices.

[0004] At the software level, the communication methods between services, applications, or processes on different devices are often related to the device's hierarchical level. For example, complex devices often communicate via high-speed data transmission systems, such as Ethernet or Controller Area Network Flexible Data (CAN-FD). Simpler devices transmit smaller data packets, which can be adequately handled via a CAN bus. This undoubtedly increases the complexity of tasks mentioned above at the hardware level, such as network attack tracing, access control, permission management, and authentication.

[0005] Therefore, how to reduce the complexity of vehicle communication and improve its security is an urgent problem to be solved. Summary of the Invention

[0006] This application provides a communication method, apparatus, system, and mobile carrier that can reduce the complexity of vehicle communication and thereby improve the security of vehicle communication.

[0007] Firstly, a communication method is provided for an identity management node. The method includes: receiving a first request message from a first node, the first request message including a requested node type and a first digital identity of the first node; determining a first digital identity container associated with the first digital identity based on the first digital identity, the first digital identity container storing attribute information of the first node; determining at least one candidate node corresponding to the requested node type based on the first digital identity container; and sending a first feedback message to the first node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the digital identity list including a second digital identity corresponding to a second node to which the first node wishes to connect.

[0008] In the above technical solution, the first node can request the second node to be connected from the identity management node using only its first digital identity information, thereby facilitating communication between the first and second nodes. This method is applicable to any entity in the automotive ecosystem, unrestricted by different hardware manufacturers, simplifying the connection process between different nodes without requiring the combination of multiple methods for different entities.

[0009] In conjunction with the first aspect, in certain implementations of the first aspect, determining at least one candidate node corresponding to the requested node type based on the first digital identity container includes: verifying whether the first node is allowed to request the node type based on the permission field in the first digital identity container. If the first node is allowed to request the node type, at least one candidate node is determined.

[0010] In the above technical solution, the permission field in the first digital identity container is used to verify the request permission of the first node, which can ensure the security of vehicle communication.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the first feedback message also includes detailed information about each candidate node, which is used to instruct the first node to determine the second node from at least one candidate node.

[0012] In the above technical solution, detailed information can help the first node quickly determine the second node to be connected from at least one candidate node.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, before receiving the first request message, the method further includes: receiving a first registration request from a first node, the first registration request including first attribute information of the first node, the first attribute information indicating the attributes of the first node; generating a first digital identity and a first digital identity container based on the first attribute information; saving the first digital identity container; and sending the first digital identity to the first node.

[0014] In the above technical solution, the security of vehicle communication can be guaranteed by determining the first digital identity and the first digital identity container through a registration request.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, when the requested node type comes from a third node, the first request message also includes the third digital identity and token of the third node, and the first node is a proxy node of the third node.

[0016] It should be understood that the third node can be a resource-constrained device.

[0017] In the above technical solution, the third node authorizes the first node as a proxy node to obtain a list of digital identities of candidate nodes corresponding to the requested node type. This can make full use of the resources of the first node and reduce the complexity of communication between the third node and the second node.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, before receiving the first request message, the method further includes: receiving a second registration request from the first node, the second registration request including third attribute information of the third node and a first digital identity, the third attribute information indicating the attributes of the third node; verifying, based on the first digital identity, whether the node type for which the first node is allowed to request the request is valid; after successful verification, generating a third digital identity, a token, and a third digital identity container for the third node based on the third attribute information; saving the third digital identity container; and sending the third digital identity and token to the first node.

[0019] In the above technical solution, the security of vehicle communication can be guaranteed by determining the third digital identity and third digital identity container of the third node through a registration request.

[0020] In conjunction with the first aspect, in some implementations of the first aspect, the identity management node is used for the identity management of the vehicle entity, the identity management node is located on a cloud server, or the identity management node is located on at least one entity of the vehicle.

[0021] In the above technical solutions, when the identity management node is located on a single entity within the vehicle, this centralized architecture can save resource consumption. When the identity management node is located on multiple entities within the vehicle, it can avoid security risks caused by single points of failure and improve the reliability of vehicle communication. When the identity management node is located on a cloud server, it can save vehicle-side resources.

[0022] Secondly, a communication method is provided for a first node. This method may include sending a first request message to an identity management node, the first request message including a requested node type and a first digital identity of the first node. The method also includes receiving a first feedback message from the identity management node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the at least one candidate node being determined based on a first digital identity container associated with the first digital identity and the requested node type, wherein the first digital identity container stores attribute information of the first node. Finally, the method includes selecting a second digital identity of a second node to be connected from the list of digital identities.

[0023] It should be understood that the technical effects involved in the second aspect can be referenced from the first aspect, and will not be elaborated here.

[0024] In conjunction with the second aspect, in some implementations of the second aspect, the first feedback message also includes detailed information about each candidate node. Selecting the second digital identity of the second node to be connected from the list of digital identities includes: determining the second node from at least one candidate node based on the detailed information, and determining the second digital identity from the list of digital identities.

[0025] In conjunction with the second aspect, in some implementations of the second aspect, before sending the first request message to the identity management node, the method further includes: sending a first registration request to the identity management node, the first registration request including first attribute information of the first node, the first attribute information indicating the attributes of the first node, and the first registration request requesting the first digital identity of the first node. The method also includes receiving the first digital identity from the identity management node.

[0026] In conjunction with the second aspect, in some implementations of the second aspect, before sending the first request message to the identity management node, the method further includes: receiving an authorization message from a third node, the authorization message being used to authorize the first node as a proxy node of the third node; receiving a second request message from the third node, the second request message including the requested node type and the third digital identity and token of the third node, the first request message also including the third digital identity and token.

[0027] In conjunction with the second aspect, in some implementations of the second aspect, before receiving the second request message from the third node, the method further includes: receiving a third registration request from the third node, the third registration request including third attribute information of the third node, the third attribute information indicating the attributes of the third node, and the third registration request being used to request a third digital identity and token; sending a second registration request to the identity management node, the second registration request including the third attribute information of the third node and a first digital identity, the second registration request being used to request a third digital identity and token; and receiving the third digital identity and token from the identity management node.

[0028] In conjunction with the second aspect, in some implementations of the second aspect, the first node is an entity related to the vehicle.

[0029] Thirdly, an identity management node is provided, comprising a transceiver unit and a processing unit. The transceiver unit is configured to receive a first request message from a first node, the first request message including a requested node type and a first digital identity of the first node. The processing unit is configured to determine, based on the first digital identity, a first digital identity container associated with the first digital identity, the first digital identity container storing attribute information of the first node. The processing unit is further configured to determine, based on the first digital identity container, at least one candidate node corresponding to the requested node type. The transceiver unit is further configured to send a first feedback message to the first node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the digital identity list including a second digital identity corresponding to a second node to which the first node wishes to connect.

[0030] It should be understood that the third aspect refers to the device corresponding to the communication method of the first aspect, and the technical effects of the solution involved in the third aspect can be referred to the first aspect, which will not be elaborated here.

[0031] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is specifically used to: verify whether the first node is allowed to request a node type based on the permission field in the first digital identity container; and determine at least one candidate node if the first node is allowed to request a node type.

[0032] In conjunction with the third aspect, in some implementations of the third aspect, the first feedback message also includes detailed information about each candidate node, which is used to instruct the first node to determine the second node from at least one candidate node.

[0033] In conjunction with the third aspect, in some implementations of the third aspect, before receiving the first request message, the transceiver unit is further configured to receive a first registration request from the first node, the first registration request including first attribute information of the first node, the first attribute information indicating the attributes of the first node. The processing unit is further configured to: generate a first digital identity and a first digital identity container based on the first attribute information; and save the first digital identity container. The transceiver unit is further configured to send the first digital identity to the first node.

[0034] In conjunction with the third aspect, in some implementations of the third aspect, when the requested node type comes from a third node, the first request message also includes the third digital identity and token of the third node, and the first node is a proxy node of the third node.

[0035] In conjunction with the third aspect, in some implementations of the third aspect, before receiving the first request message, the transceiver unit is further configured to receive a second registration request from the first node. The second registration request includes the third attribute information of the third node and the first digital identity. The third attribute information is used to indicate the attributes of the third node. The processing unit is further configured to: verify, based on the first digital identity, whether the node type for which the first node is allowed to request the request is valid. After successful verification, based on the third attribute information, generate the third digital identity, token, and third digital identity container for the third node; and save the third digital identity container. The transceiver unit is further configured to send the third digital identity and token to the first node.

[0036] In conjunction with the third aspect, in some implementations of the third aspect, the identity management node is used for the identity management of vehicle entities, the identity management node is located on a cloud server, or the identity management node is located on at least one entity of the vehicle.

[0037] Fourthly, a first node is provided, comprising a transceiver unit and a processing unit: the transceiver unit is configured to send a first request message to an identity management node, the first request message including a requested node type and a first digital identity of the first node. The transceiver unit is configured to receive a first feedback message from the identity management node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the at least one candidate node being determined based on a first digital identity container associated with the first digital identity and the requested node type, wherein the first digital identity container stores attribute information of the first node. The processing unit is configured to select a second digital identity of a second node to be connected from the list of digital identities.

[0038] It should be understood that the fourth aspect refers to the device corresponding to the communication method of the second aspect. The technical effects of the scheme involved in the fourth aspect can be referred to the second aspect, and will not be elaborated here.

[0039] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first feedback message also includes detailed information about each candidate node, and the processing unit is specifically used to: determine a second node from at least one candidate node based on the detailed information, and determine a second digital identity from the list of digital identities.

[0040] In conjunction with the fourth aspect, in some implementations of the fourth aspect, before sending the first request message to the identity management node, the transceiver unit is further configured to: send a first registration request to the identity management node, the first registration request including first attribute information of the first node, the first attribute information being used to indicate the attributes of the first node, the first registration request being used to request the first digital identity of the first node; and receive the first digital identity from the identity management node.

[0041] In conjunction with the fourth aspect, in some implementations of the fourth aspect, before sending the first request message to the identity management node, the transceiver unit is further configured to: receive an authorization message from the third node, the authorization message being used to authorize the first node as a proxy node of the third node; receive a second request message from the third node, the second request message including the requested node type and the third digital identity and token of the third node, the first request message also including the third digital identity and token.

[0042] In conjunction with the fourth aspect, in some implementations of the fourth aspect, before receiving the second request message from the third node, the transceiver unit is further configured to: receive a third registration request from the third node, the third registration request including third attribute information of the third node, the third attribute information being used to indicate the attributes of the third node, and the third registration request being used to request a third digital identity and token; send a second registration request to the identity management node, the second registration request including the third attribute information of the third node and a first digital identity, the second registration request being used to request a third digital identity and token; and receive the third digital identity and token from the identity management node.

[0043] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first node is an entity related to the vehicle.

[0044] Fifthly, a communication device is provided, comprising: a memory for storing a program; and a processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to execute the method in any possible implementation of the first or second aspect described above.

[0045] Sixthly, a communication system is provided, comprising an identity management node in any possible implementation of the third aspect above, and a first node in any possible implementation of the fourth aspect above.

[0046] In a seventh aspect, a mobile carrier is provided, the vehicle including a first node in any possible implementation of the fourth aspect, and / or an identity management node in any possible implementation of the third aspect, and / or a communication device in the fifth aspect.

[0047] It should be understood that the mobile carrier in this application can include road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, the mobile carrier can be a vehicle, which is a vehicle in a broad sense, and can be a means of transportation (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawnmowers, harvesters, etc.), amusement equipment, toy vehicles, etc. The embodiments of this application do not specifically limit the type of vehicle. As another example, the mobile carrier can be a means of transportation such as an airplane or a ship.

[0048] In conjunction with the seventh aspect, in one possible implementation, the mobile carrier is a vehicle.

[0049] Eighthly, a computer program product is provided, comprising: computer program code, which, when executed on a computer, causes the computer to perform the method in any possible implementation of the first or second aspect.

[0050] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or packaged separately from the processor. This application embodiment does not specifically limit this.

[0051] Ninthly, a computer-readable medium is provided that stores program code, which, when executed on a computer, causes the computer to perform the method in any possible implementation of the first or second aspect.

[0052] In a tenth aspect, a chip is provided, the chip including a processor for calling a computer program or computer instructions stored in a memory, such that the processor performs the method in any possible implementation of the first or second aspect described above.

[0053] In conjunction with the tenth aspect, in one possible implementation, the processor is coupled to the memory via an interface.

[0054] In conjunction with the tenth aspect, in one possible implementation, the chip system further includes a memory in which computer programs or computer instructions are stored. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of an in-vehicle equipment type provided in an embodiment of this application;

[0056] Figure 2 This is a schematic diagram of the interaction flow of a communication method provided in an embodiment of this application;

[0057] Figure 3 This is a schematic diagram of a digital identity container provided in an embodiment of this application;

[0058] Figure 4 This is a schematic diagram of the interactive flow of a digital identity generation process provided in an embodiment of this application;

[0059] Figure 5 This is a schematic diagram of a digital identity generation process for a hardware component provided in an embodiment of this application;

[0060] Figure 6 This is a schematic diagram of the digital identity generation process of another hardware component provided in an embodiment of this application;

[0061] Figure 7 This is a schematic diagram of a digital identity generation process for another hardware component provided in an embodiment of this application;

[0062] Figure 8 This is a schematic diagram of a digital identity generation process for a software component provided in an embodiment of this application;

[0063] Figure 9 This is a schematic diagram of the digital identity generation process of another software component provided in an embodiment of this application;

[0064] Figure 10 This is a schematic diagram of the communication process between services of a vehicle resource-rich device provided in an embodiment of this application;

[0065] Figure 11 This is a schematic diagram of the communication process between a vehicle resource-rich device and a resource-constrained device, provided in an embodiment of this application.

[0066] Figure 12 This is a communication flowchart between in-vehicle devices and external devices provided in an embodiment of this application;

[0067] Figure 13 This is a schematic block diagram of a communication device 1300 provided in an embodiment of this application;

[0068] Figure 14 This is a schematic block diagram of a communication device 1400 provided in an embodiment of this application. Detailed Implementation

[0069] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0070] To facilitate understanding of the embodiments of this application, the following points are made:

[0071] First, in this application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0072] Second, in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can mean: a, or, b, or, c, or, a and b, or, a and c, or, b and c, or, a, b, and c. Here, a, b, and c can be single or multiple.

[0073] Third, in this application, "first" and "second" indicate distinctions made for ease of description and are not intended to limit the scope of the embodiments of this application. For example, they distinguish different nodes, rather than describing a specific order or sequence. It should be understood that such described objects can be interchanged where appropriate to describe solutions other than those in the embodiments of this application.

[0074] Fourth, in this application, descriptions such as "when," "under the circumstances," and "if" all refer to the device making corresponding processing under certain objective circumstances, and are not time-limited, nor do they require the device to make a judgment action when implementing it, nor do they imply any other limitations.

[0075] Fifth, in this application, the terms “comprising” and “having” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0076] Sixth, in this application, "for indicating" can include both direct and indirect indication. When describing an indication information as indicating A, it can include whether the indication information directly indicates A or indirectly indicates A, but does not necessarily mean that the indication information carries A.

[0077] The indication methods involved in the embodiments of this application should be understood to cover various methods that enable the party to be indicated to obtain the information to be indicated. The information to be indicated can be sent as a whole or divided into multiple sub-information and sent separately. Moreover, the sending period and / or sending time of these sub-information can be the same or different. This application does not limit the specific sending method.

[0078] The "instruction information" in the embodiments of this application can be an explicit instruction, that is, a direct instruction through signaling, or an instruction obtained by combining other rules or parameters with the parameters indicated by the signaling, or by deduction. It can also be an implicit instruction, that is, an instruction obtained based on rules or relationships, or based on other parameters, or by deduction. This application does not specifically limit it in this regard.

[0079] Seventh, in this application, "storage" can refer to storage in one or more memories. The one or more memories can be separate installations or integrated into an encoder or decoder, processor, or communication device. Alternatively, some memories can be separate installations, while others can be integrated into a decoder, processor, or communication device. The type of memory can be any form of storage medium, and this application is not limited to this.

[0080] Eighth, in this application, "communication" can also be described as "data transmission", "information transmission", "data processing", etc. "Transmission" includes "sending" and "receiving".

[0081] The following is a brief explanation of the relevant categories involved in this application.

[0082] 1. Digital Identity

[0083] Digital identity is an information entity about an individual, organization, or electronic device online. Digital identity, especially self-sovereign identity (SSI), is key to realizing Web 3.0 because it involves the decentralization of data privacy. As the name suggests, Web 3.0 is the third version of the internet. In Web 2.0, a few tech giants controlled the majority of the data space, resulting in overly centralized user data privacy. In Web 3.0, data owners can manage their own data, and digital identity is a way of identifying information that keeps it within the user's control, eliminating the need to store personal information entirely in a central database.

[0084] Figure 1 This is a schematic diagram of an in-vehicle equipment type provided in an embodiment of this application.

[0085] Figure 1(a) illustrates different types of devices in a vehicle, and the hardware components in the vehicle may include a first type of device 110, a second type of device 120, and a third type of device 130.

[0086] The first type of device 110 can be understood as a complex ECU. That is, the first type of device 110 includes more resources, memory, and an operating system, and it can use sophisticated security methods and has secure storage, such as a trusted execution environment (TEE), a trusted platform module (TPM), and a hardware security module (HSM). Furthermore, the first type of device 110 communicates via high-speed data transmission, such as Ethernet or CAN FD.

[0087] For example, such as Figure 1 As shown in (a), the first type of device 110 may be a telematics box (T-BOX), VIU, vehicle controller unit (VCU), MDC, or vehicle dynamic controller (VDC), etc.

[0088] The second type of device 120 can be understood as a medium-complex ECU. That is, the second type of device 120 is not as complex as the first type of device 110, but it also communicates through high-speed data transmission, for example, through CAN FD.

[0089] For example, such as Figure 1 As shown in (a), the second type of device 120 can be an ECU, a domain controller (DC), or a sub-domain controller (SDC). The domain controller, for example, can be a CDC.

[0090] It should be understood that the first type of device 110 and the second type of device 120 communicate via high-speed data transmission, such as CAN FD.

[0091] Type 3 device 130 can be understood as a resource-constrained device, meaning it has limited memory, generally no secure storage space, and communicates via small data transfer methods. For example, the small data transfer method could be CAN bus communication, or other buses such as a local interconnect network (LIN). It should be understood that Type 3 device 130 generally lacks secure storage space, but the possibility of Type 3 devices resembling electronic wallets cannot be ruled out.

[0092] For example, such as Figure 1 As shown in (a), the third type of device 130 may be a resource-constrained ECU, sensor or actuator, etc.

[0093] It should be understood that the first type of device 110 and the third type of device 130 communicate via small data transmission methods, such as the CAN bus.

[0094] Figure 1 (b) illustrates the communication relationships between different devices in vehicle communication. The first type of devices 110 can transmit data via Ethernet or CAN FD. The T-BOX can communicate with external devices via fourth-generation (4G) or fifth-generation (5G) mobile communication. Of course, the T-BOX can also communicate with external devices via future mobile communication and other communication methods.

[0095] like Figure 1 As shown in (b), the in-vehicle power devices such as the subdomain controller SDC, ECU1, and ECU2 communicate with the VIU via Ethernet or CAN FD. Here, the in-vehicle power devices can be understood as... Figure 1 The second type of device 120 shown in (a). For example, the VIU here could be a gateway ECU.

[0096] like Figure 1 As shown in (b), in-vehicle low-voltage devices such as actuators, sensors, and micro control units (MCUs) are connected to the VIU via low-bandwidth communication methods such as CAN or LIN. Here, in-vehicle low-voltage devices can be understood as... Figure 1 The third type of device 130 shown in (a) may be a type of resource-constrained ECU in the third type of device 130.

[0097] like Figure 1As shown in (b), external devices such as wireless fidelity (Wi-Fi) devices, Bluetooth devices, cloud devices, or universal serial bus (USB) devices can connect to the CDC via wired or wireless communication.

[0098] It should be understood that Figure 1 (a) and Figure 1 The various hardware components shown in (b) are merely an example. In actual applications, the above devices may be added or removed as needed. For example, there may be different numbers of devices with different names, or they may be interconnected in different vehicles with different topologies.

[0099] Currently, vehicle hardware components are manufactured by different manufacturers, each using proprietary methods, and interoperability between devices from different manufacturers is problematic. Therefore, tracing the source of attacks presents challenges when facing cyberattacks. For example, when hardware A from manufacturer A is attacked, because different hardware is currently produced by different manufacturers, it is difficult to identify the root cause of the attack (i.e., the point of attack or failure) in in-vehicle network communication. This makes it difficult to isolate hardware A from other physical hardware to prevent further damage from broadcast attacks. This further reduces the security of in-vehicle communication.

[0100] In addition, hardware components from different manufacturers, when facing processes such as access control, access management, and authentication, require different mechanisms or combinations of methods from different devices based on their respective hardware attributes to complete these steps. For example, for complex hardware (e.g., Figure 1 The first type of device 110 shown in (a) and resource-constrained hardware (e.g., Figure 1 Access control, access management, and authentication between the third type of devices 130 shown in (a) will complicate the communication process between different types of hardware components.

[0101] Different types of devices in a vehicle have different types of software components; for example, different devices provide different types of services. Specific software components can be services, applications, or processes within applications. Services corresponding to complex devices communicate via high-speed data transmission methods (e.g., Ethernet or CAN FD), transmitting large data packets and using more secure communication methods. For example, Figure 1The first type of device 110 and the second type of device 120 are shown in (a). However, the service corresponding to the simple device is a simple service operating at the signal level, specifically communicating through low-bandwidth data transmission and transmitting small data packets (i.e., data size is limited). Because the communication characteristics of the services corresponding to different types of devices are quite different, the ability to trace the attack point is poor when facing network attacks. Or there are problems such as complex access control, permission management, and identity authentication processes.

[0102] Currently, in-vehicle identity and access management (IAM) can be implemented using scalable service-oriented middleware over IP (SOME / IP) protocols, or SOME / IP and IAM modules within an adaptive platform based on the automotive open system architecture (AUTOSAR). However, these are only for service-level communication and cannot be applied to device-level communication.

[0103] The SOME / IP and IAM modules in the AUTOSAR adaptive platform mainly include the following: The SOME / IP protocol defines Service ID, Method ID, Routine ID, and Message ID. The Service ID is a number used to identify the service type, the Method ID is a number used to identify the method, the Routine ID is a number used to indicate the routine running the service, and the Message ID includes both the Service ID and the Method ID. Distributed IAM for services includes IAM in the local device and IAM in the remote device. During access control, the IAM modules in the local device and the remote device need to work together.

[0104] In the AUTOSAR adaptive platform, the SOME / IP and IAM modules store the "roles and permissions" information required for access control, access management, and identity verification in a manifest file. The manifest file includes a wealth of information about the entire system, such as service IDs and access control information, including permitted services. Currently, there is no defined method for sharing the manifest with other devices; the system designer chooses an appropriate method.

[0105] To address the aforementioned problems, embodiments of this application provide a communication method, apparatus, system, and mobile carrier, which will be described below in conjunction with... Figures 2 to 14 Detailed explanation.

[0106] Figure 2This is a schematic diagram of the interaction process of a communication method provided in an embodiment of this application.

[0107] It should be understood that Figure 2 The first node shown can be a vehicle, a manufacturer, or a hardware component within the vehicle (e.g., Figure 1 The identity management node can be any entity in the automotive ecosystem, such as the different types of devices shown in (a) or software components (e.g., services, applications, or processes within applications) in the vehicle. The identity management node can reside in the vehicle's hardware entity, or it can be in the Identity and Access Management (IAM) module on a cloud server, or it can be in the cloud-based identity and access management (CIAM) module on a server.

[0108] It should also be understood that Figure 2 The illustrated interaction diagram uses the first node and the identity management node as examples to illustrate the corresponding methods, but this application does not limit the execution entities of the interaction diagram. The first node can be a chip, chip system, or processor that supports the implementation of the corresponding methods, such as a vehicle hardware component with a corresponding chip, chip system, or processor. It can also be a logical module or software that implements all or part of the functions of the first node, such as a vehicle software component. The identity management node can also be a chip, chip system, or processor that supports the implementation of the corresponding methods, such as a chip, chip system, or processor in a vehicle hardware component or a cloud server. It can also be a logical module or software that can implement all or part of the functions of the node, such as an IAM module in a vehicle hardware component (e.g., identity and access management service (IAMS)) or a cloud-based identity and access management (CIAM) module in a cloud server.

[0109] S210, the first node sends a first request message to the identity management node, and the identity management node receives the first request message from the first node. The first request message includes the requested node type and the first digital identity of the first node.

[0110] It should be understood that the first digital identity is used to indicate the identity information of the first node. The first digital identity is a pointer to a first digital identity container stored in a database or memory. The first digital identity container is a structure, which can be an embedded structure with pointers to additional resources. Further details will follow. Figures 4 to 9 The process of generating the first digital identity and the first digital identity container is explained in detail.

[0111] It should also be understood that the first digital identity can be an integer, a string, or a combination of numbers and strings. An integer-type first digital identity can be for a service or ECU at the first node, while a string-type first digital identity has a maximum size of N bytes, where N is configurable.

[0112] As one possible implementation, the node type can be the node type directly requested by the first node.

[0113] In this case, the first node is the direct requester of the requested node type. For example, the first node could be... Figure 1 The first type of device 110 or the second type of device 120 in the vehicle shown in (a), or the software components on these devices.

[0114] As one possible implementation, the node type could also be a third node indirectly requesting the identity management node through the first node. The third node could be a third type of device 130, such as a resource-constrained ECU. Figure 1 The MCU shown in (b).

[0115] At this point, the third node will grant the first node the ability to send the first request message in advance. That is, the first node receives the authorization message from the third node, which authorizes the first node to act as the third node's proxy node.

[0116] S220, the identity management node determines the first digital identity container associated with the first digital identity based on the first digital identity. The first digital identity container stores the attribute information of the first node.

[0117] It should be understood that the first digital identity container can also be called the first digital identity file. The following will combine... Figure 3 This section details the pattern of the digital identity container, that is, the architecture of the digital identity container.

[0118] Figure 3 This is a schematic diagram of a digital identity container provided in an embodiment of this application.

[0119] Figure 3 The illustrated digital identity container pattern is applicable to the entire vehicle, hardware components within the vehicle, or software components within the vehicle, and even to vehicle owners or hardware component manufacturers. This pattern can also be extended to any entity in the future automotive ecosystem. While the architecture of the digital identity containers for different entities can be similar, the specific content within each entity's corresponding digital identity container will differ.

[0120] A digital identity is a pointer to a structure that points to a corresponding database or memory. In the automotive ecosystem, a digital identity can be a pointer to a structure that points to a centralized vehicle database or memory, or it can be a pointer to a structure that points to a distributed vehicle database / memory. The structure mentioned in this paragraph can be an embedded structure with pointers to additional resources.

[0121] like Figure 3 As shown, a digital identity container includes general fields, which may include identity information, authentication methods, identification methods or services, and service endpoints. The identity information changes depending on the entity the digital identity container targets. For example, if the entity corresponding to the digital identity container is a hardware component, such as a device, then the identity information is the device identity, or device ID. Similarly, if the entity corresponding to the digital identity container is a software component, such as a service, then the identity information is the service identity, or service ID. Furthermore, if the entity corresponding to the digital identity container is a manufacturer, or producer, then the identity information is the manufacturer identity, or manufacturer ID.

[0122] The digital identity container may also include a first additional field, which may include entity type, key type, and identity recognition type. The first additional field is used to distinguish different entities. The entity type may be an ECU, service, vehicle, user, or manufacturer, etc.

[0123] The digital identity container may also include a second additional field, which may include an encryption key and a verifiable certificate. This second additional field is used for identity authentication or encrypted information authentication. Verifiable certificates cannot be publicly placed in the digital identity container; however, they can be stored on the device and displayed in other suitable forms upon request. These suitable forms can be encrypted or other confidential forms derived from a private certificate. In other words, the verifiable certificate is stored confidentially in the digital identity container. Alternatively, the verifiable certificate can also be a signed version of a private certificate. That is, the digital identity container only stores publicly available verifiable certificates. Private data (e.g., verifiable certificates) is only transmitted through a secure channel. This facilitates the realization of self-sovereign identity (SSI).

[0124] The digital identity container may also include a third additional field, which may include a role / permission field. The third additional field is used to verify the permissions of the entity corresponding to the digital identity.

[0125] The digital identity container may also include a fourth additional field, which may include a signature. The digital identity container may also include other fields, and this embodiment of the application does not limit this.

[0126] S230, the identity management node determines at least one candidate node corresponding to the requested node type based on the first digital identity container.

[0127] Specifically, based on the role / permission field in the first digital identity container, it is verified whether the first node is allowed to request the node type. If the first node is allowed to request the node type, at least one candidate node is determined, and the type of the candidate node matches the type of the requested node.

[0128] S240, the identity management node sends a first feedback message to the first node, and the first node receives the first feedback message from the identity management node. The first feedback message includes a list of digital identities for at least one candidate node.

[0129] Optionally, the first feedback message may also include detailed information about each candidate node pair, which instructs the first node to select the second node to connect from at least one candidate node.

[0130] For example, detailed information may include the node type of the candidate nodes, such as the service type, which helps the first node quickly and accurately select the second node to connect to from the candidate nodes.

[0131] S250, the first node selects the second digital identity of the second node to be connected from the digital candidate list.

[0132] As one possible implementation, the first node randomly selects the second digital identity of the second node to be connected from a list of digital candidates.

[0133] Optionally, if the first feedback message may also include detailed information about each candidate node pair, the first node checks the detailed information about each candidate node, determines the second node from at least one candidate node, and determines the second digital identity from the list of digital identities.

[0134] It should be understood that when the requested node type originates from a third node, the third node authorizes the first node to act as its proxy node for the S250 procedure. A more detailed process will follow. Figure 11 The explanation is as follows.

[0135] In the above technical solution, the first node can request the second node to be connected from the identity management node using only its first digital identity information, thereby facilitating communication between the first and second nodes. This method is applicable to any entity in the automotive ecosystem, unrestricted by different hardware manufacturers, simplifying the connection process between different nodes without requiring the combination of multiple methods for different entities.

[0136] The following will combine Figures 4 to 9 The first digital identity and the first digital identity container provide a detailed explanation of the generation process for different types of first nodes.

[0137] Figure 4 This is a schematic diagram of the interactive process of a digital identity generation process provided in an embodiment of this application.

[0138] about Figure 4 For explanations regarding the first node and identity management node, please refer to [link / reference]. Figure 2 The relevant explanations will not be elaborated here.

[0139] S410, the first node determines the first attribute information, which is used to indicate the attributes of the first node.

[0140] It should be understood that the first attribute information may include the media access control identity (MAC ID).

[0141] Optionally, the first node determines a first encryption certificate, which is used to verify the identity of the first node.

[0142] S420, the first node sends a first registration request to the identity management node, and the identity management node receives the first registration request from the first node. The first registration request includes first attribute information.

[0143] Optionally, the first registration request may also include a first encryption certificate.

[0144] S430, the identity management node generates a first digital identity and a first digital identity container based on the first attribute information.

[0145] Optionally, before S430, the identity management node verifies the identity of the first node based on the first encryption certificate, and executes S430 after the verification is successful.

[0146] One possible implementation involves taking the first attribute information as input to generate a keyed HMAC (Hybrid MAC) that concatenates the first attribute data. This HMAC can have a 256-bit output. The HMAC is then shortened to N bytes and preamble data is added to obtain the first digital identity. As mentioned earlier, the first digital identity can be an integer, a string, or a combination of numbers and strings.

[0147] Alternatively, the first digital identity can simply be a shortened output of N bytes.

[0148] In this way, a lightweight first digital identity can reduce the bandwidth used in data transmission, as well as the resources used in memory or databases.

[0149] It should be understood that the first digital identity container associated with the first digital identity includes first attribute information. The first attribute information may also include information such as the type of the first node, its role / permissions, authorization functions, or permissions for connecting with other nodes.

[0150] For a lightweight first digital identity, the first digital identity container can use the field of the type of the first node as the first sorted field in the first digital identity container.

[0151] In this way, it will be easier to identify the type of the first node through the first digital identity.

[0152] It should be understood that since the first digital identity is associated with a first digital identity container, the first digital identity container can be determined based on the first digital identity, and thus more detailed attribute information about the first node can be obtained from the first digital identity container. The first digital identity container is stored in the database or memory corresponding to the identity management node.

[0153] S440, the identity management node sends the first digital identity to the first node, and the first node receives the first digital identity from the identity management node.

[0154] In the above technical solution, the method of generating the first digital identity and the first digital identity container helps different nodes from different manufacturers to more easily achieve subsequent access control, identity authentication, and permission management processes in vehicle communication scenarios.

[0155] The following will combine Figures 5 to 9 The process of registering and generating digital identities and digital identity containers is described in detail for vehicle hardware components and vehicle software components.

[0156] Figure 5 This is a schematic diagram of a digital identity generation process for a hardware component provided in an embodiment of this application.

[0157] Figure 5 The process illustrated applies before the vehicle's hardware components are assembled into the vehicle. The first node represents the manufacturer node, which can be completed using the manufacturer's corresponding equipment. Figure 5 The interaction process is shown. The fourth node is a hardware component in the vehicle. The identity management node can be a trusted server, an identity store, or CIAM.

[0158] S510, the manufacturer node determines the first attribute information and the first encryption certificate.

[0159] It should be understood that the first encryption certificate can be referenced in the relevant explanation of S410. The first attribute information may include MAC ID, data of manufacture (DOM), manufacturer ID, role / permission, authorized functions, or permissions for connecting with other nodes, etc.

[0160] In S520, the manufacturer node stores the first attribute information and the first encryption certificate in the fourth node.

[0161] It should be understood that the fourth node can be a vehicle hardware component manufactured by the manufacturer node. The specific storage location can be a secure space within the fourth node or in memory.

[0162] S530, the manufacturer node sends the first registration request to the identity management node. The first registration request includes the first attribute information and the first encryption certificate.

[0163] S540, the identity management node verifies the first encryption certificate.

[0164] Specifically, the identity management node needs to verify the digital signature on the first encryption certificate and the challenge response method using the manufacturer's public key. For the latter, the specific steps are as follows:

[0165] S541, the identity management node sends an encrypted verification message to the manufacturer node. The manufacturer node receives the encrypted verification message from the identity management node, which is encrypted using the manufacturer's public key.

[0166] S542, the manufacturer node decrypts the encrypted verification message using its private key. If decryption is successful, it sends a verification pass message to the identity management node, which then receives the verification pass message.

[0167] S550, after successful verification, the identity management node generates a first digital identity and a first digital identity container based on the first attribute information.

[0168] It should be understood that the specific details of S550 can be found in S430, and will not be repeated here.

[0169] In S560, the identity management node sends the first digital identity to the manufacturer node, and the manufacturer node receives the first digital identity from the identity management node.

[0170] In the S570, the manufacturer node securely stores the first digital identity in the fourth node.

[0171] Figure 6 This is a schematic diagram of the digital identity generation process of another hardware component provided in an embodiment of this application.

[0172] Figure 6This illustrates the process of generating digital identities for hardware components after they have been assembled into a vehicle from different manufacturers.

[0173] S1, the first node sends the first registration request to the identity management node.

[0174] The first node can be Figure 6 The first type of equipment, the second type of equipment, or the complete vehicle shown.

[0175] Identity management nodes can be Figure 6 The trusted servers shown.

[0176] It should be understood that the first registration request may include the initial security factory certificate for the hardware component, which is the first encryption certificate in the S410. The first registration request may also include first attribute information, which can be used to indicate the attributes of the first node.

[0177] S2, the identity management node generates a first digital identity and a first digital identity container based on the first encryption certificate and the first attribute information.

[0178] The first digital identity container is stored in the database of the identity management node.

[0179] It should be understood that the steps for verification using the first encryption certificate can be found in S540, and the steps for generating the first digital identity and the first digital identity container can be found in S430, which will not be elaborated here.

[0180] S3, the identity management node sends the first digital identity to the first node.

[0181] It should be understood that the first digital identity can be the digital identity corresponding to the hardware component.

[0182] It should also be understood that the first digital identity can be stored in Figure 6 In the digital wallet shown in the first node, the digital wallet is a secure and reliable space. Examples include TEE, HSM, or TPM.

[0183] S4, when a third-type device requests a digital identity, the third-type device, acting as a third node, sends a third registration request to the first node. This third registration request includes the third node's third attribute information. Subsequently, the first node sends a second registration request to the identity management node. This second registration request includes the third attribute information and the first node's first digital identity.

[0184] In other words, the first node can be regarded as the parent node of the third node, that is, the proxy node of the third node. The third node authorizes the first node to represent the third node in the process of access management, identity authentication or permission management.

[0185] Specifically, the first node needs to have the ability to invoke proxy capabilities authorized by the third-type device (i.e., the third node). For example, here, the first node could be a gateway ECU, and the third-type device could be a resource-constrained ECU. The resource-constrained ECU can delegate its tasks to the gateway ECU, and the gateway ECU represents the resource-constrained ECU in complex security authentication and certificate recognition. In other words, the gateway ECU helps the resource-constrained ECU perform complex security authentication and other steps with other devices that do not directly communicate with the resource-constrained ECU.

[0186] It should be understood that a more detailed process will be provided in subsequent sections. Figure 11 The specific application scenarios will be explained in detail.

[0187] Figure 7 This is a schematic diagram of a digital identity generation process for another hardware component provided in an embodiment of this application.

[0188] Figure 7 The digital identity generation process shown and Figure 6 similar, Figure 7 This more clearly demonstrates the communication connections between different types of hardware components. The specific generation process will not be detailed here.

[0189] like Figure 7 As shown, in the vehicle's hardware components, the T-BOX can communicate with the cloud server via 4G or 5G, while the CDC can communicate with the cloud server via WiFi. It should be understood that in the future, other hardware components in the vehicle capable of communicating with external devices could also communicate via future mobile communication methods; this application does not limit this.

[0190] Therefore, although MDC, VDC, and VIU are all Type 1 devices, when they communicate with the cloud server as the primary node, they can use T-BOX as a relay node to forward messages such as the primary registration request. It should be understood that a relay node is different from... Figure 6 The first node described in S4 acts as a proxy node for the third node. The relay node only has the function of message forwarding and does not have the ability to perform access management and other processes on behalf of other nodes.

[0191] There are two architectures for vehicle software components to generate digital identities: centralized and distributed. In a centralized architecture, the identity management node for communication between vehicle software components resides within a single hardware component of the vehicle. In a distributed architecture, the identity management node for communication between vehicle software components resides across multiple hardware components of the vehicle. Here, the hardware components are classified as Type I devices, meaning devices with abundant resources. The following will combine... Figure 8 and Figure 9 Please provide detailed explanations for each.

[0192] Figure 8 This is a schematic diagram of a digital identity generation process for a software component provided in an embodiment of this application.

[0193] Figure 8 The software components shown can be services, applications, or application processes in different hardware. Figure 8 Let's take the service as an example to explain in detail.

[0194] like Figure 8 As shown, the in-vehicle hardware components offer different services, with the first node in... Figure 8 The middle part can be understood as the first service, and the identity management node can be understood as the identity management service, that is... Figure 8 The Identity and Access Management Service (IAMS) is shown. IAMS resides on resource-rich devices, for example, Figure 8 The identity management node is located in MDC.

[0195] The process of generating digital identities using software components is similar to that using hardware components. The difference is that for the former, the identity management node can reside on the vehicle hardware component, while for the latter, the identity management node can reside on a cloud server. In the detailed explanation below, "First Service" can be considered as "First Node," and "IAMS" can be considered as "Identity Management Node."

[0196] S1, the first service sends the first registration request to IAMS.

[0197] It should be understood that since both Type 1 and Type 2 devices communicate via high-bandwidth methods such as Ethernet or CAN FD, when the first service is a service within either Type 1 or Type 2 devices, the first service can communicate directly with IAMS.

[0198] For example, the first service on the subdomain controller and the IAMS on the MDC can communicate directly via high-bandwidth communication.

[0199] It should be understood that the first registration request includes the first encryption certificate and the first attribute information, both of which are related to the first service.

[0200] S2, IAMS verifies the identity of the first service based on the first encryption certificate. After the verification is successful, IAMS generates the first digital identity and the first digital identity container based on the first attribute information.

[0201] For the specific verification process, please refer to S540. For the specific digital identity and digital identity container generation process, please refer to S430. They will not be elaborated here.

[0202] S3, IAMS sends the first digital identity to the first service and stores the first digital identity container in the database.

[0203] like Figure 8 As shown, the first digital identity can be stored in the digital wallet corresponding to the first service.

[0204] It should be understood that the digital wallet stores not only the digital identity corresponding to the first service, but also the digital identity corresponding to the hardware components of the first service (such as...). Figure 8 As shown), for the latter, it can be done through Figure 5 or Figure 6 or Figure 7 It is obtained in the manner shown.

[0205] S4, for the third service located in the third device type, and Figure 7 Similar to S4, the service of the third type of device, acting as a third service, sends a third registration request to the first service. This third registration request includes the third attribute information of the third service. Subsequently, the first service sends a second registration request to IAMS, which includes the third attribute information and the first digital identity of the first service.

[0206] The third service authorizes the first service to request its own digital identity, and the digital wallet corresponding to the first service can also store the third service's third digital identity and token. The third service's token will be used in the third service's identity authentication process.

[0207] For example, such as Figure 8 As shown, firstly, the MCU's third service sends a third registration request to the VIU's first service. Secondly, the VIU's first service sends a second registration request to the IAMS, which includes third attribute information and the first service's first digital identity. Then, the IAMS verifies whether the first service is allowed to initiate the second registration request based on the first digital identity. After successful verification, the IAMS generates a third digital identity, a token, and a third digital identity container based on the third attribute information. Finally, the IAMS sends the third digital identity and token to the first service, and the third digital identity container is stored in the IAMS's database. The digital wallet corresponding to the first service can store the third digital identity and token.

[0208] Figure 9 This is a schematic diagram of the digital identity generation process of another software component provided in an embodiment of this application.

[0209] Figure 9 The distributed digital identity generation process is shown. Figure 9 The process of software components generating digital identities and digital identity containers and Figure 8 The process shown is similar and will not be repeated here.

[0210] Figure 9 The architecture and Figure 8 The difference is that, Figure 9 In Type 1 devices, there is an IAMS, which generates digital identities and digital identity containers, and the database that stores the digital identity containers can be distributed across different Type 1 devices with abundant resources.

[0211] Specifically, the first service can send the first registration request or the second registration request to IAMS via broadcast. In this way, the first service does not need to know the specific hardware component entity of IAMS, that is, the first service does not need to know the network protocol (IP address) of the hardware component that has IAMS in advance, and can send the corresponding registration request to IAMS.

[0212] so, Figure 9 The method and architecture for generating digital identities shown can avoid security risks caused by single points of failure and improve the reliability of vehicle communication.

[0213] The following will combine Figures 10 to 12 Examples illustrate the communication process of vehicle-related services in different scenarios. The main scenarios are as follows: First, communication between services of resource-rich devices, namely, communication between services of type 1 devices, communication between services of type 2 devices, or communication between services of type 1 and type 2 devices; Second, communication between resource-rich devices and resource-constrained devices, namely, communication between services of type 1 and type 3 devices, or communication between services of type 2 and type 3 devices; Third, communication between in-vehicle devices and external devices.

[0214] Figure 10 This is a schematic diagram of the communication process between services of a vehicle resource-rich device provided in an embodiment of this application.

[0215] like Figure 10 As shown, the first node can be understood as the first service, and the second node can be understood as the second service.

[0216] S1010 generates the first digital identity between the first service and IAMS. Specifically, this includes S1011 to S1013.

[0217] S1011, the first service sends a first registration request to IAMS, the first registration request including a first encryption certificate and first attribute information.

[0218] The first attribute information may include device information of the device where the first service is located, service type, role and access permissions, public key, creation date and other related attributes.

[0219] S1012, IAMS verifies the first encryption certificate. After the verification is successful, it generates the first digital identity and the first digital identity container for the first service based on the first attribute information.

[0220] For specific procedures, please refer to [link / reference]. Figure 4 The S430 will not be discussed in detail here.

[0221] It should be understood that the first digital identity container is stored in the database, and a new entry for starting the first service is created in the service registry.

[0222] S1013, IAMS sends the first digital identity to the first service.

[0223] S1020, a second digital identity is generated between the second service and IAMS. Specifically, this includes S1021 to S1023.

[0224] S1021, the second service sends a fourth registration request to IAMS, which includes the second encryption certificate and the second attribute information.

[0225] S1022, IAMS verifies the second encryption certificate. After successful verification, it generates the second digital identity and the second digital identity container for the second service based on the second attribute information.

[0226] S1023, IAMS sends the second digital identity to the second service.

[0227] It should be understood that S1021 to S1023 are similar to S1021 to S1023. For details not explained in detail, please refer to S1021 to S1023. They will not be elaborated here.

[0228] S1030, the service to be connected by the first service is determined between the first service and IAMS, specifically including S1031 to S1035.

[0229] S1031, the first service sends a first request message to IAMS, the first request message including the first digital identity of the first service and the requested service type.

[0230] It should be understood that in vehicle communication, the requested service type can be a number corresponding to a known specific service type.

[0231] S1032, IAMS verifies whether the service type of the first service connection request is allowed based on the first digital identity.

[0232] Specifically, IAMS determines the first digital identity container associated with the first digital identity based on the first digital identity. The role field in the first digital identity container is used to indicate whether the first service connection is allowed for the requested service type.

[0233] S1033, after the verification is passed, IAMS determines at least one candidate service corresponding to the requested service type.

[0234] It should be understood that at least one candidate service may be a list of digital identities of candidate services corresponding to at least one candidate service, as well as detailed information corresponding to each candidate service.

[0235] For example, detailed information may include the node type of the candidate nodes, such as the service type, which helps the first node quickly and accurately select the second node to connect to from the candidate nodes.

[0236] S1034, IAMS sends a first feedback message to the first service. The first feedback message includes a list of digital identities of candidate services and detailed information about each candidate service.

[0237] S1035, the first service checks the details and determines the second digital identity from the list of digital identities as the second service to be connected.

[0238] S1040 connects the first service and the second service. Implementation method 1 specifically includes S1041a to S1046a.

[0239] S1041a, the first service sends an acquisition request message to IAMS. The acquisition request message is used to request the secure connection certificate of the second service. The acquisition request message includes the second digital identity.

[0240] S1042a, IAMS obtains a secure connection certificate based on the second digital identity and sends the second service's secure connection certificate to the first service.

[0241] It should be understood that IAMS sends the encrypted secure connection certificate to the first service, which is the encrypted verifiable certificate.

[0242] S1043a, the first service sends a connection request message to the second service. The connection request message is used to request a connection with the second service. The connection request message includes the second service's secure connection certificate and the first digital identity.

[0243] S1044a, the second service sends a verification message to IAMS. The verification message is used to verify whether the first service is allowed to connect. The verification message includes the first digital identity.

[0244] S1045a, IAMS determines a first digital identity container based on the first digital identity, and verifies whether the first service connection is allowed based on the role field in the first digital identity container. After successful verification, IAMS sends a second verification success message to the second service, which instructs the second service to allow the first service connection.

[0245] S1046a, the second service sends a connection acceptance message to the first service.

[0246] Implementation method 2 specifically includes S1041b to S1047b.

[0247] S1041b, the first service sends an acquisition request message to IAMS. The acquisition request message is used to request the secure connection certificate of the second service, and the acquisition request message includes the second digital identity.

[0248] S1042b, IAMS obtains a secure connection certificate based on the second digital identity and sends the second service's secure connection certificate to the first service.

[0249] S1043b, the first service sends a connection request message to the second service. The connection request message is used to request a connection with the second service and includes the second service's secure connection certificate and first digital identity.

[0250] S1044b, the second service sends a verification acquisition message to IAMS. The verification acquisition message is used to obtain the permission field and verifiable certificate of the first service. The verification acquisition message includes the secure connection certificate of the second service and the first digital identity of the first service.

[0251] In step S1045b, IAMS verifies the identity of the second service based on its secure connection certificate, and retrieves the permission field and verifiable certificate of the first service from the first digital identity container based on the first digital identity. IAMS then sends the permission field and verifiable certificate of the first service to the second service.

[0252] S1046b, the second service verifies whether the first service is allowed to connect based on the first service's permission field and verifiable certificate.

[0253] Upon successful verification, in step S1047b, the second service sends a connection acceptance message to the first service.

[0254] Figure 11 This is a schematic diagram of the communication process between a vehicle resource-rich device and a resource-constrained device, as provided in an embodiment of this application.

[0255] For example, such as Figure 11As shown, the first node can be a VIU service, that is, a service on the VIU, such as a service on the gateway ECU; the second node can be an MDC service, that is, a service on the MDC; and the third node can be a sensor service, that is, a service on the sensor. The following will provide a detailed explanation using VIU services, MDC services, and sensor services as examples.

[0256] S1110 generates a third digital identity between sensor services, VIU services, and IAMS. Specifically, this includes S1111 to S1115.

[0257] S1111, the sensor service sends a third registration request to the VIU service. The third registration request includes the service type requested by the sensor service and the third attribute information of the sensor service.

[0258] S1112, the VIU service sends a second registration request to IAMS, the second registration request including the VIU service's first digital identity and third attribute information.

[0259] S1113, IAMS verifies whether the service type requested by the VIU service is allowed based on the first digital identity. After successful verification, IAMS generates a third digital identity, a token, and a third digital identity container corresponding to the sensor service based on the third attribute information.

[0260] The token for the sensor service is used for authentication in subsequent sensor services.

[0261] For details on the process of generating third digital identities and third digital identity containers, please refer to [link / reference]. Figure 4 The S430 will not be discussed in detail here.

[0262] It should be understood that the third digital identity container is stored in the database corresponding to IAMS.

[0263] S1114, IAMS sends a third digital identity and token to the VIU service.

[0264] S1115, the VIU service sends a third digital identity and token to the sensor service.

[0265] It should be understood that when the sensor corresponding to the sensor service has a secure space, the third digital identity and token of the sensor service can be stored in the secure space of the sensor. Alternatively, the third digital identity and token can also be stored in the secure space of the VIU.

[0266] S1120 generates a second digital identity between the MDC service and IAMS. Specifically, this includes S1121 to S1123.

[0267] It should be understood that S1121 and S1123 are similar to S1021 to S1023. For detailed process, please refer to S1021 to S1023. They will not be repeated here.

[0268] S1130 determines the service to be connected between the sensor service, VIU service, and IAMS. Specifically, this includes S1131 to S1137.

[0269] S1131, the sensor service sends an authorization message to the VIU service. The authorization message is used to authorize the VIU service to act as a proxy service for the sensor service.

[0270] It should be understood that after receiving the authorization message, the VIU service can perform complex steps such as identity authentication, permission management, and access management on behalf of the sensor service.

[0271] The VIU service sends an update request to the IAMS service. The update request is used to add information about the VIU service as a proxy service for the sensor service to the permissions field of the first digital identity container of the VIU service.

[0272] S1132, the sensor service sends a second request message to the VIU service, the second request message including a third digital identity, a token, and the requested service type.

[0273] S1133, the VIU service sends a first request message to IAMS, the first request message including the third digital identity, the token, the requested service type, and the first digital identity.

[0274] It should be understood that the first digital identity is used to instruct the VIU service to act as an agent for the sensor service.

[0275] S1134, IAMS verifies, based on the first digital identity, whether the VIU service is allowed to initiate a request message for the sensor service type. IAMS also verifies, based on the third digital identity and the token, whether the sensor service connection request is allowed.

[0276] Specifically, IAMS determines the first digital identity container associated with the first digital identity based on the first digital identity. The role field in the first digital identity container is used to indicate whether the VIU service is allowed to initiate a service type request message for sensor services.

[0277] IAMS determines the third digital container associated with the third digital identity based on the third digital identity and the token. The role field in the third digital identity container is used to indicate whether the service type of the sensor service connection request is allowed.

[0278] S1135, after the verification is successful, IAMS determines at least one candidate service corresponding to the requested service type.

[0279] It should be understood that at least one candidate service may be a list of digital identities of candidate services corresponding to at least one candidate service, as well as detailed information corresponding to each candidate service.

[0280] S1136, IAMS sends a first feedback message to the VIU service. The first feedback message includes a list of digital identities of candidate services and detailed information about each candidate service.

[0281] For example, detailed information may include the node type of the candidate nodes, such as the service type, which helps the first node quickly and accurately select the second node to connect to from the candidate nodes.

[0282] S1137, the VIU service, representing the sensor service, checks the details and determines the second digital identity from the list of digital identities as the MDC service to be connected.

[0283] S1140 connects the sensor service and the MDC service through the VIU service. The implementation method 1 specifically includes S1141a to S1147a.

[0284] S1141a, the VIU service sends an acquisition request message to IAMS. The acquisition request message is used to request the acquisition of the secure connection certificate of the MDC service. The acquisition request message includes a second digital identity.

[0285] S1142a, IAMS obtains a secure connection certificate based on the second digital identity and sends the secure connection certificate of the MDC service to the VIU service.

[0286] It should be understood that IAMS sends the encrypted secure connection certificate to the VIU service, which is the encrypted verifiable certificate.

[0287] S1143a, the VIU service sends a connection request message to the MDC service. The connection request message is used to request a connection with the second service. The connection request message includes the MDC service's secure connection certificate, third digital identity, token, and first digital identity.

[0288] S1144a, the MDC service sends a verification message to IAMS. The verification message is used to verify whether the VIU service connection is allowed. The verification message includes the first digital identity, the third digital identity, the token, and the security connection certificate of the MDC service.

[0289] S1145a, IAMS determines a first digital identity container based on the first digital identity, and verifies whether the VIU service is allowed to connect to the MDC service on behalf of the sensor service based on the role field in the first digital identity container, the third digital identity, the token, and the secure connection certificate of the MDC service. After successful verification, IAMS sends a second verification success message to the MDC service, which instructs the MDC service to allow the VIU service to connect on behalf of the sensor service.

[0290] S1146a, the MDC service sends a connection acceptance message to the VIU service.

[0291] S1147a, the VIU service sends a connection acceptance message to the sensor service.

[0292] Implementation method 2, specifically including S1141b to S1148b, should be understood that these steps are not included in... Figure 11 As shown in the image.

[0293] S1141b, the VIU service sends an retrieval request message to IAMS. The retrieval request message is used to request the secure connection certificate of the MDC service and includes a second digital identity.

[0294] S1142b, IAMS obtains a secure connection certificate based on the second digital identity and sends the secure connection certificate of the MDC service to the VIU service.

[0295] S1143b, the VIU service sends a connection request message to the MDC service. The connection request message is used to request a connection with the second service. The connection request message includes the MDC service's secure connection certificate, third digital identity, token, and first digital identity.

[0296] S1144b, the MDC service sends a verification acquisition message to IAMS. The verification acquisition message is used to obtain the permission fields and verifiable certificates of the VIU service. The verification acquisition message includes the secure connection certificate of the MDC service and the first digital identity of the VIU service.

[0297] In step S1145b, IAMS verifies the identity of the MDC service based on its secure connection certificate, and retrieves the permission field and verifiable certificate of the VIU service from the first digital identity container based on the first digital identity. IAMS then sends the permission field and verifiable certificate of the VIU service to the MDC service.

[0298] S1146b, the MDC service verifies whether the VIU service is allowed to connect on behalf of the sensor service and the MDC service based on the third digital identity, token, VIU service permission fields and verifiable certificate.

[0299] Upon successful verification, in step S1147b, the MDC service sends a connection acceptance message to the VIU service.

[0300] S1148b, the VIU service sends a connection acceptance message to the sensor service.

[0301] It should be understood that the VIU service and the sensor service communicate via low-bandwidth methods such as the in-vehicle CAN bus or LIN bus, while the VIU service and the MDC service communicate via high-bandwidth methods such as in-vehicle Ethernet or CAN FD.

[0302] Figure 12 This is a communication flowchart between in-vehicle devices and external devices provided in an embodiment of this application.

[0303] For example, such as Figure 12 As shown, the first node can be a CDC service, such as a multimedia or entertainment service, which is a service on the CDC; the second node can be a vehicle-to-everything (V2X) service, which supports V2X services on external devices; the identity management node can be a cloud-based identity and access management service (CIAMS) or a cloud-based identity management service (CIMS). The following explanation uses CDC, V2X, and CIAMS as examples.

[0304] It should be understood that the external CIAMS can communicate with the internal IAMS.

[0305] It should also be understood that, Figure 12 The communication process omits the steps involved in generating the first digital identity and its container using the CDC service. The CDC's first digital identity container is stored in the in-vehicle IAMS, which is the part of the actual generation process. Figure 10 S1010 and Figure 11 Similar to S1110, it will not be elaborated here.

[0306] S1210 determines the services to be connected between the CDC service and CIAMS. This includes S1211 through S1215.

[0307] S1211, the CDC sends a first request message to the in-vehicle IAMS, and the in-vehicle IAMS forwards the first request message to the CIAMS. The first request message includes the first digital identity of the CDC service and the type of service requested.

[0308] S1212, CIAMS verifies the type of service for which the CDC service connection request is allowed based on the first digital identity.

[0309] Specifically, CIAMS determines the first digital identity container from the in-vehicle IAMS database based on the first digital identity. The role field in the first digital identity container is used to indicate whether the CDC service is allowed to connect to the requested service type.

[0310] S1213, CIAMS determines at least one candidate service corresponding to the requested service type.

[0311] It should be understood that S1213 and S1033 are similar, and a detailed description can be found in S1033, which will not be repeated here.

[0312] S1214, CIAMS sends the first feedback message to the in-vehicle IAMS, and IAMS forwards the first feedback message to the CDC service. The first feedback message includes a list of digital identities of candidate services and detailed information of each candidate service.

[0313] S1215, the CDC service checks the details and determines the second digital identity from the list of digital identities to be used as the V2X service to be connected.

[0314] Alternatively, the V2X service can directly send a connection request to the CDC service. Or,

[0315] S1220 connects CDC services and V2X services. Specifically, it includes S1221 to S1226.

[0316] S1221, the first service sends an acquisition request message to the in-vehicle IAMS, the in-vehicle IAMS forwards the acquisition request message to the CIAMS, the acquisition request message is used to request the acquisition of the secure connection certificate of the V2X service, and the acquisition request message includes the second digital identity.

[0317] S1222, CIAMS obtains a secure connection certificate based on the second digital identity and sends the secure connection certificate to the in-vehicle IAMS. The in-vehicle IAMS then forwards the secure connection certificate of the V2X service to the CDC service.

[0318] It should be understood that CIAMS sends the encrypted secure connection certificate to the in-vehicle IAMS, which is the encrypted verifiable certificate.

[0319] S1223, the CDC service sends a connection request message to the V2X service. The connection request message is used to request a connection with the V2X service. The connection request message includes the V2X service's secure connection certificate and first digital identity.

[0320] S1224, the V2X service sends a verification message to CIAMS. The verification message is used to verify whether the CDC service connection is allowed. The verification message includes the first digital identity.

[0321] S1225, CIAMS determines the first digital identity container from the in-vehicle IAMS based on the first digital identity, and verifies whether the CDC service connection is allowed based on the role field in the first digital identity container. After successful verification, CIAMS sends a second verification success message to the V2X service, which instructs the V2X service to allow the CDC service connection.

[0322] S1226, the V2X service sends a connection acceptance message to the CDC service.

[0323] It should be understood that in the communication scenario between in-vehicle devices and external devices, the specific implementation of connecting CDC service and V2X service can also be similar to implementation method 2 corresponding to S1040, that is, V2X service checks whether CDC service connection is allowed.

[0324] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0325] The above text combines Figures 1 to 12 The methods provided in the embodiments of this application are described in detail below. Figure 13 and Figure 14 The apparatus provided in the embodiments of this application is described in detail. It should be understood that the description of the apparatus embodiments corresponds to the description of the method embodiments. Therefore, for content not described in detail, please refer to the method embodiments above. For the sake of brevity, it will not be repeated here.

[0326] Figure 13 This is a schematic block diagram of a communication device 1300 provided in an embodiment of this application.

[0327] The communication device 1300 includes a transceiver unit 1310 and a processing unit 1310.

[0328] The communication device 1300 can also be used to perform... Figure 2 , Figure 4 , Figure 5 , Figure 6 , Figures 10 to 12 Any of the following methods. The communication device 1300 can be an identity management node or a first node.

[0329] When the communication device 1300 is an identity management node, the communication device 1300 can specifically perform the following steps:

[0330] The transceiver unit 1310 is configured to receive a first request message from a first node, the first request message including a requested node type and a first digital identity of the first node. The processing unit 1320 is configured to determine, based on the first digital identity, a first digital identity container associated with the first digital identity, the first digital identity container storing attribute information of the first node. The processing unit 1320 is further configured to determine, based on the first digital identity container, at least one candidate node corresponding to the requested node type. The transceiver unit 1310 is further configured to send a first feedback message to the first node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the digital identity list including a second digital identity corresponding to a second node to which the first node wishes to connect.

[0331] To avoid redundancy, detailed steps can be found in the corresponding method implementation examples.

[0332] When the communication device 1300 is the first node, the communication device 1300 can specifically perform the following steps:

[0333] The transceiver unit 1310 is configured to send a first request message to the identity management node, the first request message including the requested node type and the first digital identity of the first node. The transceiver unit 1310 is configured to receive a first feedback message from the identity management node, the first feedback message including a list of digital identities corresponding to at least one candidate node, the at least one candidate node being determined based on a first digital identity container associated with the first digital identity and the requested node type, wherein the first digital identity container stores attribute information of the first node. The processing unit 1320 is configured to select a second digital identity of the second node to be connected from the list of digital identities.

[0334] To avoid redundancy, detailed steps can be found in the corresponding method implementation examples.

[0335] It should be understood that the division of units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), and the functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD), such as a field-programmable gate array (FPGA), which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby achieving the functionality of some or all of the above units. All units of the above device can be implemented entirely through processor-invoked software, entirely through hardware circuits, or partially through processor-invoked software with the remaining parts implemented through hardware circuits.

[0336] In this application embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships of hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc.

[0337] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0338] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and artificial intelligence processor, CPU and GPU, etc.

[0339] Figure 14 This is a schematic block diagram of a communication device 1400 provided in an embodiment of this application. Figure 14The communication device 1400 shown may include a processor 1410, a transceiver 1420, and a memory 1430. The processor 1410, transceiver 1420, and memory 1430 are connected via internal interconnection paths. The memory 1430 stores instructions, and the processor 1410 executes the instructions stored in the memory 1430 to receive / send certain parameters via the transceiver 1420. Optionally, the memory 1430 may be coupled to the processor 1410 via an interface or integrated with the processor 1410.

[0340] It should be noted that the transceiver 1420 described above may include, but is not limited to, transceiver devices such as input / output interfaces, to enable communication between device 1400 and other devices or communication networks.

[0341] In implementation, each step of the above method can be completed by the integrated logic circuitry of the hardware in the processor 1410 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 1430, and the processor 1410 reads the information in memory 1430 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0342] The processor 1410 can be a general-purpose CPU, microprocessor, ASIC, GPU, or one or more integrated circuits to execute related programs to implement the communication method of the embodiments of this application. The processor 1410 can also be an integrated circuit chip with signal processing capabilities. In specific implementation, each step of the communication method of this application can be completed by the integrated logic circuits in the hardware of the processor 1410 or by instructions in software form. The processor 1410 can also be a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory 1430. The processor 1410 reads the information in the memory 1430 and executes the communication method of the method embodiment of this application in conjunction with its hardware.

[0343] The memory 1430 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM).

[0344] Transceiver 1420 uses transceiver devices, such as, but not limited to, transceivers, to enable communication between device 1400 and other devices or communication networks.

[0345] This application also provides a communication system, which includes the above-described communication device 1300 or the above-described communication device 1400.

[0346] This application also provides a mobile carrier, which in some possible implementations may include the aforementioned communication device 1300, or the aforementioned communication device 1300. For example, in the communication device 1300 (or communication device 1400) for performing... Figure 2 , Figure 4 , Figure 5 , Figure 6 , Figures 10 to 12 When the device is any of the methods described above, the vehicle may include the communication device 1300 (or communication device 1400).

[0347] Alternatively, the mobile carrier may be a vehicle.

[0348] This application embodiment also provides a cloud server, which may include the above-mentioned communication device 1300. In this case, the communication device 1300 is an identity management node.

[0349] This application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to perform the above-described... Figure 2 , Figure 4 , Figure 5 , Figure 6 , Figures 10 to 12 Any one of the methods.

[0350] This application also provides a computer-readable medium storing program code that, when executed on a computer, causes the computer to perform the above-described actions. Figure 2 , Figure 4 , Figure 5 , Figure 6 , Figures 10 to 12 Any one of the methods.

[0351] This application also provides a chip, including: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is used to read and execute instructions in the memory to perform the above-mentioned... Figure 2 , Figure 4 , Figure 5 , Figure 6 , Figures 10 to 12 Any one of the methods.

[0352] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0353] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0354] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0355] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0356] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0357] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0358] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0359] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method, characterized in that, The method is used for an identity management node, and the method includes: Receive a first request message from a first node, the first request message including the requested node type and the first digital identity of the first node; Based on the first digital identity, a first digital identity container associated with the first digital identity is determined, and the first digital identity container stores the attribute information of the first node; Based on the first digital identity container, determine at least one candidate node corresponding to the node type of the request; Send a first feedback message to the first node. The first feedback message includes a list of digital identities corresponding to the at least one candidate node. The list of digital identities includes a second digital identity corresponding to the second node to which the first node wants to connect.

2. The method as described in claim 1, characterized in that, The step of determining at least one candidate node corresponding to the node type of the request based on the first digital identity container includes: Based on the permission field in the first digital identity container, verify whether the first node is allowed to request the node type; When the first node is allowed to request the node type, the at least one candidate node is determined.

3. The method of claim 1 or 2, wherein, The first feedback message also includes detailed information about each of the candidate nodes, which is used to instruct the first node to determine the second node from the at least one candidate node.

4. The method of claim 1 or 2, wherein, Before receiving the first request message, the method further includes: Receive a first registration request from the first node, the first registration request including first attribute information of the first node, the first attribute information being used to indicate the attributes of the first node; Based on the first attribute information, generate the first digital identity and the first digital identity container; Save the first digital identity container; Send the first digital identity to the first node.

5. The method of claim 1 or 2, wherein, When the node type of the request comes from a third node, the first request message also includes the third digital identity and token of the third node, and the first node is a proxy node of the third node.

6. The method as described in claim 5, characterized in that, Before receiving the first request message, the method further includes: Receive a second registration request from the first node, the second registration request including the third attribute information of the third node and the first digital identity, the third attribute information being used to indicate the attributes of the third node; Based on the first digital identity, verify whether the first node is allowed to request the node type of the request; After the verification is successful, the third digital identity, the token, and the third digital identity container of the third node are generated based on the third attribute information. Store the third digital identity container; Send the third digital identity and the token to the first node.

7. The method of claim 1 or 2, wherein, The identity management node is used for the identity management of the vehicle entity. The identity management node is located on a cloud server, or the identity management node is located on at least one of the entities of the vehicle.

8. A communication method characterized by comprising: The method is used for the first node, and the method includes: Send a first request message to the identity management node, the first request message including the requested node type and the first digital identity of the first node; Receive a first feedback message from the identity management node. The first feedback message includes a list of digital identities corresponding to at least one candidate node. The at least one candidate node is determined based on a first digital identity container associated with the first digital identity and the node type requested. The first digital identity container stores the attribute information of the first node. Select the second digital identity of the second node to be connected from the list of digital identities.

9. The method of claim 8, wherein, The first feedback message also includes detailed information about each candidate node, and the second digital identity for selecting the second node to be connected from the digital identity list includes: Based on the detailed information, the second node is determined from the at least one candidate node, and the second digital identity is determined from the list of digital identities.

10. The method of claim 8 or 9, wherein, Before sending the first request message to the identity management node, the method further includes: Send a first registration request to the identity management node. The first registration request includes first attribute information of the first node. The first attribute information is used to indicate the attributes of the first node. The first registration request is used to request the first digital identity of the first node. Receive the first digital identity from the identity management node.

11. The method of claim 8 or 9, wherein, Before sending the first request message to the identity management node, the method further includes: Receive an authorization message from a third node, the authorization message being used to authorize the first node as a proxy node of the third node; The first request message receives a second request message from the third node, the second request message including the node type of the request and the third digital identity and token of the third node, and the first request message also includes the third digital identity and the token.

12. The method of claim 11, wherein, Before receiving the second request message from the third node, the method further includes: Receive a third registration request from the third node, the third registration request including third attribute information of the third node, the third attribute information being used to indicate the attributes of the third node, the third registration request being used to request the third digital identity and the token; A second registration request is sent to the identity management node. The second registration request includes the third attribute information of the third node and the first digital identity. The second registration request is used to request the third digital identity and the token. Receive the third digital identity and the token from the identity management node.

13. The method as described in claim 8 or 9, characterized in that, The first node is an entity related to the vehicle.

14. An identity management node, characterized in that, Includes a transceiver unit and a processing unit: The transceiver unit is configured to receive a first request message from a first node, the first request message including the requested node type and the first digital identity of the first node; The processing unit is configured to determine, based on the first digital identity, a first digital identity container associated with the first digital identity, wherein the first digital identity container stores the attribute information of the first node; The processing unit is further configured to determine at least one candidate node corresponding to the node type of the request based on the first digital identity container; The transceiver unit is further configured to send a first feedback message to the first node, the first feedback message including a list of digital identities corresponding to the at least one candidate node, the list of digital identities including a second digital identity corresponding to the second node to which the first node wants to connect.

15. The identity management node as described in claim 14, characterized in that, The processing unit is specifically used for: Based on the permission field in the first digital identity container, verify whether the first node is allowed to request the node type; When the first node is allowed to request the node type, the at least one candidate node is determined.

16. The identity management node of claim 14 or 15, characterized by The first feedback message also includes detailed information about each of the candidate nodes, which is used to instruct the first node to determine the second node from the at least one candidate node.

17. The identity management node of claim 14 or 15, characterized by Before receiving the first request message, The transceiver unit is further configured to receive a first registration request from the first node, the first registration request including first attribute information of the first node, the first attribute information being used to indicate the attributes of the first node; The processing unit is also used for, Based on the first attribute information, generate the first digital identity and the first digital identity container; Save the first digital identity container; The transceiver unit is also used to send the first digital identity to the first node.

18. The identity management node of claim 14 or 15, characterized by When the node type of the request comes from a third node, the first request message also includes the third digital identity and token of the third node, and the first node is a proxy node of the third node.

19. The identity management node of claim 18, wherein, Before receiving the first request message, The transceiver unit is further configured to receive a second registration request from the first node, the second registration request including the third attribute information of the third node and the first digital identity, the third attribute information being used to indicate the attributes of the third node; The processing unit is also used for: Based on the first digital identity, verify whether the first node is allowed to request the node type of the request; After the verification is successful, the third digital identity, the token, and the third digital identity container of the third node are generated based on the third attribute information. Store the third digital identity container; The transceiver unit is also used to send the third digital identity and the token to the first node.

20. The identity management node of claim 14 or 15, wherein, The identity management node is used for the identity management of the vehicle entity. The identity management node is located on a cloud server, or the identity management node is located on at least one of the entities of the vehicle.

21. A first node, the first node comprising: Includes a transceiver unit and a processing unit: The transceiver unit is used to send a first request message to the identity management node, the first request message including the requested node type and the first digital identity of the first node; The transceiver unit is configured to receive a first feedback message from the identity management node. The first feedback message includes a list of digital identities corresponding to at least one candidate node. The at least one candidate node is determined based on a first digital identity container associated with the first digital identity and the node type requested. The first digital identity container stores the attribute information of the first node. The processing unit is used to select a second digital identity of the second node to be connected from the list of digital identities.

22. The first node of claim 21, wherein, The first feedback message also includes detailed information about each candidate node, and the processing unit is specifically used for: Based on the detailed information, the second node is determined from the at least one candidate node, and the second digital identity is determined from the list of digital identities.

23. The first node of claim 21 or 22, wherein, Before sending the first request message to the identity management node, the transceiver unit is further configured to: Send a first registration request to the identity management node. The first registration request includes first attribute information of the first node. The first attribute information is used to indicate the attributes of the first node. The first registration request is used to request the first digital identity of the first node. Receive the first digital identity from the identity management node.

24. The first node of claim 21 or 22, wherein, Before sending the first request message to the identity management node, the transceiver unit is further configured to: Receive an authorization message from a third node, the authorization message being used to authorize the first node as a proxy node of the third node; The first request message receives a second request message from the third node, the second request message including the node type of the request and the third digital identity and token of the third node, and the first request message also includes the third digital identity and the token.

25. The first node of claim 24, wherein, Before receiving the second request message from the third node, the transceiver unit is further configured to: Receive a third registration request from the third node, the third registration request including third attribute information of the third node, the third attribute information being used to indicate the attributes of the third node, the third registration request being used to request the third digital identity and the token; A second registration request is sent to the identity management node. The second registration request includes the third attribute information of the third node and the first digital identity. The second registration request is used to request the third digital identity and the token. Receive the third digital identity and the token from the identity management node.

26. The first node of claim 21 or 22, wherein, The first node is an entity related to the vehicle.

27. A communications device, characterized by include: Memory, used to store computer programs; A processor for executing a computer program stored in the memory to cause the communication device to perform the method as described in any one of claims 1 to 7, or the method as described in any one of claims 8 to 13.

28. A communication system, characterized by The communication system includes an identity management node as described in any one of claims 14 to 20, and a first node as described in any one of claims 21 to 26.

29. A mobile carrier, characterized in that The mobile carrier includes a first node as described in any one of claims 21 to 26, and / or an identity management node as described in any one of claims 14 to 20, and / or a communication device as described in claim 27.

30. The mobile carrier of claim 29, wherein, The mobile carrier is a vehicle.

31. A computer readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a computer, causes to implement the method as claimed in any one of claims 1 to 7, or causes to implement the method as claimed in any one of claims 8 to 13.

32. A computer program product, characterised in that, The computer program product includes: computer program code, which, when run on a computer, causes to implement the method as described in any one of claims 1 to 7, or causes to implement the method as described in any one of claims 8 to 13.

33. A chip, characterized by Includes a circuit for performing the method as claimed in any one of claims 1 to 7, or the circuit for performing the method as claimed in any one of claims 8 to 13.

Images