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

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

Info

Publication number
WO2023178691A1
WO2023178691A1 PCT/CN2022/083173 CN2022083173W WO2023178691A1 WO 2023178691 A1 WO2023178691 A1 WO 2023178691A1 CN 2022083173 W CN2022083173 W CN 2022083173W WO 2023178691 A1 WO2023178691 A1 WO 2023178691A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
data
authorization
information
certificate
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2022/083173
Other languages
English (en)
French (fr)
Inventor
甘露
刘雪峰
邹继鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
Guangdong Oppo Mobile Telecommunications Corp Ltd
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 Guangdong Oppo Mobile Telecommunications Corp Ltd filed Critical Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority to CN202280093484.1A priority Critical patent/CN118946888A/zh
Priority to PCT/CN2022/083173 priority patent/WO2023178691A1/zh
Priority to EP22932752.3A priority patent/EP4502844A4/en
Publication of WO2023178691A1 publication Critical patent/WO2023178691A1/zh
Priority to US18/895,027 priority patent/US20250016005A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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
    • 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
    • H04L9/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • H04L9/3247—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 involving digital signatures
    • 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/40—Network security protocols
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications

Definitions

  • the embodiments of this 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 full functions, and therefore will not be able to support 3rd Generation Partnership Project (3GPP) devices.
  • 3GPP 3rd Generation Partnership Project
  • Authentication mechanism Based on this, there is currently no clear solution for how zero-power devices or other low-capability devices authorize devices requesting their data for secure data transmission.
  • 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 device obtains the authorization certificate of the first network element; the authorization certificate is used to verify whether the first network element has the authority to receive data; the data comes from at least one second device associated with the first device ;
  • the authorization certificate includes a first digital signature;
  • the first device determines that the first network element has the authority to receive data sent by the at least one second device.
  • the embodiment of this application also provides a security implementation method, including:
  • the first network element sends second request information to the first device.
  • the second request information is used to request the first device to grant the first network element permission to obtain data of at least one second device.
  • the second device has an association relationship with the first device;
  • the second request information includes an authorization credential
  • the authorization credential is used by the first device to verify whether the first network element has the authority to receive data from the at least one second device; the authorization credential is passed through it. Include the first digital signature for verification.
  • the embodiment of this application also provides another security implementation method, including:
  • the certificate issuance device receives the fifth request information sent by the first network element; the fifth request information is used to request the authorization certificate of the first network element; the authorization certificate is used by the first device to verify whether the first network element has the authority to obtain data; the data From at least one second device associated with the first device; the certificate issuing device generates the authorization certificate of the first network element.
  • the embodiment of the present application provides a security implementation device, applied to the first device, including:
  • the first receiving unit is configured to obtain the authorization certificate of the first network element; the authorization certificate is used to verify whether the first network element has the authority to receive data; the data comes from at least one second device associated with the first device; the authorization certificate Includes first digital signature;
  • the determining unit is configured to determine that the first network element has the authority to receive data sent by at least one second device when the authorization certificate is verified based on the first digital signature.
  • the embodiment of the present application also provides a security implementation device, which is applied to the first network element and includes:
  • the second sending unit is configured to send second request information to the first device.
  • the second request information is used to request the first device to grant the first network element permission to obtain data of at least one second device.
  • the at least one second device is related to The first device has an association relationship; wherein the second request information includes an authorization credential, and the authorization credential is used by the first device to verify whether the first network element has the authority to receive data from at least one second device; the authorization credential passes through the third element it includes. A digital signature is verified.
  • the embodiment of this application also provides another security implementation device, which is applied to the voucher issuance equipment, including:
  • the third receiving unit is configured to receive the fifth request information sent by the first network element; the fifth request information is used to request the authorization certificate of the first network element; the authorization certificate is used by the first device to verify whether the first network element has the ability to obtain Permissions for data; the data comes from at least one second device associated with the first device; and a credential generation unit configured to generate an authorization credential for the first network element.
  • 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 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 credential generation 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, configured to call and run a computer program from the memory, so that the device installed 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 verify the authorization certificate of the first network element on behalf of at least one second device associated with it. If the verification passes, the first device may determine that the first network element has the authority to receive data from at least one second device. In this way, the second device with low computing power can verify the network elements on the network side, avoid theft and leakage problems during the data transmission of the second device, and ensure the security of data transmission of the second device.
  • 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 flow chart 6 of a security implementation method provided by an embodiment of the present application.
  • Figure 8 is a schematic flow chart of the security implementation method in application scenario one provided by the embodiment of the present application.
  • Figure 9 is a schematic flow chart of the security implementation method in application scenario two provided by the embodiment of the present application.
  • Figure 10 is a schematic flow chart 2 of the security implementation method in application scenario 2 provided by the embodiment of the present application.
  • Figure 11 is a schematic flowchart of the security implementation method in application scenario three provided by the embodiment of the present application.
  • Figure 12 is a schematic flowchart 1 of the security implementation method in application scenario 4 provided by the embodiment of the present application;
  • Figure 13 is a schematic flowchart 2 of the security implementation method in application scenario 4 provided by the embodiment of the present application;
  • Figure 14 is a schematic flow chart of the security implementation method in application scenario five provided by the embodiment of the present application.
  • Figure 15 is a schematic flowchart two of the security implementation method in application scenario five provided by the embodiment of the present application.
  • Figure 16 is a schematic structural diagram of a security implementation device 1600 provided by an embodiment of the present application.
  • Figure 17 is a schematic structural diagram of a security implementation device 1700 provided by an embodiment of the present application.
  • Figure 18 is a schematic structural diagram of a security implementation device 1800 provided by an embodiment of the present application.
  • Figure 19 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • Figure 20 is a schematic structural diagram of a chip according to an embodiment of the present application.
  • Figure 21 is a schematic block diagram of a communication system provided by an embodiment of the present application.
  • FIG. 1 is a schematic diagram of the network architecture of a communication system according to an 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 (e.g., UEs) located within the coverage area.
  • terminal devices 110 e.g., 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 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 a base station, a core network device and two terminal devices.
  • the wireless communication system 100 may include multiple base station devices and other numbers of terminals may be included within the coverage of each base station.
  • Equipment the embodiments of this application do not limit this.
  • 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 devices are very limited and cannot support security functions such as those defined by SHA-256, let alone the authentication mechanism of 3GPP. Therefore, how zero-power devices or other low-capacity devices authorize the transmission of uplink data to prevent attackers or pseudo base stations from maliciously triggering the device's uplink data transmission and ensure the security of uplink data transmission is an urgent technical issue that needs to be solved.
  • the embodiment of the present application provides a security implementation method, as shown in Figure 2.
  • the method includes but is not limited to the following steps:
  • Step 210 The first device obtains the authorization certificate of the first network element; the authorization certificate is used to verify whether the first network element has the authority to receive data; the data comes from at least one second device associated with the first device; the authorization certificate includes First digital signature.
  • Step 220 If the authorization certificate is successfully verified based on the first digital signature, the first device determines that the first network element has the authority to receive data sent by at least one second device.
  • the first device may be a device that supports the device authentication mechanism algorithm.
  • the first device may be a user equipment UE, a base station, and 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 second device since the computing power of the second device is low, the second device can be bound to the first device to form an association relationship. In this way, the second device can utilize the complete capabilities of the associated first device. Computing capabilities and/or communication mechanisms enable authorization of network elements on the network side.
  • the first device may be bound to one or more second devices.
  • the second device may communicate with the first device through a technology that modulates incoming wave signals to achieve backscattering.
  • the first network element mentioned in the embodiment of this application may be a network element on the network side, where the first network element may be a core network element, an access network element, a network element in a third-party application network, etc.
  • the first network element may be a sensing server, and the sensing server may be an application server that provides sensing services (such as positioning, speed measurement, and health calling services).
  • the first network element when the first device is a UE, the first network element may be a base station or an application server. When the first device is a base station, the first network element may be an application server.
  • the first device can obtain the authorization certificate of the first network element, and verify whether the first network element has the authority to obtain data of at least one second device associated with the first device based on the authorization certificate.
  • the authorization certificate of the first network element may include a first digital signature, and the first device may use the first digital signature to verify the authorization certificate to determine whether the first network element has the authority to obtain the at least one second device data. .
  • the data mentioned in the embodiment of the present application may be the uplink data of the second device.
  • the data may include wireless signals, reflected signals, control plane data, user plane data, etc.
  • the embodiment of the present application applies to the second device.
  • the data sent is not limited.
  • the second device serves as a sensing device, the data may be sensing data.
  • the second device can directly send the generated data to the first network element, and the second device can also generate it.
  • the data is forwarded to the first network element through the first device, and the embodiment of the present application does not limit this.
  • the first network element can receive data sent by the first device, which is sent by at least one second device to the first device, or the first network element can receive data sent by at least one second device.
  • the first device can authenticate the authorization certificate of the first network element on behalf of at least one second device associated with it. If the verification passes, the first device may determine that the first network element has the authority to receive data from at least one second device. In this way, the second device with low computing power can verify the network elements on the network side, avoid theft and leakage problems during the data transmission of the second device, and ensure the security of data transmission of the second device.
  • the first digital signature may be a signature of the certificate issuance device. That is to say, the first digital signature may be obtained by using the private key of the certificate issuance device to sign other information in the authorization certificate. It should be understood that the certificate issuance device is a device that generates the first network element authorization certificate.
  • the authorization certificate of the first network element includes at least one of the following: service identification information, a public key of the certificate issuance device, a public key of the certificate issuance device, identification information of the first network element, The public key, the RSA accumulator parameters corresponding to the first network element, and the data identification information.
  • the authorization certificate of the first network element may include service identification information.
  • the service identification information may be used to indicate the service type corresponding to the data required by the first network element.
  • the service types may include positioning services, speed measurement services, health calling services, environmental monitoring services, etc., which are not limited in the embodiments of this application.
  • the service identification information may be a fixed length of bit data, where different bit data correspond to different service types.
  • the first device determines the service type corresponding to the bit data by looking up the table.
  • the service identification information may be the identification information of the first network element.
  • the first network element may provide one or more services, so the required service types are different. Based on this, in this embodiment of the present application, the identification information of the first network element can be used to characterize the service type of the data.
  • the RSA accumulator parameter corresponding to the first network element is used to verify whether the authorization certificate of the first network element has been revoked. It should be understood that in actual applications, the authorization certificate may be revoked. Therefore, the authorization certificate needs to carry the RSA parameter of the authorization certificate so that the first device can verify whether the obtained authorization certificate of the first network element has been revoked.
  • the data identification information can be used to indicate the data type corresponding to the above data, and the data type includes one or more types.
  • the data type may include heart rate data, body temperature data, exercise data, blood pressure data, respiratory frequency data, etc.
  • 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 certificate issuance device can generate an authorization certificate for the first network element at the request of the first network element.
  • the certificate issuance device may be an application provider certificate authority (Certificate Authority, CA), a business server, or an operator CA. This application embodiment does not limit this.
  • CA application provider certificate authority
  • This application embodiment does not limit this.
  • the relevant content of the first network element requesting the certificate issuance device to generate the authorization certificate is described in detail below. For the sake of brevity, details will not be described here.
  • the first digital signature may be obtained by signing all or part of the above information using the private key of the certificate issuance device.
  • the authorization credentials can also be verified through the following steps:
  • Step 230 The first device verifies the first digital signature using the public key of the certificate issuance device to obtain the first verification information
  • Step 240 If the first verification information is consistent with other information in the authorization certificate except the first digital signature, it is determined that the authorization certificate has been verified.
  • the first device can verify the first digital signature using the public key of the certificate issuance device to obtain the first verification information. Only when the first verification information is consistent with other information in the authorization certificate, can the first device determine that the first network element has the authority to obtain data of at least one second device. If they are inconsistent, the first device does not perform further processing.
  • the first device can obtain the public key of the certificate issuance device from the authorization certificate and verify the first digital signature.
  • the first device can also store the public key of the certificate issuance device in advance, and use the pre-stored public key to verify the first digital signature.
  • the embodiment of this application does not limit the source of the public key of the certificate issuance device.
  • the authorization certificate when the authorization certificate includes the RSA accumulator parameter corresponding to the first network element, in step 220, if the authorization certificate is verified based on the first digital signature, the first device determines that the first network element The element has the permission to receive data sent by at least one second device, which can also be achieved in the following ways:
  • the first device verifies whether the authorization certificate of the first network element has been revoked based on the RSA accumulator parameter;
  • the first device determines that the first network element has the authority to receive data from at least one second device.
  • the first device can also verify whether the authorization certificate has been revoked according to the RSA accumulator parameter. If the authorization certificate of the first network element has not been revoked, the first device may determine that the first network element has the authority to receive data from at least one second device associated with it. If the authorization certificate of the first network element is revoked, the first device may determine that the first network element does not have the authority to obtain the data of the second device. In this way, the authorization efficiency of the first device for the uplink data of the second device can be improved.
  • the first device if the authorization certificate of the first network element includes service identification information and/or data identification information, before verifying the authorization certificate, the first device also needs to determine whether the second device associated with it supports the service identification information.
  • the service type indicated by the information, and/or the data type indicated by the data identification information are included in the authorization certificate of the first network element.
  • the service identification information carried in the authorization voucher can be used to represent the service type of the data that the first network element needs to obtain.
  • the data identification information carried in the authorization certificate can be used to characterize the data type of data that the first network element needs to obtain. Therefore, after the first device obtains the authorization certificate of the first network element, it needs to first determine whether at least one second device associated with it supports the service type and/or data type required by the first network element.
  • the first device may maintain a service type list, which may store the identification information of each second device associated with it and the service types supported by each second device.
  • the first device can compare the service type corresponding to the service identification information in the authorization voucher with the service types supported by each second device in the above list, thereby determining that the service type is supported. Secondary device of service type.
  • the first device may also maintain a data type list, which may store identification information of each second device associated with the first device, and data types supported by each second device.
  • a data type list may store identification information of each second device associated with the first device, and data types supported by each second device.
  • the first device can compare the data type corresponding to the data identification information in the authorization certificate with the data type supported by each second device in the above list, thereby determining that the data type is supported.
  • Secondary device of data type may be used to compare the data type corresponding to the data identification information in the authorization certificate with the data type supported by each second device in the above list, thereby determining that the data type is supported.
  • the first device If any of the at least one second device associated with the first device supports the service type and/or data type, the first device starts the verification process of the authorization credential of the first network element, and then based on the first The digital signature verifies the authorization certificate of the first network element. If at least one second device associated with the first device does not support the service type and/or data type, the first device ignores the authorization voucher and does not perform verification processing on the authorization voucher. In this way, it can be ensured that the service type of the data received by the first network element is a service type that meets its needs, and/or the data type of the data received by the first network element is a data type that meets its needs. In this way, data authorization is improved. s efficiency.
  • step 220 after the first device determines that the first network element has the authority to receive data sent by at least one second device, it also The following steps can be included:
  • Step 250 The first device receives the first indication information sent by the first network element; the first indication information is used to indicate at least one second device that needs to send data to the first network element;
  • Step 260 The first device sends first request information to the second device indicated by the first indication information; the first request information is used to request data of the second device indicated by the first indication information.
  • the first network element informs the first device through the first indication information which second devices need to send data to it. Furthermore, the first device may send first request information to the second devices indicated by the first indication information to request data from these second devices.
  • At least one second device associated with the first device includes the second device indicated by the first indication information.
  • the first indication information may include identification information of the second device that needs to transmit data to the first network element.
  • the first device can send the first request information to the second device corresponding to the identification information carried in the first indication information.
  • the second device indicated by the first device information may directly send its own data to the first network element, or may forward its own data to the first network element through the first device.
  • the embodiments of this application do not limit this.
  • step 260 in the security implementation method of the embodiment of the present application, the following steps may also be included:
  • Step 270 The first device receives the data sent by the second device indicated by the first indication information
  • Step 280 The first device sends the data to the first network element.
  • the first device after the first device initiates a data request to the second device indicated by the first indication information, the first device can also serve as a relay device to forward the data fed back by these second devices to the first network element. In this way, accurate data transmission is achieved and data transmission efficiency is ensured.
  • the authorization voucher includes business identification information and/or data identification information
  • the above-mentioned step 260 of the first device sending the first request information to the second device indicated by the first indication information can also be implemented in the following manner:
  • the first device sends the first request information to the second device indicated by the first indication information that supports the service type indicated by the service identification information and/or the data type indicated by the data identification information.
  • the first device may only support the service type corresponding to the above-mentioned service identification information and/or support the service type corresponding to the above-mentioned data identification information to the second device indicated by the first indication information.
  • the second terminal sends the first request information of data type. In this way, it can be ensured that the service type of the data sent by the second device matches the service type required by the first network element, thereby improving transmission efficiency.
  • the first device may also perform mutual authentication with these second devices to ensure that the other parties are Trusted devices. After the first device and the second device pass mutual authentication, the first device continues to perform the above steps 260 and 270 to achieve physical layer secure data transmission with the second device. This prevents third-party attackers from stealing and tampering with data.
  • the first device can perform a simple device authentication process with the second device.
  • the first device and the second device can perform authentication based on the initial key K of the second device.
  • the initial secret key K may be a symmetric secret key, and the local storage space of each second device may store its own initial secret key K.
  • the first device and the second device can also negotiate based on the initial secret key K to obtain the physical layer security key s, and then the first device and the second device perform device authentication based on the secret key s.
  • the first device in the embodiment of this application There are no restrictions on the authentication method with the second device.
  • step 210 the first device obtains the authorization certificate of the first network element, which can be achieved through the following steps:
  • Step 2101 The first device receives the second request information sent by the first network element; the second request information is used to request the first device to grant the first network element permission to obtain data of at least one second device; the second request information includes Authorization credentials;
  • Step 2102 The first device obtains the authorization certificate from the second request information.
  • the first network element when it needs to obtain data of the second device, it can send the second request information to the first device bound/associated with the second device.
  • the first network element may carry the authorization certificate of the first network element in the second request information.
  • the first device after receiving the second request information, the first device can obtain the authorization certificate of the first network element from the second request information, and verify the authorization certificate based on the first digital signature in the authorization certificate to determine the third Whether a network element has the permission to obtain the data of the second device.
  • the first device may first authenticate the first network element that sent the second request information, determine whether the first network element is a trusted network element, and determine whether the first network element is a trusted network element. 2. Whether the request information has been tampered with. Only when the identity verification of the first network element passes, the first device obtains the authorization certificate based on the first request information and verifies the authorization certificate, thereby ensuring that during the subsequent transmission process, the second device associated with the first Device data will not be leaked or stolen.
  • the first device can use the shared secret key with the first network element to authenticate the first network element, or the first device can also use the public key of the first network element to authenticate the first network element. , the embodiment of the present application does not limit this.
  • the second request information may include at least one of the following information:
  • the channel parameters are used to establish a possible communication between the first network element and the first device. communication channel; the public key of the first network element and the second digital signature; the second digital signature is obtained by signing other information in the second request information with the private key of the first network element.
  • the first device can use the second digital signature to authenticate the first network element.
  • the method for the first device to authenticate the first network element includes the following:
  • the first device uses the public key of the first network element to verify the above-mentioned second digital signature to obtain the second verification information; if the second verification information is consistent with other information in the second request information except the second digital signature, Then the first device determines that the identity authentication of the first network element is passed.
  • the first device may maintain a public key list, which stores identification information of multiple network elements and the public key corresponding to each network element. After receiving the second request information sent by the first network element, the first device can search the public key corresponding to the identification information of the first network element from the above public key list. Furthermore, the first device can verify the second digital signature based on the public key to obtain the second verification information.
  • the first device can also verify the second digital signature based on the public key carried in the second request information to obtain the second verification information.
  • the embodiment of this application does not limit the method of obtaining the public key of the first network element.
  • the first device confirms that the first network element is a trusted network element, and the second request information has not been has been tampered with, the first network element can further perform verification based on the authorization certificate in the second request information to determine whether the first network element has the authority to obtain the second device data.
  • the first device may consider the first network element to be an untrusted network element, and/or the first request Information has been tampered with by a third party. In this case, the first device may ignore the second request information without further processing.
  • the first network element can actively send the first request information carrying its authorization credentials to the first device to request the first device to perform verification and grant it the second authorization. Permissions for device data. In this way, it is ensured that the uplink data of the second device will not be leaked or stolen.
  • the first network element can also obtain its own authorization credentials to generate the second request information.
  • the authorization certificate of the first network element can be stored in the local storage space of the first network element.
  • the first network element needs to obtain the data of the second device, it can obtain the authorization certificate in the local storage space and store the authorization certificate.
  • the authorization certificate is sent to the first device bound/associated with the second device through the second request information.
  • the authorization certificate may not be stored locally on the first network element, but may be distributed and stored in the blockchain node through decentralized identity (Decentralized Identity, DID).
  • DID Decentralized Identity
  • the first network element needs to obtain the data of the second device, it can first obtain the authorization certificate of the first network element from the storage block of the blockchain node. Referring to the schematic flow chart shown in Figure 5, before the first network element sends the second request information to the first device, the following steps may also be performed:
  • Step 2001 The first network element sends fourth request information to the blockchain node; the fourth request information is used to request the authorization certificate of the first network element; the fourth request information includes the storage location information of the authorization certificate in the blockchain node;
  • Step 2002 The first network element receives the authorization certificate of the first network element sent by the blockchain node.
  • the first network element before sending the second request information to the first device, can request the blockchain node to obtain the authorization certificate of the first network element based on the storage location information of the first network element authorization certificate. After receiving the authorization credential fed back by the blockchain node, the first network element may carry the obtained authorization credential in the second request information and send it to the first device, so that the first device grants it the authorization to associate with the first device. the data of the second device.
  • the authorization certificate includes the first digital signature of the certificate issuance device
  • the first network element can use the public key of the certificate issuance device to sign the first digital signature. Verification is performed to determine the authenticity of the authorization credentials. After passing the verification of the first digital signature, the first network element carries the authorization certificate in the first request information and sends it to the first device.
  • the authorization certificate of the first network element can be generated in advance by the certificate issuance device.
  • the certificate issuance device can return the authorization certificate to the first network element, or upload the authorization certificate to the blockchain node for distributed storage.
  • the first network element obtains data according to business needs, it can obtain the authorization certificate from the local storage space, or request the authorization certificate from the blockchain node, and send the obtained authorization certificate to the first network element through the first request information.
  • First device In this way, the flexibility of data authorization by the first device is improved.
  • the first device obtains the authorization certificate of the first network element, which can also be achieved through the following steps:
  • Step 2103. The first device sends third request information to the blockchain node.
  • the third request information is used to request the authorization certificate of the first network element; the authorization certificate is stored in the block of the blockchain node; the third request information includes The storage location information of the authorization certificate in the blockchain node;
  • Step 2104 The first device receives the authorization certificate of the first network element sent by the blockchain node.
  • the authorization certificate of the first network element can be distributed and stored in the block of the blockchain node through DID method.
  • the first device may actively request the authorization certificate of the first network element from the blockchain node. Specifically, the first device may request the blockchain node to obtain the authorization certificate of the first network element based on the storage location information of the authorization certificate of the first network element.
  • the storage location information of the first network element authorization credential may be obtained by the first device from an access network element (such as a base station) or a core network element, which is not limited in the embodiments of this application.
  • the first device actively requests the blockchain node for the authorization certificate of the first network element for verification and authorization, which may be triggered according to the interactive instructions received by the user interface, or may be triggered by the application program of the first device, or It may be actively triggered after obtaining the data of the second device bound/associated with the first device, and the embodiment of the present application does not limit this.
  • the first device may be triggered to periodically upload data of the second device to which it is bound/associated.
  • the periodic uploading of data to the second device may be initiated by the first device, may also be triggered by user interface interaction, triggered by an application program of the first device, etc. This embodiment of the present application does not limit this.
  • the first device can actively request the authorization certificate of the first network element from the blockchain node, and then verify the requested authorization certificate and pass it.
  • the second device bound/associated with the first device can send data according to a preset time period.
  • the data can be forwarded to the first network element through the first device or directly sent to the first network element.
  • the first device can also proactively request the authorization certificate of the first network element from the blockchain node, and then trigger the second device to periodically upload data. This application does not limit the order of the two.
  • the first device can actively obtain the authorization certificate of the first network element and verify it. Only when the verification passes, the second device can transmit the data. In this way, it is ensured that The data of the second device will not be leaked or stolen.
  • the security implementation method provided by the embodiment of the present application may include the following steps:
  • Step 710 The certificate issuance device receives the fifth request information sent by the first network element; the fifth request information is used to request the authorization certificate of the first network element; the authorization certificate is used by the first device to verify whether the first network element has the ability to obtain data. Permission; data comes from at least one second device associated with the first device;
  • Step 720 The certificate issuance device generates the authorization certificate of the first network element.
  • the certificate issuance device may be an application provider CA or an application server, which is not limited in the embodiment of this application.
  • the first network element may initiate a voucher request to the voucher issuance device. Specifically, the first network element may send the fifth request information to the credential issuance device through a secure channel to request the credential issuance device to generate an authorization credential for the first network element, so that the first device can perform verification and judgment based on the authorization credential. Whether to grant the first network element the permission to obtain the data of the second device.
  • the credential issuance device may first perform identity verification on the first network element that sent the fifth request information, determine whether the first network element is a trusted network element, and determine whether the first network element is a trusted network element, and determine whether the first network element is a trusted network element. 5. Whether the requested information has been tampered with. Only when the identity verification of the first network element passes, the certificate issuance device can generate an authorization certificate for the first network element.
  • the fifth request information may include at least one of the following information:
  • Service identification information identification information of the first network element, public key of the first network element, data identification information, and third digital signature; the third digital signature uses the private key of the first network element to other information in the fifth request information. Get signed.
  • the certificate issuance device can use the third digital signature to authenticate the first network element.
  • the method by which the certificate issuance device authenticates the first network element includes the following:
  • the certificate issuance device uses the public key of the first network element to verify the third digital signature to obtain the third verification information; if the third verification information is consistent with other information in the fifth request information except the third digital signature, then The certificate issuance device determines that the identity verification of the first network element has passed.
  • the certificate issuance device can maintain a public key list, which stores the identification information of multiple network elements and the public key corresponding to each network element. After receiving the fifth request information sent by the first network element, the certificate issuance device can search for the public key corresponding to the identification information of the first network element from the above public key list. Then, the certificate issuance device verifies the third digital signature based on the public key to obtain the third verification information.
  • the certificate issuance device can also verify the third digital signature based on the public key carried in the fifth request information to obtain the third verification information.
  • the embodiment of this application does not limit the identity verification method of the first network element.
  • the certificate issuance device confirms that the first network element is a trusted network element, and the fifth request information has not been been tampered with.
  • the certificate issuance device may consider the first network element to be an untrusted network element, and/or the fifth request Information has been tampered with by a third party. In this case, the certificate issuance device may ignore the fifth request information without further processing.
  • an RSA accumulator parameter ⁇ may be generated for the first network element, and the RSA accumulator parameter ⁇ of the first network element may be used to prove the first network element. Whether the authorization certificate has been revoked.
  • the authorization credential generated by the credential issuance device may include at least one of the following information:
  • the first digital signature may be obtained by the certificate issuing device using its own private key to sign other information in the authorization certificate.
  • the voucher issuance device may also perform step 730 and step 740 .
  • Step 730 The certificate issuance device sends the authorization certificate of the first network element to the blockchain node;
  • Step 740 The certificate issuance device receives the storage location information of the authorization certificate sent by the blockchain node.
  • the certificate issuance device can send the generated authorization certificate of the first network element to the blockchain node, and perform an on-chain operation on the authorization certificate of the first network element to achieve distributed storage of the authorization certificate. Further, after the blockchain node receives the authorization certificate, it can store the authorization certificate in the storage block of the blockchain and feed back the storage location information to the certificate issuance device.
  • step 740 the following steps may also be included after step 740:
  • Step 750 The voucher issuance device sends the authorization voucher to the first network element and/or stores the location information.
  • the certificate issuance device can send the generated authorization certificate to the requesting party, that is, the first network element.
  • the certificate issuance device can also send the storage location information of the authorization certificate in the storage block to the first network element, and the first network element can request the authorization certificate from the blockchain node based on the storage location information when needed.
  • the voucher generation device can generate an authorization voucher for the first network element according to the request of the first network element, and perform distributed storage of the authorization voucher.
  • the first network element or the first device can request the authorization certificate from the blockchain node for distributed verification. That is to say, the same type of business in different geographical locations can authorize data in parallel, improving the efficiency of data authorization. efficiency.
  • the first device may be a UE
  • the second device may be a zero-power device ZPD
  • the first network element may be an application server Server
  • the certificate issuance device may be an application provider CA.
  • Step 801 The server sends the certificate request information to the application provider CA.
  • the credential request information is used to request the server's authorization credential.
  • the credential request information may include at least one of ID server , pk server , ID SP , Type server , and Sig server .
  • ID server is the identification information of the Server
  • pk server is the public key of the Server
  • ID SP is the business identification information
  • Type server is the data identification information
  • Sig server is the digital signature of the Server. Sig server is obtained by the Server using its own private key to sign one or more of the ID server , pk server , ID SP , and Type server .
  • Step 802 The application provider CA generates the authorization certificate Cert sp->server for the server.
  • the application provider CA can first authenticate the server that sent the request information.
  • the application provider CA may maintain a public key list, which is used to store multiple server IDs and their public keys.
  • the application provider CA can check whether the ID server in the certificate request information is in the public key list. If it is in the public key list, obtain the public key corresponding to the ID server .
  • the application provider CA uses the public key corresponding to the ID server to verify the Sig server in the certificate request information. If the verification result is consistent with other information in the credential request information, it is determined that the server identity authentication is passed.
  • the application provider CA can generate the server's authorization certificate based on the content in the certificate request information.
  • the authorization certificate can be represented by Cert sp->server .
  • Cert sp->server may include at least one of ID server , pk server , ID SP , Type server , pk SP , ⁇ server , and Sig sp->server .
  • pk SP is the public key of the application provider CA
  • ⁇ server is the RSA accumulator parameter generated by the application provider CA for sever
  • Sig sp->server is the application provider CA using its own private key to ID server and pk server .
  • ID SP , Type server , pk SP , ⁇ server one or more signatures are obtained.
  • Step 803 The application provider CA sends the authorization certificate Cert sp->server to the blockchain node.
  • Step 804 The application provider CA receives the storage location information BlockNum Cert sent by the blockchain node.
  • Step 805 The application provider CA sends the storage location information BlockNum Cert of the authorization certificate to the server.
  • the application provider CA can also send the authorization certificate Cert sp->server directly to the Server.
  • Step 806 Server obtains the authorization certificate Cert sp->server from the blockchain node based on the storage location information BlockNum Cert .
  • the server can verify the authenticity of the obtained authorization certificate Cert sp->server through the public key pk SP of the application provider CA. Specifically, the server uses pk SP to verify the Sig sp->server in the authorization certificate Cert sp->server . If the verification result is consistent with other information in the authorization certificate Cert sp->server , it is determined that the authorization certificate is a real certificate.
  • Step 807 The Server sends a data request to the UE.
  • the data request may include at least one of ID server , ID UE , ⁇ ID ZP1 ,..., ID ZPn ⁇ , pk server , g, Cert sp->server , and Sig server '.
  • 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
  • n is an integer greater than 1.
  • ZP1 to ZPn may be some or all of all zero-power consumption devices associated with the UE, and the embodiment of the present application does not limit this.
  • g is a channel parameter, used to establish a trusted channel between the Server and the UE.
  • Sig server ' is obtained by the Server using its own private key to sign one or more of ID server , ID UE , pk server , ⁇ ID ZP1 ,..., ID ZPn ⁇ , g, Cert sp->server .
  • Step 808 The UE verifies the identity of the Server.
  • the UE may maintain a public key list, which stores identification information of multiple servers and the public key corresponding to each server. After receiving the data request sent by the Server, the UE can search for the public key pk server corresponding to the ID server from the above public key list. Then the UE verifies the Sig server ' based on the pk server . If the UE verifies the Sig server based on the pk server and the verification result is consistent with other information in the data request, the Server is determined to be a trusted device. Otherwise, the UE determines that the verification fails and does not perform further processing.
  • Step 809 After the UE authenticates the identity of the Server, it authenticates the Cert sp->server , and after passing the authentication of the Cert sp->server, it grants the Server the permission to obtain the data of the zero-power device.
  • the UE after the UE successfully verifies the identity of the Server, it further verifies Cert sp->server . Specifically, the UE uses the public key pk SP of the certificate issuance device to verify the digital signature Sig sp->server in Cert sp->server . If the verification result is consistent with other information in Cert sp->server , the Server is determined Has the permission to obtain zero-power device data bound to the UE. If the verification result is inconsistent with other information in Cert sp->server , no further processing will be performed.
  • the UE can use the ⁇ server to verify whether the Cert sp->server has been revoked. If it is revoked, no further processing will be performed. If it is not revoked, the UE may continue to perform step 810.
  • Step 810 The UE performs device authentication with each zero-power device respectively, and establishes a secure channel with each zero-power device.
  • the UE can perform device authentication with ZP1...ZPn respectively through the initial secret key K of ZP1...ZPn.
  • the UE can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then the UE and ZP1...ZPn perform device authentication based on the secret key s.
  • Step 811 The UE sends a trigger signal to each zero-power consumption device.
  • the UE can send a trigger signal to each zero-power device through the secure channel established in step 810 to trigger each zero-power device to transmit data.
  • Step 812 The UE receives data sent by each zero-power consumption device.
  • each zero-power consumption device can send data to the UE through the secure channel established with the UE in step 810.
  • Step 813 The UE sends the data of each zero-power consumption device to the Sever.
  • the UE can send data of each zero-power device to the Sever through the wireless access network.
  • steps 801 to 805 in application scenario 1 can be implemented individually, steps 806 to 813 can also be implemented individually, and steps 801 to 813 can be implemented together.
  • steps 801 to 813 can be implemented together.
  • the embodiments of the present application do not limit this.
  • the first device may be a UE
  • the second device may be a zero-power consumption device ZPD
  • the first network element may be a base station
  • the certificate issuance device may be an application provider CA.
  • the certificate issuance device can independently issue authorization certificates for the base station. Referring to the flow diagram shown in Figure 9, the process of the application provider CA issuing authorization certificates for the base station can be implemented through the following steps:
  • Step 901 The base station sends certificate request information to the application provider CA.
  • the voucher request information is used to request the authorization voucher of the base station.
  • the credential request information may include at least one of ID bs , pk bs , ID SP , Type bs , and Sig bs .
  • ID bs is the identification information of the base station
  • pk bs is the public key of the base station
  • ID SP is the service identification information
  • Type bs is the data identification information
  • Sig bs is the digital signature of the base station. Sig bs is obtained by the base station using its own private key to sign one or more of ID bs , pk bs , ID SP and Type bs .
  • Step 902 The application provider CA generates an authorization certificate for the base station.
  • the application provider CA can authenticate the base station sending the requested information.
  • the application provider CA can maintain a public key list, which is used to store all base station IDs and corresponding public keys using the service type corresponding to the ID sp .
  • the application provider CA can check whether ID bs in the certificate request information is in the public key list, and if it is in the public key list, obtain the public key corresponding to ID bs .
  • the application provider CA uses the public key corresponding to the ID bs to verify the Sig bs in the certificate request information. If the verification result is consistent with other information in the credential request information, it is determined that the base station identity verification is passed.
  • the application provider CA can generate an authorization certificate for the base station based on the content in the certificate request information.
  • the authorization certificate can be represented by Cert sp->bs .
  • Cert sp->bs may include at least one of ID bs , pk bs , ID SP , Type sbs , pk SP , ⁇ bs , and Sig sp->bs .
  • pk SP is the public key of the application provider CA
  • ⁇ bs is the RSA accumulator parameter generated by the application provider CA for the base station
  • Sig sp->bs is the ID bs and pk bs used by the application provider CA with its own private key.
  • ID SP , Type sbs , pk SP , ⁇ bs one or more signatures are obtained.
  • Step 903 The application provider CA sends the authorization certificate Cert sp->bs to the blockchain node.
  • Step 904 The application provider CA receives the storage location information BlockNum Cert sent by the blockchain node.
  • Step 905 The application provider CA sends the storage location information BlockNum Cert of the authorization certificate to the base station.
  • the application provider CA can also directly send the authorization certificate Cert sp->bs to the base station.
  • Step 906 The base station obtains the authorization certificate Cert sp->bs from the blockchain node according to the storage location information BlockNum Cert .
  • the base station can verify the authenticity of the obtained authorization certificate Cert sp->bs by using the public key pk SP of the application provider CA. Specifically, the base station uses pk SP to verify Sig sp->bs in the authorization certificate Cert sp->bs . If the verification result is consistent with other information in the authorization certificate Cert sp->bs , it is determined that the authorization certificate is a real certificate.
  • Step 907 The base station sends a data request to the UE.
  • the data request may include at least one of ID bs , ID UE , ⁇ ID ZP1 , ..., ID ZPn ⁇ , pk bs , g, Cert sp->bs , and Sig bs '.
  • 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
  • n is an integer greater than 1.
  • ZP1 to ZPn may be some or all of all zero-power consumption devices bound to the UE, and the embodiment of the present application does not limit this.
  • g is a channel parameter, which is used to establish a trusted channel between the base station and the UE.
  • Sig bs ' is obtained by the base station using its own private key to sign one or more of ID bs , ID UE , pk bs , ⁇ ID ZP1 ,..., ID ZPn ⁇ , g, Cert sp->bs .
  • Step 908 The UE verifies the identity of the base station.
  • the UE may maintain a public key list, which stores identification information of multiple base stations and the public key corresponding to each base station. After receiving the data request sent by the base station, the UE can search for the public key pk bs corresponding to ID bs from the above public key list. Then the UE verifies Sig bs based on pk bs . If the verification result obtained by the UE based on the pk bs verification of Sig bs ' is consistent with other information in the data request, the base station is determined to be a trusted device. Otherwise, the UE determines that the verification fails and does not perform further processing.
  • Step 909 After the UE authenticates the identity of the base station and passes the verification, it verifies Cert sp->bs , and after passing the verification of Cert sp->bs, it grants the base station the permission to obtain the data of the zero-power device.
  • the UE after the UE successfully verifies the identity of the base station, it further verifies Cert sp->bs . Specifically, the UE uses the public key pk SP of the certificate issuance device to verify the digital signature Sig sp->bs in Cert sp->bs . If the verification result is consistent with other information in Cert sp->bs , the base station is determined Has the permission to obtain zero-power device data bound to the UE. If the verification result is inconsistent with other information in Cert sp->bs , no further processing will be performed.
  • the UE can use ⁇ bs to verify whether the Cert sp->bs has been revoked. If it is revoked, no further processing will be performed. If it is not revoked, the UE may continue to perform step 910.
  • Step 910 The UE performs device authentication with each zero-power device respectively, and establishes a secure channel with each zero-power device.
  • the UE can perform device authentication with ZP1...ZPn respectively through the initial secret key K of ZP1...ZPn.
  • the UE can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then the UE and ZP1...ZPn perform device authentication based on the secret key s.
  • a secure channel can be established between the UE and each zero-power device.
  • Step 911 The UE sends a trigger signal to each zero-power consumption device.
  • the UE can send a trigger signal to each zero-power device through the secure channel established in step 910 to trigger each zero-power device to transmit data.
  • Step 912 The UE receives data sent by each zero-power consumption device.
  • each zero-power consumption device can send data to the UE through the secure channel established with the UE in step 810.
  • Step 913 The UE sends the data of each zero-power consumption device to the base station.
  • Step 912' Each zero-power device performs device authentication with the base station, and establishes a secure channel between each zero-power device and the base station.
  • the base station can perform device authentication with ZP1...ZPn respectively through the initial secret keys K of ZP1...ZPn.
  • the base station can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then the base station and ZP1...ZPn perform device authentication based on the secret key s.
  • Step 913' each zero-power consumption device sends data to the base station.
  • each zero-power consumption device ZP1...ZPn can send data to the base station through the secure channel established in step 912'.
  • steps 901 to 905 in application scenario one can be implemented individually, and steps 906 to step 913 or step 906 to step 913' can also be implemented separately. Steps 901 to step 913 or steps 901 to step 913' can also be implemented together. implementation, the embodiments of this application do not limit this.
  • the first device may be a base station
  • the second device may be a zero-power device ZPD
  • the first network element may be an application server
  • the certificate issuance device may be an application provider CA.
  • Step 1101. Server obtains the authorization certificate Cert sp->server from the blockchain node based on the storage location information BlockNum Cert .
  • the server can verify the authenticity of the obtained authorization certificate Cert sp->server through the public key pk SP of the application provider CA. Specifically, the server uses pk SP to verify the Sig sp->server in the authorization certificate Cert sp->server . If the verification result is consistent with other information in the authorization certificate Cert sp->server , it is determined that the authorization certificate is a real certificate.
  • Step 1102 Server sends a data request to the base station.
  • the data request may include at least one of ID server , ID bs , ⁇ ID ZP1 , ..., ID ZPn ⁇ , pk server , g, Cert sp->server , and Sig server '.
  • ID bs is the identification information of the base station
  • ID ZP1 ,..., ID ZPn are the identification information respectively corresponding to n zero-power consumption devices ZP1 to ZPn bound to the base station
  • n is an integer greater than 1.
  • ZP1 to ZPn may be some or all of all zero-power consumption devices associated with the base station, and the embodiment of the present application does not limit this.
  • g is the channel parameter, which is used to establish a trusted channel between the server and the base station.
  • Sig server ' is obtained by the Server using its own private key to sign one or more of ID server , ID bs , pk server , ⁇ ID ZP1 ,..., ID ZPn ⁇ , g, Cert sp->server .
  • Step 1103 The base station verifies the identity of the Server.
  • the base station can maintain a public key list, which stores identification information of multiple servers and the public key corresponding to each server. After receiving the data request sent by the server, the base station can search for the public key pk server corresponding to the ID server from the above public key list. Then the base station verifies the Sig server ' based on the pk server . If the base station verifies the Sig server based on the pk server and the verification result is consistent with other information in the data request, the server is determined to be a trusted device. Otherwise, the base station determines that the verification fails and does not perform further processing.
  • Step 1104 After the base station verifies the identity of the Server, it verifies Cert sp->server , and after passing the verification of Cert sp->server, it grants the Server the permission to obtain the data of the zero-power device.
  • the base station After the base station passes the verification of the Server's identity, it further verifies Cert sp->server . Specifically, the base station uses the public key pk SP of the certificate issuance device to verify the digital signature Sig sp->server in Cert sp->server . If the verification result is consistent with other information in Cert sp->server , the Server is determined Has the permission to obtain the data of multiple zero-power devices bound to the base station. If the verification result is inconsistent with other information in Cert sp->server , no further processing will be performed.
  • the base station can use the ⁇ server to verify whether the Cert sp->server has been revoked. If it is revoked, no further processing will be performed. If it is not revoked, the base station can continue to perform step 1105.
  • Step 1105 The base station performs device authentication with each zero-power device, and establishes a secure channel with each zero-power device.
  • the base station can perform device authentication with ZP1...ZPn respectively through the initial secret keys K of ZP1...ZPn.
  • the base station can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then the base station and ZP1...ZPn perform device authentication based on the secret key s.
  • Step 1106 The base station sends a trigger signal to each zero-power consumption device.
  • the base station can send trigger signals to each zero-power device through the secure channel established in step 1105 to trigger each zero-power device to transmit data.
  • Step 1107 The base station receives data sent by each zero-power consumption device.
  • each zero-power consumption device can send data to the base station through the secure channel established with the base station in step 1105.
  • Step 1108 The base station sends the data of each zero-power consumption device to the Sever.
  • the first device may be a UE
  • the second device may be a zero-power device ZPD
  • the first network element may be an application server Server
  • the certificate issuance device may be an application provider CA.
  • Step 1201 The UE obtains the server's authorization certificate Cert sp->server from the blockchain node according to the storage location information BlockNum Cert .
  • the UE can verify the authenticity of the obtained authorization certificate by applying the public key pk SP of the provider CA. Specifically, the UE can use pk SP to verify Sig sp->server in the authorization certificate Cert sp->server . If the verification result is consistent with other information in the authorization certificate Cert sp->server , it is determined that the authorization certificate is a real certificate.
  • Step 1202 The UE is triggered to upload periodic data.
  • step 1201 may be executed before step 1202 or after step 1202.
  • the embodiment of the present application does not limit the execution order of the two steps.
  • Step 1203 The UE verifies Cert sp->server , and after passing the verification, grants the Server permission to obtain data of each zero-power device.
  • the UE can use the public key pk SP of the certificate issuance device to verify the digital signature Sig sp->server in Cert sp->server . If the verification result is consistent with other information in Cert sp->server , it is determined that the Server has the permission to obtain the data of zero-power devices ZP1...ZPn. If the verification result is inconsistent with other information in Cert sp->server , no further processing will be performed.
  • the UE can use the ⁇ server to verify whether the Cert sp->server has been revoked. If it is revoked, no further processing will be performed. If it is not revoked, the UE may continue to perform step 1204.
  • Step 1204 The UE performs device authentication with each zero-power device respectively, and establishes a secure channel with each zero-power device.
  • the UE can perform device authentication with ZP1...ZPn respectively through the initial secret key K of ZP1...ZPn.
  • the UE can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then the UE and ZP1...ZPn perform device authentication based on the secret key s.
  • Step 1205 The UE sends a trigger signal to each zero-power consumption device.
  • the UE can send a trigger signal to each zero-power device through the secure channel established in step 1204 to trigger each zero-power device to transmit data.
  • Step 1206 The UE receives data sent by each zero-power consumption device.
  • each zero-power consumption device can send data to the UE through the secure channel established with the UE in step 1204.
  • Step 1207 The UE sends the data of each zero-power consumption device to the Sever.
  • the UE can send data of each zero-power device to the Sever through the wireless access network.
  • Step 1206' Each zero-power device performs device authentication with the Server, and establishes a secure channel between each zero-power device and the Server.
  • the Server can perform device authentication with ZP1...ZPn respectively through the initial secret keys K of ZP1...ZPn.
  • Server can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then Server and ZP1...ZPn perform device authentication based on the secret key s.
  • Step 1207' each zero-power device sends data to the server.
  • each zero-power device ZP1...ZPn can send data to the Server through the secure channel established in step 911'.
  • the Server in the above application scenario 4 can be replaced by the base station.
  • Cert sp->server is replaced by Cert sp->bs .
  • the first device may be a base station
  • the second device may be a zero-power device ZPD
  • the first network element may be an application server Server
  • the certificate issuance device may be an application provider CA.
  • Step 1401 The base station obtains the server's authorization certificate Cert sp->server from the blockchain node based on the storage location information BlockNum Cert .
  • the base station can verify the authenticity of the obtained authorization certificate by applying the public key pk SP of the provider CA. Specifically, the base station can use pk SP to verify Sig sp->server in the authorization certificate Cert sp->server . If the verification result is consistent with other information in the authorization certificate Cert sp->server , it is determined that the authorization certificate is a real certificate.
  • Step 1402 The base station is triggered to upload periodic data.
  • step 1401 may be executed before step 1402 or after step 1402.
  • the embodiment of the present application does not limit the execution order of the two steps.
  • Step 1403 The base station verifies Cert sp->server , and after passing the verification, grants the server permission to obtain data of each zero-power device.
  • the base station can use the public key pk SP of the certificate issuance device to verify the digital signature Sig sp->server in Cert sp->server . If the verification result is consistent with other information in Cert sp->server , it is determined that the Server has the permission to obtain the data of zero-power devices ZP1...ZPn. If the verification result is inconsistent with other information in Cert sp->server , no further processing will be performed.
  • the base station can use the ⁇ server to verify whether the Cert sp->server has been revoked. If it is revoked, no further processing will be performed. If it is not revoked, the base station can continue to perform step 1404.
  • Step 1404 The base station performs device authentication with each zero-power device, and establishes a secure channel with each zero-power device.
  • the base station can perform device authentication with ZP1...ZPn respectively through the initial secret keys K of ZP1...ZPn.
  • the base station can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then the base station and ZP1...ZPn perform device authentication based on the secret key s. In this way, after successful authentication between the base station and the zero-power devices, a secure channel can be established between the base station and each zero-power device.
  • Step 1405 The base station sends a trigger signal to each zero-power consumption device.
  • the base station can send a trigger signal to each zero-power device through the secure channel established in step 1404 to trigger each zero-power device to transmit data.
  • Step 1406 The base station receives data sent by each zero-power consumption device.
  • each zero-power consumption device can send data to the base station through the secure channel established with the base station in step 1404.
  • Step 1407 The base station sends the data of each zero-power device to the Sever.
  • Step 1406' Each zero-power device performs device authentication with the Server, and establishes a secure channel between each zero-power device and the Server.
  • the Server can perform device authentication with ZP1...ZPn respectively through the initial secret keys K of ZP1...ZPn.
  • Server can also negotiate with ZP1...ZPn respectively based on the initial secret key K of ZP1...ZPn to obtain the physical layer security key s of each zero-power device, and then Server and ZP1...ZPn perform device authentication based on the secret key s. In this way, after the server and zero-power devices ZP1...ZPn are successfully authenticated, a secure channel can be established between the server and each zero-power device.
  • Step 1407' each zero-power device sends data to the server.
  • each zero-power device ZP1...ZPn can send data to the Server through the secure channel established in step 911'.
  • 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 character "/" in this article generally indicates that the related objects are an "or" relationship.
  • FIG 16 is a schematic structural diagram of the security implementation device 1600 provided by the embodiment of the present application. It is applied to the first device. As shown in Figure 16, the security implementation device 1600 includes:
  • the first receiving unit 1601 is configured to obtain the authorization certificate of the first network element; the authorization certificate is used to verify whether the first network element has the authority to receive data; the data comes from at least one second device associated with the first device; authorization The certificate includes a first digital signature;
  • the determining unit 1602 is configured to, if the authorization certificate is successfully verified based on the first digital signature, the first device determines that the first network element has the authority to receive data sent by at least one second device.
  • the authorization certificate includes at least one of the following: service identification information, which is used to indicate the service type corresponding to the data; the public key of the certificate issuance device; the identification information of the first network element; Public key; RSA accumulator parameters corresponding to the first network element; data identification information.
  • the first digital signature is signed using the private key of the certificate issuance device; correspondingly, the security implementation device 1600 may also include a first verification unit, and the first verification unit may be configured to use the public key of the certificate issuance device.
  • the first digital signature is verified to obtain the first verification information; if the first verification information is consistent with other information in the authorization certificate except the first digital signature, it is determined that the authorization certificate has been verified.
  • the authorization certificate includes the RSA accumulator parameter corresponding to the first network element; correspondingly, the first verification unit is also configured to, in the case where the authorization certificate is verified based on the first digital signature, based on the RSA accumulator parameters to verify whether the authorization certificate has been revoked; the determination unit 1602 is also configured to determine that if the authorization certificate has not been revoked, the first device determines that the first network element has the authority to receive data from at least one second device.
  • the authorization voucher includes service identification information, and the service identification information is used to indicate the service type of the data; correspondingly, the first verification unit is also configured to support the service type in any one of the at least one second device.
  • the first device verifies the authorization certificate based on the first digital signature.
  • the first receiving unit 1601 is further configured to receive first indication information sent by the first network element; the first indication information is used to indicate a second device in at least one second device that needs to send data to the first network element. equipment;
  • the security implementation apparatus 1600 further includes a first sending unit configured to send first request information to the second device indicated by the first indication information; the first request information is used to request data of the second device indicated by the first indication information. .
  • the first receiving unit 1601 is also configured to receive data sent by the second device indicated by the first indication information
  • the first sending unit is further configured to send data to the first network element.
  • the authorization voucher includes service identification information, and the identification information of the service is used for the service type of the data; the first sending unit is also configured to send the second device supporting the service type to the second device indicated by the first indication information. The device sends the first request information.
  • the first receiving unit 1601 is also configured to receive second request information sent by the first network element; the second request information is used to request the first device to grant the first network element to obtain data of at least one second device. Permissions; the second request information includes authorization credentials; and the authorization credentials are obtained from the second request information.
  • the second request information also includes at least one of the following: identification information of the first network element; identification information of the first device; identification information of each of the at least one second device; channel parameters. ;
  • the channel parameters are used to establish a trusted channel between the first network element and the first device; the public key of the first network element;
  • the second digital signature is used by the first device to verify the identity of the first network element; the second digital signature is obtained by signing other information in the second request information with the private key of the first network element.
  • the first receiving unit 1601 is also configured to obtain the authorization certificate from the second request information when the identity verification of the first network element is passed.
  • the second request information also includes a second digital signature signed using the private key of the first network element; the first verification unit is further configured to use the public key of the first network element to verify the second digital signature. Verification processing is performed to obtain the second verification information; if the second verification information is consistent with other information in the second request information except the second digital signature, it is determined that the identity verification of the first network element is passed.
  • the first sending unit is also configured to send third request information to the blockchain node.
  • the third request information is used to request the authorization certificate of the first network element; the authorization certificate is stored in the block of the blockchain node. in; the third request information includes the storage location information of the authorization certificate in the blockchain node; the first receiving unit 1601 is also configured to receive the authorization certificate sent by the blockchain node.
  • the first sending unit is further configured to send data transmitted by at least one second device to the first network element according to a preset time period.
  • FIG 17 is a schematic structural diagram of the security implementation device 1700 provided by the embodiment of the present application. It is applied to the first network element. As shown in Figure 17, the security implementation device 1700 includes:
  • the second sending unit 1701 is configured to send second request information to the first device.
  • the second request information is used to request the first device to grant the first network element permission to obtain data of at least one second device. It has an association relationship with the first device; wherein, the second request information includes an authorization credential, and the authorization credential is used by the first device to verify whether the first network element has the authority to receive data from at least one second device; the authorization credential is included through the The first digital signature is verified.
  • the second request information also includes at least one of the following: identification information of the first network element; identification information of the first device; identification information of each second device in at least one second device; channel parameters, The channel parameters are used to establish a trusted channel between the first network element and the first device; the public key of the first network element; the second digital signature, and the second digital signature is used by the first device to verify the identity of the first network element, The second digital signature is obtained by signing other information in the second request information with the private key of the first network element.
  • the security implementation apparatus 1700 may also include a second receiving unit configured to receive data sent by the first device; the data is sent by at least one second device to the first device; or the second receiving unit is also configured To receive data sent by at least one second device.
  • a second receiving unit configured to receive data sent by the first device; the data is sent by at least one second device to the first device; or the second receiving unit is also configured To receive data sent by at least one second device.
  • the second sending unit 1701 is also configured to send fourth request information to the blockchain node; the fourth request information is used to request the authorization certificate of the first network element; the authorization certificate is stored in the area of the blockchain node. block; the fourth request information includes the storage location information of the authorization certificate in the blockchain node; the second receiving unit is also configured to receive the authorization certificate sent by the blockchain node.
  • the second sending unit 1701 is also configured to send fifth request information to the certificate issuance device; the fifth request information is used to request the authorization certificate of the first network element.
  • the fifth request information includes at least one of the following: service identification information, the service identification information is used to indicate the service type corresponding to the data; identification information of the first network element; the public key of the first network element; data Identification information; third digital signature, the third digital signature is obtained by signing with the private key of the first network element.
  • the second receiving unit is also configured to receive the authorization voucher sent by the voucher issuance device, and/or the storage location information of the authorization voucher.
  • FIG 18 is a schematic structural diagram of the security implementation device 1800 provided by the embodiment of the present application. It is applied to the certificate issuance equipment. As shown in Figure 18, the security implementation device 1800 includes:
  • the third receiving unit 1801 is configured to receive the fifth request information sent by the first network element; the fifth request information is used to request the authorization certificate of the first network element; the authorization certificate is used by the first device to verify whether the first network element has Permission to obtain data; data from at least one second device associated with the first device;
  • the voucher generation unit 1802 is configured to generate an authorization voucher for the first network element.
  • the authorization voucher includes at least one of the following: service identification information, which is used to indicate the service type of the data; identification information of the voucher issuance device; public key of the voucher issuance device; identification information of the first network element ; The public key of the first network element; the RSA accumulator parameter corresponding to the first network element; data identification information; the first digital signature, which is obtained by signing the private key of the certificate issuance device.
  • the voucher generation unit 1802 is also configured to generate an authorization voucher for the first network element by the voucher issuance device when the identity authentication of the first network element is passed.
  • the security implementation device 1800 further includes a third sending unit configured to send the authorization certificate to the blockchain node;
  • the third receiving unit 1801 is also configured to receive the storage location information of the authorization certificate sent by the blockchain node.
  • the third sending unit is also configured to send the authorization voucher to the first network element and/or store the location information.
  • Figure 19 is a schematic structural diagram of a communication device 1900 provided by an embodiment of the present application.
  • the communication device may be the first device, the first network element, or the voucher issuance device.
  • the communication device 1900 shown in Figure 19 includes a processor 1910.
  • the processor 1910 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the communication device 1900 may further include a memory 1920.
  • the processor 1910 can call and run the computer program from the memory 1920 to implement the method in the embodiment of the present application.
  • the memory 1920 may be a separate device independent of the processor 1910, or may be integrated into the processor 1910.
  • the communication device 1900 can also include a transceiver 1930.
  • the processor 1910 can control the transceiver 1930 to communicate with other devices. Specifically, it can send information or data to other devices, or receive other devices. Information or data sent by the device.
  • the transceiver 1930 may include a transmitter and a receiver.
  • the transceiver 1930 may further include an antenna, and the number of antennas may be one or more.
  • the communication device 1900 may specifically be the first device in the embodiment of the present application, and the communication device 1900 may 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.
  • the communication device 1900 may specifically be the first network element in the embodiment of the present application, and the communication device 1900 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 1900 can specifically be the voucher issuance device of the embodiment of the present application, and the communication device 1900 can implement the corresponding processes implemented by the voucher issuance device in the various methods of the embodiment of the present application. For the sake of brevity, they are not mentioned here. Again.
  • Figure 20 is a schematic structural diagram of a chip according to an embodiment of the present application.
  • the chip 2000 shown in Figure 20 includes a processor 2010.
  • the processor 2010 can call and run a computer program from the memory to implement the method in the embodiment of the present application.
  • the chip 2000 may also include a memory 2020.
  • the processor 2010 can call and run the computer program from the memory 2020 to implement the method in the embodiment of the present application.
  • the memory 2020 may be a separate device independent of the processor 2010 , or may be integrated into the processor 2010 .
  • the chip 2000 may also include an input interface 2030.
  • the processor 2010 can control the input interface 2030 to communicate with other devices or chips. Specifically, it can obtain information or data sent by other devices or chips.
  • the chip 2000 may also include an output interface 2040.
  • the processor 2010 can control the output interface 2040 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 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.
  • 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 voucher issuance device in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the voucher issuance device in the various methods of the embodiment of the present application. For the sake of brevity, details will not be repeated here.
  • 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 21 is a schematic block diagram of a communication system 2100 provided by an embodiment of the present application. As shown in Figure 21, the communication system 2100 includes a first device 2110, a first network element 2120, and a certificate issuance device 2130.
  • the first device 2110 can be used to implement the corresponding functions implemented by the first device in the above method
  • the first network element 2120 can be used to implement the corresponding functions implemented by the first network element in the above method
  • the voucher issuance device 2130 can be used to implement the corresponding functions implemented by the voucher issuance device in the above method. For the sake of brevity, details will not be described here.
  • 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.
  • the computer-readable storage medium can be applied to the voucher issuance device in the embodiment of the present application, and the computer program causes the computer to execute the corresponding processes implemented by the voucher issuance 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 product, including computer program instructions.
  • 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.
  • 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 voucher issuance device in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the voucher issuance device 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 voucher issuance device 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 voucher issuance device in the various methods of the embodiment of the present application.
  • An embodiment of the present application also provides a computer program.
  • 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 each method 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 each method of the embodiment of the present application.
  • 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 voucher issuance 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 voucher issuance 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 voucher issuance device in the various methods of the embodiment of the present application.
  • the computer program can be applied to the voucher issuance device in the embodiment of the present application.
  • 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)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供一种安全实现方法、装置、设备、网元，该方法包括：第一设备获取第一网元的授权凭证；所述授权凭证用于验证所述第一网元是否具有接收数据的权限；所述数据来自于与所述第一设备关联的至少一个第二设备；所述授权凭证包括第一数字签名；在基于所述第一数字签名对所述授权凭证验证通过的情况下，所述第一设备确定所述第一网元具有接收所述至少一个第二设备发送的数据的权限。

