Communication method and device for trusted decision

Abstract

The invention provides a communication method and device for trusted decision, relates to the technical field of communication, and is used for solving the problems that only the security capability of a terminal is considered in a security policy generation process, and the generation mode is single and not flexible enough. The method comprises the following steps: acquiring a decision mode used for indicating whether a first device serves as a decision party of a trusted policy, or the first device determines the decision party based on a competition mode; sending a first message to the second device based on the decision mode for triggering negotiation of a trusted policy, the trusted policy being used for indicating a security technology and / or a security algorithm employed by communication between the first device and the second device; obtaining a credible policy, the credible policy being obtained according to a first input parameter and a second input parameter corresponding to a second device, the first input parameter being obtained according to a credible demand of the first device, and the credible demand of the first device being used for indicating a demand of the first device for the current communication security capability;

Description

A communication method and device for trusted decision-making Technical Field

[0001] The present application relates to the technical field of communication network security, and in particular to a communication method and device for trusted decision-making. Background Art

[0002] In a mobile communication network system, a terminal and the network can negotiate a security policy before transmitting data. This security policy can include encryption algorithms or integrity protection algorithms. For example, the interactive process for security policy negotiation may include: the terminal sends its supported security capabilities to the network device, and the network device generates a security policy and returns it to the terminal. In other words, the security policy only considers the security capabilities between the terminal and the network device.

[0003] However, with regard to the future development trend of communication networks, communication scenarios will be more flexible and changeable, and the technical requirements for communication security will be higher. In addition, the security requirements of different nodes for communication networks, the security requirements of different users for communication networks, or the security requirements of different scenarios for communication networks may all be differentiated. The existing security policy negotiation is difficult to meet the diverse application scenarios of future communication networks and the needs for the evolution of communication security.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a communication method and apparatus for trusted decision-making, which are used to improve the flexibility of generating security policies to meet diverse application scenarios of communication networks.

[0006] In a first aspect, a communication method for trusted decision-making is provided, which is applied to a first device, the method comprising: obtaining a decision mode for indicating whether the first device serves as a decision-maker of a trusted policy, or for instructing the first device to determine a decision-maker based on a competition mode; sending a first message to a second device based on the decision mode for triggering negotiation of a trusted policy, the trusted policy being used to indicate the security technology and / or security algorithm adopted for communication between the first device and the second device; obtaining a trusted policy, the trusted policy being obtained based on a first input parameter and a second input parameter corresponding to the second device, wherein the first input parameter is obtained based on the trusted requirements of the first device, the second input parameter is obtained based on the trusted requirements of the second device, and the trusted requirements of the first device are used to indicate the first device's requirements for current communication security capabilities.

[0007] In the above embodiment, the first device can trigger a trusted negotiation with the second device according to the configured decision mode to obtain a trusted policy, wherein the trusted policy is obtained based on the input parameters of the first device and the second device. That is to say, the trusted negotiation process of the present application takes into account the communication security needs of both parties to the communication, and the nodes for generating trusted decisions are flexible, and the decision mode can be flexibly configured, which can effectively improve the efficiency and flexibility of the trusted negotiation between the two parties to the communication.

[0008] In one embodiment, the decision mode is used to indicate that the first device acts as a decision maker of the trusted policy, or the decision mode is used to indicate that the first device is not set as a decision maker of the trusted policy, the first message is used to indicate the start of negotiation of the trusted policy, and the first message includes the decision mode.

[0009] In the above embodiment, the first device determines that it can serve as the decision-maker for the trusted decision based on the configured decision-making mode, and can then request the second device to conduct a trusted negotiation. The request message can carry the decision-making mode of the first device to indicate the decision-maker of this trusted policy, so that the second device can feed back its own input parameters to the first device to generate a trusted policy.

[0010] In one embodiment, the method further includes: receiving a second input parameter from a second device; obtaining a trusted policy, including: obtaining a first trusted policy based on the first input parameter, the second input parameter and a decision rule; the method further includes: sending the first trusted policy to the second device.

[0011] In the above implementation, the first device determines the trusted decision-maker based on the configured decision-making model. It then obtains the input parameters of the second device, generates a trusted policy based on the input parameters of both communicating parties, and feeds it back to the second device. This demonstrates that determining the trusted decision-maker based on the decision-making model can reduce signaling overhead and improve the efficiency of trusted negotiation.

[0012] In one embodiment, the decision mode is used to indicate that the first device does not serve as a decision-maker of the trusted policy, the first message is used to indicate the start of negotiation of the trusted policy, and the first message includes the first input parameter.

[0013] In the above-described embodiment, if the first device determines that it is not a decision-maker in a trusted decision-making process based on the configured decision-making mode, it can request a trusted negotiation from the second device and carry its own input parameters for the other party to generate a trusted policy, thereby effectively improving the efficiency of trusted negotiation between the communicating parties. Specifically, in the scenario where the first device is not a decision-maker, carrying the first input parameters in the first message triggering the trusted negotiation avoids separately indicating the first input parameters for the trusted negotiation to the second device, thereby saving the signaling overhead of the trusted negotiation interaction and improving the efficiency of the trusted negotiation.

[0014] In one embodiment, the method further includes: receiving second indication information from a second device, for indicating that the second device serves as the decision-maker of the trusted policy. In the above embodiment, when the first device determines not to serve as the decision-maker of the trusted decision or does not set a decision-maker based on the configured decision-making mode, it can request the second device to conduct a trusted negotiation. At the same time, the second device can feed back its own decision-making mode to the first device, so that the first device can determine the decision-maker of this trusted decision based on the other party's decision-making mode, thereby flexibly implementing the process of the communicating parties conducting trusted negotiation to determine the decision-maker.

[0015] In one embodiment, obtaining a trusted policy includes receiving a second trusted policy from a second device. In the above embodiment, when the first device is not a trusted decision-maker, it can receive a trusted policy generated by the second device, i.e., the communication peer, to flexibly implement a trusted negotiation process between the communicating parties.

[0016] In one embodiment, the trust requirements include security algorithms corresponding to at least one of the following security technologies: encryption, authentication, authorization, blockchain, trust metrics, or privacy protection. In the above embodiment, the trust requirements are expanded beyond encryption algorithms to include trust requirements for communication nodes in other dimensions. This enriches the input parameters for trust decision-making between communicating parties and improves the comprehensiveness and accuracy of trust policies.

[0017] In one embodiment, the trust requirement also includes the priority corresponding to the security algorithm and / or the validity period corresponding to the trust requirement. Specifically, if the trust requirement includes multiple encryption algorithms, the corresponding priorities can be set so that encryption algorithms with higher priorities are preferentially selected when generating a trust policy, thereby improving communication security. Optionally, the validity period of the trust requirement can also be set to periodically update the trust requirements of communication nodes, meet the security requirements of different nodes for the communication network, meet the security requirements of different users for the communication network, or meet the differentiated security requirements of the communication network in different scenarios, thereby improving the flexibility and accuracy of trust negotiation.

[0018] In one embodiment, the first input parameter is obtained based on the trusted configuration and / or network policy of the first device, wherein the trusted configuration of the first device is used to indicate the operator's configuration information on the current communication security capabilities of the first device, and the network policy of the first device is used to indicate the network's requirements for the current communication security capabilities of the first device.

[0019] In the above-mentioned implementation manner, the trusted negotiation process between the communicating parties may also refer to the trusted configuration and / or network policy of each communicating party, that is, comprehensively consider the security requirements and configuration of the network or operator for this communication process, and make the input more comprehensive and reliable, so that the generated trusted policy is more in line with the network environment, meeting the security requirements of different nodes for the communication network, the security requirements of different users for the communication network, or the differentiated security requirements of the communication network in different scenarios, thereby improving the flexibility and accuracy of trusted negotiation.

[0020] In one embodiment, the trusted configuration includes at least one of the following: granularity of trusted negotiation, decision mode, priority of a security algorithm configured by an operator, or validity period corresponding to a trusted policy.

[0021] In one embodiment, the network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

[0022] In one embodiment, obtaining the decision mode includes: obtaining the decision mode from a third device or from an operator. The decision mode of the communication node can be configured by the operator or other network elements such as a trusted engine, thereby improving the flexibility of trusted decision making.

[0023] In one embodiment, the decision mode is used to instruct the first device to determine the decision-maker based on the competition mode, and the method further includes: sending the first input parameter to the blockchain node; when the trusted negotiation between the first device and the second device is triggered, obtaining the second input parameter corresponding to the second device from the blockchain node.

[0024] In one embodiment, obtaining a trusted policy includes: obtaining a first trusted policy based on a first input parameter, a second input parameter, and a decision rule, and sending the first trusted policy to a blockchain node for a decision-maker competing for the trusted policy; or, receiving a notification of successful trusted policy competition by a second device, and obtaining a second trusted policy generated by the second device from the blockchain node.

[0025] In the above implementation, trusted negotiation is applied to the blockchain scenario, and the communication node can obtain the input parameters of the communication peer node from the blockchain node, generate a trusted policy, and then broadcast it on the chain. The decision-maker is determined through a competitive model, so that the communicating parties obtain the trusted policy generated by the communication node that successfully competes, thereby improving the flexibility and efficiency of trusted decision-making.

[0026] In one embodiment, the method further includes: verifying whether the trusted policy meets the trusted requirements of the first device. In the above embodiment, considering that the trusted decisions generated by different communication nodes may differ or not meet the trusted requirements of the communication nodes themselves, the obtained trusted policy can be verified to determine whether it meets the trusted requirements, thereby improving the efficiency of trusted negotiation and communication security.

[0027] In one embodiment, the method further includes: sending a verification result of the trusted policy to the second device.

[0028] In one embodiment, the method further includes: sending a second message to the second device to update the trusted policy. In the above embodiment, both communicating parties can trigger an update of the trusted policy, which can better meet the security requirements of communication nodes for different services, different communication scenarios, or different nodes for the communication network, the security requirements of different users for the communication network, or the differentiated security requirements of different scenarios for the communication network, thereby improving the flexibility and accuracy of trusted negotiation.

[0029] In one embodiment, the second message includes the updated first input parameter of the first device. If the input parameter of the communication node is updated, the updated input parameter can be carried in the request message for updating the trusted policy, thereby generating a new trusted policy and saving the overhead of interactive signaling.

[0030] In one embodiment, the method further includes receiving a notification message from a third device indicating an update to a decision rule for a trusted decision. If the decision rule obtained by the communication node is updated, an update to the trusted policy may be triggered, thereby generating a new trusted policy and improving the flexibility and accuracy of trusted negotiation.

[0031] In one embodiment, the method further includes: receiving a second response from the second device, the second response including an updated trusted policy, wherein the updated trusted policy is obtained by the second device according to the valid first input parameter and the valid second input parameter.

[0032] In one embodiment, the first device is a terminal, a network device, a node responsible for security functions, or a security module included in a terminal or network device. The communication node performing trusted negotiation can be a terminal, a network device, an independent node responsible for security functions, or a security module included in a terminal or network device. This application does not impose any specific restrictions on the type of communication node.

[0033] In one embodiment, the first device is an independent node responsible for security functions, and the method further includes: receiving a trusted negotiation request from the first node, the trusted negotiation request including identification information of the second device, wherein the first device provides security services for the first node.

[0034] In one embodiment, the first device is a security module included in the first terminal or the first network device, and the method further includes: the first device establishing a connection with the second device to trigger trusted negotiation.

[0035] In a second aspect, a communication method for trusted decision-making is provided, which is applied to a second device, the method comprising: obtaining a decision mode, used to indicate whether the second device serves as a decision-maker of a trusted policy, or used to instruct the second device to determine a decision-maker based on a competition mode; receiving a first message from a first device, the first message being used to trigger a negotiated trusted policy, the trusted policy being used to indicate the security technology and / or security algorithm adopted for communication between the first device and the second device; obtaining a trusted policy, the trusted policy being obtained based on a first input parameter corresponding to the first device and a second input parameter corresponding to the second device, wherein the first input parameter is obtained based on the trusted requirements of the first device, the second input parameter is obtained based on the trusted requirements of the second device, and the trusted requirements of the second device are used to indicate the second device's requirements for current communication security capabilities.

[0036] In one embodiment, the decision mode is used to indicate that the second device does not serve as a decision-maker for a trusted policy, or the decision mode is used to indicate that the second device is not set as a decision-maker for a trusted policy, the first message is used to indicate the start of negotiation of a trusted policy, and the first message includes the decision mode.

[0037] In one embodiment, the method further includes: sending a second input parameter to the first device; and obtaining the trusted policy includes: receiving a first trusted policy from the first device.

[0038] In one embodiment, the decision mode is used to instruct the second device to act as a decision-maker of the trusted policy, the first message is used to instruct the start of negotiation of the trusted policy, and the first message includes the first input parameter.

[0039] In one embodiment, the method further includes: sending second indication information to the first device, for indicating the second device as a decision-maker of the trusted policy.

[0040] In one embodiment, obtaining a trusted policy includes: obtaining a second trusted policy according to a first input parameter, a second input parameter, and a decision rule; the method also includes: sending the second trusted policy to the first device.

[0041] In one embodiment, the trust requirement includes a security algorithm corresponding to at least one of the following security technologies: encryption, authentication, authorization, blockchain, trust measurement, or privacy protection.

[0042] In one embodiment, the trust requirement further includes a priority corresponding to the security algorithm and / or a validity period corresponding to the trust requirement.

