WO2019041809A1 - 基于服务化架构的注册方法及装置 - Google Patents

基于服务化架构的注册方法及装置 Download PDF

Info

Publication number
WO2019041809A1
WO2019041809A1 PCT/CN2018/081447 CN2018081447W WO2019041809A1 WO 2019041809 A1 WO2019041809 A1 WO 2019041809A1 CN 2018081447 W CN2018081447 W CN 2018081447W WO 2019041809 A1 WO2019041809 A1 WO 2019041809A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
key
function
function network
management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/081447
Other languages
English (en)
French (fr)
Inventor
张博
甘露
吴�荣
谭帅帅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP18849939.6A priority Critical patent/EP3668042B1/en
Publication of WO2019041809A1 publication Critical patent/WO2019041809A1/zh
Priority to US16/803,624 priority patent/US11496320B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption

Definitions

  • the present application relates to the field of communications technologies, and in particular, to a registration method and apparatus based on a service architecture.
  • NF network function
  • the control network element such as the NF repository function (NRF) usually provides functions such as registration, discovery, and authorization for the NF, and implements the on-demand configuration of the NF and the service and the interconnection between the NFs.
  • the management network element first configures corresponding parameters to the function network element to be registered, and then the function network element to be registered directly sends a registration request to the NRF, and the NRF directly completes the registration after receiving the registration request.
  • the NRF adds the registered function network element to the NF topology and sends a response message to the registered function network element.
  • the communication interface between the function network element to be registered and the NRF is not protected by the security channel.
  • the attacker may modify the parameters, or the attacker plays the role of the function network element to be registered to try to access the NRF.
  • the NRF does not perform security authentication on the registration request sent by the registered function network element, and the security is low.
  • the embodiment of the present invention provides a registration method and device based on a service architecture, so as to implement security authentication for a control network element to register a function of a function network element, thereby improving security.
  • a registration method based on a service architecture in which a function network element sends a registration request to a control network element, and the registration request includes a security parameter.
  • the control network element receives the registration request sent by the function network element, verifies the correctness of the security parameters included in the registration request, and determines whether the registration request sent by the NF is legal through the correctness of the verified security parameter, so as to implement registration of the function network element. Requested security certification to improve security.
  • the security parameter may be determined by the management network element, and the management network element includes the determined security parameter in the configuration information and sent to the function network element. After receiving the configuration information sent by the management network element, the function network element includes the security included in the configuration information. The parameter is carried in the registration request and sent to the management network element.
  • the management network element can determine the validity of the registration request sent by the function network element by verifying the correctness of the security parameter included in the registration request.
  • the management network element adds the function network element to the function network element topology when the registration request sent by the function network element is valid, and refuses to add the function network element if it is determined that the registration request sent by the function network element is invalid.
  • the communication method provided by the embodiment of the present application can improve communication security to a certain extent.
  • the security parameters determined by the management network element include asymmetric tokens.
  • the management network element may perform a digital signature algorithm on the function network element data and the identifier of the function network element to generate a digital signature based on the private key of the management network element, and based on the public key of the control network element, the digital signature and the function network element data.
  • the identifier of the function network element is encrypted to generate an asymmetric token.
  • the management network element may further generate a digital signature by performing a digital signature algorithm on the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element, based on the private key of the management network element, and
  • the asymmetric token is generated by encrypting the digital signature, the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element based on the public key of the control network element.
  • the shared key may be a session key generated by the management network element.
  • the session key is used for secure communication or authentication between the function network element and the control network element.
  • the session key may be generated by the management network element according to the preset root key and the identifier of the function network element.
  • the session key may also be generated by the management network element by encrypting the identifier of the function network element according to the derivation key.
  • the derivation key is obtained by performing a key derivation on the preset root key by the management network element, or the derivation key is a key of the function network element saved by the management network element.
  • the parameter for encrypting based on the public key of the control network element may include a control network in addition to the digital signature, the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element.
  • a token identifier At least one of a token identifier, a function network element type, a PLMN identifier, a service identifier supported by the function network element, a digital signature random number, and the like, and a token validity period, a token random number, a counter, and a sequence number. item.
  • the management network element performs the digital signature algorithm based on the private key of the management network element.
  • the management network element may further include a control network element.
  • the management network element sends the asymmetric token generated as a security parameter to the function network element, and the function network element sends an asymmetric token to the control network element, and the control network element receives the asymmetric token, and controls the private element of the network element.
  • the key decrypts the asymmetric token to obtain a digital signature, and verifies the correctness of the digital signature by using the public key of the management network element and the signed content.
  • the signed content is the same as the parameter of the execution signature algorithm, and may include, for example, the function network element data and the function network element identifier.
  • the function network element and the control network element may be included in addition to the function network element data and the function network element identifier.
  • the security parameters determined by the management network element include symmetric tokens.
  • the management network element may generate a message authentication code based on the symmetric key shared between the management network element and the control network element, the identifier of the function network element, and the algorithm for executing the message authentication code of the function network element data, and based on the management network element and
  • the symmetric key shared between the control network elements is encrypted, and the message authentication code, the function network element data, and the identifier of the function network element are encrypted to generate a symmetric token.
  • the management network element may also perform a message authentication code on the shared key between the function network element and the control network element, the identifier of the function network element, and the function network element data based on the symmetric key shared between the management network element and the control network element.
  • the algorithm generates a message authentication code and is based on a symmetric key shared between the management network element and the control network element, between the message authentication code, the function network element data, the function network element identifier, and between the function network element and the control network element.
  • the shared key encryption generates a symmetric key.
  • the shared key between the function network element and the control network element may be a session key generated by the management network element.
  • the session key is used for secure communication or authentication between the function network element and the control network element.
  • the session key may be generated by the management network element according to the preset root key and the identifier of the function network element.
  • the session key may also be generated by the management network element by encrypting the identifier of the function network element according to the derivation key.
  • the derivation key is obtained by performing a key derivation on the preset root key by the management network element, or the derivation key is a key of the function network element saved by the management network element.
  • the parameter that the management network element encrypts based on the symmetric key shared between the management network element and the control network element is in addition to the message authentication code, the function network element data, the identifier of the function network element, and the function network element and the control network element.
  • the control network element identifier, the function network element type, the PLMN identifier, the service identifier supported by the function network element, the random number of the message authentication code, and the like, and the validity period of the token may also be included. At least one of a token random number, a counter, and a serial number.
  • the management network element performs the message authentication code algorithm based on the symmetric key shared between the management network element and the control network element, except for the function network element data, the identifier of the function network element, and the shared secret between the function network element and the control network element.
  • the control network element identifier, the function network element type, the PLMN identifier, and the service identifier supported by the function network element, and the message authentication code validity period, the message authentication code random number, the counter, and the sequence may also be included. At least one of the numbers.
  • the management network element sends the symmetric token generated as the security parameter to the function network element, and the function network element sends a symmetric token to the control network element, and the control network element receives the symmetric token, and decrypts the symmetric token by using the symmetric key.
  • the content protected by the message verification code is the same as the parameter of the message verification code algorithm, and may include, for example, the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element;
  • the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element may further include a control network element identifier, a function network element type, a PLMN identifier, a service identifier supported by the function network element, and the like.
  • the security parameters determined by the management network element include a first message authentication code.
  • the management network element may generate a first message authentication code by performing a message authentication code algorithm on the function network element data and the identifier of the function network element based on a symmetric key shared between the management network element and the control network element.
  • the management network element generates a first message authentication code based on the symmetric authentication key shared by the management network element and the control network element.
  • the parameter of the first message authentication code may be included in addition to the function network element data and the function network element identifier. Control one or more of the network element identifier, the function network element type, the PLMN identifier, the service identifier supported by the function network element, and the validity period of the first message authentication code, the first message authentication code random number, the counter and the serial number At least one of them.
  • the management network element sends the first message authentication code generated as the security parameter to the function network element, and the function network element sends the first message authentication code to the control network element, and the control network element receives the first message authentication code, and uses the management network.
  • the symmetric key shared between the element and the control network element and the content protected by the first message verification code verify the correctness of the first message authentication code.
  • the content protected by the first message verification code is the same as the parameter used by the message verification code algorithm to generate the first message verification code, and may include, for example, the function network element data and the identifier of the function network element;
  • the identifier of the function network element may further include one or more of a control network element identifier, a function network element type, a PLMN identifier, and a service identifier supported by the function network element, and a validity period of the first message authentication code, and the first message authentication. At least one of a code random number, a counter, and a serial number.
  • the security parameters determined by the management network element include a first digital signature.
  • the management network element may perform a digital signature algorithm on the function network element data and the identifier of the function network element to generate a first digital signature based on the private key of the management network element.
  • the parameter that the management network element performs the digital signature algorithm based on the private key of the management network element may include the control network element identifier, the function network element type, the PLMN identifier, and the function network, in addition to the function network element data and the identifier of the function network element.
  • the management network element sends the first digital signature generated as the security parameter to the function network element, and the function network element sends the first digital signature to the control network element, and the control network element receives the first digital signature, and uses the private network of the control network element.
  • the key decrypts the first digital signature to obtain a digital signature, and verifies the correctness of the first digital signature by using the public key of the management network element and the content signed by the first digital signature.
  • the content signed by the first digital signature is the same as the parameter for generating the first digital signature by the execution of the signature algorithm, and may include, for example, the function network element data and the function network element identifier, and includes the function network element data and the function network element identifier. Controlling one or more of the network element identification function network element type, the PLMN identifier, the service identifier supported by the function network element, and the first digital signature validity period, the first digital signature random number, the counter and the serial number at least One.
  • control network element can verify the function network element by verifying the asymmetric token, the symmetric token, the first message authentication code, or the first digital signature generated by the management network element.
  • the management network element generates a first message authentication code and a third message authentication code, and sends the same to the function network element.
  • the function network element sends the first message authentication code to the control network element, and the control network element verifies the validity of the first message authentication code to implement authentication of the function network element.
  • the control network element generates a second message authentication code and sends it to the function network element.
  • the function network element verifies whether the third message authentication code is consistent with the second message authentication code, so as to verify the validity of the second message authentication code, and implement the authentication of the control network element by using the legality of the second message authentication code.
  • the mutual authentication of the function network element and the control network element can be implemented by using the embodiment of the present application.
  • the second message authentication code is generated by the control network element based on a symmetric key shared between the management network element and the control network element, and an algorithm for performing the message authentication code on the identifier of the function network element and the identifier of the control network element. Further, the control network element generates a second message authentication code based on the symmetric authentication key shared by the management network element and the control network element, and the parameter of the second network message authentication code is not only the identifier of the function network element but also the identifier of the control network element.
  • the function network element data, the function network element type, the PLMN identifier, the service identifier supported by the function network element, and the like, and the second message authentication code validity period, the second message authentication code random number, the counter and the serial number At least one of them.
  • the third message authentication code is generated by the management network element based on the symmetric key shared between the management network element and the control network element, and the algorithm for performing the message authentication code on the identifier of the function network element and the identifier of the control network element. Further, the management network element generates a third message authentication code based on the symmetric authentication key shared by the management network element and the control network element, and the parameter of the third-party authentication code is not only the identifier of the function network element but also the identifier of the control network element.
  • the function network element data, the function network element type, the PLMN identifier, the service identifier supported by the function network element, and the like, and the third message authentication code validity period, the third message authentication code random number, the counter and the serial number At least one of them.
  • the management network element generates a first digital signature and sends it to the functional network element.
  • the function network element sends the first digital signature to the control network element, and the control network element verifies the legality of the first digital signature to implement authentication of the function network element.
  • the control network element generates a second digital signature and sends it to the functional network element.
  • the function network element verifies whether the first digital signature is consistent with the second digital signature, so as to verify the validity of the second digital signature, and implement authentication of the control network element by using the legality of the second digital signature.
  • the mutual authentication of the function network element and the control network element can be implemented by using the embodiment of the present application.
  • the second digital signature is generated by the control network element based on the private key of the control network element, and performs a digital signature algorithm on the identifier of the function network element and the identifier of the control network element. Further, the control network element performs a digital signature algorithm based on the private key of the control network element to generate a second digital signature.
  • the control network element may further include the function network element data and the function network element type. And one or more of a PLMN identifier, a service identifier supported by the function network element, and at least one of a second digital signature validity period, a second digital signature random number, a counter, and a serial number.
  • the security parameter sent by the function network element to the control network element may include a fourth message authentication code generated by the function network element.
  • the function network element may generate a fourth message authentication code by performing a message authentication code algorithm on the identifier of the function network element according to the derivation key.
  • the derivation key used by the function network element to generate the fourth message authentication code is obtained by the management network element performing key derivation on the preset root key, or the function network element saved by the management network element. Key.
  • the function network element sends a fourth message authentication code and an identifier of the function network element to the control network element, and after the control network element receives the fourth message authentication code and the identifier of the function network element, the network element is sent to the management network element.
  • the function network element determines that the fourth message authentication code is correct, confirms that the registration request sent by the function network element is legal, and confirms that the function network element authentication passes, The function network element authenticates the control network element.
  • the function network element sends a fourth message authentication code to the control network element, and after receiving the fourth message authentication code, the function network element sends a fourth message authentication code to the management network element.
  • the management network element receives the fourth message authentication code sent by the control network element, generates a fifth message authentication code based on the pre-stored derivation key, and compares whether the fourth message authentication code and the fifth message authentication code are consistent, so as to implement If the fourth message authentication code is consistent with the fifth message authentication code, the function network element determines that the fourth message authentication code is correct, confirms that the registration request sent by the function network element is legal, and confirms that the function network element authentication is passed. .
  • the management network element sends the verification result of the fourth message authentication code to the control network element, and the control network element receives the verification result of the fourth message authentication code sent by the management network element, and determines the verification result of the fourth message authentication code sent by the management network element.
  • the correctness of the fourth message authentication code is used to implement authentication of the function network element.
  • the fifth message authentication code is generated by the management network element according to the derivation key, the identifier of the function network element, and the algorithm for controlling the identifier of the network element to execute the message authentication code.
  • the fourth message authentication code is the same as the parameter of the message authentication code algorithm in the process of generating the fifth message authentication code, and includes the function network element data, and the function network element, in addition to the identifier of the function network element and the identifier of the control network element.
  • a secure channel may be established between the control network element and the functional network element based on the session key or the session key based derivation key.
  • the control network element may obtain a session key by decrypting an asymmetric token or a symmetric token, the asymmetric token or the symmetric token being generated based on the session key; or the session key may also be managed
  • the network element is configured to encrypt the identifier of the network element according to the preset root key, or the control network element obtains the session key from the management network element, and the session key is pushed by the management network element.
  • the derivation key is generated by encrypting the identifier of the function network element; the derivation key is obtained by performing a key derivation on the preset root key by the management network element, or the derivation key is the management network The key of the function network element saved by the meta.
  • a registration device based on a service architecture is provided, and the registration device is applicable to a management network element, and the registration device applied to the management network element has the foregoing first aspect and the management network element in any design of the first aspect.
  • Function can be implemented by hardware, or can be implemented by hardware corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the modules can be software and/or hardware.
  • the registration device applied to the management network element includes a processing unit and a sending unit, and may further include a receiving unit, wherein the receiving unit, the processing unit, and the sending unit may be associated with each functional step performed by the management network element. Correspondence will not be repeated here.
  • the registration device applied to the management network element includes a processor, a transceiver, and a memory.
  • the memory is coupled to the processor for storing various software programs and/or sets of instructions.
  • the processor calls the memory's stored program or instruction to perform the functional steps performed by the management network element described above, and controls the transceiver to send and receive signals.
  • a registration device based on a service architecture where the registration device is applicable to a function network element, and the registration device applied to the function network element has a function network element that implements the foregoing first aspect and any design in the first aspect.
  • Function the function can be implemented by hardware, or can be implemented by hardware corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the modules can be software and/or hardware.
  • the registration device applied to the function network element includes a receiving unit and a sending unit, and may further include a processing unit, wherein the receiving unit, the processing unit, and the sending unit may be associated with each functional step performed by the function network element. Correspondence will not be repeated here.
  • the registration device applied to the functional network element includes a processor, a transceiver, and a memory.
  • the memory is coupled to the processor for storing various software programs and/or sets of instructions.
  • the processor calls the stored program or instruction of the memory to perform the functional steps performed by the function network element described above, and controls the transceiver to send and receive signals.
  • a fourth aspect provides a registration device based on a service architecture, where the registration device is applicable to a control network element, and the registration device applied to the control network element has the foregoing first aspect and the control network element in any design of the first aspect.
  • Function can be implemented by hardware, or can be implemented by hardware corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the modules can be software and/or hardware.
  • the registration device applied to the control network element includes a receiving unit and a processing unit, and may further include a sending unit, wherein the receiving unit, the processing unit, and the sending unit may be associated with each functional step performed by the control network element. Correspondence will not be repeated here.
  • the registration device applied to the control network element includes a processor, a transceiver, and a memory.
  • the memory is coupled to the processor for storing various software programs and/or sets of instructions.
  • the stored program or instruction of the processor calling memory performs the above-mentioned functional steps performed by the control network element and controls the transceiver to send and receive signals.
  • a computer storage medium stores computer instructions, and when the instructions are run on a computer, the management network element and the function network element in the first aspect and any possible design of the first aspect may be completed. Or control any function involved in the network element.
  • a computer program product comprising a computer program for executing a management network element, a function network element or a control in the first aspect and any possible design of the first aspect Any of the functions involved in the network element.
  • the management network element can determine the registration sent by the function network element by verifying the correctness of the security parameters included in the registration request. The legality of the request.
  • the management network element adds the function network element to the function network element topology when the registration request sent by the function network element is valid, and refuses to add the function network element if it is determined that the registration request sent by the function network element is invalid. To the function network element topology. Therefore, the communication method provided by the embodiment of the present application can improve communication security to a certain extent.
  • FIG. 1 is a schematic diagram of a service architecture applied to a registration method according to an embodiment of the present disclosure
  • FIG. 2 is a flowchart of implementing a registration method based on a service architecture according to an embodiment of the present application
  • FIG. 3 is a flowchart of a security registration implementation based on a service architecture according to Embodiment 1 of the present application;
  • FIG. 4 is a flowchart of a security registration implementation based on a service architecture provided by Embodiment 2 of the present application;
  • FIG. 5 is a flowchart of a security registration implementation based on a service architecture provided by Embodiment 3 of the present application;
  • FIG. 6 is a flowchart of a security registration implementation based on a service architecture provided by Embodiment 4 of the present application;
  • FIG. 7 is a flowchart of a security registration implementation based on a service architecture provided by Embodiment 5 of the present application.
  • FIG. 8 is a flowchart of a security registration implementation based on a service architecture provided by Embodiment 6 of the present application.
  • FIG. 9 is a flowchart of a security registration implementation based on a service architecture provided in Embodiment 7 of the present application.
  • FIG. 10 is a flowchart of a security registration implementation based on a service architecture provided in Embodiment 8 of the present application.
  • FIG. 11 is a flowchart of a security registration implementation based on a service architecture provided by Embodiment 9 of the present application.
  • FIG. 12 is a schematic structural diagram of a device for registering a management network element according to an embodiment of the present disclosure
  • FIG. 13 is a schematic structural diagram of another apparatus for registering a management network element according to an embodiment of the present disclosure.
  • FIG. 14 is a schematic structural diagram of a device for registering a function network element according to an embodiment of the present disclosure
  • FIG. 15 is a schematic structural diagram of another apparatus for registering a function network element according to an embodiment of the present disclosure.
  • FIG. 16 is a schematic structural diagram of a device for registering a control network element according to an embodiment of the present disclosure
  • FIG. 17 is a schematic structural diagram of another apparatus for registering a control network element according to an embodiment of the present disclosure.
  • the service architecture of the core network control plane implements decoupling and integration between NFs through modularization, and each NF uses a serviced interface to interact.
  • the NF (authentication server function, AUSF), access and mobility management function (AMF), session management function (SMF) and other NFs can pass the NEF serviced interface (service- Based interface improves by NEF, Nnef), service-based interface exhibit by AUSF (Nausf), service-based interface exhibit by NRF (Nnrf), AMF serviced interface (service-based interface) Exploration by AMF, Namf), service-based interface exhibit by PCF (Npcf), SMF service interface (service-based interface exhibit by SMF, Nsmf), UDM service interface (service-based interface enhanced by UDM, Nud
  • the user equipment can access the AMF of the core network through the Radio Access Network (RAN), or directly access the AMF.
  • the interface between the UE and the AMF is N1.
  • Interface, the interface between the RAN and the AMF is an N2 interface.
  • the RAN can interact with the user plan function (UPF) through the N3 interface.
  • the UPF can access the SMF of the core network through the N4 interface and interact with the core network.
  • the UPF can also access the data network (DN) through the N6 interface and interact with the DN.
  • DN data network
  • the network element names and interface definitions shown in Figure 1 are all referenced from the fifth generation (5G) and the third generation of the 3rd Generation Partnership Project (3GPP) draft.
  • 5G fifth generation
  • 3GPP 3rd Generation Partnership Project
  • the specific definitions can be found in the relevant definitions in the 5G 3GPP draft.
  • a management network element having a network element management and registration function is provided to a control network having a function of storing registration information.
  • the meta sends a registration request, and the configuration information of the newly added function network element is included in the registration request.
  • the control network element After receiving the registration request, the control network element completes the registration, adds the registered function network element to the NF topology, and sends a response message to the management network element.
  • the management network element configures corresponding parameters to the function network element to be registered, and then the function network element to be registered directly sends a registration request to the control network element, and the control network element directly completes the registration after receiving the registration request.
  • the NRF adds the registered function network element to the NF topology and sends a response message to the registered function network element.
  • the management network element needs to send configuration information to the control network element and the newly added function network element.
  • the first embodiment described above may no longer be applicable to future 5G communication services.
  • the second implementation manner may be adopted to implement registration of the newly added function network element.
  • the management network element does not need to send configuration information to the control network element
  • the newly added function network element directly sends a registration request to the control network element, but the newly added function network element and the control network
  • the communication interface between the elements is not protected by the security channel.
  • the attacker may modify the parameters, or the attacker plays the role of the function network element to be registered to try to access the control network element, and the communication security is low.
  • the embodiment of the present application provides a security registration method based on a service architecture, in which a security authentication is performed between a control network element and a function network element to improve communication security.
  • the management network element involved in the embodiment of the present application may be any functional entity having a network element management and control function, such as an operation administration and maintenance (OAM) or a slice management network element (Slice).
  • An entity such as a terminal, a base station, a controller, or a server, is not limited in the embodiment of the present application.
  • the management network element is OAM as an example.
  • the control network element in the embodiment of the present application may be any functional entity that has the function of storing the registration information and controlling the network element, and may be, for example, an NRF, or a terminal, a base station, a controller, or a server.
  • the description is made by taking the control network element as the NRF as an example.
  • the function network element involved in the embodiment of the present application is an entity having a certain function, and may be an NF, for example, a terminal, a base station, a controller, or a server.
  • the embodiments of the present application are not limited, and the functions are convenient for description and subsequent functions.
  • the network element is described as an example of NF.
  • FIG. 2 is a flowchart of a method for performing registration based on a service architecture according to an embodiment of the present application. Referring to FIG. 2, the method includes:
  • the OAM determines configuration information of the NF, where the configuration information includes a security parameter.
  • the OAM sends the determined configuration information containing the security parameters to the NF.
  • the NF obtains configuration information sent by the OAM, and sends a registration request to the NRF, where the registration request includes a security parameter and configuration information of the NF.
  • the NRF receives the registration request sent by the NF, and verifies the correctness of the security parameter included in the registration request, and determines whether the registration request sent by the NF is legal by the correctness of the verified security parameter.
  • the OAM includes a security parameter in the configuration information sent to the NF, and the NF carries the security parameter in the registration request and sends the security parameter to the NRF.
  • the NRF can determine the validity of the registration request sent by the NF by verifying the correctness of the security parameters included in the registration request.
  • the NRF adds the NF to the NF topology in the case that it is determined that the registration request sent by the NF is legal, and refuses to add the NF to the NF topology if it is determined that the registration request sent by the NF is invalid. Therefore, the communication method provided by the embodiment of the present application can improve communication security to a certain extent.
  • the foregoing security parameter in the embodiment of the present application may be a token, a digital signature (Signature), or a message authentication code (MAC).
  • Signature digital signature
  • MAC message authentication code
  • different security parameters have different generation methods, and the process of security parameter verification is also different.
  • Embodiment 1 The security parameter includes a token, and the token is generated based on an asymmetric key.
  • FIG. 3 is a flowchart of a security registration implementation based on a service architecture according to Embodiment 1 of the present application. Referring to FIG. 3, the method includes:
  • S201a OAM generates an asymmetric token.
  • the OAM may generate an asymmetric token based on the NRF public key (PKnrf).
  • the OAM generates an asymmetric token, and the OAM needs to pre-store the OAM public key (PKoam), the OAM private key (SKoam), and the NRF public key (PKnrf).
  • the PKnrf may be initially preset in the OAM, or may be obtained from the NRF during the interaction between the OAM and the NRF.
  • NRF also needs to save Pkoam, PKnrf and NRF private key (SKnrf) in advance.
  • the Pkoam may be initially set in the NRF, or may be in the process of OAM interacting with the NRF, and the OAM is sent to the NRF.
  • the OAM may encrypt the digital signature, the NF profile, and the NF identifier (ID_NF) based on PKoam to generate an asymmetric token.
  • the digital signature may be generated by the OAM based on SKoam, performing a digital signature algorithm on the NF profile and the ID_NF.
  • the parameter that the OAM performs encryption based on PKoam may include an identifier of the NRF (ID_NRF), an NF type (NF type), and a public land mobile network identifier (in addition to the digital signature, the NF profile, and the ID_NF).
  • ID_NRF NRF
  • NF type NF type
  • a public land mobile network identifier in addition to the digital signature, the NF profile, and the ID_NF.
  • Public Land Mobile Network ID PLMN ID
  • one or more of the service identifier supported by NF the number of random numbers (nonce_sign), and the validity period (time), token random number (nonce_token), counter and serial number. At least one of them.
  • the NF profile is an optional parameter
  • the ID_NRF is an optional parameter
  • the NF type is an optional parameter
  • the PLMN ID is an optional parameter
  • the NF support is The service identifier is optional.
  • Nonce_token, Nonce_sign is randomly selected for OAM.
  • the two nones can be the same or different, and are optional parameters.
  • the time may be the validity period of the key, and the specific form may include a start time and an end time, or a start time and a valid time, or an end time.
  • the PLMN ID may include the PLMN ID of the NF home network.
  • the NF is in the visited network, but the information of the NF is stored in the home network, so the PLMN ID may include at least one of the PLMN ID of the home network and the PLMN ID of the visited network.
  • the parameter of the digital signature algorithm based on SKoam includes one of ID_NRF, NF type, PLMN ID, and service identifier supported by NF, in addition to NF profile and ID_NF. Item or item, and at least one of time, nonce_sign, counter, and serial number.
  • the signed content may include an NF profile, an ID_NF, and may also include an ID_NRF, an NF type, a PLMN ID, a service identifier supported by the NF, a time, a nonce_sign, a counter, and a serial number.
  • the NF profile is an optional parameter
  • the NF type is an optional parameter
  • the PLMN ID is an optional parameter
  • the service identifier supported by the NF is an optional parameter.
  • S201b OAM determines the session key (K_session).
  • K_session may be shared between the NF and the NRF, and the K_session may be used for secure communication or authentication between the NF and the NRF.
  • the determination of K_session is an optional parameter step. When it is not necessary to use K_session for secure communication or authentication, the step of determining K_session may not be included.
  • the K_session may be used as a shared key between the NF and the NRF.
  • the PKoam may be used to encrypt the parameters involved.
  • the K_session is encrypted.
  • the K_session can also be signed.
  • the K_session may be randomly selected by the OAM, or the OAM may be derived from the ID_NF according to a preset root key.
  • the OAM may also derive one or more of the ID_NF, ID_NRF, NF profile, NF type, PLMN ID, and NF-supported service identifiers into K_session according to a preset root key.
  • the OAM may further derive at least one of time, session key random number (noce_session), counter and serial number into K_session.
  • the K_session may be derived from the ID_NF by the OAM according to the derivation key.
  • the OAM may also encrypt one or more of the ID_NF, ID_NRF, NF profile, NF type, PLMN ID, and NF-supported service identifiers according to the derivation key to generate a K_session.
  • the OAM may also derive at least one of time, session key random number (noce_session), counter and serial number into K_session.
  • the derivation key used to generate the K_session may be obtained by the OAM deriving the key of the preset root key, or may be the key of the NF saved by the OAM saved by the OAM.
  • K_session can also be a randomly selected parameter of OAM.
  • the ID_NRF is an optional parameter
  • the NF profile is an optional parameter
  • the NF type is an optional parameter
  • the PLMN ID is an optional parameter
  • the service identifier supported by the NF is optional.
  • the OAM determines configuration information, and sends configuration information to the NF, where the configuration information includes the generated asymmetric token.
  • the configuration information sent by the OAM and sent to the NF may further include ID_NF and token, and further may further include at least one of K_Session, ID_NRF, NF profile, NF type, and the like.
  • the NF receives the configuration information sent by the OAM, and sends a registration request to the NRF based on the configuration information, where the registration request includes an asymmetric token included in the configuration information, and may also include ID_NF, ID_NRF, NF profile, NF type, and the like. At least one of them.
  • the NRF receives the registration request sent by the NF, and verifies the correctness of the asymmetric token included in the registration request.
  • the NRF can use the SKnrf to decrypt the asymmetric token included in the registration request, obtain a digital signature, and verify the correctness of the digital signature by using Pkoam and the signed content. If the digital signature verification is successful, the NRF determines that the asymmetric token sent by the NF is correct, the registration request sent by the NF is legal, and the NF is authorized by the OAM, then the NRF adds the NF to the NF topology according to the registration request sent by the NF, and saves the NF. registration message.
  • the NRF determines that the asymmetric token sent by the NF is incorrect, the registration request sent by the NF is invalid, and the NF is not authorized by the OAM, and the NRF rejects the registration request of the NF.
  • S205 The NRF sends a registration response to the NF to notify whether the NF is successfully registered.
  • the NRF uses the SKnrf to decrypt the asymmetric token included in the registration request, and also obtains the K_Session
  • the K_Session is shared between the NF and the NRF.
  • the NRF can perform the following steps of S206 by using K_Session, where S206 is an optional step:
  • the NRF determines that the registration request sent by the NF is legal, and establishes a secure channel with the NF based on the K_session or the K_session derived key.
  • the key after the K_session is derived may be obtained by performing a key derivation algorithm on at least one of a K_session, a tunnel establishment counter, and a session ID.
  • the OAM includes an asymmetric token in the configuration information sent to the NF, and the asymmetric token is generated by the OAM based on the PKnrf.
  • the NF carries the asymmetric token in the registration request and sends it to the NRF. After receiving the registration request, the NRF can verify the validity of the registration request sent by the NF and verify the NF by verifying the correctness of the asymmetric token included in the registration request.
  • the K_session can be shared between the NF and the NRF, and the shared K_session is used to perform secure communication or authentication between the NF and the NRF.
  • Embodiment 2 The security parameter includes a token, and the token is generated based on a symmetric key.
  • FIG. 4 is a flowchart of implementing a security registration method according to Embodiment 2 of the present application.
  • the implementation flowchart of the security registration method shown in FIG. 4 is similar to the implementation process of the security registration method shown in FIG. 3, except that the calculation method of the token is different, and the following only explains the differences, for the same or similarities. Please refer to the description of the first embodiment above.
  • S301a The OAM generates a symmetric token.
  • the OAM may generate a symmetric token based on the symmetric key (k) shared between the OAM and the NRF.
  • the OAM In the case that the OAM generates a symmetric token based on the symmetric key (k) shared between the OAM and the NRF, the OAM and the NRF are each required to pre-store the symmetric key.
  • the OAM can generate and encrypt the MAC, the NF profile, and the ID_NF based on the symmetric key (k) shared between the OAM and the NRF.
  • the MAC may be generated by the OAM based on a symmetric key (k) shared between the OAM and the NRF, and an algorithm for performing a message authentication code on the ID_NF and the NF profile.
  • the OAM is based on a symmetric key (k) shared between the OAM and the NRF
  • the parameters for encryption include, in addition to the MAC, the NF profile, and the ID_NF, the ID_NRF, the NF type, the PLMN ID, and the NF support.
  • the parameters of the message authentication code algorithm may include the ID_NRF, the NF type, and the PLMN ID in addition to the ID_NF and the NF profile.
  • the MAC protected content may include a NF profile, ID_NF, and a shared key between the NF and the NRF, and may also include ID_NRF, NF type, PLMN ID, NF supported service identifier, time, nonce_mac, counter and serial number. Wait.
  • ID_NRF is an optional parameter
  • the NF profile is an optional parameter
  • the NF type is an optional parameter
  • the PLMN ID is an optional parameter
  • the service identifier supported by the NF is an optional parameter.
  • S301b OAM generates K_session.
  • the step of generating the K_session by the OAM in the embodiment of the present application is an optional step.
  • For the process of generating the K_session refer to the related description in the foregoing Embodiment 1 and no further details are provided herein.
  • the K_session can be used as the shared key between the NF and the NRF.
  • the OAM is divided by the symmetric key (k) shared between the OAM and the NRF.
  • the K_session can also be encrypted.
  • a message authentication code algorithm may be executed on the K_session.
  • the OAM determines configuration information, and sends configuration information to the NF, where the configuration information includes the symmetric token generated as described above.
  • the configuration information sent by the OAM and sent to the NF may further include ID_NF and token, and further may also include at least one of ID_NRF, K_Session, NF profile, NF type, and the like.
  • the NF receives the configuration information sent by the OAM, and sends a registration request to the NRF based on the configuration information, where the registration request includes a symmetric token included in the configuration information, and may also include ID_NF, ID_NRF, NF profile, NF type, and the like. At least one of them.
  • S304 The NRF receives the registration request sent by the NF, and verifies the correctness of the symmetric token included in the registration request.
  • the symmetric key shared by the NRF between the OAM and the NRF decrypts the symmetric token included in the registration request to obtain the MAC, and then utilizes the symmetric key (k) shared between the OAM and the NRF, and is MAC Protect the content and verify the correctness of the MAC. If the NRF verifies that the MAC is correct, the NRF determines that the symmetric token sent by the NF is correct, the registration request sent by the NF is legal, and the NF is authorized by the OAM, then the NRF adds the NF to the NF topology according to the registration request sent by the NF, and saves the registration of the NF. information.
  • the NRF determines that the symmetric token sent by the NF is incorrect, the registration request sent by the NF is invalid, and the NF is not authorized by the OAM, and the NRF rejects the registration request of the NF.
  • the K_Session is shared between the NF and the NRF.
  • the execution steps of S305 and S306 are similar to the execution steps of S205 and S206 involved in the first embodiment, and details are not described herein again.
  • the OAM generates a symmetric token based on the symmetric key (k) shared between the OAM and the NRF, and the OAM includes a symmetric token in the configuration information sent to the NF, and the NF carries the symmetric token in the registration request.
  • the NRF can verify the validity of the registration request sent by the NF by verifying the correctness of the symmetric token included in the registration request, and implement the authentication of the NF.
  • the K_session can be shared between the NF and the NRF, and the shared K_session is used to perform secure communication or authentication between the NF and the NRF.
  • Embodiment 3 Security parameters include MAC.
  • FIG. 5 is a flowchart of implementing a security registration method according to Embodiment 3 of the present application.
  • the implementation flowchart of the security registration method shown in FIG. 5 is similar to the implementation process of the security registration method shown in FIG. 4, except that the security parameter generated by the OAM is a MAC, and no token is generated, and the NRF only verifies the MAC, and does not need to verify the token. . Only the differences will be described below. For the same or similar aspects, refer to the related description of the above embodiment 2.
  • S401 The OAM generates a MAC.
  • the OAM may generate a MAC based on a symmetric key (k) shared between the OAM and the NRF.
  • the OAM In the case that the OAM generates a MAC based on the symmetric key (k) shared between the OAM and the NRF, the OAM and the NRF are each required to pre-store the symmetric key.
  • the OAM may perform a message authentication code algorithm on the ID_NF based on the symmetric key (k) shared between the OAM and the NRF to generate a MAC.
  • the parameter of the message authentication code algorithm may include one of an NF profile, an ID_NRF, an NF type, a PLMN ID, and a service identifier supported by the NF, in addition to the ID_NF. Multiple, and at least one of time, MAC random number (nonce_mac), counter and serial number.
  • the MAC protected content may include ID_NF, and may also include NF profile, ID_NRF, NF type, PLMN ID, service identifier supported by NF, time, nonce_mac, counter and serial number, and the like.
  • the ID_NRF is an optional parameter
  • the NF profile is an optional parameter
  • the NF type is an optional parameter
  • the PLMN ID is an optional parameter
  • the service identifier supported by the NF is an optional parameter.
  • the OAM determines configuration information, and sends configuration information to the NF, where the configuration information includes the generated MAC.
  • the configuration information in the embodiment of the present application includes, in addition to the MAC, an ID_NF used when generating the MAC. If the generated MAC includes the NF profile, the ID_NRF, the NF type, the PLMN ID, the service identifier supported by the NF, the time, the nonce_mac, the counter, the serial number, and other optional parameters, the configuration information may include the MAC address generation The parameters used. For example, if the parameter used to generate the MAC includes the ID_NRF in addition to the ID_NF, the configuration information sent by the OAM to the NF includes the MAC, the ID_NF, and the ID_NRF. The ID_NRF may be the identity information of the NRF or the address information of the NRF.
  • the shared parameter such as time or nonce_mac, or a non-shared counter or serial number must be sent.
  • the shared parameter does not need to be sent, for example, the OAM and the NRF share the counter and/or the serial number, and when the MAC is generated, the counter and/or the serial number are included, and then the configuration is performed. It is not necessary to include counters and/or serial numbers in the parameters.
  • the NF receives the configuration information sent by the OAM, and sends a registration request to the NRF based on the configuration information, where the registration request includes the parameter information included in the configuration information, for example, including the MAC and the ID_NF, and may also include the ID_NRF and the NF profile. At least one of NF type, PLMN ID, service identifier supported by NF, and the like. Further, parameters for calculating the MAC and non-shared between the OAM and the NRF need to be sent to the NRF, for example, the received time, nonce_mac, counter or serial number, etc., also need to be sent to the NRF.
  • the NRF receives the registration request sent by the NF, and verifies the correctness of the MAC included in the registration request.
  • the NRF can verify the correctness of the MAC by using the symmetric key (k) shared between the OAM and the NRF and the content protected by the MAC. If the NRF verifies that the MAC address is correct, the NRF determines that the registration request sent by the NF is legal, and the NF is authorized by the OAM, the NRF adds the NF to the NF topology according to the registration request sent by the NF, and saves the registration information of the NF. If the NRF verifies that the MAC is incorrect, the NRF determines that the registration request sent by the NF is invalid, and the NF is not authorized by the OAM, and the NRF rejects the registration request of the NF.
  • k symmetric key
  • S405 The NRF sends a registration response to the NF to notify whether the NF is successfully registered.
  • the OAM generates a MAC based on the symmetric key (k) shared between the OAM and the NRF.
  • the OAM includes a MAC in the configuration information sent to the NF, and the NF carries the MAC in the registration request and sends the MAC to the NRF.
  • the NRF can verify the validity of the registration request sent by the NF and verify the NF by verifying the correctness of the MAC included in the registration request.
  • the NRF is authenticated by the NRF.
  • the NF-to-NRF authentication is also implemented, that is, the two-way authentication of the NF and the NRF is implemented.
  • the process of implementing mutual authentication between NF and NRF will be described in the following embodiments in conjunction with Embodiment 4 and Embodiment 5.
  • Embodiment 4 Two-way authentication of NF and NRF is implemented based on MAC.
  • FIG. 6 is a flowchart of implementing a security registration method according to Embodiment 4 of the present application.
  • a MAC is generated by the NRF and the OAM respectively, and whether the MAC generated by the OAM is consistent with the MAC generated by the NRF, and the NF and the NF are implemented. Two-way authentication of NRF.
  • the MAC generated by the OAM in the third embodiment is referred to as the first MAC
  • the MAC generated by the NRF in the fourth embodiment of the present application is referred to as the second MAC, which is generated by the OAM in the embodiment of the present application.
  • the MAC is called the third MAC.
  • the OAM generates a first MAC and a third MAC.
  • the OAM may generate a third MAC based on a symmetric key (k) shared between the OAM and the NRF.
  • the OAM may perform a message authentication code algorithm on the ID_NF and the ID_NRF based on the symmetric key (k) shared between the OAM and the NRF to generate a third MAC.
  • the parameters of the message authentication code algorithm may include an NF profile in addition to the ID_NF and the ID_NRF.
  • the content protected by the third MAC may include ID_NF and ID_NRF, and may also include NF profile, NF type, PLMN ID, service identifier supported by NF, time, nonce_mac3, counter and serial number, and the like.
  • the NF profile is an optional parameter
  • the NF type is an optional parameter
  • the PLMN ID is an optional parameter
  • the service identifier supported by the NF is an optional parameter.
  • the OAM determines configuration information, and sends configuration information to the NF, where the configuration information includes the generated first MAC and third MAC.
  • the execution steps of S503 and S504 are the same as the execution steps of S403 and S404.
  • a parameter that uses OAM and NRF non-shared in the third MAC is generated, it needs to be sent to the NRF. For example, at least one of the received time, nonce_mac3, counter or serial number needs to be sent to the NRF through the NF.
  • S505 The NRF generates a second MAC.
  • the NRF may generate a second MAC based on a symmetric key (k) shared between the OAM and the NRF.
  • the NRF may perform a message authentication code algorithm on the ID_NF and the ID_NRF based on the symmetric key (k) shared between the OAM and the NRF to generate a second MAC.
  • the parameters involved in the second MAC process generated by the NRF in the embodiment of the present application are the same as those involved in the third MAC generated by the OAM, and are not described here.
  • the NRF sends a second MAC to the NF, where the second MAC may be sent by using a registration response sent by the NRF to the NF.
  • the NF receives the second MAC sent by the NRF, and compares whether the second MAC is consistent with the third MAC, and determines the validity of the second MAC according to the comparison result.
  • the NF determines that the second MAC is legal, and confirms that the NRF authentication passes.
  • the NRF authenticates the NF by verifying the first MAC, and the NF authenticates the NRF by comparing whether the second MAC and the third MAC are consistent, thereby implementing mutual authentication between the NF and the NRF.
  • Embodiment 5 Based on MAC, NF and NRF implement mutual authentication.
  • FIG. 7 is a flowchart of implementing a security registration method according to Embodiment 5 of the present application.
  • the execution steps of S601, S603, S604, S605, and S606 in Fig. 7 are the same as the execution steps of S501, S503, S504, S505, and S506 in Fig. 6 described above.
  • the execution steps of S602 in Fig. 7 are the same as the execution steps of S402 in Fig. 5.
  • the NF receives the second MAC sent by the NRF, and sends the second MAC to the OAM.
  • the OAM receives the second MAC sent by the NF, and compares whether the second MAC is consistent with the third MAC, and determines a verification result of the second MAC according to the comparison result.
  • the NF determines that the second MAC is legal, and confirms that the NRF authentication passes.
  • the OAM sends the verification result of the second MAC to the NF, and the NF determines the validity of the second MAC according to the verification result of the second MAC received from the OAM.
  • the NRF authenticates the NF by verifying the first MAC, and the NF determines the validity of the second MAC by using the verification result of the second MAC received from the OAM, and implements the authentication of the NRF, thereby implementing the NF and the NF.
  • Mutual authentication of NRF is a condition in which the NF determines the validity of the second MAC by using the verification result of the second MAC received from the OAM, and implements the authentication of the NRF, thereby implementing the NF and the NF.
  • Embodiment 6 Security parameters include digital signatures.
  • FIG. 8 is a flowchart of implementing a security registration method according to Embodiment 6 of the present application.
  • the implementation flowchart of the security registration method shown in FIG. 8 is similar to the security registration method implementation flow shown in FIG. 5, except that the security parameters generated by the OAM are digital signatures, not MAC addresses. Only the differences will be described below. For the same or similar aspects, refer to the related description of the third embodiment above.
  • S701 The OAM generates a digital signature.
  • the OAM may generate a digital signature based on SKoam.
  • OAM In the case where OAM generates a digital signature based on SKoam, OAM needs to save PKoam and SKoam in advance, and NRF also needs to save PKoam in advance.
  • the Pkoam may be initially set in the NRF, or may be in the process of OAM interacting with the NRF, and the OAM is sent to the NRF.
  • the OAM may be based on the parameter (the signed content) involved in the digital signature algorithm and the algorithm for executing the message authentication code in the process of generating the MAC involved in the third embodiment.
  • the parameters (the contents protected by the MAC) are similar. The only difference is that the random number used in the digital signature process is a digitally signed random number. For the same thing, it will not be described here.
  • the OAM determines configuration information, and sends configuration information to the NF, where the configuration information includes the generated digital signature.
  • a parameter that uses OAM and NRF non-shared in the digital signature is generated, it needs to be sent to the NRF. For example, at least one of the received time, nonce_sign, counter or serial number needs to be sent to the NRF through the NF.
  • the NF receives the configuration information sent by the OAM, and sends a registration request to the NRF based on the configuration information, where the registration request includes a digital signature generated by the OAM and sent to the NF.
  • the NRF receives the registration request sent by the NF, and verifies the correctness of the digital signature included in the registration request.
  • the NRF can verify the correctness of the digital signature by using the pre-saved Pkoam and the signed content. If the NRF determines that the digital signature sent by the NF is correct, the registration request sent by the NF is legal, and the NF is authorized by the OAM, the NRF adds the NF to the NF topology according to the registration request sent by the NF, and saves the registration information of the NF. If the NRF determines that the digital signature sent by the NF is incorrect, the registration request sent by the NF is invalid, and the NF is not authorized by the OAM, the NRF rejects the registration request of the NF.
  • S705 The NRF sends a registration response to the NF to notify whether the NF is successfully registered.
  • the OAM generates a digital signature based on the SKoam, and the OAM includes a digital signature in the configuration information sent to the NF, and the NF carries the digital signature in the registration request and sends the digital signature to the NRF.
  • the NRF can verify the validity of the registration request sent by the NF and verify the NF by verifying the correctness of the digital signature included in the registration request.
  • the NRF is authenticated by the digital signature based on the digital signature.
  • the NF-to-NRF authentication may also be implemented based on the digital signature, that is, the two-way authentication of the NF and the NRF is implemented based on the digital signature.
  • the process of implementing mutual authentication based on digital signatures by NF and NRF will be described below in conjunction with Embodiment 7.
  • Embodiment 7 NF and NRF perform mutual authentication based on digital signature.
  • a digital signature is generated by the NRF, and the NF verifies the NF pair by verifying the digital signature generated by the NRF. NRF certification.
  • the parameters for specifically generating the digital signature are consistent with the parameters for calculating the MAC in S605 in the corresponding embodiment of FIG. 7.
  • the digital signature generated by the OAM in the sixth embodiment is referred to as a first digital signature
  • the digital signature generated by the NRF in the seventh embodiment is referred to as a second digital signature.
  • FIG. 9 is a flowchart of implementing a security registration method according to Embodiment 7 of the present application.
  • the execution steps of S801, S802, and S803 involved in the security registration method implementation flow shown in FIG. 9 are similar to the execution steps of S701, S702, and S703 involved in the security registration method implementation flow shown in FIG. 8, and only FIG. 8 is required.
  • the digital signature involved in the replacement can be replaced by the first digital signature, so the same points will not be described here. The following only explains the differences:
  • S804 The NRF generates a second digital signature.
  • the NRF may generate a second digital signature based on the SKnrf.
  • the NRF performs the second digital signature process based on the SKnrf, performs the parameters involved in the digital signature algorithm (the signed content), and performs the message authentication in the process of generating the second MAC involved in the fourth embodiment.
  • the parameters involved in the code algorithm are similar, except that the random number used in the digital signature process is a digitally signed random number. For the same, the details are not described herein.
  • the NRF sends a second digital signature to the NF, where the second digital signature can be sent by using a registration response sent by the NRF to the NF.
  • the NF may verify the correctness of the second digital signature by using the pre-stored PKnrf, where the PKnrf may be initially preset in the NF, or may be obtained from the NRF during the interaction between the NF and the NRF.
  • the NF may verify the correctness of the second digital signature by using PKnrf and the content signed by the second digital signature. If the second digital signature is verified correctly, the NR verifies that the NRF is legal. If the second digital signature verification is incorrect, the NR verifies that the NRF is invalid.
  • the NRF authenticates the NF by verifying the first digital signature
  • the NF authenticates the NRF by verifying the second digital signature, thereby implementing mutual authentication of the NF and the NRF based on the digital signature.
  • Embodiment 8 The security parameter includes the MAC generated by the NF, and the correctness of the MAC generated by the NF is verified by the NRF.
  • FIG. 10 is a flowchart of implementing a security registration method according to Embodiment 8 of the present application. Referring to FIG. 10, the method includes:
  • the OAM determines the configuration information of the NF, and sends the determined configuration information to the NF, where the configuration information includes a derivation key (K_NF).
  • the OAM may perform key derivation on the preset root key to obtain a derivation key (K_NF), or the OAM may store a pre-configured derivation key (K_NF).
  • the OAM may perform a key derivation algorithm on the preset root key, the ID_NF, and the PLMN ID, and obtain the derivation key (K_NF).
  • the NF receives the configuration information sent by the OAM, and generates a MAC by using a derivation key (K_NF) included in the configuration information.
  • K_NF derivation key
  • the message authentication code generated by the NF according to the derivation key (K_NF) is referred to as a fourth MAC.
  • the fourth MAC generated by the NF based on the derivation key (K_NF) is similar to the first MAC generated by the OAM, except that the NF is generated based on the derivation key (K_NF), and the OAM is generated. It is generated based on the symmetric key (k) shared between OAM and NRF.
  • the NF based on the derivation key (K_NF) to generate the fourth MAC involved in the implementation of the message authentication code algorithm parameters see OAM based on the symmetric key shared between the OAM and the NRF (k) to generate the first MAC in the implementation of the message authentication code algorithm The parameters involved are not described here.
  • the NF sends a registration request to the NRF, where the registration request includes the generated fourth MAC and ID_NF.
  • the registration request may also include other configuration information than ID_NF.
  • S904 The NRF sends an ID_NF to the OAM.
  • the NRF may also send information such as the validity period (time) and the nonce_mac4 of the fourth MAC to the OAM to query the MAC information of the NF saved in the OAM.
  • the OAM receives the ID_NF sent by the NRF, and performs a message authentication code algorithm on the ID_NF based on the pre-stored derivation key (K_NF) to obtain a MAC for the NRF authentication NF.
  • K_NF pre-stored derivation key
  • the MAC generated by the OAM based on the derivation key (K_NF) is referred to as a fifth MAC.
  • the OAM generates a fifth MAC based on the derivation key (K_NF), which may be similar to the execution process of the third MAC generated by the OAM based on the symmetric key (k) shared between the OAM and the NRF.
  • K_NF derivation key
  • the OAM for the OAM to generate a parameter related to the execution of the message authentication code algorithm in the fifth MAC based on the derivation key (K_NF), refer to the OAM to generate the third MAC based on the symmetric key (k) shared between the OAM and the NRF.
  • K_NF derivation key
  • the OAM may also generate a K_session based on the derived key (K_NF).
  • S906 The OAM sends a fifth MAC to the NRF.
  • the OAM generates a K_session based on the derivation key (K_NF)
  • the generated K_session is also sent to the NRF.
  • the NRF receives the fifth MAC sent by the OAM, and compares whether the fourth MAC and the fifth MAC are consistent, to verify the correctness of the fourth MAC, and confirms the validity of the registration request sent by the NF based on the correctness of the fourth MAC. .
  • the NF determines that the fourth MAC is correct, confirms that the registration request sent by the NF is legal, and confirms that the NF authentication passes.
  • S908 The NRF sends an authentication response to the NF to notify the NF whether the authentication is passed.
  • the NRF may perform the following steps of S909 using K_Session:
  • the NRF determines that the registration request sent by the NF is legal, and establishes a secure channel with the NF based on the K_session or the K_session derived key.
  • the NF generates a fourth MAC and sends it to the NRF.
  • the NRF obtains the fifth MAC from the OAM by querying, and compares whether the fourth MAC and the fifth MAC are consistent to implement the NF authentication.
  • the NRF may send the fourth MAC to the OAM, and the OAM verifies the correctness of the fourth MAC, and the NRF may confirm the verification result of the fourth MAC sent by the OAM.
  • the OAM verifies the correctness of the fourth MAC
  • the NRF may confirm the verification result of the fourth MAC sent by the OAM.
  • Embodiment 9 The security parameter includes the MAC generated by the NF, and the correctness of the MAC generated by the NF is verified by the OAM.
  • FIG. 11 is a flowchart of implementing a security registration method according to Embodiment 9 of the present application.
  • the execution steps of S1001, S1002, S1003, S1008, and S1009 are the same as the execution steps of S901, S902, S903, S908, and S909 in FIG. 10, and details are not described herein again. The following only explains the differences:
  • S1004 The NRF sends the ID_NF and the fourth MAC to the OAM.
  • the OAM receives the ID_NF and the fourth MAC sent by the NRF, and generates a fifth MAC based on the pre-stored derivation key (K_NF).
  • the OAM may also generate a K_session based on the derived key (K_NF).
  • the OAM compares whether the fourth MAC and the fifth MAC are consistent to verify the correctness of the fourth MAC, and sends the verification result of the fourth MAC to the NRF.
  • the NF determines that the fourth MAC is correct, confirms that the registration request sent by the NF is legal, and confirms that the NF authentication passes.
  • the NRF receives the verification result of the fourth MAC sent by the OAM to confirm the correctness of the fourth MAC, and confirms the validity of the registration request sent by the NF.
  • the K_session is sent to the NRF.
  • the NF generates a fourth MAC and sends the fourth MAC
  • the NRF sends the fourth MAC to the OAM.
  • the OAM generates a fifth MAC, and compares whether the fourth MAC and the fifth MAC are consistent, verifies the correctness of the fourth MAC, and sends the verification result of the fourth MAC to the NRF, and the NRF confirms the NF transmission based on the verification result of the fourth MAC.
  • the legality of the registration request to achieve the certification of the NF.
  • the foregoing embodiment for verifying by using the MAC and the signature further includes the possibility of generating a K_session based on DH (Diffie-Hellman) key negotiation, that is, the OAM generates a public key PK_DH_OAM and a private key for DH key negotiation.
  • SK_DH_OAM protects PK_DH_OAM with MAC or signature, and OAM sends PK_DH_OAM and SK_DH_OAM to NF.
  • the NF additionally transmits PK_DH_OAM to the NRF based on the transmission of the registration request in the previous embodiment.
  • the public key PK_DH_NRF and the private key SK_DH_NRF of the DH key negotiation are generated. And generate K_session based on PK_DH_OAM and SK_DH_NRF.
  • the NRF sends PK_DH_NRF to the NF.
  • NF can generate K_session based on PK_DH_NRF and SK_DH_OAM.
  • the format of the parameters and the way in which K_session is calculated are similar to the classic DH key negotiation procedure.
  • the DH key agreement is not limited, including but not limited to discrete logarithms and the like.
  • the embodiments for all the asymmetric technologies described above can still be implemented by using identity-based technology.
  • identity-based technology and certificate-based asymmetric security technology is that the public key PK can be an ID, ie, a user identity.
  • the solution provided by the embodiment of the present application is introduced from the perspective of the interaction between the management network element, the function network element, and the control network element.
  • the management network element, the function network element and the control network element comprise corresponding hardware structures and/or software modules for performing the respective functions in order to implement the above functions.
  • the embodiments of the present application can be implemented in a combination of hardware or hardware and computer software in combination with the elements of the examples and algorithm steps described in the embodiments disclosed in the application. Whether a function is implemented in hardware or computer software to drive hardware depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the technical solutions of the embodiments of the present application.
  • the embodiments of the present application may perform functional unit division on the management network element, the function network element, and the control network element according to the foregoing method example.
  • each functional unit may be divided according to each function, or two or more functions may be integrated.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. It should be noted that the division of the unit in the embodiment of the present application is schematic, and is only a logical function division. In actual implementation, there may be another division manner.
  • FIG. 12 is a schematic structural diagram of a registration device 100 based on a service architecture provided by an embodiment of the present application.
  • the registration device 100 based on the service architecture can be applied to the management network element.
  • the registration device 100 applied to the management network element can include the processing unit 101 and the sending unit 102.
  • the processing unit 101 is configured to determine configuration information of the function network element and generate a security parameter.
  • the sending unit 102 is configured to send the configuration information determined by the processing unit 101 to the function network element, and include the generated security parameter in the sent configuration information.
  • the processing unit 101 may manage a private key of the network element, perform a digital signature algorithm on the function network element data and the identifier of the function network element, generate a digital signature, and perform digital signature based on the public key of the control network element.
  • the function network element data and the identifier of the function network element are encrypted to generate an asymmetric token.
  • the sending unit 102 sends the asymmetric token generated by the processing unit 101 as a security parameter to the function network element.
  • the processing unit 101 may further generate a digital signature by performing a digital signature algorithm on the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element, based on the private key of the management network element, and
  • the asymmetric token is generated by encrypting the digital signature, the function network element data, the identifier of the function network element, and the shared key between the function network element and the control network element based on the public key of the control network element.
  • the sending unit 102 sends the asymmetric token generated by the processing unit 101 as a security parameter to the function network element.
  • the processing unit 101 may generate a message authentication code based on a symmetric key shared between the management network element and the control network element, and an algorithm for performing a message authentication code on the identifier of the function network element and the function network element data. And based on the symmetric key shared between the management network element and the control network element, encrypt the message authentication code, the function network element data, and the function network element identifier to generate a symmetric token.
  • the sending unit 102 sends the symmetric token generated by the processing unit 101 as a security parameter to the functional network element.
  • the processing unit 101 may further perform a message on the shared key between the function network element and the control network element, the identifier of the function network element, and the function network element data based on the symmetric key shared between the management network element and the control network element.
  • the algorithm of the authentication code generates a message authentication code, and based on the symmetric key shared between the management network element and the control network element, the message authentication code, the function network element data, the identifier of the function network element, and the function network element and the control network element.
  • the shared key encryption creates a symmetric key.
  • the sending unit 102 sends the symmetric token generated by the processing unit 101 as a security parameter to the functional network element.
  • the processing unit 101 may generate a message authentication code algorithm for the function network element data and the identifier of the function network element based on a symmetric key shared between the management network element and the control network element. A message authentication code.
  • the sending unit 102 sends the first message authentication code generated by the processing unit 101 as a security parameter to the function network element.
  • the processing unit 101 may further generate a third message authentication code by performing an algorithm for performing a message authentication code on the identifier of the function network element and the identifier of the control network element based on the symmetric key shared between the management network element and the control network element.
  • the sending unit 102 sends the third message authentication code generated by the processing unit 101 as a security parameter to the function network element.
  • the registration device 100 may further include a receiving unit 103, where the receiving unit 103 is configured to receive a fourth message authentication code sent by the control network element and an identifier of the function network element.
  • the processing unit 101 generates a fifth message authentication code according to the algorithm for performing the message authentication code on the identifier of the function network element and the identifier of the control network element, and compares whether the fourth message authentication code and the fifth message authentication code are consistent.
  • the function network element determines that the fourth message authentication code is correct, and confirms that the registration request sent by the function network element is legal, and confirms the function network.
  • the sending unit 102 sends the verification result of the fourth message authentication code to the control network element.
  • the processing unit 101 may perform a digital signature algorithm on the function network element data and the identifier of the function network element to generate a first digital signature based on the private key of the management network element.
  • the sending unit 102 sends the first digital signature generated by the processing unit 101 as a security parameter to the function network element.
  • the processing unit 101 may be a processor
  • the transmitting unit 102 may be a transmitter
  • the receiving unit 103 may be a receiver
  • the registration device 100 can adopt the configuration of the management network element shown in FIG.
  • the management network element shown in FIG. 13 may be OAM
  • the OAM may be the OAM involved in the foregoing method embodiment.
  • FIG. 13 is a schematic structural diagram of a management network element 1000 provided by an embodiment of the present application, that is, another structure diagram of the registration apparatus 100.
  • the management network element 1000 includes a processor 1001, a transmitter 1002, and a receiver 1003.
  • the processor 1001 can also be a controller.
  • the processor 1001 is configured to support the management network element 1000 to perform the functions of the management network element involved in FIGS. 2 to 11.
  • the transmitter 1002 and the receiver 1003 are configured to support a function of transmitting and receiving messages between the management network element 1000 and the control network element and the function network element.
  • the management network element 1000 can also include a memory 1004 for coupling with the processor 1001, which stores the necessary program instructions and data for managing the network element 1000.
  • the processor 1001, the transmitter 1002, the receiver 1003, and the memory 1004 are connected to the memory 1004.
  • the processor 1001 is configured to execute instructions stored in the memory 1004 to control the transceiver 1002 and the receiver 1003 to transmit and receive. Data, completing the steps of the above method to manage the network element to perform the corresponding function.
  • FIG. 14 is a schematic structural diagram of a registration device 200 based on a service architecture provided by an embodiment of the present application.
  • the registration device 200 based on the service architecture can be applied to the function network element.
  • the registration device 200 applied to the function network element can include a receiving unit 201 and a sending unit 202.
  • the receiving unit 201 is configured to receive configuration information and security parameters sent by the management network element.
  • the sending unit 202 is configured to send a registration request to the control network element based on the configuration information received by the receiving unit 201, where the registration request includes the security parameter received by the receiving unit 201.
  • the security parameter received by the receiving unit 201 may be an asymmetric token generated by the management network element, a symmetric token, a first message authentication code, or a first digital signature.
  • the receiving unit 201 is further configured to receive a second message authentication code sent by the control network element and a third message authentication code sent by the management network element.
  • the registration device 200 further includes a processing unit 203, wherein the processing unit 203 is configured to compare whether the second message authentication code and the third message authentication code are consistent, and determine the validity of the second message authentication code according to the comparison result.
  • the receiving unit 201 is further configured to receive a second message authentication code sent by the control network element, and the sending unit 202 sends the second message authentication code received by the receiving unit 201 to the management network element.
  • the receiving unit 201 is further configured to receive a second message authentication code verification result sent by the control network element.
  • the registration device 200 further includes a processing unit 203, wherein the processing unit 203 is configured to determine the validity of the second message authentication code according to the second message authentication code verification result received by the receiving unit 201.
  • the receiving unit 201 is further configured to receive a second digital signature sent by the control network element.
  • the booklet device 200 further includes a processing unit 203, wherein the processing unit 203 is configured to verify the legitimacy of the second digital signature according to the receiving of the second digital signature by the receiving unit 201 and the content signed by the second digital signature.
  • the registration apparatus 200 further includes a processing unit 203, configured to establish a secure channel with the control network element based on the session key or the session key based derivation key.
  • the receiving unit 201 may be a receiver
  • the sending unit 202 may be a transmitter
  • the processing unit 203 may be a processor
  • the registration device 200 can adopt the structure of the function network element shown in FIG.
  • the functional network element shown in FIG. 15 may be NF
  • the NF may be the NF involved in the foregoing method embodiment.
  • FIG. 15 is a schematic structural diagram of a function network element 2000 provided by an embodiment of the present application, that is, another structure diagram of the registration apparatus 200.
  • the function network element 2000 includes a processor 2001, a transmitter 2002, and a receiver 2003.
  • the processor 2001 can also be a controller.
  • the processor 2001 is configured to support the function network element 2000 to perform the functions of the functional network elements involved in FIGS. 2 through 11.
  • the transmitter 2002 and the receiver 2003 are configured to support the function of transmitting and receiving messages between the function network element 2000 and the control network element and the management network element.
  • the functional network element 2000 can also include a memory 2004 for coupling with the processor 2001 that holds the necessary program instructions and data for the functional network element 2000.
  • the processor 2001, the transmitter 2002, the receiver 2003 and the memory 2004 are connected, the memory 2004 is for storing instructions for executing the instructions stored by the memory 2004 to control the transmitter 2002 and the receiver 2003 to transmit and receive. Data, completing the steps of the function network element performing the corresponding function in the above method.
  • FIG. 16 is a schematic structural diagram of a registration device 300 based on a service architecture provided by an embodiment of the present application.
  • the registration device 300 based on the service architecture can be applied to the control network element.
  • the registration device 300 applied to the function network element can include a receiving unit 301 and a processing unit 302.
  • the receiving unit 301 is configured to receive a registration request sent by the function network element, where the registration request includes a security parameter.
  • the processing unit 302 is configured to verify the correctness of the security parameters received by the receiving unit 301, and determine the legitimacy of the registration request by the correctness of the security parameters.
  • the security parameter includes an asymmetric token.
  • the processing unit 302 decrypts the asymmetric token by using the private key of the control network element to obtain a digital signature, and verifies the correctness of the digital signature by using the public key of the management network element and the signed content.
  • the security parameter includes a symmetric token.
  • the processing unit 302 decrypts the symmetric token by using the symmetric key to obtain a message authentication code, and verifies the correctness of the message verification code by using the symmetric key and the content protected by the message verification code.
  • the security parameter includes a first message authentication code.
  • the processing unit 302 verifies the correctness of the first message authentication code by using a symmetric key shared between the management network element and the control network element and content protected by the first message verification code.
  • the processing unit 302 is further configured to manage a symmetric key shared between the network element and the control network element, and generate a second message authentication by using an algorithm for performing the message authentication code on the identifier of the function network element and the identifier of the control network element. code.
  • the registration device 300 also includes a transmitting unit 303.
  • the sending unit 303 is configured to send the second message authentication code generated by the processing unit 302 to the function network element, so that the function network element implements authentication on the control network element by using the second message authentication code.
  • the security parameter includes a first digital signature.
  • the processing unit 302 verifies the correctness of the first digital signature by using the public key of the management network element and the content signed by the first digital signature.
  • the processing unit 302 is further configured to perform a digital signature algorithm on the identifier of the function network element and the identifier of the control network element to generate a second digital signature based on a private key of the control network element.
  • the registration device 300 also includes a transmitting unit 303.
  • the sending unit 303 is configured to send the second digital signature generated by the processing unit 302 to the function network element, so that the function network element implements authentication on the control network element by using the second digital signature.
  • the receiving unit 301 is configured to receive an identifier of the function network element sent by the function network element and a fourth message authentication code.
  • the registration device 300 also includes a transmitting unit 303.
  • the sending unit 303 sends the identifier of the function network element and the fourth message authentication code received by the receiving unit 301 to the management network element.
  • the receiving unit 301 is further configured to receive a fifth message authentication code sent by the management network element.
  • the processing unit 302 is further configured to compare whether the fourth message authentication code and the fifth message authentication code are consistent, and verify the correctness of the fourth message authentication code.
  • the receiving unit 301 is configured to receive an identifier of the function network element sent by the function network element and a fourth message authentication code.
  • the registration device 300 also includes a transmitting unit 303.
  • the sending unit 303 sends the identifier of the function network element and the fourth message authentication code received by the receiving unit 301 to the management network element.
  • the receiving unit 301 is further configured to receive a fourth message authentication code verification result sent by the management network element.
  • the processing unit 302 determines the correctness of the fourth message authentication code according to the fourth message authentication code verification result received by the receiving unit 301.
  • the receiving unit 301 may be a receiver
  • the processing unit 302 may be a processor
  • the sending unit 303 may be a transmitter
  • the receiving unit 301 is a receiver
  • the processing unit 302 is a processor
  • the sending unit 303 When it is a transmitter, the registration device 300 can adopt the structure of the control network element shown in FIG.
  • the control network element shown in FIG. 17 may be an NRF
  • the NRF may be the NRF involved in the foregoing method embodiment.
  • FIG. 17 is a schematic structural diagram of a control network element 3000 provided by an embodiment of the present application, that is, another structure diagram of the registration apparatus 300.
  • the control network element 3000 includes a processor 3001, a transmitter 3002, and a receiver 3003.
  • the processor 3001 can also be a controller.
  • the processor 3001 is configured to support the control network element 3000 to perform the functions of the control network elements involved in FIGS. 2 through 11.
  • the transmitter 3002 and the receiver 3003 are configured to support a function of transmitting and receiving messages between the control network element 3000 and the function network element and the management network element.
  • the control network element 3000 can also include a memory 3004 for coupling with the processor 3001 that holds the necessary program instructions and data for controlling the network element 3000.
  • the processor 3001, the transmitter 3002, the receiver 3003, and the memory 3004 are connected to each other.
  • the memory 3004 is configured to store an instruction
  • the processor 3001 is configured to execute the instruction stored in the memory 3004 to control the transceiver 3002 and the receiver 3003 to transmit and receive. Data, completing the steps of the above method for controlling the network element to perform the corresponding function.
  • the registration device 300 and the control network element 3000 are referred to the foregoing methods or other embodiments. Description, no further description here.
  • the processor involved in the foregoing embodiments may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), and an application-specific integrated circuit (application-specific).
  • the processor can also be a combination of computing functions, for example, including one or more microprocessor combinations, a combination of a DSP and a microprocessor, and the like.
  • the memory may be integrated in the processor or may be separately provided from the processor.
  • the functions of the receiver and the transmitter can be implemented by a dedicated chip through the transceiver circuit or the transceiver.
  • the processor can be implemented by a dedicated processing chip, a processing circuit, a processor, or a general purpose chip.
  • program code that implements processor, receiver, and transmitter functions is stored in a memory that implements the functions of the processor, receiver, and transmitter by executing code in memory.
  • the embodiment of the present application further provides a communication system, which includes the foregoing management network element, a function network element, and a control network element.
  • the embodiment of the present application further provides a chip, and the chip is connected to a memory for reading and executing a software program stored in the memory to implement the functions performed by the management network element involved in the foregoing embodiment.
  • the embodiment of the present application further provides a chip, and the chip is connected to a memory for reading and executing a software program stored in the memory to implement functions performed by the function network element involved in the foregoing embodiment.
  • the embodiment of the present application further provides a chip, and the chip is connected to a memory for reading and executing a software program stored in the memory to implement the functions performed by the control network element involved in the foregoing embodiment.
  • the embodiment of the present application further provides a computer storage medium, where the computer storage medium stores some instructions, and when the instructions are executed, the registration method involved in the foregoing method embodiments may be completed.
  • the embodiment of the present application further provides a computer program product, where the computer program product includes a computer program, and the computer program is used to execute the registration method involved in the foregoing method embodiment.
  • embodiments of the present application can be provided as a method, system, or computer program product. Therefore, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Landscapes

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

