WO2021164458A1 - Procédé de communication, appareil associé, et support de stockage lisible par ordinateur - Google Patents

Procédé de communication, appareil associé, et support de stockage lisible par ordinateur Download PDF

Info

Publication number
WO2021164458A1
WO2021164458A1 PCT/CN2021/070915 CN2021070915W WO2021164458A1 WO 2021164458 A1 WO2021164458 A1 WO 2021164458A1 CN 2021070915 W CN2021070915 W CN 2021070915W WO 2021164458 A1 WO2021164458 A1 WO 2021164458A1
Authority
WO
WIPO (PCT)
Prior art keywords
ipx
message
sepp
public key
signature
Prior art date
Application number
PCT/CN2021/070915
Other languages
English (en)
Chinese (zh)
Inventor
邵国强
刘清明
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2021164458A1 publication Critical patent/WO2021164458A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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
    • 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
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • This application relates to the field of communication technology, and in particular to communication methods and related communication devices and related computer-readable storage media.
  • the 3rd Generation Partnership Project (3GPP, 3rd Generation Partner Project) defines the Security and Edge Protection Proxy (SEPP, Security and Edge Protection Proxy) device as a boundary security gateway for the 5G core network (5GC, 5G Core).
  • SEPP is a proxy device for docking between networks of different operators. The signaling interaction between the network function (NF, Network Function) device within the 5G core network and the roaming network is forwarded through the SEPP device.
  • NF Network Function
  • IP Internet Protocol
  • IPX IP Exchange Service
  • the prior art has not yet provided a scheme for implementing secure communication between an IPX network (such as a routing device in an IPX network, etc.) and a SEPP device. In this case, it may cause signaling or transmission between the SEPP device and the device of the IPX network. Business data was illegally obtained.
  • IPX network such as a routing device in an IPX network, etc.
  • SEPP device may cause signaling or transmission between the SEPP device and the device of the IPX network.
  • Business data was illegally obtained.
  • the embodiments of the present application provide a communication method, related devices, and computer-readable storage media.
  • the first aspect of the embodiments of the present application provides a communication method, including: when a first IPX device sends a first public key to the first SEPP device (the first IPX device may be an IPX device directly connected to the first SEPP device) The first message, the first SEPP device can receive the first message containing the first public key from the first IPX device, where the first public key is the public key of the first IPX device (the first SEPP device can cache The first public key contained in the first message).
  • the first IPX device may forward the first N32f message to the first SEPP device.
  • the first SEPP device receives a first N32f message from the first IPX, the first N32f message contains a first signature content, and the first signature content is signed using the private key of the first IPX (so The first signature content is, for example, obtained by the first IPX device using the private key of the first IPX to sign); the first SEPP device uses the first public key to perform signature verification on the first N32f message (Specifically, the first SEPP device may use the first public key to perform signature verification on the first signature content in the first N32f message).
  • SEPP can directly obtain the public key of IPX from the directly connected IPX, and then when SEPP receives the first N32f message from IPX, SEPP can use the obtained public key of IPX.
  • the key performs signature verification on the first signature content, thereby achieving integrity verification, etc.
  • This signature verification mechanism is beneficial to improve the communication security between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • the first SEPP device may also use the certificate of the first IPX device to perform signature verification on the first N32f message.
  • the first message may be a message used between the first SEPP device and the first IPX device to establish a TLS connection or establish an IPsec connection.
  • the first message may be a server greeting (Server_Hello) message or a client greeting (Client_Hello) message or a client key exchange (Client_Key_exchange) message or a server key exchange (Server_Key_exchange) message or a certificate (Certificate) message Wait.
  • the first message may also be a message used between the first SEPP device and the first IPX device to establish another underlying security connection.
  • the first message may also be a message exchanged after the first SEPP device and the first IPX device establish a secure connection.
  • the first message is a message used to establish a TLS connection or an IPsec connection between the first SEPP device and the first IPX device
  • the first IPX device uses the first SEPP device to communicate with the first SEPP device.
  • the process of establishing a TLS connection or establishing an IPsec connection between the first IPX devices is used to distribute the public key of the first IPX device, which eliminates the need for an additional public key distribution process, which is beneficial to simplify the implementation complexity.
  • the method may further include: the first SEPP device sends the message to the first IPX device.
  • the device sends a HyperText Transfer Protocol (HTTP, HyperText Transfer Protocol) message for querying the public key of the first IPX device, and the first message is a response message of the HTTP message.
  • HTTP HyperText Transfer Protocol
  • the method further includes: the first SEPP device and the first IPX device Establish transport layer security TLS connection or Internet security protocol IPsec connection between devices.
  • the method may further include: the first SEPP device sends a subscription message to the first IPX device The subscription message of the public key of the first IPX device, where the first message is a response message of the subscription message.
  • the method may further include: the first SEPP device sends a subscription message to the first IPX device The subscription message of the public key of the first IPX device.
  • the first IPX device when the first IPX device receives a subscription message for subscribing to the public key of the first IPX device, then the first IPX device can update the public key of the first IPX device by sending a response message of the subscription message to the first IPX device.
  • a SEPP device distributes the updated public key of the first IPX device.
  • the first message is a response message for querying or subscribing to the public key of the first IPX device
  • this can be regarded as the first SEPP device actively requesting the first IPX device to distribute its public key.
  • the mechanism enables the first SEPP device to request the first IPX device to distribute its public key on demand, which is beneficial to improve the autonomous flexibility of the first SEPP device to obtain the public key of the first IPX device, thereby helping to meet a variety of differentiated scenarios need.
  • the method further includes: the first SEPP device receives a second message containing a second public key from a second SEPP device (the second message may be the connection between the first SEPP device and the second SEPP device).
  • the second public key is the public key of the second IPX device;
  • the first N32f message also includes second signature content, and the second signature content Use the private key of the second IPX device to sign.
  • the first SEPP uses the second public key to perform signature verification on the first N32f message (specifically, the first SEPP device may use the second public key to perform signature verification on the first N32f message
  • the second signature content performs signature verification). That is, when the first N32f message contains multiple signature content, the first SEPP device can use the corresponding public key to perform signature verification on the multiple signature content in the first N32f message.
  • the signature verification order of each signature content It is not limited.
  • the first SEPP device may also use the certificate of the second IPX device to perform signature verification on the first N32f message.
  • the method further includes: the first SEPP device receives a second message containing a second public key from a second SEPP device, where the second public key is the second IPX device The public key; the first SEPP device receives the second N32f message from the first IPX device, and the second N32f message contains the second signature content, and the second signature content uses the second The private key corresponding to the public key (the private key of the second IPX device) is signed (the second N32f message does not contain the signature content signed with the private key of the first IPX device, for example), and the first SEPP device uses all The second public key performs signature verification on the second N32f message (specifically, the first SEPP device may use the second public key to perform signature verification on the second signature content in the second N32f message) .
  • the first SEPP device may also use the certificate of the second IPX device to perform signature verification on the second N32f message.
  • a second aspect of the embodiments of the present application provides a first SEPP device, including:
  • the communication unit is configured to receive a first message containing a first public key from a first IPX device, where the first public key is a public key of the first IPX device. Receive a first N32f message from the first IPX, the first N32f message containing the first signature content, the first signature content is signed using the private key of the first IPX (the first signature content, for example, It is obtained by signing by the first IPX device using the private key of the first IPX).
  • the signature verification unit is configured to use a first public key to perform signature verification on the first N32f message (specifically, the first public key may be used to sign the first signature content in the first N32f message check).
  • the first message may be a message used between the first SEPP device and the first IPX device to establish a TLS connection or establish an IPsec connection. Or the first message may also be a message used between the first SEPP device and the first IPX device to establish another underlying security connection. Or the first message may also be a message exchanged after the first SEPP device and the first IPX device establish a secure connection.
  • the communication unit is further configured to, before receiving the first message containing the first public key from the first IPX device, send to the first IPX device a public key for querying the first IPX device.
  • Key HTTP message the first message is a response message of the HTTP message.
  • the first SEPP device further includes a connection unit, configured to communicate with the first IPX device before the communication unit is further used to send an HTTP message for querying the public key of the first IPX device to the first IPX device.
  • a connection unit configured to communicate with the first IPX device before the communication unit is further used to send an HTTP message for querying the public key of the first IPX device to the first IPX device.
  • the communication unit may be further configured to send a subscription for subscribing to the public key of the first IPX device to the first IPX device before receiving the first message containing the first public key from the first IPX device Message, the first message is a response message of the subscription message.
  • the communication unit may be further configured to, after receiving the first message containing the first public key from the first IPX device, send to the first IPX device a subscription for subscribing to the public key of the first IPX device information.
  • the first IPX device when the first IPX device receives a subscription message for subscribing to the public key of the first IPX device, then the first IPX device can update the public key of the first IPX device by sending a response message of the subscription message to the first IPX device.
  • a SEPP device distributes the updated public key of the first IPX device.
  • the communication unit may also be used to receive a second message containing a second public key from a second SEPP device (the second message may be that the first SEPP device interacts with the second SEPP device).
  • the second public key is the public key of the second IPX device; wherein, the first N32f message also includes second signature content, and the second signature content uses the The private key of the second IPX device is signed.
  • the signature verification unit is further configured to use a second public key to perform signature verification on the first N32f message (specifically, the second public key may be used to perform signature verification on the second signature content in the first N32f message. Test). That is, when the first N32f message contains multiple signature content, the signature verification unit can use the corresponding public key to perform signature verification on the multiple signature content in the first N32f message.
  • the signature verification order of each signature content is different. limited.
  • the communication unit may be further configured to receive a second message containing a second public key from a second SEPP device, where the second public key is the public key of the second IPX device; receive To the second N32f message from the first IPX device, and the second N32f message contains the second signature content, and the second signature content uses the private key corresponding to the second public key (the second IPX device (The second N32f message does not contain the signature content signed with the private key of the first IPX device, for example).
  • the signature verification unit is further configured to use the second public key to perform signature verification on the second N32f message (specifically, the second public key can be used to perform signature verification on the second signature content in the second N32f message. Test).
  • a third aspect of the embodiments of the present application provides a communication method, including: a first IPX device sends a first message containing a first public key to a first SEPP device, where the first public key is the Public key; the first IPX device receives the first N32f message from the second IPX device or the second SEPP device, and uses the private key of the first IPX device to sign the first N32f message to obtain the first signature Content; the first IPX device forwards the first N32f message to the first SEPP device, and the first N32f message contains the first signature content.
  • the IPX device can send the first message containing the first public key to the directly connected SEPP device, that is, the SEPP can directly obtain the IPX public key from the directly connected IPX, and then the SEPP receives the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the first signature content, thereby achieving integrity verification, etc.
  • This signature verification mechanism is beneficial to improve Security of communication between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • the first message may be a message used between the first SEPP device and the first IPX device to establish a TLS connection or establish an IPsec connection.
  • the first message may also be a message used between the first SEPP device and the first IPX device to establish another underlying security connection.
  • the first message may also be a message exchanged after the first SEPP device and the first IPX device establish a secure connection.
  • the first message is a message used to establish a TLS connection or an IPsec connection between the first SEPP device and the first IPX device
  • the first IPX device uses the first SEPP device to communicate with the first SEPP device.
  • the process of establishing a TLS connection or establishing an IPsec connection between the first IPX devices is used to distribute the public key of the first IPX device, which eliminates the need for an additional public key distribution process, which is beneficial to simplify the implementation complexity.
  • the method may further include: the first IPX device receives from the A Hypertext Transfer Protocol HTTP message of the first SEPP device used to query the public key of the first IPX device, and the first message is a response message of the HTTP message.
  • the method further includes: the first IPX device Establish a transport layer security TLS connection or an Internet security protocol IPsec connection with the first SEPP device.
  • the method before the first IPX device sends the first message containing the first public key to the first SEPP device, the method further includes: the first IPX device receives the first message from the first SEPP device.
  • the first message is a response message for querying or subscribing to the public key of the first IPX device
  • this can be regarded as the first SEPP device actively requesting the first IPX device to distribute its public key.
  • the mechanism enables the first SEPP device to request the first IPX device to distribute its public key on demand, which is beneficial to improve the autonomous flexibility of the first SEPP device to obtain the public key of the first IPX device, thereby helping to meet a variety of differentiated scenarios need.
  • the first N32f message further includes second signature content, and the second signature content is signed using the private key of the second IPX device.
  • the method further includes: the first IPX device receives a second N32f message from the second IPX device, the second N32f message includes a second signature content, and the second The signature content is signed using the private key of the second IPX device; the second N32f message is forwarded to the first SEPP device.
  • the first SEPP device can use the corresponding public key to perform signature verification on the multiple signature content in the first N32f message.
  • signature verification of each signature content The order is not limited.
  • a fourth aspect of the embodiments of the present application provides a first IPX device, including:
  • the communication unit is configured to send a first message containing a first public key to the first SEPP device, where the first public key is the public key of the first IPX device; receiving from the second IPX device or the second SEPP device The first N32f message;
  • the signature unit is configured to use the private key of the first IPX device to sign the first N32f message to obtain the first signature content.
  • the communication unit is further configured to forward the first N32f message to the first SEPP device, where the first N32f message includes the first signature content.
  • the IPX device can send the first message containing the first public key to the directly connected SEPP device, that is, the SEPP can directly obtain the IPX public key from the directly connected IPX, and then the SEPP receives the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the first signature content, thereby achieving integrity verification, etc.
  • This signature verification mechanism is beneficial to improve Security of communication between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • the first message may be a message used between the first SEPP device and the first IPX device to establish a TLS connection or establish an IPsec connection. Or the first message may also be a message used between the first SEPP device and the first IPX device to establish another underlying security connection. Or the first message may also be a message exchanged after the first SEPP device and the first IPX device establish a secure connection.
  • the first message is a message used to establish a TLS connection or an IPsec connection between the first SEPP device and the first IPX device
  • the first IPX device uses the first SEPP device to communicate with the first SEPP device.
  • the process of establishing a TLS connection or establishing an IPsec connection between the first IPX devices is used to distribute the public key of the first IPX device, which eliminates the need for an additional public key distribution process, which is beneficial to simplify the implementation complexity.
  • the communication unit is further configured to, before sending the first message containing the first public key to the first SEPP device, receive a query for the first IPX from the first SEPP device.
  • a hypertext transfer protocol HTTP message of the public key of the device, and the first message is a response message of the HTTP message.
  • the first IPX device further includes a connection unit, configured to communicate with the first SEPP device before the communication unit receives a Hypertext Transfer Protocol HTTP message for querying the public key of the first IPX device.
  • a transport layer security TLS connection or an Internet security protocol IPsec connection is established between a SEPP device.
  • the communication unit is further configured to, before sending the first message containing the first public key to the first SEPP device, receive a request from the first SEPP device for subscribing to the first IPX device The subscription message of the public key, and the first message is a response message of the subscription message.
  • the first N32f message further includes second signature content, and the second signature content is signed using the private key of the second IPX device.
  • the communication unit is further configured to receive a second N32f message from the second IPX device, where the second N32f message includes second signature content, and the second signature content uses the second N32f message. 2. Sign the private key of the IPX device; forward the second N32f message to the first SEPP device.
  • the first SEPP device can use the corresponding public key to perform signature verification on the multiple signature content in the first N32f message.
  • signature verification of each signature content The order is not limited.
  • a fifth aspect of the embodiments of the present application provides an SEPP device, including: a processor and a memory coupled to each other; the processor is used to call a computer program stored in the memory to execute the SEPP device in the embodiment of the present application. Part or all of the steps of any method.
  • a sixth aspect of the embodiments of the present application provides an IPX device, including: a processor and a memory coupled to each other; wherein, the processor is configured to call a computer program stored in the memory to execute the IPX device in the embodiment of the present application. Part or all of the steps of any method performed.
  • the seventh aspect of the embodiments of the present application provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it can be completed by the SEPP device or the IPX device in the embodiment of the present application. Part or all of the steps of any method performed.
  • the eighth aspect of the embodiments of the present application provides a communication device, including: at least one input terminal, a signal processor, and at least one output terminal; Part or all of the steps of any method executed by the device.
  • a ninth aspect of the embodiments of the present application provides a communication device, including: an input interface circuit, a logic circuit, and an output interface circuit, the logic circuit is used to execute any one of the SEPP device or the IPX device in the embodiment of the present application Part or all of the steps of the method.
  • the tenth aspect of the embodiments of the present application provides a computer program product including instructions.
  • the computer program product runs on a computer device, the computer device is caused to execute part or part of any method that can be executed by SEPP or IPX. All steps.
  • the IPX device may be a domain name server or a Diameter routing agent device.
  • Figure 1-A is a schematic diagram of a 5G network architecture exemplified in an embodiment of the present application.
  • Figure 1-B is a schematic diagram of a network architecture in a roaming scenario as an example of an embodiment of the present application.
  • Figure 1-C is a schematic diagram of a network architecture in another roaming scenario exemplified by an embodiment of the present application.
  • Figure 1-D is a schematic diagram of a network architecture in another roaming scenario exemplified by an embodiment of the present application.
  • Figure 1-E is a schematic diagram of a network architecture in another roaming scenario exemplified by an embodiment of the present application.
  • Figure 1-F is a schematic diagram of content signature and signature verification in a roaming scenario as an example of an embodiment of the present application.
  • Fig. 2 is a schematic flowchart of a communication method provided by an embodiment of the present application.
  • Fig. 3 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • Fig. 4 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • Fig. 5 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • FIG. 6 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • FIG. 8 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • FIG. 9 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of another communication method provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of an SEPP device provided by an embodiment of the present application.
  • FIG. 12 is a schematic structural diagram of an IPX device provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • Fig. 14 is a schematic structural diagram of another communication device provided by an embodiment of the present application.
  • FIG. 15 is a schematic structural diagram of another communication device provided by an embodiment of the present application.
  • FIG. 1-A is a schematic diagram of a 5G network architecture exemplified by an embodiment of the present application.
  • the 5G network splits some functional network elements of the 4G network (such as mobility management entity (MME, Mobility Management Entity), etc.) to a certain extent, and defines an architecture based on a service-oriented architecture.
  • MME mobility management entity
  • MMF Session Management
  • Function access and mobility management functions
  • SMF Session Management Function
  • the user terminal accesses the data network (DN, Data Network) and so on by accessing the operator's network, and uses the service provided by the operator or a third party on the DN.
  • DN Data Network
  • the user terminal, user equipment, terminal device, mobile terminal, or terminal in the embodiments of the present application may be collectively referred to as UE. That is, unless otherwise specified, the UE described later in the embodiments of the present application can be replaced with a user terminal, user equipment, terminal device, mobile terminal, or terminal, and of course they can also be interchanged.
  • the Access and Mobility Management Function is a control plane function in the 3GPP network, which is mainly responsible for the access control and mobility management of the UE's access to the operator's network.
  • the security anchor function SEAF, Security Anchor Function
  • SEAF may be deployed in the AMF, or the SEAF may also be deployed in another device different from the AMF.
  • the SEAF is deployed in the AMF as an example.
  • SEAF and AMF can be collectively referred to as AMF.
  • the session management function is a control plane function in the 3GPP network. Among them, the SMF is mainly used to manage the data packet (PDU, Packet Data Unit) session of the UE.
  • the PDU session is a channel used to transmit PDUs, and the UE can send PDUs to each other through the PDU session and the DN.
  • SMF is responsible for management work such as the establishment, maintenance and deletion of PDU sessions.
  • the data network (DN, Data Network) is also called the Packet Data Network (PDN, Packet Data Network), which is a network located outside the 3GPP network.
  • the 3GPP network can access multiple DNs, and multiple services provided by operators or third parties can be deployed on the DNs.
  • a certain DN is a private network of a smart factory, sensors installed on the smart factory workshop play the role of UE, and a control server for the sensors is deployed in the DN.
  • the UE communicates with the control server, and after obtaining the instruction of the control server, the UE can transmit the collected data to the control server according to the instruction.
  • a DN is a company's internal office network, and the terminal used by the company's employees can play the role of a UE, and this UE can access the company's internal information and other resources.
  • the unified data management entity (UDM, Unified Data Management) is also a control plane function in the 3GPP network.
  • UDM is mainly responsible for storing the subscription data, credentials and persistent identity of the subscriber (UE) in the 3GPP network.
  • SUPI Subscriber Permanent Identifier
  • These data can be used to authenticate and authorize the UE to access the operator's 3GPP network.
  • the authentication server function (AUSF, Authentication Server Function) is also a control plane function in the 3GPP network, and the AUSF is mainly used for the first-level authentication (that is, the 3GPP network authenticates its subscribers).
  • the Network Exposure Function (NEF, Network Exposure Function) is also a control plane function in the 3GPP network.
  • NEF is mainly responsible for opening the external interface of the 3GPP network to third parties in a safe manner.
  • SMF and other functions need to communicate with third-party network elements
  • NEF can be used as a communication relay.
  • when relaying, NEF can translate internal and external logos. For example, when the SUPI of the UE is sent from the 3GPP network to a third party, the NEF can translate the SUPI into its corresponding external identity (ID, Identity). Conversely, NEF can translate the external identity ID into the corresponding SUPI when it is sent to the 3GPP network.
  • ID external identity
  • the network storage function (NRF, Network Repository Function) is also a control plane function in the 3GPP network, which is mainly responsible for storing the configuration service profile of the accessible network function (NF) and providing the network for other network elements Functional discovery service.
  • the user plane function (UPF, User Plane Function) is the gateway for the communication between the 3GPP network and the DN.
  • the Policy Control Function (PCF, Policy Control Function) is a control plane function in the 3GPP network, which is used to provide the SMF with the policy of the PDU session.
  • Strategies may include billing, quality of service (QoS, Quality of Service), authorization-related strategies, and so on.
  • Access Network is a sub-network of the 3GPP network. To access the 3GPP network, the UE first needs to go through the AN. In the wireless access scenario, AN is also called Radio Access Network (RAN, Radio Access Network), so the two terms RAN and AN are often mixed without distinction.
  • RAN Radio Access Network
  • 3GPP network refers to a network that complies with 3GPP standards. Among them, the part except UE and DN in Fig. 1-A can be regarded as 3GPP network.
  • 3GPP networks are not limited to 5G networks defined by 3GPP, but can also include 2G, 3G, and 4G networks. Usually 3GPP networks are operated by operators.
  • N1, N2, N3, N4, N6, etc. in the architecture shown in Figure 1-A respectively represent reference points between related entities/network functions. Nausf, Namf... etc. respectively represent service-oriented interfaces of related network functions.
  • 3GPP networks and non-3GPP networks may coexist, and some network elements in the 5G network may also be used in some non-5G networks.
  • SEPP SEPP equipment
  • SEPP acts as an agent for the docking between operator networks, and the signaling interaction between the internal network function (NF) of the 5G core network and the roaming network is forwarded through SEPP.
  • SEPP While supporting the integrity and confidentiality protection of transmission messages, SEPP also supports IPX devices (IPX for short) to identify and modify the content of non-sensitive transmission messages.
  • the SEPP device is referred to as SEPP for short (for example, the first SEPP device is referred to as the first SEPP, and the second SEPP device is referred to as the second SEPP, and so on), that is, the SEPP device and the SEPP can be mixed.
  • the IPX device is referred to as IPX (for example, the first IPX device is referred to as the first IPX, the second IPX device is referred to as the second IPX, and so on), that is, the IPX device and the IPX can be mixed.
  • IPX there may be one IPX between the SEPPs of different operator networks (such as the example shown in Figure 1-D), or there may be multiple IPXs (such as the example shown in Figure 1-C) ).
  • SEPP when the UE roams between different operator networks, SEPP can be divided into visiting SEPP (vSEPP, visit SEPP) and home SEPP (hSEPP, home SEPP).
  • SEPP can be divided into SEPP (cSEPP, consumer's SEPP) for serving consumers and SEPP (pSEPP, producer's SEPP) for service producers.
  • SEPP SEPP
  • pSEPP producer's SEPP
  • vSEPP may be pSEPP and hSEPP may be cSEPP.
  • vSEPP may also be cSEPP and hSEPP may be pSEPP.
  • IPX network directly connected to pSEPP is called pIPX
  • cIPX IPX network directly connected to cSEPP
  • the IPX network may include Diameter routing agent (DRA, Diameter routing agent) equipment and domain name server (domain name server, DNS).
  • DRA Diameter routing agent
  • DNS domain name server
  • Figure 1-F shows an example of a possible implementation in which IPX devices use IPX's private key to sign, and SEPP uses IPX's public key to verify the signature. While SEPP supports the integrity and confidentiality protection of transmission messages, it also supports IPX to identify and modify the content of non-sensitive transmission messages.
  • the IPX device may be a DRA device or DNS in an IPX network.
  • SEPP needs to support the above functions, and then realize the secure communication between IPX network equipment (such as DRA equipment or DNS backup in IPX network) and SEPP, then SEPP needs to obtain the IPX public key.
  • IPX network equipment such as DRA equipment or DNS backup in IPX network
  • SEPP needs to obtain the IPX public key.
  • the following describes some example implementations of SEPP obtaining and using the IPX public key. These example implementations can be applied to roaming scenarios.
  • a communication method may include:
  • the first IPX sends a first message containing a first public key to the first SEPP, where the first public key is the public key of the first IPX.
  • the first public key may be included in the certificate of the first IPX, for example, that is, the first IPX sends a first message containing the certificate of the first IPX to the first SEPP.
  • the first SEPP may receive the first message containing the first public key from the first IPX.
  • the first SEPP may obtain the first public key from the first message.
  • the first message may be a related message used to establish a secure connection (or secure tunnel) between the first SEPP and the first IPX.
  • the first message may also be a message exchanged after the secure connection between the first SEPP and the first IPX is established.
  • the secure connection mentioned in each embodiment of the present application is, for example, a Transport Layer Security (TLS, Transport Layer Security) connection or an Internet Security Protocol (IPsec, Internet Protocol Security) connection or other underlying security connections.
  • TLS Transport Layer Security
  • IPsec Internet Protocol Security
  • the connection in each embodiment of the present application may also be called a tunnel or a channel, for example, a TLS connection may also be called a TLS tunnel or a TLS channel, and an IPsec connection may also be called an IPsec tunnel or an IPsec channel.
  • the first IPX uses the first IPX private key (that is, the private key corresponding to the first public key) to The first N32f message is signed to obtain the first signature content (specifically, for example, the modified content of the first N32f message may be signed to obtain the first signature content).
  • the first IPX forwards the first N32f message to the first SEPP, where the first N32f message includes the first signature content.
  • the first SEPP receives the first N32f message from the first IPX, and the first N32f message includes the first signature content, and the first signature content uses the first public The private key corresponding to the key performs signature, and the first SEPP uses the first public key to perform signature verification on the first signature content.
  • the first SEPP may forward the service request or response carried by the first N32f message to the corresponding NF.
  • the signature (such as the first signature content) mentioned in each embodiment of this application may be JavaScript Object Notation (JSON, JavaScript Object Notation) web signature (JWS, JSON Web Signature) or other forms sign.
  • JSON JavaScript Object Notation
  • JWS JavaScript Object Notation
  • JWS JSON Web Signature
  • SEPP can directly obtain the public key of IPX from the directly connected IPX, and then when SEPP receives the first N32f message from IPX, SEPP can use the obtained public key of IPX.
  • the key performs signature verification on the first signature content, thereby achieving integrity verification.
  • This signature verification mechanism is beneficial to improve the communication security between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • FIG. 3 is a schematic flowchart of another communication method provided by an embodiment of this application.
  • the first SEPP will verify the related signatures made by the IPX directly connected to it.
  • another communication method may include:
  • the first IPX and the first SEPP establish a secure connection (the first IPX sends the first public key to the first SEPP by using a related message established by the secure connection).
  • the second IPX and the second SEPP perform a secure connection establishment (the second IPX sends a second public key to the second SEPP by using the related message of the secure connection establishment).
  • the first IPX is directly connected to the first SEPP.
  • the second IPX is directly connected to the second SEPP.
  • the first IPX is cIPX and the first SEPP is cSEPP
  • the second IPX is pIPX
  • the second SEPP is pSEPP.
  • the second IPX is cIPX and the second SEPP is cSEPP
  • the first IPX is pIPX and the first SEPP is pSEPP.
  • the first public key is the public key of the first IPX.
  • the second public key is the public key of the second IPX.
  • the first SEPP may obtain the public key of the first IPX from the first IPX through the secure connection establishment process.
  • the second SEPP may obtain the public key of the second IPX from the second IPX through the secure connection establishment process.
  • the first public key may be included in the certificate of the first IPX, for example, the first SEPP may obtain the certificate containing the public key of the first IPX from the first IPX through the secure connection establishment process.
  • the second public key may be included in the certificate of the second IPX, for example, the second SEPP may obtain the certificate containing the public key of the second IPX from the second IPX through the secure connection establishment process.
  • the establishment of a secure connection between the first IPX and the first SEPP may be performed before, after, or in synchronization with the second IPX and the second SEPP.
  • the second SEPP conducts mutual authentication with the first SEPP.
  • the second SEPP and the first SEPP exchange the public key of the IPX they obtained during the mutual authentication process, that is, the second SEPP obtains the public key of the first IPX from the first SEPP during the mutual authentication process.
  • the first SEPP obtains the public key of the second IPX from the second SEPP.
  • the second SEPP sends the first N32f message to the second IPX.
  • the first N32f message may be an N32f request or an N32f response.
  • the first N32f message may specifically carry a roaming signaling message or a roaming data packet.
  • the second IPX receives the first N32f message from the second SEPP, and the second IPX forwards the first N32f message to the first IPX.
  • the first IPX receives the first N32f message from the second IPX, and the first IPX uses the private key corresponding to the first public key (the private key of the first IPX) to perform the content of the first N32f message Sign to get the first signature content.
  • the first IPX can add content to the received N32f message, and then sign the added content or sign the overall message content after the added content.
  • the first IPX forwards the signed first N32f message to the first SEPP, where the first N32f message includes the first signature content.
  • the first SEPP receives the first N32f message from the first IPX, and the first N32f message includes the first signature content, and the first signature content uses the first public The private key corresponding to the key is signed, and the first SEPP uses the first public key to perform signature verification on the first N32f message (specifically, the first SEPP uses the first public key to The first signature content in the first N32f message is subjected to signature verification).
  • the first SEPP may forward the service request or response carried by the first N32f message to the related NF.
  • SEPP can obtain the public key of IPX directly from the directly connected IPX through the secure connection establishment process, and then when SEPP receives the first N32f message from IPX, SEPP can use the acquisition The received IPX public key performs signature verification on the first signature content, thereby achieving integrity verification.
  • This signature verification mechanism is beneficial to improve the communication security between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • FIG. 4 is a schematic flowchart of another communication method provided by an embodiment of the application.
  • the first SEPP will verify the related signatures of the directly connected and not directly connected IPX respectively.
  • another communication method may include:
  • the first IPX and the first SEPP perform a secure connection establishment (the first IPX sends the first public key to the first SEPP by using the related message of the secure connection establishment).
  • the second IPX and the second SEPP perform a secure connection establishment (the second IPX sends a second public key to the second SEPP using a message related to the secure connection establishment).
  • the second SEPP conducts mutual authentication with the first SEPP.
  • step 401 to step 403 are the same as step 301 to step 303, and the related technical details can refer to the detailed description of step 301 to step 303.
  • the second SEPP sends the first N32f message to the second IPX.
  • the second IPX receives the first N32f message from the second SEPP, and the second IPX uses the private key corresponding to the second public key (the private key of the second IPX) to perform the content of the first N32f message. Sign to get the second signature content.
  • the second IPX can add content to the received N32f message, and then sign the added content or sign the overall message content after the added content.
  • the second IPX forwards the signed first N32f message to the first IPX, where the first N32f message includes the second signature content.
  • the first IPX receives the first N32f message containing the second signature content from the second IPX, and the first IPX uses the private key corresponding to the first public key (private key of the first IPX) to The content of the first N32f message is signed to obtain the first signature content.
  • the first IPX can add content to the received N32f message, and then sign the added content or sign the overall message content after the added content.
  • the first IPX forwards the first N32f message to the first SEPP, where the first N32f message includes the first signature content and the second signature content.
  • the first SEPP receives the first N32f message from the first IPX, and the first N32f message contains the first signature content and the second signature content, and the first signature The content is signed using the private key corresponding to the first public key, and the second signature content is signed using the private key corresponding to the second public key.
  • the first SEPP uses the first public key and the second public key. Key to perform signature verification on the first N32f message (specifically, for example, the first SEPP uses the first public key to perform signature verification on the first signature content in the first N32f message, the first An SEPP uses the second public key to perform signature verification on the second signature content in the first N32f message).
  • the first SEPP may forward the service request or response carried by the first N32f message to the related NF.
  • SEPP can obtain the public key of IPX directly from the directly connected IPX through the secure connection establishment process, and can obtain the public key of other IPX through the SEPP mutual authentication process, and then can receive the public key in SEPP.
  • SEPP can use the obtained IPX public key to perform signature verification on the first signature content and the second signature content, thereby achieving integrity verification.
  • This signature verification mechanism has It is helpful to improve the communication security between SEPP and IPX.
  • the first IPX device and the second IPX device respectively signed the N32f message, and the first SEPP performed two integrity checks on the received N32f message (two signature verifications). Test), which further improves the security of the communication process.
  • FIG. 5 is a schematic flowchart of another communication method provided by an embodiment of the application.
  • the first SEPP will verify the related signatures made by the IPX that is not directly connected to it.
  • another communication method may include:
  • the first IPX and the first SEPP perform a secure connection establishment (the first IPX sends the first public key to the first SEPP by using the related message of the secure connection establishment).
  • the second IPX and the second SEPP perform a secure connection establishment (the second IPX sends a second public key to the second SEPP using a message related to the secure connection establishment).
  • the second SEPP conducts mutual authentication with the first SEPP.
  • step 501 to step 503 are the same as step 301 to step 303, and the related technical details can refer to the detailed description of step 301 to step 303.
  • the second SEPP sends the first N32f message to the second IPX.
  • the second IPX receives the first N32f message from the second SEPP, and the second IPX uses the private key corresponding to the second public key (private key of the second IPX) to perform the content of the first N32f message. Sign to get the second signature content.
  • the second IPX can add content to the received N32f message, and then sign the added content or sign the overall message content after the added content.
  • the second IPX forwards the signed first N32f message to the first IPX, where the first N32f message includes the second signature content.
  • the first IPX receives the first N32f message containing the second signature content from the second IPX, and the first IPX forwards the first N32f message containing the second signature content to the first SEPP .
  • the first SEPP receives the first N32f message from the first IPX, and the first N32f message contains the second signature content, and the second signature content uses the private key corresponding to the second public key
  • the first SEPP uses the second public key to perform signature verification on the first N32f message (for example, the first SEPP uses the second public key to perform the signature verification on the first N32f message).
  • the second signature content performs signature verification).
  • the first SEPP may forward the service request or response carried by the first N32f message to the related NF.
  • SEPP can obtain the public key of IPX directly from the directly connected IPX through the secure connection establishment process, and obtain the public key of other IPX through the SEPP mutual authentication process, and then it can be received when SEPP For the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the second signature content, thereby achieving integrity verification.
  • This signature verification mechanism is beneficial to improve the communication between SEPP and IPX. Communication security.
  • FIG. 6 is a schematic flowchart of another communication method provided by an embodiment of the application.
  • This embodiment mainly introduces an example process for establishing a TLS connection between SEPP and IPX, where IPX can release its public key during the establishment of a TLS connection.
  • another communication method may include:
  • SEEP sends a client hello (Client_Hello) message to IPX.
  • the IPX may send a server hello (Server_Hello) message to the SEEP.
  • server hello Server_Hello
  • the IPX sends a certificate (Certificate) message containing the public key of the IPX to the SEEP.
  • IPX sends a server key exchange (Server_Key_exchange) message to SEEP.
  • Server_Key_exchange server key exchange
  • IPX sends a request for client certificate (Request_Client_Certificate) message to SEEP.
  • IPX sends a server greeting confirmation (Server_Hello_done) message to SEEP.
  • the SEEP sends a certificate (Certificate) message to the IPX.
  • SEEP sends a client certificate verification (Client_Certificate_verify) message to IPX.
  • SEEP sends a client key exchange (Client_Key_exchange) message to IPX.
  • SEEP sends a Change_cipher_spec message to IPX.
  • the SEEP sends a Finish message to the IPX.
  • IPX sends a Change_cipher_spec message to SEEP.
  • IPX sends a Finish message to SEEP.
  • IPX publishes the public key of IPX to SEEP through a Certificate message.
  • IPX can also publish the public key of IPX to SEEP through other messages used to establish a TLS tunnel.
  • FIG. 7 is a schematic flowchart of another communication method provided by an embodiment of the application.
  • This embodiment mainly introduces an example process for establishing a TLS connection between SEPP and IPX, where IPX can release its public key during the establishment of a TLS connection.
  • another communication method may include:
  • IPX sends a client hello (Client_Hello) message to SEEP.
  • SEEP After SEEP receives the Client_Hello message sent by IPX, SEEP sends Server_Hello message to IPX.
  • the SEEP sends a certificate (Certificate) message to the IPX.
  • SEEP sends a server key exchange (Server_Key_exchange) message to IPX.
  • Server_Key_exchange server key exchange
  • the SEEP sends a request for a client certificate (Request_Client_Certificate) message to the IPX.
  • the SEEP sends a server greeting confirmation (Server_Hello_done) message to the IPX.
  • the IPX sends a certificate (Certificate) message containing the public key of the IPX to the SEEP.
  • IPX sends a client certificate verification (Client_Certificate_verify) message to SEEP.
  • IPX sends a client key exchange (Client_Key_exchange) message to SEEP.
  • IPX sends a Change_cipher_spec message to SEEP.
  • IPX sends a Finish message to SEEP.
  • SEEP sends a Change_cipher_spec message to IPX.
  • the SEEP sends a Finish message to the IPX.
  • IPX publishes the public key of IPX to SEEP through a Certificate message.
  • IPX can also publish the public key of IPX to SEEP through other messages used to establish a TLS tunnel.
  • FIG. 8 is a schematic flowchart of another communication method provided by an embodiment of this application.
  • the first SEPP will verify the related signatures made by the IPX directly connected to it.
  • another communication method may include:
  • a secure connection is established between the first IPX and the first SEPP.
  • a secure connection is established between the second IPX and the second SEPP.
  • the first IPX is directly connected to the first SEPP
  • the second IPX is directly connected to the second SEPP.
  • the first IPX is cIPX and the first SEPP is cSEPP
  • the second IPX is pIPX
  • the second SEPP is pSEPP.
  • the second IPX is cIPX and the second SEPP is cSEPP
  • the first IPX is pIPX and the first SEPP is pSEPP.
  • the establishment of a secure connection between the first IPX and the first SEPP may be performed before, after, or in synchronization with the second IPX and the second SEPP.
  • the first SEPP sends a first HTTP message for querying the public key of the first IPX to the first IPX.
  • the first IPX sends a response message of the first HTTP message (such as a 200 OK message, the format of the 200 OK message may be, for example, JSON) to the first SEPP, and the response message of the first HTTP message includes the first public key.
  • the first public key is the public key of the first IPX.
  • the first public key may be included in the certificate of the first IPX, that is, the response message of the first HTTP message may include the certificate of the first IPX.
  • the first SEPP sends a first subscription message for subscribing to the first IPX public key to the first IPX.
  • the first IPX receives the first subscription message, if the first IPX public key is updated, the first IPX can send a subscription response containing the updated first IPX public key to the first SEPP (such as 200 OK message, 200 OK
  • the format of the message can be, for example, JSON).
  • the first HTTP message also has the subscription function of the first IPX public key, the first subscription message may not be sent.
  • the second SEPP sends a second HTTP message for querying the public key of the second IPX to the second IPX,
  • the second IPX sends a response message (such as 200 OK) of the second HTTP message to the second SEPP, and the response message of the second HTTP message contains the second public key.
  • the second public key is the public key of the second IPX.
  • the second public key may be included in the certificate of the second IPX, that is, the response message of the second HTTP message may include the certificate of the second IPX.
  • the second SEPP sends a second subscription message for subscribing to the second IPX public key to the second IPX.
  • the second IPX may send a subscription response containing the updated second IPX public key to the second SEPP.
  • the second HTTP message also has the subscription function of the second IPX public key, the second subscription message may not be sent.
  • steps 803-805 may be earlier, later than, or synchronized with steps 806-808.
  • the second SEPP conducts mutual authentication with the first SEPP.
  • the second SEPP sends the first N32f message to the second IPX.
  • the second IPX receives the first N32f message from the second SEPP, and the second IPX forwards the first N32f message to the first IPX.
  • the first IPX receives the first N32f message from the second IPX, and the first IPX uses the private key corresponding to the first public key to sign the content of the first N32f message to obtain the first signature content.
  • the first IPX forwards the signed first N32f message to the first SEPP, where the first N32f message includes the first signature content.
  • the first SEPP uses the first public key to perform signature verification on the first N32f message (specifically, for example, The first SEPP uses the first public key to perform signature verification on the first signature content in the first N32f message).
  • step 809 to step 814 are the same as step 303 to step 308, and the related technical details can refer to the detailed description of step 303 to step 308.
  • the first SEPP may forward the service request or response carried by the first N32f message to the related NF.
  • SEPP can directly obtain the IPX public key from the directly connected IPX through the active request process, and pass the SEPP mutual authentication process Obtain other IPX public keys, and then when SEPP receives the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the first signature content, thereby achieving integrity verification,
  • This signature verification mechanism helps to improve the communication security between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and thereby helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • FIG. 9 is a schematic flowchart of another communication method provided by an embodiment of this application.
  • the first SEPP will verify the related signatures of the directly connected and not directly connected IPX respectively.
  • another communication method may include:
  • a secure connection is established between the first IPX and the first SEPP.
  • a secure connection is established between the second IPX and the second SEPP.
  • the first SEPP sends a first HTTP message for querying the public key of the first IPX to the first IPX.
  • the first IPX sends a response message of the first HTTP message to the first SEPP, where the response message of the first HTTP message includes the first public key.
  • the first public key is the public key of the first IPX.
  • the first SEPP sends a first subscription message for subscribing to the first IPX public key to the first IPX.
  • the second SEPP sends a second HTTP message for querying the public key of the second IPX to the second IPX.
  • the second IPX sends a response message of the second HTTP message to the second SEPP, and the response message of the second HTTP message includes the second public key.
  • the second public key is the public key of the second IPX.
  • the second SEPP sends a second subscription message for subscribing to the second IPX public key to the second IPX.
  • steps 903-905 may be earlier, later than, or synchronized with steps 906-908.
  • step 901 to step 908 are the same as step 801 to step 808, and the related technical details can refer to the detailed description of step 801 to step 808.
  • the second SEPP conducts mutual authentication with the first SEPP.
  • the second SEPP sends the first N32f message to the second IPX.
  • the second IPX receives the first N32f message from the second SEPP, and the second IPX uses the private key corresponding to the second public key to sign the content of the first N32f message to obtain the second signature content.
  • the second IPX forwards the signed first N32f message to the first IPX, where the first N32f message includes the second signature content.
  • the first IPX receives the first N32f message containing the second signature content from the second IPX, and the first IPX uses the private key corresponding to the first public key (the private key of the first IPX) to The content of the first N32f message is signed to obtain the first signature content.
  • the first IPX forwards the first N32f message to the first SEPP, where the first N32f message includes the first signature content and the second signature content.
  • the first SEPP receives the first N32f message from the first IPX, and the first N32f message contains the first signature content and the second signature content, and the first signature The content is signed using the private key corresponding to the first public key, and the second signature content is signed using the private key corresponding to the second public key, and the first SEPP uses the first public key and the second public key.
  • the two public keys respectively perform signature verification on the first N32f message (specifically, the first SEPP uses the first public key to perform signature verification on the first signature content in the first N32f message, and the second An SEPP uses the second public key to perform signature verification on the second signature content in the first N32f message).
  • step 909 to step 915 are the same as step 503 to step 508, and the related technical details can refer to the detailed description of step 503 to step 508.
  • the first SEPP may forward the service request or response carried by the first N32f message to the related NF.
  • SEPP can directly obtain the IPX public key from the directly connected IPX through the active request process, and pass the SEPP mutual authentication process Obtain other IPX public keys, and then when SEPP receives the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the first signature content and the second signature content, thereby achieving Integrity verification, this signature verification mechanism helps to improve the communication security between SEPP and IPX.
  • the first IPX device and the second IPX device respectively signed the N32f message, and the first SEPP performed two integrity checks on the received N32f message (two signature verifications). Test), which further improves the security of the communication process.
  • FIG. 10 is a schematic flowchart of another communication method provided by an embodiment of this application.
  • the first SEPP will verify the relevant signatures made by the IPX that is not directly connected to it.
  • another communication method may include:
  • a secure connection is established between the first IPX and the first SEPP.
  • a secure connection is established between the second IPX and the second SEPP.
  • the first SEPP sends a first HTTP message for querying the public key of the first IPX to the first IPX.
  • the first IPX sends a response message of the first HTTP message to the first SEPP, where the response message of the first HTTP message includes the first public key.
  • the first public key is the public key of the first IPX.
  • the first SEPP sends a first subscription message for subscribing to the first IPX public key to the first IPX.
  • the second SEPP sends a second HTTP message for querying the public key of the second IPX to the second IPX.
  • the second IPX sends a response message of the second HTTP message to the second SEPP, and the response message of the second HTTP message includes the second public key.
  • the second public key is the public key of the second IPX.
  • the second SEPP sends a second subscription message for subscribing to the second IPX public key to the second IPX.
  • steps 1003-1005 may be earlier, later than, or synchronized with steps 1006-1008.
  • step 1001 to step 1008 are the same as step 801 to step 808, and the related technical details can refer to the detailed description of step 801 to step 808.
  • the second SEPP conducts mutual authentication with the first SEPP.
  • the second SEPP sends the first N32f message to the second IPX.
  • the second IPX receives the first N32f message from the second SEPP, and the second IPX uses the private key corresponding to the second public key to sign the content of the first N32f message to obtain the second signature content.
  • the second IPX forwards the signed first N32f message to the first IPX, where the first N32f message includes the second signature content.
  • the first IPX receives the first N32f message containing the second signature content from the second IPX, and the first IPX forwards the first N32f message containing the second signature content to the first SEPP.
  • the first SEPP receives the first N32f message from the first IPX, and the first N32f message includes the second signature content, and the second signature content corresponds to the second public key
  • the first SEPP uses the second public key to perform signature verification on the first N32f message (specifically, the first SEPP uses the second public key to perform signature verification on the first N32f message
  • the second signature content is subjected to signature verification).
  • step 1009 to step 1014 are the same as step 403 to step 408, and the related technical details can refer to the detailed description of step 403 to step 408.
  • the first SEPP may forward the service request or response carried by the first N32f message to the related NF.
  • SEPP can directly obtain the IPX public key from the directly connected IPX through the active request process, and pass the SEPP mutual authentication process Obtain other IPX public keys, and then when SEPP receives the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the second signature content, thereby achieving integrity verification.
  • This signature verification mechanism helps to improve the communication security between SEPP and IPX.
  • an embodiment of the present application provides a first SEPP device 1100, including:
  • the communication unit 1110 is configured to receive a first message containing a first public key from a first IPX device, where the first public key is the public key of the first IPX device. Receive a first N32f message from the first IPX, the first N32f message containing the first signature content, the first signature content is signed using the private key of the first IPX (the first signature content, for example, It is obtained by signing by the first IPX device using the private key of the first IPX).
  • the signature verification unit 1120 is configured to use a first public key to perform signature verification on the first N32f message (specifically, the first public key may be used to perform signature verification on the first signature content in the first N32f message. Signature verification).
  • the first message may be a message used between the first SEPP device and the first IPX device to establish a TLS connection or establish an IPsec connection. Or the first message may also be a message used between the first SEPP device and the first IPX device to establish another underlying security connection. Or the first message may also be a message exchanged after the first SEPP device and the first IPX device establish a secure connection.
  • the communication unit 1110 is further configured to, before receiving the first message containing the first public key from the first IPX device, send to the first IPX device a request for querying the first IPX device The HTTP message of the public key, and the first message is a response message of the HTTP message.
  • the first SEPP device further includes a connection unit 1130, configured to communicate with the first IPX device before the communication unit is further configured to send an HTTP message for querying the public key of the first IPX device to the first IPX device.
  • a connection unit 1130 configured to communicate with the first IPX device before the communication unit is further configured to send an HTTP message for querying the public key of the first IPX device to the first IPX device.
  • the communication unit 1110 may also be configured to, before receiving the first message containing the first public key from the first IPX device, send to the first IPX device a message for subscribing to the public key of the first IPX device.
  • a subscription message where the first message is a response message of the subscription message.
  • the communication unit 1110 may also be configured to, after receiving the first message containing the first public key from the first IPX device, send to the first IPX device a message for subscribing to the public key of the first IPX device. Subscribe to news.
  • the first IPX device when the first IPX device receives a subscription message for subscribing to the public key of the first IPX device, then the first IPX device can update the public key of the first IPX device by sending a response message of the subscription message to the first IPX device.
  • a SEPP device distributes the updated public key of the first IPX device.
  • the communication unit 1110 may also be configured to receive a second message containing a second public key from a second SEPP device (the second message may be a communication between the first SEPP device and the second SEPP device).
  • the second public key is the public key of the second IPX device; wherein, the first N32f message also includes second signature content, and the second signature content uses all The private key of the second IPX device is used for signing.
  • the signature verification unit 1120 is further configured to use a second public key to perform signature verification on the first N32f message (specifically, the second public key may be used to sign the second signature content in the first N32f message check). That is, when the first N32f message contains multiple signature content, the signature verification unit can use the corresponding public key to perform signature verification on the multiple signature content in the first N32f message.
  • the signature verification order of each signature content is different. limited.
  • the communication unit 1110 may also be configured to receive a second message containing a second public key from a second SEPP device, where the second public key is the public key of the second IPX device;
  • the second N32f message from the first IPX device is received, and the second N32f message contains the second signature content, and the second signature content uses the private key corresponding to the second public key (the second IPX The private key of the device) for signing (the second N32f message, for example, does not include the signature content signed with the private key of the first IPX device).
  • the signature verification unit 1120 is further configured to use the second public key to perform signature verification on the second signature content.
  • an embodiment of the present application provides a first IPX device 1200, including:
  • the communication unit 1210 is configured to send a first message containing a first public key to a first SEPP device, where the first public key is the public key of the first IPX device; receiving from the second IPX device or the second SEPP The first N32f message of the device;
  • the signing unit 1220 is configured to use the private key of the first IPX device to sign the first N32f message to obtain the first signature content.
  • the communication unit 1210 is further configured to forward the first N32f message to the first SEPP device, where the first N32f message includes the first signature content.
  • the IPX device can send the first message containing the first public key to the directly connected SEPP device, that is, the SEPP can directly obtain the IPX public key from the directly connected IPX, and then the SEPP receives the first N32f message from IPX, SEPP can use the obtained IPX public key to perform signature verification on the first signature content, thereby achieving integrity verification, etc.
  • This signature verification mechanism is beneficial to improve Security of communication between SEPP and IPX.
  • the above-mentioned solution is beneficial to realize the automatic distribution of the IPX public key without manual intervention, thereby helping to reduce the risk of human error in the IPX public key (certificate) distribution process and the risk of being attacked during the transmission process.
  • the IPX public key distribution process is relatively simplified, which helps to save communication costs, shortens the IPX public key distribution time, and helps improve the risk handling capabilities in specific scenarios (such as IPX private key leakage, etc.).
  • the first message may be a message used between the first SEPP device and the first IPX device to establish a TLS connection or establish an IPsec connection. Or the first message may also be a message used between the first SEPP device and the first IPX device to establish another underlying security connection. Or the first message may also be a message exchanged after the first SEPP device and the first IPX device establish a secure connection.
  • the first message is a message used to establish a TLS connection or an IPsec connection between the first SEPP device and the first IPX device
  • the first IPX device uses the first SEPP device to communicate with the first SEPP device.
  • the process of establishing a TLS connection or establishing an IPsec connection between the first IPX devices is used to distribute the public key of the first IPX device, which eliminates the need for an additional public key distribution process, which is beneficial to simplify the implementation complexity.
  • the communication unit 1210 is further configured to, before sending the first message containing the first public key to the first SEPP device, receive a query from the first SEPP device for querying the first SEPP device.
  • a Hypertext Transfer Protocol HTTP message of the public key of the IPX device, and the first message is a response message of the HTTP message.
  • the first IPX device further includes a connecting unit 1230, configured to communicate with the first SEPP device before the communication unit receives a Hypertext Transfer Protocol HTTP message for querying the public key of the first IPX device
  • a connecting unit 1230 configured to communicate with the first SEPP device before the communication unit receives a Hypertext Transfer Protocol HTTP message for querying the public key of the first IPX device
  • a transport layer security TLS connection or an Internet security protocol IPsec connection is established between the first SEPP devices.
  • the communication unit 1210 is further configured to, before sending the first message containing the first public key to the first SEPP device, receive from the first SEPP device for subscribing to the first IPX device
  • the subscription message of the public key of, and the first message is a response message of the subscription message.
  • the first N32f message further includes second signature content, and the second signature content is signed using the private key of the second IPX device.
  • the communication unit 1210 is further configured to receive a second N32f message from the second IPX device, the second N32f message includes a second signature content, and the second signature content uses Sign the private key of the second IPX device; forward the second N32f message to the first SEPP device.
  • the first SEPP device can use the corresponding public key to perform signature verification on the multiple signature content in the first N32f message.
  • signature verification of each signature content The order is not limited.
  • an embodiment of the present application provides a communication device 1300, including:
  • the signal processor 1320 is configured to execute part or all of the steps of any method that can be executed by SEPP or IPX in the embodiment of the present application.
  • an embodiment of the present application provides a communication device 1400 that includes: an input interface circuit 1410, a logic circuit 1420, and an output interface circuit 1430.
  • the logic circuit 1420 is used to execute part or all of the steps of any method that can be executed by SEPP or IPX in the embodiment of the present application.
  • an embodiment of the present application provides a communication device 1500, which may include:
  • the processor 1510 and the memory 1520 are coupled to each other.
  • the processor 1510 is configured to call a computer program stored in the memory 1520 to execute part or all of the steps of any method that can be executed by SEPP or IPX in the embodiment of the present application.
  • the embodiments of the present application also provide a computer-readable storage medium, the computer-readable storage medium stores a computer program, and the computer program can be completed when executed by hardware (such as a processor).
  • the computer program can be completed when executed by hardware (such as a processor).
  • SEPP or IPX Part or all of the steps of any method performed.
  • the embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and the computer program is executed by hardware (for example, a processor, etc.) to implement any device in the embodiment of the present application. Part or all of the steps of any method performed.
  • the embodiments of the present application also provide a computer program product including instructions.
  • the computer program product runs on a computer device, the computer device is caused to execute part or all of any method that can be executed by SEPP or IPX. step.
  • the computer may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software it can be implemented in the form of a computer program product in whole or in part.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • the computer instructions may be transmitted from a website, computer, server, or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media.
  • the usable medium may be a magnetic medium (such as a floppy disk, a hard disk, and a magnetic tape), an optical medium (such as an optical disk), or a semiconductor medium (such as a solid-state hard disk).
  • the disclosed device may also be implemented in other ways.
  • the device embodiments described above are only illustrative, for example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or integrated. To another system, or some features can be ignored or not implemented.
  • the displayed or discussed indirect coupling or direct coupling or communication connection between each other may be through some interfaces, indirect coupling or communication connection between devices or units, and may be in electrical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed 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 may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • the functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit may be implemented in the form of hardware, or may also be implemented in the form of software functional unit.
  • the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the technical solution of the application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium.
  • a number of instructions are included to enable a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage medium may include, for example: U disk, mobile hard disk, Read-Only Memory (ROM), Random Access Memory (RAM, Random Access Memory), magnetic disks or optical disks and other storable program codes. Medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Des modes de réalisation de la présente invention concernent un procédé de communication, un appareil associé et un moyen de stockage. Le procédé de communication comprend : un premier dispositif proxy de sécurité et de protection des bords (SEPP) recevant un premier message contenant une première clé publique d'un premier dispositif de service d'échange IP (IPX), la première clé publique étant une clé publique du premier dispositif IPX ; le premier dispositif SEPP recevant un premier message N32f du premier IPX, le premier message N32f contenant un premier contenu de signature, et le premier contenu de signature étant signé en utilisant une clé privée du premier IPX ; et le premier dispositif SEPP utilisant la première clé publique pour effectuer une vérification de signature sur le premier message N32f. La solution des modes de réalisation de la présente invention aide à améliorer la sécurité de communication entre un SEPP et un IPX.