[0043] In one embodiment, the second input parameter is obtained based on the trusted configuration and / or network policy of the second device, wherein the trusted configuration of the second device is used to indicate the operator's configuration information on the current communication security capabilities of the second device, and the network policy of the second device is used to indicate the network's requirements for the current communication security capabilities of the second device.

[0044] In one embodiment, the trusted configuration includes at least one of the following: granularity of trusted negotiation, decision mode, priority of a security algorithm configured by an operator, or validity period corresponding to a trusted policy.

[0045] In one embodiment, the network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

[0046] In one embodiment, obtaining the decision model includes: obtaining the decision model from a third device or from an operator.

[0047] In one embodiment, the decision mode is used to instruct the second device to determine the decision-maker based on the competition mode, and the method also includes: sending the second input parameter to the blockchain node; when the trusted negotiation between the first device and the second device is triggered, obtaining the first input parameter corresponding to the first device from the blockchain node.

[0048] In one embodiment, obtaining a trusted policy includes: obtaining a second trusted policy based on a first input parameter, a second input parameter, and a decision rule, and sending the second trusted policy to a blockchain node for a decision-maker competing for the trusted policy; or, receiving a notification of successful trusted policy competition of a first device, and obtaining a first trusted policy generated by the first device from the blockchain node.

[0049] In one embodiment, the method further includes: verifying whether the trust policy meets the trust requirements of the second device.

[0050] In one embodiment, the method further includes: sending a verification result of the trusted policy to the first device.

[0051] In one embodiment, the method further includes: receiving a second message from the first device for updating the trusted policy.

[0052] In one embodiment, the second message includes the updated second input parameter of the second device.

[0053] In one embodiment, the method further includes: receiving a notification message from a third device, indicating an update of a decision rule of the trusted decision.

[0054] In one embodiment, the method further includes: sending a second response to the first device, the second response including an updated trusted policy, wherein the updated trusted policy is obtained by the second device according to the valid first input parameter and the valid second input parameter.

[0055] In one embodiment, the second device is a terminal, a network device, a node with a security function, or a security module included in the terminal or the network device.

[0056] In one embodiment, the first device is a first terminal, a first network device, or an independent node of a security function, and the method further includes: the first device establishes a connection with the second device to trigger a trusted negotiation.

[0057] In a third aspect, a communication device is provided for implementing the above method. The communication device may be the first device described in the first aspect, or a node including the first device, or a module in the first device described in the first aspect, such as a chip, chip system, or circuit, or a logical node, logical module, or software that implements some or all of the functions of the first device.

[0058] Alternatively, the communication device may be the second device in the second aspect above, or a node including the second device above, or a module in the second device in the second aspect above, such as a chip, a chip system or a circuit, or a logical node, logical module or software that can realize part or all of the functions of the second device.

[0059] The communication device includes modules, units, or means corresponding to the above-mentioned method, which can be implemented by hardware, software, or hardware executing corresponding software implementation. The hardware or software includes one or more modules or units corresponding to the above-mentioned functions.

[0060] In conjunction with the third aspect above, in one possible implementation, the communication device may include a processing module and a transceiver module. The processing module may be configured to implement the processing functions described in any of the above aspects and any possible implementations thereof. The processing module may, for example, be a processor. The transceiver module, also referred to as a transceiver unit, may be configured to implement the transmitting and / or receiving functions described in any of the above aspects and any possible implementations thereof. The transceiver module may be comprised of a transceiver circuit, a transceiver, a transceiver, or a communication interface.

[0061] In combination with the third aspect above, in a possible implementation, the transceiver module includes a sending module and a receiving module, which are respectively used to implement the sending and receiving functions in any of the above aspects and any possible implementations thereof.

[0062] In a fourth aspect, a communication device is provided, comprising: a processor; the processor is configured to be coupled to a memory, read instructions from the memory, and then execute the method described in any of the above aspects according to the instructions. The communication device may be the first device described in the first aspect and any possible implementation thereof, or a node including the first device, or a module in the first device, such as a chip, chip system, or circuit, or a logical node, logical module, or software that implements some or all of the functions of the first device.

[0063] Alternatively, the communication device may be the second device in the above-mentioned second aspect and any possible implementation thereof, or a node including the above-mentioned second device, or a module in the above-mentioned second device, such as a chip, a chip system or a circuit, or a logical node, logical module or software that can realize part or all of the functions of the second device.

[0064] In combination with the fourth aspect above, in a possible implementation, the communication device further includes a memory, which is used to store necessary program instructions and data.

[0065] In conjunction with the fourth aspect above, in one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0066] In a fifth aspect, a communication device is provided, comprising: a processor and an interface circuit; the interface circuit is configured to receive a computer program or instruction and transmit it to the processor; and the processor is configured to execute the computer program or instruction, so that the communication device performs the method described in any of the above aspects. The communication device may be the first device described in the first aspect and any possible implementation thereof, or a node including the first device, or a module in the first device, such as a chip, chip system, or circuit, or a logical node, logical module, or software capable of implementing some or all of the functions of the first device.

[0067] Alternatively, the communication device may be the second device in the above-mentioned second aspect and any possible implementation thereof, or a node including the above-mentioned second device, or a module in the above-mentioned second device, such as a chip, a chip system or a circuit, or a logical node, logical module or software that can realize part or all of the functions of the second device.

[0068] In conjunction with the fifth aspect above, in one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0069] In a sixth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a computer, the method described in any one of the above aspects is executed.

[0070] In a seventh aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the method described in any one of the above aspects to be executed.

[0071] In an eighth aspect, a communication system is provided, which includes a first device for executing the method described in any possible implementation of the first aspect, and a second device for executing the method described in any possible implementation of the second aspect.

[0072] Among them, the technical effects brought about by any possible implementation method in the second to eighth aspects can refer to the technical effects brought about by different possible implementation methods in the above-mentioned first aspect, and will not be repeated here.

[0073] It is understandable that, provided that the solutions are not contradictory, the solutions in each aspect can be combined. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] FIG1 is a schematic diagram of a process for security negotiation between a terminal and a network device;

[0075] Figures 2 to 5 are schematic diagrams of the architecture of a communication system provided in an embodiment of the present application;

[0076] FIG6 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0077] FIG7 is a flow chart of a communication method for trusted decision-making provided in an embodiment of the present application;

[0078] FIG8 is a schematic diagram of a process for a communication node to obtain input parameters according to an embodiment of the present application;

[0079] FIG9 is a schematic diagram of a communication between two parties negotiating a trust strategy according to an embodiment of the present application;

[0080] Figures 10 to 15 are flowcharts of several communication methods for trusted decision-making provided in embodiments of the present application;

[0081] FIG16 and FIG17 are flowcharts of several communication node acquisition decision modes provided in embodiments of the present application;

[0082] FIG18 is a schematic structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0083] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0084] In the following, the terms "first," "second," etc. are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the quantity of the technical features indicated. Therefore, a feature specified as "first," "second," etc. may explicitly or implicitly include one or more of the features.

[0085] In current mobile communications, security policy negotiation can be performed between terminals and network devices, including security policy negotiation between the terminal and the core network and between the terminal and the access network.

[0086] Among them, the terminal can negotiate security policies with the Access and Mobility Management Function (AMF) in the core network. Exemplarily, security policies can be negotiated in the security mode command phase of the non-access stratum (NAS) protocol. The specific process is shown in Figure 1 and may include the following steps.

[0087] Step 1: During the initial registration phase, the terminal sends the security capabilities supported by the terminal to the AMF.

[0088] Exemplarily, the security capabilities supported by the terminal may be indicated by a UE security capabilities IE information element, which may include a variety of different encryption algorithms and indication information of whether the corresponding terminal supports the algorithm.

[0089] Step 2: The AMF sends the security algorithm to the terminal based on the security capabilities supported by itself and the terminal.

[0090] The AMF can determine the security algorithm that meets the communication needs of both parties by comparing the security capabilities supported by itself and the terminal.

[0091] For example, if both the AMF and the terminal support encryption algorithm 1 and encryption algorithm 2, the algorithm with higher priority can be selected according to the algorithm priority list specified by the operator. The AMF sends a Security Mode Command message, which carries an indication of the security algorithm, which is used to declare the encryption and integrity protection algorithm provided by the network to the terminal.

[0092] Step 3: The terminal sets the encryption algorithm and integrity protection algorithm.

[0093] In addition, the security policy negotiation between the terminal and the access network is similar to the above. For example, the security policy negotiation between the terminal and the base station can be implemented through the access layer (Access Stratum, AS) security mode command / completion process. Specifically, the base station obtains the security capabilities supported by the terminal, and then determines the AS encryption and integrity protection algorithm based on its own and the security capabilities supported by the terminal, and sends a security mode command (Security Mode Command) message to the terminal, which can carry the encryption algorithm and integrity protection algorithm indication. The terminal receives and obtains the encryption and integrity protection algorithm and the random key K generated by the base station. eNodeB , obtain the encryption key; the terminal initially activates security and sends a Security Mode Complete message to the base station, and encrypted transmission can be achieved between the terminal and the base station.

[0094] In the above-mentioned security policy negotiation, the input parameters of the security policy include the security capabilities of the communication node, and the resulting security policy includes two security technologies: encryption algorithm and integrity protection. Moreover, the current security policy negotiation is static, that is, the security policy is negotiated entirely based on the operator's configuration, and cannot be dynamically set according to different scenarios and different terminal types. It cannot adaptively generate different security policies as the node scenario changes. It can be seen that the security policy generation method is single and not flexible enough.

[0095] Based on the above problems, the present application provides a communication method for trusted decision-making. By expanding the input parameters of the trusted policy and flexibly designing the decision-making party that executes the trusted decision, the trusted decision-making process is made more flexible and can meet the needs of a variety of different scenarios. The negotiation process of the trusted policy will not only exist between the terminal and the core network device, or between the terminal and the access network device, but can exist between any two communication nodes such as the terminal, the access network device, the core network element, the third-party network element, etc., and the terminal, the access network device or the core network element or the third-party network element can all have the same trusted decision-making power. Therefore, the trusted decision-making scheme designed by the present application can be used by any node among the two nodes in the trusted policy negotiation as the decision-making party.

[0096] First, a brief introduction to the technology involved in this application is given.

[0097] Node: A node in a communication network, including a terminal, access network equipment or a network element of a core network. Alternatively, a node may also include an independent node or module responsible for security, such as a trusted enabling unit (Gear), which can be used to perform trusted negotiation.

[0098] Trusted Negotiation: After two nodes establish a connection and before executing specific services, they can conduct a trusted negotiation process to determine the security technologies and algorithms to be adopted by both communicating nodes. Trusted negotiation may also be referred to as security negotiation, security algorithm negotiation, or security policy negotiation, though this application does not limit this.

[0099] Trusted decision-making: In the trusted negotiation process, a node generates a trusted policy based on the obtained parameters.

[0100] Trusted policy: Parameters ultimately determined by nodes in a communication network through trusted negotiation, used to describe the security technologies and corresponding security algorithms to be adopted.

[0101] Network policy: Trusted policy is security at the node level, and network policy is security at the network level. Network policy can be generated by network situational awareness and can be provided by specific nodes, such as core network functions (NFs) and independent nodes responsible for security functions, such as trusted engines.

[0102] Security technology: A type of security functionality, such as encryption, integrity protection, blockchain, attestation, etc.

[0103] Security algorithms: Different implementations of security technologies, such as the Zu Chongzhi Serial Cipher (ZUC) algorithm, Advanced Encryption Standard (AES), and RSA algorithms in asymmetric encryption technologies; and trusted platform modules (TPM), Software Guard Extensions (SGX), and trusted boot zones in trusted measurement technologies.

[0104] Security capabilities: The collection of security technologies and security algorithms provided by a node or communication network as a whole.

[0105] Next, the application scenarios of the embodiments of the present application are introduced. For example, the present application can be applied to the communication systems shown in Figures 2 to 4.

[0106] As shown in Figure 2, the architecture of the communication system is illustrated by taking the network service architecture of the fifth generation (5G) mobile communication system as an example, which mainly includes terminals, access networks and core networks. In the embodiments of the present application, the terminals, the nodes of the access network and the nodes of the core network are collectively referred to as network nodes. Among them, the core network is mainly responsible for maintaining the subscription data of the mobile network and providing functions such as session management, mobility management, policy management and security authentication for the terminal. The core network can be a centralized network architecture, and the NF of the core network is deployed by the management plane. The deployed NF can be called a network element or a network device. Trusted negotiation can be carried out between the network nodes shown in Figure 2, such as between NFs, between terminals and radio access network (RAN) nodes, between RANs and RANs, between RANs and NFs, etc.

