WO2023178689A1 - 安全实现方法及装置、设备、网元 - Google Patents

安全实现方法及装置、设备、网元 Download PDF

Info

Publication number
WO2023178689A1
WO2023178689A1 PCT/CN2022/083170 CN2022083170W WO2023178689A1 WO 2023178689 A1 WO2023178689 A1 WO 2023178689A1 CN 2022083170 W CN2022083170 W CN 2022083170W WO 2023178689 A1 WO2023178689 A1 WO 2023178689A1
Authority
WO
WIPO (PCT)
Prior art keywords
identification information
information
secret key
network element
service
Prior art date
Application number
PCT/CN2022/083170
Other languages
English (en)
French (fr)
Inventor
甘露
刘雪峰
邹继鹏
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to PCT/CN2022/083170 priority Critical patent/WO2023178689A1/zh
Publication of WO2023178689A1 publication Critical patent/WO2023178689A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Definitions

  • the embodiments of the present application relate to the field of mobile communication technology, and specifically relate to a security implementation method, device, equipment, and network element.
  • the three major application scenarios of the fifth generation mobile communication technology include enhanced mobile broadband (eMBB), massive machine type communications (mMTC) and ultra-high reliability and low latency communication (uRLLC).
  • enhanced mobile broadband eMBB
  • massive machine type communications mMTC
  • ultra-high reliability and low latency communication uRLLC
  • terminal IoT applications such as industrial wireless sensors, video surveillance, and wearable devices have put forward new requirements for 5G equipment such as complexity and cost reduction, size reduction, and lower energy consumption.
  • Zero-power communication technology will have significant advantages in terms of device power consumption, size and cost, and has become a hot research topic.
  • zero-power devices or other low-power devices with limited computing power these devices will not be able to support complex security functions, and therefore will not be able to support 3rd Generation Partnership Project (3GPP) devices. Authentication mechanism. Based on this, there is currently no clear solution for how zero-power devices or other low-capacity devices can perform secure operations to ensure the security of data transmission.
  • 3GPP 3rd Generation Partnership Project
  • the embodiments of this application provide a security implementation method, device, equipment, and network element.
  • the embodiment of this application provides a security implementation method, including:
  • the first network element receives the first information; the first information includes a Device Authentication Code (DAC) and/or a Service Authentication Code (SAC); the DAC is used to verify the first The association relationship between the device and at least one second device, the SAC is used to verify whether the first device and/or the at least one second device supports the service type indicated by the service identification information, and/or the first Whether the device and/or the at least one second device supports the data type indicated by the data identification information.
  • DAC Device Authentication Code
  • SAC Service Authentication Code
  • Another embodiment of the present application provides a security implementation method, including:
  • the first device sends first information; the first device is associated with at least one second device; the first information includes DAC and/or SAC; the DAC is used to verify the relationship between the first device and at least one second device.
  • the SAC is used to verify whether the first device and/or the at least one second device support the service type indicated by the service identification information, and/or the first device and/or the Whether the at least one second device supports the data type indicated by the data identification information.
  • the embodiment of the present application provides a security implementation device, which is applied to the first network element and includes:
  • a first receiving unit configured to receive first information; the first information includes DAC and/or SAC; the DAC is used to verify the association between the first device and at least one second device, and the SAC For verifying whether the first device and/or the at least one second device supports the service type indicated by the service identification information, and/or whether the first device and/or the at least one second device supports data Identifies the data type indicated by the information.
  • An embodiment of the present application provides a security implementation device, applied to a first device, where the first device is associated with at least one second device; including:
  • the second sending unit is configured to send first information; the first information includes DAC and/or SAC; DAC is used to verify the association between the first device and at least one second device, and SAC is used to verify all Whether the first device and/or the at least one second device supports the service type indicated by the service identification information, and/or whether the first device and/or the at least one second device supports the service type indicated by the data identification information. type of data.
  • the first network element provided by the embodiment of the present application includes a processor and a memory.
  • the memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute the above security implementation method.
  • the first device provided by the embodiment of the present application includes a processor and a memory.
  • the memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute the above security implementation method.
  • the chip provided by the embodiment of this application is used to implement the above security implementation method.
  • the chip includes: a processor for calling and running a computer program from the memory, so that the device equipped with the chip executes the above-mentioned security implementation method.
  • the computer-readable storage medium provided by the embodiment of the present application is used to store a computer program.
  • the computer program causes the computer to execute the above security implementation method.
  • the computer program product provided by the embodiment of the present application includes computer program instructions, which cause the computer to execute the above security implementation method.
  • the computer program provided by the embodiment of the present application when run on a computer, causes the computer to execute the above security implementation method.
  • the first device can send the first information; the first device is associated with at least one second device; the first information includes the device binding verification code DAC, and/ Or, service verification code SAC; DAC is used to verify the association between the first device and the at least one second device, and SAC is used to verify whether the first device and/or the at least one second device Support the service type indicated by the service identification information, and/or whether the first device and/or the at least one second device support the data type indicated by the data identification information. That is to say, the second device can use the computing and/or communication mechanism of the first device to implement secure computing and improve data transmission security.
  • Figure 1 is a schematic diagram of the network architecture of an exemplary communication system provided by an embodiment of the present application
  • FIG. 2 is a schematic flowchart 1 of a security implementation method provided by an embodiment of the present application.
  • Figure 3 is a schematic flow chart 2 of a security implementation method provided by an embodiment of the present application.
  • Figure 4 is a schematic flow chart 3 of a security implementation method provided by an embodiment of the present application.
  • Figure 5 is a schematic flow chart 4 of a security implementation method provided by an embodiment of the present application.
  • Figure 6 is a schematic flow chart 5 of a security implementation method provided by an embodiment of the present application.
  • Figure 7 is a schematic structural diagram of a security implementation device 700 provided by an embodiment of the present application.
  • Figure 8 is a schematic structural diagram of a security implementation device 800 provided by an embodiment of the present application.
  • Figure 9 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • Figure 10 is a schematic structural diagram of a chip according to an embodiment of the present application.
  • Figure 11 is a schematic block diagram of a communication system provided by an embodiment of the present application.
  • Figure 1 is a schematic diagram of an application scenario according to the embodiment of the present application.
  • the communication system 100 may include a terminal device 110 and a network device 120 .
  • the network device 120 may communicate with the terminal device 110 through the air interface. Multi-service transmission is supported between the terminal device 110 and the network device 120.
  • LTE Long Term Evolution
  • TDD Time Division Duplex
  • UMTS Universal Mobile Telecommunication System
  • IoT Internet of Things
  • NB-IoT Narrow Band Internet of Things
  • eMTC enhanced Machine-Type Communications
  • 5G communication system also known as New Radio (NR) communication system
  • NR New Radio
  • the network device 120 may be an access network device that communicates with the terminal device 110 .
  • the access network device may provide communication coverage for a specific geographical area and may communicate with terminal devices 110 (eg, UEs) located within the coverage area.
  • terminal devices 110 eg, UEs
  • the network device 120 may be an evolutionary base station (Evolutional Node B, eNB or eNodeB) in a Long Term Evolution (LTE) system, or a next generation radio access network (Next Generation Radio Access Network, NG RAN) equipment, It may be a base station (gNB) in an NR system, or a wireless controller in a Cloud Radio Access Network (CRAN), or the network device 120 may be a relay station, access point, vehicle-mounted device, or wearable device. Equipment, hubs, switches, bridges, routers, or network equipment in the future evolved Public Land Mobile Network (Public Land Mobile Network, PLMN), etc.
  • Evolutional Node B, eNB or eNodeB in a Long Term Evolution (LTE) system
  • NG RAN Next Generation Radio Access Network
  • gNB base station
  • CRAN Cloud Radio Access Network
  • the terminal device 110 may be any terminal device, including but not limited to terminal devices that are wired or wirelessly connected to the network device 120 or other terminal devices.
  • the terminal device 110 may refer to an access terminal, user equipment (UE), user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication Device, user agent, or user device.
  • Access terminals can be cellular phones, cordless phones, Session Initiation Protocol (SIP) phones, IoT devices, satellite handheld terminals, Wireless Local Loop (WLL) stations, Personal Digital Assistants (Personal Digital Assistant) , PDA), handheld devices with wireless communication functions, computing devices or other processing devices connected to wireless modems, vehicle-mounted devices, wearable devices, terminal devices in 5G networks or terminal devices in future evolution networks, etc.
  • SIP Session Initiation Protocol
  • WLL Wireless Local Loop
  • PDA Personal Digital Assistants
  • handheld devices with wireless communication functions computing devices or other processing devices connected to wireless modems
  • vehicle-mounted devices wearable devices
  • terminal devices in 5G networks or terminal devices in future evolution networks etc.
  • the terminal device 110 can be used for device to device (Device to Device, D2D) communication.
  • D2D Device to Device
  • the wireless communication system 100 may also include a core network device 130 that communicates with the base station.
  • the core network device 130 may be a 5G core network (5G Core, 5GC) device, such as an access and mobility management function (Access and Mobility Management Function). , AMF), for example, Authentication Server Function (AUSF), for example, User Plane Function (UPF), for example, Session Management Function (Session Management Function, SMF).
  • AMF Access and Mobility Management Function
  • AUSF Authentication Server Function
  • UPF User Plane Function
  • Session Management Function Session Management Function
  • SMF Session Management Function
  • the core network device 130 may also be an Evolved Packet Core (EPC) device of the LTE network, for example, a session management function + core network data gateway (Session Management Function + Core Packet Gateway, SMF + PGW- C) Equipment.
  • EPC Evolved Packet Core
  • SMF+PGW-C can simultaneously realize the functions that SMF and PGW-C can realize.
  • the above-mentioned core network equipment may also be called by other names, or a new network entity may be formed by dividing the functions of the core network, which is not limited by the embodiments of this application.
  • Various functional units in the communication system 100 can also establish connections through next generation network (NG) interfaces to achieve communication.
  • NG next generation network
  • the terminal device establishes an air interface connection with the access network device through the NR interface for transmitting user plane data and control plane signaling; the terminal device can establish a control plane signaling connection with the AMF through the NG interface 1 (referred to as N1); access Network equipment, such as the next generation wireless access base station (gNB), can establish user plane data connections with UPF through NG interface 3 (referred to as N3); access network equipment can establish control plane signaling with AMF through NG interface 2 (referred to as N2) connection; UPF can establish a control plane signaling connection with SMF through NG interface 4 (referred to as N4); UPF can exchange user plane data with the data network through NG interface 6 (referred to as N6); AMF can communicate with SMF through NG interface 11 (referred to as N11) SMF establishes a control plane signaling connection; SMF can establish a control plane signaling connection with PCF through NG interface 7 (referred to as N7).
  • N1 AMF through the NG interface 1
  • access Network equipment such as the next generation wireless
  • Figure 1 exemplarily shows an access network device, a core network device and two terminal devices.
  • the wireless communication system 100 may include multiple base station devices and the coverage of each base station may include other
  • the number of terminal devices is not limited in the embodiments of this application.
  • FIG. 1 only illustrates the system to which the present application is applicable in the form of an example.
  • the method shown in the embodiment of the present application can also be applied to other systems.
  • system and “network” are often used interchangeably herein.
  • the term “and/or” in this article is just an association relationship that describes related objects, indicating that three relationships can exist. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and they exist alone. B these three situations.
  • the character "/" in this article generally indicates that the related objects are an "or” relationship.
  • the "instruction” mentioned in the embodiments of this application may be a direct instruction, an indirect instruction, or an association relationship.
  • A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association between A and B. relation.
  • the "correspondence" mentioned in the embodiments of this application can mean that there is a direct correspondence or indirect correspondence between the two, it can also mean that there is an associated relationship between the two, or it can mean indicating and being instructed. , configuration and configured relationship.
  • predefined can refer to what is defined in the protocol.
  • protocol may refer to a standard protocol in the communication field, which may include, for example, LTE protocol, NR protocol, and related protocols applied in future communication systems. This application does not limit this. .
  • Zero-power communication technology will have significant advantages in terms of device power consumption, size and cost. For example, zero-power communication technology is expected to reduce device power consumption from tens of milliwatts of Narrow Band Internet of Things (NB-IoT) devices to tens of microwatts or even microwatts. ; In terms of cost, it is expected to reduce the equipment cost from more than a dozen yuan for the cheapest NB-IoT equipment to 1 yuan or even less.
  • the main feature of zero-power communication technology is to achieve backscatter communication by modulating incoming wave signals. At the same time, it can also obtain energy through energy harvesting to drive digital logic circuits or chips (such as micro control units or sensor chips) to achieve signal processing. Functions such as encoding, encryption or simple calculations.
  • the conversion efficiency of radio frequency energy in zero-power communication technology is often less than 10%, which determines that the power consumption requirements for driving digital logic circuits or chips for calculation cannot be too high.
  • the number of calculations that can be used for each microjoule of energy has increased, but it still cannot satisfy complex calculations.
  • the computing capabilities of zero-power terminal devices are very limited and cannot support security functions such as those defined by SHA-256, let alone the authentication mechanism of 3GPP. Therefore, it is necessary to design a lightweight group certificate mechanism for zero-power devices to authorize uplink data transmission, prevent attackers or pseudo base stations from maliciously triggering the uplink data transmission of zero-power devices, and ensure the uplink data transmission of zero-power devices.
  • the security of transmitted data improves the efficiency of zero-power device authorization.
  • the embodiment of this application provides a security implementation method, as shown in Reference 2.
  • the method includes but is not limited to the following steps:
  • Step 210 The first device sends the first information; the first information may include the device binding verification code DAC and/or the service verification code SAC; where the DAC is used to verify the connection between the first device and at least one second device.
  • the SAC is used to verify whether the first device and/or at least one second device supports the service type indicated by the service identification information, and/or whether the first device and/or at least one second device supports the data identification information indication. data type.
  • Step 220 The first network element receives the first information.
  • the first device may be a device that supports the device authentication mechanism algorithm.
  • the first device may be a UE, a base station, or other devices that can support complex operations. This embodiment of the present application does not limit this.
  • the second device may be a device with low computing power that does not support the device authentication mechanism algorithm, that is, the second device is a device that cannot perform secure computing alone.
  • the second device may be a zero power device (Zero Power Device, ZPD). Or a low-capacity device with weak computing power, or a device with less remaining power, which is not limited in the embodiment of the present application.
  • ZPD Zero Power Device
  • the first network element may be a device located in the network.
  • the first network element may be an application server or device ID management server provided by the manufacturer of at least one second device, or it may be an access network device (such as a base station) or a core network device provided by an operator, or it may be Server or device ID management server provided by the service provider (SP).
  • SP service provider
  • the second device may communicate with the first device through a technology that modulates incoming wave signals to achieve backscattering.
  • the first device may be associated with one or more second devices. It should be understood that the first device is a device that supports a device authentication mechanism, and at least one second device associated with the first device can utilize the computing and/or communication mechanism of the first device to implement secure computing.
  • the first device may send the first information to the first network element, and carry the DAC and/or SAC through the first information.
  • the first network element can verify at least one second device associated with the first device based on the DAC and/or SAC in the first information, so as to facilitate data interaction with the at least one second device, or the first network element
  • the element may generate an authorization credential for at least one second device based on the DAC and/or SAC to ensure the security of data transmission by the second device.
  • the first information may be sent directly by the first device to the first network element, or may be forwarded by the first device to the first network element through other intermediate devices.
  • the first device may directly send the first information to the first network element.
  • the first network element is an application server or a device ID management server
  • the first device can forward the above-mentioned first information to the first network element through the access network equipment and/or core network equipment provided by the operator.
  • the first network element can verify whether an association relationship truly exists between the first device and the at least one second device based on the DAC, thereby determining whether the at least one second device can be trusted.
  • the first network element may verify, based on the SAC, whether the service type supported by the first device and/or the second device is the service type indicated by the service identification information, thereby determining whether the first device and/or at least one second device has The permission to transmit data corresponding to this business type.
  • the first network element may also verify, based on the SAC, whether the data type supported by the first device and/or the second device is the data type indicated by the data identification information, thereby determining whether the first device and/or at least one second device Has the authority to transmit data corresponding to this data type.
  • the first device and/or at least one second device may provide one or more services, such as positioning service, speed measurement service, health calling service, environment monitoring service, etc.
  • This embodiment of the present application may use service identification information to indicate the service type provided by the first device and/or at least one second device.
  • the service identification information may be an ID of the service type, or may be an ID of an application server provided by the manufacturer of the first device and/or at least one second device, or an ID of an application server provided by the service provider.
  • the first network element is an application server provided by a service provider (SP)
  • the ID of the first network element is the same as the service identification information.
  • the data identification information may indicate a data type supported by the first device and/or at least one second device, and the data type includes one or more types.
  • the data types supported by the device are usually related to the services supported by the device.
  • the data type may include heart rate data, body temperature data, respiratory frequency data, exercise volume data, blood pressure data, etc.
  • the sensing service is an environment monitoring service
  • the data type may include location data, Wind speed data, temperature data, insolation data, altitude data, etc.
  • the embodiments of this application do not impose restrictions on data types.
  • the above service identification information and data identification information may be carried through the first information.
  • the service identification information and data identification information may also be pre-stored by the first network element, and this embodiment of the present application does not limit this.
  • the first device can serve as an intermediate agent for the second device, and implement secure calculations for the second device through the complete calculation and/or communication mechanism of the first device to improve data security. Transmission security.
  • the first information may be credential request information, that is, the first information may be used to request an authorization credential for at least one second device associated with the first device.
  • the first device can use its own computing and/or communication mechanism to request the authorization certificate of at least one second device associated with the network element from the network side.
  • the security implementation method provided by the embodiment of the present application may also include the following steps:
  • Step 230 If the first network element passes the verification of the DAC and/or SAC, the first network element generates an authorization certificate for at least one second device.
  • the first network element after receiving the first information, can determine through DAC that there is a real association between the first device and at least one second device, and verify the first device and/or at least one through SAC. Whether the service type supported by a second device is the service type indicated by the service identification information, and/or whether the data type supported by the first device and/or at least one second device is the data type indicated by the data identification information.
  • association relationship between the first device and at least one second device is correct only when the first network element determines that the association relationship between the first device and at least one second device is correct, and the service type supported by the first device and/or the at least one second device is specified by the service identification information.
  • the first network element generates authorization for at least one second device only when the indicated service type and/or the data type supported by the first device and/or at least one second device is the data type indicated by the data identification information. certificate.
  • the forwarding device of the first information can verify the DAC in the first information, and after passing the verification of the DAC, the forwarding device can send the first information to the first network element according to the service identification information.
  • the first network element can continue to verify the SAC, and after passing the verification of the SAC, generate at least one authorization certificate for the second device.
  • the first device can serve as an intermediate proxy device to implement security operations for at least one second device associated with the first device to obtain the authorization certificate of at least one second device.
  • the first device can be used to interact with the first network element, so that the first network element generates a lightweight authorization credential for at least one second device, so that the device can obtain business authorization and improve business security and data transmission security.
  • step 210 in the security implementation method provided by the embodiment of the present application, the following content may also be included:
  • Step 240 The first device generates the device binding verification code DAC based on the device secret key Secret;
  • the first device generates a service verification code SAC based on at least one of the identification information of the first device, the identification information of each second device, the service identification information, the data identification information, the random number NONCE, and the counter parameter COUNT.
  • the first device may calculate the device binding verification code DAC based on the following formula (1).
  • H() is the hash function or verification function or key generation function.
  • H() can be HMAC-SHA-256, or it can be the security function f1, security function f2, security function f3, security function f4 , or security function or f5, the embodiment of this application does not limit this.
  • ID UE is the identification information of the first device
  • ID ZP is the identification information of at least one second device. It should be understood that when the number of second devices includes multiple second devices, the ID ZP may include identification information of each second device in the multiple second devices.
  • S may include at least one of the following: certificate information Cert UE of the first device, random number NONCE, and counter parameter COUNT.
  • S can also include one or more of the following information: ID SP , ID DATA .
  • ID SP refers to business identification information
  • ID DATA refers to data identification information.
  • the device secret key Secret may be generated based on the service shared secret key Kservice and/or the initial secret key of each second device.
  • the service shared secret key Kservice is a symmetric secret key obtained after security negotiation between the first network element and the first device.
  • the service shared secret key Kservice may be any one of K eNB , K RRCint , K RRCenc , K NASenc , K NASint , K AF , or K s_NAF . The embodiment of the present application does not limit this.
  • step 240 the method for generating the device secret key Secret in step 240 is detailed in the description of the embodiment below and will not be described again here.
  • the first device may use the private key of the first device to identify the identification information of the first device, the identification information of at least one second device, the service identification information, the data identification information, NONCE, and Sign at least one piece of information in COUNT to obtain the business verification code SAC.
  • the first device may use the following formula (2) to generate the service verification code SAC:
  • Sig UE refers to the process of signing using the UE's private key.
  • S is an input parameter, which contains at least one or more of the following: ID ZP , ID UE , ID SP , ID DATA , NONCE, and COUNT.
  • ID ZP the number of bits in the input parameter
  • ID UE the number of bits in the input parameter
  • ID SP the number of bits in the input parameter
  • ID DATA the number of the ID DATA
  • NONCE NONCE
  • COUNT COUNT
  • the first device may, based on the service shared secret key Kservice, use the identification information of the first device, the identification information of each second device, the service identification information, the data identification information, NONCE, and At least one item in COUNT performs a safe operation and generates SAC.
  • the first device can use the following formula (3) to generate the service verification code SAC:
  • S is the input parameter, which can include one or more of the following information: ID ZP , ID UE , ID SP , ID DATA , NONCE, COUNT.
  • ID ZP , ID UE , ID SP , and ID DATA are as mentioned above and will not be described again here.
  • the first device sends the calculated DAC and/or SAC to the first network element through the first information, so that the first network element generates an authorization certificate for at least one second device associated with the first device.
  • the first network element may verify the DAC and/or SAC.
  • the following describes in detail the verification process of DAC and SAC by the first network element.
  • the first network element can verify whether there is a true association between the first device and at least one second device through DAC, and verify the first device and/or the first device through SAC. Whether the service type supported by the at least one second device is the service type indicated by the service identification information, and/or whether the data type supported by the first device and/or the at least one second device is the data type indicated by the data identification information.
  • the verification process of the DAC by the first network element is as follows:
  • the first network element can generate the first verification information based on the device secret key Secret.
  • the first network element may refer to the above formula (1) to generate the first verification information. If the first verification information is consistent with the DAC carried in the first information, it can be considered that there is a real association between the first device and at least one second device, and the first device determines that the DAC verification is passed. If the first verification information is inconsistent with the DAC carried in the first information, it is considered that the association between the first device and at least one second device is wrong or does not exist, and the first network element determines that the DAC verification fails.
  • the first network element may obtain the device secret key Secret from the first device, or may obtain the device secret key Secret from other trusted devices (such as a base station, UDM network element, application server, etc.).
  • the first network element can also generate the device secret key Secret based on the service shared secret key, and/or the initial secret key of each second device, wherein the first network element generates the device secret key Secret in the same way as the first device generates the device secret key.
  • the device secret key Secret works in the same way.
  • the method of determining the device secret key Secret is not limited in the embodiment of this application.
  • the SAC uses the private key of the first device to pair the identification information of the first device, the identification information of each second device, the service identification information, and the data identification information, NONCE, and COUNT
  • the first network element can use the public key of the first device to verify the SAC.
  • the first network element can verify the SAC through the public key of the first device to obtain the second verification information. If the second verification information is consistent with at least one piece of information including the identification information of the first device, identification information of at least one second device, service identification information, data type identification information, NONCE, and COUNT included in the first information , it is considered that the service type supported by the first device and/or at least one second device is the same as the service type indicated by the service identification information, and the data type supported by the first device and/or at least one second device is indicated by the data identification information. data type, the first network element determines that the SAC verification is passed. Otherwise, it is determined that the SAC verification fails.
  • the SAC uses the service shared secret key Kservice, the identification information of the first device, the identification information of each second device, the service identification information, the data identification information, NONCE, and COUNT At least one of them is obtained through security calculation, then the first network element can use the service shared secret key Kservice to verify the SAC.
  • the first network element may first use the service shared secret key Kservice to obtain at least one of the identification information of the first device, the identification information of each second device, the service identification information, the data identification information, NONCE, and COUNT.
  • a security operation is performed to obtain the third verification information; wherein, the first network element can refer to the above formula (3) to generate the third verification information. If the third verification information is consistent with the SAC, the first network element determines that the SAC verification is passed. Otherwise, it is determined that the SAC verification fails.
  • the forwarding device of the first information may also verify the DAC in the first information, and after passing the verification of the DAC, the forwarding device may send the first information to the first network element according to the service identification information.
  • the first network element can continue to verify the SAC, and after passing the verification of the SAC, generate at least one authorization certificate for the second device.
  • the DAC and/or SAC carried in the first information can be directly verified.
  • some operations may also be performed based on the content in the first information. Preliminary verification to avoid unnecessary DAC and/or SAC verification.
  • the first network element may maintain a device list, and the device list stores identification information of all devices supported by the first network element.
  • the first network element may determine whether the device list includes the identification information of the first device and/or the first information. Identification information of at least one second device. If the identification information of the first device and the identification information of at least one second device are not in the device list, it can be determined that the first network element does not support data transmission with the first device and/or the second device, then the first network element can No further action is performed, i.e. no complex DAC and/or SAC verification is performed. Otherwise, the first network element needs to continue with DAC and/or SAC verification.
  • the first network element may also maintain a service type list, and the service type list is used to store service types supported by the first network element.
  • the first network element may search from the service type list whether the service type corresponding to the service identification information is included. If the service type list does not include the service type, it means that the first network element does not support the service type. In this way, the first network element can avoid performing DAC and/or SAC verification.
  • the first network element can also maintain a data type list, and the data type list is used to store data types supported by the first network element.
  • the first network element may search from the data type list to see whether the data type corresponding to the data identification information is included. If the data type list does not include the data type, it means that the first network element does not support the data type. In this way, the first network element can avoid performing DAC and/or SAC verification.
  • the information in the above device list, service type list, and data type list can be obtained by the first network element by calling information stored in other database devices.
  • the first network element can determine based on the DAC and/or SAC that the first device and at least one second device have a binding relationship, and that the first device and/or the second device are bound to the service type indicated by the service identification information. It is determined that the first device and/or the second device are bound to the data type indicated by the data identification information; only under the premise that at least one of the above binding relationships is established, the first network element can generate authorization for at least one second device. Credentials, thus ensuring the security of the generated authorization credentials.
  • the first information also includes at least one of the following:
  • the first network element may also first verify the identity of the first device that sends the first information. Only after the authentication of the first device is passed, the DAC and /SAC are further authenticated. Otherwise, the identity verification of the first device fails, and the first network element may consider the device sending the first information to be an untrusted device and not respond to the first information.
  • the first network element may authenticate the first device based on the first MAC.
  • the first network element can use the service shared secret key Kservice to generate it. Verification information. If the verification information is consistent with the first MAC, it is determined that the identity verification of the first device has passed.
  • the service shared secret key Kservice pre-agreed between the first device and the first network element may be the secret key K eNB , K RRCint , K RRCenc , K NASenc , K NASint , K AF , K s_NAF , etc., this application implements There is no restriction on this.
  • the first network element can use the public key of the first device to sign the first MAC. Verification, if the verification result is consistent with other information in the first information, it is determined that the identity verification of the first device has passed. If the identity verification of the first device passes, the first network element further verifies the DAC and/or SAC to determine whether to generate an authorization certificate for at least one second device.
  • the first network element may generate an authorization certificate for at least one second device.
  • at least one second device can share an authorization credential.
  • an RSA accumulator parameter ⁇ ZP may be generated for each second device, and the RSA accumulator parameter ⁇ ZP of each second device may be used to prove that the second device whether it has been revoked.
  • the authorization certificate generated by the first network element may include at least one of the following information:
  • the public key of the first device is the public key of the first device
  • the identification information of the first network element is the identification information of the first network element
  • the digital signature may be obtained by the first network element using its own private key to sign other information in the authorization certificate. It should be understood that the digital signature can be used to verify the legitimacy of the authorization certificate.
  • the authorization certificate of the second device ZP1 can be: Cert IS->ZP ([ID ZP1 , DAC], ⁇ ZP1 , ID UE , ID IS , ID SP , SigskIS ).
  • IS refers to the first network element
  • Cert IS->ZP can be understood as the authorization certificate generated by the first network element for the second device.
  • ⁇ ZP1 is the RSA accumulator parameter of the second device ZP1
  • ID IS is the identification information of the first network element
  • sk IS is the private key of the first network element
  • Sig skIS is the digital signature of the first network element.
  • the authorization credentials of the n second devices may be: Cert IS->ZPg ([ID ZP1 ,...,ID ZPn ,DAC ], ⁇ ZP1 , ..., ⁇ ZPn , ID UE , ID IS , ID SP , Sig skIS ).
  • ⁇ ZP1 ,..., ⁇ ZPn are respectively the RSA accumulator parameters corresponding to n second devices.
  • the identification information ID IS of the first network element is the same as the service identification information ID SP , and the first network element can Use only one of them to generate authorization credentials.
  • the first network element can generate one authorization certificate for multiple second devices.
  • the authorization certificate can be a group certificate, that is, multiple second devices can share one authorization certificate.
  • the first network element may also perform steps 250 and 260.
  • Step 250 The first network element sends the authorization certificate to the blockchain node
  • Step 260 The first network element obtains the storage location information of the authorization certificate.
  • the first network element can send the generated authorization certificate of at least one second device to the blockchain node, and perform an on-chain operation on the authorization certificate of at least one second device to realize the distribution of the authorization certificate. type storage. Further, after receiving the authorization voucher, the blockchain node can store the authorization voucher in the storage block of the blockchain and feed back the storage location information to the first network element.
  • step 260 the following steps may also be included after step 260:
  • Step 270 The first network element sends the authorization voucher to the first device and/or stores the location information.
  • the first network element may send the generated authorization certificate to the requester of the certificate, that is, the first device.
  • the first network element can also send the storage location information of the authorization certificate in the storage block to the first device, and the first device and/or at least one second device can request the blockchain node according to the storage location information when needed.
  • Authorization credentials may be sent to the requester of the certificate, that is, the first device.
  • the first network element can also send the storage location information of the authorization certificate in the storage block to the first device, and the first device and/or at least one second device can request the blockchain node according to the storage location information when needed.
  • Authorization credentials may be used to send the generated authorization certificate to the requester of the certificate, that is, the first device.
  • step 240 The following describes in detail how to generate the device secret key Secret in step 240.
  • the device secret key Secret in step 240 may be calculated by the first device based on the service shared secret key Kservice and/or the initial secret key corresponding to each second device.
  • step 240 the following content may also be included before step 240:
  • Step 510 The first device generates a device secret key Secret based on the service shared secret key Kservice and/or the initial secret key of each second device in at least one second device.
  • the first device can directly generate the device secret key Secret based on the initial secret key corresponding to each second device.
  • the device secret key Secret is the initial secret key of the second device. If there are multiple second devices, the first device can aggregate the initial secret keys of each second device to obtain the device secret key Secret. Among them, the aggregation process may be a direct connection process of multiple secret keys.
  • the first device may also generate the device secret key Secret based on the initial secret key of each of the at least one second device and the service shared secret key Kservice.
  • the service shared secret key Kservice may be K eNB , K RRCint , K RRCenc , K NASenc , K NASint , K AF , K s_NAF, etc. This embodiment of the present application does not limit this.
  • the first device can directly connect the initial secret key of the second device and the service shared secret key Kservice to obtain the device secret key Secret. If there are multiple second devices, the first device can directly connect the initial secret key of each second device and the service shared secret key Kservice to obtain the device secret key Secret.
  • the first device generates the device secret key Secret based on the service shared secret key Kservice and/or the initial secret key of each of the at least one second device.
  • This can also be implemented in the following manner:
  • the first device generates an intermediate secret key for each second device based on the initial secret key of each second device;
  • the first device generates the device secret key Secret based on the service shared secret key Kservice and/or the intermediate secret key of each second device.
  • the intermediate secret key may be a symmetric secret key obtained after physical layer security negotiation between the first device and the second device and can be shared between the two devices.
  • the first device may first generate an intermediate secret key for each second device based on the initial key of each second device; then, the first device may generate an intermediate secret key for each second device based on the initial key of each second device in the at least one second device. Intermediate key, generate device secret key Secret.
  • the first device can negotiate the physical layer security mechanism with the second device based on the initial secret key of each second device, and generate intermediate secret keys corresponding to each second device. Furthermore, the first device can generate the device secret key Secret based on the intermediate secret key of each second device.
  • the device secret key Secret is the intermediate secret key of the second device. If there are multiple second devices, the first device can aggregate the intermediate secret keys of each second device to obtain the device secret key Secret. Among them, the aggregation process may be a direct connection process of multiple secret keys.
  • the first device can also first generate an intermediate secret key for each second device based on the initial key of each second device; then, the first device can generate an intermediate secret key for each second device based on the service shared key Kservice, and each second device The intermediate secret key is used to generate the device secret key Secret.
  • the device secret key Secret is the intermediate secret key of the second device. If there are multiple second devices, the first device can aggregate the service shared secret key Kservice and the intermediate secret key of each second device to obtain the above device secret key Secret.
  • the first network element can also determine the device secret key Secret through the above method. That is to say, the first network element can generate the device secret key Secret based on the service shared secret key Kservice and/or the initial secret key of each second device. Alternatively, the first network element may calculate the intermediate secret key of each second device based on the initial secret key of each second device; further, the first network element may calculate the intermediate secret key of each second device based on the service shared secret key Kservice, and/or, each second The intermediate secret key of the device generates the device secret key Secret.
  • the calculation method is the same as that described in step 510, and will not be described again here for the sake of brevity.
  • step 510 the following steps may also be performed:
  • Step 520 The first device sends key request information to the second network element; the key request information is used to request an initial key of at least one second device associated with the first device.
  • Step 530 The second network element sends initial secret key information to the first device, where the initial secret key information includes the initial secret key of each second device in the at least one second device.
  • the second network element may be a device trusted by the at least one second device, and is used to manage the initial secret key of each of the at least one second device.
  • the second network element may be a server or device ID management server provided by the manufacturer of the second device, an access network device or a core network device provided by an operator, or a service provider (SP). Server or device ID management server, the embodiment of this application does not limit this.
  • the second network element and the first network element in the above embodiments may be the same device or may be different devices, and the embodiments of the present application do not limit this.
  • the secret key request information may include at least one of the following information:
  • the identification information of the first device is the identification information of the first device
  • the second MAC corresponding to the secret key request information.
  • the second network element may feed back the initial secret key information to the first device, and the initial secret key information may carry at least one initial secret key of the second device.
  • the initial secret key information may include identification information of at least one second device and the initial secret key corresponding to each second device.
  • the initial key information may include an identification information-initial key pair, that is, (ID ZP1 , K ZP1 ). If there are multiple second devices (for example, n), the initial key information may include n identification information-initial key pairs: (ID ZP1 , K ZP1 ), (ID ZP2 , K ZP2 ), ( ID ZP3 , K ZP3 ), ..., (ID ZPn , K ZPn ).
  • ID ZP1 is the identification information of zero-power device 1
  • K ZP1 is the initial secret key of zero-power device 1
  • ID ZPn is the identification information of zero-power device n
  • K ZPn is the zero-power device The initial secret key of n.
  • the initial secret key may be a symmetric secret key
  • the second device may also store its own initial secret key in the local storage space.
  • the second network element may verify the at least one second device based on the service identification information and/or data identification information, and determine whether the at least one 2. Whether the device has the authority to use the service corresponding to the service identification information and/or data identification information. Furthermore, only after at least one second device passes the verification, the second network element sends the initial key information to the first device.
  • the second network element may determine whether the locally stored service identification information is consistent with the service identification information carried in the secret key request information, and/or whether the locally stored data identification information is consistent with the data identification information in the secret key request information. If they are consistent, the second network element determines that at least one second device has passed the verification, that is, at least one second device has the authority to use the service type corresponding to the service identification information and/or the data type corresponding to the data identification information. If they are inconsistent, the second network element determines that at least one second device fails the verification, and at least one second device does not have the authority to use the service type corresponding to the service identification information and/or the data type corresponding to the data identification information.
  • the second network element when the second network element is an application server and the service identification information is the ID of the application server, the second network element can compare its own ID with the service identification information carried in the secret key request information. If the two are the same, it is determined that at least one second device has passed the verification; otherwise, it is determined that at least one second device has failed the verification.
  • the secret key request information may include the second MAC.
  • the second network element may first authenticate the identity of the first device based on the second MAC to determine whether the first device sending the secret key request information is trustworthy. equipment.
  • the first device may use a secret key pre-negotiated with the second network element to encrypt or complete the key request information to obtain the second MAC.
  • the secret key pre-agreed between the first device and the second network element may be the secret key K eNB , K RRCint , K RRCenc , K NASenc , K NASint , K AF , K s_NAF , etc., in this embodiment of the present application, No restrictions.
  • the second network element can verify the second MAC using the secret key negotiated with the first device. For example, if the second network element is a base station, the second network element can use K eNB or K RRCint to verify the second MAC. If the second network element is an application server, the second network element can use K AF or K s_NAF to verify the second MAC. If the second network element is a core network element, the second network element can use K NASint to verify the second MAC.
  • the first device can use the private key of the first device to sign the content or part of the content of the secret key request information to obtain the second MAC.
  • the second network element can verify the second MAC using the certificate of the first device or the public key of the first device.
  • the second network element only sends the initial key information to the first device after passing the identity authentication of the first device.
  • the first device may be a UE
  • the second device may be a ZPD
  • the first network element may be an application server provided by a service provider
  • the second network element may be a base station.
  • the first information may be credential request information.
  • Step 601 The UE sends key request information to the base station.
  • the key request information is used to request initial keys for n zero-power consumption devices ZPD associated with the UE, where n is an integer greater than or equal to 1.
  • the secret key request information may include at least one of ID UE , ⁇ ID ZP1 , ..., ID ZPn ⁇ , ID SP , ID DATA , and the first MAC.
  • ID UE is the identification information of the UE
  • ID ZP1 ,..., ID ZPn are the identification information respectively corresponding to n zero-power consumption devices ZP1 to ZPn bound to the UE.
  • ID SP is business identification information
  • ID DATA is data identification information.
  • the first MAC is the information verification code of the secret key request information.
  • the UE can use the secret key K AF or K s_NAF negotiated with the base station to encrypt or complete the key request information to obtain the first MAC.
  • the UE can use its own private key to sign the content or part of the secret key request information to obtain the first MAC.
  • Step 602 The base station sends initial key information to the UE.
  • the initial key information includes n zero-power consumption device ZPD initial keys associated with the UE.
  • the initial key information may include an identification information-initial key pair, that is, (ID ZP1 , K ZP1 ). If there are multiple ZPDs (that is, n is greater than 1), the initial key information may include n identification information-initial key pairs: (ID ZP1 , K ZP1 ), (ID ZP2 , K ZP2 ), (ID ZP3 , K ZP3 ), ..., (ID ZPn , K ZPn ).
  • ID ZP1 is the identification information of zero-power device 1
  • K ZP1 is the initial secret key of zero-power device 1
  • ID ZPn is the identification information of zero-power device n
  • K ZPn is the zero-power device The initial secret key of n.
  • the initial secret key may be a symmetric secret key
  • the second device may also store its own initial secret key in the local storage space.
  • the base station can verify the n ZPDs based on the service identification information and/or data identification information, and determine whether the n ZPDs have the ability to use the service. The permissions of the business corresponding to the identification information and/or data identification information. Moreover, only after n ZPD verifications pass, the base station sends the initial key information to the UE.
  • the base station can determine whether the locally stored service identification information is consistent with the ID SP carried in the key request information, and/or determine whether the locally stored data identification information is consistent with the ID DATA carried in the key request information. If they are consistent, the base station determines that at least one second device has passed the verification and at least one second device has the authority to use the service identification information and/or data identification information corresponding to the service. If they are inconsistent, the base station determines that at least one second device has failed the verification.
  • the base station may first authenticate the identity of the UE to determine whether the UE sending the secret key request information is a trustworthy device. Further, after the identity authentication of the UE passes, the base station sends the initial key information to the UE.
  • the base station may authenticate the identity of the UE based on the first MAC.
  • the base station can use the secret key K AF or K s_NAF to verify the first MAC.
  • the base station can use the UE's certificate or the UE's public key to verify the first MAC.
  • Step 603 The UE performs initial authentication with n ZPDs respectively.
  • the UE can perform initial authentication with each ZPD based on the initial keys of each ZPD to determine that each other is a trusted device and prevent data leakage and theft.
  • the authentication process between the UE and each ZPD can refer to the authentication process in related technologies. For the sake of brevity, no details will be described here.
  • Step 604 The UE generates the device secret key Secret based on the service shared secret key Kservice and the initial secret key corresponding to each ZPD.
  • the UE can directly generate the device secret key Secret based on the service shared secret key Kservice and the initial secret key corresponding to each ZPD.
  • the device secret key Secret is the result of the aggregation of Kservice and the initial secret key of the ZPD. If the number of ZPDs includes multiple, the UE can aggregate the Kservice and the initial secret key of each ZPD to obtain the above device secret key Secret.
  • the aggregation process may be a direct connection process of multiple secret keys.
  • the UE may negotiate the physical layer security mechanism with the ZPD based on the initial key of each ZPD, and generate an intermediate key corresponding to each ZPD. Furthermore, the UE can generate the device secret key Secret based on the service shared secret key Kservice and the intermediate secret key of each ZPD.
  • the device secret key Secret is the result of aggregation of the service shared secret key Kservice and the intermediate secret key of the ZPD. If the number of ZPDs includes multiple, the UE can aggregate the service shared secret key Kservice and the intermediate secret key of each ZPD to obtain the above device secret key Secret.
  • the aggregation process may be a direct connection process of multiple secret keys.
  • Step 605 The UE generates a device binding verification code DAC and/or a service verification code SAC.
  • DAC is used to verify the association between the UE and n ZPDs
  • SAC is used to verify whether the UE and/or n ZPDs support the service type indicated by the ID SP , and/or whether the UE and/or n ZPDs support The data type indicated by ID DATA .
  • the UE can generate the device binding verification code DAC based on the device secret key Secret.
  • the UE may refer to formula (1) to calculate the DAC.
  • the UE can generate the service verification code SAC based on at least one of ID UE , ⁇ ID ZP1 , ..., ID ZPn ⁇ , ID SP , ID DATA , NONCE, and COUNT.
  • the UE can use its private key to sign at least one piece of information including ID UE , ⁇ ID ZP1 ,..., ID ZPn ⁇ , ID SP , ID DATA , NONCE, and COUNT to obtain the SAC.
  • the specific calculation method can refer to formula (2) and will not be described in detail here.
  • the UE can use the service shared secret key Kservice to encrypt and integrity protect at least one of ID UE , ⁇ ID ZP1 ,..., ID ZPn ⁇ , ID SP , ID DATA , NONCE, and COUNT to obtain SAC .
  • the specific calculation method can refer to formula (3) and will not be described in detail here.
  • Step 606 The UE sends voucher request information to the base station.
  • the voucher request information is used to request authorization vouchers for n ZPDs.
  • the credential request information may include DAC and/or SAC, and at least one of ID UE , ⁇ ID ZP1 , ..., ID ZPn ⁇ , ID SP , ID DATA , and the second MAC.
  • the second MAC may be obtained by the UE using its own private key to sign all or part of the other information in the certificate request information.
  • the second MAC is used to verify whether the sender of the voucher request information is a legitimate device.
  • the UE can directly send the voucher request information to the application server.
  • Step 607 The base station verifies the DAC in the voucher request information.
  • the base station can determine whether the UE has a real association relationship with n ZPDs through the DAC.
  • the base station may generate the first verification information based on the device secret key Secret.
  • the base station may refer to the above formula (1) to generate the first verification information. If the first verification information is consistent with the DAC in the voucher request information, it can be considered that there is a real association between the UE and n ZPDs, and the base station determines that the DAC verification is passed. If the first verification information is inconsistent with the DAC, it is considered that the association between the UE and the n ZPDs is wrong or does not exist, and the base station determines that the DAC verification fails.
  • the base station can obtain the device secret key Secret from the UE, or can also obtain the device secret key Secret from other trusted devices (such as UDM network elements, application servers, etc.).
  • the base station can also generate the device secret key Secret based on the service shared secret key Kservice and the initial secret key of each second device.
  • the embodiments of this application do not limit this.
  • Step 608 If the base station passes the DAC verification, it sends the certificate request information to the application server.
  • the base station may forward the voucher request information to the application server corresponding to the ID SP and/or ID DATA .
  • Step 609 If the SAC verification passes, the application server generates authorization credentials for n ZPDs.
  • the application server verifies through the SAC whether the service type supported by the UE and/or n ZPDs is the service type indicated by the ID SP , and/or, the UE and/or n ZPDs support Whether the data type is the data type indicated by ID DATA .
  • the application server can The SAC is verified using the UE's public key.
  • the application server can verify the SAC through the UE's public key to obtain the second verification information. If the second verification information is consistent with at least one of ID UE , ⁇ ID ZP1 ,..., ID ZPn ⁇ , ID SP , ID DATA , NONCE, and COUNT carried in the voucher request information, it is determined that the SAC verification is passed. Otherwise, it is determined that the SAC verification fails.
  • the application server can use the business shared secret key Kservice to verify the SAC.
  • the application server can first perform a secure operation on at least one piece of information including ID UE , ⁇ ID ZP1 ,..., ID ZPn ⁇ , ID SP , ID DATA , NONCE, and COUNT based on the service shared secret key Kservice, and obtain the first Three verification information; wherein, the application server can refer to the above formula (3) to generate the third verification information. If the third verification information is consistent with the SAC, the application server determines that the SAC verification is passed. Otherwise, it is determined that the SAC verification fails.
  • the application server after the application server passes the SAC verification, it can generate authorization credentials for n ZPDs.
  • the application server can generate the RSA accumulator parameter ⁇ ZP for each ZPD before generating the authorization credential.
  • the RSA accumulator parameter ⁇ ZP of each ZPD can be used to prove whether the ZPD is revoked.
  • the authorization certificate may include: at least one of ID UE , pk UE , ⁇ ID ZP1 ,..., ID ZPn ⁇ , DAC, ⁇ ZP1 ,..., ⁇ ZPn , ID SP , ID IS , ID DATA , and Sig skIS .
  • pk UE is the public key of the UE
  • ID IS is the identification information of the application server IS
  • Sig skIS is obtained by the application server using its own private key to sign other information in the above authorization certificate.
  • the authorization certificate of the ZPD can be: Cert IS->ZP ([ID ZP1 , DAC], ⁇ ZP1 , ID UE , ID IS , ID SP , Sig skIS ).
  • the ZPD authorization credential can be: Cert IS->ZPg ([ID ZP1 ,...,ID ZPn ,DAC], ⁇ ZP1 ,..., ⁇ ZPn ,ID UE ,ID IS ,ID SP ,Sig skIS ).
  • ⁇ ZP1 ,..., ⁇ ZPn are respectively the RSA accumulator parameters corresponding to n second devices.
  • the application server can use only one of them to generate the authorization certificate.
  • Step 610 The application server uploads the authorization certificate to the storage block of the blockchain node.
  • Step 611 The application server obtains the storage location information of the authorization voucher, and sends the authorization voucher and/or the storage location information of the authorization voucher to the UE.
  • the UE can serve as an intermediate proxy device to implement security operations for multiple zero-power devices associated with it, so as to obtain authorization credentials for multiple zero-power devices.
  • the UE can be used to interact with the application server, so that the application server generates lightweight group authorization credentials for multiple zero-power devices to authorize the uplink data transmission of the zero-power devices to avoid attackers.
  • the pseudo base station maliciously triggers the uplink data transmission of the zero-power device to ensure the security of the uplink transmission data of the zero-power device and improve the efficiency of authorization of the zero-power device.
  • the size of the sequence numbers of the above-mentioned processes does not mean the order of execution.
  • the execution order of each process should be determined by its functions and internal logic, and should not be used in this application.
  • the implementation of the examples does not constitute any limitations.
  • the terms “downlink”, “uplink” and “sidelink” are used to indicate the transmission direction of signals or data, where “downlink” is used to indicate that the transmission direction of signals or data is from the station.
  • uplink is used to indicate that the transmission direction of the signal or data is the second direction from the user equipment of the cell to the site
  • sidelink is used to indicate that the transmission direction of the signal or data is A third direction sent from User Device 1 to User Device 2.
  • downlink signal indicates that the transmission direction of the signal is the first direction.
  • the term “and/or” is only an association relationship describing associated objects, indicating that three relationships can exist. Specifically, A and/or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" in this article generally indicates that the related objects are an "or" relationship.
  • FIG. 7 is a schematic structural diagram of a security implementation device 700 provided by an embodiment of the present application. It is applied to the first network element. As shown in Figure 7, the security implementation device 700 includes:
  • the first receiving unit 701 is configured to receive first information; the first information includes a device binding verification code DAC and/or a service verification code SAC; the DAC is used to verify the first device and at least one second device The SAC is used to verify whether the first device and/or the at least one second device support the service type indicated by the service identification information, and/or the first device and/or the at least one second device Whether a second device supports the data type indicated by the data identification information.
  • the first information also includes at least one of the following:
  • Service identification information is used to indicate the service type supported by the first device and/or the at least one second device;
  • the service identification information is used to indicate the data type supported by the first device and/or the at least one second device;
  • the identification information of the first device is the identification information of the first device
  • the first information is used to request the at least one second device associated with the first device to issue an authorization certificate; the security implementation device 700 further includes:
  • a credential generating unit configured to generate an authorization credential for the at least one second device if the DAC and/or the SAC are successfully verified.
  • the security implementation device 700 further includes a verification unit configured to: generate first verification information based on the device secret key Secret; if the first verification information is consistent with the DAC, determine that the DAC verification passed.
  • the verification unit is also configured to generate the device secret key Secret based on the service shared secret key Kservice and/or the initial secret key of each second device in the at least one second device, wherein, the service shared secret key Kservice is a shared secret key between the first network element and the first device.
  • the verification unit is also configured to calculate the intermediate secret key of each second device based on the service shared secret key Kservice and/or the initial secret key of each second device; based on the service shared secret key Kservice and/or, the intermediate secret key of each second device in the at least one second device, generates the device secret key Secret.
  • the SAC uses the private key of the first device to compare the identification information of the first device, the identification information of each second device, the service identification information, and the data identification information, the random number NONCE, And at least one piece of information including the counter parameter COUNT is obtained by signing;
  • the verification unit is also configured to verify the SAC using the public key of the first device to obtain second verification information; if the second verification information is consistent with the first information If the carried identification information of the first device, the identification information of each second device, the service identification information, the data identification information, the random number NONCE, and the counter parameter COUNT are consistent, it is determined that the SAC verification has passed.
  • the SAC uses the service shared secret key Kservice to compare the identification information of the first device, the identification information of each second device in the at least one second device, the service identification information, and the At least one of the data identification information, random number NONCE, and counter parameter COUNT is obtained through safe operation;
  • the verification unit is further configured to, based on the service shared secret key Kservice, verify the identification information of the first device, the identification information of each second device, the service identification information, and the At least one of the data identification information, the random number NONCE, and the counter parameter COUNT is safely operated to obtain the third verification information; if the third verification information is consistent with the SAC, it is determined that the SAC verification passed.
  • the authorization credentials include at least one of the following:
  • the identification information of the first device is the identification information of the first device
  • the public key of the first device is the public key of the first device
  • the identification information of the first network element is the identification information of the first network element
  • the digital signature of the first network element is obtained by signing other information in the authorization certificate based on the private key of the first network element.
  • the security implementation device 700 further includes a first sending unit configured to send the authorization voucher to the blockchain node; the first receiving unit 701 is also configured to obtain the storage of the authorization voucher. location information.
  • the first sending unit is further configured to send the authorization voucher and/or the storage location information to the first device.
  • FIG 8 is a schematic structural diagram of the security implementation device 800 provided by the embodiment of the present application, which is applied to the first device. As shown in Figure 8, the security implementation device 800 includes:
  • the second sending unit 801 is configured to send first information; the first device is associated with at least one second device; the first information includes a device binding verification code DAC and/or a service verification code SAC; DAC is used to verify the association between the first device and at least one second device, SAC is used to verify whether the first device and/or the at least one second device supports the service type indicated by the service identification information, and/ Or, whether the first device and/or the at least one second device supports the data type indicated by the data identification information.
  • DAC is used to verify the association between the first device and at least one second device
  • SAC is used to verify whether the first device and/or the at least one second device supports the service type indicated by the service identification information, and/ Or, whether the first device and/or the at least one second device supports the data type indicated by the data identification information.
  • the first information also includes at least one of the following:
  • Service identification information is used to indicate the service type supported by the first device and/or the at least one second device;
  • the service identification information is used to indicate the data type supported by the first device and/or the at least one second device;
  • the identification information of the first device is the identification information of the first device
  • the security implementation apparatus 800 further includes a processing unit configured to generate the device binding verification code DAC based on the device secret key Secret; and/or based on the identification information of the first device, each second device At least one of the device identification information, service identification information, and data identification information is used to generate a service verification code SAC.
  • the processing unit is further configured to generate the device secret key Secret based on the service shared secret key Kservice and/or the initial secret key of each second device in the at least one second device; wherein , the service shared secret key Kservice is a shared secret key between the first network element and the first device.
  • the processing unit is further configured to generate an intermediate secret key for each second device based on the initial secret key of each second device; based on the service shared secret key Kservice, and/or the at least one The intermediate secret key of each second device in the second device is used to generate the device secret key Secret.
  • the second sending unit 801 is also configured to send secret key request information to the second network element; the secret key request information is used to request the secret key request information of at least one second device associated with the first device. Initial key.
  • the security implementation apparatus 800 further includes a second receiving unit configured to receive the initial secret key information sent by the second network element; the initial secret key information includes the initial secret key of each second device. key.
  • the secret key request information also includes at least one of the following:
  • the identification information of the first device is the identification information of the first device
  • the second MAC corresponding to the secret key request information is used to verify whether the sender of the secret key request information is a legitimate device.
  • the processing unit is further configured to use the private key of the first device to compare the identification information of the first device, the identification information of each second device, the service identification information, and the identification information of the first device. Sign at least one piece of information including the data identification information, the random number NONCE, and the counter parameter COUNT to obtain the SAC.
  • the processing unit is further configured to use the identification information of the first device, the identification information of each second device, the service identification information, and the data based on the service shared secret key Kservice. At least one of the identification information, the random number NONCE, and the counter parameter COUNT performs a secure operation to generate the SAC.
  • the first information is used to request authorization credentials for at least one second device associated with the first device.
  • Figure 9 is a schematic structural diagram of a communication device 900 provided by an embodiment of the present application.
  • the communication device may be the first network element or the first device.
  • the communication device 900 shown in Figure 9 includes a processor 910.
  • the processor 910 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the communication device 900 may further include a memory 920.
  • the processor 910 can call and run the computer program from the memory 920 to implement the method in the embodiment of the present application.
  • the memory 920 may be a separate device independent of the processor 910 , or may be integrated into the processor 910 .
  • the communication device 900 may also include a transceiver 930, and the processor 910 may control the transceiver 930 to communicate with other devices. Specifically, it may send information or data to other devices, or receive other devices. Information or data sent by the device.
  • the transceiver 930 may include a transmitter and a receiver.
  • the transceiver 930 may further include an antenna, and the number of antennas may be one or more.
  • the communication device 900 may specifically be the first network element in the embodiment of the present application, and the communication device 900 may implement the corresponding processes implemented by the first network element in the various methods of the embodiment of the present application. For simplicity, in This will not be described again.
  • the communication device 900 can specifically be the first device in the embodiment of the present application, and the communication device 1800 can implement the corresponding processes implemented by the first device in the various methods of the embodiment of the present application. For the sake of brevity, they are not mentioned here. Again.
  • Figure 10 is a schematic structural diagram of a chip according to an embodiment of the present application.
  • the chip 1000 shown in Figure 10 includes a processor 1010.
  • the processor 1010 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the chip 1900 may also include a memory 1020.
  • the processor 1010 can call and run the computer program from the memory 1020 to implement the method in the embodiment of the present application.
  • the memory 1020 may be a separate device independent of the processor 1010 , or may be integrated into the processor 100 .
  • the chip 1000 may also include an input interface 1030.
  • the processor 1010 can control the input interface 1030 to communicate with other devices or chips. Specifically, it can obtain information or data sent by other devices or chips.
  • the chip 1000 may also include an output interface 1040.
  • the processor 1010 can control the output interface 1040 to communicate with other devices or chips. Specifically, it can output information or data to other devices or chips.
  • the chip can be applied to the first network element in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the first network element in the various methods of the embodiment of the present application. For the sake of brevity, they will not be described here. Repeat.
  • the chip can be applied to the first device in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the first device in the various methods of the embodiment of the present application.
  • the details will not be described again.
  • chips mentioned in the embodiments of this application may also be called system-on-chip, system-on-a-chip, system-on-chip or system-on-chip, etc.
  • Figure 11 is a schematic block diagram of a communication system 1100 provided by an embodiment of the present application. As shown in Figure 11, the communication system 1100 includes a first device 1110 and a first network element 1120.
  • the first device 1110 can be used to implement the corresponding functions implemented by the first device in the above method
  • the first network element 1120 can be used to implement the corresponding functions implemented by the first network element in the above method.
  • the first device 1110 can be used to implement the corresponding functions implemented by the first device in the above method
  • the first network element 1120 can be used to implement the corresponding functions implemented by the first network element in the above method.
  • the processor in the embodiment of the present application may be an integrated circuit chip and has signal processing capabilities.
  • each step of the above method embodiment can be completed through an integrated logic circuit of hardware in the processor or instructions in the form of software.
  • the above-mentioned processor can be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other available processors.
  • DSP Digital Signal Processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • the steps of the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
  • non-volatile memory can be read-only memory (Read-Only Memory, ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), electrically removable memory. Erase programmable read-only memory (Electrically EPROM, EEPROM) or flash memory. Volatile memory may be Random Access Memory (RAM), which is used as an external cache.
  • RAM Random Access Memory
  • RAM static random access memory
  • DRAM dynamic random access memory
  • DRAM synchronous dynamic random access memory
  • SDRAM double data rate synchronous dynamic random access memory
  • Double Data Rate SDRAM DDR SDRAM
  • enhanced SDRAM ESDRAM
  • Synchlink DRAM SLDRAM
  • Direct Rambus RAM Direct Rambus RAM
  • the memory in the embodiment of the present application can also be a static random access memory (static RAM, SRAM), a dynamic random access memory (dynamic RAM, DRAM), Synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection Dynamic random access memory (synch link DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM) and so on. That is, memories in embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.
  • Embodiments of the present application also provide a computer-readable storage medium for storing computer programs.
  • the computer-readable storage medium can be applied to the first network element in the embodiment of the present application, and the computer program causes the computer to execute the corresponding processes implemented by the first network element in the various methods of the embodiment of the present application, in order to It’s concise and I won’t go into details here.
  • the computer-readable storage medium can be applied to the first device in the embodiment of the present application, and the computer program causes the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiment of the present application.
  • I won’t go into details here.
  • An embodiment of the present application also provides a computer program product, including computer program instructions.
  • the computer program product can be applied to the first network element in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the first network element in the various methods of the embodiment of the present application.
  • the computer program instructions cause the computer to execute the corresponding processes implemented by the first network element in the various methods of the embodiment of the present application.
  • the computer program product can be applied to the first device in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiment of the present application. For simplicity, in This will not be described again.
  • An embodiment of the present application also provides a computer program.
  • the computer program can be applied to the first network element in the embodiment of the present application.
  • the computer program When the computer program is run on the computer, it causes the computer to execute the corresponding steps implemented by the first network element in the various methods of the embodiment of the present application. The process, for the sake of brevity, will not be repeated here.
  • the computer program can be applied to the first device in the embodiment of the present application.
  • the computer program When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiment of the present application.
  • the computer program When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiment of the present application.
  • the computer program For the sake of brevity, no further details will be given here.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of the present application is essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory,) ROM, random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供一种安全实现方法、装置、设备及网元，该方法包括：第一网元接收第一信息；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。