PCT/CN2021/070915 2020-02-21 2021-01-08 Procédé de communication, appareil associé, et support de stockage lisible par ordinateur WO2021164458A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010109122.X 2020-02-21
CN202010109122.XA CN113382410B (zh) 2020-02-21 2020-02-21 通信方法和相关装置及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2021164458A1 true WO2021164458A1 (fr) 2021-08-26

Family

ID=77390399

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/070915 WO2021164458A1 (fr) 2020-02-21 2021-01-08 Procédé de communication, appareil associé, et support de stockage lisible par ordinateur

Country Status (2)

Country Link
CN (1) CN113382410B (fr)
WO (1) WO2021164458A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115022032A (zh) * 2022-05-31 2022-09-06 中国电信股份有限公司 通信方法、安全边缘保护代理和通信系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109699031A (zh) * 2018-01-11 2019-04-30 华为技术有限公司 采用共享密钥、公钥和私钥的验证方法及装置
CN110167013A (zh) * 2018-02-13 2019-08-23 华为技术有限公司 一种通信方法及装置
US20200036754A1 (en) * 2018-07-30 2020-01-30 Cisco Technology, Inc. Sepp registration, discovery and inter-plmn connectivity policies
WO2020030852A1 (fr) * 2018-08-10 2020-02-13 Nokia Technologies Oy Authentification de fonction de réseau basée sur une liaison de clé publique dans un jeton d'accès dans un système de communication

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10447467B2 (en) * 2016-05-04 2019-10-15 International Business Machines Corporation Revocable PKI signatures
CN108880813B (zh) * 2017-05-08 2021-07-16 中国移动通信有限公司研究院 一种附着流程的实现方法及装置
CN110035433B (zh) * 2018-01-11 2024-03-19 华为技术有限公司 采用共享密钥、公钥和私钥的验证方法及装置
WO2020012065A1 (fr) * 2018-07-12 2020-01-16 Nokia Technologies Oy Gestion de sécurité pour demandes non autorisées dans un système de communication avec une architecture à base de service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109699031A (zh) * 2018-01-11 2019-04-30 华为技术有限公司 采用共享密钥、公钥和私钥的验证方法及装置
CN110167013A (zh) * 2018-02-13 2019-08-23 华为技术有限公司 一种通信方法及装置
US20200036754A1 (en) * 2018-07-30 2020-01-30 Cisco Technology, Inc. Sepp registration, discovery and inter-plmn connectivity policies
WO2020030852A1 (fr) * 2018-08-10 2020-02-13 Nokia Technologies Oy Authentification de fonction de réseau basée sur une liaison de clé publique dans un jeton d'accès dans un système de communication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HUAWEI, HISILICON: "Mirror for clarification on IPX certificate acquirement in SEPP", 3GPP DRAFT; S3-200225, vol. SA WG3, 21 February 2020 (2020-02-21), pages 1 - 3, XP051854961 *
HUAWEI, HISILICON: "Mirror for clarification on IPX certificate acquirement in SEPP", 3GPP DRAFT; S3-201090, vol. SA WG3, 1 May 2020 (2020-05-01), pages 1 - 3, XP051879730 *
NOKIA, NOKIA SHANGHAI BELL: "Clarifications and corrections in clause 13.2.a", 3GPP DRAFT; S3-183127-V1_REVISION_OF_3001 V1, vol. SA WG3, 3 October 2018 (2018-10-03), Harbin (China), pages 1 - 10, XP051541171 *