[0107] In this application, a terminal is a device with wireless transceiver capabilities. The terminal can be deployed on land, including indoors, outdoors, handheld or vehicle-mounted; it can also be deployed on the water (such as ships, etc.); it can also be deployed in the air (such as airplanes, balloons and satellites, etc.). The terminal can also be called a terminal device, and the terminal device can be a user equipment (UE), a mobile station (MS), a mobile terminal (MT), etc., or a device used to provide voice or data connectivity to users. Among them, UE includes handheld devices with wireless communication capabilities, vehicle-mounted devices (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed railways, etc.), wearable devices (such as smart watches, smart bracelets, pedometers, smart glasses, etc.) or computing devices. Exemplarily, UE can be a mobile phone, a tablet computer, a laptop computer, a PDA, a mobile internet device (MID), a satellite terminal or a computer with wireless transceiver capabilities. The terminal device may also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless modem, a smart point of sale (POS) machine, customer-premises equipment (CPE), an intelligent robot, a robotic arm, workshop equipment, smart home devices (e.g., refrigerators, televisions, air conditioners, electric meters, etc.), a wireless terminal in industrial control, a wireless terminal in unmanned driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, an in-vehicle terminal, a roadside unit (RSU) with terminal functions, or an aerial device (e.g., an intelligent robot, a hot air balloon, a drone, an airplane), etc. The terminal device may also be other devices with terminal functions, for example, a terminal device may also be a device that functions as a terminal in device-to-device (D2D) communication.

[0108] In the present application, the terminal may be a terminal in an Internet of Things (IoT) system. IoT is an important part of the development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection. The terminal in the present application may be a terminal in machine type communication (MTC). The terminal of the present application may be an on-board module, on-board module, on-board component, on-board chip or on-board unit built into a vehicle as one or more components or units. The vehicle may implement the method of the present application through the built-in on-board module, on-board module, on-board component, on-board chip or on-board unit. The terminal of the present application may be a vehicle, such as a car. Therefore, the present application can be applied to vehicle networks, such as vehicle to everything (V2X), long term evolution vehicle (LTE-V), vehicle to vehicle (V2V), etc.

[0109] This application does not limit the form of the terminal. The device used to implement the terminal's functions can be a terminal; it can also be a device that supports the terminal in implementing the functions, such as a chip system. This device can be installed in the terminal or used in conjunction with the terminal. In this application, the chip system can be composed of a chip or include a chip and other discrete components.

[0110] In this application, a RAN node may be any device with wireless transceiver functions that can help a terminal achieve wireless access, such as a node in a RAN, which may also be referred to as an access network device or a network device. Including but not limited to: evolved base stations (NodeB or eNB or e-NodeB, evolutionary Node B) in long term evolution (LTE), evolved base stations (next generation eNB, ng-eNB) in next generation LTE, base stations (gNodeB or gNB) in new radio (NR), transmitting points (TP) or transmission reception points (TRP), base stations of subsequent evolution of 3GPP, next generation NodeB (gNB), base stations in systems evolved after 5G such as the sixth generation (6G) mobile communication system, base stations in future mobile communication systems, access nodes in satellite wireless fidelity (WiFi) systems, wireless relay nodes, wireless backhaul nodes, integrated access and backhaul (IAB) nodes, mobile switching centers, network equipment in non-terrestrial network (NTN) communication systems, that is, network equipment that can be deployed on high-altitude platforms or satellites. A base station can be: a macro base station, a micro base station, a pico base station, a small station, a relay station, a donor node, or a balloon station, etc. Multiple base stations can support networks using the same technology mentioned above, or they can support networks using different technologies mentioned above. A base station can include one or more co-located or non-co-located TRPs. A RAN node can also be a device that acts as a base station in D2D communication, vehicle-to-vehicle communication, drone communication, or machine communication. A RAN node can also be a wireless controller in a cloud radio access network (CRAN) scenario. A RAN node can also be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), a radio unit (RU), an RSU with base station functions, a wired access gateway, etc. A RAN node can also be a server, a wearable device, a machine communication device, or an in-vehicle device, etc. For example, the access network device in V2X technology can be an RSU.

[0111] In this application, the CU and DU may be separately configured or may be included in the same network element, such as a baseband unit (BBU). The RU may be included in a radio frequency device or radio frequency unit, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). It is understood that the CU may be classified as a network device in an access network, or as a network device in a core network, without limitation herein.

[0112] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in an open radio access network (ORAN) system, CU may also be called O-CU (open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application takes CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0113] It is understandable that in some scenarios, the roles of RAN nodes and terminals are relative. For example, a helicopter or drone, which is usually configured as a terminal, can also be configured as a mobile base station, and the device that accesses the RAN via the helicopter or drone is configured as a terminal.

[0114] In this application, the form of a RAN node is not limited. The device used to implement the functions of a RAN node can be a RAN node; it can also be a device that supports the RAN node to implement the functions, such as a chip system. The device can be installed in a RAN node or used in conjunction with a RAN node.

[0115] Exemplarily, the network elements of the core network may include but are not limited to: network slice selection function (NSSF), network exposure function (NEF), network storage function (NF repository function, NRF), policy control function (PCF), unified data management (UDM), application function (AF), edge application server discovery function (EASDF), network slice and standalone non-public network (SNPN) authentication and authorization function (NSSAAF), authentication server function (AUSF), access management function (AMF), session management function (SMF), service communication proxy (SCP) or network slice admission control function (NSACF), etc. It can be understood that the core network shown in Figure 2 is only exemplary. In specific applications, the core network may include more or less network functions than shown in Figure 2 without limitation.

[0116] In addition, the present application can also be applied to independent nodes responsible for security, such as trusted enabling units (Gear). Trusted enabling units can provide network nodes such as RAN nodes with security capabilities such as blockchain, quantum encryption, and homomorphic encryption, for example, as an all-in-one blockchain machine. As shown in Figure 3, trusted enabling units 1 and 2 negotiate a trusted policy, where trusted enabling unit 1 serves network node 1 and trusted enabling unit 2 serves network node 2.

[0117] If the security functions in the network exist as modules within network nodes, the trusted decision-making process provided by this application can also be executed by network nodes that have deployed security modules. For example, as shown in Figure 4, a trusted enabling unit module is deployed on the terminal and a trusted enabling unit module is deployed on the RAN. Trusted negotiation can be performed between network nodes containing the trusted enabling unit modules.

[0118] In one embodiment, the present application also provides a network architecture consisting of a trusted engine and a trusted enabling unit (Gear), wherein the trusted engine can provide trusted global decision-making and management information for the network, and provide trusted policy input, activation, and management of trusted services for the trusted enabling unit in a static or dynamic manner; the trusted enabling unit can provide a trusted surface enabling module for the network, accept the configuration and management of the trusted engine, and execute trusted capabilities. For example, as shown in FIG5 , the trusted engine and the trusted enabling unit can be independent nodes in the network, or, as shown in FIG4 , they can also be modules within the node.

[0119] The communication systems shown in Figures 2-5 are for illustrative purposes only and are not intended to limit the technical solutions of this application. Those skilled in the art will appreciate that, in a specific implementation, the communication system may also include other devices, and the number of RAN nodes, terminals, core network elements, or third-party nodes may be determined based on specific needs without limitation.

[0120] Optionally, each network element or device in Figures 2 to 5 of the present application may also be referred to as a communication device, which may be a general device or a dedicated device, and the present application does not make any specific limitations on this.

[0121] Optionally, the relevant functions of each network element or device in Figures 2 to 5 of the present application can be implemented by a single device, or by multiple devices, or by one or more functional modules within a single device, and this application does not impose any specific restrictions on this. It is understood that the above functions can be components in a hardware device, or software functions running on dedicated hardware, or a combination of hardware and software, or virtualized functions instantiated on a platform (e.g., a cloud platform).

[0122] In specific implementations, each network element or device in Figures 2-5 of this application may adopt the structure shown in Figure 6, or include the components shown in Figure 6. Figure 6 shows a schematic diagram of the hardware structure of a communication device applicable to this application. The communication device 60 includes at least one processor 601 and at least one communication interface 604, which are used to implement the methods provided in this application. The communication device 60 may also include a communication circuit 602 and a memory 603.

[0123] The processor 601 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0124] The communication link 602 may include a path for transmitting information between the above components, such as a bus.

[0125] Communication interface 604 is used to communicate with other devices or communication networks. Communication interface 604 can be any transceiver-like device, such as an Ethernet interface, a radio access network (RAN) interface, a wireless local area network (WLAN) interface, a transceiver, a pin, a bus, an interface circuit, or a transceiver circuit.

[0126] The memory 603 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may be independent and coupled to the processor 601 via a communication line 602. The memory 603 may also be integrated with the processor 601. The memory provided in this application may generally be non-volatile.

[0127] Among them, the memory 603 is used to store computer-executable instructions involved in executing the solution provided by this application, and the execution is controlled by the processor 601. The processor 601 is used to execute the computer-executable instructions stored in the memory 603, thereby implementing the method provided by this application. Alternatively, optionally, in this application, the processor 601 can also perform the processing-related functions of the method provided below in this application, and the communication interface 604 is responsible for communicating with other devices or communication networks, which is not specifically limited in this application.

[0128] Optionally, the computer-executable instructions in this application may also be referred to as application code, which is not specifically limited in this application.

[0129] The coupling in this application is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.

[0130] As an embodiment, the processor 601 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 6 .

[0131] As an embodiment, the communication device 60 may include multiple processors, such as processor 601 and processor 607 in FIG6 . Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0132] As an embodiment, the communication device 60 may further include an output device 605 and / or an input device 606. The output device 605 is coupled to the processor 601 and can display information in a variety of ways. For example, the output device 605 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 606 is coupled to the processor 601 and can receive user input in a variety of ways. For example, the input device 606 can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0133] It is understandable that the composition structure shown in Figure 6 does not constitute a limitation on the communication device. In addition to the components shown in Figure 6, the communication device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0134] The method provided by the present application will be described below with reference to the accompanying drawings. Each network element in the following embodiment may include the components shown in FIG6 , which will not be described in detail.

[0135] As shown in Figure 7, the present application provides a trusted decision method for performing trusted negotiation between a first device and a second device. The first device and / or the second device may be a terminal, a network device, a node with a security function, or a security module included in the terminal or network device.

[0136] As shown in FIG7 , the method may include the following steps.

[0137] 701: The first device obtains a decision mode.

[0138] In one embodiment, the decision mode can be used to indicate whether the first device serves as a decision-maker of the trusted policy. Exemplarily, the decision mode of the first device can be dynamically configured, pre-configured, or agreed upon by protocol.

[0139] Exemplarily, the decision mode may include decision-making, no decision-making, or no setting, etc. For example, the decision mode of the first device is set to decision-making, which means that the first device acts as the decision-maker of the trusted policy in the trusted decision-making process. Similarly, the decision mode of the first device is set to no decision-making, which means that the first device does not act as the decision-maker of the trusted policy in the trusted decision-making process. In addition, the decision mode of the first device corresponds to no setting, such as the decision mode is empty, which can be used to indicate that the first device can act as the decision-maker of the trusted policy in the trusted decision-making process, or it can not act as the decision-maker. In this embodiment, the decision-maker of the final trusted decision can be determined specifically according to the decision mode of the other party, or the decision-maker can be randomly determined, or the communicating parties negotiate to determine the decision-maker of the trusted decision, etc.

[0140] Alternatively, in another embodiment, the decision mode can be used to instruct the first device to determine the decision maker based on a competition mode. That is, before the first device and the second device communicate, they can determine the decision maker of the trusted decision through competition. The successful party in the competition will generate a trusted policy as the decision maker, and the unsuccessful party can obtain the trusted policy generated by the decision maker to communicate.

[0141] Exemplarily, the trusted decision-making method provided by the present application includes static decision-making or dynamic decision-making, wherein static decision-making refers to the generation of a trusted policy by both communicating parties based on preset static rules. For static decision-making, if the decision rules configured for different nodes are the same, then for the same input parameters, the obtained trusted policies are also the same. Therefore, the two parties in the trusted negotiation can determine the decision mode through static rules, such as the decision mode of the node can be sent to the node along with the trusted configuration, or the decision mode is built into the node through the configuration of the decision-maker of the trusted decision, such as the decision mode built into a certain type of node is decision-making, or the operator presets certain nodes not to make decisions through the management plane, or the two parties in the trusted negotiation do not set the decision mode.

[0142] Among them, the decision rule refers to the strategy or algorithm based on which the node generates a trusted strategy based on the input parameters. For example, if the input parameters include multiple encryption algorithms, the decision rule may include determining one or two encryption algorithms with higher priority from the multiple encryption algorithms. The decision rule can be generated by the management node in the network by sensing the security needs of the network node. The decision rules corresponding to different scenarios and different communication nodes may be different. In addition, the decision rule can also be dynamically updated. For example, a management node such as an operator can obtain the decision rule through an algorithm model such as artificial intelligence (AI) or machine learning (ML). The operator can configure the decision rule for the network node through the management plane or specific NF configuration. As the usage time and input samples increase, the model can autonomously learn and update, generate new decision rules, and update the decision rules for the network node.

[0143] Dynamic decision-making refers to the generation of a trusted policy by both communicating parties based on dynamic decision-making rules. This dynamic nature is reflected in the fact that the decision-making rules for different scenarios and different communication nodes may be different; or the initial decision-making rules of a node may be the same, but the evolution of the decision-making rules after long-term operation may be different. For dynamic decision-making, the trusted policy results obtained by the two communicating parties as decision-makers may be different. Therefore, when making a trusted decision, the decision-maker can be determined first, and then the trusted policy can be generated through negotiation. For example, the two communicating parties can first determine the decision-maker based on their respective decision-making models, and then the decision-maker can execute the trusted decision to generate the trusted policy. The specific implementation process will be introduced in conjunction with different embodiments later, and will not be repeated here.