Abstract

本申请实施例提供一种基于服务化架构的注册方法及装置，在该方法中，管理网元确定功能网元的配置信息，所述配置信息中包括安全参数；所述管理网元向功能网元发送所述配置信息。功能网元接收管理网元发送的配置信息；所述功能网元基于所述配置信息，向控制网元发送注册请求，所述注册请求中包括安全参数。控制网元接收功能网元发送的注册请求，所述注册请求中包括安全参数；所述控制网元验证所述安全参数的正确性，并通过所述安全参数的正确性确定所述注册请求的合法性，以实现控制网元对功能网元的注册请求进行安全认证，提高安全性。

Description

基于服务化架构的注册方法及装置
本申请要求在2017年8月31日提交中国专利局、申请号为201710774290.9、申请名称为“基于服务化架构的注册方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及一种基于服务化架构的注册方法及装置。
背景技术
在5G网络的核心网网络架构讨论中，提出以网络功能(network function，NF)为中心的服务化架构方案。在服务化架构方案中，通过模块化实现NF间的解耦和整合，各解耦后的NF独立扩容、独立演进、按需部署，并且控制面的所有NF之间采用服务化接口进行交互，同一种服务可以被多种NF调用，降低NF之间接口定义的耦合度，最终实现整网功能的按需定制，以灵活支持不同的业务场景和需求。
在服务化架构方案中，通常由NF存储功能(NF repository function，NRF)等控制网元为NF提供服务的注册、发现、授权等功能，实现NF和服务的按需配置及NF间的互连。目前，一种可能的安全注册方法中，管理网元首先向待注册的功能网元配置相应参数，之后待注册的功能网元直接向NRF发送注册请求，NRF接收到该注册请求后直接完成注册。NRF将注册完成的功能网元添加至NF拓扑中，并发送响应消息至该注册完成的功能网元。
由于待注册的功能网元与NRF之间通信接口不受安全信道的保护，可能存在攻击者修改参数，或者攻击者扮演待注册的功能网元的角色尝试接入NRF的风险，故上述基于服务化架构的安全注册方法中，NRF并不会对待注册的功能网元所发送的注册请求进行安全认证，安全性较低。
发明内容
本申请实施例提供一种基于服务化架构的注册方法及装置，以实现控制网元对功能网元的注册请求进行安全认证，提高安全性。
第一方面，提供一种基于服务化架构的注册方法，在该方法中，功能网元向控制网元发送注册请求，并且该注册请求中包括有安全参数。控制网元接收到功能网元发送的注册请求，验证注册请求中包括的安全参数的正确性，通过验证的安全参数的正确性确定NF发送的注册请求是否合法，以实现对功能网元的注册请求的安全认证，提高安全性。
其中，安全参数可由管理网元确定，管理网元将确定的安全参数包含在配置信息中发送给功能网元，功能网元接收到管理网元发送的配置信息后，将配置信息中包括的安全参数携带在注册请求中发送给管理网元。
本申请实施例提供的注册方法中，管理网元接收功能网元发送的注册请求后，通过验证注册请求中包括的安全参数的正确性，可确定功能网元发送的注册请求的合法性。管理网元在确定功能网元发送的注册请求合法的情况下，将功能网元添加至功能网元拓扑中，在确定功能网元发送的注册请求不合法的情况下，拒绝将功能网元添加 至功能网元拓扑中。故，通过本申请实施例提供的注册方法，可一定程度上提高通信安全性。
一种可能的设计中，管理网元确定的安全参数包括非对称令牌。
其中，管理网元可基于管理网元的私钥，对功能网元资料、功能网元的标识执行数字签名算法生成数字签名，并基于控制网元的公钥，对数字签名、功能网元资料、功能网元的标识加密生成非对称令牌。
其中，管理网元还可基于管理网元的私钥，对功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥执行数字签名算法生成数字签名，并基于控制网元的公钥，对数字签名、功能网元资料、功能网元的标识以及功能网元与控制网元之间的共享密钥加密生成非对称令牌。
其中，上述共享密钥可以是管理网元生成的会话密钥。会话密钥用于功能网元与控制网元之间的安全通信或认证。会话密钥可由管理网元根据预设的根密钥，对功能网元的标识加密生成。会话密钥也可由管理网元根据推衍密钥对功能网元的标识加密生成。其中，推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者推衍密钥为管理网元保存的功能网元的密钥。
进一步的，基于控制网元的公钥进行加密的参数除了数字签名、功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥以外，还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识，数字签名随机数等中的一项或多项，以及令牌有效期，令牌随机数，计数器和序列号中的至少一项。管理网元基于管理网元的私钥执行数字签名算法的参数除了功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥以外，还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及签名有效期，签名随机数，计数器和序列号中的至少一项。
管理网元将上述生成的非对称令牌作为安全参数发送给功能网元，功能网元向控制网元发送非对称令牌，控制网元接收该非对称令牌，并利用控制网元的私钥解密该非对称令牌，以得到数字签名，并利用管理网元的公钥以及被签名的内容，验证数字签名的正确性。
其中，被签名的内容与执行签名算法的参数相同，例如可包括功能网元资料、功能网元标识；除包括功能网元资料、功能网元标识以外还可包括功能网元与控制网元之间的共享密钥、控制网元标识功能网元类型，PLMN标识，功能网元支持的业务标识，数字签名随机数等中的一项或多项，以及令牌有效期，令牌随机数，计数器和序列号中的至少一项。
另一种可能的设计中，管理网元确定的安全参数包括对称令牌。
其中，管理网元可基于管理网元与控制网元之间共享的对称密钥，对功能网元的标识以及功能网元资料执行消息认证码的算法生成消息认证码，并基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、功能网元的标识加密，生成对称令牌。
管理网元也可基于管理网元与控制网元之间共享的对称密钥，对功能网元和控制网元之间的共享密钥，功能网元的标识以及功能网元资料执行消息认证码的算法生成消息认证码，并基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能 网元资料、功能网元的标识、以及功能网元和控制网元之间的共享密钥加密生成对称密钥。
其中，功能网元和控制网元之间的共享密钥可以是管理网元生成的会话密钥。会话密钥用于功能网元与控制网元之间的安全通信或认证。会话密钥可由管理网元根据预设的根密钥，对功能网元的标识加密生成。会话密钥也可由管理网元根据推衍密钥对功能网元的标识加密生成。其中，推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者推衍密钥为管理网元保存的功能网元的密钥。
进一步的，管理网元基于管理网元与控制网元之间共享的对称密钥进行加密的参数除了消息认证码、功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥以外，还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识，消息认证码随机数等中的一项或多项，以及令牌有效期，令牌随机数，计数器和序列号中的至少一项。管理网元基于管理网元与控制网元之间共享的对称密钥执行消息认证码算法的参数除了功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥以外，还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及消息认证码有效期，消息认证码随机数，计数器和序列号中的至少一项。
管理网元将上述生成的对称令牌作为安全参数发送给功能网元，功能网元向控制网元发送对称令牌，控制网元接收该对称令牌，并利用对称密钥解密该对称令牌，以得到消息认证码，并利用管理网元与控制网元之间共享的对称密钥，以及被消息验证码保护的内容，验证消息验证码的正确性。
其中，被消息验证码保护的内容与执行消息验证码算法的参数相同，例如可包括功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥；除包括功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥以外还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及消息认证码有效期，消息认证码随机数，计数器和序列号中的至少一项。
又一种可能的设计中，管理网元确定的安全参数包括第一消息认证码。
其中，管理网元可基于管理网元与控制网元之间共享的对称密钥，对功能网元资料以及所述功能网元的标识执行消息认证码的算法生成第一消息认证码。
进一步的，管理网元基于管理网元与控制网元之间共享的对称密钥执行消息认证码算法生成第一消息认证码的参数除了功能网元资料、功能网元的标识以外，还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第一消息认证码有效期，第一消息认证码随机数，计数器和序列号中的至少一项。
管理网元将上述生成的第一消息认证码作为安全参数发送给功能网元，功能网元向控制网元发送第一消息认证码，控制网元接收到该第一消息认证码，利用管理网元与控制网元之间共享的对称密钥、以及被第一消息验证码保护的内容，验证第一消息认证码的正确性。其中，被第一消息验证码保护的内容与执行消息验证码算法生成第一消息验证码时使用的参数相同，例如可包括功能网元资料以及功能网元的标识；除包括功能网元资料以及功能网元的标识以外还可包括控制网元标识，功能网元类型， PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第一消息认证码有效期，第一消息认证码随机数，计数器和序列号中的至少一项。
又一种可能的设计中，管理网元确定的安全参数包括第一数字签名。
其中，管理网元可基于管理网元的私钥，对功能网元资料、以及功能网元的标识执行数字签名算法生成第一数字签名。
进一步的，管理网元基于管理网元的私钥执行数字签名算法的参数除了功能网元资料、功能网元的标识以外，还可包括控制网元标识，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第一数字签名有效期，第一数字签名随机数，计数器和序列号中的至少一项。
管理网元将上述生成的第一数字签名作为安全参数发送给功能网元，功能网元向控制网元发送第一数字签名，控制网元接收该第一数字签名，并利用控制网元的私钥解密该第一数字签名，以得到数字签名，并利用管理网元的公钥以及被第一数字签名所签名的内容，验证第一数字签名的正确性。
其中，被第一数字签名所签名的内容与执行签名算法生成第一数字签名的参数相同，例如可包括功能网元资料、功能网元标识；除包括功能网元资料、功能网元标识以外还可控制网元标识功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第一数字签名有效期，第一数字签名随机数，计数器和序列号中的至少一项。
本申请实施例中，控制网元通过对管理网元生成的非对称令牌、对称令牌、第一消息认证码或者第一数字签名进行验证，可实现对功能网元的认证。
又一种可能的设计中，管理网元生成第一消息认证码和第三消息认证码，并发送给功能网元。功能网元将第一消息认证码发送给控制网元，控制网元验证第一消息认证码的合法性，实现对功能网元的认证。控制网元生成第二消息认证码，并发送给功能网元。功能网元验证第三消息认证码与第二消息认证码是否一致，以实现对第二消息认证码的合法性进行验证，并通过第二消息认证码的合法性实现对控制网元的认证。通过本申请实施例可实现功能网元和控制网元的相互认证。
其中，第二消息认证码由控制网元基于管理网元与控制网元之间共享的对称密钥，对功能网元的标识以及控制网元的标识执行消息认证码的算法生成。进一步的，控制网元基于管理网元与控制网元之间共享的对称密钥执行消息认证码算法生成第二消息认证码的参数除了功能网元的标识以及控制网元的标识以外，还可包括功能网元资料，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第二消息认证码有效期，第二消息认证码随机数，计数器和序列号中的至少一项。
其中，第三消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对功能网元的标识以及控制网元的标识执行消息认证码的算法生成。进一步的，管理网元基于管理网元与控制网元之间共享的对称密钥执行消息认证码算法生成第三消息认证码的参数除了功能网元的标识以及控制网元的标识以外，还可包括功能网元资料，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第三消息认证码有效期，第三消息认证码随机数，计数器和序列号中的至少一项。
又一种可能的设计中，管理网元生成第一数字签名，并发送给功能网元。功能网元将第一数字签名发送给控制网元，控制网元验证第一数字签名的合法性，实现对功 能网元的认证。控制网元生成第二数字签名，并发送给功能网元。功能网元验证第一数字签名与第二数字签名是否一致，以实现对第二数字签名的合法性进行验证，并通过第二数字签名的合法性实现对控制网元的认证。通过本申请实施例可实现功能网元和控制网元的相互认证。
其中，第二数字签名由述控制网元基于控制网元的私钥，对功能网元的标识以及控制网元的标识执行数字签名算法生成。进一步的，控制网元基于控制网元的私钥执行数字签名算法生成第二数字签名的参数除了功能网元的标识以及控制网元的标识以外，还可包括功能网元资料，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及第二数字签名有效期，第二数字签名随机数，计数器和序列号中的至少一项。
又一种可能的设计中，功能网元向控制网元发送的安全参数可包括由功能网元生成的第四消息认证码。
其中，功能网元可根据推衍密钥，对功能网元的标识执行消息认证码的算法生成第四消息认证码。
其中，功能网元生成第四消息认证码所用的推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者为所述管理网元保存的所述功能网元的密钥。
一种可能的实施方式中，功能网元向控制网元发送第四消息认证码以及功能网元的标识，控制网元接收到第四消息认证码以及功能网元的标识之后，向管理网元发送功能网元的标识，并接收管理网元发送的第五消息认证码，控制网元通过比较第四消息认证码与第五消息认证码是否一致，验证所述第四消息认证码的正确性，并基于第四消息认证码的正确性，确认功能网元发送的注册请求的合法性。本申请实施例中，若第四消息认证码与第五消息认证码一致，则功能网元确定第四消息认证码正确，确认功能网元发送的注册请求合法，确认功能网元认证通过，实现功能网元对控制网元的认证。
另一种可能的实施方式中，功能网元向控制网元发送第四消息认证码，功能网元接收到第四消息认证码之后，向管理网元发送第四消息认证码。管理网元接收到控制网元发送的第四消息认证码，基于预先保存的推衍密钥生成第五消息认证码，并比较第四消息认证码与第五消息认证码是否一致，以实现对第四消息认证码的验证，若第四消息认证码与第五消息认证码一致，则功能网元确定第四消息认证码正确，确认功能网元发送的注册请求合法，确认功能网元认证通过。管理网元向控制网元发送第四消息认证码的验证结果，控制网元接收管理网元发送的第四消息认证码的验证结果，根据管理网元发送的第四消息认证码验证结果，确定第四消息认证码的正确性，以实现对功能网元的认证。
其中，第五消息认证码由管理网元根据推衍密钥，对功能网元的标识以及控制网元的标识执行消息认证码的算法生成。
其中，第四消息认证码与第五消息认证码生成过程中执行消息认证码算法的参数相同，除包括功能网元的标识以及控制网元的标识以外，还可包括功能网元资料，功能网元类型，PLMN标识，功能网元支持的业务标识等中的一项或多项，以及消息认证码有效期，消息认证码随机数，计数器和序列号中的至少一项。
又一种可能的设计中，控制网元与功能网元之间可基于会话密钥或者基于会话密钥的推衍密钥，建立安全通道。
其中，控制网元可通过解密非对称令牌或对称令牌得到会话密钥，所述非对称令牌或所述对称令牌基于所述会话密钥生成；或者所述会话密钥也可由管理网元根据预设的根密钥，对能网元的标识加密生成；或者所述控制网元从管理网元处获取所述会话密钥，所述会话密钥由所述管理网元根据推衍密钥对所述功能网元的标识加密生成；所述推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者所述推衍密钥为所述管理网元保存的所述功能网元的密钥。
第二方面，提供一种基于服务化架构的注册装置，该注册装置可应用于管理网元，应用于管理网元的注册装置具有实现上述第一方面以及第一方面任意设计中管理网元的功能，所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。所述模块可以是软件和/或硬件。
一种可能的设计中，应用于管理网元的注册装置包括处理单元和发送单元，还可包括接收单元，其中，接收单元、处理单元和发送单元可以和上述管理网元执行的各功能步骤相对应，在此不予赘述。
另一种可能的设计中，应用于管理网元的注册装置包括处理器，收发器和存储器。存储器与处理器耦合，用于存储各种软件程序和/或多组指令。处理器调用存储器的存储程序或指令执行上述管理网元执行的功能步骤，并控制收发器收发信号。
第三方面，提供一种基于服务化架构的注册装置，该注册装置可应用于功能网元，应用于功能网元的注册装置具有实现上述第一方面以及第一方面任意设计中功能网元的功能，所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。所述模块可以是软件和/或硬件。
一种可能的设计中，应用于功能网元的注册装置包括接收单元和发送单元，还可包括处理单元，其中，接收单元、处理单元和发送单元可以和上述功能网元执行的各功能步骤相对应，在此不予赘述。
另一种可能的设计中，应用于功能网元的注册装置包括处理器，收发器和存储器。存储器与处理器耦合，用于存储各种软件程序和/或多组指令。处理器调用存储器的存储程序或指令执行上述功能网元执行的功能步骤，并控制收发器收发信号。
第四方面，提供一种基于服务化架构的注册装置，该注册装置可应用于控制网元，应用于控制网元的注册装置具有实现上述第一方面以及第一方面任意设计中控制网元的功能，所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。所述模块可以是软件和/或硬件。
一种可能的设计中，应用于控制网元的注册装置包括接收单元和处理单元，还可包括发送单元，其中，接收单元、处理单元和发送单元可以和上述控制网元执行的各功能步骤相对应，在此不予赘述。
另一种可能的设计中，应用于控制网元的注册装置包括处理器，收发器和存储器。存储器与处理器耦合，用于存储各种软件程序和/或多组指令。处理器调用存储器的存储程序或指令执行上述控制网元执行的功能步骤，并控制收发器收发信号。
第五方面，提供计算机存储介质，所述计算机存储介质存储有计算机指令，当所述指令在计算机上运行时，可以完成第一方面以及第一方面任意可能设计中的管理网元、功能网元或控制网元所涉及的任意一种功能。
第六方面，提供一种计算机程序产品，所述计算机程序产品中包括有计算机程序，该 计算机程序用于执行完成第一方面以及第一方面任意可能设计中的管理网元、功能网元或控制网元所涉及的任意一种功能。
本申请实施例提供的基于服务化架构的注册方法及装置，管理网元接收功能网元发送的注册请求后，通过验证注册请求中包括的安全参数的正确性，可确定功能网元发送的注册请求的合法性。管理网元在确定功能网元发送的注册请求合法的情况下，将功能网元添加至功能网元拓扑中，在确定功能网元发送的注册请求不合法的情况下，拒绝将功能网元添加至功能网元拓扑中。故，通过本申请实施例提供的注册方法，可一定程度上提高通信安全性。
附图说明
图1为本申请实施例提供的注册方法所应用的服务化架构示意图；
图2为本申请实施例提供的基于服务化架构的注册方法实施流程图；
图3所示为本申请实施例一提供的基于服务化架构的安全注册实施流程图；
图4所示为本申请实施例二提供的基于服务化架构的安全注册实施流程图；
图5所示为本申请实施例三提供的基于服务化架构的安全注册实施流程图；
图6所示为本申请实施例四提供的基于服务化架构的安全注册实施流程图；
图7所示为本申请实施例五提供的基于服务化架构的安全注册实施流程图；
图8所示为本申请实施例六提供的基于服务化架构的安全注册实施流程图；
图9所示为本申请实施例七提供的基于服务化架构的安全注册实施流程图；
图10所示为本申请实施例八提供的基于服务化架构的安全注册实施流程图；
图11所示为本申请实施例九提供的基于服务化架构的安全注册实施流程图；
图12为本申请实施例提供的一种应用于管理网元的注册装置结构示意图；
图13为本申请实施例提供的另一种应用于管理网元的注册装置结构示意图；
图14为本申请实施例提供的一种应用于功能网元的注册装置结构示意图；
图15为本申请实施例提供的另一种应用于功能网元的注册装置结构示意图；
图16为本申请实施例提供的一种应用于控制网元的注册装置结构示意图；
图17为本申请实施例提供的另一种应用于控制网元的注册装置结构示意图。
具体实施方式
下面将结合附图，对本申请实施例中的技术方案进行描述。
本申请实施例提供的注册方法可应用于图1所示的服务化架构。图1中，核心网控制面的服务化架构中通过模块化实现NF间的解耦与整合，并且各NF之间采用服务化接口进行交互。例如图1中，网络开放功能(network exposure function，NEF)、NRF、策略控制功能(policy control function，PCF)、统一数据管理(unified data management，UDM)、应用功能(application function，AF)、鉴权服务器功能(authentication server function，AUSF)、接入与移动性管理功能(access and mobility management function，AMF)、会话管理功能(session management function，SMF)等各NF可通过NEF服务化接口(service-based interface exhibited by NEF，Nnef)、AUSF服务化接口(service-based interface exhibited by AUSF，Nausf)、NRF服务化接口(service-based interface exhibited by NRF，Nnrf)、AMF服务化接口(service-based interface exhibited by AMF，Namf)、PCF服务化接口(service-based interface exhibited by PCF，Npcf)、SMF服务化接口(service-based interface exhibited by  SMF，Nsmf)、UDM服务化接口(service-based interface exhibited by UDM，Nudm)和AF服务化接口(service-based interface exhibited by AF，Naf)等服务化接口进行交互，并且同一种服务可被多种NF调用，降低了NF之间接口定义的耦合度，实现NF的按需定制。图1中，用户设备(user equipment，UE)可通过无线接入网络(Radio Access Network，RAN)接入核心网的AMF，也可直接接入AMF，其中，UE与AMF之间的接口为N1接口，RAN与AMF之间的接口为N2接口。RAN可通过N3接口与用户面功能(user plan function，UPF)交互。UPF可通过N4接口接入核心网的SMF，并与核心网进行交互，UPF也可通过N6接口接入与数据网络(data network，DN)，与DN进行交互。
其中，图1所示的各网元名称以及接口定义都是引用自第五代(5G)以及第三代移动通信标准化组织(3rd Generation Partnership Project，3GPP)草案中的定义，图示中仅是简单说明各个网络功能实体之间的接口定义，其中，方框代表具体的NF定义，连线代表接口定义，具体的定义可参阅5G 3GPP草案中的相关定义。
在上述服务化架构中，若需要新增功能网元，可采用如下两种方式：一种实施方式中，由具备网元管理和注册功能的管理网元，向具有存储注册信息功能的控制网元发送注册请求，在该注册请求中包括新增功能网元的配置信息。控制网元接收到注册请求后完成注册，将注册完成的功能网元添加至NF拓扑中，并发送响应消息至管理网元。另一种实施方式中，由管理网元向待注册的功能网元配置相应参数，之后待注册的功能网元直接向控制网元发送注册请求，控制网元接收到该注册请求后直接完成注册。NRF将注册完成的功能网元添加至NF拓扑中，并发送响应消息至该注册完成的功能网元。
随着未来5G通信业务的迅速发展，可能会存在海量的功能网元需要新增，上述第一种实施方式中，管理网元需要向控制网元和新增的功能网元发送配置信息，故上述第一种实施方式可能不再适用未来5G通信业务。在未来5G通信业务中可采用第二种实施方式实现新增功能网元的注册。然而，在第二种实施方式中，虽然管理网元不需要向控制网元发送配置信息，由新增的功能网元直接向控制网元发送注册请求，但是新增的功能网元与控制网元之间的通信接口并不受安全信道的保护，可能攻击者修改参数，或者攻击者扮演待注册的功能网元的角色尝试接入控制网元的风险，通信安全性较低。
有鉴于此，本申请实施例提供一种基于服务化架构的安全注册方法，在该注册方法中，控制网元与功能网元之间进行安全认证，以提高通信安全性。
可以理解的是，本申请实施例中涉及的管理网元可以是任何具备网元管理和控制功能的功能实体，例如运行管理维护网元(operation administration and maintenance，OAM)或者切片管理网元(Slice manager)等实体，也可以为终端、基站、控制器或服务器等实体，本申请实施例不做限制，为描述方便，后续以管理网元为OAM为例进行描述。本申请实施例涉及的控制网元可以是任何具备存储注册信息并对网元进行控制功能的功能实体，例如可以是NRF，也可以为终端、基站、控制器或服务器等实体本申请实施例不做限制，为描述方便，后续以控制网元为NRF为例进行描述。本申请实施例中涉及的功能网元是具有一定功能的实体，例如可以是NF，也可以为终端、基站、控制器或服务器等实体本申请实施例不做限制，为描述方便，后续以功能网元为NF为例进行描述。
图2所示为本申请实施例提供的一种基于服务化架构进行注册的方法实施流程图，参阅图2所示，包括：
S101：OAM确定NF的配置信息，所述配置信息中包括安全参数。OAM将确定的 包含有安全参数的配置信息发送给NF。
S102：NF获取到OAM发送的配置信息，向NRF发送注册请求，该注册请求中包括安全参数，以及NF的配置信息。
S103：NRF接收NF发送的注册请求，并验证注册请求中包括的安全参数的正确性，通过验证的安全参数的正确性确定NF发送的注册请求是否合法。
本申请实施例中，OAM在向NF发送的配置信息中包括安全参数，NF将该安全参数携带在注册请求中发送给NRF。NRF收到该注册请求后，通过验证注册请求中包括的安全参数的正确性，可确定NF发送的注册请求的合法性。NRF在确定NF发送的注册请求合法的情况下，将NF添加至NF拓扑中，在确定NF发送的注册请求不合法的情况下，拒绝将NF添加至NF拓扑中。故，通过本申请实施例提供的注册方法，可一定程度上提高通信安全性。
本申请实施例中上述及的安全参数可以是令牌(token)，也可以是数字签名(Signature)，还可以是消息认证码(message Authentication code，MAC)。其中，不同的安全参数有不同的生成方法，并且安全参数验证的过程也不同。
本申请实施例以下将结合实际应用对安全参数的生成以及验证过程进行说明。
实施例一：安全参数包括token，token基于非对称密钥生成。
图3所示为本申请实施例一提供的基于服务化架构的安全注册实施流程图，参阅图3所示，包括：
S201a：OAM生成非对称token。
本申请实施例中，OAM可基于NRF的公钥(PKnrf)生成非对称token。
其中，OAM生成非对称token，需要OAM预先保存OAM的公钥(PKoam)，OAM的私钥(SKoam)以及NRF的公钥(PKnrf)。其中，PKnrf可以是初始预先设置在OAM中的，也可以是OAM与NRF进行交互过程中，从NRF处获取得到的。NRF也需要预先保存Pkoam，PKnrf以及NRF的私钥(SKnrf)。其中，Pkoam可以是初始预先设置在NRF中的，也可以是OAM与NRF进行交互过程中，OAM发送至NRF的。
具体的，OAM可基于PKoam，对数字签名、NF资料(NF profile)、以及NF的标识(ID_NF)进行加密，以生成非对称token。
其中，所述数字签名可由OAM基于SKoam，对NF profile、以及ID_NF执行数字签名算法生成。
一种可能的实施方式中，OAM基于PKoam进行加密的参数，除包括数字签名、NF profile、ID_NF以外，还可包括NRF的标识(ID_NRF)，NF类型(NF type)，公共陆地移动网络标识(Public Land Mobile Network ID，PLMN ID)，NF支持的业务标识，数字签名随机数(nonce_sign)等中的一项或多项，以及有效期(time)，token随机数(nonce_token)，计数器和序列号中的至少一项。
具体的，上述生成非对称token过程中所使用的各参数中，NF profile为可选的参数,ID_NRF为可选的参数，NF type为可选的参数，PLMN ID为可选的参数，NF支持业务标识可选。Nonce_token，Nonce_sign为OAM随机选择，两个nonce可以相同也可以不同，并且都是可选的参数。其中，time可以为密钥的有效期，具体形式可以为包含开始时间和结束时间，或者为开始时间和有效的时间，或者为结束时间。非漫游场景下，PLMN ID可包括NF归属网络的PLMN ID。漫游场景下，NF处于拜访网络，但NF的信息保存在归属网络，故PLMN ID可包括归属网络的PLMN ID和拜访网络的PLMN ID的至少一项。
一种可能的实施方式中，OAM生成数字签名时，基于SKoam执行数字签名算法的参数，除包括NF profile、ID_NF以外，还包括ID_NRF，NF type，PLMN ID，NF支持的业务标识等中的一项或多项，以及time，nonce_sign，计数器和序列号中的至少一项。换言之，被签名的内容中可包括NF profile、ID_NF，还可包括ID_NRF，NF type，PLMN ID，NF支持的业务标识，time，nonce_sign，计数器和序列号等。其中，被签名的内容中，NF profile为可选的参数，NF type为可选的参数，PLMN ID为可选的参数，NF支持的业务标识为可选的参数。
S201b：OAM确定会话密钥(K_session)。
本申请实施例中NF和NRF之间可共享K_session，该K_session可用于NF与NRF之间的安全通信或认证。当然，K_session的确定为可选的参数步骤，在不需要使用K_session进行安全通信或认证时，则可不包含该确定K_session的步骤。
本申请实施例中，若OAM生成K_session，则可将K_session作为NF和NRF之间的共享密钥，上述生成非对称token的过程中，基于PKoam除对上述涉及的参数进行加密以外，还可对该K_session进行加密。同时除对上述涉及的参数进行签名以外，还可对该K_session进行签名。
本申请实施例中，一种可能的实施方式中，K_session可以是OAM随机选择的，也可以是OAM根据预设的根密钥，对ID_NF推衍生成的。OAM也可根据预设的根密钥，对ID_NF，ID_NRF，NF profile，NF type，PLMN ID和NF支持的业务标识中的一项或多项进行推衍生成K_session。OAM除对上述参数进行加密以外，还可对time，会话密钥随机数(nonce_session)，计数器和序列号中的至少一项进行推衍生成K_session。另一种可能的实施方式中，K_session可以是OAM根据推衍密钥，对ID_NF推衍生成的。OAM也可根据推衍密钥，对ID_NF，ID_NRF，NF profile，NF type，PLMN ID和NF支持的业务标识中的一项或多项进行加密生成K_session。OAM除对上述参数进行推衍以外，还可对time，会话密钥随机数(nonce_session)，计数器和序列号中的至少一项进行推衍生成K_session。其中，生成K_session所用的推衍密钥，可以是OAM对预设的根密钥进行密钥推衍得到，也可以是由OAM保存的由OAM保存的NF的密钥。另外，K_session也可以为OAM随机选择的参数。
本申请实施例中生成K_session所用参数中，ID_NRF为可选的参数，NF profile为可选的参数，NF type为可选的参数，PLMN ID为可选的参数，NF支持的业务标识可选，(time，nonce_session，计数器和序列号为至少一项)为可选的参数，其中，nonce_session为OAM随机选择的。
S202：OAM确定配置信息，并向NF发送配置信息，该配置信息中包括上述生成的非对称token。
本申请实施例中OAM确定并向NF发送的配置信息中还可能包括ID_NF和token，进一步的也有可能还包括K_Session、ID_NRF，NF profile，NF type等中的至少一项。
S203：NF接收OAM发送的配置信息，基于该配置信息向NRF发送注册请求，其中，该注册请求中包括有配置信息中包括的非对称token，也可能包括ID_NF、ID_NRF、NF profile、NF type等中的至少一项。
S204：NRF接收NF发送的注册请求，并验证注册请求中包括的非对称token的正确性。
具体的，NRF可利用SKnrf解密注册请求中包括的非对称token，得到数字签名，并利用Pkoam和被签名的内容，验证数字签名的正确性。若数字签名验证成功，则NRF确定NF发送的非对称token正确，NF发送的注册请求合法，NF被OAM授权，则NRF依据NF发送的注册请求，将NF加入到NF拓扑中，并保存NF的注册信息。若数字签名验证不成功，则NRF确定NF发送的非对称token不正确，NF发送的注册请求不合法，NF未被OAM授权，则NRF拒绝NF的注册请求。
S205：NRF发送注册响应至NF，以通知NF是否被注册成功。
一种可能的示例中，若NRF利用SKnrf解密注册请求中包括的非对称token，还可得到K_Session，则NF与NRF之间共享K_Session。NRF可利用K_Session执行如下S206的步骤，其中，S206为可选步骤：
S206：NRF确定NF发送的注册请求合法的情况下，基于K_session或者K_session推衍后的密钥，与NF建立安全通道。
其中，K_session推衍后的密钥，可以通过对K_session，隧道建立计数器和会话ID中至少一项执行密钥推衍算法得到。
本申请上述实施例中，OAM在向NF发送的配置信息中包括非对称token，非对称token由OAM基于PKnrf生成。NF将该非对称token携带在注册请求中发送给NRF。NRF收到该注册请求后，通过验证注册请求中包括的非对称token的正确性，可确定NF发送的注册请求的合法性，实现对NF的认证。
进一步的，NF与NRF之间可共享K_session，并利用该共享的K_session，进行NF与NRF之间的安全通信或认证。
实施例二：安全参数包括token，token基于对称密钥生成。
图4所示为本申请实施例二提供的安全注册方法实施流程图。图4所示的安全注册方法实施流程图与图3所示的安全注册方法实施流程类似，不同之处仅在于token的计算方式不同，以下仅就不同之处进行说明，对于相同或相似之处可参阅上述实施例一的描述。
S301a：OAM生成对称token。
本申请实施例中，OAM可基于OAM与NRF之间共享的对称密钥(k)，生成对称token。
其中，OAM基于OAM与NRF之间共享的对称密钥(k)生成对称token情况下，需要OAM与NRF二者各自分别预先保存该对称密钥。
具体的，OAM可基于OAM与NRF之间共享的对称密钥(k)，对MAC、NF profile、ID_NF加密生成。其中，MAC可由OAM基于OAM与NRF之间共享的对称密钥(k)，对所述ID_NF以及NF profile执行消息认证码的算法生成。
一种可能的示例中，OAM基于OAM与NRF之间共享的对称密钥(k)，进行加密的参数除包括MAC、NF profile、ID_NF以外，还可包括ID_NRF，NF type，PLMN ID，NF支持的业务标识等中的一项或多项，以及time，nonce_token，计数器和序列号中的至少一项。
类似的，OAM生成MAC时，基于OAM与NRF之间共享的对称密钥(k)，执行消息认证码算法的参数除包括所述ID_NF以及NF profile以外，还可包括ID_NRF，NF type，PLMN ID，NF支持的业务标识等中的一项或多项，以及time，MAC随机数(nonce_mac)，计数器和序列号中的至少一项。换言之，被MAC保护的内容可包括NF  profile、ID_NF、以及NF和NRF之间的共享密钥，还可包括ID_NRF，NF type，PLMN ID，NF支持的业务标识，time，nonce_mac，计数器和序列号等。其中，被MAC保护的内容中，ID_NRF为可选的参数，NF profile为可选的参数，NF type为可选的参数，PLMN ID为可选的参数，NF支持的业务标识为可选的参数。
S301b：OAM生成K_session。
本申请实施例中OAM生成K_session的步骤为可选步骤，具体生成K_session的过程可参阅上述实施例一中的相关描述在此不再赘述。
本申请实施例中，若OAM生成K_session，可将K_session作为NF和NRF之间的共享密钥，则上述生成对称token的过程中，OAM基于OAM与NRF之间共享的对称密钥(k)除对上述涉及的参数进行加密以外，还可对该K_session进行加密。同时除对上述涉及的参数执行消息认证码算法以外，还可对该K_session执行消息认证码算法。
S302：OAM确定配置信息，并向NF发送配置信息，该配置信息中包括上述生成的对称token。
本申请实施例中OAM确定并向NF发送的配置信息中还可能包括ID_NF和token，进一步的也有可能同时包括ID_NRF，K_Session，NF profile，NF type等中的至少一项。
S303：NF接收OAM发送的配置信息，基于该配置信息向NRF发送注册请求，其中，该注册请求中包括有配置信息中包括的对称token，也可能包括ID_NF、ID_NRF、NF profile、NF type等中的至少一项。
S304：NRF接收NF发送的注册请求，并验证注册请求中包括的对称token的正确性。
具体的，NRF可OAM与NRF之间共享的对称密钥(k)解密注册请求中包括的对称token，以得到MAC，然后利用OAM与NRF之间共享的对称密钥(k)，以及被MAC保护的内容，验证MAC的正确性。若NRF验证MAC正确，则NRF确定NF发送的对称token正确，NF发送的注册请求合法，NF被OAM授权，则NRF依据NF发送的注册请求，将NF加入到NF拓扑中，并保存NF的注册信息。若NRF验证MAC不正确，则NRF确定NF发送的对称token不正确，NF发送的注册请求不合法，NF未被OAM授权，则NRF拒绝NF的注册请求。
一种可能的示例中，若NRF利用k解密注册请求中包括的对称token，还可得到K_Session，则NF与NRF之间共享K_Session。
S305以及S306的执行步骤与上述实施例一中涉及的S205和S206的执行步骤类似，在此不再赘述。
本申请上述实施例中，OAM基于OAM与NRF之间共享的对称密钥(k)生成对称token，OAM在向NF发送的配置信息中包括对称token，NF将该对称token携带在注册请求中发送给NRF。NRF收到该注册请求后，通过验证注册请求中包括的对称token的正确性，可确定NF发送的注册请求的合法性，实现对NF的认证。
进一步的，NF与NRF之间可共享K_session，并利用该共享的K_session，进行NF与NRF之间的安全通信或认证。
实施例三：安全参数包括MAC。
图5所示为本申请实施例三提供的安全注册方法实施流程图。图5所示的安全注册方法实施流程图与图4所示的安全注册方法实施流程类似，不同之处仅在于OAM生成的安全参数为MAC，无需生成token，并且NRF只验证MAC，无需验证token。 以下仅就不同之处进行说明，对于相同或相似之处可参阅上述实施例二的相关描述。
S401：OAM生成MAC。
本申请实施例中，OAM可基于OAM与NRF之间共享的对称密钥(k)，生成MAC。
其中，OAM基于OAM与NRF之间共享的对称密钥(k)生成MAC情况下，需要OAM与NRF二者各自分别预先保存该对称密钥。
具体的，本申请实施例中，OAM可基于OAM与NRF之间共享的对称密钥(k)，对ID_NF执行消息认证码算法，以生成MAC。
一种可能的实施方式中，OAM生成MAC时，执行消息认证码算法的参数除包括ID_NF以外，还可包括NF profile，ID_NRF，NF type，PLMN ID，NF支持的业务标识等中的一项或多项，以及time，MAC随机数(nonce_mac)，计数器和序列号中的至少一项。换言之，被MAC保护的内容可包括ID_NF，还可包括NF profile，ID_NRF，NF type，PLMN ID，NF支持的业务标识，time，nonce_mac，计数器和序列号等。其中，被MAC保护的内容中，ID_NRF为可选的参数，NF profile为可选的参数，NF type为可选的参数，PLMN ID为可选的参数，NF支持的业务标识为可选的参数。
S402：OAM确定配置信息，并向NF发送配置信息，该配置信息中包括上述生成的MAC。
本申请实施例中配置信息中除包括MAC以外，还包括生成MAC时所用的ID_NF。若生成MAC中包括有NF profile，ID_NRF，NF type，PLMN ID，NF支持的业务标识，time，nonce_mac，计数器和序列号等其它可选的参数，则在该配置信息中可相应包括生成MAC时所用的参数。例如生成MAC时所用参数除了包含ID_NF以外还包含有ID_NRF，则在OAM向NF发送的配置信息中包括MAC、ID_NF以及ID_NRF。其中，ID_NRF可以是NRF的身份标识信息，也可以是NRF的地址信息。
进一步的，若生成MAC所用的参数不是OAM与NRF共享的，则必须发送该共享的参数，例如time或者nonce_mac，又或者非共享的计数器或者序列号。
进一步的，若生成MAC所用的参数为OAM与NRF共享，则无需发送该共享的参数，例如OAM与NRF共享计数器和/或序列号，且生成MAC时包含有计数器和/或序列号，则配置参数中无需包含计数器和/或序列号。
S403：NF接收OAM发送的配置信息，基于该配置信息向NRF发送注册请求，其中，该注册请求中包括有配置信息中包括的参数信息，例如包括MAC和ID_NF，也可能还包括ID_NRF、NF profile、NF type、PLMN ID，NF支持的业务标识等中的至少一项。进一步的，用于计算MAC，并且OAM与NRF非共享的参数，都需要发送至NRF，例如接收到的time，nonce_mac，计数器或者序列号等也需要发送至NRF。
S404：NRF接收NF发送的注册请求，并验证注册请求中包括的MAC的正确性。
具体的，NRF可利用OAM与NRF之间共享的对称密钥(k)，以及被MAC保护的内容，验证MAC的正确性。若NRF验证MAC正确，则NRF确定NF发送的注册请求合法，NF被OAM授权，则NRF依据NF发送的注册请求，将NF加入到NF拓扑中，并保存NF的注册信息。若NRF验证MAC不正确，则NRF确定NF发送的注册请求不合法，NF未被OAM授权，则NRF拒绝NF的注册请求。
S405：NRF发送注册响应至NF，以通知NF是否被注册成功。
本申请实施例三中，OAM基于OAM与NRF之间共享的对称密钥(k)生成MAC， OAM在向NF发送的配置信息中包括MAC，NF将该MAC携带在注册请求中发送给NRF。NRF收到该注册请求后，通过验证注册请求中包括的MAC的正确性，可确定NF发送的注册请求的合法性，并实现对NF的认证。
本申请实施例三中实现了NRF对NF的认证，在一种可能的实施例中，也可实现NF对NRF的认证，即实现NF与NRF的双向认证。本申请实施例中以下将结合实施例四和实施例五对NF与NRF实现双向认证的过程进行说明。
实施例四：基于MAC实现NF与NRF的双向认证。
图6所示为本申请实施例四提供的安全注册方法实施流程图。图6所示的安全注册方法中可在实施例四中涉及的安全注册方法基础上，由NRF和OAM分别再生成一个MAC，通过比较OAM生成的MAC与NRF生成的MAC是否一致，实现NF与NRF的双向认证。
本申请实施例中为描述方便，将实施例三中OAM生成的MAC称为第一MAC，将本申请实施例四中NRF生成的MAC称为第二MAC，将本申请实施例中OAM生成的MAC称为第三MAC。
图6中S501、S502、S503和S504的执行步骤与上述图5中的S401、S402、S403和404的执行步骤类似，不同之处在于S501中OAM除生成第一MAC以外还生成第三MAC。本申请实施例中对于与实施例三相同之处，在此不再赘述，以下仅就不同之处进行说明：
S501：OAM生成第一MAC和第三MAC。
其中，OAM可基于OAM与NRF之间共享的对称密钥(k)生成第三MAC。
具体的，本申请实施例中，OAM可基于OAM与NRF之间共享的对称密钥(k)，对ID_NF、以及ID_NRF执行消息认证码算法，以生成第三MAC。
一种可能的实施方式中OAM生成第三MAC时，基于OAM与NRF之间共享的对称密钥(k)，执行消息认证码算法的参数除包括ID_NF、以及ID_NRF以外，还可包括NF profile，NF type，PLMN ID，NF支持的业务标识等中的一项或多项，以及time，MAC3随机数(nonce_mac3)，计数器和序列号中的至少一项。换言之，被第三MAC保护的内容可包括ID_NF和ID_NRF，还可包括NF profile，NF type，PLMN ID，NF支持的业务标识，time，nonce_mac3，计数器和序列号等。其中，被第三MAC保护的内容中，NF profile为可选的参数，NF type为可选的参数，PLMN ID为可选的参数，NF支持的业务标识为可选的参数。
S502：OAM确定配置信息，并向NF发送配置信息，该配置信息中包括上述生成的第一MAC和第三MAC。
S503和S504的执行步骤与S403和S404的执行步骤相同。
进一步的，若生成第三MAC中采用了OAM与NRF非共享的参数，都需要发送至NRF，例如接收到的time，nonce_mac3，计数器或者序列号等至少一项也需要通过NF发送至NRF。
S505：NRF生成第二MAC。
本申请实施例中，NRF可基于OAM与NRF之间共享的对称密钥(k)生成第二MAC。
具体的，本申请实施例中，NRF可基于OAM与NRF之间共享的对称密钥(k)，对ID_NF、以及ID_NRF执行消息认证码算法，以生成第二MAC。
本申请实施例中NRF生成的第二MAC过程中所涉及的参数，与OAM生成第三 MAC中涉及到的参数相同，在此不再赘述。
S506：NRF向NF发送第二MAC，其中，该第二MAC可通过NRF向NF发送的注册响应发送。
S507：NF接收NRF发送的第二MAC，并比较第二MAC与第三MAC是否一致，并根据比较结果确定第二MAC的合法性。
本申请实施例中，若第二MAC与第三MAC一致，则NF确定第二MAC合法，确认NRF认证通过。
本申请实施例中NRF通过验证第一MAC，实现对NF的认证，NF通过比较第二MAC与第三MAC是否一致，实现对NRF的认证，进而实现了NF与NRF的相互认证。
实施例五：基于MAC，NF与NRF实现双向认证。
图7所示为本申请实施例五提供的安全注册方法实施流程图。图7中S601、S603、S604、S605和S606的执行步骤与上述图6中的S501、S503、S504、S505和S506的执行步骤相同。图7中S602的执行步骤与图5中的S402的执行步骤相同。
S607：NF接收NRF发送的第二MAC，并向OAM发送该第二MAC。
S608：OAM接收NF发送的第二MAC，并比较第二MAC与第三MAC是否一致，并根据比较结果确定第二MAC的验证结果。
本申请实施例中，若第二MAC与第三MAC一致，则NF确定第二MAC合法，确认NRF认证通过。
S609：OAM向NF发送第二MAC的验证结果，NF根据从OAM接收的第二MAC的验证结果，确定第二MAC的合法性。
本申请实施例中NRF通过验证第一MAC，实现对NF的认证，NF通过从OAM接收的第二MAC的验证结果，确定第二MAC的合法性，实现对NRF的认证，进而实现了NF与NRF的相互认证。
实施例六：安全参数包括数字签名。
图8所示为本申请实施例六提供的安全注册方法实施流程图。图8所示的安全注册方法实施流程图与图5所示的安全注册方法实施流程类似，不同之处仅在于OAM生成的安全参数为数字签名，而不是MAC。以下仅就不同之处进行说明，对于相同或相似之处可参阅上述实施例三的相关描述。
S701：OAM生成数字签名。
本申请实施例中OAM可基于SKoam，生成数字签名。
其中，OAM基于SKoam生成数字签名的情况下，OAM需要预先保存PKoam和SKoam，NRF也需要预先保存PKoam。其中，Pkoam可以是初始预先设置在NRF中的，也可以是OAM与NRF进行交互过程中，OAM发送至NRF的。
具体的，本申请实施例中OAM可基于SKoam生成数字签名过程中，执行数字签名算法中涉及的参数(被签名的内容)与上述实施例三中涉及的生成MAC过程中执行消息认证码算法涉及的参数(被MAC保护的内容)类似，不同之处仅在于执行数字签名过程中用的随机数为数字签名的随机数，对于相同之处，在此不再赘述。
S702：OAM确定配置信息，并向NF发送配置信息，该配置信息中包括上述生成的数字签名。
进一步的，若生成数字签名中采用了OAM与NRF非共享的参数，都需要发送至NRF， 例如接收到的time，nonce_sign，计数器或者序列号等至少一项也需要通过NF发送至NRF。
S703：NF接收OAM发送的配置信息，基于该配置信息向NRF发送注册请求，该注册请求中包括OAM生成并发送给NF的数字签名。
S704：NRF接收NF发送的注册请求，并验证注册请求中包括的数字签名的正确性。
具体的，NRF可利用预先保存的Pkoam，以及被签名的内容，验证数字签名的正确性。若NRF确定NF发送的数字签名正确，则NF发送的注册请求合法，NF被OAM授权，则NRF依据NF发送的注册请求，将NF加入到NF拓扑中，并保存NF的注册信息。若NRF确定NF发送的数字签名不正确，则NF发送的注册请求不合法，NF未被OAM授权，则NRF拒绝NF的注册请求。
S705：NRF发送注册响应至NF，以通知NF是否被注册成功。
本申请实施例六中，OAM基于SKoam生成数字签名，OAM在向NF发送的配置信息中包括数字签名，NF将该数字签名携带在注册请求中发送给NRF。NRF收到该注册请求后，通过验证注册请求中包括的数字签名的正确性，可确定NF发送的注册请求的合法性，并实现对NF的认证。
本申请实施例六中实现了NRF基于数字签名对NF的认证，在一种可能的实施例中，也可基于数字签名实现NF对NRF的认证，即基于数字签名实现NF与NRF的双向认证。本申请实施例中以下将结合实施例七对NF与NRF基于数字签名实现双向认证的过程进行说明。
实施例七：NF与NRF基于数字签名进行双向认证。
本申请实施例中为实现NF与NRF基于数字签名进行双向认证，可在实施例六涉及的安全注册方法基础上，由NRF再生成一个数字签名，NF通过验证NRF生成的数字签名，实现NF对NRF的认证。具体生成数字签名的参数与图7对应实施例中S605计算MAC的参数一致。
本申请实施例中为描述方便，可将实施例六中OAM生成的数字签名称为第一数字签名，将本实施例七中NRF生成的数字签名称为第二数字签名。
图9所示为本申请实施例七提供的安全注册方法实施流程图。图9所示的安全注册方法实施流程中涉及的S801、S802以及S803的执行步骤与图8所示的安全注册方法实施流程中涉及的S701、S702以及S703的执行步骤类似，仅需要将图8中涉及的数字签名替换为第一数字签名即可，故相同之处在此不再赘述，以下仅就不同之处进行说明：
S804：NRF生成第二数字签名。
本申请实施例中NRF可基于SKnrf生成第二数字签名。
具体的，本申请实施例中NRF基于SKnrf生成第二数字签名过程中，执行数字签名算法中涉及的参数(被签名的内容)与上述实施例四中涉及的生成第二MAC过程中执行消息认证码算法涉及的参数(被第二MAC保护的内容)类似，不同之处仅在于执行数字签名过程中用的随机数为数字签名的随机数，对于相同之处，在此不再赘述。
S805：NRF向NF发送第二数字签名，该第二数字签名可通过NRF向NF发送的注册响应发送。
S806：NF验证NRF发送的第二数字签名。
具体的，NF可通过预先保存的PKnrf验证第二数字签名的正确性，其中该PKnrf可以是初始预先设置在NF中的，也可以是NF与NRF进行交互过程中，从NRF处获取得到的。
本申请实施例中，NF可利用PKnrf和被第二数字签名所签名的内容，验证第二数字签名的正确性。若第二数字签名验证正确，NR验证NRF合法。若第二数字签名验证不正确，则NR验证NRF不合法。
本申请实施例中NRF通过验证第一数字签名，实现对NF的认证，NF通过验证第二数字签名，实现对NRF的认证，进而实现了基于数字签名的NF与NRF的相互认证。
实施例八：安全参数包括NF生成的MAC，由NRF验证NF生成的MAC的正确性。
图10所示为本申请实施例八提供的安全注册方法实施流程图，参阅图10所示，包括：
S901：OAM确定NF的配置信息，并向NF发送该确定的配置信息，所述配置信息中包括推衍密钥(K_NF)。
本申请实施例中，OAM可对预设的根密钥进行密钥推衍得到推衍密钥(K_NF)，或者OAM保存有预配置的推衍密钥(K_NF)。
具体的，OAM可对预设的根密钥、ID_NF以及PLMN ID执行密钥推衍算法，得到给推衍密钥(K_NF)。
S902：NF接收OAM发送的配置信息，并利用配置信息中包括的推衍密钥(K_NF)，生成MAC。
本申请实施例中为描述方便，将NF根据推衍密钥(K_NF)生成的消息认证码，称为第四MAC。
本申请实施例中，NF基于推衍密钥(K_NF)生成的第四MAC，与OAM生成的第一MAC相似，不同之处仅在于NF是基于推衍密钥(K_NF)生成的，而OAM是基于OAM与NRF之间共享的对称密钥(k)生成的。对于NF基于推衍密钥(K_NF)生成第四MAC中涉及执行消息认证码算法的参数可参阅OAM基于OAM与NRF之间共享的对称密钥(k)生成第一MAC中执行消息认证码算法所涉及的参数，在此不再赘述。
S903：NF向NRF发送注册请求，该注册请求中包括上述生成的第四MAC和ID_NF。当然该注册请求中还可包括除ID_NF以外的其它配置信息。
S904：NRF向OAM发送ID_NF。
其中，NRF还可向OAM发送第四MAC的有效期(time)、nonce_mac4等信息，以查询OAM中保存的NF的MAC信息。
S905：OAM接收NRF发送的ID_NF，并基于预先保存的推衍密钥(K_NF)，对ID_NF执行消息认证码算法，得到用于NRF认证NF的MAC。
本申请实施例中为描述方便，将OAM基于推衍密钥(K_NF)生成的MAC，称为第五MAC。
本申请实施例中，OAM基于推衍密钥(K_NF)生成第五MAC的执行过程，可与OAM基于OAM与NRF之间共享的对称密钥(k)生成第三MAC的执行过程类似，不同之处仅在于，第五MAC是基于推衍密钥(K_NF)生成的，而第三MAC是基于OAM与NRF之间共享的对称密钥(k)生成的。本申请实施例中对于OAM基于推衍密钥(K_NF)生成第五MAC中涉及执行消息认证码算法的参数可参阅OAM基于OAM与NRF之间共享的对称密钥(k)生成第三MAC中执行消息认证码算法所涉及的参数，在此不再赘述。
一种可能的示例中，若NF与NRF之间共享用于NF与NRF之间的安全通信或认证的K_session，则OAM还可基于推衍密钥(K_NF)生成K_session。
S906：OAM向NRF发送第五MAC。
其中，若OAM基于推衍密钥(K_NF)生成K_session，则将该生成的K_session也发送给NRF。
S907：NRF接收OAM发送的第五MAC，并比较第四MAC与第五MAC是否一致，以验证第四MAC的正确性，并基于第四MAC的正确性，确认NF发送的注册请求的合法性。
本申请实施例中，若第四MAC与第五MAC一致，则NF确定第四MAC正确，确认NF发送的注册请求合法，确认NF认证通过。
S908：NRF向NF发送认证响应，以通知NF是否认证通过。
一种可能的示例中，若OAM基于推衍密钥(K_NF)生成K_session，NRF可利用K_Session执行如下S909的步骤：
S909：NRF确定NF发送的注册请求合法的情况下，基于K_session或者K_session推衍后的密钥，与NF建立安全通道。
本申请实施例八中，NF生成第四MAC并发送给NRF，NRF通过查询的方式，从OAM获取到第五MAC，通过比较第四MAC与第五MAC是否一致，实现对NF的认证。
本申请实施例中，NRF接收到NF发送的第四MAC后，可将第四MAC发送给OAM，由OAM验证第四MAC的正确性，NRF可基于OAM发送的第四MAC的验证结果，确认NF发送的注册请求的合法性，具体实施过程可参阅实施例九。
实施例九：安全参数包括NF生成的MAC，由OAM验证NF生成的MAC的正确性。
图11所示为本申请实施例九提供的安全注册方法实施流程图。图11所示的安全注册方法流程图中，S1001、S1002、S1003、S1008和S1009的执行步骤与上述图10中的S901、S902、S903、S908和S909的执行步骤相同，在此不再赘述，以下仅就不同之处进行说明：
S1004：NRF向OAM发送ID_NF以及第四MAC。
S1005：OAM接收NRF发送的ID_NF以及第四MAC，并基于预先保存的推衍密钥(K_NF)生成第五MAC。
一种可能的示例中，若NF与NRF之间共享用于NF与NRF之间的安全通信或认证的K_session，则OAM还可基于推衍密钥(K_NF)生成K_session。
S1006：OAM比较第四MAC与第五MAC是否一致，以验证第四MAC的正确性，并向NRF发送第四MAC的验证结果。
本申请实施例中，若第四MAC与第五MAC一致，则NF确定第四MAC正确，确认NF发送的注册请求合法，确认NF认证通过。
S1007：NRF接收OAM发送的第四MAC的验证结果，以确认第四MAC的正确性，并确认NF发送的注册请求的合法性。
一种可能的示例中，若OAM基于推衍密钥(K_NF)生成K_session，则将该K_session发送给NRF。
本申请实施例九中，NF生成第四MAC并发送给NRF，NRF向OAM发送该第四MAC。OAM生成第五MAC，通过比较第四MAC与第五MAC是否一致，验证第四MAC的正确性，并将第四MAC的验证结果发送给NRF，NRF基于第四MAC的验证结果，确认NF发送的注册请求的合法性，实现对NF的认证。
本申请实施例中，针对上述采用MAC和签名做验证的实施例，还包括基于DH (Diffie-Hellman)密钥协商生成K_session的可能性，即OAM生成DH密钥协商的公钥PK_DH_OAM和私钥SK_DH_OAM，采用MAC或者签名对PK_DH_OAM做保护，另外OAM将PK_DH_OAM和SK_DH_OAM发送至NF。NF在之前实施例中发送注册请求的基础上，另外发送PK_DH_OAM至NRF。NRF验证MAC或签名成功后，生成DH密钥协商的公钥PK_DH_NRF和私钥SK_DH_NRF。并基于PK_DH_OAM和SK_DH_NRF生成K_session。NRF发送PK_DH_NRF至NF。此时NF可以基于PK_DH_NRF和SK_DH_OAM生成K_session。所述参数的格式和计算K_session的方式与经典DH密钥协商流程类似。DH密钥协议不做限制，包括但不限于离散对数等等。
本申请实施例中，针对上述所有非对称技术的实施例，仍旧可以用基于身份技术实现。基于身份技术与基于证书非对称安全技术中的不同点在于，公钥PK可以为ID，即用户身份。
上述主要从管理网元、功能网元和控制网元交互的角度对本申请实施例提供的方案进行了介绍。可以理解的是，管理网元、功能网元和控制网元为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。结合本申请中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同的方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的技术方案的范围。
本申请实施例可以根据上述方法示例对管理网元、功能网元和控制网元进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
在采用软件功能单元的形式实现时，图12示出了本申请实施例提供的一种基于服务化架构的注册装置100的结构示意图。其中，基于服务化架构的注册装置100可应用于管理网元，参阅图12所示，应用于管理网元的注册装置100可包括处理单元101和发送单元102。其中，处理单元101用于确定功能网元的配置信息，以及生成安全参数。发送单元102用于向功能网元发送处理单元101确定的配置信息，在发送的配置信息中包括生成的安全参数。
一种可能的实施方式中，处理单元101可管理网元的私钥，对功能网元资料、功能网元的标识执行数字签名算法生成数字签名，并基于控制网元的公钥，对数字签名、功能网元资料、功能网元的标识加密生成非对称令牌。发送单元102将处理单元101生成的非对称令牌作为安全参数发送给功能网元。
其中，处理单元101还可基于管理网元的私钥，对功能网元资料、功能网元的标识、以及功能网元与控制网元之间的共享密钥执行数字签名算法生成数字签名，并基于控制网元的公钥，对数字签名、功能网元资料、功能网元的标识以及功能网元与控制网元之间的共享密钥加密生成非对称令牌。发送单元102将处理单元101生成的非对称令牌作为安全参数发送给功能网元。
另一种可能的实施方式中，处理单元101可基于管理网元与控制网元之间共享的对称密钥，对功能网元的标识以及功能网元资料执行消息认证码的算法生成消息认证 码，并基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、功能网元的标识加密，生成对称令牌。发送单元102将处理单元101生成的对称令牌作为安全参数发送给功能网元。
其中，处理单元101还可基于管理网元与控制网元之间共享的对称密钥，对功能网元和控制网元之间的共享密钥，功能网元的标识以及功能网元资料执行消息认证码的算法生成消息认证码，并基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、功能网元的标识、以及功能网元和控制网元之间的共享密钥加密生成对称密钥。发送单元102将处理单元101生成的对称令牌作为安全参数发送给功能网元。
另一种可能的实施方式中，处理单元101可基于管理网元与控制网元之间共享的对称密钥，对功能网元资料以及所述功能网元的标识执行消息认证码的算法生成第一消息认证码。发送单元102将处理单元101生成的第一消息认证码作为安全参数发送给功能网元。
其中，处理单元101还可基于管理网元与控制网元之间共享的对称密钥，对功能网元的标识以及控制网元的标识执行消息认证码的算法生成第三消息认证码。发送单元102将处理单元101生成的第三消息认证码作为安全参数发送给功能网元。
又一种可能的实施方式中，注册装置100还可包括接收单元103，其中接收单元103用于接收控制网元发送的第四消息认证码以及功能网元的标识。处理单元101根据推衍密钥，对功能网元的标识以及控制网元的标识执行消息认证码的算法生成第五消息认证码，并比较第四消息认证码与第五消息认证码是否一致，以实现对第四消息认证码的验证，若第四消息认证码与第五消息认证码一致，则功能网元确定第四消息认证码正确，确认功能网元发送的注册请求合法，确认功能网元认证通过，发送单元102向控制网元发送第四消息认证码的验证结果。
另一种可能的实施方式中，处理单元101可基于管理网元的私钥，对功能网元资料、以及功能网元的标识执行数字签名算法生成第一数字签名。发送单元102将处理单元101生成的第一数字签名作为安全参数发送给功能网元。
在采用硬件形式实现时，上述处理单元101可以是处理器，发送单元102可以是发射器，接收单元103可以是接收器，当处理单元101是处理器，发送单元102是发射器，接收单元103是接收器时，注册装置100可采用图13所示管理网元的结构。采用图13所示的管理网元可以是OAM，该OAM可以是上述方法实施例中涉及的OAM。
图13示出了本申请实施例提供的管理网元1000的结构示意图，即示出了注册装置100的另一结构示意图。参阅图13所示，管理网元1000包括处理器1001、发射器1002和接收器1003。其中，处理器1001也可以为控制器。所述处理器1001被配置为支持管理网元1000执行图2至图11中涉及的管理网元的功能。所述发射器1002和接收器1003被配置为支持管理网元1000与控制网元以及功能网元之间进行消息的收发功能。所述管理网元1000还可以包括存储器1004，所述存储器1004用于与处理器1001耦合，其保存管理网元1000必要的程序指令和数据。其中，处理器1001、发射器1002、接收器1003和存储器1004相连，该存储器1004用于存储指令，该处理器1001用于执行该存储器1004存储的指令，以控制发射器1002和接收器1003收发数据，完成上述方法中管理网元执行相应功能的步骤。
本申请实施例中，注册装置100和管理网元1000所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
在采用软件功能单元的形式实现时，图14示出了本申请实施例提供的一种基于服务化架构的注册装置200的结构示意图。其中，基于服务化架构的注册装置200可应用于功能网元，参阅图14所示，应用于功能网元的注册装置200可包括接收单元201和发送单元202。其中，接收单元201用于接收管理网元发送的配置信息以及安全参数。发送单元202用于基于接收单元201接收的配置信息，向控制网元发送注册请求，注册请求中包括接收单元201接收到的安全参数。
其中，接收单元201接收到的安全参数可以是管理网元生成的非对称令牌、对称令牌、第一消息认证码或第一数字签名。
一种可能的实施方式中，接收单元201还用于接收控制网元发送的第二消息认证码以及管理网元发送的第三消息认证码。注册装置200还包括处理单元203，其中，处理单元203用于比较第二消息认证码与第三消息认证码是否一致，并根据比较结果确定第二消息认证码的合法性。
另一种可能的实施方式中，接收单元201还用于接收控制网元发送的第二消息认证码，发送单元202向管理网元发送接收单元201接收到的第二消息认证码。接收单元201还用于接收控制网元发送的第二消息认证码验证结果。注册装置200还包括处理单元203，其中，处理单元203用于根据接收单元201接收到的第二消息认证码验证结果，确定所述第二消息认证码的合法性。
又一种可能的实施方式中，接收单元201还用于接收控制网元发送的第二数字签名。册装置200还包括处理单元203，其中，处理单元203用于根据接收单元201接收到第二数字签名，以及被第二数字签名所签名的内容，验证所述第二数字签名的合法性。
又一种可能的实施方式中，注册装置200还包括处理单元203，处理单元203用于基于会话密钥或者基于会话密钥的推衍密钥，与控制网元建立安全通道。
在采用硬件形式实现时，上述接收单元201可以是接收器，发送单元202可以是发射器，处理单元203可以是处理器，当接收单元201是接收器，发送单元202是发射器，处理单元203是处理器时，注册装置200可采用图15所示功能网元的结构。采用图15所示的功能网元可以是NF，该NF可以是上述方法实施例中涉及的NF。
图15示出了本申请实施例提供的功能网元2000的结构示意图，即示出了注册装置200的另一结构示意图。参阅图15所示，功能网元2000包括处理器2001、发射器2002和接收器2003。其中，处理器2001也可以为控制器。所述处理器2001被配置为支持功能网元2000执行图2至图11中涉及的功能网元的功能。所述发射器2002和接收器2003被配置为支持功能网元2000与控制网元以及管理网元之间进行消息的收发功能。所述功能网元2000还可以包括存储器2004，所述存储器2004用于与处理器2001耦合，其保存功能网元2000必要的程序指令和数据。其中，处理器2001、发射器2002、接收器2003和存储器2004相连，该存储器2004用于存储指令，该处理器2001用于执行该存储器2004存储的指令，以控制发射器2002和接收器2003收发数据，完成上述方法中功能网元执行相应功能的步骤。
本申请实施例中，注册装置200和功能网元2000所涉及的与本申请实施例提供的技 术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
在采用软件功能单元的形式实现时，图16示出了本申请实施例提供的一种基于服务化架构的注册装置300的结构示意图。其中，基于服务化架构的注册装置300可应用于控制网元，参阅图16所示，应用于功能网元的注册装置300可包括接收单元301和处理单元302。其中，接收单元301用于接收功能网元发送的注册请求，该注册请求中包括安全参数。处理单元302用于验证接收单元301接收到的安全参数的正确性，并通过安全参数的正确性确定所述注册请求的合法性。
一种可能的实施方式中，所述安全参数包括非对称令牌。处理单元302利用所述控制网元的私钥解密所述非对称令牌，以得到数字签名，并利用管理网元的公钥以及被签名的内容，验证所述数字签名的正确性。
另一种可能的实施方式中，所述安全参数包括对称令牌。处理单元302利用所述对称密钥解密所述对称令牌，以得到消息认证码，并利用所述对称密钥，以及被消息验证码保护的内容，验证所述消息验证码的正确性。
又一种可能的实施方式中，所述安全参数包括第一消息认证码。处理单元302利用管理网元与控制网元之间共享的对称密钥、以及被第一消息验证码保护的内容，验证所述第一消息认证码的正确性。
其中，处理单元302还用于管理网元与控制网元之间共享的对称密钥，对所述功能网元的标识以及所述控制网元的标识执行消息认证码的算法生成第二消息认证码。注册装置300还包括发送单元303。其中，发送单元303用于将处理单元302生成的第二消息认证码发送给功能网元，以使功能网元利用第二消息认证码对控制网元实现认证。
又一种可能的实施方式中，所述安全参数包括第一数字签名。处理单元302利用管理网元的公钥，以及被第一数字签名所签名的内容，验证所述第一数字签名的正确性。
其中，处理单元302还用于基于控制网元的私钥，对所述功能网元的标识以及所述控制网元的标识执行数字签名算法生成第二数字签名。注册装置300还包括发送单元303。其中，发送单元303用于将处理单元302生成的第二数字签名发送给功能网元，以使功能网元利用第二数字签名对控制网元实现认证。
又一种可能的实施方式中，接收单元301用于接收功能网元发送的功能网元的标识以及第四消息认证码。注册装置300还包括发送单元303。发送单元303将接收单元301接收到的功能网元的标识以及第四消息认证码发送给管理网元。接收单元301还用于接收管理网元发送的第五消息认证码。处理单元302还用于比较所述第四消息认证码与所述第五消息认证码是否一致，验证所述第四消息认证码的正确性。
又一种可能的实施方式中，接收单元301用于接收功能网元发送的功能网元的标识以及第四消息认证码。注册装置300还包括发送单元303。发送单元303将接收单元301接收到的功能网元的标识以及第四消息认证码发送给管理网元。接收单元301还用于接收管理网元发送的第四消息认证码验证结果。处理单元302依据接收单元301接收的第四消息认证码验证结果确定所述第四消息认证码的正确性。
在采用硬件形式实现时，上述接收单元301可以是接收器，处理单元302可以是处理器，发送单元303可以是发射器，当接收单元301是接收器，处理单元302是处理器，发 送单元303是发射器时，注册装置300可采用图17所示控制网元的结构。采用图17所示的控制网元可以是NRF，该NRF可以是上述方法实施例中涉及的NRF。
图17示出了本申请实施例提供的控制网元3000的结构示意图，即示出了注册装置300的另一结构示意图。参阅图17所示，控制网元3000包括处理器3001、发射器3002和接收器3003。其中，处理器3001也可以为控制器。所述处理器3001被配置为支持控制网元3000执行图2至图11中涉及的控制网元的功能。所述发射器3002和接收器3003被配置为支持控制网元3000与功能网元以及管理网元之间进行消息的收发功能。所述控制网元3000还可以包括存储器3004，所述存储器3004用于与处理器3001耦合，其保存控制网元3000必要的程序指令和数据。其中，处理器3001、发射器3002、接收器3003和存储器3004相连，该存储器3004用于存储指令，该处理器3001用于执行该存储器3004存储的指令，以控制发射器3002和接收器3003收发数据，完成上述方法中控制网元执行相应功能的步骤。
本申请实施例中，注册装置300和控制网元3000所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
需要说明的是，本申请实施例上述涉及的处理器可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。
其中，所述存储器可以集成在所述处理器中，也可以与所述处理器分开设置。
作为一种实现方式，接收器和发射器的功能可以考虑通过收发电路或者收发的专用芯片实现。处理器可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。
作为另一种实现方式，将实现处理器、接收器和发射器功能的程序代码存储在存储器中，通用处理器通过执行存储器中的代码来实现处理器、接收器和发射器的功能。
根据本申请实施例提供的方法，本申请实施例还提供一种通信系统，其包括前述的管理网元、功能网元及控制网元。
本申请实施例还提供一种芯片，所述芯片与存储器相连，用于读取并执行所述存储器中存储的软件程序，以实现上述实施例中涉及的管理网元所执行的功能。
本申请实施例还提供一种芯片，所述芯片与存储器相连，用于读取并执行所述存储器中存储的软件程序，以实现上述实施例中涉及的功能网元所执行的功能。
本申请实施例还提供一种芯片，所述芯片与存储器相连，用于读取并执行所述存储器中存储的软件程序，以实现上述实施例中涉及的控制网元所执行的功能。
本申请实施例还提供一种计算机存储介质，该计算机存储介质中存储有一些指令，这些指令被执行时，可以完成上述方法实施例中涉及的注册方法。
本申请实施例还提供一种计算机程序产品，该计算机程序产品中包括计算机程序，该计算机程序用于执行上述方法实施例中涉及的注册方法。
本领域内的技术人员应明白，本申请实施例可提供为方法、系统、或计算机程序产品。 因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