Description

安全实现方法、装置、设备及网元 技术领域
本申请实施例涉及移动通信技术领域，具体涉及一种安全实现方法、装置、设备及网元。
背景技术
第五代移动通信技术(5th Generation Mobile Communication Technology，5G)的三大应用场景包括增强型移动宽带(eMBB)、海量机器类通信(mMTC)和超高可靠低时延通信(uRLLC)。随着通信技术的演进，工业无线传感器、视频监控和可穿戴设备等终端物联网应用对5G设备提出了复杂度与成本降低、尺寸减小、能耗更低等新要求。零功耗通信技术在设备的功耗、尺寸以及成本等方面将具有显著优势，从而成为了研究的热点。
然而，在零功耗设备或其他低能力设备的计算能力有限的情况下，这些设备将无法支持复杂的全函数，因此更无法支持第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)的设备认证机制。基于此，零功耗设备设备或其他低能力设备如何授权请求其数据的设备，以进行安全的数据传输，目前并没有明确的解决方法。
发明内容
本申请实施例提供一种安全实现方法、装置、设备及网元。
本申请实施例提供一种安全实现方法，包括：
第一设备获取第一网元的授权凭证；所述授权凭证用于验证所述第一网元是否具有接收数据的权限；所述数据来自于与所述第一设备关联的至少一个第二设备；所述授权凭证包括第一数字签名；
在基于所述第一数字签名对所述授权凭证验证通过的情况下，所述第一设备确定所述第一网元具有接收所述至少一个第二设备发送的数据的权限。
本申请实施例还提供一种安全实现方法，包括：
第一网元向第一设备发送第二请求信息，所述第二请求信息用于请求所述第一设备授予所述第一网元获取至少一个第二设备的数据的权限，所述至少一个第二设备与所述第一设备具有关联关系；
其中，所述第二请求信息中包括授权凭证，所述授权凭证用于所述第一设备验证所述第一网元是否具有接收所述至少一个第二设备的数据的权限；授权凭证通过其包括的第一数字签名进行验证。
本申请实施例还提供另一种安全实现方法，包括：
凭证发放设备接收第一网元发送的第五请求信息；第五请求信息用于请求第一网元的授权凭证；授权凭证用于第一设备验证第一网元是否具有获取数据的权限；数据来自于与第一设备关联的至少一个第二设备；凭证发放设备生成所述第一网元的授权凭证。
本申请实施例提供一种安全实现装置，应用于第一设备，包括：
第一接收单元，被配置为获取第一网元的授权凭证；授权凭证用于验证第一网元是否具有接收数据的权限；数据来自于与第一设备关联的至少一个第二设备；授权凭证包括第一数字签名；
确定单元，被配置为在基于第一数字签名对授权凭证验证通过的情况下，第一设备确定第一网元具有接收至少一个第二设备发送的数据的权限。
本申请实施例还提供一种安全实现装置，应用于第一网元，包括：
第二发送单元，被配置为向第一设备发送第二请求信息，第二请求信息用于请求第一设备授予第一网元获取至少一个第二设备的数据的权限，至少一个第二设备与第一设备具有关联关系；其中，第二请求信息中包括授权凭证，授权凭证用于第一设备验证第一网元是否具有接收至少一个第二设备的数据的权限；授权凭证通过其包括的第一数字签名进行验证。
本申请实施例还提供另一种安全实现装置，应用于凭证发放设备，包括：
第三接收单元，被配置为接收第一网元发送的第五请求信息；第五请求信息用于请求第一网元的授权凭证；授权凭证用于第一设备验证第一网元是否具有获取数据的权限；数据来自于与第一设备关联的至少一个第二设备；凭证生成单元，被配置为生成第一网元的授权凭证。
本申请实施例提供的第一设备，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述的安全实现方法。
本申请实施例提供的第一网元，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述的安全实现方法。
本申请实施例提供的凭证生成设备，包括处理器和存储器。该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行上述的安全实现方法。
本申请实施例提供的芯片，用于实现上述的安全实现方法。具体地，该芯片包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有该芯片的设备执行上述的安全实现方法。
本申请实施例提供的计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行上述的安全实现方法。
本申请实施例提供的计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述的安全实现方法。
本申请实施例提供的计算机程序，当其在计算机上运行时，使得计算机执行上述安全实现方法。
本申请实施例提供的安全实现方法中，第一设备可以代理其关联的至少一个第二设备对第一网元的授权凭证进行验证。在验证通过的情况下，第一设备可以确定第一网元具有接收至少一个第二设备的数据的权限。这样，低运算能力的第二设备可以实现对网络侧的网元进行验证，避免第二设备数据传输过程中的窃取和泄露问题，保证了第二设备的数据传输的安全性。
附图说明
图1是本申请实施例提供的一种示例性的通信系统的网络架构示意图；
图2是本申请实施例提供的一种安全实现方法流程示意图一；
图3是本申请实施例提供的一种安全实现方法流程示意图二；
图4是本申请实施例提供的一种安全实现方法流程示意图三；
图5是本申请实施例提供的一种安全实现方法流程示意图四；
图6是本申请实施例提供的一种安全实现方法流程示意图五；
图7是本申请实施例提供的一种安全实现方法流程示意图六；
图8是本申请实施例提供的在应用场景一中的安全实现方法流程示意图；
图9是本申请实施例提供的在应用场景二中的安全实现方法流程示意图一
图10是本申请实施例提供的在应用场景二中的安全实现方法流程示意图二
图11是本申请实施例提供的在应用场景三中的安全实现方法流程示意图；
图12是本申请实施例提供的在应用场景四中的安全实现方法流程示意图一；
图13是本申请实施例提供的在应用场景四中的安全实现方法流程示意图二；
图14是本申请实施例提供的在应用场景五中的安全实现方法流程示意图一；
图15是本申请实施例提供的在应用场景五中的安全实现方法流程示意图二；
图16是本申请实施例提供的一种安全实现装置1600的结构组成示意图；
图17是本申请实施例提供的一种安全实现装置1700的结构组成示意图；
图18是本申请实施例提供的一种安全实现装置1800的结构组成示意图；
图19是本申请实施例提供的一种通信设备示意性结构图；
图20是本申请实施例的芯片的示意性结构图；
图21是本申请实施例提供的一种通信系统的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图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网络中的终端设备或者未来演进网络中的终端设备等。
无线通信系统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、第一设备获取第一网元的授权凭证；该授权凭证用于验证第一网元是否具有接收数据的权限；数据来自于与第一设备关联的至少一个第二设备；授权凭证包括第一数字签名。
步骤220、在基于第一数字签名对授权凭证验证通过的情况下，第一设备确定第一网元具有接收至少一个第二设备发送的数据的权限。
本申请实施例中，第一设备可以是支持设备认证机制算法的设备，例如，第一设备可以是用户设备UE，基站，以及其他可支持复杂运算的设备，本申请实施例对此不做限制。
第二设备可以是不支持设备认证机制算法的低运算能力的设备，即第二设备是无法单独进行安全运算的设备，例如，第二设备可以是零功耗设备(Zero Power Device，ZPD)，或者运算能力较弱的低能力设备，或者剩余电量较少的设备，本申请实施例对此不做限制。
本申请实施例中，由于第二设备的运算能力较低，因此，第二设备可以与第一设备进行绑定以形成关联关系，这样，第二设备可以利用其关联的第一设备的完备的运算能力和/或通信机制，实现对网络侧网元的授权。其中，第一设备可以与一个或者多个第二设备绑定。
可选地，第二设备可以与第一设备通过调制来波信号实现反向散射的技术进行通信。
另外，本申请实施例所提及的第一网元可以是网络侧网元，其中，第一网元可以是核心网网元、接入网网元、第三方应用网络中的网元等，本申请实施例对此不做限制。例如，第一网元可以是感知服务器，感知服务器可以是提供感知服务(例如定位、测速、健康呼救服务)的应用服务器。
可选地，当第一设备为UE时，第一网元可以为基站或应用服务器。当第一设备为基站时，第一网元可以为应用服务器。
本申请实施例中，第一设备可以获取第一网元的授权凭证，根据该授权凭证验证第一网元是否具有获取该第一设备关联的至少一个第二设备的数据的权限。其中，第一网元的授权凭证可以包括第一数字签名，第一设备可以利用第一数字签名来对授权凭证进行验证，以确定第一网元是否具有获取上述至少一个第二设备数据的权限。
可选地，本申请实施例中所提及的数据可以是第二设备的上行数据，该数据可以包括无线信号、反射信号、控制面数据、用户面数据等，本申请实施例对第二设备发送的数据不做限制，示例性的，第二设备作为感知设备时，该数据可以是感知数据。
可选地，第一设备确定第一网元具有获取其关联的至少一个第二设备的数据后，第二设备可以将产生的数据直接发送给第一网元，第二设备也可以将其产生的数据通过第一设备转发给第一网元，本申请实施例对此不做限制。
也就是说，第一网元可以接收第一设备发送的数据，该数据是至少一个第二设备发送给第一设备的，或者，第一网元可以接收至少一个第二设备发送的数据。
综上所述，本申请实施例提供的安全实现方法中，第一设备可以代理其关联的至少一个第二设备对第一网元的授权凭证进行验证。在验证通过的情况下，第一设备可以确定第一网元具有接收至少一个第二设备的数据的权限。这样，低运算能力的第二设备可以实现对网络侧的网元进行验证，避免第二设备数据传输过程中的窃取和泄露问题，保证了第二设备的数据传输的安全性。
可选地，第一数字签名可以是凭证发放设备的签名，也就是说，第一数字签名可以是利用凭证发放设备的私钥对授权凭证中的其他信息进行签名得到的。应理解，凭证发放设备是生成第一网元授权凭证的设备。
可选地，第一网元的授权凭证包括以下中的至少一项：业务标识信息、凭证发放设备的公钥、凭证发放设备的公钥、第一网元的标识信息、第一网元的公钥、第一网元对应的RSA累加器参数、数据标识信息。
其中，若第一网元根据业务需要而获取数据时，则第一网元的授权凭证中可以包括业务标识信息。该业务标识信息可以用于指示第一网元需要的数据对应的业务类型。其中，业务类型可以包括定位业务、测速业务、健康呼救业务、环境监测业务等，本申请实施例对此不做限制。
可选地，业务标识信息可以是一固定长度的比特数据，其中，不同比特数据对应不同的业务类型。第一设备通过查表的方式确定该比特数据对应的业务类型。
可选地，业务标识信息可以是第一网元的标识信息，一般来说，第一网元可以提供一种或多种业务，因此所需的业务类型不同。基于此，本申请实施例中可以通过第一网元的标识信息来表征数据的业务类型。
其中，第一网元对应的RSA累加器参数用于验证第一网元的授权凭证是否被撤销。应理解，实际应用中存在授权凭证被撤销的情况，因此，在授权凭证中需要携带该授权凭证的RSA参数，以供第一设备验证所获取的第一网元的授权凭证是否被撤销。
另外，数据标识信息，可以用于指示上述数据对应的数据类型，数据类型包括一种或多种。示例性的，如果业务为健康呼救业务，那么数据类型可以包括心率数据、体温数据、运动量数据、血压数据、呼吸频率数据等，如果业务为环境监测业务，那么数据类型可以包括位置数据、风速数据、温度数据、日晒数据、高度数据等。本申请实施例对数据类型不做限制。
需要说明的是，凭证发放设备可以在第一网元的请求下，为第一网元生成授权凭证。凭证发放设备可以是应用提供商证书颁发机构(Certificate Authority，CA)，也可以是业务服务器，也可以是运营商CA，本申请实施例对此不做限制。另外，第一网元请求凭证发放设备生成授权凭证的相关内容详见下文描述，为了简洁，此处不做赘述。
可选地，第一数字签名可以是利用凭证发放设备的私钥对上述信息中的全部内容或部分内容进行签名得到。对应的，参考图3所示，步骤220之前，还可以通过以下步骤实现对授权凭证的验证：
步骤230、第一设备利用凭证发放设备的公钥对第一数字签名进行验证，得到第一验证信息；
步骤240、若第一验证信息与授权凭证中除第一数字签名之外的其他信息一致，则确定授权凭证验证通过。
可以理解的是，既然第一数字签名是利用凭证发放设备的私钥签名得到，那么第一设备可以利用凭证发放设备的公钥对第一数字签名进行验证，得到第一验证信息。只有在第一验证信息与授权凭证中的其他信息一致，第一设备才可以确定第一网元具有获取至少一个第二设备的数据的权限。若不一致，则第一设备不进行进一步处理。
需要说明的是，第一设备可以从授权凭证中获取凭证发放设备的公钥，对第一数字签名进行验证。第一设备也可以提前存储凭证发放设备的公钥，利用预先存储的公钥对第一数字签名进行验证，本申请实施例对凭证发放设备的公钥来源不做限制。
可选地，在一些实施例中，授权凭证包括第一网元对应的RSA累加器参数时，步骤220中在基于第一数字签名对授权凭证验证通过的情况下，第一设备确定第一网元具有接收至少一个第二设备发送的数据的权限，还可以通过以下方式实现：
在基于第一数字签名对授权凭证验证通过的情况下，第一设备基于RSA累加器参数，验证第一网元的授权凭证是否被撤销；
若授权凭证未被撤销，则第一设备确定第一网元具有接收至少一个第二设备的数据的权限。
可以理解的是，在对第一网元的授权凭证验证通过之后，第一设备还可以根据RSA累加器参数验证该授权凭证是否被撤销。若第一网元的授权凭证未被撤销，则第一设备可以确定第一网元具有接收其关联的至少一个第二设备的数据的权限。若第一网元的授权凭证被撤销，则第一设备可以确定第一网元不具有获取第二设备的数据的权限。如此，可以提高第一设备针对第二设备上行数据的授权效率。
可选地，若第一网元的授权凭证中包括业务标识信息和/或数据标识信息，则在对授权凭证进行验证之前，第一设备还需要判断与其关联的第二设备是否支持该业务标识信息指示的业务类型，和/或数据标识信息指示的数据类型。
其中，授权凭证中携带的业务标识信息，可以用来表征第一网元需要获取的数据的业务类型。授权凭证中携带的数据标识信息，可以用来表征第一网元需要获取的数据的数据类型。因此，第一设备获取到第一网元的授权凭证之后，需要先判断与其关联的至少一个第二设备是否支持第一网元 所需的业务类型，和/或数据类型。
可选地，第一设备可以维护一份业务类型列表，该列表可以存储与其关联的每个第二设备的标识信息，以及每个第二设备支持的业务类型。这样，第一设备在获取到第一网元的授权凭证之后，可以将授权凭证中的业务标识信息对应的业务类型与上述列表中每个第二设备支持的业务类型进行对比，从而确定支持该业务类型的第二设备。
可选地，第一设备还可以维护一份数据类型列表，该列表可以存储与第一设备关联的每个第二设备的标识信息，以及每个第二设备支持的数据类型。这样，第一设备在获取到第一网元的授权凭证之后，可以将授权凭证中的数据标识信息对应的数据类型与上述列表中每个第二设备支持的数据类型进行对比，从而确定支持该数据类型的第二设备。
若与第一设备关联的至少一个第二设备中任意一个第二设备支持该业务类型和/或数据类型，则第一设备才启动对第一网元的授权凭证的验证过程，进而基于第一数字签名对第一网元的授权凭证进行验证。若与第一设备关联的至少一个第二设备均不支持该业务类型和/或数据类型，则第一设备忽略该授权凭证，不对该授权凭证进行验证处理。如此，可以保证第一网元接收到的数据的业务类型是符合其需求的业务类型，和/或第一网元接收到的数据的数据类型是符合其需求的数据类型，如此，提高数据授权的效率。
可选地，参考图4所示的流程示意图，本申请实施例提供的安全实现方法中，步骤220中第一设备确定第一网元具有接收至少一个第二设备发送的数据的权限之后，还可以包括以下步骤：
步骤250、第一设备接收第一网元发送的第一指示信息；该第一指示信息用于指示至少一个第二设备中需要向第一网元发送数据的第二设备；
步骤260、第一设备向第一指示信息所指示的第二设备发送第一请求信息；第一请求信息用于请求第一指示信息所指示的第二设备的数据。
本申请实施例中，在第一设备确定第一网元具有获取数据的权限之后，第一网元通过第一指示信息告知第一设备需要哪些第二设备向其发送数据。进而，第一设备可以向第一指示信息所指示的第二设备发送第一请求信息，以请求这些第二设备的数据。
需要说明的是，第一设备关联的至少一个第二设备中包括第一指示信息所指示的第二设备。
可选地，第一指示信息中可以包括需要向第一网元传输数据的第二设备的标识信息。这样，第一设备可以向第一指示信息中携带的标识信息所对应的第二设备发送第一请求信息。
可选地，第一设备信息所指示的第二设备接收到第一请求信息后，可以直接向第一网元发送自己的数据，也可以通过第一设备向第一网元转发自己的数据。本申请实施例对此不做限制。
可选地，参考图4所示，本申请实施例的安全实现方法中步骤260之后，还可以包括以下步骤：
步骤270、第一设备接收第一指示信息所指示的第二设备发送的数据；
步骤280、第一设备向第一网元发送所述数据。
本申请实施例中，第一设备向第一指示信息所指示的第二设备发起数据请求之后，第一设备还可以作为中继设备，将这些第二设备反馈的数据转发给第一网元。如此，实现数据的精准传输，保证数据传输的效率。
可选地，当授权凭证中包括业务标识信息和/或数据标识信息时，上述步骤260第一设备向第一指示信息所指示的第二设备发送第一请求信息，还可以通过以下方式实现：
第一设备向第一指示信息所指示的第二设备中，支持业务标识信息指示的业务类型和/或数据标识信息指示的数据类型的第二设备发送第一请求信息。
也就是说，第一设备在接收到第一指示信息之后，可以仅向第一指示信息所指示的第二设备中，支持上述业务标识信息对应的业务类型和/或支持上述数据标识信息对应的数据类型的第二终端发送第一请求信息。如此，可以保证第二设备发送的数据的业务类型与第一网元所需的业务类型匹配，提高传输效率。
可选地，在一些实施例中，步骤260中第一设备向第一指示信息所指示的第二设备发送第一请求信息之前，还可以与这些第二设备进行互相认证，以确保对方均为受信任的设备。在第一设备与第二设备相互认证通过后，第一设备才继续执行上述步骤260和步骤270，以实现与第二设备之间的物理层安全的数据传输。如此，避免第三方攻击者窃取和篡改数据。
本申请实施例中，第一设备可以与第二设备之间进行简单的设备认证过程，例如，第一设备与第二设备之间可以基于第二设备的初始秘钥K进行认证。其中，初始秘钥K可以是对称秘钥，每个第二设备的本地存储空间均可以存储自己的初始秘钥K。第一设备与第二设备之间也可以基于初始秘钥K进行协商，得到物理层安全秘钥s，进而第一设备与第二设备基于秘钥s进行设备认证，本 申请实施例第一设备与第二设备认证的方式不做限制。
本申请实施例中，第一设备获取第一网元的授权凭证的方式包括多种，下面详细介绍其中的两种。
方式一、
在本申请一实施例中，参考图5所示，步骤210中第一设备获取第一网元的授权凭证，可以通过以下步骤实现：
步骤2101、第一设备接收第一网元发送的第二请求信息；第二请求信息用于请求第一设备授予第一网元获取至少一个第二设备的数据的权限；第二请求信息中包括授权凭证；
步骤2102、第一设备从第二请求信息中获取授权凭证。
可以理解的是，第一网元需要获取第二设备的数据时，可以向第二设备绑定/关联的第一设备发送第二请求信息。这里，第一网元可以在第二请求信息中携带第一网元的授权凭证。这样，第一设备在接收到第二请求信息之后，可以从第二请求信息中获取第一网元的授权凭证，并基于授权凭证中的第一数字签名对该授权凭证进行验证，以确定第一网元是否具有获取第二设备数据的权限。
可选地，第一设备在接收到第二请求信息之后，可以先对发送第二请求信息的第一网元进行身份验证，确定该第一网元是否为受信任的网元，以及确定第二请求信息是否被篡改。只有在对第一网元的身份验证通过的情况下，第一设备才基于第一请求信息获取授权凭证并对该授权凭证进行验证，以此保证后续传输过程中，与第一关联的第二设备的数据不被泄露和窃取。
可选地，第一设备可以使用与第一网元之间的共享秘钥对第一网元进行身份验证，第一设备也可以使用第一网元的公钥对第一网元进行身份验证，本申请实施例对此不做限制。
可选地，第二请求信息中可以包括以下信息中的至少一项：
第一网元的标识信息、第一设备的标识信息、至少一个第二设备中每个第二设备的标识信息、信道参数，信道参数用于建立第一网元与第一设备之间的可信信道；第一网元的公钥、第二数字签名；第二数字签名通过第一网元的私钥对第二请求信息中的其他信息进行签名得到。
应理解，在第一请求信息中包括第二数字签名时，第一设备可以利用第二数字签名对第一网元进行身份验证。其中，第一设备对第一网元进行身份验证的方式包括如下内容：
第一设备利用第一网元的公钥对上述第二数字签名进行验证处理，得到第二验证信息；若第二验证信息与第二请求信息中除第二数字签名之外的其他信息一致，则第一设备确定第一网元身份验证通过。
可选地，第一设备可以维护一份公钥列表，该列表中存储了多个网元的标识信息，以及每个网元对应的公钥。第一设备接收到第一网元发送的第二请求信息后，可以从上述公钥列表中查找第一网元的标识信息对应的公钥。进而第一设备可以基于该公钥对第二数字签名进行验证，得到第二验证信息。
可选地，若第二请求信息中包括第一网元的公钥时，第一设备也可以基于第二请求信息中携带的公钥对第二数字签名进行验证，得到第二验证信息。本申请实施例对第一网元的公钥的获取方式不做限制。
应理解，在第二验证信息与第二请求信息中除第二数字签名之外的其他信息一致的情况下，第一设备确认第一网元为受信任的网元，并且第二请求信息未被篡改，第一网元进一步可以基于第二请求信息中的授权凭证进行验证，以确定第一网元是否具有获取第二设备数据的权限。
在第二验证信息与第二请求信息中除第二数字签名之外的其他信息不一致的情况下，第一设备可以认为第一网元为不受信任的网元，和/或，第一请求信息被第三方篡改。在此情况下，第一设备可以忽略该第二请求信息，不进行进一步处理。
综上所述，本申请实施例提供的安全实现方法中，第一网元可以主动向第一设备发送携带其授权凭证的第一请求信息，以请求第一设备进行验证从而授予其获取第二设备数据的权限。如此，保证第二设备的上行数据不被泄露和窃取。
可选地，步骤2101中第一设备接收第一网元发送的第二请求信息之前，第一网元还可以先获取自己的授权凭证，以生成该第二请求信息。
可选地，第一网元的授权凭证可以存储于第一网元的本地存储空间中，第一网元需要获取第二设备的数据时，可以获取本地存储空间中的授权凭证，并将该授权凭证通过第二请求信息发送给该第二设备绑定/关联的第一设备。
可选地，授权凭证可以不存储在第一网元的本地，而是通过去中心化身份(Decentralized Identity，DID)方式，分布式存储于区块链节点中。当第一网元需要获取第二设备的数据时，可以先从区块 链节点的存储区块中获取第一网元的授权凭证。其中，参考图5所示的流程示意图，第一网元向第一设备发送第二请求信息之前，还可以执行以下步骤：
步骤2001、第一网元向区块链节点发送第四请求信息；第四请求信息用于请求第一网元的授权凭证；第四请求信息包括授权凭证在区块链节点的存储位置信息；
步骤2002、第一网元接收区块链节点发送的该第一网元的授权凭证。
也就是说，第一网元在向第一设备发送第二请求信息之前，可以根据第一网元授权凭证的存储位置信息，向区块链节点请求获取第一网元的授权凭证。在接收到区块链节点反馈的授权凭证之后，第一网元可以将获取到的授权凭证携带在第二请求信息中发送给第一设备，以使第一设备授予其获取与第一设备关联的第二设备的数据。
可选地，由于授权凭证中包括凭证发放设备的第一数字签名，基于此，第一网元接收到区块链节点发送的授权凭证之后，可以使用凭证发放设备的公钥对第一数字签名进行验证，以确定授权凭证的真实性。第一网元在对第一数字签名验证通过后，将该授权凭证携带在第一请求信息中发送给第一设备。
应理解，第一网元的授权凭证可以预先通过凭证发放设备生成。这里，凭证发放设备生成授权凭证之后，可以将授权凭证回传给第一网元，或者将授权凭证上传到区块链节点进行分布式存储。进一步地，当第一网元根据业务需要而获取数据时，可以从本地存储空间获取授权凭证，或者从区块链节点中请求授权凭证，并将获取到的授权凭证通过第一请求信息发送给第一设备。如此，提高第一设备进行数据授权的灵活性。
方式二、
在本申请一实施例中，参考图6所示的流程示意图，步骤210中第一设备获取第一网元的授权凭证，还可以通过以下步骤实现：
步骤2103、第一设备向区块链节点发送第三请求信息，第三请求信息用于请求第一网元的授权凭证；授权凭证存储于区块链节点的区块中；第三请求信息包括授权凭证在区块链节点的存储位置信息；
步骤2104、第一设备接收区块链节点发送的第一网元的授权凭证。
应理解，第一网元的授权凭证可以通过DID方式，分布式存储于区块链节点的区块中。第一设备可以主动地向区块链节点请求第一网元的授权凭证。具体地，第一设备可以根据第一网元授权凭证的存储位置信息，向区块链节点请求获取第一网元的授权凭证。
需要说明的是，第一网元授权凭证的存储位置信息可以是第一设备从接入网网元(例如基站)、或者核心网网元处获取，本申请实施例对此不做限制。
可选地，第一设备主动向区块链节点请求第一网元的授权凭证进行验证授权，可以是根据用户界面接收到的交互指令触发的，也可以是第一设备的应用程序触发，也可以是获取到与第一设备绑定/关联的第二设备的数据后主动触发，本申请实施例对此不做限制。
可选地，本申请实施例中，第一设备可以被触发周期性上传其绑定/关联的第二设备的数据。该周期性上传第二设备的数据可以是第一设备主动发起，也可以通过用户界面交互触发，第一设备的应用程序触发等，本申请实施例对此不做限制。
基于此，第一设备被触发周期性上传数据后，可以主动向区块链节点请求第一网元的授权凭证，对请求到的授权凭证进行验证通过后。与第一设备绑定/关联的第二设备可以按照预设时间周期发送数据，该数据可以通过第一设备转发给第一网元，还可以直接发送给第一网元。当然，第一设备也可以先主动向区块链节点请求第一网元的授权凭证，后触发第二设备周期性上传数据，本申请对两者的先后顺序不做限制。
由此可见，本申请实施例提供的安全实现方法中，第一设备可以主动获取第一网元的授权凭证并进行验证，在验证通过的情况下，第二设备才进行数据传输，如此，保证第二设备的数据不被泄露和窃取。
以下详细介绍授权凭证的生成过程。
在本申请一实施例中，参考图7所示的流程示意图，本申请实施例提供的安全实现方法可以包括以下步骤：
步骤710、凭证发放设备接收第一网元发送的第五请求信息；第五请求信息用于请求第一网元的授权凭证；授权凭证用于第一设备验证第一网元是否具有获取数据的权限；数据来自于与第一设备关联的至少一个第二设备；
步骤720、凭证发放设备生成第一网元的授权凭证。
其中，凭证发放设备可以是应用提供商CA，也可以是应用服务器，本申请实施例对此不做限制。
可以理解的是，第一网元在确定要获取第二设备的数据之前，可以向凭证发放设备发起凭证请求。具体地，第一网元可以通过安全的信道向凭证发放设备发送第五请求信息，以请求凭证发放设备生成第一网元的授权凭证，以使得第一设备可以根据该授权凭证进行验证，判断是否授予第一网元获取第二设备数据的权限。
可选地，凭证发放设备在接收到第五请求信息之后，可以先对发送第五请求信息的第一网元进行身份验证，确定该第一网元是否为受信任的网元，以及确定第五请求信息是否被篡改。只有在对第一网元的身份验证通过的情况下，凭证发放设备才可以为第一网元生成授权凭证。
可选地，第五请求信息中可以包括以下信息中的至少一项：
业务标识信息、第一网元的标识信息、第一网元的公钥、数据标识信息、第三数字签名；第三数字签名通过第一网元的私钥对第五请求信息中的其他信息进行签名得到。
应理解，在第五请求信息中包括第三数字签名时，凭证发放设备可以利用第三数字签名对第一网元进行身份验证。其中，凭证发放设备对第一网元进行身份验证的方式包括如下内容：
凭证发放设备利用第一网元的公钥对第三数字签名进行验证处理，得到第三验证信息；若第三验证信息与第五请求信息中除第三数字签名之外的其他信息一致，则凭证发放设备确定第一网元身份验证通过。
可选地，凭证发放设备可以维护一份公钥列表，该列表中存储了多个网元的标识信息，以及每个网元对应的公钥。凭证发放设备接收到第一网元发送的第五请求信息后，可以从上述公钥列表中查找第一网元的标识信息对应的公钥。进而凭证发放设备基于该公钥对第三数字签名进行验证，得到第三验证信息。
可选地，若第五请求信息中包括第一网元的公钥时，凭证发放设备也可以基于第五请求信息中携带的公钥对第三数字签名进行验证，得到第三验证信息。本申请实施例对第一网元的身份验证方式不做限制。
应理解，在第三验证信息与第五请求信息中除第三数字签名之外的其他信息一致的情况下，凭证发放设备确认第一网元为受信任的网元，并且第五请求信息未被篡改。在第三验证信息与第五请求信息中除第三数字签名之外的其他信息不一致的情况下，凭证发放设备可以认为第一网元为不受信任的网元，和/或，第五请求信息被第三方篡改。在此情况下，凭证发放设备可以忽略该第五请求信息，不做进一步处理。
可选地，在凭证发放设备生成第一网元的授权凭证之前，可以为第一网元生成RSA累加器参数α，第一网元的RSA累加器参数α可以用于证明该第一网元的授权凭证是否被撤销。
可选地，凭证发放设备生成的授权凭证中可以包括以下信息中的至少一项：
业务标识信息、凭证发放设备的标识信息、凭证发放设备的公钥、第一网元的标识信息、第一网元的公钥、第一网元对应的RSA累加器参数、数据标识信息、第一数字签名。其中，第一数字签名可以是凭证发放设备利用自己的私钥对授权凭证中的其他信息进行签名得到。
可选地，参考图7所示的流程示意图，本申请实施例中，凭证发放设备在生成第一网元的授权凭证之后，还可以执行步骤730和步骤740。
步骤730、凭证发放设备向区块链节点发送第一网元的授权凭证；
步骤740、凭证发放设备接收区块链节点发送的授权凭证的存储位置信息。
应理解，凭证发放设备可以向区块链节点发送所生成的第一网元的授权凭证，对第一网元的授权凭证进行上链操作，以实现对该授权凭证进行分布式存储。进一步地，区块链节点接收到授权凭证后，可以将该授权凭证存储于区块链的存储区块中，并将存储位置信息反馈给凭证发放设备。
可选地，参考图7所示，步骤740之后还可以包括以下步骤：
步骤750、凭证发放设备向第一网元发送授权凭证，和/或，存储位置信息。
可以理解的是，凭证发放设备在生成授权凭证之后，可以将生成的授权凭证发送给请求方，即第一网元。凭证发放设备也可以将授权凭证在存储区块中的存储位置信息发送给第一网元，第一网元可以在需要时根据该存储位置信息向区块链节点请求授权凭证。
综上所述，本申请实施例提供的安全实现方法中，凭证生成设备可以根据第一网元的请求，为其生成授权凭证，并对该授权凭证进行分布式存储。这样，第一网元或者第一设备可以从区块链节点请求该授权凭证进行分布式验证，也就是说，在不同地理位置的同一类业务，可以并行进行数据的授权，提高了数据授权的效率。
以下结合具体应用场景，对本申请实施例进行阐述。
应用场景一：
在应用场景一中，第一设备可以是UE，第二设备可以为零功耗设备ZPD，第一网元可以是应用服务器Server，凭证发放设备可以是应用提供商CA。参考图8所示的流程示意图，本申请实施例提供的安全实现方法可以通过以下步骤实现：
步骤801、Server向应用提供商CA发送凭证请求信息。
本实施例中，凭证请求信息用于请求Server的授权凭证。凭证请求信息中可以包括ID server、pk server、ID SP、Type server、以及Sig server中的至少一项。
其中，ID server为Server的标识信息，pk server为Server的公钥，ID SP为业务标识信息，Type server为数据标识信息，Sig server为Server的数字签名。Sig server是Server利用自己的私钥对ID server、pk server、ID SP、Type server中的一项或多项签名得到。
步骤802、应用提供商CA为Server生成授权凭证Cert sp->server。
可选地，应用提供商CA接收到凭证请求信息后可以先对发送请求信息的Server进行身份验证。
具体地，应用提供商CA可以维护一份公钥列表，该列表用于存储多个服务器ID及其公钥。应用提供商CA可以检查凭证请求信息中的ID server是否在公钥列表中，若在该公钥列表中，则获取ID server对应的公钥。
进一步地，应用提供商CA利用ID server对应的公钥对凭证请求信息中的Sig server进行验证。若验证结果与凭证请求信息中的其他信息一致，则确定Server身份验证通过。
需要说明的是，本申请实施例对获取公钥列表的方式不做限制。
本实施例中，应用提供商CA可以基于凭证请求信息中的内容，生成Server的授权凭证，该授权凭证可以使用Cert sp->server表示。
具体地，Cert sp->server可以包括ID server、pk server、ID SP、Type server、pk SP、α server、和Sig sp->server中的至少一项。
其中，pk SP为应用提供商CA的公钥，α server为应用提供商CA为sever生成的RSA累加器参数，Sig sp->server为应用提供商CA用自己的私钥对ID server、pk server、ID SP、Type server、pk SP、α server中的一项或多项签名得到。
步骤803、应用提供商CA向区块链节点发送授权凭证Cert sp->server。
步骤804、应用提供商CA接收区块链节点发送的存储位置信息BlockNum Cert。
步骤805、应用提供商CA向Server发送授权凭证的存储位置信息BlockNum Cert。
可选地，应用提供商CA也可以将授权凭证Cert sp->server直接发送给Server。
步骤806、Server根据存储位置信息BlockNum Cert从区块链节点获取授权凭证Cert sp->server。
可选地，Server可以通过应用提供商CA的公钥pk SP验证获取到的授权凭证Cert sp->server的真实性。具体地，Server利用pk SP对授权凭证Cert sp->server中的Sig sp->server进行验证，若验证结果与授权凭证Cert sp->server中其他信息一致，则确定授权凭证为真实凭证。
步骤807、Server向UE发送数据请求。
本实施例中，数据请求可以包括ID server、ID UE、{ID ZP1、…、ID ZPn}、pk server、g、Cert sp->server、Sig server’中的至少一项。
其中，ID UE为UE的标识信息，ID ZP1、…、ID ZPn为与UE绑定的n个零功耗设备ZP1至ZPn分别对应的标识信息，n为大于1的整数。
需要说明的是，ZP1至ZPn可以是UE关联的所有的零功耗设备中的部分或全部设备，本申请实施例对此不做限制。
另外，g为信道参数，用于建立Server和UE之间的可信信道。Sig server’是Server利用自己的私钥对ID server、ID UE、pk server、{ID ZP1、…、ID ZPn}、g、Cert sp->server中的一项或多项签名得到。
步骤808、UE对Server的身份进行验证。
具体地，UE可以维护一份公钥列表，该列表中存储了多个服务器的标识信息，以及每个服务器对应的公钥。UE接收到Server发送的数据请求后，可以从上述公钥列表中查找ID server对应的公钥pk server。进而UE基于pk server对Sig server’进行验证。若UE基于pk server对Sig server’验证得到的验证结果与数据请求中其他信息一致，则确定Server为受信任的设备。否则，UE确定验证不通过，不进行进一步处理。
步骤809、UE对Server的身份进行验证通过后，对Cert sp->server进行验证，并在对Cert sp->server验证通过后授予Server获取零功耗设备的数据的权限。
本实施例中，UE对Server的身份进行验证通过后，进一步验证Cert sp->server。具体地，UE使用 凭证发放设备的公钥pk SP对Cert sp->server中的数字签名Sig sp->server进行验证，若验证结果与Cert sp->server中的其他信息一致，则确定该Server拥有获取UE绑定的零功耗设备数据的权限。若验证结果与Cert sp->server中的其他信息不一致，则不进行进一步处理。
可选地，若Cert sp->server中包括Server的RSA累加器参数α server，则UE可以利用α server验证该Cert sp->server是否被撤销，若被撤销，则不进行进一步处理。若未被撤销，则UE可以继续执行步骤810。
步骤810、UE分别与各零功耗设备进行设备认证，建立与各零耗设备之间的安全信道。
可选地，UE可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。UE也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而UE与ZP1…ZPn基于秘钥s进行设备认证。
这样，UE与零功耗设备ZP1…ZPn认证成功之后，即可建立UE与各零功耗设备之间的安全信道。
步骤811、UE向各零功耗设备发送触发信号。
这里，UE可以通过步骤810建立的安全信道，向各零功耗设备发送触发信号，以触发各零功耗设备传输数据。
步骤812、UE接收各零功耗设备发送的数据。
这里，各零功耗设备可以通过步骤810与UE建立的安全信道，向UE发送数据。
步骤813、UE向Sever发送各零功耗设备的数据。
这里，UE可以通过无线接入网向Sever发送各零功耗设备的数据。
需要说明的是，应用场景一中步骤801至步骤805可以单独实施，步骤806至步骤813也可以单独实施，步骤801至步骤813可以一起实施，本申请实施例对此不做限制。
应用场景二、
在应用场景二中，第一设备可以是UE，第二设备可以是零功耗设备ZPD，第一网元可以是基站，凭证发放设备可以是应用提供商CA。凭证发放设备可以单独为基站发放授权凭证，参考图9所示的流程示意图，应用提供商CA为基站发放授权凭证的过程可以通过以下步骤实现：
步骤901、基站向应用提供商CA发送凭证请求信息。
本实施例中，凭证请求信息用于请求基站的授权凭证。凭证请求信息中可以包括ID bs、pk bs、ID SP、Type bs、以及Sig bs中的至少一项。
其中，ID bs为基站的标识信息，pk bs为基站的公钥，ID SP为业务标识信息，Type bs为数据标识信息，Sig bs为基站的数字签名。Sig bs是基站利用自己的私钥对ID bs、pk bs、ID SP、Type bs中的一项或多项签名得到。
步骤902、应用提供商CA为基站生成授权凭证。
可选地，应用提供商CA可以对发送请求信息的基站进行身份验证。
具体地，应用提供商CA可以维护一份公钥列表，该列表用于存储使用ID sp对应的业务类型的所有基站ID以及对应的公钥。应用提供商CA可以检查凭证请求信息中的ID bs是否在公钥列表中，若在该公钥列表中，则获取ID bs对应的公钥。
进一步地，应用提供商CA利用ID bs对应的公钥对凭证请求信息中的Sig bs进行验证。若验证结果与凭证请求信息中的其他信息一致，则确定基站身份验证通过。
需要说明的是，本申请实施例对获取公钥列表的方式不做限制。
本实施例中，应用提供商CA可以基于凭证请求信息中的内容，生成基站的授权凭证，该授权凭证可以使用Cert sp->bs表示。
具体地，Cert sp->bs可以包括ID bs、pk bs、ID SP、Type sbs、pk SP、α bs、和Sig sp->bs中的至少一项。其中，pk SP为应用提供商CA的公钥，α bs为应用提供商CA为基站生成的RSA累加器参数，Sig sp->bs为应用提供商CA用自己的私钥对ID bs、pk bs、ID SP、Type sbs、pk SP、α bs中的一项或多项签名得到。
步骤903、应用提供商CA向区块链节点发送授权凭证Cert sp->bs。
步骤904、应用提供商CA接收区块链节点发送的存储位置信息BlockNum Cert。
步骤905、应用提供商CA向基站发送授权凭证的存储位置信息BlockNum Cert。
可选地，应用提供商CA也可以将授权凭证Cert sp->bs直接发送给基站。
步骤906、基站根据存储位置信息BlockNum Cert从区块链节点获取授权凭证Cert sp->bs。
可选地，基站可以通过应用提供商CA的公钥pk SP验证获取到的授权凭证Cert sp->bs的真实性。具体地，基站利用pk SP对授权凭证Cert sp->bs中的Sig sp->bs进行验证，若验证结果与授权凭证Cert sp->bs 中其他信息一致，则确定授权凭证为真实凭证。
步骤907、基站向UE发送数据请求。
本实施例中，数据请求可以包括ID bs、ID UE、{ID ZP1、…、ID ZPn}、pk  bs、g、Cert sp->bs、Sig bs’中的至少一项。
其中，ID UE为UE的标识信息，ID ZP1、…、ID ZPn为与UE绑定的n个零功耗设备ZP1至ZPn分别对应的标识信息，n为大于1的整数。
需要说明的是，ZP1至ZPn可以是UE绑定的所有的零功耗设备中的部分或全部设备，本申请实施例对此不做限制。
另外，g为信道参数，用于建立基站和UE之间的可信信道。Sig bs’是基站利用自己的私钥对ID bs、ID UE、pk bs、{ID ZP1、…、ID ZPn}、g、Cert sp->bs中的一项或多项签名得到。
步骤908、UE对基站的身份进行验证。
具体地，UE可以维护一份公钥列表，该列表中存储了多个基站的标识信息，以及每个基站对应的公钥。UE接收到基站发送的数据请求后，可以从上述公钥列表中查找ID bs对应的公钥pk bs。进而UE基于pk bs对Sig bs进行验证。若UE基于pk bs对Sig bs’验证得到的验证结果与数据请求中其他信息一致，则确定基站为受信任的设备。否则，UE确定验证不通过，不进行进一步处理。
步骤909、UE对基站的身份进行验证通过后，对Cert sp->bs进行验证，并在对Cert sp->bs验证通过后授予基站获取零功耗设备的数据的权限。
本实施例中，UE对基站的身份进行验证通过后，进一步验证Cert sp->bs。具体地，UE使用凭证发放设备的公钥pk SP对Cert sp->bs中的数字签名Sig sp->bs进行验证，若验证结果与Cert sp->bs中的其他信息一致，则确定该基站拥有获取UE绑定的零功耗设备数据的权限。若验证结果与Cert sp->bs中的其他信息不一致，则不进行进一步处理。
可选地，若Cert sp->bs中包括基站的RSA累加器参数α bs，则UE可以利用α bs验证该Cert sp->bs是否被撤销，若被撤销，则不进行进一步处理。若未被撤销，则UE可以继续执行步骤910。
步骤910、UE分别与各零功耗设备进行设备认证，建立与各零功耗设备之间的安全信道。
可选地，UE可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。UE也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而UE与ZP1…ZPn基于秘钥s进行设备认证。这样，UE与零功耗设备ZP1…ZPn认证成功之后，即可建立UE与各零功耗设备之间的安全信道。
步骤911、UE向各零功耗设备发送触发信号。
这里，UE可以通过步骤910建立的安全信道，向各零功耗设备发送触发信号，以触发各零功耗设备传输数据。
步骤912、UE接收各零功耗设备发送的数据。
这里，各个零功耗设备可以通过步骤810与UE建立的安全信道，向UE发送数据。
步骤913、UE向基站发送各零功耗设备的数据。
可选地，参考图10所示的流程示意图，上述步骤912和步骤913还可以替换为以下步骤：
步骤912’、各零功耗设备与基站进行设备认证，建立各零功耗设备与基站之间的安全信道。
可选地，基站可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。基站也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而基站与ZP1…ZPn基于秘钥s进行设备认证。
这样，基站与零功耗设备ZP1…ZPn认证成功之后，即可建立基站与各零功耗设备之间的安全信道。
步骤913’，各零功耗设备向基站发送数据。
这里，各零功耗设备ZP1…ZPn可以通过步骤912’建立的安全信道，向基站发送数据。
需要说明的是，应用场景一中步骤901至步骤905可以单独实施，步骤906至步骤913或步骤906至步骤913’，也可以单独实施，步骤901至步骤913或步骤901至步骤913’可以一起实施，本申请实施例对此不做限制。
应用场景三
在应用场景三中，第一设备可以是基站，第二设备可以为零功耗设备ZPD，第一网元可以是应用服务器Server，凭证发放设备可以是应用提供商CA。参考图11所示的流程示意图，本申请实施例提供的安全实现方法可以通过以下步骤实现：
步骤1101、Server根据存储位置信息BlockNum Cert从区块链节点获取授权凭证Cert sp->server。
可选地，Server可以通过应用提供商CA的公钥pk SP验证获取到的授权凭证Cert sp->server的真实性。具体地，Server利用pk SP对授权凭证Cert sp->server中的Sig sp->server进行验证，若验证结果与授权凭证Cert sp->server中其他信息一致，则确定授权凭证为真实凭证。
步骤1102、Server向基站发送数据请求。
本实施例中，数据请求可以包括ID server、ID bs、{ID ZP1、…、ID ZPn}、pk server、g、Cert sp->server、Sig server’中的至少一项。
其中，ID bs为基站的标识信息，ID ZP1、…、ID ZPn为与基站绑定的n个零功耗设备ZP1至ZPn分别对应的标识信息，n为大于1的整数。
需要说明的是，ZP1至ZPn可以是基站关联的所有的零功耗设备中的部分或全部设备，本申请实施例对此不做限制。
另外，g为信道参数，用于建立Server和基站之间的可信信道。Sig server’是Server利用自己的私钥对ID server、ID bs、pk server、{ID ZP1、…、ID ZPn}、g、Cert sp->server中的一项或多项签名得到。
步骤1103、基站对Server的身份进行验证。
具体地，基站可以维护一份公钥列表，该列表中存储了多个服务器的标识信息，以及每个服务器对应的公钥。基站接收到Server发送的数据请求后，可以从上述公钥列表中查找ID server对应的公钥pk server。进而基站基于pk server对Sig server’进行验证。若基站基于pk server对Sig server’验证得到的验证结果与数据请求中其他信息一致，则确定Server为受信任的设备。否则，基站确定验证不通过，不进行进一步处理。
步骤1104、基站对Server的身份进行验证通过后，对Cert sp->server进行验证，并在对Cert sp->server验证通过后授予Server获取零功耗设备的数据的权限。
本实施例中，基站对Server的身份进行验证通过后，进一步验证Cert sp->server。具体地，基站使用凭证发放设备的公钥pk SP对Cert sp->server中的数字签名Sig sp->server进行验证，若验证结果与Cert sp->server中的其他信息一致，则确定该Server拥有获取基站绑定的多个零功耗设备数据的权限。若验证结果与Cert sp->server中的其他信息不一致，则不进行进一步处理。
可选地，若Cert sp->server中包括Server的RSA累加器参数α server，则基站可以利用α server验证该Cert sp->server是否被撤销，若被撤销，则不进行进一步处理。若未被撤销，则基站可以继续执行步骤1105。
步骤1105、基站分别与各零功耗设备进行设备认证，建立与各零功耗设备之间的安全信道。
可选地，基站可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。基站也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而基站与ZP1…ZPn基于秘钥s进行设备认证。
这样，基站与零功耗设备ZP1…ZPn认证成功之后，即可建立基站与各零功耗设备之间的安全信道。
步骤1106、基站向各零功耗设备发送触发信号。
这里，基站可以通过步骤1105建立的安全信道，向各个零功耗设备发送触发信号，以触发各零功耗设备传输数据。
步骤1107、基站接收各零功耗设备发送的数据。
这里，各零功耗设备可以通过步骤1105与基站建立的安全信道，向基站发送数据。
步骤1108、基站向Sever发送各零功耗设备的数据。
应用场景四
在应用场景四中，第一设备可以是UE，第二设备可以为零功耗设备ZPD，第一网元可以是应用服务器Server，凭证发放设备可以是应用提供商CA。参考图12所示的流程示意图，本申请实施例提供的安全实现方法可以通过以下步骤实现：
步骤1201、UE根据存储位置信息BlockNum Cert从区块链节点获取Server的授权凭证Cert sp->server。
可选地，UE可以通过应用提供商CA的公钥pk SP验证获取到的授权凭证的真实性。具体地，UE可以利用pk SP对授权凭证Cert sp->server中的Sig sp->server进行验证，若验证结果与授权凭证Cert sp->server中其他信息一致，则确定授权凭证为真实凭证。
步骤1202、UE被触发周期性数据上传。
需要说明的是，步骤1201可以在步骤1202之前执行，也可以在步骤1202之后执行，本申请实施例对两个步骤的执行顺序不做限制。
步骤1203、UE对Cert sp->server进行验证，并在验证通过后授予Server获取各零功耗设备数据的 权限。
具体地，UE可以使用凭证发放设备的公钥pk SP对Cert sp->server中的数字签名Sig sp->server进行验证，若验证结果与Cert sp->server中的其他信息一致，则确定该Server拥有获取零功耗设备ZP1…ZPn的数据的权限。若验证结果与Cert sp->server中的其他信息不一致，则不进行进一步处理。
可选地，若Cert sp->server中包括Server的RSA累加器参数α server，则UE可以利用α server验证该Cert sp->server是否被撤销，若被撤销，则不进行进一步处理。若未被撤销，则UE可以继续执行步骤1204。
步骤1204、UE分别与各零功耗设备进行设备认证，建立与各零耗设备之间的安全信道。
可选地，UE可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。UE也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而UE与ZP1…ZPn基于秘钥s进行设备认证。
这样，UE与零功耗设备ZP1…ZPn认证成功之后，即可建立UE与各零功耗设备之间的安全信道。
步骤1205、UE向各零功耗设备发送触发信号。
这里，UE可以通过步骤1204建立的安全信道，向各零功耗设备发送触发信号，以触发各零功耗设备传输数据。
步骤1206、UE接收各零功耗设备发送的数据。
这里，各零功耗设备可以通过步骤1204与UE建立的安全信道，向UE发送数据。
步骤1207、UE向Sever发送各零功耗设备的数据。
这里，UE可以通过无线接入网向Sever发送各零功耗设备的数据。
可选地，参考图13所示的流程示意图，上述步骤1206和步骤1207还可以替换为以下步骤：
步骤1206’、各零功耗设备与Server进行设备认证，建立各零功耗设备与Server之间的安全信道。
可选地，Server可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。Server也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而Server与ZP1…ZPn基于秘钥s进行设备认证。
这样，Server与零功耗设备ZP1…ZPn认证成功之后，即可建立Server与各零功耗设备之间的安全信道。
步骤1207’，各零功耗设备向Server发送数据。
这里，各零功耗设备ZP1…ZPn可以通过步骤911’建立的安全信道，向Server发送数据。
可选地，上述应用场景四中的Server可以替换为基站，相应的，Cert sp->server替换为Cert sp->bs。
应用场景五
在应用场景五中，第一设备可以是基站，第二设备可以为零功耗设备ZPD，第一网元可以是应用服务器Server，凭证发放设备可以是应用提供商CA。参考图14所示的流程示意图，本申请实施例提供的安全实现方法可以通过以下步骤实现：
步骤1401、基站根据存储位置信息BlockNum Cert从区块链节点获取Server的授权凭证Cert sp->server。
可选地，基站可以通过应用提供商CA的公钥pk SP验证获取到的授权凭证的真实性。具体地，基站可以利用pk SP对授权凭证Cert sp->server中的Sig sp->server进行验证，若验证结果与授权凭证Cert sp->server中其他信息一致，则确定授权凭证为真实凭证。
步骤1402、基站被触发周期性数据上传。
需要说明的是，步骤1401可以在步骤1402之前执行，也可以在步骤1402之后执行，本申请实施例对两个步骤的执行顺序不做限制。
步骤1403、基站对Cert sp->server进行验证，并在验证通过后授予Server获取各零功耗设备数据的权限。
具体地，基站可以使用凭证发放设备的公钥pk SP对Cert sp->server中的数字签名Sig sp->server进行验证，若验证结果与Cert sp->server中的其他信息一致，则确定该Server拥有获取零功耗设备ZP1…ZPn的数据的权限。若验证结果与Cert sp->server中的其他信息不一致，则不进行进一步处理。
可选地，若Cert sp->server中包括Server的RSA累加器参数α server，则基站可以利用α server验证该Cert sp->server是否被撤销，若被撤销，则不进行进一步处理。若未被撤销，则基站可以继续执行步骤1404。
步骤1404、基站分别与各零功耗设备进行设备认证，建立与各零耗设备之间的安全信道。
可选地，基站可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。基站也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而基站与ZP1…ZPn基于秘钥s进行设备认证。这样，基站与零功耗设备认证成功之后，即可建立基站与各零功耗设备之间的安全信道。
步骤1405、基站向各零功耗设备发送触发信号。这里，基站可以通过步骤1404建立的安全信道，向各零功耗设备发送触发信号，以触发各零功耗设备传输数据。
步骤1406、基站接收各零功耗设备发送的数据。这里，各零功耗设备可以通过步骤1404与基站建立的安全信道，向基站发送数据。
步骤1407、基站向Sever发送各零功耗设备的数据。
可选地，参考图15所示的流程示意图，上述步骤1406和步骤1407还可以替换为以下步骤：
步骤1406’、各零功耗设备与Server进行设备认证，建立各零功耗设备与Server之间的安全信道。可选地，Server可以通过ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行设备认证。Server也可以基于ZP1…ZPn的初始秘钥K，分别与ZP1…ZPn进行协商，得到各零功耗设备的物理层安全秘钥s，进而Server与ZP1…ZPn基于秘钥s进行设备认证。这样，Server与零功耗设备ZP1…ZPn认证成功之后，即可建立Server与各零功耗设备之间的安全信道。
步骤1407’，各零功耗设备向Server发送数据。
这里，各零功耗设备ZP1…ZPn可以通过步骤911’建立的安全信道，向Server发送数据。
以上结合附图详细描述了本申请的优选实施方式，但是，本申请并不限于上述实施方式中的具体细节，在本申请的技术构思范围内，可以对本申请的技术方案进行多种简单变型，这些简单变型均属于本申请的保护范围。例如，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本申请对各种可能的组合方式不再另行说明。又例如，本申请的各种不同的实施方式之间也可以进行任意组合，只要其不违背本申请的思想，其同样应当视为本申请所公开的内容。又例如，在不冲突的前提下，本申请描述的各个实施例和/或各个实施例中的技术特征可以和现有技术任意的相互组合，组合之后得到的技术方案也应落入本申请的保护范围。
还应理解，在本申请的各种方法实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
图16是本申请实施例提供的安全实现装置1600的结构组成示意图一，应用于第一设备，如图16所示，安全实现装置1600包括：
第一接收单元1601，被配置为获取第一网元的授权凭证；授权凭证用于验证第一网元是否具有接收数据的权限；数据来自于与第一设备关联的至少一个第二设备；授权凭证包括第一数字签名；
确定单元1602，被配置为在基于第一数字签名对授权凭证验证通过的情况下，第一设备确定第一网元具有接收至少一个第二设备发送的数据的权限。
可选地，授权凭证包括以下中的至少一项：业务标识信息，业务标识信息用于指示数据对应的业务类型；凭证发放设备的公钥；第一网元的标识信息；第一网元的公钥；第一网元对应的RSA累加器参数；数据标识信息。
可选地，第一数字签名通过凭证发放设备的私钥进行签名；对应的，安全实现装置1600还可以包括第一验证单元，该第一验证单元，可以被配置为利用凭证发放设备的公钥对第一数字签名进行验证，得到第一验证信息；若第一验证信息与授权凭证中除第一数字签名之外的其他信息一致，则确定授权凭证验证通过。
可选地，授权凭证中包括第一网元对应的RSA累加器参数；对应的，第一验证单元，还被配置为在基于第一数字签名对授权凭证验证通过的情况下，基于RSA累加器参数，验证授权凭证是否被撤销；确定单元1602，还被配置为若授权凭证未被撤销，则第一设备确定第一网元具有接收至少一个第二设备的数据的权限。
可选地，授权凭证中包括业务标识信息，业务标识信息用于指示数据的业务类型；对应的，第一验证单元，还被配置为在至少一个第二设备中任意一个第二设备支持业务类型的情况下，第一设备基于第一数字签名对授权凭证进行验证。
可选地，第一接收单元1601，还被配置为接收第一网元发送的第一指示信息；第一指示信息用于指示至少一个第二设备中需要向第一网元发送数据的第二设备；
安全实现装置1600还包括第一发送单元，被配置为向第一指示信息所指示的第二设备发送第一 请求信息；第一请求信息用于请求第一指示信息所指示的第二设备的数据。
可选地，第一接收单元1601，还被配置为接收第一指示信息所指示的第二设备发送的数据；
第一发送单元，还被配置为向第一网元发送数据。
可选地，授权凭证中包括业务标识信息，业务的标识信息用于数据的业务类型；第一发送单元，还被配置为向第一指示信息所指示的第二设备中支持业务类型的第二设备发送第一请求信息。
可选地，第一接收单元1601，还被配置为接收第一网元发送的第二请求信息；第二请求信息用于请求第一设备授予第一网元获取至少一个第二设备的数据的权限；第二请求信息中包括授权凭证；从第二请求信息中获取授权凭证。
可选地，第二请求信息中还包括以下中的至少一项：第一网元的标识信息；第一设备的标识信息；至少一个第二设备中每个第二设备的标识信息；信道参数；信道参数用于建立第一网元与第一设备之间的可信信道；第一网元的公钥；
第二数字签名；第二数字签名用于第一设备验证第一网元的身份；第二数字签名通过第一网元的私钥对第二请求信息中的其他信息进行签名得到。
可选地，第一接收单元1601，还被配置为在对第一网元的身份验证通过的情况下，从第二请求信息中获取授权凭证。
可选地，第二请求信息中还包括利用第一网元的私钥进行签名的第二数字签名；第一验证单元，还被配置为利用第一网元的公钥对第二数字签名进行验证处理，得到第二验证信息；若第二验证信息与第二请求信息中除第二数字签名之外的其他信息一致，则确定第一网元身份验证通过。
可选地，第一发送单元，还被配置为向区块链节点发送第三请求信息，第三请求信息用于请求第一网元的授权凭证；授权凭证存储于区块链节点的区块中；第三请求信息包括授权凭证在区块链节点的存储位置信息；第一接收单元1601，还被配置为接收区块链节点发送的授权凭证。
可选地，第一发送单元，还被配置为按照预设时间周期向第一网元发送至少一个第二设备传输的数据。
图17是本申请实施例提供的安全实现装置1700的结构组成示意图一，应用于第一网元，如图17所示，安全实现装置1700包括：
第二发送单元1701，被配置为向第一设备发送第二请求信息，第二请求信息用于请求第一设备授予第一网元获取至少一个第二设备的数据的权限，至少一个第二设备与第一设备具有关联关系；其中，第二请求信息中包括授权凭证，授权凭证用于第一设备验证第一网元是否具有接收至少一个第二设备的数据的权限；授权凭证通过其包括的第一数字签名进行验证。
可选地，第二请求信息还包括以下中的至少一项：第一网元的标识信息；第一设备的标识信息；至少一个第二设备中每个第二设备的标识信息；信道参数，信道参数用于建立第一网元与第一设备之间的可信信道；第一网元的公钥；第二数字签名，第二数字签名用于第一设备验证第一网元的身份，第二数字签名通过第一网元的私钥对第二请求信息中的其他信息进行签名得到。
可选地，安全实现装置1700还可以包括第二接收单元，被配置为接收第一设备发送的数据；数据是至少一个第二设备发送给第一设备；或者，第二接收单元，还被配置为接收至少一个第二设备发送的数据。
可选地，第二发送单元1701，还被配置为向区块链节点发送第四请求信息；第四请求信息用于请求第一网元的授权凭证；授权凭证存储于区块链节点的区块中；第四请求信息包括授权凭证在区块链节点的存储位置信息；第二接收单元，还被配置为接收区块链节点发送的授权凭证。
可选地，第二发送单元1701，还被配置为向凭证发放设备发送第五请求信息；第五请求信息用于请求第一网元的授权凭证。
可选地，第五请求信息中包括以下中的至少一项：业务标识信息，业务标识信息用于指示数据对应的业务类型；第一网元的标识信息；第一网元的公钥；数据标识信息；第三数字签名，第三数字签名通过第一网元的私钥签名得到。
可选地，第二接收单元，还被配置为接收凭证发放设备发送的授权凭证，和/或，授权凭证的存储位置信息。
图18是本申请实施例提供的安全实现装置1800的结构组成示意图一，应用于凭证发放设备，如图18所示，安全实现装置1800包括：
第三接收单元1801，被配置为接收第一网元发送的第五请求信息；第五请求信息用于请求第一网元的授权凭证；授权凭证用于第一设备验证第一网元是否具有获取数据的权限；数据来自于与第一设备关联的至少一个第二设备；
凭证生成单元1802，被配置为生成第一网元的授权凭证。
可选地，授权凭证包括以下中的至少一项：业务标识信息，业务标识信息用于指示数据的业务类型；凭证发放设备的标识信息；凭证发放设备的公钥；第一网元的标识信息；第一网元的公钥；第一网元对应的RSA累加器参数；数据标识信息；第一数字签名，第一数字签名通过凭证发放设备的私钥签名得到。
可选地，凭证生成单元1802，还被配置为在对第一网元身份验证通过的情况下，凭证发放设备生成第一网元的授权凭证。
可选地，安全实现装置1800还包括第三发送单元，被配置为向区块链节点发送授权凭证；
第三接收单元1801，还被配置为接收区块链节点发送的授权凭证的存储位置信息。
可选地，第三发送单元，还被配置为向第一网元发送授权凭证，和/或，存储位置信息。
本领域技术人员应当理解，本申请实施例的上述安全实现装置的相关描述可以参照本申请实施例的安全实现方法的相关描述进行理解。
图19是本申请实施例提供的一种通信设备1900示意性结构图。该通信设备可以是第一设备，也可以是第一网元，还可以是凭证发放设备。图19所示的通信设备1900包括处理器1910，处理器1910可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图19所示，通信设备1900还可以包括存储器1920。其中，处理器1910可以从存储器1920中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器1920可以是独立于处理器1910的一个单独的器件，也可以集成在处理器1910中。
可选地，如图19所示，通信设备1900还可以包括收发器1930，处理器1910可以控制该收发器1930与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。
其中，收发器1930可以包括发射机和接收机。收发器1930还可以进一步包括天线，天线的数量可以为一个或多个。
可选地，该通信设备1900具体可为本申请实施例的第一设备，并且该通信设备1900可以实现本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该通信设备1900具体可为本申请实施例的第一网元，并且该通信设备1900可以实现本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该通信设备1900具体可为本申请实施例的凭证发放设备，并且该通信设备1900可以实现本申请实施例的各个方法中由凭证发放设备实现的相应流程，为了简洁，在此不再赘述。
图20是本申请实施例的芯片的示意性结构图。图20所示的芯片2000包括处理器2010，处理器2010可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。
可选地，如图20所示，芯片2000还可以包括存储器2020。其中，处理器2010可以从存储器2020中调用并运行计算机程序，以实现本申请实施例中的方法。
其中，存储器2020可以是独立于处理器2010的一个单独的器件，也可以集成在处理器2010中。
可选地，该芯片2000还可以包括输入接口2030。其中，处理器2010可以控制该输入接口2030与其他设备或芯片进行通信，具体地，可以获取其他设备或芯片发送的信息或数据。
可选地，该芯片2000还可以包括输出接口2040。其中，处理器2010可以控制该输出接口2040与其他设备或芯片进行通信，具体地，可以向其他设备或芯片输出信息或数据。
可选地，该芯片可应用于本申请实施例中的第一设备，并且该芯片可以实现本申请实施例的各个方法中由第一设备实现的相应流程，为了简洁，在此不再赘述。
可选地，该芯片可应用于本申请实施例中的第一网元，并且该芯片可以实现本申请实施例的各个方法中由第一网元实现的相应流程，为了简洁，在此不再赘述。
可选地，该芯片可应用于本申请实施例中的凭证发放设备，并且该芯片可以实现本申请实施例的各个方法中由凭证发放设备实现的相应流程，为了简洁，在此不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。
图21是本申请实施例提供的一种通信系统2100的示意性框图。如图21所示，该通信系统2100包括第一设备2110、第一网元2120、以及凭证发放设备2130。
其中，该第一设备2110可以用于实现上述方法中由第一设备实现的相应的功能，，该第一网元2120可以用于实现上述方法中由第一网元实现的相应的功能，该凭证发放设备2130可以用于实现上述方法中由凭证发放设备实现的相应的功能，为了简洁，在此不再赘述。
应理解，本申请实施例的处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(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 (44)

  1. 一种安全实现方法，所述方法包括：
    第一设备获取第一网元的授权凭证；所述授权凭证用于验证所述第一网元是否具有接收数据的权限；所述数据来自于与所述第一设备关联的至少一个第二设备；所述授权凭证包括第一数字签名；
    在基于所述第一数字签名对所述授权凭证验证通过的情况下，所述第一设备确定所述第一网元具有接收所述至少一个第二设备发送的数据的权限。
  2. 根据权利要求1所述的方法，其中，所述授权凭证包括以下中的至少一项：
    业务标识信息；所述业务标识信息用于指示所述数据对应的业务类型；
    数据标识信息；所述数据标识信息用于指示所述数据的数据类型；
    凭证发放设备的标识信息；
    所述凭证发放设备的公钥；
    所述第一网元的标识信息；
    所述第一网元的公钥；
    所述第一网元对应的RSA累加器参数。
  3. 根据权利要求1或2所述的方法，其中，所述第一数字签名通过凭证发放设备的私钥进行签名，所述方法还包括：
    所述第一设备利用所述凭证发放设备的公钥对所述第一数字签名进行验证，得到第一验证信息；
    若所述第一验证信息与所述授权凭证中除所述第一数字签名之外的其他信息一致，则确定所述授权凭证验证通过。
  4. 根据权利要求1-3任一项所述的方法，其中，所述授权凭证中包括所述第一网元对应的RSA累加器参数；
    所述在基于所述第一数字签名对所述授权凭证验证通过的情况下，所述第一设备确定所述第一网元具有接收所述至少一个第二设备的数据的权限，包括：
    在基于所述第一数字签名对所述授权凭证验证通过的情况下，所述第一设备基于所述RSA累加器参数，验证所述授权凭证是否被撤销；
    若所述授权凭证未被撤销，则所述第一设备确定所述第一网元具有接收所述至少一个第二设备的数据的权限。
  5. 根据权利要求1-4任一项所述的方法，其中，所述授权凭证中包括业务标识信息和/或数据标识信息，所述业务标识信息用于指示所述数据的业务类型，所述数据标识信息用于指示所述数据的数据类型；所述方法还包括：
    在所述至少一个第二设备中任意一个第二设备支持所述业务类型和/或所述数据类型的情况下，所述第一设备基于所述第一数字签名对所述授权凭证进行验证。
  6. 根据权利要求1-5任一项所述的方法，其中，所述第一设备确定所述第一网元具有接收所述至少一个第二设备发送的数据的权限之后，所述方法还包括：
    所述第一设备接收第一网元发送的第一指示信息；所述第一指示信息用于指示所述至少一个第二设备中需要向所述第一网元发送数据的第二设备；
    所述第一设备向所述第一指示信息所指示的第二设备发送第一请求信息；所述第一请求信息用于请求所述第一指示信息所指示的第二设备的数据。
  7. 根据权利要求6所述的方法，其中，所述方法还包括：
    所述第一设备接收所述第一指示信息所指示的第二设备发送的数据；
    所述第一设备向所述第一网元发送所述数据。
  8. 根据权利要求6或7所述的方法，其中，所述授权凭证中包括业务标识信息和/或数据标识信息，所述业务的标识信息用于所述数据的业务类型；
    所述第一设备向所述第一指示信息所指示的第二设备发送第一请求信息，包括：
    所述第一设备向所述第一指示信息所指示的第二设备中，支持所述业务类型和/或所述数据类型的第二设备发送第一请求信息。
  9. 根据权利要求1-8任一项所述的方法，其中，所述第一设备获取第一网元的授权凭证，包括：
    所述第一设备接收第一网元发送的第二请求信息；所述第二请求信息用于请求所述第一设备授予所述第一网元获取所述至少一个第二设备的数据的权限；所述第二请求信息中包括所述授权凭证；
    所述第一设备从所述第二请求信息中获取所述授权凭证。
  10. 根据权利要求9所述的方法，其中，所述第二请求信息中还包括以下中的至少一项：
    所述第一网元的标识信息；
    所述第一设备的标识信息；
    所述至少一个第二设备中每个第二设备的标识信息；
    信道参数；所述信道参数用于建立所述第一网元与所述第一设备之间的可信信道；
    所述第一网元的公钥；
    第二数字签名；所述第二数字签名用于第一设备验证所述第一网元的身份；所述第二数字签名通过所述第一网元的私钥对所述第二请求信息中的其他信息进行签名得到。
  11. 根据权利要求9或10所述的方法，其中，所述第一设备从所述第二请求信息中获取所述授权凭证，包括：
    在对所述第一网元的身份验证通过的情况下，所述第一设备从所述第二请求信息中获取所述授权凭证。
  12. 根据权利要求11所述的方法，其中，所述第二请求信息中还包括利用所述第一网元的私钥进行签名的第二数字签名；
    所述方法还包括：
    所述第一设备利用所述第一网元的公钥对所述第二数字签名进行验证处理，得到第二验证信息；
    若所述第二验证信息与所述第二请求信息中除所述第二数字签名之外的其他信息一致，则确定所述第一网元身份验证通过。
  13. 根据权利要求1-8任一项所述的方法，其中，所述第一设备获取第一网元的授权凭证，包括：
    所述第一设备向区块链节点发送第三请求信息，所述第三请求信息用于请求所述第一网元的授权凭证；所述授权凭证存储于所述区块链节点的区块中；所述第三请求信息包括所述授权凭证在所述区块链节点的存储位置信息；
    所述第一设备接收所述区块链节点发送的所述授权凭证。
  14. 根据权利要求13所述的方法，其中，所述方法还包括：
    所述第一设备按照预设时间周期，向所述第一网元发送所述至少一个第二设备传输的数据。
  15. 一种安全实现方法，其中，
    第一网元向第一设备发送第二请求信息，所述第二请求信息用于请求所述第一设备授予所述第一网元获取至少一个第二设备的数据的权限，所述至少一个第二设备与所述第一设备具有关联关系；
    其中，所述第二请求信息中包括授权凭证，所述授权凭证用于所述第一设备验证所述第一网元是否具有接收所述至少一个第二设备的数据的权限；所述授权凭证通过其包括的第一数字签名进行验证。
  16. 根据权利要求15所述的方法，其中，所述第二请求信息还包括以下中的至少一项：
    所述第一网元的标识信息；
    所述第一设备的标识信息；
    所述至少一个第二设备中每个第二设备的标识信息；
    信道参数；所述信道参数用于建立所述第一网元与所述第一设备之间的可信信道；
    所述第一网元的公钥；
    第二数字签名；所述第二数字签名用于第一设备验证所述第一网元的身份；所述第二数字签名通过所述第一网元的私钥对所述第二请求信息中的其他信息进行签名得到。
  17. 根据权利要求15或16所述的方法，其中，所述方法还包括：
    所述第一网元接收所述第一设备发送的数据；所述数据是所述至少一个第二设备发送给所述第一设备；
    或者，所述第一网元接收所述至少一个第二设备发送的数据。
  18. 根据权利要求15-17任一项所述的方法，其中，所述第一网元向第一设备发送第一请求信息之前，还包括：
    所述第一网元向区块链节点发送第四请求信息；所述第四请求信息用于请求所述第一网元的授权凭证；所述授权凭证存储于所述区块链节点的区块中；所述第四请求信息包括所述授权凭证在所述区块链节点的存储位置信息；
    所述第一网元接收所述区块链节点发送的所述授权凭证。
  19. 根据权利要求18所述的方法，其中，所述第一网元向区块链节点发送第四请求之前，还包括：
    所述第一网元向凭证发放设备发送第五请求信息；所述第五请求信息用于请求所述第一网元的授权凭证。
  20. 根据权利要求19所述的方法，其中，所述第五请求信息中包括以下中的至少一项：
    业务标识信息；所述业务的标识信息用于指示所述数据对应的业务类型；
    所述第一网元的标识信息；
    所述第一网元的公钥；
    数据标识信息；
    第三数字签名，所述第三数字签名通过所述第一网元的私钥签名得到。
  21. 根据权利要求19或20所述的方法，其中，还包括：
    所述第一网元接收所述凭证发放设备发送的所述授权凭证，和/或，所述授权凭证的存储位置信息。
  22. 一种安全实现方法，包括：
    凭证发放设备接收第一网元发送的第五请求信息；所述第五请求信息用于请求所述第一网元的授权凭证；所述授权凭证用于第一设备验证所述第一网元是否具有获取数据的权限；所述数据来自于与所述第一设备关联的至少一个第二设备；
    所述凭证发放设备生成所述第一网元的授权凭证。
  23. 根据权利要求22所述的方法，其中，所述授权凭证包括以下中的至少一项：
    业务标识信息；所述业务标识信息用于指示所述数据的业务类型；
    所述凭证发放设备的标识信息；
    所述凭证发放设备的公钥；
    所述第一网元的标识信息；
    所述第一网元的公钥；
    所述第一网元对应的RSA累加器参数；
    数据标识信息；
    第一数字签名；所述第一数字签名通过所述凭证发放设备的私钥签名得到。
  24. 根据权利要求22或23所述的方法，其中，还包括：
    在对所述第一网元身份验证通过的情况下，所述凭证发放设备生成所述第一网元的授权凭证。
  25. 根据权利要求22-24任一项所述的方法，其中，还包括：
    所述凭证发放设备向区块链节点发送所述授权凭证；
    所述凭证发放设备接收所述区块链节点发送的所述授权凭证的存储位置信息。
  26. 根据权利要求25所述的方法，其中，还包括：
    所述凭证发放设备向所述第一网元发送所述授权凭证，和/或，所述存储位置信息。
  27. 一种安全实现装置，应用于第一设备，包括：
    第一接收单元，被配置为获取第一网元的授权凭证；所述授权凭证用于验证所述第一网元是否具有接收数据的权限；所述数据来自于与所述第一设备关联的至少一个第二设备；所述授权凭证包括第一数字签名；
    确定单元，被配置为在基于所述第一数字签名对所述授权凭证验证通过的情况下，所述第一设备确定所述第一网元具有接收所述至少一个第二设备发送的数据的权限。
  28. 一种安全实现装置，应用于第一网元，包括：
    第二发送单元，被配置为向第一设备发送第二请求信息，所述第二请求信息用于请求所述第一设备授予所述第一网元获取至少一个第二设备的数据的权限，所述至少一个第二设备与所述第一设备具有关联关系；
    其中，所述第二请求信息中包括授权凭证，所述授权凭证用于所述第一设备验证所述第一网元是否具有接收所述至少一个第二设备的数据的权限；所述授权凭证通过其包括的第一数字签名进行验证。
  29. 一种安全实现装置，应用于凭证发放设备，包括：
    第三接收单元，被配置为接收第一网元发送的第五请求信息；所述第五请求信息用于请求所述第一网元的授权凭证；所述授权凭证用于第一设备验证所述第一网元是否具有获取数据的权限；所述数据来自于与所述第一设备关联的至少一个第二设备；
    凭证生成单元，被配置为生成所述第一网元的授权凭证。
  30. 一种第一设备，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求1至14中任一项所述的方法。
  31. 一种第一网元，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行如权利要求15至21中任一项所述的方法。
  32. 一种凭证发放设备，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，执行权利要求22至26中任一项所述的方法。
  33. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求1至14中任一项所述的方法。
  34. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求15至21中任一项所述的方法。
  35. 一种芯片，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的设备执行如权利要求22至26中任一项所述的方法。
  36. 一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1至14中任一项所述的方法。
  37. 一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求15至21中任一项所述的方法。
  38. 一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求22至26中任一项所述的方法。
  39. 一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如权利要求1至14中任一项所述的方法。
  40. 一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如权利要求15至21中任一项所述的方法。
  41. 一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行如权利要求22至26中任一项所述的方法。
  42. 一种计算机程序，所述计算机程序使得计算机执行权利要求1至14中任一项所述方法。
  43. 一种计算机程序，所述计算机程序使得计算机执行权利要求15至21中任一项所述方法。
  44. 一种计算机程序，所述计算机程序使得计算机执行权利要求22至26中任一项所述方法。
PCT/CN2022/083173 2022-03-25 2022-03-25 安全实现方法、装置、设备及网元 Ceased WO2023178691A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202280093484.1A CN118946888A (zh) 2022-03-25 2022-03-25 安全实现方法、装置、设备及网元
PCT/CN2022/083173 WO2023178691A1 (zh) 2022-03-25 2022-03-25 安全实现方法、装置、设备及网元
EP22932752.3A EP4502844A4 (en) 2022-03-25 2022-03-25 METHOD AND APPARATUS FOR IMPLEMENTING SAFETY, DEVICE AND NETWORK ELEMENT
US18/895,027 US20250016005A1 (en) 2022-03-25 2024-09-24 Method for implementing security, device, network element, and chip

Applications Claiming Priority (1)

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

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/895,027 Continuation US20250016005A1 (en) 2022-03-25 2024-09-24 Method for implementing security, device, network element, and chip

Publications (1)

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

Family

ID=88099600

Family Applications (1)

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

Country Status (4)

Country Link
US (1) US20250016005A1 (zh)
EP (1) EP4502844A4 (zh)
CN (1) CN118946888A (zh)
WO (1) WO2023178691A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117056899A (zh) * 2023-10-11 2023-11-14 北京中科江南信息技术股份有限公司 电子凭证的生成方法及装置
WO2025077597A1 (zh) * 2023-10-11 2025-04-17 中兴通讯股份有限公司 数据报文的传输方法、传输授权方法及电子设备
WO2025157074A1 (zh) * 2024-01-22 2025-07-31 华为技术有限公司 一种接入认证方法及相关装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014175721A1 (en) * 2013-04-25 2014-10-30 Mimos Berhad A system and method for privacy management for internet of things services
CN106507350A (zh) * 2016-10-21 2017-03-15 陕西理工学院 一种低耗能受限触发的物联网终端及系统
CN108282453A (zh) * 2017-01-05 2018-07-13 纬创资通股份有限公司 物联网读取装置、安全存取方法以及控制中心设备
CN109756450A (zh) * 2017-11-03 2019-05-14 华为技术有限公司 一种物联网通信的方法、装置和系统
CN113965370A (zh) * 2021-10-19 2022-01-21 深圳市电子商务安全证书管理有限公司 一种数据传输方法、装置、计算机设备及可读存储介质
CN114124375A (zh) * 2021-11-13 2022-03-01 北京工业大学 一种用于物联网环境的多阶段密钥协商方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10250395B1 (en) * 2018-08-29 2019-04-02 Accenture Global Solutions Limited Cryptologic blockchain interoperation
US11196570B2 (en) * 2019-10-07 2021-12-07 Accenture Global Solutions Limited Cryptologic blockchain interoperability membership system
US11888965B2 (en) * 2019-12-10 2024-01-30 Mastercard Asia/Pacific Pte. Ltd. Method and system for IOT device digital asset permission transfer system using blockchain network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014175721A1 (en) * 2013-04-25 2014-10-30 Mimos Berhad A system and method for privacy management for internet of things services
CN106507350A (zh) * 2016-10-21 2017-03-15 陕西理工学院 一种低耗能受限触发的物联网终端及系统
CN108282453A (zh) * 2017-01-05 2018-07-13 纬创资通股份有限公司 物联网读取装置、安全存取方法以及控制中心设备
CN109756450A (zh) * 2017-11-03 2019-05-14 华为技术有限公司 一种物联网通信的方法、装置和系统
CN113965370A (zh) * 2021-10-19 2022-01-21 深圳市电子商务安全证书管理有限公司 一种数据传输方法、装置、计算机设备及可读存储介质
CN114124375A (zh) * 2021-11-13 2022-03-01 北京工业大学 一种用于物联网环境的多阶段密钥协商方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4502844A4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117056899A (zh) * 2023-10-11 2023-11-14 北京中科江南信息技术股份有限公司 电子凭证的生成方法及装置
WO2025077597A1 (zh) * 2023-10-11 2025-04-17 中兴通讯股份有限公司 数据报文的传输方法、传输授权方法及电子设备
WO2025157074A1 (zh) * 2024-01-22 2025-07-31 华为技术有限公司 一种接入认证方法及相关装置

Also Published As

Publication number Publication date
EP4502844A4 (en) 2025-11-19
US20250016005A1 (en) 2025-01-09
EP4502844A1 (en) 2025-02-05
CN118946888A (zh) 2024-11-12

Similar Documents

Publication Publication Date Title
CN114268943B (zh) 授权方法及装置
WO2023283789A1 (zh) 一种安全通信方法及装置、终端设备、网络设备
US20200228988A1 (en) V2x communication device and method for inspecting forgery/falsification of key thereof
KR20210097797A (ko) 디바이스 인증 방법 및 장치
US20030236980A1 (en) Authentication in a communication system
US20250016005A1 (en) Method for implementing security, device, network element, and chip
US11997078B2 (en) Secured authenticated communication between an initiator and a responder
WO2022237741A1 (zh) 一种通信方法及装置
KR20160078426A (ko) 무선 직접통신 네트워크에서 비대칭 키를 사용하여 아이덴티티를 검증하기 위한 방법 및 장치
KR102119586B1 (ko) 통신 네트워크를 통해 데이터를 릴레이하는 시스템 및 방법
CN110351725B (zh) 通信方法和装置
CN112449323B (zh) 一种通信方法、装置和系统
US20240411889A1 (en) Method for implementing, terminal device, network element, and chip
US20230308875A1 (en) Wi-fi security authentication method and communication apparatus
CN111615837B (zh) 数据传输方法、相关设备以及系统
US20250055685A1 (en) Security implementation method and apparatus, device, and network element
CN113472714A (zh) 认证终端设备的方法及装置
CN117579280A (zh) 接入设备的认证方法、聚合设备、装置及存储介质
CN116528234B (zh) 一种虚拟机的安全可信验证方法及装置
US20250016006A1 (en) Security implementation method and apparatus, terminal device, network element and credential generating device
CN119031363B (zh) 一种基于数据安全的应急管理方法及系统
CN116711336A (zh) 无线通信的方法和装置
WO2024261515A1 (en) Pure authentication and key management for applications (akma) based two-factor authentication
CN121312170A (zh) 基于应用认证和密钥管理（akma）的静默双因素认证
CN116847350A (zh) 一种d2d通信方法、终端及介质

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: 22932752

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280093484.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2022932752

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022932752

Country of ref document: EP

Effective date: 20241025