[0144] Optionally, since the decision rules of different nodes in dynamic decision-making may be different, after generating a trusted policy, the node can also perform a verification process to verify whether the security algorithm indicated in the trusted policy is supported by all nodes participating in the trusted negotiation, or to verify whether the trusted policy meets the node's own trust requirements.

[0145] In one embodiment, the first device may obtain the decision model from the operator, or may obtain the decision model through a third device, such as a trusted engine, which may issue a specific configuration of the decision model to the first device or the second device. The configuration process of the decision model is described below and is not repeated here.

[0146] 702: The first device sends a first message to the second device based on the decision-making mode to trigger negotiation of a trusted policy.

[0147] The trusted policy is used to indicate the security technology and / or security algorithm used in the communication between the first device and the second device. Exemplarily, the first message may include a request message for starting trusted policy negotiation, which is used to indicate to the second device a request to start the trusted policy negotiation process.

[0148] 703: The first device obtains a trusted policy.

[0149] Among them, the trusted policy is obtained based on the first input parameter and the second input parameter corresponding to the second device. The first input parameter is obtained based on the trusted requirements of the first device, and the second input parameter is obtained based on the trusted requirements of the second device. The trusted requirements of the first device are used to indicate the first device's requirements for the current communication security capabilities, and the trusted requirements of the second device are used to indicate the second device's requirements for the current communication security capabilities.

[0150] That is, the trust policy adopted by the two-way communication negotiated between the first device and the second device can be obtained according to the trust requirements corresponding to the first device and the trust requirements corresponding to the second device.

[0151] Specifically, if the first device is the decision-maker of this trusted decision, then the first device can obtain a trusted policy (such as a first trusted policy) based on the decision rules according to the first input parameter corresponding to the first device and the second input parameter corresponding to the second device, and send it to the second device, or share it with the second device through the blockchain. Conversely, if the first device is not the decision-maker of this trusted decision, and the second device is the decision-maker of this trusted decision, then the second device can obtain a trusted policy (such as a second trusted policy, the first trusted policy and the second trusted policy may be the same or different) based on the decision rules according to the first input parameter corresponding to the first device and the second input parameter corresponding to the second device, and send it to the first device, or the first device obtains the trusted policy through the blockchain.

[0152] In one embodiment, the trusted requirement is used to indicate the node's own requirements for the current communication security capabilities. Therefore, the trusted requirement is provided by the node and may specifically include a security algorithm corresponding to at least one of the following security technologies: encryption, authentication, authorization, blockchain, trusted measurement, or privacy protection.

[0153] Exemplarily, the configuration of the trust requirements of the first device may be as shown in Table 1, which may include the security technologies supported by the first device and the trust requirements corresponding to each security. Exemplarily, an indication value of 1 corresponding to "whether the algorithm is supported" may indicate that the first device supports the security algorithm; and an indication value of 0 corresponding to "whether the algorithm is supported" may indicate that the first device does not support the security algorithm.

[0154] Optionally, the trusted requirements may also include the priority level of each security algorithm. If the first device supports more than two security algorithms corresponding to the security technology, the algorithm priority level may be further indicated. For example, if the indicator value for "whether this algorithm is supported" is 2, the algorithm has a higher priority than the algorithm with the indicator value of 1. Optionally, a separate field may be used to indicate the priority level of at least one algorithm.

[0155] Table 1

[0156] Optionally, the trusted requirement may further include a validity period corresponding to the trusted requirement, as shown in Table 1. Optionally, if the trusted requirement reaches or exceeds the indicated validity period, the first device may regenerate or obtain a new trusted requirement.

[0157] Among them, trusted requirements are generated in two ways:

[0158] In one possible implementation, trusted requirements are automatically generated: nodes can automatically sense the application environment and generate trusted requirements based on pre-set rules. For example, if a terminal enters a high-density user scenario (i.e., the number of terminals in the area exceeds a preset threshold), the terminal's trusted requirements can be set to lightweight encryption, decryption, and authentication algorithms, thereby improving communication efficiency. Alternatively, the terminal can detect the high-density user scenario by experiencing increased latency in communication with the base station, slower access rates to the base station, or reduced bandwidth allocated by the base station.

[0159] In another possible implementation, the trust requirements are manually generated, such as through manual configuration. For example, a terminal can obtain the user's configuration of the terminal trust requirements through a human-machine interface. For another example, a RAN node and NF can obtain the operator administrator's configuration of the RAN node and NF trust requirements through the management plane.

[0160] It is understandable that the trust requirements corresponding to a node can change dynamically. When a node communicates with different other nodes, different trust requirements may be generated. In addition, when the communication scenario or business in which the node is located changes, new trust requirements may be generated. Furthermore, if the trust requirements reach their effective time, new trust requirements may be generated.

[0161] In one embodiment, the first input parameter and / or the second input parameter refer to input parameters for a trusted decision-maker to generate a trusted policy. In the embodiment of the present application, as mentioned above, the input parameters may include trusted requirements.

[0162] Optionally, the first input parameter and / or the second input parameter may further include a trusted configuration and / or a network policy.

[0163] In one embodiment, the first input parameter is obtained based on the trusted configuration and / or network policy of the first device, wherein the trusted configuration of the first device is used to indicate the operator's configuration information on the current communication security capabilities of the first device, and the network policy of the first device is used to indicate the network's requirements for the current communication security capabilities of the first device.

[0164] In one embodiment, the trusted configuration includes at least one of the following: the granularity of the trusted negotiation, the decision-making mode, the priority of the operator-configured security algorithm, or the validity period of the trusted policy. The granularity of the trusted negotiation refers to whether the trusted policy negotiated by the communicating parties is based on a specific service, a specific device, or a specific user setting.

[0165] Illustratively, the trusted configuration of the first device may be specifically as shown in Table 2.

[0166] Table 2

[0167] Optionally, the trusted configuration is provided by the operator or generated by Operations, Administration and Maintenance (OAM). In addition, the trusted configuration can be manually configured and can be set by the operator's administrator through the management plane. In view of the possible integration of the management plane and the control plane in future communication systems, the trusted configuration can also be optionally provided by a specific node. For example, the core network sets up an NF to manage the trusted configuration and send the trusted configuration to the communicating nodes. After receiving the trusted configuration, the node can configure the node's decision mode, decision method, or method of determining the decision-maker based on the parameters included in the trusted configuration.

[0168] Optionally, the trusted configuration may be valid for a long time until the node receives a new trusted configuration from the core network. Therefore, the indication bit corresponding to the valid duration may not be set in the trusted configuration, or the valid duration may be set to the maximum value corresponding to the indication bit.

[0169] In one embodiment, the network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

[0170] Optionally, network policies can be provided by the core network NF or an independent node responsible for security functions, such as a trusted engine. Network policies can be in the form of a four-tuple, including an event, condition, scope, and behavior, as shown in Table 3. For example, the first event in Table 3 refers to the event when a node establishes a connection. The execution condition for this event includes: If the node supports trust metrics, then when this event occurs, the node type corresponding to the configuration behavior of this network policy includes: For all NFs, the configuration behavior corresponding to this event specifically sets the indicator bit corresponding to the trust metric in the trusted policy to 1. Similarly, the second network policy in Table 3 refers to the event when a user requests the use of privacy protection technology. If the node supports privacy protection, the indicator bit corresponding to the privacy protection in the trusted policy can be set to 1 for all trusted negotiations between NFs and UEs. The third network policy in Table 3 refers to the event when the network updates the blockchain function. If the node passes initial authentication, the indicator bit corresponding to the blockchain in the trusted policy can be set to 1 for all trusted negotiations between NFs, base stations, and UEs.

[0171] Table 3

[0172] Network policies are generated by nodes in the network. In one possible implementation, special functional nodes, such as an engine, are set up in the network. The engine can collect perception information through network-wide situational awareness, and then generate network policies based on the collected perception information based on artificial intelligence (AI) algorithms or expert libraries. Optionally, network policies can be generated by a single node or by collaboration of multiple nodes. In addition, network policies can generally be applied to multiple nodes. For example, a network policy generated based on NF-related information can be sent to all NFs; a network policy based on access network-related information can be sent to all RAN nodes; a network policy based on a physical area-related information can be sent to all nodes in the area.

[0173] Optionally, the network policy may further include a valid duration corresponding to the network policy, as shown in Table 3. Optionally, if the network policy reaches or exceeds the indicated valid duration, the first device may reacquire a new network policy.

[0174] Furthermore, network policies can be dynamically changing. When the network changes, such as when a node joins or leaves the network, a new network policy may be generated; when the scenario changes, a new network policy may be generated; when the duration corresponding to the network policy reaches or exceeds the effective duration configured for the network device, a new network policy can be regenerated.

[0175] In one embodiment, before the first device sends the first message to the second device, the first device may obtain a first input parameter. Specifically, the first device may obtain the first input parameter based on at least one of a trusted requirement, a trusted configuration, or a network policy, for use by a trusted decision-maker in generating a trusted policy.

[0176] When the first device obtains at least one of the trusted requirements, trusted configurations, or network policies, it may not pre-process the above parameters, but instead perform parameter fusion processing on all the above parameters to obtain first input parameters for generating a trusted policy. This method of obtaining input parameters can reduce the data processing process and reduce computing latency. Alternatively, the first device may also pre-process at least one of the obtained trusted requirements, trusted configurations, or network policies to obtain first input parameters, which are then used by the decision-maker of the trusted decision to generate a trusted policy.

[0177] Optionally, a preprocessing method is that the first device can determine alternative security algorithms and some attributes of trusted policy negotiation based on trusted requirements, trusted configuration and network policies, such as: alternative security algorithms can be determined based on trusted requirements and algorithm priorities in trusted configurations, negotiation granularity and trusted policy lifecycles can be determined based on trusted configurations, and specific security algorithms can be set based on network policies.

[0178] Exemplarily, the first input parameter obtained after preprocessing may be similar to the trusted policy structure obtained by the decision-maker, as shown in Table 4. Compared with the trusted requirements in Table 1 above, the negotiation granularity and the effective duration of the trusted policy are increased, and the security algorithms with a flag bit of 0 are eliminated; compared with the final trusted policy, more than one security algorithm is selected in the first input parameter. Since the security algorithm priority of the node security requirements and the algorithm priority of the trusted configuration may be different, two values ​​can be retained for the security algorithm in the first input parameter. For example, in the table, the priority of ZUC set in the trusted requirements is 1, and the priority set in the network policy is 2. The priority of the ZUC algorithm in the first input parameter is 1 and 2. The advantage of this method is that when the negotiating nodes pass parameters to each other, there is no need to transmit the complete three parameters, which reduces the data packets to be transmitted and reduces the transmission delay.

[0179] Table 4

[0180] It should be noted that in the embodiment of the present application, regardless of whether the two nodes of the trusted decision-making pre-process the obtained parameters, the input parameters used for trusted decision-making can be uniformly referred to as input parameters (input), such as the input parameter corresponding to the first device can be input1, and the input parameter corresponding to the second device can be input2.

[0181] For example, Figure 8 shows a flow chart of the first device obtaining the first input parameter. This process can be executed before the subsequent trusted negotiation process of this application, and will not be repeated in the subsequent embodiments.

[0182] The first device may be a communication node, or may be a trusted enabling unit 1, wherein the trusted enabling unit 1 may be an independent security node or a module within a communication node. For example, as shown in FIG8 , one of the communication nodes may be communication node 1, and the trusted enabling unit 1 may be an independent node responsible for providing security services for communication node 1. The process by which the trusted enabling unit 1 obtains the first input parameter may include the following steps.

[0183] Step 1: The trusted enabling unit 1 checks whether a valid trusted requirement is stored locally.

[0184] If the trusted enabling unit 1 does not store valid trusted requirements locally, it can obtain valid trusted requirements from the communication node 1. Optionally, if a blockchain is deployed on the network, the trusted enabling unit 1 can also obtain the trusted requirements of the node from the blockchain.

[0185] Step 2: The trusted enabling unit 1 checks whether a valid network policy is saved locally.

[0186] If the trusted enabler 1 does not have a valid network policy stored locally, it can obtain a valid network policy from the trusted engine. Alternatively, if a blockchain is deployed on the network, the trusted enabler 1 can obtain the network policy from the blockchain. As mentioned above, the trusted enabler 1 can also optionally obtain the network policy from a specific NF in the core network.

[0187] Step 3: The trusted enabling unit 1 obtains the local trusted configuration.

[0188] As mentioned above, the trusted configuration may be stored locally in the trusted enabling unit 1 through the management plane, or may be obtained from a specific NF in the core network.

[0189] Step 4: The trusted enabling unit 1 obtains a first input parameter (input 1) based on the trusted configuration, trusted requirements, and network policy.

[0190] Similarly, as shown in Figure 9, the second device can obtain a second input parameter (input2) based on the trusted configuration, trusted requirements, and network policy. The decision-maker can then obtain a trusted policy based on the first input parameter (input1) corresponding to the first device and the second input parameter (input2) corresponding to the second device. For example, the trusted policy may include the parameters shown in Table 5.

[0191] Table 5