Description

安全实现方法及装置、设备、网元 技术领域
本申请实施例涉及移动通信技术领域，具体涉及一种安全实现方法及装置、设备、网元。
背景技术
第五代移动通信技术(5th Generation Mobile Communication Technology，5G)的三大应用场景包括增强型移动宽带(eMBB)、海量机器类通信(mMTC)和超高可靠低时延通信(uRLLC)。随着通信技术的演进，工业无线传感器、视频监控和可穿戴设备等终端物联网应用对5G设备提出了复杂度与成本降低、尺寸减小、能耗更低等新要求。零功耗通信技术在设备的功耗、尺寸以及成本等方面将具有显著优势，从而成为了研究的热点。
然而，在零功耗设备或其他低能力设备的计算能力有限的情况下，这些设备将无法支持复杂的安全函数，因此更无法支持第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)的设备认证机制。基于此，零功耗设备或其他低能力设备如何进行安全运算，以保证数据传输的安全，目前并没有明确的解决方法。
发明内容
本申请实施例提供一种安全实现方法及装置、设备、网元。
本申请实施例提供一种安全实现方法，包括：
第一网元接收第一信息；所述第一信息中包括设备绑定验证码(Device Authentication Code，DAC)，和/或，业务验证码(Sercice Authentication Code，SAC)；DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
本申请另一实施例提供一种安全实现方法，包括：
第一设备发送第一信息；所述第一设备与至少一个第二设备关联；所述第一信息中包括DAC和/或SAC；所述DAC用于验证第一设备与至少一个第二设备之间的关联关系，所述SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
本申请实施例提供一种安全实现装置，应用于第一网元，包括：
第一接收单元，被配置为接收第一信息；所述第一信息中包括DAC和/或SAC；所述DAC用于验证第一设备与至少一个第二设备之间的关联关系，所述SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
本申请实施例提供一种安全实现装置，应用于第一设备，所述第一设备与至少一个第二设备关联；包括：
第二发送单元，被配置为发送第一信息；所述第一信息中包括DAC和/或SAC；DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
本申请实施例提供的第一网元，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述的安全实现方法。
本申请实施例提供的第一设备，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述的安全实现方法。
本申请实施例提供的芯片，用于实现上述的安全实现方法。
具体地，该芯片包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有该芯片的 设备执行上述的安全实现方法。
本申请实施例提供的计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述的安全实现方法。
本申请实施例提供的计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述的安全实现方法。
本申请实施例提供的计算机程序，当其在计算机上运行时，使得计算机执行上述的安全实现方法。
本申请实施例提供的安全实现方法，其中，第一设备可以发送第一信息；所述第一设备与至少一个第二设备关联；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证所述第一设备与所述至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。也就是说，第二设备可以借助第一设备的运算和/或通信机制实现安全运算，提高数据传输安全。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是本申请实施例提供的一种示例性的通信系统的网络架构示意图；
图2是本申请实施例提供的一种安全实现方法流程示意图一；
图3是本申请实施例提供的一种安全实现方法流程示意图二；
图4是本申请实施例提供的一种安全实现方法流程示意图三；
图5是本申请实施例提供的一种安全实现方法流程示意图四；
图6是本申请实施例提供的一种安全实现方法流程示意图五；
图7是本申请实施例提供的一种安全实现装置700的结构组成示意图；
图8是本申请实施例提供的一种安全实现装置800的结构组成示意图；
图9是本申请实施例提供的一种通信设备示意性结构图；
图10是本申请实施例的芯片的示意性结构图；
图11是本申请实施例提供的一种通信系统的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图1是本申请实施例的一个应用场景的示意图。
如图1所示，通信系统100可以包括终端设备110和网络设备120。网络设备120可以通过空口与终端设备110通信。终端设备110和网络设备120之间支持多业务传输。
应理解，本申请实施例仅以通信系统100进行示例性说明，但本申请实施例不限定于此。也就是说，本申请实施例的技术方案可以应用于各种通信系统，例如：长期演进(Long Term Evolution，LTE)系统、LTE时分双工(Time Division Duplex，TDD)、通用移动通信系统(Universal Mobile Telecommunication System，UMTS)、物联网(Internet of Things，IoT)系统、窄带物联网(Narrow Band Internet of Things，NB-IoT)系统、增强的机器类型通信(enhanced Machine-Type Communications，eMTC)系统、5G通信系统(也称为新无线(New Radio，NR)通信系统)，或未来的通信系统等。
在图1所示的通信系统100中，网络设备120可以是与终端设备110通信的接入网设备。接入网设备可以为特定的地理区域提供通信覆盖，并且可以与位于该覆盖区域内的终端设备110(例如UE)进行通信。
网络设备120可以是长期演进(Long Term Evolution，LTE)系统中的演进型基站(Evolutional Node B，eNB或eNodeB)，或者是下一代无线接入网(Next Generation Radio Access Network，NG RAN)设备，或者是NR系统中的基站(gNB)，或者是云无线接入网络(Cloud Radio Access Network，CRAN)中的无线控制器，或者该网络设备120可以为中继站、接入点、车载设备、可穿戴设备、集线器、 交换机、网桥、路由器，或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)中的网络设备等。
终端设备110可以是任意终端设备，其包括但不限于与网络设备120或其它终端设备采用有线或者无线连接的终端设备。
例如，所述终端设备110可以指接入终端、用户设备(User Equipment，UE)、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。接入终端可以是蜂窝电话、无绳电话、会话启动协议(Session Initiation Protocol，SIP)电话、IoT设备、卫星手持终端、无线本地环路(Wireless Local Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备、5G网络中的终端设备或者未来演进网络中的终端设备等。
终端设备110可以用于设备到设备(Device to Device，D2D)的通信。
无线通信系统100还可以包括与基站进行通信的核心网设备130，该核心网设备130可以是5G核心网(5G Core，5GC)设备，例如，接入与移动性管理功能(Access and Mobility Management Function，AMF)，又例如，认证服务器功能(Authentication Server Function，AUSF)，又例如，用户面功能(User Plane Function，UPF)，又例如，会话管理功能(Session Management Function，SMF)。可选地，核心网络设备130也可以是LTE网络的分组核心演进(Evolved Packet Core，EPC)设备，例如，会话管理功能+核心网络的数据网关(Session Management Function+Core Packet Gateway，SMF+PGW-C)设备。应理解，SMF+PGW-C可以同时实现SMF和PGW-C所能实现的功能。在网络演进过程中，上述核心网设备也有可能叫其它名字，或者通过对核心网的功能进行划分形成新的网络实体，对此本申请实施例不做限制。
通信系统100中的各个功能单元之间还可以通过下一代网络(next generation，NG)接口建立连接实现通信。
例如，终端设备通过NR接口与接入网设备建立空口连接，用于传输用户面数据和控制面信令；终端设备可以通过NG接口1(简称N1)与AMF建立控制面信令连接；接入网设备例如下一代无线接入基站(gNB)，可以通过NG接口3(简称N3)与UPF建立用户面数据连接；接入网设备可以通过NG接口2(简称N2)与AMF建立控制面信令连接；UPF可以通过NG接口4(简称N4)与SMF建立控制面信令连接；UPF可以通过NG接口6(简称N6)与数据网络交互用户面数据；AMF可以通过NG接口11(简称N11)与SMF建立控制面信令连接；SMF可以通过NG接口7(简称N7)与PCF建立控制面信令连接。
图1示例性地示出了一个接入网设备、一个核心网设备和两个终端设备，可选地，该无线通信系统100可以包括多个基站设备并且每个基站的覆盖范围内可以包括其它数量的终端设备，本申请实施例对此不做限定。
需要说明的是，图1只是以示例的形式示意本申请所适用的系统，当然，本申请实施例所示的方法还可以适用于其它系统。此外，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。还应理解，在本申请的实施例中提到的“指示”可以是直接指示，也可以是间接指示，还可以是表示具有关联关系。举例说明，A指示B，可以表示A直接指示B，例如B可以通过A获取；也可以表示A间接指示B，例如A指示C，B可以通过C获取；还可以表示A和B之间具有关联关系。还应理解，在本申请的实施例中提到的“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。还应理解，在本申请的实施例中提到的“预定义”或“预定义规则”可以通过在设备(例如，包括终端设备和网络设备)中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本申请对于其具体的实现方式不做限定。比如预定义可以是指协议中定义的。还应理解，本申请实施例中，所述“协议”可以指通信领域的标准协议，例如可以包括LTE协议、NR协议以及应用于未来的通信系统中的相关协议，本申请对此不做限定。
为便于理解本申请实施例的技术方案，以下通过具体实施例详述本申请的技术方案。以上相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合，其均属于本申请实施例的保护范围。本申请实施例包括以下内容中的至少部分内容。
零功耗通信技术在设备的功耗、尺寸以及成本等方面将具有显著优势。例如，零功耗通信技术从功耗上有望将设备功耗从窄带物联网(Narrow Band Internet of Things,NB-IoT)设备的数十毫瓦的 功耗降低至几十微瓦甚至数微瓦；从成本上有望将设备成本从最便宜的NB-IoT设备的十几元降低至1元甚至更低。零功耗通信技术的主要特点是通过调制来波信号实现反向散射通信，同时它还可以通过能量采集获得能量以驱动数字逻辑电路或芯片(如微控制单元或传感器芯片)，实现对信号的编码、加密或简单计算等功能。
然而，零功耗通信技术中射频能量的转化效率往往不足10％，决定了驱动数字逻辑电路或芯片用于计算的功耗要求不能太高。虽然随着工艺的改进和设计的优化有所提高，每微焦耳能量可使用于计算的次数增多，但是仍不能满足复杂的计算。零功耗终端设备计算功能非常有限，无法支持如SHA-256定义的安全函数，更无法支持3GPP的认证机制。因此，需要为零功耗设备设计轻量级的群组证书机制，以便对上行数据传输进行授权，避免攻击者或者伪基站恶意触发零功耗设备的上行数据传输，保证零功耗设备的上行传输数据的安全，提高零功耗设备授权的效率。
基于此，本申请实施例提供一种安全实现方法，参考2所示，该方法包括但不限于以下步骤：
步骤210、第一设备发送第一信息；第一信息中可以包括设备绑定验证码DAC，和/或，业务验证码SAC；其中，DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证第一设备和/或至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，第一设备和/或至少一个第二设备是否支持数据标识信息指示的数据类型。
步骤220、第一网元接收该第一信息。
本申请实施例中，第一设备可以是支持设备认证机制算法的设备，例如，第一设备可以是UE，基站，或者其他可支持复杂运算的设备，本申请实施例对此不做限制。
第二设备可以是不支持设备认证机制算法的低运算能力的设备，即第二设备是无法单独进行安全运算的设备，例如，第二设备可以是零功耗设备(Zero Power Device，ZPD)，或者运算能力较弱的低能力设备，或者剩余电量较少的设备，本申请实施例对此不做限制。
第一网元可以是位于网络中的设备。示例性的，第一网元可以是至少一个第二设备的厂商提供的应用服务器或设备ID管理服务器，也可以是运营商提供的接入网设备(例如基站)或核心网设备，也可以是业务提供商(SP)提供的服务器或设备ID管理服务器。本申请实施例对此不做限制。
可选地，第二设备可以与第一设备通过调制来波信号实现反向散射的技术进行通信。
本申请实施例中，第一设备可以与一个或者多个第二设备进行关联。应理解，第一设备是支持设备认证机制的设备，与第一设备关联的至少一个第二设备可以利用该第一设备的运算和/或通信机制，实现安全运算。
具体地，本申请实施例中，第一设备可以向第一网元发送第一信息，通过第一信息携带DAC和/或SAC。这样，第一网元可以基于第一信息中的DAC和/或SAC，对与第一设备关联的至少一个第二设备进行验证，以便于与至少一个第二设备进行数据交互，或者第一网元可以基于DAC和/或SAC，为至少一个第二设备生成授权凭证，以保证第二设备数据传输的安全。
需要说明的是，第一信息可以是第一设备直接发送给第一网元，也可以是第一设备通过其他中间设备转发给第一网元，本申请实施例对此不做限制。示例性的，当第一网元为接入网设备或和核心网设备时，第一设备可以直接向该第一网元发送第一信息。当第一网元为应用服务器或设备ID管理服务器时，第一设备可以通过运营商提供的接入网设备和/或核心网设备，向该第一网元转发上述第一信息。
可选地，第一网元接收到第一信息后，可以基于DAC验证第一设备与至少一个第二设备之间是否真实存在关联关系，从而确定是否可以信任至少一个第二设备。
可选地，第一网元可以基于SAC，验证第一设备和/或第二设备支持的业务类型是否是业务标识信息指示的业务类型，从而确定第一设备和/至少一个第二设备是否具有传输该业务类型对应的数据的权限。
可选地，第一网元还可以基于SAC，验证第一设备和/或第二设备支持的数据类型是否是数据标识信息指示的数据类型，从而确定第一设备和/至少一个第二设备是否具有传输该数据类型对应的数据的权限。
本申请实施例中，第一设备和/或至少一个第二设备可以提供一种或多种业务，例如定位业务、测速业务、健康呼救业务、环境监测业务等。本申请实施例可以通过业务标识信息来指示第一设备和/或至少一个第二设备提供的业务类型。
可选地，业务标识信息可以是业务类型的ID，也可以是第一设备和/或至少一个第二设备的厂商提供的应用服务器的ID，或者业务提供商提供的应用服务器的ID。示例性的，当第一网元为业务提供商(SP)提供的应用服务器时，第一网元的ID与业务标识信息相同。
本申请实施例中，数据标识信息可以指示第一设备和/或至少一个第二设备支持的数据类型，该数据类型包括一种或多种。通常情况下，设备所支持的数据类型通常与设备所支持的业务相关。示例性的，如果该业务为健康呼救业务，那么数据类型可以包括心率数据、体温数据、呼吸频率数据、运动量数据、血压数据等，如果感知业务为环境监测业务，那么数据类型可以包括位置数据、风速数据、温度数据、日晒数据、高度数据等。本申请实施例对数据类型不做限制。
可选地，上述业务标识信息和数据标识信息可以通过第一信息携带。业务标识信息和数据标识信息也可以是第一网元预存储的，本申请实施例对此不做限制。
由此可见，本申请实施例提供的安全实现方法中，第一设备可以做为第二设备的中间代理，通过第一设备完备的运算和/或通信机制为第二设备实现安全运算，提高数据传输安全。
可选地，第一信息可以是凭证请求信息，也就是说，该第一信息可以用于请求与第一设备关联的至少一个第二设备的授权凭证。
可以理解的是，第一设备可以利用其自身的运算和/或通信机制，向网络侧的网元请求与其关联的至少一个第二设备的授权凭证。
对应的，参考图3所示，本申请实施例提供的安全实现方法中还可以包括以下步骤：
步骤230、在第一网元对DAC和/或SAC验证通过的情况下，第一网元为至少一个第二设备生成授权凭证。
本申请实施例中，第一网元接收到第一信息之后，可以通过DAC来确定第一设备与至少一个第二设备之间具有真实的关联关系，通过SAC来验证第一设备和/或至少一个第二设备支持的业务类型是否是业务标识信息指示的业务类型，和/或，第一设备和/或至少一个第二设备支持的数据类型是否是数据标识信息指示的数据类型。
应理解，只有在第一网元确定了第一设备和至少一个第二设备之间的关联关系是正确的，且第一设备和/或至少一个第二设备支持的业务类型为业务标识信息所指示的业务类型，和/或，第一设备和/或至少一个第二设备支持的数据类型为数据标识信息所指示的数据类型的情况下，第一网元才为至少一个第二设备生成授权凭证。
可选地，若第一信息是第一设备通过接入网设备和/或核心网设备转发给第一网元的，那么第一信息的转发设备(也就是接入网设备和/或核心网设备)可以对第一信息中的DAC进行验证，并且，该转发设备可以在对DAC验证通过之后，根据业务标识信息，将该第一信息发送给第一网元。进而，第一网元可以继续对SAC进行验证，并在对SAC验证通过后，生成至少一个第二设备的授权凭证。
综上所述，本申请实施例提供的安全实现方法中，第一设备可以作为中间代理设备，为第一设备关联的至少一个第二设备实现安全运算，以获得至少一个第二设备的授权凭证。也就是说，可以借用第一设备与第一网元进行交互，以使第一网元为至少一个第二设备生成轻量级的授权凭证，使设备获得业务授权，提高业务安全和数据传输安全。
可选地，参考图3所示，本申请实施例提供的安全实现方法中，步骤210之前，还可以包括以下内容：
步骤240、第一设备基于设备秘钥Secret，生成设备绑定验证码DAC；
和/或，
第一设备基于第一设备的标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项，生成业务验证码SAC。
可选地，第一设备可以基于以下公式(1)来计算设备绑定验证码DAC。
DAC＝H(Secret，ID UE，ID ZP，S)        (1)；
其中，H()为哈希函数或校验功能或密钥生成功能函数，例如H()可以以为HMAC-SHA-256、也可以为安全函数f1、安全函数f2、安全函数f3、安全函数f4、或者安全函数或f5，本申请实施例对此不做限制。
ID UE为第一设备的标识信息，ID ZP为至少一个第二设备的标识信息。应理解，当第二设备的数量包括多个时，ID ZP可以包括多个第二设备中每个第二设备的标识信息。S可以包括以下中的至少一项：第一设备的证书信息Cert UE，随机数NONCE，以及计数器参数COUNT。
可选的，S还可以包括以下信息中的一个或多个：ID SP，ID DATA。其中，ID SP是指业务标识信息，ID DATA是指数据标识信息。
可选地，设备秘钥Secret可以是基于业务共享秘钥Kservice，和/或，每个第二设备的初始秘钥生成。这里，业务共享秘钥Kservice是第一网元与第一设备进行安全协商后得到的对称秘钥。其中，业务共享秘钥Kservice，可以为K eNB，K RRCint,K RRCenc,K NASenc,K NASint,K AF，或K s_NAF中的任意一个， 本申请实施例对此不做限制。
需要说明的是，步骤240中设备秘钥Secret的生成方式详见下文实施例的描述，此处不再赘述。
可选地，在一些实施例中，第一设备可以利用第一设备的私钥，对第一设备的标识信息、至少一个第二设备的标识信息、业务标识信息、数据标识信息、NONCE、以及COUNT中的至少一项信息进行签名，得到业务验证码SAC。
示例性的，第一设备可以利用以下公式(2)来生成业务验证码SAC：
SAC＝Sig UE(S)        (2)；
其中，Sig UE是指使用UE的私钥进行签名的过程。S为输入参数，至少包含以下一个或多个：ID ZP，ID UE，ID SP，ID DATA，NONCE，以及COUNT。这里的ID SP、ID DATA、ID ZP和ID UE如上所述，此处不做赘述。
可选地，在另一些实施例中，第一设备可以基于业务共享秘钥Kservice，对第一设备的标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、NONCE、以及COUNT中的至少一项进行安全运算，生成SAC。
示例性的，第一设备可以利用以下公式(3)来生成业务验证码SAC：
SAC＝H(Kservice，S)          (3)；
其中，S为输入参数，可以包括以下信息中的一个或多个：ID ZP，ID UE，ID SP，ID DATA，NONCE，COUNT。其中，ID ZP，ID UE，ID SP，和ID DATA如上所述，此处不做赘述。
进一步地，第一设备将运算得到的DAC和/或SAC通过第一信息发送给第一网元，以使第一网元为第一设备关联的至少一个第二设备生成授权凭证。
本申请实施例中，第一网元在接收到第一信息后，可以对DAC和/或SAC进行验证。以下详细介绍第一网元对DAC和SAC的验证过程。
本申请实施例中，第一网元接收到第一信息后，可以通过DAC来验证第一设备与至少一个第二设备之间是否具有真实的关联关系，通过SAC来验证第一设备和/或至少一个第二设备支持的业务类型是否是业务标识信息指示的业务类型，和/或，第一设备和/或至少一个第二设备支持的数据类型是否是数据标识信息指示的数据类型。
其中，第一网元对DAC的验证过程如下：
第一网元可以基于设备秘钥Secret，生成第一校验信息。其中，第一网元可以参考上述公式(1)来生成第一校验信息。若第一校验信息与第一信息中携带的DAC一致，可以认为第一设备和至少一个第二设备之间真实存在关联关系，第一设备确定DAC验证通过。若第一校验信息与第一信息中携带的DAC不一致，则认为第一设备与至少一个第二设备之间的关联关系错误或不存在，第一网元确定DAC验证不通过。
可选地，第一网元可以从第一设备处获取设备秘钥Secret，也可以从其他受信任的设备(例如基站、UDM网元、应用服务器等)处获取设备秘钥Secret。第一网元还可以基于业务共享秘钥，和/或，每个第二设备的初始秘钥生成该设备秘钥Secret，其中，第一网元生成设备秘钥Secret的方式与第一设备生成设备秘钥Secret的方式相同。本申请实施例确定设备秘钥Secret的方式不做限制。
另外，第一网元对SAC的验证过程如下：
可选地，在一些实施例中，若SAC是利用第一设备的私钥对第一设备的标识信息、每个第二设备的标识信息、业务标识信息、以及数据标识信息、NONCE、以及COUNT在内的至少一项信息进行签名得到，则第一网元可以利用第一设备的公钥对SAC进行验证。
具体地，第一网元可以通过第一设备的公钥对SAC进行验证，得到第二校验信息。若第二校验信息与第一信息中包括的第一设备的标识信息、至少一个第二设备的标识信息、业务标识信息、数据类型标识信息、NONCE、以及COUNT在内的至少一项信息一致，则认为第一设备和/或至少一个第二设备支持的业务类型与业务标识信息指示的业务类型相同，以及第一设备和/或至少一个第二设备支持的数据类型为数据标识信息所指示的数据类型，第一网元确定SAC验证通过。否则，确定SAC验证不通过。
可选地，在另一些实施例中，若SAC是利用业务共享秘钥Kservice，对第一设备的标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、NONCE、以及COUNT中的至少一项进行安全运算得到，则第一网元可以利用业务共享秘钥Kservice，对SAC进行验证
具体地，第一网元首先可以基于业务共享秘钥Kservice，对第一设备的标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、NONCE、以及COUNT中的至少一项进行安全运算，得到第三校验信息；其中，第一网元可以参考上述公式(3)来生成第三校验信息。若第三校验信息 与所述SAC一致，则第一网元确定SAC验证通过。否者，确定SAC验证不通过。
可选地，若第一信息是第一设备通过接入网设备和/或核心网设备转发给第一网元的，那么第一信息的转发设备(也就是接入网设备和/或核心网设备)也可以对第一信息中的DAC进行验证，并且，该转发设备可以在对DAC验证通过之后，根据业务标识信息，将该第一信息发送给第一网元。进而，第一网元可以继续对SAC进行验证，并在对SAC验证通过后，生成至少一个第二设备的授权凭证。
需要说明的是，接入网设备和/或核心网设备对DAC进行验证的方式与上文中描述的方式相同，为了简洁，此处不再赘述。
另外，若第一网元为接入网设备和/或核心网设备，则可以直接对第一信息中携带的DAC和/或SAC进行验证。
可选地，考虑到DAC和/或SAC的验证过程需要进行复杂的安全运算，因此，本申请实施例中，在DAC和/或SAC进行验证之前，还可以根据第一信息中的内容进行一些初步的验证，避免进行不必要的DAC和/或SAC验证。
示例性的，第一网元可以维护一份设备列表，该设备列表中存储第一网元支持的所有设备的标识信息。当第一信息中包括第一设备的标识信息和/或至少一个第二设备的标识信息时，第一网元可以判断设备列表中是否包括第一信息中的第一设备的标识信息和/或至少一个第二设备的标识信息。若第一设备的标识信息和至少一个第二设备的标识信息不在设备列表中，则可以确定第一网元不支持与第一设备和/或第二设备进行数据传输，那么第一网元可以不进行进一步操作，即不进行复杂的DAC和/或SAC验证。否则，第一网元需要继续进行DAC和/或SAC验证。
第一网元还可以维护一份业务类型列表，该业务类型列表用于存储第一网元支持的业务类型。当第一信息中包括业务标识信息时，第一网元可以从业务类型列表中查找是否包括该业务标识信息对应的业务类型。若该业务类型列表中不包括该业务类型，则说明第一网元不支持该业务类型，这样，第一网元可以避免进行DAC和/或SAC验证。
另外，第一网元还可以维护一份数据类型列表、该数据类型列表用于存储第一网元支持的数据类型。当第一信息中包括数据标识信息时，第一网元可以从数据类型列表中查找是否包括该数据标识信息对应的数据类型。若该数据类型列表中不包括该数据类型，则说明第一网元不支持该数据类型，这样，第一网元可以避免进行DAC和/或SAC验证。
可选地，上述设备列表、业务类型列表、以及数据类型列表中的信息可以是第一网元通过调用其他数据库设备存储的信息获取得到。
综上所述，第一网元可以根据DAC和/或SAC确定第一设备和至少一个第二设备具有绑定关系，以及第一设备和/或第二设备与业务标识信息指示的业务类型绑定，第一设备和/或第二设备与数据标识信息指示的数据类型绑定；只有在上述至少一项绑定关系成立的前提下，第一网元才可以为至少一个第二设备生成授权凭证，如此保证生成的授权凭证的安全性。
可选地，第一信息除了包括DAC和/或SAC之外，还包括以下中的至少一项：
业务标识信息；
数据标识信息；
第一设备的标识信息；
至少一个第二设备中每个第二设备的标识信息；
设备秘钥Secret；
第一信息对应的第一信息验证码MAC；第一MAC用于验证所述第一信息的发送方是否为合法设备。
可选地，第一网元在对DAC和/SAC进行验证之前，还可以先对发送第一信息的第一设备进行身份验证。只有在对第一设备的身份验证通过之后，才进一步地对DAC和/SAC进行验证。否则，第一设备的身份验证未通过，第一网元可以认为发送第一信息的设备为不可信任的设备，不对第一信息进行响应。
可选地，在第一信息中包括第一MAC的情况下，第一网元可以根据该第一MAC对第一设备进行身份验证。
在一种可能的实现方式中，若第一MAC是第一设备基于其与第一网元之间的业务共享秘钥生Kservice成的，则第一网元可以使用该业务共享秘钥Kservice生成校验信息，若校验信息与第一MAC一致，则确定第一设备的身份验证通过。
可选地，第一设备与第一网元预先协商好的业务共享秘钥Kservice可以是秘钥K eNB，K RRCint, K RRCenc,K NASenc,K NASint,K AF，K s_NAF等，本申请实施例对此不做限制。
在另一种可能的实现方式中，若第一MAC是第一设备利用其私钥对第一信息中的其他信息签名得到，则第一网元可以使用第一设备的公钥对第一MAC验证，若验证结果与第一信息中的其他信息一致，则确定第一设备的身份验证通过。在对第一设备的身份验证通过的情况下，第一网元进一步对DAC和/或SAC进行验证，确定是否为至少一个第二设备生成授权凭证。
本申请实施例中，第一网元在对DAC和/或SAC验证通过后，可以为至少一个第二设备生成授权凭证。其中，至少一个第二设备可以共用一个授权凭证。
可选地，在第一网元生成授权凭证之前，可以为每个第二设备生成RSA累加器参数α ZP，每个第二设备的RSA累加器参数α ZP可以用于证明该第二设备的是否被撤销。
可选地，第一网元生成的授权凭证中可以包括以下信息中的至少一项：
第一设备的标识信息；
第一设备的公钥；
至少一个第二设备中每个第二设备的标识信息；
至少一个第二设备中每个第二设备的RSA累加器参数；
第一网元的标识信息；
第一网元的公钥；
业务标识信息；
数据标识信息；
设备绑定验证码DAC；
第一网元的数字签名。
其中，数字签名可以是第一网元利用自己的私钥对上述授权凭证中的其他信息进行签名得到。应理解，该数字签名可以用于验证该授权凭证的合法性。
在一示例中，第二设备的数量为1时，该第二设备ZP1的授权凭证可以为：Cert IS->ZP([ID ZP1，DAC]，α ZP1，ID UE，ID IS，ID SP，Sig skIS)。其中，IS是指第一网元，Cert IS->ZP可以理解为是第一网元为第二设备生成的授权凭证。α ZP1为第二设备ZP1的RSA累加器参数，ID IS为第一网元的标识信息，sk IS为第一网元的私钥，Sig skIS为第一网元的数字签名。
在另一示例中，第二设备的数量为n时，n为大于1的整数，该n个第二设备的授权凭证可以为：Cert IS->ZPg([ID ZP1，…，ID ZPn，DAC]，α ZP1，…，α ZPn，ID UE，ID IS，ID SP，Sig skIS)。其中，α ZP1，…，α ZPn分别为n个第二设备对应的RSA累加器参数。
需要说明的是，当业务标识信息ID SP为应用服务器的ID，且第一网元为该应用服务器时，第一网元的标识信息ID IS与业务标识信息ID SP相同，第一网元可以仅使用其中的一种来生成授权凭证。
应理解，第二设备的数量包括多个时，第一网元可以为多个第二设备生成一个授权凭证，该授权凭证可以是群组证书，即多个第二设备可以共用一个授权凭证。
可选地，参考图4所示的流程示意图，本申请实施例中，第一网元在生成至少一个第二设备的授权凭证之后，还可以执行步骤250和步骤260。
步骤250、第一网元向区块链节点发送授权凭证；
步骤260、第一网元获取该授权凭证的存储位置信息。
可以理解的是，第一网元可以向区块链节点发送所生成的至少一个第二设备的授权凭证，对至少一个第二设备的授权凭证进行上链操作，以实现对该授权凭证的分布式存储。进一步地，区块链节点接收到授权凭证后，可以将该授权凭证存储于区块链的存储区块中，并将存储位置信息反馈给第一网元。
可选地，参考图4所示，步骤260之后还可以包括以下步骤：
步骤270、第一网元向第一设备发送授权凭证，和/或，存储位置信息。
可以理解的是，第一网元在生成授权凭证之后，可以将生成的授权凭证发送给凭证的请求方，即第一设备。第一网元也可以将授权凭证在存储区块中的存储位置信息发送给第一设备，第一设备和/或至少一个第二设备可以在需要时根据该存储位置信息向区块链节点请求授权凭证。
以下详细介绍步骤240中设备秘钥Secret的生成方式。
本申请实施例中，步骤240中的设备秘钥Secret可以是第一设备基于业务共享秘钥Kservice，和/或，每个第二设备对应的初始秘钥计算得到。
可选地，参考图5所示，步骤240之前还可以包括以下内容：
步骤510、第一设备基于业务共享秘钥Kservice，和/或，至少一个第二设备中每个第二设备的 初始秘钥，生成设备秘钥Secret。
可选地，第一设备可以直接基于每个第二设备对应的初始秘钥，生成设备秘钥Secret。
示例性的，若第二设备的数量为1，则设备秘钥Secret即为该第二设备的初始秘钥。若第二设备的数量包括多个，则第一设备可以将每个第二设备的初始秘钥进行汇聚处理，得到上述设备秘钥Secret。其中，汇聚处理可以是将多个秘钥直连处理。
可选地，第一设备也可以基于至少一个第二设备中每个第二设备的初始秘钥，以及业务共享秘钥Kservice，生成设备秘钥Secret。其中，业务共享秘钥Kservice可以为K eNB，K RRCint，K RRCenc，K NASenc，K NASint，K AF，K s_NAF等，本申请实施例对此不做限制。
示例性的，若第二设备的数量为1，则第一设备可以将该第二设备的初始秘钥和业务共享秘钥Kservice进行直连处理，得到设备秘钥Secret。若第二设备的数量包括多个，则第一设备可以将每个第二设备的初始秘钥，以及业务共享秘钥Kservice进行直连处理，得到设备秘钥Secret。
可选地，步骤510中第一设备基于业务共享秘钥Kservice，和/或，至少一个第二设备中每个第二设备的初始秘钥，生成设备秘钥Secret，还可以通过以下方式实现：
第一设备基于每个第二设备的初始秘钥，生成每个第二设备的中间秘钥；
第一设备基于业务共享秘钥Kservice，和/或，每个第二设备的中间秘钥，生成设备秘钥Secret。
其中，中间秘钥可以是第一设备与第二设备进行物理层安全协商后得到的可以在两个设备之间共享使用的对称秘钥。
可选地，第一设备可以先基于每个第二设备的初始秘钥，生成每个第二设备的中间秘钥；接着，第一设备可以基于至少一个第二设备中每个第二设备的中间秘钥，生成设备秘钥Secret。
也就是说，第一设备可以基于每个第二设备的初始秘钥，与该第二设备进行物理层安全机制的协商处理，生成各个第二设备分别对应的中间秘钥。进而，第一设备可以基于每个第二设备的中间秘钥，生成设备秘钥Secret。
示例性的，若第二设备的数量为1，则设备秘钥Secret即为该第二设备的中间秘钥。若第二设备的数量包括多个，则第一设备可以将每个第二设备的中间秘钥进行汇聚处理，得到上述设备秘钥Secret。其中，汇聚处理可以是将多个秘钥直连处理。
可选地，第一设备还可以先基于每个第二设备的初始秘钥生成每个第二设备的中间秘钥；接着，第一设备可以基于业务共享秘钥Kservice，以及每个第二设备的中间秘钥，生成设备秘钥Secret。
示例性的，若第二设备的数量为1，则设备秘钥Secret即为该第二设备的中间秘钥。若第二设备的数量包括多个，则第一设备可以将业务共享秘钥Kservice，和每个第二设备的中间秘钥进行汇聚处理，得到上述设备秘钥Secret。
需要说明的是，第一网元在验证DAC之前，也可以通过上述方式确定设备秘钥Secret。也就是说，第一网元可以基于业务共享秘钥Kservice，和/或，每个第二设备的初始秘钥，生成设备秘钥Secret。或者，第一网元可以基于每个第二设备的初始秘钥，计算每个第二设备的中间秘钥；进一步，第一网元基于业务共享秘钥Kservice，和/或，每个第二设备的中间秘钥，生成设备秘钥Secret。计算方式与步骤510中描述的方式相同，为了简洁，此处不再赘述。
可选地，参考图5所示，步骤510之前，还可以执行以下步骤：
步骤520、第一设备向第二网元发送秘钥请求信息；该秘钥请求信息用于请求与第一设备关联的至少一个第二设备的初始秘钥。
步骤530、第二网元向第一设备发送初始秘钥信息，该初始秘钥信息中包括所述至少一个第二设备中每个第二设备的初始秘钥。
其中，第二网元可以是上述至少一个第二设备所信任的设备，用于管理上述至少一个第二设备中每个第二设备的初始秘钥。例如，第二网元可以是上述第二设备的厂商提供的服务器或设备ID管理服务器，也可以是运营商提供的接入网设备或核心网设备，也可以是业务提供商(SP)提供的服务器或设备ID管理服务器，本申请实施例对此不做限制。
需要说明的是，第二网元与上述实施例中的第一网元可以为同一设备，也可以为不同的设备，本申请实施例对此不做限制。
可选地，秘钥请求信息中可以包括以下信息中的至少一项：
第一设备的标识信息；
至少一个第二设备中每个第二设备的标识信息；
业务标识信息；
数据标识信息；
秘钥请求信息对应的第二MAC。
本申请实施例中，第二网元在接收到秘钥请求信息后，可以向第一设备反馈初始秘钥信息，该初始秘钥信息中可以携带至少一个第二设备的初始秘钥。具体地，初始秘钥信息中可以包括至少一个第二设备的标识信息，以及每个第二设备对应的初始秘钥。
示例性的，若第二设备的数量仅为一个，则初始秘钥信息中可以包括一个标识信息-初始秘钥对，即(ID ZP1，K ZP1)。若第二设备的数量为多个(例如n个)，则初始秘钥信息中可以包括n个标识信息-初始秘钥对：(ID ZP1，K ZP1)，(ID ZP2，K ZP2)，(ID ZP3,K ZP3)，……，(ID ZPn，K ZPn)。其中，ID ZP1即零功耗设备1的标识信息，K ZP1即零功耗设备1的初始秘钥，以此类推，ID ZPn即零功耗设备n的标识信息，K ZPn即零功耗设备n的初始秘钥。
可选地，初始秘钥可以是对称秘钥，第二设备的本地存储空间中也可以存储自己的初始秘钥。
可选地，当秘钥请求信息中包括业务标识信息和/或数据标识信息时，第二网元可以基于业务标识信息和/或数据标识信息对至少一个第二设备进行验证，判断至少一个第二设备是否具有使用该业务标识信息和/或数据标识信息对应的业务的权限。并且，只有在至少一个第二设备验证通过后，第二网元才向第一设备发送初始秘钥信息。
其中，第二网元可以判断本地存储的业务标识信息与秘钥请求信息中携带的业务标识信息是否一致，和/或，本地存储的数据标识信息与秘钥请求信息中数据标识信息是否一致。若一致，则第二网元确定至少一个第二设备验证通过，也就是说，至少一个第二设备具有使用该业务标识信息对应业务类型，和/或数据标识信息对应的数据类型的权限。若不一致，则第二网元确定至少一个第二设备验证失败，至少一个第二设备均不具有使用该业务标识信息对应业务类型，和/或数据标识信息对应的数据类型的权限。
示例性的，在第二网元为应用服务器，业务标识信息为应用服务器的ID的情况下，第二网元可以对比自己的ID与秘钥请求信息中携带的业务标识信息。若两者相同，则确定至少一个第二设备验证通过，否则，确定至少一个第二设备验证失败。
本申请实施例中，秘钥请求信息中可以包括第二MAC。第二网元在接收到第一设备发送的秘钥请求信息后，可以先根据该第二MAC对第一设备的身份进行认证，以确定发送秘钥请求信息的第一设备是否是可信任的设备。
可选地，在一些实施例中，第一设备可以使用与第二网元预先协商好的秘钥来对秘钥请求信息进行加密或完成性保护，得到第二MAC。示例性的，第一设备与第二网元预先协商好的秘钥可以是秘钥K eNB，K RRCint,K RRCenc,K NASenc,K NASint,K AF，K s_NAF等，本申请实施例对此不做限制。
对应的，第二网元在接收到秘钥请求信息之后，可以利用上述与第一设备协商好的秘钥对第二MAC进行验证。示例性的，若第二网元为基站，则第二网元可以使用K eNB或K RRCint对第二MAC进行验证。若第二网元为应用服务器，则第二网元可以使用K AF或K s_NAF对第二MAC进行验证。若第二网元为核心网网元，则第二网元可以使用K NASint，对第二MAC进行验证。
可选地，在另一些实施例中，第一设备可以使用第一设备的私钥对秘钥请求信息的内容或部分内容进行签名，得到第二MAC。对应的，第二网元在接收到秘钥请求信息后，可以利用使用第一设备的证书或者第一设备的公钥对第二MAC进行验证。
应理解，第二网元在对第一设备的身份认证通过后，才向第一设备发送初始秘钥信息。
下面结合具体应用场景，对本申请实施例进行详细阐述。
在该应用场景中，第一设备可以为UE，第二设备可以为ZPD，第一网元可以为业务提供商提供的应用服务器，第二网元可以为基站。另外，第一信息可以是凭证请求信息。参考图6所示的流程示意图，本申请实施例提供的安全实现方法可以包括以下步骤：
步骤601、UE向基站发送秘钥请求信息，该秘钥请求信息用于请求与UE关联的n个零功耗设备ZPD的初始秘钥，其中，n为大于或等于1的整数。
可选地，秘钥请求信息中可以包括ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、以及第一MAC中的至少一项。
其中，ID UE为UE的标识信息，ID ZP1、…、ID ZPn为与UE绑定的n个零功耗设备ZP1至ZPn分别对应的标识信息。ID SP为业务标识信息，ID DATA为数据标识信息。
另外，第一MAC即为秘钥请求信息的信息验证码。
可选地，UE可以使用与基站之间协商好的秘钥K AF或K s_NAF，对秘钥请求信息进行加密或完成性保护，得到第一MAC。
可选地，UE可以使用自己的私钥对秘钥请求信息的内容或部分内容进行签名，得到第一MAC。
步骤602、基站向UE发送初始秘钥信息，该初始秘钥信息中包括与UE关联的n个零功耗设备ZPD初始秘钥。
若ZPD的数量仅为一个(即n取值为1)，则初始秘钥信息中可以包括一个标识信息-初始秘钥对，即(ID ZP1，K ZP1)。若ZPD的数量为多个(即n取值大于1)，则初始秘钥信息中可以包括n个标识信息-初始秘钥对：(ID ZP1，K ZP1)，(ID ZP2，K ZP2)，(ID ZP3,K ZP3)，……，(ID ZPn，K ZPn)。其中，ID ZP1即零功耗设备1的标识信息，K ZP1即零功耗设备1的初始秘钥，以此类推，ID ZPn即零功耗设备n的标识信息，K ZPn即零功耗设备n的初始秘钥。
可选地，初始秘钥可以是对称秘钥，第二设备的本地存储空间中也可以存储自己的初始秘钥。
可选地，当秘钥请求信息中包括业务标识信息和/或数据标识信息时，基站可以基于业务标识信息和/或数据标识信息对n个ZPD进行验证，判断n个ZPD是否具有使用该业务标识信息和/或数据标识信息对应的业务的权限。并且，只有在n个ZPD验证通过后，基站才向UE发送初始秘钥信息。
其中，基站可以判断本地保存的业务标识信息与秘钥请求信息中携带的ID SP是否一致，和/或判断本地保存的数据标识信息与秘钥请求信息中携带的ID DATA是否一致。若一致，则基站确定至少一个第二设备验证通过，至少一个第二设备具有使用该业务标识信息和/或数据标识信息对应业务的权限，若不一致，则基站确定至少一个第二设备验证失败。
可选地，基站在接收到第一设备发送的秘钥请求信息后，首先可以对UE的身份进行认证，以确定发送秘钥请求信息的UE是否是可信任的设备。进一步地，在对UE的身份认证通过后，基站才向UE发送初始秘钥信息。
可选地，基站可以基于第一MAC，对UE的身份进行认证,。
在一种可能的实现方式中，若第一MAC是根据UE与基站协商的秘钥K AF或K s_NAF生成的，则基站可以利用该秘钥K AF或K s_NAF对第一MAC进行验证。
在另一种可能的实现方式中，若第一MAC时根据UE的私钥生成的，则基站可以使用UE的证书或者UE的公钥对第一MAC进行验证。
步骤603、UE分别与n个ZPD进行初始认证。
应理解，UE确定n个ZPD的初始秘钥之后，可以基于每个ZPD的初始秘钥与每个ZPD进行初始认证，以确定彼此是可信的设备，防止数据泄露和窃取。
需要说明的是，UE与每个ZPD之间的认证过程可以参考相关技术中的认证过程，为了简洁，此处不做赘述。
步骤604、UE基于业务共享秘钥Kservice和每个ZPD对应的初始秘钥，生成设备秘钥Secret。
可选地，UE可以直接基于业务共享秘钥Kservice和每个ZPD对应的初始秘钥，生成设备秘钥Secret。
示例性的，若ZPD的数量为1，则设备秘钥Secret即为Kservice和该ZPD的初始秘钥汇聚后的结果。若ZPD的数量包括多个，则UE可以将Kservice和每个ZPD的初始秘钥进行汇聚处理，得到上述设备秘钥Secret。其中，汇聚处理可以是将多个秘钥直连处理。
可选地，UE可以基于每个ZPD的初始秘钥，与该ZPD进行物理层安全机制的协商处理，生成各个ZPD对应的中间秘钥。进而，UE可以基于业务共享秘钥Kservice和每个ZPD的中间秘钥，生成设备秘钥Secret。
示例性的，若ZPD的数量为1，则设备秘钥Secret即为业务共享秘钥Kservice和该ZPD的中间秘钥汇聚后的结果。若ZPD的数量包括多个，则UE可以将业务共享秘钥Kservice和每个ZPD的中间秘钥进行汇聚处理，得到上述设备秘钥Secret。其中，汇聚处理可以是将多个秘钥直连处理。
步骤605、UE生成设备绑定验证码DAC，和/或，业务验证码SAC。其中，DAC用于验证UE与n个ZPD之间的关联关系；SAC用于验证UE和/或n个ZPD是否支持ID SP指示的业务类型，和/或，UE和/或n个ZPD是否支持ID DATA指示的数据类型。
本申请实施例中，UE可以基于设备秘钥Secret，生成设备绑定验证码DAC。示例性的，UE可以参考公式(1)来计算DAC。
本申请实施例中，UE可以基于ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT中的至少一项，生成业务验证码SAC。
可选地，UE可以利用其私钥对ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT在内的至少一项信息进行签名，得到SAC。具体计算方式可以参考公式(2)，此处不做赘述。
可选地，UE可以利用业务共享秘钥Kservice，对ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT中的至少一项进行加密和完整性保护，得到SAC。具体计算方式可以参考公式(3)，此处 不做赘述。
步骤606、UE向基站发送凭证请求信息，凭证请求信息用于请求n个ZPD的授权凭证。
本申请实施例中，凭证请求信息中可以包括DAC和/或SAC，以及ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、和第二MAC中的至少一项。
其中，第二MAC可以是UE使用自己的私钥，对凭证请求信息中其他的全部信息或部分信息进行签名处理得到。该第二MAC用于验证凭证请求信息的发送方是否为合法设备。
可选地，UE可以直接向应用服务器发送凭证请求信息。
步骤607、基站对凭证请求信息中的DAC进行验证。
本申请实施例中，基站可以通过DAC来确定UE与n个ZPD是否具有真实的关联关系。
具体地，基站可以基于设备秘钥Secret，生成第一校验信息。其中，基站可以参考上述公式(1)来生成第一校验信息。若第一校验信息与凭证请求信息中的DAC一致，可以认为UE与n个ZPD之间真实存在关联关系，基站确定DAC验证通过。若第一校验信息与DAC不一致，则认为UE与n个ZPD之间的关联关系错误或不存在，基站确定DAC验证不通过。
其中，基站可以从UE处获取设备秘钥Secret，也可以从其他受信任的设备(例如UDM网元、应用服务器等)处获取设备秘钥Secret。基站还可以基于业务共享秘钥Kservice和每个第二设备的初始秘钥，生成该设备秘钥Secret。本申请实施例对此不做限制。
步骤608、基站在对DAC验证通过的情况下，向应用服务器发送凭证请求信息。
可选地，基站在确定了UE与n个ZPD之间真实存在关联关系之后，可以将凭证请求信息转发给ID SP和/或ID DATA对应的应用服务器。
步骤609、在对SAC验证通过的情况下，应用服务器为n个ZPD生成授权凭证。
可以理解的是，应用服务器接收到凭证请求信息之后，通过SAC来验证UE和/或n个ZPD支持的业务类型是否是ID SP指示的业务类型，和/或，UE和/或n个ZPD支持的数据类型是否是ID DATA指示的数据类型。
可选地，若SAC是利用UE的私钥对ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT在内的至少一项信息进行签名得到，则应用服务器可以利用UE的公钥对SAC进行验证。
具体地，应用服务器可以通过UE的公钥对SAC进行验证，得到第二校验信息。若第二校验信息与凭证请求信息中携带的ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT至少一项信息一致，则确定SAC验证通过。否则，确定SAC验证不通过。
可选地，在另一些实施例中，若SAC是利用业务共享秘钥Kservice，对ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT在内的至少一项信息进行安全运算得到，则应用服务器可以利用业务共享秘钥Kservice，对SAC进行验证。
具体地，应用服务器首先可以基于业务共享秘钥Kservice，对ID UE、{ID ZP1、…、ID ZPn}、ID SP、ID DATA、NONCE、COUNT在内的至少一项信息进行安全运算，得到第三校验信息；其中，应用服务器可以参考上述公式(3)来生成第三校验信息。若第三校验信息与所述SAC一致，则应用服务器确定SAC验证通过。否者，确定SAC验证不通过。
本申请实施例中，应用服务器在对SAC验证通过后，可以为n个ZPD生成授权凭证。
可选地，应用服务器在生成授权凭证之前，可以为每个ZPD生成RSA累加器参数α ZP。其中，每个ZPD的RSA累加器参数α ZP可以用于证明该ZPD的是否被撤销。
可选地，授权凭证中可以包括：ID UE、pk UE、{ID ZP1、…、ID ZPn}、DAC、α ZP1、…、α ZPn、ID SP、ID IS、ID DATA、Sig skIS中的至少一项。
其中，pk UE为UE的公钥，ID IS为应用服务器IS的标识信息，Sig skIS是应用服务器利用自己的私钥对上述授权凭证中的其他信息进行签名得到。
示例性的，ZPD的数量为1时，该ZPD的授权凭证可以为：Cert IS->ZP([ID ZP1，DAC]，α ZP1，ID UE，ID IS，ID SP，Sig skIS)。ZPD的数量大于1时，ZPD授权凭证可以为：Cert IS->ZPg([ID ZP1，…，ID ZPn，DAC]，α ZP1，…，α ZPn，ID UE，ID IS，ID SP，Sig skIS)。其中，α ZP1，…，α ZPn分别为n个第二设备对应的RSA累加器参数。
需要说明的是，当业务标识信息ID SP为应用服务器的ID时，ID SP和ID IS相同，则应用服务器可以仅使用其中的一种来生成授权凭证。
步骤610、应用服务器将授权凭证上传到区块链节点的存储区块。
步骤611、应用服务器获取该授权凭证的存储位置信息，并向UE发送授权凭证，和/或，该授权凭证的存储位置信息。
综上所述，本申请实施例提供的安全实现方法中，UE可以作为中间代理设备，为其关联的多个零功耗设备实现安全运算，以获得多个零功耗设备的授权凭证。也就是说，可以借用UE与应用服务器进行交互，以使应用服务器为多个零功耗设备生成轻量级的群组授权凭证，以便对零功耗设备的上行数据传输进行授权，避免攻击者或者伪基站恶意触发零功耗设备的上行数据传输，保证零功耗设备的上行传输数据的安全，提高零功耗设备的授权的效率。
以上结合附图详细描述了本申请的优选实施方式，但是，本申请并不限于上述实施方式中的具体细节，在本申请的技术构思范围内，可以对本申请的技术方案进行多种简单变型，这些简单变型均属于本申请的保护范围。例如，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本申请对各种可能的组合方式不再另行说明。又例如，本申请的各种不同的实施方式之间也可以进行任意组合，只要其不违背本申请的思想，其同样应当视为本申请所公开的内容。又例如，在不冲突的前提下，本申请描述的各个实施例和/或各个实施例中的技术特征可以和现有技术任意的相互组合，组合之后得到的技术方案也应落入本申请的保护范围。
还应理解，在本申请的各种方法实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。此外，在本申请实施例中，术语“下行”、“上行”和“侧行”用于表示信号或数据的传输方向，其中，“下行”用于表示信号或数据的传输方向为从站点发送至小区的用户设备的第一方向，“上行”用于表示信号或数据的传输方向为从小区的用户设备发送至站点的第二方向，“侧行”用于表示信号或数据的传输方向为从用户设备1发送至用户设备2的第三方向。例如，“下行信号”表示该信号的传输方向为第一方向。另外，本申请实施例中，术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。具体地，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
图7是本申请实施例提供的安全实现装置700的结构组成示意图，应用于第一网元，如图7所示，所述安全实现装置700包括：
第一接收单元701，被配置为接收第一信息；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
可选地，所述第一信息中还包括以下中的至少一项：
业务标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的业务类型；
数据标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的数据类型；
所述第一设备的标识信息；
所述至少一个第二设备中每个第二设备的标识信息；
设备秘钥Secret；
所述第一信息对应的第一信息验证码MAC；第一MAC用于验证所述第一信息的发送方是否为合法设备。
可选地，所述第一信息用于请求与所述第一设备关联的所述至少一个第二设备发放授权凭证；所述安全实现装置700还包括：
凭证生成单元，被配置为在对所述DAC和/或所述SAC验证通过的情况下，为所述至少一个第二设备生成授权凭证。
可选地，所述安全实现装置700还包括验证单元，被配置为：基于设备秘钥Secret，生成第一校验信息；若所述第一校验信息与所述DAC一致，则确定所述DAC验证通过。
可选地，所述验证单元，还被配置为基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的初始秘钥，生成所述设备秘钥Secret，其中，所述业务共享秘钥Kservice为所述第一网元与所述第一设备之间的共享秘钥。
可选地，所述验证单元，还被配置为基于业务共享秘钥Kservice，和/或，每个第二设备的初始秘钥，计算每个第二设备的中间秘钥；基于业务共享秘钥Kservice和/或，所述至少一个第二设备中每个第二设备的中间秘钥，生成所述设备秘钥Secret。
可选地，所述SAC是利用所述第一设备的私钥对所述第一设备的标识标识信息、每个第二设备 的标识信息、业务标识信息、以及数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项信息进行签名得到；
对应的，所述验证单元，还被配置为利用所述第一设备的公钥对所述SAC进行验证，得到第二校验信息；若所述第二校验信息与所述第一信息中携带的所述第一设备的标识信息、每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT一致，则确定所述SAC验证通过。
可选地，所述SAC是利用业务共享秘钥Kservice，对所述第一设备的标识信息、所述至少一个第二设备中每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT中的至少一项进行安全运算得到；
对应的，所述验证单元，还被配置为基于所述业务共享秘钥Kservice，对所述第一设备的标识信息、所述每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、所述随机数NONCE、以及所述计数器参数COUNT中的至少一项进行安全运算，得到第三校验信息；若所述第三校验信息与所述SAC一致，则确定所述SAC验证通过。
可选地，所述授权凭证包括以下中的至少一项：
所述第一设备的标识信息；
所述第一设备的公钥；
所述至少一个第二设备中每个第二设备的标识信息；
所述至少一个第二设备中每个第二设备的RSA累加器参数；
所述第一网元的标识信息；
所述第一网元的公钥；
业务标识信息；
数据标识信息；
设备绑定验证码DAC；
所述第一网元的数字签名；所述数字签名是基于所述第一网元的私钥对所述授权凭证中其他信息进行签名得到。
可选地，所述安全实现装置700还包括第一发送单元，被配置为向区块链节点发送所述授权凭证；所述第一接收单元701，还被配置为获取所述授权凭证的存储位置信息。
可选地，第一发送单元，还配置为向所述第一设备发送授权凭证，和/或，所述存储位置信息。
图8是本申请实施例提供的安全实现装置800的结构组成示意图，应用于第一设备，如图8所示，所述安全实现装置800包括：
第二发送单元801，被配置为发送第一信息；所述第一设备与至少一个第二设备关联；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
可选地，所述第一信息还包括以下中的至少一项：
业务标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的业务类型；
数据标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的数据类型；
所述第一设备的标识信息；
所述至少一个第二设备中每个第二设备的标识信息；
设备秘钥Secret；
所述第一信息对应的第一信息验证码MAC；第一MAC用于验证所述第一信息的发送方是否为合法设备。
可选地，所述安全实现装置800还包括处理单元，被配置为基于设备秘钥Secret，生成所述设备绑定验证码DAC；和/或，基于第一设备的标识信息、每个第二设备的标识信息、业务标识信息、以及数据标识信息在内的至少一项，生成业务验证码SAC。
可选地，所述处理单元，还被配置基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的初始秘钥，生成所述设备秘钥Secret；其中，所述业务共享秘钥Kservice为第一网元与第一设备之间的共享秘钥。
可选地，所述处理单元，还被配置为基于每个第二设备的初始秘钥，生成每个第二设备的中间秘钥；基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的中间秘钥，生成所述设备秘钥Secret。
可选地，所述第二发送单元801，还被配置为向第二网元发送秘钥请求信息；所述秘钥请求信息用于请求与所述第一设备关联的至少一个第二设备的初始秘钥。
可选地，所述安全实现装置800还包括第二接收单元，被配置为接收所述第二网元发送的初始秘钥信息；所述初始秘钥信息中包括每个第二设备的初始秘钥。
可选地，所述秘钥请求信息还包括以下中的至少一项：
第一设备的标识信息；
至少一个第二设备中每个第二设备的标识信息；
业务标识信息；
数据标识信息；
所述秘钥请求信息对应的第二MAC；所述第二MAC用于验证所述秘钥请求信息的发送方是否为合法设备。
可选地，所述处理单元，还被配置为利用所述第一设备的私钥对所述第一设备的标识信息、所述每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项信息进行签名，得到所述SAC。
可选地，所述处理单元，还被配置为基于业务共享秘钥Kservice，对所述第一设备的标识信息、所述每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT中的至少一项进行安全运算，生成所述SAC。
可选地，所述第一信息用于请求与所述第一设备关联的至少一个第二设备的授权凭证。
本领域技术人员应当理解，本申请实施例的上述安全实现装置的相关描述可以参照本申请实施例的安全实现方法的相关描述进行理解。
图9是本申请实施例提供的一种通信设备900示意性结构图。该通信设备可以是第一网元，也可以是第一设备。图9所示的通信设备900包括处理器910，处理器910可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图9所示，通信设备900还可以包括存储器920。其中，处理器910可以从存储器920中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器920可以是独立于处理器910的一个单独的器件，也可以集成在处理器910中。
可选地，如图9所示，通信设备900还可以包括收发器930，处理器910可以控制该收发器930与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。
其中，收发器930可以包括发射机和接收机。收发器930还可以进一步包括天线，天线的数量可以为一个或多个。
可选地，该通信设备900具体可为本申请实施例的第一网元，并且该通信设备900可以实现本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该通信设备900具体可为本申请实施例的第一设备，并且该通信设备1800可以实现本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
图10是本申请实施例的芯片的示意性结构图。图10所示的芯片1000包括处理器1010，处理器1010可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图10所示，芯片1900还可以包括存储器1020。其中，处理器1010可以从存储器1020中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器1020可以是独立于处理器1010的一个单独的器件，也可以集成在处理器100中。
可选地，该芯片1000还可以包括输入接口1030。其中，处理器1010可以控制该输入接口1030与其他设备或芯片进行通信，具体地，可以获取其他设备或芯片发送的信息或数据。
可选地，该芯片1000还可以包括输出接口1040。其中，处理器1010可以控制该输出接口1040与其他设备或芯片进行通信，具体地，可以向其他设备或芯片输出信息或数据。
可选地，该芯片可应用于本申请实施例中的第一网元，并且该芯片可以实现本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该芯片可应用于本申请实施例中的第一设备，并且该芯片可以实现本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。
图11是本申请实施例提供的一种通信系统1100的示意性框图。如图11所示，该通信系统1100包括第一设备1110和第一网元1120。
其中，该第一设备1110可以用于实现上述方法中由第一设备实现的相应的功能，以及该第一网元1120可以用于实现上述方法中由第一网元实现的相应的功能为了简洁，在此不再赘述。
应理解，本申请实施例的处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
应理解，上述存储器为示例性但不是限制性说明，例如，本申请实施例中的存储器还可以是静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synch link DRAM，SLDRAM)以及直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)等等。也就是说，本申请实施例中的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。
可选的，该计算机可读存储介质可应用于本申请实施例中的第一网元，并且该计算机程序使得计算机执行本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机可读存储介质可应用于本申请实施例中的第一设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种计算机程序产品，包括计算机程序指令。
可选的，该计算机程序产品可应用于本申请实施例中的第一网元，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机程序产品可应用于本申请实施例中的第一设备，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种计算机程序。
可选的，该计算机程序可应用于本申请实施例中的第一网元，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该计算机程序可应用于本申请实施例中的第一设备，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，)ROM、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (34)

  1. 一种安全实现方法，所述方法包括：
    第一网元接收第一信息；所述第一信息包括设备绑定验证码DAC，和/或，业务验证码SAC；其中，DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
  2. 根据权利要求1所述的方法，其中，所述第一信息中还包括以下中的至少一项：
    业务标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的业务类型；
    数据标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的数据类型；
    所述第一设备的标识信息；
    所述至少一个第二设备中每个第二设备的标识信息；
    设备秘钥Secret；
    所述第一信息对应的第一信息验证码MAC；第一MAC用于验证所述第一信息的发送方是否为合法设备。
  3. 根据权利要求1或2所述的方法，其中，所述第一信息用于请求与所述第一设备关联的所述至少一个第二设备发放授权凭证；
    所述方法还包括：
    在对所述DAC和/或所述SAC验证通过的情况下，所述第一网元为所述至少一个第二设备生成授权凭证。
  4. 根据权利要求3所述的方法，其中，还包括：
    所述第一网元基于设备秘钥Secret，生成第一校验信息；
    若所述第一校验信息与所述DAC一致，则所述第一网元确定所述DAC验证通过。
  5. 根据权利要求4所述的方法，其中，所述第一网元基于设备秘钥Secret，生成第一校验信息之前，还包括：
    所述第一网元基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的初始秘钥，生成所述设备秘钥Secret；
    其中，所述业务共享秘钥Kservice为所述第一网元与所述第一设备之间的共享秘钥。
  6. 根据权利要求5所述的方法，其中，所述第一网元基于业务共享秘钥Kservice，和/或，每个第二设备的初始秘钥，计算所述设备秘钥Secret，包括：
    所述第一网元基于每个第二设备的初始秘钥，计算每个第二设备的中间秘钥；
    所述第一网元基于所述业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的中间秘钥，生成所述设备秘钥Secret。
  7. 根据权利要求3-6任一项所述的方法，其中，所述SAC基于所述第一设备的私钥对所述第一设备的标识标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项信息进行签名得到；
    对应的，所述方法还包括：
    所述第一网元利用所述第一设备的公钥对所述SAC进行验证，得到第二校验信息；
    若所述第二校验信息与所述第一信息中携带的所述第一设备的标识信息、每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、所述随机数NONCE、以及所述计数器参数COUNT一致，则所述第一网元确定所述SAC验证通过。
  8. 根据权利要求3-6任一项所述的方法，其中，所述SAC是基于业务共享秘钥Kservice，对所述第一设备的标识信息、所述至少一个第二设备中每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT中的至少一项进行安全运算得到；
    对应的，所述方法还包括：
    所述第一网元基于所述业务共享秘钥Kservice，对所述第一设备的标识信息、所述每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT 中的至少一项进行安全运算，得到第三校验信息；
    若所述第三校验信息与所述SAC一致，则所述第一网元确定所述SAC验证通过。
  9. 根据权利要求3-8任一项所述的方法，其中，所述授权凭证包括以下中的至少一项：
    所述第一设备的标识信息；
    所述第一设备的公钥；
    所述至少一个第二设备中每个第二设备的标识信息；
    所述至少一个第二设备中每个第二设备的RSA累加器参数；
    所述第一网元的标识信息；
    所述第一网元的公钥；
    业务标识信息；
    数据标识信息；
    设备绑定验证码DAC；
    所述第一网元的数字签名；所述数字签名是基于所述第一网元的私钥对所述授权凭证中其他信息进行签名得到。
  10. 根据权利要求3-9任一项所述的方法，其中，还包括：
    所述第一网元向区块链节点发送所述授权凭证；
    所述第一网元获取所述授权凭证的存储位置信息。
  11. 根据权利要求10所述的方法，其中，还包括：
    所述第一网元向所述第一设备发送所述授权凭证，和/或，所述存储位置信息。
  12. 一种安全实现方法，所述方法包括：
    第一设备发送第一信息；所述第一设备与至少一个第二设备关联；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证所述第一设备与所述至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
  13. 根据权利要求12所述的方法，其中，所述第一信息还包括以下中的至少一项：
    业务标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的业务类型；
    数据标识信息；所述业务标识信息用于指示所述第一设备和/或所述至少一个第二设备支持的数据类型；
    所述第一设备的标识信息；
    所述至少一个第二设备中每个第二设备的标识信息；
    设备秘钥Secret；
    所述第一信息对应的第一信息验证码MAC；第一MAC用于验证所述第一信息的发送方是否为合法设备。
  14. 根据权利要求12或13所述的方法，其中，所述第一设备发送第一信息之前，还包括：
    所述第一设备基于设备秘钥Secret，生成DAC；
    和/或，
    所述第一设备基于第一设备的标识信息、每个第二设备的标识信息、业务标识信息、以及数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项，生成SAC。
  15. 根据权利要求14所述的方法，其中，所述第一设备基于设备秘钥Secret，生成DAC之前，还包括：
    所述第一设备基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的初始秘钥，计算所述设备秘钥Secret；
    其中，所述业务共享秘钥Kservice为所述第一网元与所述第一设备之间的共享秘钥。
  16. 根据权利要求14所述的方法，其中，所述第一设备基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的标识信息，生成所述设备秘钥Secret，包括：
    所述第一设备基于每个第二设备的初始秘钥，生成每个第二设备的中间秘钥；
    所述第一设备基于业务共享秘钥Kservice，和/或，所述至少一个第二设备中每个第二设备的中间秘钥，生成所述设备秘钥Secret。
  17. 根据权利要求15或16所述的方法，其中，所述第一设备基于所述至少一个第二设备中每 个第二设备的标识信息，生成所述设备秘钥Secret之前，还包括：
    所述第一设备向第二网元发送秘钥请求信息；所述秘钥请求信息用于请求与所述第一设备关联的至少一个第二设备的初始秘钥。
  18. 根据权利要求17所述的方法，其中，还包括：
    所述第一设备接收所述秘第二网元发送的初始秘钥信息；所述初始秘钥信息中包括每个第二设备的初始秘钥。
  19. 根据权利要求17或18所述的方法，其中，所述秘钥请求信息还包括以下中的至少一项：
    第一设备的标识信息；
    至少一个第二设备中每个第二设备的标识信息；
    业务标识信息；
    数据标识信息；
    所述秘钥请求信息对应的第二MAC；所述第二MAC用于验证所述秘钥请求信息的发送方是否为合法设备。
  20. 根据权利要求14-19任一项所述的方法，其中，所述第一设备基于第一设备的标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项，生成SAC，包括：
    所述第一设备利用其私钥对所述第一设备的标识信息、所述每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项信息进行签名，得到所述SAC。
  21. 根据权利要求14-19任一项所述的方法，其中，所述第一设备基于第一设备的标识信息、每个第二设备的标识信息、业务标识信息、数据标识信息、随机数NONCE、以及计数器参数COUNT在内的至少一项，生成SAC，包括：
    所述第一设备基于业务共享秘钥Kservice，对所述第一设备的标识信息、所述每个第二设备的标识信息、所述业务标识信息、所述数据标识信息、随机数NONCE、以及计数器参数COUNT中的至少一项进行安全运算，生成所述SAC。
  22. 根据权利要求12-21任一项所述的方法，其中，所述第一信息用于请求与所述第一设备关联的至少一个第二设备的授权凭证。
  23. 一种安全实现装置，应用于第一网元，包括：
    第一接收单元，被配置为接收第一信息；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证第一设备与至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
  24. 一种安全实现装置，应用于第一设备，所述第一设备与至少一个第二设备关联；包括：
    第二发送单元，被配置为发送第一信息；所述第一信息中包括设备绑定验证码DAC，和/或，业务验证码SAC；DAC用于验证所述第一设备与所述至少一个第二设备之间的关联关系，SAC用于验证所述第一设备和/或所述至少一个第二设备是否支持业务标识信息指示的业务类型，和/或，所述第一设备和/或所述至少一个第二设备是否支持数据标识信息指示的数据类型。
  25. 一种第一网元，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求1至11中任一项所述的方法。
  26. 一种第一设备，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求12至22中任一项所述的方法。
  27. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求1至11中任一项所述的方法。
  28. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求12至22中任一项所述的方法。
  29. 一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1至11中任一项所述的方法。
  30. 一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求12至22中任一项所述的方法。
  31. 一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如权利要求1至11中任一项所述的方法。
  32. 一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如权利要求12至22中任一项所述的方法。
  33. 一种计算机程序，所述计算机程序使得计算机执行如权利要求1至11中任一项所述的方法。
  34. 一种计算机程序，所述计算机程序使得计算机执行如权利要求12至22中任一项所述的方法。