Claims (25)

  1. 一种基于服务化架构的注册方法，其特征在于，包括：
    控制网元接收功能网元发送的注册请求，所述注册请求中包括安全参数；
    所述控制网元验证所述安全参数的正确性，并通过所述安全参数的正确性确定所述注册请求的合法性。
  2. 根据权利要求1所述的方法，其特征在于，所述安全参数包括令牌，所述令牌由管理网元生成并发送给所述功能网元。
  3. 根据权利要求2所述的方法，其特征在于，所述令牌由管理网元基于所述控制网元的公钥，对数字签名、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；
    所述数字签名由管理网元基于所述管理网元的私钥，对功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥执行数字签名算法生成；
    所述控制网元验证所述安全参数的正确性，包括：
    所述控制网元利用所述控制网元的私钥解密所述令牌，以得到数字签名，并
    利用管理网元的公钥以及被签名的内容，验证所述数字签名的正确性；
    其中，所述被签名的内容包括所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料。
  4. 根据权利要求2所述的方法，其特征在于，所述令牌由管理网元基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；
    所述消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料执行消息认证码的算法生成；
    所述控制网元验证所述安全参数的正确性，包括：
    所述控制网元利用所述对称密钥解密所述令牌，以得到消息认证码，并
    利用所述对称密钥，以及被消息验证码保护的内容，验证所述消息验证码的正确性；
    其中，所述被消息验证码保护的内容包括所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料；另外还可能包括控制网元的标识。
  5. 根据权利要求1至4任一项所述的方法，其特征在于，所述控制网元接收功能网元发送的注册请求之后，所述方法还包括：
    所述控制网元确定所述注册请求合法的情况下，基于会话密钥或者基于会话密钥的推衍密钥，与所述功能网元建立安全通道；
    其中，所述控制网元通过解密令牌得到所述会话密钥，所述令牌基于所述会话密钥生成，所述会话密钥由所述管理网元根据预设的根密钥，对所述功能网元的标识加密生成；或者所述控制网元从管理网元处获取所述会话密钥，所述会话密钥由所述管理网元根据推衍密钥对所述功能网元的标识加密生成；所述推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者所述推衍密钥为所述管理网元保存的所述功能网 元的密钥。
  6. 一种基于服务化架构的注册方法，其特征在于，包括：
    功能网元接收管理网元发送的配置信息；
    所述功能网元基于所述配置信息，向控制网元发送注册请求，所述注册请求中包括安全参数。
  7. 根据权利要求6所述的方法，其特征在于，所述安全参数包括令牌，所述配置信息中包括所述令牌。
  8. 根据权利要求7所述的方法，其特征在于，所述令牌由管理网元基于所述控制网元的公钥，对数字签名、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述数字签名由管理网元基于所述管理网元的私钥，对功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥执行数字签名算法生成；或者
    所述令牌由管理网元基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料执行消息认证码的算法生成。
  9. 根据权利要求6至8任一项所述的方法，其特征在于，所述功能网元向控制网元发送注册请求之后，所述方法还包括：
    所述功能网元基于会话密钥或者基于会话密钥的推衍密钥，与所述控制网元建立安全通道；
    其中，所述会话密钥由所述管理网元根据预设的根密钥以及所述功能网元的标识生成，所述配置信息中包括所述会话密钥；或者所述会话密钥由所述功能网元根据所述功能网元的标识以及从管理网元处获取的推衍密钥生成，所述推衍密钥由管理网元对预设的根密钥进行密钥推得到，或者所述推衍密钥为所述管理网元保存的所述功能网元的密钥。
  10. 一种基于服务化架构的注册方法，其特征在于，包括：
    管理网元确定功能网元的配置信息，所述配置信息中包括安全参数；
    所述管理网元向功能网元发送所述配置信息。
  11. 根据权利要求10所述的方法，其特征在于，所述安全参数包括令牌；
    其中，所述令牌由管理网元基于所述控制网元的公钥，对数字签名、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述数字签名由管理网元基于所述管理网元的私钥，对功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥执行数字签名算法生成；或者
    所述令牌由管理网元基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料执行消息认证码的算法生成。
  12. 根据权利要求10或11所述的方法，其特征在于，所述方法还包括：
    所述管理网元生成会话密钥，并将所述会话密钥发送给所述功能网元或控制网元；
    其中，所述会话密钥由所述管理网元根据预设的根密钥，对所述功能网元的标识加密生成；或者所述会话密钥由所述管理网元根据推衍密钥，对所述功能网元的标识加密生成，所述推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者所述推衍密钥为所述管理网元保存的所述功能网元的密钥。
  13. 一种基于服务化架构的注册装置，应用于控制网元，其特征在于，包括：
    接收单元，用于接收功能网元发送的注册请求，所述注册请求中包括安全参数；
    处理单元，用于验证所述接收单元接收的安全参数的正确性，并通过所述安全参数的正确性确定所述注册请求的合法性。
  14. 根据权利要求13所述的装置，其特征在于，所述安全参数包括令牌，所述令牌由管理网元生成并发送给所述功能网元。
  15. 根据权利要求13所述的装置，其特征在于，所述令牌由管理网元基于所述控制网元的公钥，对数字签名、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；
    所述数字签名由管理网元基于所述管理网元的私钥，对功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥执行数字签名算法生成；
    所述控制网元验证所述安全参数的正确性，包括：
    所述控制网元利用所述控制网元的私钥解密所述令牌，以得到数字签名，并
    利用管理网元的公钥以及被签名的内容，验证所述数字签名的正确性；
    其中，所述被签名的内容包括所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料。
  16. 根据权利要求14所述的装置，其特征在于，所述令牌由管理网元基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；
    所述消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料执行消息认证码的算法生成；
    所述控制网元验证所述安全参数的正确性，包括：
    所述控制网元利用所述对称密钥解密所述令牌，以得到消息认证码，并
    利用所述对称密钥，以及被消息验证码保护的内容，验证所述消息验证码的正确性；
    其中，所述被消息验证码保护的内容包括所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料；另外还可能包括控制网元的标识。
  17. 根据权利要求13至16任一项所述的装置，其特征在于，所述处理单元，还用于：
    在所述接收单元接收功能网元发送的注册请求之后，确定所述注册请求合法的情况下，基于会话密钥或者基于会话密钥的推衍密钥，与所述功能网元建立安全通道；
    其中，所述控制网元通过解密令牌得到所述会话密钥，所述令牌基于所述会话密 钥生成，所述会话密钥由所述管理网元根据预设的根密钥，对所述功能网元的标识加密生成；或者所述控制网元从管理网元处获取所述会话密钥，所述会话密钥由所述管理网元根据推衍密钥对所述功能网元的标识加密生成；所述推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者所述推衍密钥为所述管理网元保存的所述功能网元的密钥。
  18. 一种基于服务化架构的注册装置，应用于功能网元，其特征在于，包括：
    接收单元，用于接收管理网元发送的配置信息；
    发送单元，用于基于所述接收单元接收的配置信息，向控制网元发送注册请求，所述注册请求中包括安全参数。
  19. 根据权利要求18所述的装置，其特征在于，所述安全参数包括令牌，所述配置信息中包括所述令牌。
  20. 根据权利要求19所述的装置，其特征在于，所述令牌由管理网元基于所述控制网元的公钥，对数字签名、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述数字签名由管理网元基于所述管理网元的私钥，对功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥执行数字签名算法生成；或者
    所述令牌由管理网元基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料执行消息认证码的算法生成。
  21. 根据权利要求18至20任一项所述的装置，其特征在于，所述装置还包括处理单元，所述处理单元用于：
    在所述发送单元向控制网元发送注册请求之后，基于会话密钥或者基于会话密钥的推衍密钥，与所述控制网元建立安全通道；
    其中，所述会话密钥由所述管理网元根据预设的根密钥以及所述功能网元的标识生成，所述配置信息中包括所述会话密钥；或者所述会话密钥由所述功能网元根据所述功能网元的标识以及从管理网元处获取的推衍密钥生成，所述推衍密钥由管理网元对预设的根密钥进行密钥推得到，或者所述推衍密钥为所述管理网元保存的所述功能网元的密钥。
  22. 一种基于服务化架构的注册装置，应用于管理网元，其特征在于，包括：
    处理单元，用于确定功能网元的配置信息，所述配置信息中包括安全参数；
    发送单元，用于向功能网元发送所述处理单元确定的配置信息。
  23. 根据权利要求22所述的装置，其特征在于，所述安全参数包括令牌；
    所述处理单元具体用于：
    基于所述控制网元的公钥，对数字签名、功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述数字签名由管理网元基于所述管理网元的私钥，对功能网元资料、所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥执行数字签名算法生成；或者
    基于管理网元与控制网元之间共享的对称密钥，对消息认证码、功能网元资料、 所述功能网元的标识、以及所述功能网元和所述控制网元之间的共享密钥加密生成；所述消息认证码由管理网元基于管理网元与控制网元之间共享的对称密钥，对所述功能网元和所述控制网元之间的共享密钥，所述功能网元的标识以及功能网元资料执行消息认证码的算法生成。
  24. 根据权利要求22或23所述的装置，其特征在于，所述处理单元还用于生成会话密钥；
    所述发送单元还用于将所述会话密钥发送给所述功能网元或控制网元；
    其中，所述会话密钥由所述管理网元根据预设的根密钥，对所述功能网元的标识加密生成；或者所述会话密钥由所述管理网元根据推衍密钥，对所述功能网元的标识加密生成，所述推衍密钥由管理网元对预设的根密钥进行密钥推衍得到，或者所述推衍密钥为所述管理网元保存的所述功能网元的密钥。
  25. 一种通信系统，其特征在于，包括控制网元、功能网元以及管理网元，其中，
    所述控制网元为权利要求13至17任一项所述的基于服务化架构的注册装置；
    所述功能网元为权利要求18至21任一项所述的基于服务化架构的注册装置；
    所述管理网元为权利要求22至24任一项所述的基于服务化架构的注册装置。