[0192] It should be noted that the decision-maker of a trusted decision generates a trusted policy to indicate the granularity of the trusted policy, such as whether the trusted policy is user-based, device-based, or service-based. For example, a 0 indicating the negotiation granularity in the trusted policy indicates a user-based trusted policy, a 1 indicating a device-based trusted policy, and a 2 indicating a service-based trusted policy. The trusted policy also includes an identifier corresponding to the trusted policy. For example, a user-based trusted policy may provide the user ID associated with the trusted policy, a device-based trusted policy may provide the device ID associated with the trusted policy, and a service-based trusted policy may provide the service ID associated with the trusted policy. Furthermore, the trusted policy also indicates parameters such as the security algorithm to be ultimately determined by the communicating parties and the validity period of the trusted policy. For example, Table 5 shows that the trusted policy includes: the encryption algorithm is post-quantum cryptography (PQC), the authentication algorithm is IKE, the authorization algorithm is token-based, the trust measurement algorithm is the trusted platform module (TPM), privacy protection is supported, the state corresponding to the automatic service trigger is enabled, and the automatic service list corresponds to authorization and trust measurement.

[0193] Among them, for independent nodes responsible for security functions such as trusted enabling units, after trusted negotiation, usually each trusted service (such as authentication or trusted measurement, etc.) process can be triggered by the communication node sending a trusted service request to its associated trusted enabling unit, so that the trusted service can be executed between the two trusted enabling units. When the state corresponding to the automatic service trigger is started, the trusted enabling unit can automatically execute the trusted service between the two trusted enabling units according to the trusted service type in the configured automatic service list. For example, trusted enabling unit 1 can send multiple trusted service requests to trusted enabling unit 2 at one time, or send trusted service requests in sequence according to the order of the automatic service list without the need for the communication node to send a trusted service request. The automatic service list is used to configure the list of service types for the node to automatically execute trusted services.

[0194] In addition, the trust policy may also include an indication of the validity period corresponding to the trust policy. Table 5 is only a possible example of a trust policy, and this application does not make any specific limitations on this.

[0195] Optionally, the trusted policy can be dynamically changing. If a node participating in the trusted negotiation generates new input parameters or receives new input parameters, it can trigger re-trusted negotiation; or, if the decision rules of the trusted decision are updated, a new trusted negotiation process can also be executed; or, if the duration of the trusted policy reaches or exceeds the corresponding validity period, a new trusted policy can also be generated.

[0196] The following describes the specific process of trusted negotiation using the interaction between a first device and a second device as an example, in conjunction with specific embodiments. In the following embodiments, the first device and / or the second device may be a terminal, a network device, or an independent node responsible for security functions (such as a trusted enabling unit node), or a security module included in a terminal or network device (such as a trusted enabling unit module).

[0197] Example 1: Static Decision Trust Strategy

[0198] As shown in FIG10 , illustratively, the first device serves as an initiating node of the trusted decision, and the second device serves as a decision-maker of the trusted decision. The process may include the following steps.

[0199] 101: The first device sends a first message to the second device to request negotiation of a trusted policy.

[0200] The first device may first obtain a decision mode and determine that the first device is not currently a decision-maker of the trust policy. Based on the decision mode, the first device may send a first message to the second device to request negotiation of the trust policy with the second device.

[0201] Optionally, before requesting trusted negotiation, the first device may first check whether a trusted policy within its validity period is locally stored, or whether a trusted policy within its validity period corresponding to communication with the second device can be obtained from the blockchain. If it is determined that a trusted policy within its validity period cannot be obtained, the first device generates a first input parameter, or obtains the first input parameter within its validity period, and sends a first message to the second device.

[0202] Exemplarily, the first message may be a negotiation start request message. Optionally, the first message may carry a first input parameter.

[0203] In one embodiment, if the first device is an independent node responsible for security functions, before step 101 , the method further includes the following steps.

[0204] 100-1: The first node establishes a connection with the second node.

[0205] The first device is an independent node responsible for providing security services for the first node. For example, the first node can be a terminal or a network device such as a RAN node. For example, the first device is a trusted enabling unit 1, which provides security services for the first node. Similarly, the second device is an independent node trusted enabling unit 2, which provides security services for the second node.

[0206] 100 - 2 : The first node sends a trusted negotiation request to the first device, carrying identification information of the second node.

[0207] Exemplarily, the first device can calculate the identification information of the second device based on the identification information of the second node. For example, if the trusted negotiation request carries the ID of the second node, trusted enabling unit 1 can calculate the ID of trusted enabling unit 2 based on the ID of the second node. One possible approach is that both parties preconfigure that the ID of trusted enabling unit 2 can be the middle digits of the ID of the second node.

[0208] In another embodiment, if the first device is a module responsible for security functions included in the first node, such as a second node module; the second device is a module responsible for security functions included in the second node, such as a trusted enabling unit module, then before step 101, the first device and the second device can establish a connection and then trigger trusted negotiation.

[0209] 102: The second device receives the first message, obtains the second input parameter, and obtains the second trusted policy according to the first input parameter and the second input parameter.

[0210] Optionally, the decision mode configured in the second device may indicate that the second device acts as the decision maker of the trusted policy.

[0211] 103: The second device sends a second trusted policy to the first device.

[0212] Exemplarily, the second trusted policy may be carried in a response message corresponding to the first message. For example, the response message may be a negotiation complete message.

[0213] Correspondingly, the first device receives the second trusted policy from the second device, thereby obtaining the second trusted policy.

[0214] In another example, as shown in FIG11 , the first device serves as an initiating node of the trusted decision, and the first device serves as a decision-maker of the trusted decision. The process may include the following steps.

[0215] 111: The first device sends a first message to the second device to request negotiation of a trusted policy, and the second device receives the first message accordingly.

[0216] At this time, since the first device serves as the decision-maker of the trusted policy, there is no need to send the first input parameter to the second device. That is, the first message can carry the decision mode corresponding to the first device without carrying the first input parameter to save signaling overhead.

[0217] 112: The second device obtains a second input parameter and sends the second input parameter to the first device.

[0218] Exemplarily, the second device may send a response message to the first device, wherein the response message carries a second input parameter, which is used by the first device to generate a trusted policy based on the second input parameter.

[0219] 113: The first device obtains a first trusted policy according to the decision rule, the first input parameter and the second input parameter.

[0220] 114: The first device sends the first trusted policy to the second device.

[0221] Correspondingly, the second device obtains the first trusted policy.

[0222] In the above two implementations, in static decision-making, the decision rules configured by both parties participating in the trusted negotiation communication are generally the same. Then, when either party in the communication serves as the decision-maker, the generated trusted strategies are generally the same, that is, the first trusted strategy is the same as the second trusted strategy.

[0223] Example 2: Dynamic Decision-Making Trusted Strategy

[0224] As shown in FIG12 , exemplarily, the first device serves as the initiating node of the trusted decision, the decision mode corresponding to the second device is decision, and the decision mode corresponding to the first device is no decision or no setting, then the process may include the following steps.

[0225] 121: The first device sends a first message to the second device to request negotiation of a trusted policy, and the second device receives the first message accordingly.

[0226] The first device may first obtain a decision mode and determine that the first device is not currently a decision-maker for the trusted policy, or that the decision mode of the first device is not set to whether to make a decision. Based on the decision mode, the first device may send a first message to the second device, requesting negotiation of the trusted policy with the second device.

[0227] Optionally, before requesting trusted negotiation, the first device may first check whether a trusted policy within its validity period is locally stored, or whether a trusted policy within its validity period corresponding to communication with the second device can be obtained from the blockchain. If it is determined that a trusted policy within its validity period cannot be obtained, the first device generates a first input parameter and sends a first message to the second device.

[0228] Exemplarily, the first message may be a negotiate start request message. Optionally, the first message may carry first indication information for indicating a decision mode corresponding to the first device, for example, not set or not make a decision.

[0229] Further optionally, the first message may carry a first input parameter.

[0230] 122: The second device obtains a second input parameter.

[0231] Optionally, if the first message sent by the first device does not carry the first input parameter corresponding to the first device, the second device may also request the first device to obtain the first input parameter. In a possible implementation, the method may further include the following steps.

[0232] 123: The second device sends second indication information to the first device.

[0233] The second indication information is used to indicate the decision mode corresponding to the second device. Exemplarily, the decision mode of the second device at this time is decision.

[0234] 124: The first device sends the first input parameter to the second device.

[0235] Correspondingly, the first device receives second indication information from the second device, indicating that the second device serves as the decision-maker of the trusted policy. At this point, the first device may send the first input parameter to the second device. Alternatively, the first input parameter may be sent to the second device by including it in a negotiate complete message.

[0236] 125: The second device obtains a second trusted policy according to the first input parameter and the second input parameter.

[0237] Optionally, the decision mode configured for the second device may be that the second device serves as the decision-maker of the trusted policy, or the decision mode corresponding to the second device may also be configured as not set.

[0238] If the first message of the aforementioned step 121 carries the fact that the decision mode of the first device is no decision or no setting, the second device can determine that the decision-maker of this trusted decision is the second device based on the first message and the decision mode of the second device itself, and obtain the second trusted policy based on the first input parameter and the second input parameter.

[0239] If the first message of the aforementioned step 121 carries the first input parameter of the first device, the second device can determine that the decision-maker of this trusted decision is the second device based on its own decision-making model, thereby obtaining the second trusted policy based on the first input parameter and the second input parameter.

[0240] 126: The second device sends a second trusted policy to the first device.

[0241] Exemplarily, the second trusted policy may be carried in a response message corresponding to the first message. For example, the response message may be a negotiation complete message.

[0242] Correspondingly, the first device receives the second trusted policy from the second device, thereby obtaining the second trusted policy.

[0243] Optionally, the second device may check whether the security algorithm corresponding to the generated second trusted policy is a security algorithm supported by the second device, and check whether the second trusted policy meets the trust requirements of the second device. If the second device passes the verification, the first device may send the second trusted policy to the first device, and the first device will correspondingly verify the second trusted policy.

[0244] As can be seen from the foregoing, in dynamic decision-making, the trust policies generated by different nodes may be different. Therefore, the first device may also verify the obtained second trust policy to confirm whether it meets its own trust requirements.

[0245] In one embodiment, the method may further include the following steps.

[0246] 127: The first device verifies the second trusted policy.

[0247] Specifically, the first device can compare the second trusted policy with its own trusted requirements to determine whether the second trusted policy meets the first device's trusted requirements. If the verification result shows that the second trusted policy meets the first device's trusted requirements, the first device saves the second trusted policy for subsequent communication between the two parties. If the verification result shows that the second trusted policy does not meet the first device's trusted requirements, the first device can request the second device to make a new trusted decision.

[0248] For example, the first device may check whether the security algorithm included in the second trusted policy is a security algorithm supported by the first device and whether it meets the trust requirements of the first device, that is, check whether the security algorithm bit of the trust requirement corresponding to the second trusted policy is 0. Optionally, the first device may feedback the verification result to the second device.

[0249] Optionally, the method may further include the following steps.

[0250] 128: The first device sends a verification result of the second trusted policy to the second device.

[0251] In a possible implementation, in the dynamic decision mode, the corresponding decision mode can also be determined based on the random number generated by the node. There is no limitation on the way the node generates the random number, and the nodes can pre-configure or agree on a specific way to determine the decision mode based on the random number. For example, the first device generates a random number, and the decision mode can be determined as decision or no decision by the odd or even number, such as the random number is an odd number for decision, and the random number is an even number for no decision; or, the decision mode can be determined by comparing the random number with a preset threshold; or, the decision mode can be determined as decision or no decision by whether the last bit of the binary number of the random number is 0 or 1, etc. This application does not limit this.

[0252] In another example, as shown in FIG13 , illustratively, the first device serves as an initiating node of a trusted decision, and the decision mode corresponding to the first device is decision-making, then the process may include the following steps.

[0253] 131: The first device sends a first message to the second device to request negotiation of a trusted policy, and the second device receives the first message accordingly.

[0254] Further optionally, the first message may carry first indication information for indicating that the decision mode corresponding to the first device is decision making.

[0255] 132: The second device obtains a second input parameter and sends the second input parameter to the first device.

[0256] Correspondingly, the second device determines that the first device is the decision-maker based on the decision-making mode carried in the first message. Therefore, the second device can send the second input parameter to the first device, and the first device generates a trusted policy.

[0257] Optionally, if the decision mode configured for the second device can be no decision, or the decision mode corresponding to the second device can also be configured as not set.

[0258] Optionally, the second input parameter may be carried in a negotiate notify message.

[0259] 133: The first device obtains a first trusted policy according to the first input parameter and the second input parameter.

[0260] For example, the first device receives a negotiate notify message from the second device, obtains a second input parameter corresponding to the second device, and generates a first input parameter corresponding to the first device. The first device can then determine the first trusted policy based on the first input parameter and the second input parameter according to a decision rule.

[0261] 134: The first device sends the first trusted policy to the second device.

[0262] Exemplarily, the first trusted policy may be carried in a negotiate complete message.

[0263] Correspondingly, the second device receives the first trusted policy from the first device, thereby obtaining the first trusted policy.

[0264] In one embodiment, the method may further include the following steps.

[0265] 135: The second device verifies the first trusted policy.

[0266] Specifically, the second device can compare the first trust policy with its own trust requirements to determine whether the first trust policy meets the second device's trust requirements. If the verification result shows that the trust requirements of the second device are met, the second device saves the first trust policy for subsequent communication between the two parties. If the verification result shows that the trust requirements are not met, the second device can request the first device to make a new trust decision.

[0267] Optionally, the method may further include the following steps.

[0268] 136: The second device sends a verification result of the first trusted policy to the first device, and the first device receives the verification result accordingly.