PCT/CN2022/083170 2022-03-25 2022-03-25 安全实现方法及装置、设备、网元 WO2023178689A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/083170 WO2023178689A1 (zh) 2022-03-25 2022-03-25 安全实现方法及装置、设备、网元

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/083170 WO2023178689A1 (zh) 2022-03-25 2022-03-25 安全实现方法及装置、设备、网元

Publications (1)

Publication Number Publication Date
WO2023178689A1 true WO2023178689A1 (zh) 2023-09-28

Family

ID=88099597

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/083170 WO2023178689A1 (zh) 2022-03-25 2022-03-25 安全实现方法及装置、设备、网元

Country Status (1)

Country Link
WO (1) WO2023178689A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101084643A (zh) * 2004-12-21 2007-12-05 Emue控股集团公司 认证装置和/或方法
US20160285633A1 (en) * 2015-03-27 2016-09-29 Yahoo!, Inc. Facilitation of service login
US20190335332A1 (en) * 2017-01-06 2019-10-31 Huawei Technologies Co., Ltd. Authorization and Verification Method and Apparatus
CN113407910A (zh) * 2020-03-17 2021-09-17 北京华为数字技术有限公司 一种程序运行方法、程序加壳方法及设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101084643A (zh) * 2004-12-21 2007-12-05 Emue控股集团公司 认证装置和/或方法
US20160285633A1 (en) * 2015-03-27 2016-09-29 Yahoo!, Inc. Facilitation of service login
US20190335332A1 (en) * 2017-01-06 2019-10-31 Huawei Technologies Co., Ltd. Authorization and Verification Method and Apparatus
CN113407910A (zh) * 2020-03-17 2021-09-17 北京华为数字技术有限公司 一种程序运行方法、程序加壳方法及设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ERICSSON: "Editorials and minor clarifications for clause 13.2", 3GPP DRAFT; S3-190439_WAS_S3-190090_EDITORIALS_CLAUSE_13-2, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Kochi (India); 20190128 - 20190201, 29 January 2019 (2019-01-29), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051595864 *