PCT/CN2018/081447 2017-08-31 2018-03-30 基于服务化架构的注册方法及装置 Ceased WO2019041809A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18849939.6A EP3668042B1 (en) 2017-08-31 2018-03-30 Registration method and apparatus based on service-oriented architecture
US16/803,624 US11496320B2 (en) 2017-08-31 2020-02-27 Registration method and apparatus based on service-based architecture

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710774290.9 2017-08-31
CN201710774290.9A CN109428874B (zh) 2017-08-31 2017-08-31 基于服务化架构的注册方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/803,624 Continuation US11496320B2 (en) 2017-08-31 2020-02-27 Registration method and apparatus based on service-based architecture

Publications (1)

Publication Number Publication Date
WO2019041809A1 true WO2019041809A1 (zh) 2019-03-07

Family

ID=65504803

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/081447 Ceased WO2019041809A1 (zh) 2017-08-31 2018-03-30 基于服务化架构的注册方法及装置

Country Status (4)

Country Link
US (1) US11496320B2 (zh)
EP (1) EP3668042B1 (zh)
CN (1) CN109428874B (zh)
WO (1) WO2019041809A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113472724A (zh) * 2020-03-31 2021-10-01 中国联合网络通信集团有限公司 一种网络认证方法、设备及系统
WO2021224544A1 (en) * 2020-05-05 2021-11-11 Nokia Technologies Oy Registration in communication networks

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020002359A1 (en) * 2018-06-25 2020-01-02 NEC Laboratories Europe GmbH Oam functional service exposure and discovery function and data repository
WO2020082228A1 (en) * 2018-10-23 2020-04-30 Nokia Technologies Oy Method and apparatus for attesting physical attacks
CN111865598B (zh) * 2019-04-28 2022-05-10 华为技术有限公司 网络功能服务的身份校验方法及相关装置
CN115065476B (zh) * 2019-04-29 2025-03-07 华为技术有限公司 通信方法和通信设备
CN110366276B (zh) * 2019-07-03 2022-04-12 中国联合网络通信集团有限公司 服务化架构基站
CN110351141B (zh) * 2019-07-12 2022-05-17 Ut斯达康通讯有限公司 FlexE接口管理方法、装置及网元
CN114245378B (zh) * 2020-09-07 2025-04-01 中国移动通信有限公司研究院 一种数据传输方法、相关网络设备和存储介质
US11743047B2 (en) * 2020-09-11 2023-08-29 Arista Networks, Inc. Cryptographically identifying a device
CN112152856B (zh) * 2020-09-25 2021-10-01 广州爱浦路网络技术有限公司 边缘服务器管理系统及方法
DE102021201443A1 (de) * 2021-02-16 2022-08-18 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Übertragen von Daten in einem Netzwerk mit einem dienstorientierten Protokoll
CN113490212A (zh) * 2021-06-18 2021-10-08 新华三技术有限公司 一种密钥的分配方法、通信设备和存储介质
CN114760130A (zh) * 2022-04-11 2022-07-15 中国电信股份有限公司 网络功能的配置文件的更新方法、装置、电子设备和介质
WO2024014749A1 (en) * 2022-07-15 2024-01-18 Samsung Electronics Co., Ltd. Apparatus and method for performing network function management and discovery in wireless network
CN117896777A (zh) * 2022-10-13 2024-04-16 华为技术有限公司 通信方法、通信装置及通信系统
US20240224345A1 (en) * 2022-12-30 2024-07-04 Dish Wireless L.L.C. Network repository function

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7546629B2 (en) * 2002-03-06 2009-06-09 Check Point Software Technologies, Inc. System and methodology for security policy arbitration
CN102413464A (zh) * 2011-11-24 2012-04-11 杭州东信北邮信息技术有限公司 基于gba的电信能力开放平台密钥协商系统和方法
CN105101194A (zh) * 2014-04-28 2015-11-25 华为技术有限公司 终端安全认证方法、装置及系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2619680A1 (en) * 2010-09-23 2013-07-31 Hewlett-Packard Development Company, L.P. Methods, apparatus and systems for monitoring locations of data within a network service
US9294337B2 (en) * 2014-03-26 2016-03-22 Sonus Networks, Inc. Methods and systems for integrating independent IMS and WebRTC networks
CN105323096B (zh) * 2014-07-30 2018-11-23 中国移动通信集团公司 一种网络功能的运维方法及运维系统
WO2016028198A1 (en) 2014-08-20 2016-02-25 Telefonaktiebolaget L M Ericsson (Publ) Methods, devices and management terminals for establishing a secure session with a service
CN105634778B (zh) * 2014-11-04 2020-09-22 南京中兴软件有限责任公司 实现vnf实例化的方法、系统及nfvo和vnfm
WO2016116137A1 (en) * 2015-01-20 2016-07-28 Nokia Solutions And Networks Oy Multiple parallel webrtc accesses to ims
CN106384028A (zh) 2016-09-12 2017-02-08 浪潮软件股份有限公司 一种支持多租户的统一身份认证服务实现的方法
KR102559755B1 (ko) * 2016-10-06 2023-07-26 삼성전자 주식회사 네크워크 슬라이스를 지원하는 로밍 환경에서 단말의 attach 및 home routed PDU session 생성 방법
CN106550028A (zh) 2016-10-25 2017-03-29 广东科海信息科技股份有限公司 一种面向服务架构的多Agent协商模型
CN108632312B (zh) * 2017-03-20 2020-01-17 中国移动通信有限公司研究院 网络功能信息交互方法及装置
US11082458B2 (en) * 2017-08-18 2021-08-03 T-Mobile Usa, Inc. Web access in 5G environments

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7546629B2 (en) * 2002-03-06 2009-06-09 Check Point Software Technologies, Inc. System and methodology for security policy arbitration
CN102413464A (zh) * 2011-11-24 2012-04-11 杭州东信北邮信息技术有限公司 基于gba的电信能力开放平台密钥协商系统和方法
CN105101194A (zh) * 2014-04-28 2015-11-25 华为技术有限公司 终端安全认证方法、装置及系统