[0269] Example 3: Dynamic Decision-Making Trust Strategy - Competitive Determination of Decision-Making Methods

[0270] Considering that future wireless communication networks may utilize blockchain technology, the input parameters for trusted decision-making may also be stored on blockchain nodes. Both communicating nodes can each generate a trusted strategy and determine the adopted trusted strategy through competition. The decision-making mode configured in the node can be used to instruct the first and second devices to determine the decision-maker based on the competition model.

[0271] As shown in FIG. 14 , illustratively, the first device and the second device are communicating parties and negotiate a trust policy.

[0272] 141: The first device generates a first input parameter and uploads it to the blockchain ledger.

[0273] 142: The second device generates a second input parameter and uploads it to the blockchain ledger.

[0274] Specifically, after the first device and the second device are initialized, they both generate corresponding input parameters for trusted decision-making and save them on the chain.

[0275] In one embodiment, if the first device is not a blockchain node, the first device may send the first input parameter to the blockchain node. If the first device is a blockchain node, the first device may save the first input parameter to the blockchain ledger and send it to other blockchain nodes. Similarly, after the second device generates the second input parameter, it may save the second input parameter to the blockchain ledger or send it to a blockchain node.

[0276] 143: After the trusted negotiation between the first device and the second device is triggered, the first device obtains a second input parameter corresponding to the second device from the blockchain node.

[0277] 144: After the trusted negotiation between the first device and the second device is triggered, the second device obtains the first input parameter corresponding to the first device from the blockchain node.

[0278] Optionally, when a connection is established between the first and second devices, trusted negotiation can be activated / triggered based on the established connection, or based on a trusted negotiation request issued by any node. After the trusted negotiation is triggered, the first or second device can obtain a valid trusted policy from the blockchain node. If the policy is successfully obtained, it can be used for communication between the two parties. If the policy fails, the input parameters for the trusted decision corresponding to the communication peer can be obtained from the blockchain node, such as the first device obtaining the second input parameter from the blockchain, and the second device obtaining the first input parameter from the blockchain.

[0279] 145: The first device obtains a first trusted policy based on the first input parameter and the second input parameter, and sends the first trusted policy to the blockchain node for the decision-maker of the competing trusted policy.

[0280] 146: The second device obtains a second trusted policy based on the first input parameter and the second input parameter, and sends the second trusted policy to the blockchain node for the decision-maker of the competing trusted policy.

[0281] Specifically, after the first device generates the first trusted policy, it can be verified. If the verification passes, it can be sent to the blockchain nodes for network-wide consensus. At this time, the blockchain nodes that store the ledger information can obtain the first trusted policy on the blockchain.

[0282] Exemplarily, the trusted policy may carry identification information corresponding to the trusted policy, as well as node identifiers of both communicating parties, such as the ID of the first device and the ID of the second device.

[0283] In one embodiment, when determining the decision-maker based on a competition model, the first device to be prioritized in sending the generated trusted policy to the blockchain node and publicly displaying it across the entire network is considered a successful competition. For example, as shown in FIG14 , if the first device successfully competes, then the second device fails. The second device does not need to complete a trusted decision to obtain the second trusted policy, but can instead obtain the first trusted policy through the blockchain node.

[0284] Or vice versa, optionally, if the second device successfully competes, the first device receives a notification that the second device's trusted policy successfully competes, and the first device can obtain the second trusted policy generated by the second device from the blockchain node.

[0285] In the above implementation, a competitive mechanism is used to determine the decision-making model, making trusted decision-making more automated. Nodes on both sides of the communication can compete for the right to make trusted decisions based on their own capabilities. Furthermore, because nodes handle different services at different times and scenarios change dynamically, the processing capabilities of the same node may vary at different times. For example, when a node's computing power decreases when handling emergencies, the competitive mechanism allows the same node to be either a decision-maker or non-decision-maker at different times, making dynamic decision-making more flexible and adaptable to changes in services or the environment.

[0286] Example 4: Trusted Policy Update

[0287] For static or dynamic decision-making modes, trusted policy updates include the following:

[0288] (1) The nodes participating in the trusted negotiation generate new input parameters. As mentioned above about trusted requirements, trusted configurations, or network policies, updating the input parameters of trusted decisions may be triggered by the network or generated or updated periodically.

[0289] For the static decision-making mode, if the decision rules do not change and the trusted policies obtained by different nodes executing trusted decisions may be the same, a new trusted policy can be directly generated by the node that updates the input parameters, or the communicating parties can re-execute the trusted negotiation process.

[0290] For example, if the first device updates the first input parameter, the first device can further generate a new trusted policy based on the locally stored trusted policy and the updated first input parameter. The first device can then send a negotiate update message to the second device, carrying the new trusted policy, so that the second device obtains the new trusted policy.

[0291] For the dynamic decision-making mode, since the decision-maker is determined based on the decision-making mode, and the decision-making modes obtained at different times and different nodes may be different, and the results of the dynamic decision may be different, the communicating parties can re-initiate the negotiation process.

[0292] (2) If the operator configures new decision rules through the management plane or a specific NF, the communicating parties can re-execute the trusted negotiation process. At this time, one of the nodes on the communicating parties can initiate an update process to trigger the decision-maker to generate a new trusted policy based on the updated decision rules, the valid first input parameters, and the valid second input parameters.

[0293] The valid first input parameter or the valid second input parameter may refer to an input parameter updated by the communication node, or an input parameter locally stored by the communication node and within a valid period.

[0294] (3) When the validity period of the trusted policy expires, the communicating parties can re-execute the trusted negotiation process. At this time, one of the communicating parties can initiate an update process to trigger the decision-maker to generate a new trusted policy based on the valid decision rule, the valid first input parameter, and the valid second input parameter.

[0295] The valid decision rule may refer to a decision rule updated by the communication node, or may be a decision rule stored locally and within its validity period.

[0296] Exemplarily, as shown in FIG15 , taking the first device initiating an update request as an example, the update process of the trusted policy may include the following steps.

[0297] 151: The first device sends a second message to the second device to update the trusted policy.

[0298] Optionally, the second message may be a negotiate update message.

[0299] In one embodiment, if the first device updates the first input parameter, the second message may include the first input parameter after the first device is updated, or the new trusted policy generated by the first device based on the updated first input parameter. If the node is configured with a new decision rule, the second message may include an indication to indicate that the reason for the trusted policy update is the decision rule update. Furthermore, the second message may also include a new decision rule. If the validity period of the trusted policy expires, the second message may include an indication to indicate that the reason for the trusted policy update is the expiration of the validity period.

[0300] Regarding the implementation scenario of decision rule updating, in one embodiment, the method may further include:

[0301] 150: The first device receives a notification message from the third device, indicating that a decision rule of the trusted decision is updated.

[0302] Optionally, the third device may be a trusted engine or a network-specific node NF, which sends a notification message to the node to indicate the update of the decision rule of the trusted decision.

[0303] Correspondingly, after receiving the second message, the second device determines to update the trusted policy. Based on the implementation methods provided by the present application, the trusted decision-maker can be determined based on the respective decision-making models of the communicating parties, and then the trusted negotiation process can be executed. Optionally, after obtaining the trusted policy, the node can also verify the new trusted policy. The specific process is referred to in the previous embodiment and will not be repeated here.

[0304] Exemplarily, if the second device serves as the decision-maker, the method may further include the following steps.

[0305] 152: The second device generates a new trusted policy and sends a second response to the first device.

[0306] Correspondingly, the first device may receive a second response from the second device, where the second response includes an updated trusted policy, wherein the updated trusted policy is obtained by the second device based on a valid decision rule, a valid first input parameter, and a valid second input parameter.

[0307] In one possible implementation, the update may also be initiated by the second device. For example, without receiving the second message, the second device proactively sends a second response to the first device, where the second response includes an updated trusted policy, where the updated trusted policy is obtained by the second device based on a valid decision rule, valid first input parameters, and valid second input parameters.

[0308] Example 5: Trusted Policy Verification Failure

[0309] In the dynamic decision-making mode, after the node generates a trusted policy, the two parties in the trusted negotiation can verify the trusted policy. For different situations where verification fails, this application provides the following possible handling methods:

[0310] 1. Compare the parameters in the trusted policy with those in the trusted requirements. If there are fewer mismatched parameters, or the mismatched parameters have a lower priority, the mismatched parameters can be modified directly. Optionally, a threshold value can be set for the mismatched parameters. If the number of mismatched parameters is greater than the threshold value, it is considered that there are more mismatched parameters between the trusted policy and the trusted requirements; if the number of mismatched parameters is less than or equal to the threshold value, it is considered that there are fewer mismatched parameters between the trusted policy and the trusted requirements. Alternatively, the priority of the parameters in the trusted policy and the threshold value corresponding to the priority can be set. If the priority of the mismatched parameters is less than the threshold value, it is considered that the mismatched parameters between the trusted policy and the trusted requirements have a lower priority; if the priority of the mismatched parameters is greater than or equal to the threshold value, it is considered that the mismatched parameters between the trusted policy and the trusted requirements have a higher priority.

[0311] For example, the trusted requirements of the first device include the trusted metric of using TPM, the trusted requirements of the second device do not include the trusted metric, and the generated trusted policy does not contain the trusted metric. Then there is only one mismatched parameter, namely the trusted metric. In this case, the processing method can be to add the trusted metric to the trusted policy and adopt TPM, or, for the first device whose trusted policy does not match the trusted requirements, the trusted policy can be updated to make the trusted metric effective; for the second device whose trusted policy matches the trusted requirements, the trusted policy is not updated, and the trusted metric is not effective.

[0312] 2. Compare the parameters in the trusted policy with those in the trusted requirements. If there are fewer mismatched parameters or the mismatched parameters have a lower priority, the mismatched parameters can be re-entered into the dynamic decision model to update the trusted policy.

[0313] For example, if a node's trust requirements include a TPM priority of 2 and an SGX priority of 1 in the trust metric, and there is no trust metric in the trust policy, then a sequence containing only the trust metric can be obtained based on the decision rule and the algorithm sequence of the trust metric in the first input parameter and the algorithm sequence of the trust metric in the second input parameter, and the sequence of the trust metric in the old trust policy can be replaced to obtain a new trust policy. For example, if the decision rule includes a dynamic decision model, the algorithm sequence of the trust metric in the first input parameter and the algorithm sequence of the trust metric in the second input parameter can be re-input into the dynamic decision model to obtain a sequence containing only the trust metric.

[0314] 3. Compare the trusted policy parameters with the trusted requirements. If there are many mismatched parameters, or if the mismatched parameters have a higher priority, re-obtain the decision rules (such as a dynamic decision model), input the first and second input parameters into the dynamic decision model, and regenerate the trusted policy. The decision rules can be obtained from the engine, a special hosting server, or other sources.

[0315] 4. Compare the parameters in the trusted policy with those in the trusted requirements. If there are many mismatched parameters, or the mismatched parameters have a higher priority, and the configuration parameters corresponding to the decision rule can be modified, the node can try to modify the configuration parameters corresponding to the decision rule to recalculate and generate the trusted policy.

[0316] 5. Compare the trusted policy with the parameters in the trusted requirements. If verification fails, the communicating parties can change the decision-maker, and the new decision-maker will recalculate and generate the trusted policy.

[0317] For example, the initial decision-making method is the first device. If the first trusted policy generated by the first device fails to be verified by the second device, then the decision-maker can be changed to the second device, and the second device generates a second trusted policy. The first device obtains the second trusted policy and verifies whether it meets the trusted requirements.

[0318] The above-mentioned embodiments of the present application can improve the flexibility of the trusted negotiation process and enhance communication efficiency by flexibly handling trusted policies that fail verification.

[0319] The following examples illustrate possible implementations of node acquisition decision modes. For example, a node can acquire a decision mode in the following ways: the node can proactively apply for a decision mode, or the trusted engine or management plane can configure the decision mode for the node.

[0320] Method 1: Actively apply for decision-making mode.

[0321] For example, as shown in FIG16 , the first device may request a configuration decision mode from a third device. Optionally, the third device may be a trusted engine or a network-specific node NF. The first device may be a terminal, a network device, or an independent trusted enabler node, or may be a trusted enabler module within a terminal or network device.

[0322] Step 1: The first device sends a decision mode request message to the third device.

[0323] Among them, the decision mode request message can carry: the requested decision mode, node type (terminal, base station or core network element NF, etc.), and capability information of the first device (such as computing power, storage capacity or connection capacity, etc.).

[0324] Optionally, before step 1, a third device, such as an engine, may collect the decision mode preferences of other nodes, i.e., the requested decision mode types. For example, the third device may send a decision mode preference collection message to the first device, so that when the first device sends a decision mode request message to the third device, the message may carry the requested decision mode type. For example, the first device may request the third device to configure the decision mode to decision.

[0325] Step 2: The third device sends a decision mode response message to the first device.

[0326] Correspondingly, after the third device receives the decision mode request message from the first device, it can determine whether to configure the decision mode for the first device based on the situation of the first device and the network, and then send a decision mode response message to the first device, wherein the decision mode response message can carry an indication of the success or failure of configuring the decision mode.

[0327] Exemplarily, if the third device determines to configure a decision mode for the first device, optionally, the decision mode response message may also include an indication corresponding to the decision mode configured by the third device for the first device, such as indicating that the configured decision mode is decision, no decision, competition, or not set, etc.