Also Published As

Publication number Publication date
CN113382410A (zh) 2021-09-10
CN113382410B (zh) 2022-12-06

Similar Documents

Publication Publication Date Title
US20210234706A1 (en) Network function authentication based on public key binding in access token in a communication system
WO2020221219A1 (fr) Procédé de communication et dispositif de communication
KR100799222B1 (ko) 장치 그룹화 및 그룹화 된 장치들 사이 상호작용을구현하는 방법
WO2020221956A1 (fr) Autorisation de service pour une communication indirecte dans un système de communication
WO2019215390A1 (fr) Gestion de sécurité de mandataires de bord sur une interface inter-réseaux dans un système de communication
JP2020527914A (ja) ネットワークセキュリティ管理方法および装置
US20090013381A1 (en) User Authentication and Authorisation in a Communications System
CN113727341B (zh) 安全通信方法、相关装置及系统
US20210219137A1 (en) Security management between edge proxy and internetwork exchange node in a communication system
US20230156468A1 (en) Secure Communication Method, Related Apparatus, and System
WO2021094349A1 (fr) Autorisation de services en plusieurs étapes pour la communication indirecte dans un système de communication
WO2021063304A1 (fr) Procédé d'authentification de communication et dispositif associé
US20230396602A1 (en) Service authorization method and system, and communication apparatus
JP2024518417A (ja) 単一使用認証メッセージのための方法、システム、およびコンピュータ可読媒体
WO2021164458A1 (fr) Procédé de communication, appareil associé, et support de stockage lisible par ordinateur
WO2020012065A1 (fr) Gestion de sécurité pour demandes non autorisées dans un système de communication avec une architecture à base de service
WO2022067736A1 (fr) Procédé et appareil de communication
WO2024032226A1 (fr) Procédé de communication et appareil de communication
KR20200044592A (ko) 다중 경로 전송 시스템, 그리고 이의 다중 경로 전송 방법
WO2022012355A1 (fr) Procédé de communication sécurisée, appareil associé, et système
KR102553166B1 (ko) 비프록시 기반 다중 경로 전송 시스템, 그리고 이의 세션 연결을 위한 인증 방법
WO2024094047A1 (fr) Procédé de communication et appareil de communication

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21757138

Country of ref document: EP

Kind code of ref document: A1