Non-Patent Citations (1)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113472724A (zh) * 2020-03-31 2021-10-01 中国联合网络通信集团有限公司 一种网络认证方法、设备及系统
WO2021224544A1 (en) * 2020-05-05 2021-11-11 Nokia Technologies Oy Registration in communication networks

Also Published As

Publication number Publication date
EP3668042B1 (en) 2021-07-28
US20200195445A1 (en) 2020-06-18
CN109428874B (zh) 2020-10-09
EP3668042A4 (en) 2020-08-05
CN109428874A (zh) 2019-03-05
EP3668042A1 (en) 2020-06-17
US11496320B2 (en) 2022-11-08

Similar Documents

Publication Publication Date Title
CN109428874B (zh) 基于服务化架构的注册方法及装置
US11824981B2 (en) Discovery method and apparatus based on service-based architecture
US11228442B2 (en) Authentication method, authentication apparatus, and authentication system
US10516654B2 (en) System, apparatus and method for key provisioning delegation
US10250383B1 (en) Dynamic domain key exchange for authenticated device to device communications
US10841784B2 (en) Authentication and key agreement in communication network
CN111630882B (zh) 用户设备、认证服务器、介质、及确定密钥的方法和系统
EP4231680A1 (en) Identity authentication system, method and apparatus, device, and computer readable storage medium
WO2017028593A1 (zh) 网络接入设备接入无线网络接入点的方法、网络接入设备、应用程序服务器和非易失性计算机可读存储介质
CN109005032B (zh) 一种路由方法和装置
CN112423300A (zh) 无线网络接入认证方法及装置
CN101399665A (zh) 以基于身份的密码体制为基础的业务认证方法和系统
EP4734444A1 (en) Authentication methods and devices
JP2023509806A (ja) モバイルネットワークアクセスシステム、方法、記憶媒体及び電子機器
WO2020148222A1 (en) Network security
Duan et al. Lightweight Group Authentication and Key Agreement Protocol with Cross-Slice Handover for 5G Network Slicing
CN122002285A (zh) 访问权限管理方法、装置及存储介质
CN121284550A (zh) 一种通信方法、装置、设备和存储介质
CN120358493A (zh) 通信方法和通信装置
CN120358491A (zh) 通信方法和通信装置

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018849939

Country of ref document: EP

Effective date: 20200309