[0328] In one embodiment, a node may execute a decision-making mode application process before trusted negotiation. For example, during the registration process of a trusted enabler with a trusted engine, the trusted enabler may include a decision-making mode request message in a registration request message, including, for example, the requested decision-making mode, node type, and trusted enabler capability information. The registration response message fed back by the trusted engine to the trusted enabler may include a decision-making mode response message, including, for example, the configuration result of the decision-making mode.

[0329] Method 2: Trusted engine or specific network node configuration decision mode.

[0330] The trusted engine or network specific node NF can configure the decision mode for the node. For example, as shown in FIG17 , the trusted engine configuration decision mode can include the following steps.

[0331] Step 1: The trusted engine sends a decision mode configuration message to the first device.

[0332] The decision mode configuration message may include the decision mode configured by the trusted engine for the first device.

[0333] Step 2: The first device sends a decision mode configuration completion message to the trusted engine.

[0334] The decision mode configuration completion message may carry an indication of success or failure of the decision mode configuration.

[0335] In one embodiment, the node may execute a process for configuring the decision mode before trusted negotiation. For example, in the process of the trusted enabling unit registering with the trusted engine, the registration response message fed back by the trusted engine to the trusted enabling unit may include the decision mode; alternatively, the decision mode may also be configured in the management process of the trusted engine for the trusted enabling unit.

[0336] In the above implementation, the network can configure the decision mode for the communication node. Optionally, it can also configure it according to the decision mode expected by the communication node, so that the trusted decision of the communicating parties can be flexibly set to improve communication efficiency and communication security.

[0337] The various embodiments mentioned above in this application can be combined without limitation if there is no contradiction between the solutions.

[0338] The above primarily describes the solution provided by this application from the perspective of interaction between various network elements. Accordingly, this application also provides a communication device, which may be the first device in the above-described method embodiment, or a component that can be used in the first device; alternatively, the communication device may be the second device in the above-described method embodiment, or a node that includes the second device, or a component that can be used in the second device. It will be understood that, in order to implement the aforementioned functions, the first device or the second device, etc., include hardware structures and / or software modules that perform the respective functions. Those skilled in the art will readily appreciate that, in conjunction with the various exemplary units and algorithmic operations described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or in a hardware-driven manner by computer software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0339] It should be understood that the above description uses only the first device or the second device as an example to describe the interactions between various network elements. In practice, the processing performed by the first device is not limited to being performed by a single network element, and the processing performed by the second device is not limited to being performed by a single network element. For example, the processing performed by the network device can be performed by at least one of the CU, DU, and RU.

[0340] The present application can divide the functional modules of the first device or the second device according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or software functional modules. It is understood that the division of modules in this application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0341] For example, when the functional modules are divided in an integrated manner, as shown in FIG18 , the communication device 1800 may include a processing module 1801 and an interface module 1802 .

[0342] In some embodiments, the communication device 1800 may further include a storage module (not shown in FIG. 18 ) for storing program instructions and data.

[0343] Exemplarily, the communication device 1800 may be used to implement the function of the first device in the above embodiment.

[0344] The processing module 1801 may be configured to obtain a decision-making mode, for indicating whether the first device serves as a decision-maker of a trusted policy, or for instructing the first device to determine a decision-maker based on a competition mode.

[0345] The interface module 1802 is used to send a first message to the second device based on the decision mode to trigger negotiation of a trusted policy, where the trusted policy is used to indicate the security technology and / or security algorithm used in communication between the first device and the second device.

[0346] Processing module 1801 is further configured to obtain a trusted policy, which is obtained based on a first input parameter and a second input parameter corresponding to the second device. The first input parameter is obtained based on a trusted requirement of the first device, and the second input parameter is obtained based on a trusted requirement of the second device. The trusted requirement of the first device indicates the first device's requirement for current communication security capabilities.

[0347] In one embodiment, the decision mode is used to indicate that the first device acts as a decision maker of a trusted policy, or the decision mode is used to indicate that the first device is not set as a decision maker of a trusted policy, and the first message is used to indicate the start of negotiation of a trusted policy, and the first message includes the decision mode.

[0348] In one embodiment, the interface module 1802 is further configured to receive a second input parameter from the second device. The processing module 1801 is further configured to obtain a first trusted policy based on the first input parameter, the second input parameter, and the decision rule. The interface module 1802 is further configured to send the first trusted policy to the second device.

[0349] In one embodiment, the decision mode is used to indicate that the first device does not serve as a decision-maker of the trusted policy, the first message is used to indicate the start of negotiation of the trusted policy, and the first message includes a first input parameter.

[0350] In one embodiment, the interface module 1802 is further configured to receive second indication information from the second device, for indicating that the second device serves as a decision maker of the trusted policy.

[0351] In one embodiment, the interface module 1802 is further configured to receive a second trusted policy from a second device.

[0352] In one embodiment, the trust requirement includes a security algorithm corresponding to at least one of the following security technologies: encryption, authentication, authorization, blockchain, trust measurement, or privacy protection.

[0353] In one embodiment, the trust requirement further includes a priority corresponding to the security algorithm and / or a validity period corresponding to the trust requirement.

[0354] In one embodiment, the first input parameter is obtained based on the trusted configuration and / or network policy of the first device, wherein the trusted configuration of the first device is used to indicate the operator's configuration information on the current communication security capabilities of the first device, and the network policy of the first device is used to indicate the network's requirements for the current communication security capabilities of the first device.

[0355] In one embodiment, the trusted configuration includes at least one of the following: granularity of trusted negotiation, decision mode, priority of a security algorithm configured by an operator, or validity period corresponding to a trusted policy.

[0356] In one embodiment, the network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

[0357] In one embodiment, the interface module 1802 is further configured to obtain a decision model from a third device or an operator.

[0358] In one embodiment, the decision mode is used to instruct the first device to determine the decision-maker based on the competition mode, and the interface module 1802 is also used to send the first input parameter to the blockchain node; when the trusted negotiation between the first device and the second device is triggered, the second input parameter corresponding to the second device is obtained from the blockchain node.

[0359] In one embodiment, the processing module 1801 is also used to obtain a first trusted policy based on the first input parameter, the second input parameter and the decision rule, and the interface module 1802 is also used to send the first trusted policy to the blockchain node for competing for the decision-maker of the trusted policy; or, receive a notification of successful competition of the trusted policy of the second device, and obtain the second trusted policy generated by the second device from the blockchain node.

[0360] In one embodiment, the processing module 1801 is further configured to verify whether the trust policy meets the trust requirements of the first device.

[0361] In one embodiment, the interface module 1802 is further configured to send a verification result of the trusted policy to the second device.

[0362] In one embodiment, the interface module 1802 is further configured to send a second message to the second device to update the trusted policy.

[0363] In one embodiment, the second message includes the updated first input parameter of the first device.

[0364] In one embodiment, the interface module 1802 is further configured to receive a notification message from a third device, indicating an update of a decision rule for a trusted decision.

[0365] In one embodiment, the interface module 1802 is further configured to receive a second response from the second device, where the second response includes an updated trusted policy, wherein the updated trusted policy is obtained by the second device based on a valid first input parameter and a valid second input parameter.

[0366] In one embodiment, the first device is a terminal, a network device, a node responsible for security functions, or a security module included in the terminal or the network device.

[0367] In one embodiment, the first device is an independent node responsible for security functions, and the interface module 1802 is further used to receive a trusted negotiation request from the first node, the trusted negotiation request including identification information of the second device, wherein the first device provides security services for the first node.

[0368] In one embodiment, the first device is a security module included in the first terminal or the first network device, and the interface module 1802 is further configured to establish a connection between the first device and the second device to trigger trusted negotiation.

[0369] In addition, the communication device 1800 can also be used to implement the function of the second device in the above embodiment. As shown in FIG18 , the communication device 1800 can include a processing module 1801 and an interface module 1802 .

[0370] The processing module 1801 is used to obtain a decision mode, which is used to indicate whether the second device serves as a decision maker of the trusted policy, or to instruct the second device to determine a decision maker based on a competition mode.

[0371] The interface module 1802 is used to receive a first message from the first device, where the first message is used to trigger negotiation of a trusted policy, where the trusted policy is used to indicate a security technology and / or security algorithm used in communication between the first device and the second device.

[0372] The processing module 1801 is also used to obtain a trusted policy, which is obtained based on a first input parameter corresponding to the first device and a second input parameter corresponding to the second device, wherein the first input parameter is obtained based on the trusted requirements of the first device, and the second input parameter is obtained based on the trusted requirements of the second device, and the trusted requirements of the second device are used to indicate the second device's requirements for current communication security capabilities.

[0373] In one embodiment, the decision mode is used to indicate that the second device does not serve as a decision maker of the trusted policy, or the decision mode is used to indicate that the second device is not set as a decision maker of the trusted policy, and the first message is used to indicate the start of negotiation of the trusted policy, and the first message includes the decision mode.

[0374] In one embodiment, the interface module 1802 is configured to send a second input parameter to a first device and receive a first trusted policy from the first device.

[0375] In one embodiment, the decision mode is used to instruct the second device to act as a decision maker of the trusted policy, the first message is used to instruct to start negotiating the trusted policy, and the first message includes a first input parameter.

[0376] In one embodiment, the interface module 1802 is configured to send second indication information to the first device, for indicating that the second device serves as a decision maker of the trusted policy.

[0377] In one embodiment, the processing module 1801 is further configured to obtain a second trusted policy according to the first input parameter, the second input parameter, and the decision rule; and the interface module 1802 is further configured to send the second trusted policy to the first device.

[0378] In one embodiment, the trust requirement includes a security algorithm corresponding to at least one of the following security technologies: encryption, authentication, authorization, blockchain, trust measurement, or privacy protection.

[0379] In one embodiment, the trust requirement further includes a priority corresponding to the security algorithm and / or a validity period corresponding to the trust requirement.

[0380] In one embodiment, the second input parameter is obtained based on the trusted configuration and / or network policy of the second device, wherein the trusted configuration of the second device is used to indicate the operator's configuration information on the current communication security capabilities of the second device, and the network policy of the second device is used to indicate the network's requirements for the current communication security capabilities of the second device.

[0381] In one embodiment, the trusted configuration includes at least one of the following: the granularity of the trusted negotiation, the decision mode, the priority of the security algorithm configured by the operator, or the validity period corresponding to the trusted policy.

[0382] In one embodiment, the network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

[0383] In one embodiment, the interface module 1802 is further configured to obtain the decision mode from a third device or an operator.

[0384] In one embodiment, the decision mode is used to instruct the second device to determine the decision-maker based on a competition mode, and the interface module 1802 is also used to send the second input parameter to the blockchain node; when the trusted negotiation between the first device and the second device is triggered, the first input parameter corresponding to the first device is obtained from the blockchain node.

[0385] In one embodiment, the processing module 1801 is also used to obtain a second trusted policy based on the first input parameter, the second input parameter and the decision rule, and the interface module 1802 is also used to send the second trusted policy to the blockchain node for competing for the decision-maker of the trusted policy; or, receive a notification of successful competition of the trusted policy of the first device, and obtain the first trusted policy generated by the first device from the blockchain node.

[0386] In one embodiment, the processing module 1801 is further configured to verify whether the trust policy satisfies the trust requirements of the second device.

[0387] In one embodiment, the interface module 1802 is further configured to send a verification result of the trusted policy to the first device.

[0388] In one embodiment, the interface module 1802 is further configured to receive a second message from the first device for updating the trust policy.

[0389] In one embodiment, the second message includes the updated second input parameter of the second device.

[0390] In one embodiment, the interface module 1802 is further configured to receive a notification message from a third device, indicating an update of a decision rule for a trusted decision.

[0391] In one embodiment, the interface module 1802 is further configured to send a second response to the first device, where the second response includes an updated trusted policy, wherein the updated trusted policy is obtained by the second device based on a valid first input parameter and a valid second input parameter.

[0392] In one embodiment, the second device is a terminal, a network device, a node with a security function, or a security module included in the terminal or the network device.

[0393] In one embodiment, the first device is a first terminal, a first network device, or an independent node of a security function, and the method further includes: the first device establishes a connection with the second device to trigger a trusted negotiation.

[0394] When the communication device 1800 is used to implement the functions of the first device or the second device in the above embodiments, for other functions that can be implemented by the communication device 1800, reference can be made to the relevant introduction of any embodiment shown in Figures 7 to 17, and no further details will be given.

[0395] In a simple embodiment, those skilled in the art may appreciate that the communication device 1800 may be in the form shown in Figure 6. For example, the processor 601 in Figure 6 may call the computer-executable instructions stored in the memory 603 to enable the communication device 1800 to execute the method described in the above method embodiment.

[0396] Exemplarily, the functions / implementation processes of the interface module 1802 in FIG. 18 may be implemented through the communication interface 604 in FIG. 6 .

[0397] It is understandable that one or more of the above modules or units can be implemented by software, hardware or a combination of the two. When any of the above modules or units is implemented in software, the software exists in the form of computer program instructions and is stored in a memory, and a processor can be used to execute the program instructions and implement the above method flow. The processor can be built into an SoC (system on chip) or an ASIC, or it can be an independent semiconductor chip. In addition to the core used to execute software instructions to perform calculations or processing within the processor, it can further include necessary hardware accelerators, such as field programmable gate arrays (FPGAs), programmable logic devices (PLDs), or logic circuits that implement dedicated logic operations.