Similar Documents

Publication Publication Date Title
RU2663972C1 (ru) Обеспечение безопасности при связи между устройством связи и сетевым устройством
CN107005927B (zh) 用户设备ue的接入方法、设备及系统
US10904753B2 (en) Systems and methods for authentication
CN112514436B (zh) 发起器和响应器之间的安全的、被认证的通信
US9668139B2 (en) Secure negotiation of authentication capabilities
KR102119586B1 (ko) 통신 네트워크를 통해 데이터를 릴레이하는 시스템 및 방법
WO2007004824A1 (en) Authentication system and method thereof in a communication system
CN110351725B (zh) 通信方法和装置
US20200275270A1 (en) Agent-based authentication and key agreement method for devices without sim card
WO2023283789A1 (zh) 一种安全通信方法及装置、终端设备、网络设备
CN112492590A (zh) 一种通信方法及装置
CN112449323A (zh) 一种通信方法、装置和系统
CN111615837B (zh) 数据传输方法、相关设备以及系统
CN101436931B (zh) 无线通信系统中提供安全通信的方法、系统、基站与中继站
WO2023178691A1 (zh) 安全实现方法、装置、设备及网元
EP4250791A1 (en) Wifi security authentication method and communication apparatus
US8036133B2 (en) Efficient techniques for error detection and authentication in wireless networks
WO2023178689A1 (zh) 安全实现方法及装置、设备、网元
WO2022237741A1 (zh) 一种通信方法及装置
CN110226319A (zh) 用于紧急接入期间的参数交换的方法和设备
WO2023159603A1 (zh) 一种安全实现方法及装置、终端设备、网元
CN116528234B (zh) 一种虚拟机的安全可信验证方法及装置
WO2023178686A1 (zh) 安全实现方法、装置、终端设备、网元、及凭证生成设备
EP4322457A1 (en) Improved security establishment methods and systems
EP4322455A1 (en) Improved security establishment methods and systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22932750

Country of ref document: EP

Kind code of ref document: A1