[0398] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a CPU, a microprocessor, a digital signal processing (DSP) chip, a microcontroller unit (MCU), an artificial intelligence processor, an ASIC, a SoC, an FPGA, a PLD, a dedicated digital circuit, a hardware accelerator or a non-integrated discrete device, which can run the necessary software or not rely on the software to execute the above method flow.

[0399] Optionally, the present application also provides a chip system, comprising: at least one processor and an interface, wherein the at least one processor is coupled to a memory via the interface, and when the at least one processor executes a computer program or instruction in the memory, the method in any of the above method embodiments is executed. In one possible implementation, the chip system also includes a memory. Optionally, the chip system can be composed of a chip, or can include a chip and other discrete devices, which is not specifically limited in this application.

[0400] Optionally, the present application also provides a computer-readable storage medium. All or part of the processes in the above-mentioned method embodiments can be completed by a computer program to instruct the relevant hardware. The program can be stored in the above-mentioned computer-readable storage medium. When the program is executed, it can include the processes of the above-mentioned method embodiments. The computer-readable storage medium can be an internal storage unit of the communication device of any of the above-mentioned embodiments, such as a hard disk or memory of the communication device. The above-mentioned computer-readable storage medium can also be an external storage device of the above-mentioned communication device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flash card), etc. equipped on the above-mentioned communication device. Furthermore, the above-mentioned computer-readable storage medium can also include both the internal storage unit of the above-mentioned communication device and an external storage device. The above-mentioned computer-readable storage medium is used to store the above-mentioned computer program and other programs and data required by the above-mentioned communication device. The above-mentioned computer-readable storage medium can also be used to temporarily store data that has been output or is to be output.

[0401] Optionally, the present application also provides a computer program product. All or part of the processes in the above method embodiments may be completed by a computer program instructing related hardware. The program may be stored in the above computer program product, and when executed, the program may include the processes in the above method embodiments.

[0402] Optionally, the present application also provides a computer instruction. All or part of the process in the above method embodiment can be completed by the computer instruction to instruct the relevant hardware (such as a computer, processor, network device or terminal, etc.). The program can be stored in the above computer-readable storage medium or in the above computer program product.

[0403] Optionally, the present application also provides a communication system, including: the first device and the second device in the above embodiment.

[0404] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0405] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0406] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0407] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0408] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method for trusted decision making, characterized in that: Applied to a first device, the method comprises: Acquiring a decision mode, used to indicate whether the first device serves as a decision-maker of a trusted policy, or used to indicate that the first device determines a decision-maker based on a competition mode; Sending a first message to the second device based on the decision mode to trigger negotiation of a trusted policy, wherein the trusted policy is used to indicate a security technology and / or a security algorithm used for communication between the first device and the second device; Obtain a trusted policy, where the trusted policy is obtained based on a first input parameter and a second input parameter corresponding to the second device, wherein the first input parameter is obtained based on the trusted requirements of the first device, and the second input parameter is obtained based on the trusted requirements of the second device, and the trusted requirements of the first device are used to indicate the first device's requirements for current communication security capabilities.

2. The method according to claim 1, characterized in that The decision mode is used to indicate that the first device acts as a decision-maker of a trusted policy, or the decision mode is used to indicate that the first device is not set as a decision-maker of a trusted policy, and the first message is used to indicate the start of negotiation of a trusted policy, and the first message includes the decision mode.

3. The method according to claim 2, characterized in that The method further comprises: receiving a second input parameter from the second device; The obtaining of the trusted policy includes: obtaining a first trusted policy according to the first input parameter, the second input parameter and a decision rule; The method also includes sending the first trusted policy to the second device.

4. The method according to claim 1, characterized in that: The decision mode is used to indicate that the first device does not serve as a decision-maker for a trusted policy, the first message is used to indicate the start of negotiation of a trusted policy, and the first message includes the first input parameter.

5. The method according to claim 4, characterized in that The method further comprises: Second indication information is received from the second device, for indicating that the second device serves as a decision-maker of the trusted policy.

6. The method according to claim 4 or 5, characterized in that: The obtaining of the trusted strategy includes: A second trusted policy is received from the second device.

7. The method according to any one of claims 1 to 6, characterized in that: The trusted requirements include a security algorithm corresponding to at least one of the following security technologies: encryption, identity authentication, authorization, blockchain, trusted measurement or privacy protection.

8. The method according to claim 7, characterized in that The trusted requirement also includes a priority corresponding to the security algorithm and / or a validity period corresponding to the trusted requirement.

9. The method according to any one of claims 1 to 8, characterized in that: The first input parameter is obtained based on the trusted configuration and / or network policy of the first device, wherein the trusted configuration of the first device is used to indicate the operator's configuration information on the current communication security capabilities of the first device, and the network policy of the first device is used to indicate the network's requirements for the current communication security capabilities of the first device.

10. The method according to claim 9, characterized in that The trusted configuration includes at least one of the following: the granularity of the trusted negotiation, the decision mode, the priority of the security algorithm configured by the operator, or the effective time corresponding to the trusted policy.

11. The method according to claim 9 or 10, characterized in that: The network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

12. The method according to any one of claims 1 to 11, characterized in that: The acquiring the decision mode includes: acquiring the decision mode from a third device or from an operator.

13. The method according to claim 1, characterized in that The decision mode is used to instruct the first device to determine a decision-maker based on a competition mode, and the method further includes: Sending the first input parameter to a blockchain node; After the trusted negotiation between the first device and the second device is triggered, a second input parameter corresponding to the second device is obtained from the blockchain node.

14. The method according to claim 13, characterized in that The obtaining of the trusted strategy includes: A first trusted policy is obtained according to the first input parameter, the second input parameter and a decision rule, and the first The trusted policy is sent to the blockchain node for decision-makers to compete for the trusted policy; or, Receive a notification that the trusted policy competition of the second device is successful, and obtain a second trusted policy generated by the second device from the blockchain node.

15. The method according to any one of claims 1 to 14, characterized in that: The method further comprises: Verify whether the trusted policy meets the trusted requirements of the first device.

16. The method according to any one of claims 1 to 15, characterized in that: The method further comprises: Sending a verification result of the trusted policy to the second device.

17. The method according to any one of claims 1 to 16, characterized in that: The method further comprises: A second message is sent to the second device to update the trusted policy.

18. The method according to claim 17, characterized in that The second message includes the updated first input parameter of the first device.

19. The method according to claim 17, characterized in that The method further comprises: A notification message is received from a third device, indicating an update of a decision rule of a trusted decision.

20. The method according to any one of claims 1 to 19, characterized in that: The method further comprises: A second response is received from the second device, wherein the second response includes an updated trusted policy, wherein the updated trusted policy is obtained by the second device according to the valid first input parameter and the valid second input parameter.

21. The method according to any one of claims 1 to 20, characterized in that: The first device is a terminal, a network device, a node responsible for security functions, or a security module included in the terminal or the network device.

22. The method according to any one of claims 1 to 21, characterized in that: The first device is an independent node responsible for security functions, and the method further includes: A trusted negotiation request is received from a first node, wherein the trusted negotiation request includes identification information of the second device, wherein the first device provides a security service for the first node.

23. The method according to any one of claims 1 to 21, characterized in that: The first device is a security module included in a first terminal or a first network device, and the method further includes: The first device establishes a connection with the second device, triggering a trusted negotiation.

24. A communication method for trusted decision making, characterized in that: Applied to the second device, the method includes: Acquiring a decision mode, used to indicate whether the second device serves as a decision maker of a trusted policy, or used to indicate that the second device determines a decision maker based on a competition mode; receiving a first message from a first device, wherein the first message is used to trigger negotiation of a trusted policy, wherein the trusted policy is used to indicate a security technology or / and a security algorithm used for communication between the first device and the second device; Obtain a trusted policy, where the trusted policy is obtained based on a first input parameter corresponding to the first device and a second input parameter corresponding to the second device, where the first input parameter is obtained based on the trusted requirement of the first device, and the second input parameter is obtained based on the trusted requirement of the second device, and the trusted requirement of the second device is used to indicate the second device's requirement for current communication security capabilities.

25. The method according to claim 24, characterized in that The decision mode is used to indicate that the second device does not serve as a decision-maker for a trusted policy, or the decision mode is used to indicate that the second device is not set as a decision-maker for a trusted policy, and the first message is used to indicate the start of negotiation of a trusted policy, and the first message includes the decision mode.

26. The method according to claim 25, characterized in that The method further comprises: sending a second input parameter to the first device; The obtaining of the trusted strategy includes: A first trusted policy is received from the first device.

27. The method according to claim 24, characterized in that The decision mode is used to indicate that the second device serves as a decision-maker of a trusted policy, the first message is used to indicate the start of negotiation of a trusted policy, and the first message includes the first input parameter.

28. The method according to claim 27, characterized in that The method further comprises: Sending second indication information to the first device to indicate that the second device serves as a decision-maker of the trusted policy.

29. The method according to claim 27 or 28, characterized in that The obtaining of the trusted strategy includes: Obtaining a second trusted strategy according to the first input parameter, the second input parameter and a decision rule; The method also includes sending the second trusted policy to the first device.

30. The method according to any one of claims 24 to 29, characterized in that: The trusted requirements include a security algorithm corresponding to at least one of the following security technologies: encryption, identity authentication, authorization, blockchain, trusted measurement or privacy protection.

31. The method according to claim 30, characterized in that The trusted requirement also includes a priority corresponding to the security algorithm and / or a validity period corresponding to the trusted requirement.

32. The method according to any one of claims 24 to 31, characterized in that: The second input parameter is obtained based on the trusted configuration and / or network policy of the second device, wherein the trusted configuration of the second device is used to indicate the operator's configuration information on the current communication security capabilities of the second device, and the network policy of the second device is used to indicate the network's requirements for the current communication security capabilities of the second device.

33. The method according to claim 32, characterized in that The trusted configuration includes at least one of the following: the granularity of the trusted negotiation, the decision mode, the priority of the security algorithm configured by the operator, or the effective time corresponding to the trusted policy.

34. The method according to claim 32 or 33, characterized in that The network policy includes at least one of the following: an execution condition corresponding to at least one event, a node type corresponding to the network policy when the event occurs, and a configuration behavior corresponding to the event.

35. The method according to any one of claims 24 to 34, characterized in that: The acquiring the decision mode includes: acquiring the decision mode from a third device or from an operator.

36. The method according to claim 24, characterized in that The decision mode is used to instruct the second device to determine a decision-maker based on a competition mode, and the method further includes: Sending the second input parameter to the blockchain node; After the trusted negotiation between the first device and the second device is triggered, a first input parameter corresponding to the first device is obtained from a blockchain node.

37. The method according to claim 36, characterized in that The obtaining of the trusted strategy includes: Obtaining a second trusted policy according to the first input parameter, the second input parameter and the decision rule, and sending the second trusted policy to the blockchain node for the decision-maker of the competing trusted policy; or, Receive a notification that the trusted policy competition of the first device is successful, and obtain a first trusted policy generated by the first device from a blockchain node.

38. The method according to any one of claims 24 to 37, characterized in that: The method further comprises: Verify whether the trusted policy meets the trusted requirements of the second device.

39. The method according to any one of claims 24 to 38, characterized in that The method further comprises: Sending a verification result of the trusted policy to the first device.

40. The method according to any one of claims 24 to 39, characterized in that: The method further comprises: A second message is received from the first device for updating a trusted policy.

41. The method according to claim 40, characterized in that The second message includes a second input parameter updated by the second device.

42. The method according to claim 40, characterized in that The method further comprises: A notification message is received from a third device, indicating an update of a decision rule of a trusted decision.

43. The method according to any one of claims 24 to 42, characterized in that: The method further comprises: A second response is sent to the first device, where the second response includes an updated trusted policy, wherein the updated trusted policy is obtained by the second device according to the valid first input parameter and the valid second input parameter.

44. The method according to any one of claims 24 to 43, characterized in that The second device is a terminal, a network device, a node with a security function, or a security module included in the terminal or the network device.

45. The method according to any one of claims 24 to 44, characterized in that The first device is a first terminal, a first network device, or an independent node of a security function, and the method further includes: The first device establishes a connection with the second device, triggering a trusted negotiation.

46. ​​A communication device, characterized in that: The communication device includes a processor and a communication interface; wherein the communication interface is used to transmit signals, and the processor is used to execute the method as described in any one of claims 1 to 23, or execute the method as described in any one of claims 24 to 45.

47. The device according to claim 46, characterized in that The processor is configured to execute instructions stored in the memory to execute the method according to any one of claims 1 to 23, or to execute the method according to any one of claims 24 to 45.

48. The device according to claim 47, characterized in that The communication device further comprises the memory.

49. The device according to claim 46, characterized in that The processor is configured to execute the method according to any one of claims 1 to 23 or the method according to any one of claims 24 to 45 through a logic circuit.

50. A computer-readable storage medium, characterized in that The method comprises a program or an instruction, and when the program or the instruction is executed by a processor, the method according to any one of claims 1 to 45 is executed.

51. A computer program product, characterized in that When the computer program product is run on a computer or a processor, the method according to any one of claims 1 to 45 is implemented.

52. A communication system, characterized in that: The communication system comprises a first device for executing the method according to any one of claims 1 to 23, and a second device for implementing the method according to any one of claims 24 to 45.

Images