WO2018120217A1 - 验证密钥请求方的方法和设备 - Google Patents
验证密钥请求方的方法和设备 Download PDFInfo
- Publication number
- WO2018120217A1 WO2018120217A1 PCT/CN2016/113941 CN2016113941W WO2018120217A1 WO 2018120217 A1 WO2018120217 A1 WO 2018120217A1 CN 2016113941 W CN2016113941 W CN 2016113941W WO 2018120217 A1 WO2018120217 A1 WO 2018120217A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- entity
- umf
- key
- core network
- network element
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/069—Authentication using certificates or pre-shared keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
- H04W12/0431—Key distribution or pre-distribution; Key agreement
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- 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/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/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/3297—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 time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/062—Pre-authentication
Definitions
- the present application relates to the field of communications technologies, and in particular, to a method and an apparatus for verifying a key requesting party.
- the Long Term Evolution (LTE) system architecture is shown in Figure 1.
- the Mobility Management Entity (MME) is the network element responsible for security, mobility management, and session management at the core network side.
- Security that is, the user equipment (UE) needs to perform mutual authentication with the network when initially entering the network.
- the UE and the core network After mutual authentication, the UE and the core network generate a key.
- the UE and the MME perform algorithm negotiation, that is, security capability negotiation.
- the mobility management is to record the location information of the UE, and select a suitable user plane network element device for the UE according to the location information of the UE.
- Session management is responsible for establishing the user plane link of the UE.
- the Home Subscriber Server (HSS) is used to store the subscription information of the user.
- the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN; UMTS, Universal Mobile Telecommunications System) is an air interface access part in LTE, and is usually called an evolved base station (eNo
- the MME is divided into three functions: NG Auth. Function (AUF), UE Management Function (UMF), and Session Management Function (SMF).
- NG Auth. Function (AUF)
- UMF UE Management Function
- SMF Session Management Function
- slice A is specific to IoT devices.
- Each slice has its own Control Plane Network Function (CP NF), mainly SM.
- CP NF Control Plane Network Function
- UP NF User Plane Network Function
- P-GW Packet Data Network Gateway
- Common CP NF Common CP NF (Common CP NF) is a control plane function shared by several slices, including UMF and AUF.
- SSF Slice Select Function
- An Authentication Credential Repository and Processing Function is used to store subscription data of a user in a Unified Data Management (UDM).
- AUF as a security function, can be deployed independently or together with entities with UMF capabilities.
- the AUF may be further divided into an entity such as a Security Anchor Function (SEAF), a Security Context Management Function (SCMF), and a security policy management function, where the SEAF entity is used to interact with the UE and the authentication server.
- SEAF entity is used to interact with the UE and the authentication server.
- the intermediate key is received after the authentication process, and the SCMF entity is used to obtain the key from the SEAF entity and further derive other keys.
- the UE initiates an attach process, which includes a security process.
- the security process includes two processes: two-way authentication, key generation, and security capability negotiation.
- Two-way authentication means that the UE and the core network authenticate each other. The effect that can be achieved after the end of authentication is that the UE considers the core network to be authentic, and the core network considers that the UE is authentic.
- a key for protecting NAS messages is generated after authentication or during authentication. After the key is generated, the security capability negotiation between the UE and the MME is started. Security capabilities, ie encryption algorithms and integrity protection algorithms used subsequently.
- Step 1 The UE initiates an attach request (Attach Request);
- Step 2 Perform mutual authentication between the UE and the SEAF entity.
- Step 3 The UMF entity requests a security context from the SEAF entity.
- Step 4 The UE and the UMF entity initiate a NAS MM SMC process, which is an MM algorithm negotiation process.
- Step 5 The SSF entity forwards the Attach Request to the UMF entity.
- the UE and the UMF entity complete the remaining attach process
- Step 6 The UMF entity forwards the session management request to the SMF entity.
- Step 7 The SMF entity obtains a security policy.
- Step 8 The SMF entity obtains the user plane security context of the UE from the SEAF entity, and the content of the user plane security context has not been defined.
- Step 9 The SMF entity initiates a user plane NAS UP SMC process
- Step 10 Start other security processes.
- the UMF entity is an entity that handles NAS signaling security, but the UMF entity has no security function.
- the SEAF entity that generates the key is independent of the UMF entity, so the UMF entity needs to request the key from the SEAF entity.
- the attached message is forwarded to the UMF entity.
- the UMF entity needs to request the SEAF entity for the subsequent security key.
- the SEAF entity needs to determine whether the UMF entity requesting the key is the UMF entity to which the UE is attached.
- the embodiment of the present invention provides a method and a device for verifying a key requesting party, which are used to implement, in an initial network access process, a function of verifying whether a key requesting party is an entity capable of obtaining a key.
- the implementation of the present application provides a method for verifying a key requester, including: a security function entity receiving a request message sent by a user management function UMF entity; and the security function entity adopting a private key pair of the security function entity Decrypting the information in the request message, and performing signature verification on the decrypted information by using the public key in the certificate of the UMF entity, and acquiring information carried in the request message; if the security function entity determines Determining that the first authentication parameter carried in the request message is legal, and determining that the identifier of the UMF entity carried in the request message is the same as the identifier of the UMF entity to which the terminal UE is attached, determining to provide the UE for the UMF entity Key.
- the security function entity sends the UMF entity by using the private key of the security function entity. Decrypting the request message, and performing signature verification on the decrypted information by using the public key in the certificate of the UMF entity, according to the first verification parameter carried in the verification request message, the identifier of the UMF entity, and the UMF entity attached to the terminal. The identifier determines whether the UMF entity requesting the key is a UMF entity capable of obtaining the key.
- the method further includes: the security function entity generates a freshness parameter; the security function entity notifies the freshness parameter to the UMF entity attached to the UE by using a core network element And the UMF entity attached by the UE carries the freshness parameter as the first verification parameter in the request message.
- the security function entity notifies the freshness parameter to the UMF entity attached to the UE through the core network element, and the UMF entity carries the first freshness parameter as the first verification parameter in the request message, thereby making the security
- the functional entity can verify whether the UMF entity requesting the key is a UMF entity that can obtain the key.
- the security function entity determines that the first verification parameter carried in the request message is legal, and the method includes: determining, by the security function entity, that the first verification parameter is the same as the freshness parameter, or determining If the freshness parameter is within the set range, it is determined that the first verification parameter carried in the security context request is legal.
- an implementation manner in which the first verification parameter is validated using the freshness parameter is configured.
- the request message further carries a second verification parameter, where the second verification parameter is generated by the UMF entity; the method further includes: the security function entity returns a response message to the UMF entity
- the response message carries at least the key generated by the UMF entity and the second verification parameter, and the information carried in the response message is encrypted by using the public key of the UMF entity, After the UMF entity decrypts the response message by using the private key of the UMF entity, if it is determined that the second verification parameter carried in the response message is legal, the confidentiality carried in the response message is determined.
- the key is a key generated by the security function entity for the UMF entity.
- the UMF entity further determines that the key carried in the response message is a key of the UMF entity by verifying that the second verification parameter in the response message returned by the security function entity is legal, thereby further improving security.
- an embodiment of the present application provides a method for verifying a key requesting party, including: The full-featured entity receives the request message sent by the first core network element, where the request message carries the identifier of the first core network element, the identity information of the terminal UE, and the first token; The identifier of the first core network element and the identity information of the UE determine that the first token is legal, and then determine that the key is provided for the first core network element.
- the security function entity verifies whether the first token carried in the request message of the first core network element is legal, and whether the UMF entity that verifies the request key is an UMF entity capable of obtaining the key.
- the method before the security function entity receives the request message sent by the first core network element, the method further includes: the security function entity generates a first freshness parameter; the security function entity The first freshness parameter is sent to the second core network element, and the second core network element is configured according to the identifier of the first core network element attached to the UE, the identity information of the UE, and the first fresh The first parameter is generated by the sex parameter and the shared key.
- the core network element combines the shared key and the first freshness parameter to generate the first token, so that the security function entity can verify whether the first token is legal according to the locally stored core network element related parameter.
- the shared key is generated by the security function entity and sent to the second core network element; or the shared key is used by the security function entity and the second core network.
- the network elements are generated separately.
- the security function entity determines that the first token is legal according to the identifier of the first core network element and the identity information of the UE, where the security function entity is configured according to the first The identifier of the core network element, the identity information of the UE, the first freshness parameter corresponding to the first core network element, and the shared key generate a second token, if the first token is determined Same as the second token, determining that the first token is legal.
- the security function entity can use the token generated by itself to verify whether the token sent by the core network element is legal.
- the first token is used by the second core network element, the private key of the second core network element, the identifier of the first core network element attached by the UE, and the UE Identity information and second freshness parameters are generated.
- the security function entity determines that the first token is legal according to the identifier of the first core network element and the identity information of the UE, where the security function entity: The identity information, the first token, and the identifier of the first core network element are sent to the second core network element; the security function entity receives the second core network element return response message, the response The message is used to indicate that the first token is legal, where the response message is sent by the second core network element according to the identity information of the UE provided by the security function entity, and the first core network element The second freshness parameter corresponding to the identity information of the UE, and the private key of the second core network element to generate a second token, and determine the first token and the second token Return after the same.
- the embodiment of the present application provides a method for verifying a key requesting party, which includes: acquiring, by a security function entity, an identifier of a user management function UMF entity attached to a terminal UE; the security function entity generating a location for the UMF entity a key of the UE and a verification parameter; the security function entity sends configuration information to the UMF entity, where the configuration information is signed by the private key of the security function entity, and then encrypted by using the public key of the UMF entity,
- the configuration information includes the key, identity information of the UE, and the verification parameter; the security function entity receives verification information returned by the UMF entity, and the verification information is used by the UMF entity to use the key pair After the verification parameter is encrypted, the security function entity determines that the verification information is valid, and determines that the key is successfully delivered.
- the security function entity sends the key and the verification parameter generated by the UMF entity to the requesting UMF entity, and receives the verification information returned by the UMF entity. After verifying that the verification information returned by the UMF entity is legal, the security key is determined. The success is achieved, thereby achieving the effect of verifying whether the UMF entity of the request key is a UMF entity capable of obtaining a key, and simplifying the key configuration process.
- an embodiment of the present application provides a device for verifying a key requesting party, where the device has a function of implementing a security function entity in the method implementation of the first aspect, the second aspect, or the third aspect, where the function is
- the corresponding software implementation may be implemented by hardware or by hardware, and the hardware or software includes one or more modules corresponding to the above functions.
- an embodiment of the present application provides a device for verifying a key requesting party, including processing And a communication interface, wherein the memory stores a preset program, the processor reads the program in the memory, and the method of the first aspect, the second aspect or the third aspect is executed according to the program.
- the embodiment of the present application provides a system for verifying a key requester, including: a user management function UMF entity, configured to send a request message to a security function entity, and a security function entity, configured to receive the UMF entity to send The request message, decrypting the information in the request message by using the private key of the security function entity, and performing signature verification on the decrypted information by using the public key in the certificate of the UMF entity, obtaining the Determining, by the information carried in the request message, if it is determined that the first authentication parameter carried in the request message is legal, and determining that the identifier of the UMF entity carried in the request message is the same as the identifier of the UMF entity attached to the terminal UE, determining Providing the UMF entity with a key for the UE.
- a user management function UMF entity configured to send a request message to a security function entity
- a security function entity configured to receive the UMF entity to send The request message, decrypting the information in the request message by using the private
- the embodiment of the present application provides a system for verifying a key requesting party, including: a first core network element, configured to send a request message to a security function entity, where the request message carries the first core The identifier of the network element, the identity information of the terminal UE, and the first token;
- a security function entity configured to receive a request message sent by the first first core network element, and determine, according to the identifier of the first core network element and the identity information of the UE, that the first token is legal, The first core network element provides the key.
- the embodiment of the present application provides a system for verifying a key requester, including: a security function entity, configured to acquire an identifier of a user management function UMF entity attached to a terminal UE, and generate the UE for the UMF entity.
- the key and the verification parameter, the configuration information is sent to the UMF entity, and the configuration information is signed by the private key of the security function entity, and then encrypted by using the public key of the UMF entity, where the configuration information includes the key The identity information of the UE and the verification parameter;
- the UMF entity is configured to receive the configuration information sent by the security function entity, obtain the verification information by encrypting the verification parameter by using the key carried in the configuration information, and send the verification information to the security function. entity;
- the security function entity is configured to determine that the key is successfully delivered after receiving the verification information returned by the UMF entity.
- 1 is a schematic diagram of an LTE system architecture
- FIG. 2 is a schematic diagram of a 5G architecture
- Figure 3 is a schematic diagram of an existing 5G security process
- FIG. 4 is a schematic structural diagram of a system in an embodiment of the present application.
- FIG. 5 is a schematic flowchart of a verification key requesting party in a first embodiment of the present application
- FIG. 6 is a schematic flowchart of a verification key requesting party in a specific embodiment 1 of the present application.
- FIG. 7 is a schematic flowchart of a method for verifying a key requesting party according to Embodiment 2 of the present application.
- FIG. 8 is a schematic flowchart of a verification key requesting party in a second embodiment of the present application.
- FIG. 9 is a schematic flowchart of verifying a key requesting party in a third embodiment of the present application.
- FIG. 10 is a schematic flowchart of verifying a key requesting party in Embodiment 4 of the present application.
- FIG. 11 is a schematic flowchart of a verification key requesting party in a third embodiment of the present application.
- FIG. 12 is a schematic flowchart of verifying a key requesting party in Embodiment 5 of the present application.
- FIG. 13 is a schematic structural diagram of an apparatus for verifying a key requesting party in a fourth embodiment of the present application.
- FIG. 14 is a schematic structural diagram of an apparatus for verifying a key requesting party in a fifth embodiment of the present application.
- 15 is a schematic structural diagram of an apparatus for verifying a key requesting party in a sixth embodiment of the present application.
- 16 is a schematic structural diagram of an apparatus for verifying a key requesting party in a seventh embodiment of the present application.
- 17 is a schematic structural diagram of an apparatus for verifying a key requesting party in an eighth embodiment of the present application.
- FIG. 18 is a schematic structural diagram of an apparatus for verifying a key requesting party in a ninth embodiment of the present application.
- the function of verifying the key requesting party is the function of the entity that can obtain the key.
- the embodiment of the present application provides a method and a device for verifying the key requesting party.
- the 5G system architecture based on the following embodiments is shown in Figure 4.
- the control plane includes AUF, UMF, Session Management (SMF), and Policy Control (Policy Control). Function, PCF), SSF, UDM, Network Exposure Function (NEF), and NF Repository Function (NRF).
- the AUF may be further divided into an entity such as a security anchor function (SEAF), a security context management function, a security policy control function (SPCF), an authentication server function (AUSF), and the like.
- SEAF entity is used to interact with the UE and the authentication server.
- ARPF is part of the UDM.
- the entities described in the system architecture may be separately set on different devices, or at least two entities may be integrated on the same device, and other entities may be disposed on other devices, and the at least two entities may be the same. Some of the entities described in the system architecture can also be all entities. If at least two entities described in the following embodiments are integrated on the same device, the information interaction between the at least two entities should be understood as the content interaction of the device.
- the AUF is used as the center of the security capability negotiation, and the AUF, more specifically the SEAF entity or the SCMF entity or the AUSF entity, verifies whether the core network element (such as the UMF entity) requesting the key is an entity capable of obtaining the key.
- the core network element such as the UMF entity
- the security function entity may be an AUF entity in the 5G network, and may be an SCMF entity or a SEAF entity or an AUSF entity in the AUF entity, or may be an independent SEAF entity, or may be in the UMF.
- the SEAF entity may also be a separate AUSF functional entity.
- the SSF logic function is shown, which may be an independent SSF entity or an entity having an SSF function, such as a UMF entity.
- a UMF entity which is an entity that manages UE mobility, is similar to an MME in LTE. It is called an MM entity at the beginning of 5G design and is called an AMF entity later.
- the UMF entity to which the UE is attached refers to the UMF entity to which the UE is ultimately attached, and is not the default UMF entity that is accessed when the UE is initially attached.
- Step 501 The security function entity receives the request message sent by the UMF entity.
- Step 502 The security function entity adopts the private key of the security function entity in the request message. After the information is decrypted, and the decrypted information is verified by the public key in the certificate of the UMF entity, the information carried in the request message is obtained.
- Step 503 The security function entity determines that the first authentication parameter carried in the request message is legal, and determines that the identifier of the UMF entity carried in the request message is the same as the identifier of the UMF entity attached to the UE, The UMF entity provides the key of the UE.
- the security function entity obtains the identifier of the UMF entity attached to the UE provided by the core network element, where the UMF entity attached to the UE refers to the UMF entity to which the UE is ultimately attached, and is not the default UMF that is accessed when initially attached. entity.
- the security function entity generates a first freshness parameter corresponding to the identifier of the UMF entity to which the UE is attached; the security function entity notifies the first freshness parameter to the UE by using the core network element
- the UMF entity optionally, the security function entity notifies the certificate of the security function entity to the UMF entity attached to the UE, and the UMF entity can obtain the certificate of the security function entity by other means.
- the UMF entity attached by the UE carries the first freshness parameter as the first verification parameter in the request message.
- the first freshness parameter may be a random number, a counter value, a time at that time, or a derivative value of the time, etc., and it should be noted that the specific form of the first freshness parameter is not limited herein.
- the security function entity determines that the first verification parameter is the same as or similar to the first freshness parameter, and determines that the first verification parameter carried in the security context request is legal.
- the core network element may be an AMF entity or an entity having an SSF function.
- the security function entity Before the security function entity receives the request message sent by the user management function UMF entity, the security function entity generates a second freshness parameter; the security function entity uses the second freshness parameter by the core network element
- the UMF entity is sent to the UMF entity to which the UE is attached.
- the security function entity notifies the certificate of the security function entity to the UMF entity attached to the UE, and the UMF entity can obtain the certificate of the security function entity by other means.
- the UMF entity attached by the UE carries the second freshness parameter as the first verification parameter in the request message in.
- the second freshness parameter can be a random number, a timestamp or a timestamp derived value, a counter, and the like.
- the security function entity determines that the second freshness parameter is within the set range, and determines the first carried in the request message.
- the verification parameters are legal. For example, if the second freshness parameter is a timestamp, if the security function entity determines that the timestamp is within the set time range, that is, the timestamp is not expired, it is determined that the first verification parameter carried in the request message is legal.
- the request message further carries a second verification parameter, and the second verification parameter is generated by the UMF entity.
- first verification parameter and the second verification parameter belong to the same type of parameters, for example, all are random numbers, it should be ensured that the values of the first verification parameter and the second verification parameter are different.
- the security function entity returns a response message to the UMF entity, where the response message carries at least the key generated by the UMF entity and the second verification parameter, and The information carried in the response message is encrypted by using the public key of the UMF entity, and after the UMF entity decrypts the response message by using the private key of the UMF entity, if the information carried in the response message is determined, If the second verification parameter is legal, the key that is carried in the response message is a key generated by the security function entity for the UMF entity.
- Step 601 The UE sends an initial attach request to the SSF entity in the base station, where the initial attach request carries at least the IMSI of the UE;
- Step 602 The SSF entity initiates an authentication request to the security function entity.
- Step 603 The security function entity initiates an authentication process for the UE, and completely authenticates the UE.
- Step 604 The security function entity sends an authentication success message to the SSF entity.
- Step 605 The SSF entity selects an appropriate UMF entity for the UE according to the information of the UE, and Obtaining the identifier information of the UMF entity, where the SSF can view the subscription information of the UE, and find a suitable UMF entity for the UE;
- Step 606 The SSF entity sends the identifier of the UMF entity selected by the UE to the security function entity.
- the identifier of the UMF entity may be the identity information assigned by the operator to each UMF, and may be the address information of the UMF.
- UMF's logo which can be within an operator or an internationally unique identifier;
- Step 607 The security function entity generates a first random number.
- Step 608 The security function entity returns an acknowledgement message to the SSF entity, where the acknowledgement message carries at least the first random number and the identity identifier of the UE.
- the acknowledgement message further carries the certificate of the security function entity.
- Step 609 The SSF entity forwards the initial attach request to the UMF entity, and adds a first random number to the initial attach request.
- the initial attach request further carries a certificate of the security function entity.
- Step 610 The UMF entity generates a second random number.
- Step 611 The UMF entity generates a security context request, where the security context request carries, the identifier of the UMF entity, the identity of the UE, the first random number, and the second random number, and the security context request is signed by using the private key of the UMF entity.
- the security context request further carries a certificate of the UMF entity, and is encrypted by using a public key of the security function entity, and the security context request is sent to the security function entity;
- Step 612 The security function entity receives the security context request sent by the UMF entity, decrypts the security context request by using the private key of the security function entity, and verifies whether the signature of the security context request is correct, and verifies the content carried in the security context request. Whether the identifier of the UMF is the same as the identifier of the UMF entity provided by the SSF entity;
- Step 613 The security function entity determines that the security function request is successfully decrypted by using the private key of the security function entity, verifying that the signature of the security context request is correct, and verifying the UMF identifier carried in the security context request and the UMF entity provided by the SSF entity.
- the key of the UMF entity (Kmm) is generated if the identifiers are the same;
- Step 614 The security function entity sends a security context response to the UMF entity (Security Context Response), the security context response carries the key encrypted by the UMF public key and the second random number, and the UMF entity verifies whether the key carried in the security context response is assigned to itself according to the second random number. Key.
- UMF entity Security Context Response
- the security function entity verifies that the UMF entity that requests the key is a UMF entity that forwards the message to the SSF entity, and when the key is sent to the UMF entity, the public key of the UMF entity is used for encryption protection. It is enabled to verify whether the key requestor is a function of an entity capable of obtaining a key without relying on a secure connection between the underlying network elements.
- the specific embodiment 2 shows that the specific process of verifying the key requesting party is as shown in FIG. 7 , and the specific description is as follows:
- the process of the authentication described in the specific embodiment is the same as the authentication process in the first embodiment. For details, refer to the description of the steps 601 to 603 in the specific embodiment 1. Only the process after authentication will be described below.
- Step 704 The security function entity generates a timestamp.
- Step 705 The security function entity sends an authentication success message to the SSF entity, where the authentication success message includes the generated timestamp.
- the authentication success message also carries the certificate of the security function entity.
- Step 706 The SSF entity selects an appropriate UMF entity for the UE according to the information of the UE, and obtains an identifier of the selected UMF entity.
- Step 707 The SSF entity forwards the attach request to the UMF entity, and the attach request includes the timestamp.
- the attach request further includes a certificate of the security function entity, where the certificate of the security function entity includes a public key;
- Step 708 The UMF entity generates a random number.
- Step 709 The UMF entity sends a security context request to the security function entity, where the security context request is encrypted by the public key of the security function entity, where the security context request carries the identifier, timestamp, and random number of the UMF entity.
- the security context request also carries the certificate of the UMF entity, and the security context request is signed by the private key of the UMF entity;
- Step 710 After the security function entity verifies that the signature of the security context request is correct, the security function entity decrypts the security context request successfully by using the private key of the security function entity, and then verifies the timestamp. Whether it expires, if it expires, the security context request is not processed, and the SSF entity is notified that the timestamp expires;
- Step 711 The security function entity sends a request message (UMF ID Request) for the UMF entity identifier to the SSF entity, if the timestamp is not expired, and the request message carries the identity identifier of the UE.
- UMF ID Request UMF ID Request
- Step 712 The SSF entity sends the identifier of the UMF entity to the security function entity.
- Step 713 The security function entity verifies whether the identifier of the UMF entity that performs the security context request is the same as the identifier of the UMF entity provided by the SSF entity.
- Step 714 The security function entity generates a security context of the UMF entity if it determines that the identifier of the UMF entity that performs the security context request is the same as the identifier of the UMF entity provided by the SSF entity.
- Step 715 The security function entity replies a security context response message (Security Context Response) to the UMF entity, where the security context response message is encrypted with a public key of the UMF entity, where the security context response message carries a security context and a random number.
- a security context response message Security Context Response
- the time stamp enables the security function entity to control the time when the external reception is turned on.
- the security function entity can know which UE is open to the window, and the restriction is also used to verify whether the key requestor can obtain the key. The functionality of the entity.
- Step 801 The security function entity receives the request message sent by the first core network element, where the request message carries the identifier of the first core network element, the identity information of the terminal UE, and the first token.
- Step 802 If the security function entity determines that the first token is legal according to the identifier of the first core network element and the identity information of the UE, determine that the first core network element provides the Key.
- the security function entity before the security function entity receives the request message sent by the first core network element, the security function entity generates a first freshness parameter; the security function entity The first freshness parameter is sent to the second core network element, and the second core network The network element generates the first token according to the identifier of the first core network element attached to the UE, the identity information of the UE, the first freshness parameter, and a shared key.
- the shared key is generated by the security function entity and sent to the second core network element, or the shared key is generated by the security function entity and the second core network element.
- the security function entity generates, according to the identifier of the first core network element, the identity information of the UE, the first freshness parameter corresponding to the first core network element, and the shared key. And determining, by the second token, that the first token is the same as the second token, determining that the first token is legal.
- the first token is used by the second core network element, the private key of the second core network element, and the first core network element attached by the UE.
- the identity, the identity information of the UE, and the second freshness parameter are generated.
- the security function entity sends the identity information of the UE, the first token, and the identifier of the first core network element to the second core network element; the security function entity receives the The second core network element returns a response message, where the response message is used to indicate that the first token is legal, wherein the response message is provided by the second core network element according to the security function entity.
- Generating the second token by the identity information of the UE, the identifier of the first core network element, the second freshness parameter corresponding to the identity information of the UE, and the private key of the second core network element, and Determining that the first token is the same as the second token and then returns.
- the first core network element is a UMF entity; the second core network element is an AMF entity or an entity having an SSF function.
- the specific embodiment 3 shows that the specific process of verifying the key requesting party is as shown in FIG. 9 , and the specific description is as follows:
- the process of the authentication described in the specific embodiment is the same as the authentication process in the specific embodiment 1. For details, refer to the description of the steps 601 to 603. After the process.
- Step 904 The security function entity generates a shared secret between the security function entity and the SSF entity. Key, expressed as Kssf;
- Step 905 The security function entity generates a timestamp.
- Step 906 The security function entity sends an authentication success message to the SSF entity, where the authentication success message carries a timestamp.
- the authentication success message also carries the shared key Kssf of the SSF entity, and the shared key Generated by the security function entity, the shared key Kssf of the SSF entity may also be generated by the SSF entity or the entity having the SSF function;
- Step 907 The SSF entity selects an appropriate UMF entity and obtains an identifier of the UMF entity.
- Step 908 The SSF entity generates a token, and the parameters for generating the token include the identity information of the UE, the identifier of the UMF, the timestamp, and the shared key.
- Step 909 The SSF entity forwards the attach message to the UMF entity, where the attach message carries the identity information of the UE and the token.
- Step 910 The UMF entity sends a security context request (Security Context Request) to the security function entity, where the security context request carries the identifier of the UMF entity, the identity information of the UE, and the token.
- Security Context Request a security context request
- Step 911 The security function entity calculates a new token according to the information carried in the security context request, and compares the new token with the token received from the UMF entity.
- Step 912 If the new token is the same as the token received from the UMF entity, generate a key Kmm;
- Step 913 The security function entity sends a security context response to the UMF entity, where the security context response carries a security context, that is, a key Kmm and a KSI.
- the token is generated by the SSF entity and the security function entity respectively, and the security function entity determines whether the key requester is an entity capable of obtaining the key by verifying whether the two tokens are the same.
- the specific embodiment needs to rely on the security protection of the underlying network element, but reduces the process of the security function entity interacting with the SSF entity to obtain the UMF identifier compared to other specific embodiments.
- step 1001 to step 1004 in this embodiment is the same as the authentication process in the first embodiment, and is not repeated here. Only the process after authentication is described below.
- Step 1005 The SSF entity selects an appropriate UMF entity, obtains an identifier of the UMF entity, and generates a random number.
- Step 1006 The SSF entity generates a token by using a private key of the SSF entity, an identifier of the UMF entity, identity information of the UE, and a random number.
- Step 1007 The SSF entity forwards the attach request to the UMF entity, where the attached message carries the generated token;
- Step 1008 The UMF entity sends a security context request to the security function entity, where the security context request carries the UMF identifier, the token, and the identity information of the UE.
- Step 1009 The security function entity sends a request message to the SSF entity for the UMF identifier, where the request message carries the identity information of the UE, the token, and the identifier of the UMF entity.
- Step 1010 The SSF entity verifies that the generated token is the same as the token obtained from the security function entity.
- Step 1011 If the SSF entity is determined to be the same, the SSF entity sends a response message to the security function entity, where the response message carries the same indication information as the token;
- Step 1012 The security function entity generates a context related to the UMF entity, such as a key Kmm;
- Step 1013 The security function entity replies to the UMF entity with a security context response message, where the security context response message carries the context related to the UMF entity.
- the token is generated by using the private key of the SSF entity, and the generated token is verified by the SSF entity to be the same as the token obtained from the security function entity, so that the security function entity unconditionally believes that the information fed back by the SSF entity is correct.
- This particular embodiment relies on the underlying security protection between network elements.
- the process of verifying the key requesting party is as follows:
- Step 1101 The security function entity acquires an identifier of the UMF entity attached to the terminal UE.
- Step 1102 The security function entity generates a key of the UE and a verification parameter for the UMF entity.
- Step 1103 The security function entity sends configuration information to the UMF entity, where the configuration information is signed by the private key of the security function entity, and then encrypted by using the public key of the UMF entity.
- the configuration information includes the key, identity information of the UE, and the verification parameter;
- Step 1104 The security function entity receives the verification information returned by the UMF entity, and the verification information is obtained by the UMF entity encrypting the verification parameter by using the key;
- Step 1105 After the security function entity determines that the verification information is legal, it is determined that the key is successfully delivered.
- Step 1201 The UE sends an initial attach request to the SSF entity in the base station, where the initial attach request carries at least the IMSI of the UE.
- Step 1202 The SSF entity forwards the initial attach request to the security function entity to initiate an authentication request.
- Step 1203 The security function entity initiates an authentication process for the UE, and completely authenticates the UE.
- Step 1204 The security function entity sends an authentication success message to the SSF entity.
- Step 1205 The SSF entity selects an appropriate UMF entity for the UE according to the information of the UE, and obtains the identifier information of the UMF entity.
- Step 1206 The SSF entity sends a UMF identifier providing message to the security function entity, where the UMF identifier providing message carries the identifier information of the selected UMF entity and the certificate of the UMF entity.
- Step 1207 The security function entity generates a key related to the UMF entity, such as Kmm;
- Step 1208 The security function entity generates a random number.
- Step 1209 The security function entity acquires the public key of the UMF entity according to the identifier of the UMF entity, and sends a security context providing message to the UMF entity, where the security context providing message is encrypted by using the public key of the UMF entity, and is performed by using the private key of the security function entity. a signature, where the security context provides a security context (including a UMF entity-related key) of the UMF entity, identity information of the UE, and a random number;
- Step 1210 The UMF entity encrypts the random number by using the key received from the security function entity, and returns a security context providing an acknowledgement message to the security function entity, where the message carries the encrypted The data obtained;
- Step 1211 The security function entity uses the key of the UMF entity to perform confidentiality on the received data, and then verifies whether the data obtained after decryption is the same as the generated random number. If they are the same, the UMF identifier providing confirmation message is returned to the SSF entity. To notify the SSF entity that the key is successfully delivered.
- the device mainly includes:
- the first processing module 1301 is configured to receive a request message sent by the user management function UMF entity;
- the second processing module 1302 is configured to decrypt the information in the request message by using a private key of the device, and perform signature verification on the decrypted information by using a public key in the certificate of the UMF entity, and obtain Information carried in the request message;
- the third processing module 1303 is configured to: if it is determined that the first verification parameter carried in the request message is legal, and that the identifier of the UMF entity carried in the request message is the same as the identifier of the UMF entity attached to the terminal UE, Determining to provide the UMF entity with a key for the UE.
- a device for verifying a key requesting party is provided in the fifth embodiment of the present application.
- the device mainly includes:
- the receiving module 1401 is configured to receive a request message sent by the first core network element, where the request message carries the identifier of the first core network element, the identity information of the terminal UE, and the first token.
- the processing module 1402 is configured to: if the first token is legal according to the identifier of the first core network element and the identity information of the UE, determine to provide the key for the first core network element .
- a device for verifying a key requesting party is provided in the fifth embodiment of the present application.
- the device mainly includes:
- the obtaining module 1501 is configured to acquire an identifier of a user management function UMF entity attached to the terminal UE;
- a first processing module 1502 configured to generate, by the UMF entity, a key of the UE and verify parameter
- a sending module 1503 configured to send configuration information to the UMF entity, where the configuration information is signed by a private key of the security function entity, and then encrypted by using a public key of the UMF entity, where the configuration information includes the key, Identity information of the UE and the verification parameter;
- the receiving module 1504 is configured to receive verification information returned by the UMF entity, where the verification information is obtained by the UMF entity encrypting the verification parameter by using the key;
- the second processing module 1505 is configured to determine that the key is successfully delivered after determining that the verification information is legal.
- the device for verifying a key requesting party.
- the device mainly includes a processor 1601, a memory 1602, and a communication interface 1603.
- the memory 1602 stores a preset program
- the processor 1601 reads a program in the memory 1602, and executes the following process according to the program:
- the processor is configured to perform the functions of the first processing module, the second processing module, and the third processing module in the fourth embodiment, where the communication interface is used to complete the processing of each processing module in the fourth embodiment under the control of the processor.
- the device mainly includes a processor 1701, a memory 1702, and a communication interface 1703.
- the memory 1702 stores a preset program
- the processor 1701 reads the memory 1702. In the program, follow the procedure to perform the following process:
- the first token is legal according to the identifier of the first core network element and the identity information of the UE, determining to provide the key for the first core network element.
- the processor is configured to perform the functions of the processing module in the fifth embodiment
- the communication interface is configured to perform the function of the receiving module in the fifth embodiment under the control of the processor.
- the device mainly includes a processor 1801, a memory 1802, and a communication interface 1803.
- the memory 1802 stores a preset program
- the processor 1801 reads a program in the memory 1802, and executes the following process according to the program:
- the processor, the memory and the communication interface are connected by a bus, and the bus architecture may include any number of interconnected buses and bridges, specifically represented by one or more processors and memories represented by the processor.
- the various circuits of the memory are linked together.
- the bus architecture can also link various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and, therefore, will not be further described herein.
- the bus interface provides an interface.
- the communication interface can be a plurality of components, including a transmit interface and a transceiving interface, providing means for communicating with various other devices on a transmission medium.
- the processor is responsible for managing the bus architecture and communication Often processing, the memory can store the data that the processor uses when performing operations.
- embodiments of the present application can be provided as a method, system, or computer program product.
- an entirely hardware embodiment an entirely software embodiment, or a combination of software and hardware aspects may be employed.
- it 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 and optical storage, etc.) including computer usable program code.
- 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)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
一种验证密钥请求方的方法和设备,用以在初始入网过程中实现验证密钥请求方是否为能够得到密钥的实体的功能。方法为:安全功能实体接收用户管理功能UMF实体发送的请求消息;采用所述安全功能实体的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息;若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
Description
本申请涉及通信技术领域,尤其涉及一种验证密钥请求方的方法和设备。
长期演进(Long Term Evolution,LTE)***架构如图1所示,其中,移动管理实体(Mobility management entity,MME)是核心网侧负责安全、移动性管理和会话管理的网元。安全,即终端(User Equipment,UE)在初始入网时需要和网络进行相互认证。在相互认证后,UE和核心网会生成密钥。生成密钥后,UE和MME会进行算法协商,也就是安全能力协商。移动性管理是记录UE的位置信息,根据UE的位置信息为UE选择合适的用户面网元设备。会话管理负责建立UE的用户面链路。归属签约用户服务器(Home subscriber server,HSS)用于存储用户的签约信息。演进UMTS陆地无线接入网(Evolved UMTS Terrestrial Radio Access Network,E-UTRAN;UMTS,Universal Mobile Telecommunications System,通用移动通信***)是LTE中的空口接入部分,通常叫做演进型基站(eNodeB)。
如图2所示的5G架构中,将MME拆分为鉴权(NG Auth.Function,AUF)、用户管理功能(UE Management Function,UMF)、会话管理(Session Management Function,SMF)3个功能。在5G中,增加了切片(slice)的概念,一个切片可以理解为某一种特殊用户做特定服务的功能的集合。比如,slice A专门针对物联网设备。每个slice都有各自的控制面网元(Control Plane Network Function,CP NF),主要是SM。每一个slice内的用户面网元(User Plane Network Function,UP NF)为分组数据网网关(Packet Data Network Gateway,P-GW),用于将UE的数据转发到合适的服务中。公共CP NF(Common CP NF)是几个slice共用的控制面功能,包含有UMF和AUF。
切片选择功能(Slice select function,SSF)用于帮助UE选择slice。
鉴权信任状存储处理功能实体(Authentication Credential Repository and Processing Function,ARPF)在统一数据管理实体(Unified Data Management,UDM)中,用于存储用户的签约数据。其中,AUF作为一个安全功能,可以独立部署,也可以与具有UMF功能的实体共同部署。AUF可以进一步分为安全锚点(Security Anchor Function,SEAF)、安全上下文管理功能(Security Context Management Function,SCMF)和安全策略管理功能等实体,其中,SEAF实体用于与UE和鉴权服务器交互,在鉴权流程后接收中间密钥,SCMF实体用于从SEAF实体获得密钥并进一步衍生出其它密钥。这些功能实体也可能不会详细划分,但相应的功能都在AUF中体现。
可以看出,5G到4G最大的演进就是把MME拆分开,拆分后的一部分作为公共功能,一部分放到特定的slice内,为特定的slice服务。
LTE中,UE入网发起附着(attach)流程,其中包含有安全流程,安全流程包括:双向认证、密钥生成和安全能力协商三个过程。双向认证是指UE和核心网互相认证。认证结束后可以达到的效果是:UE认为核心网是真实的,核心网认为UE是真实的。认证后或认证过程中,会生成保护NAS消息的密钥。密钥生成后,会开始UE和MME之间的安全能力协商。安全能力,即后续使用的加密算法和完整性保护算法。
现有5G安全流程如图3所示,具体地:
步骤1,UE发起附着请求(Attach Request);
步骤2,UE和SEAF实体之间完成互相鉴权;
步骤3,UMF实体向SEAF实体请求安全上下文;
步骤4,UE和UMF实体发起NAS MM SMC流程,是MM算法协商流程;
步骤5,SSF实体转发Attach Request给UMF实体;
UE和UMF实体完成剩下的附着流程;
步骤6,UMF实体转发会话管理请求给SMF实体;
步骤7,SMF实体获得安全策略;
步骤8,SMF实体从SEAF实体处获得UE的用户面安全上下文,尚未定义用户面安全上下文的内容;
步骤9,SMF实体发起用户面NAS UP SMC流程;
步骤10,开始其它安全流程。
根据5G安全流程,可以看出,因为MME的拆分,UMF实体是处理NAS信令安全的实体,但是UMF实体没有安全功能。生成密钥的SEAF实体与UMF实体是独立,因此UMF实体需要向SEAF实体请求密钥。
可见,在5G安全流程中,在UE初始入网并鉴权成功后,附着消息会转发给UMF实体,UMF实体需要向SEAF实体请求后续需要使用的安全密钥,但是,由于网络中只有一个SEAF实体,但是有多个UMF实体。因此在初始入网过程中,SEAF实体需要确定请求密钥的UMF实体是否就是UE附着到的UMF实体。
发明内容
本申请实施例提供一种验证密钥请求方的方法和设备,用以在初始入网过程中实现验证密钥请求方是否为能够得到密钥的实体的功能。
本申请实施例提供的具体技术方案如下:
第一方面,本申请实施提供了一种验证密钥请求方的方法,包括:安全功能实体接收用户管理功能UMF实体发送的请求消息;所述安全功能实体采用所述安全功能实体的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息;所述安全功能实体若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
该方法中,安全功能实体通过采用安全功能实体的私钥对UMF实体发送
的请求消息进行解密,以及采用UMF实体的证书中的公钥对解密后的信息进行签名认证通过后,根据验证请求消息中携带的第一验证参数、UMF实体的标识以及终端附着的UMF实体的标识,确定请求密钥的UMF实体是否为能够得到密钥的UMF实体。
可能的实施方式中,所述方法还包括:所述安全功能实体生成新鲜性参数(fresh);所述安全功能实体通过核心网网元将所述新鲜性参数通知给所述UE附着的UMF实体,由所述UE附着的UMF实体将所述新鲜性参数作为所述第一验证参数携带在所述请求消息中。该实现方式中,安全功能实体将新鲜性参数通过核心网网元通知给UE附着的UMF实体,由该UMF实体将该第一新鲜性参数作为第一验证参数携带在请求消息中,从而使得安全功能实体能够验证请求密钥的UMF实体是否为能够得到密钥的UMF实体。
可能的实施方式中,所述安全功能实体确定所述请求消息中携带的第一验证参数合法,包括:所述安全功能实体确定所述第一验证参数与所述新鲜性参数相同,或,确定所述新鲜性参数在设定范围内,则确定所述安全上下文请求中携带的第一验证参数合法。该实现方式中,配置了采用新鲜性参数验证第一验证参数合法的实施方式。
可能的实施方式中,所述请求消息中还携带第二验证参数,所述第二验证参数由所述UMF实体生成;所述方法还包括:所述安全功能实体向所述UMF实体返回响应消息,其中,所述响应消息中至少携带为所述UMF实体生成的所述密钥以及所述第二验证参数,且所述响应消息中携带的信息采用所述UMF实体的公钥进行加密,由所述UMF实体采用所述UMF实体的私钥对所述响应消息进行解密后,若确定所述响应消息中携带的所述第二验证参数合法,则确定所述响应消息中携带的所述密钥为所述安全功能实体为所述UMF实体生成的密钥。该实现方式中,UMF实体通过验证安全功能实体返回的响应消息中的第二验证参数合法,进一步确定该响应消息中携带的密钥为该UMF实体的密钥,进一步提高安全性。
第二方面,本申请实施例提供了一种验证密钥请求方的方法,包括:安
全功能实体接收第一核心网网元发送的请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌;所述安全功能实体若根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
该方法中,安全功能实体在验证第一核心网网元的请求消息中携带的第一令牌是否合法,达到验证请求密钥的UMF实体是否为能够得到密钥的UMF实体的效果。
可能的实施方式中,所述安全功能实体接收第一核心网网元发送的请求消息之前,所述方法还包括:所述安全功能实体生成第一新鲜性参数;所述安全功能实体将所述第一新鲜性参数发送给第二核心网网元,由所述第二核心网网元根据所述UE附着的第一核心网网元的标识、所述UE的身份信息、所述第一新鲜性参数以及所述共享密钥生成所述第一令牌。该实现方式中,核心网网元结合共享密钥以及第一新鲜性参数生成第一令牌,使得安全功能实体能够根据本地保存的核心网网元相关的参数验证第一令牌是否合法。
可能的实施方式中,所述共享密钥由所述安全功能实体生成后发送给所述第二核心网网元;或者,所述共享密钥由所述安全功能实体和所述第二核心网网元各自生成。
可能的实施方式中,所述安全功能实体根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,包括:所述安全功能实体根据所述第一核心网网元的标识、所述UE的身份信息、所述第一核心网网元对应的第一新鲜性参数、以及所述共享密钥生成第二令牌,若确定所述第一令牌与所述第二令牌相同,则确定所述第一令牌合法。该实现方式中,通过配置安全功能实体生成令牌的方式,使得安全功能实体能够采用自身生成的令牌验证核心网网元发送的令牌是否合法。
可能的实施方式中,所述第一令牌由第二核心网网元采用所述第二核心网网元的私钥、所述UE附着的第一核心网网元的标识、所述UE的身份信息以及第二新鲜性参数生成。
可能的实施方式中,所述安全功能实体根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,包括:所述安全功能实体将所述UE的身份信息、所述第一令牌以及所述第一核心网网元的标识发送给第二核心网网元;所述安全功能实体接收所述第二核心网网元返回响应消息,所述响应消息用于指示所述第一令牌合法,其中,所述响应消息由所述第二核心网网元根据所述安全功能实体提供的所述UE的身份信息、所述第一核心网网元的标识、所述UE的身份信息对应的第二新鲜性参数、以及所述第二核心网网元的私钥生成第二令牌,并确定所述第一令牌与所述第二令牌相同后返回。
第三方面,本申请实施例提供了一种验证密钥请求方的方法,包括:安全功能实体获取终端UE附着的用户管理功能UMF实体的标识;所述安全功能实体为所述UMF实体生成所述UE的密钥以及验证参数;所述安全功能实体向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;所述安全功能实体接收所述UMF实体返回的验证信息,所述验证信息由所述UMF实体采用所述密钥对所述验证参数加密后得到;所述安全功能实体确定所述验证信息合法后,确定所述密钥下发成功。
该方法中,安全功能实体主动将为UMF实体生成的密钥以及验证参数下发给请求UMF实体,并接收UMF实体返回的验证信息,在验证UMF实体返回的验证信息合法后,确定密钥下发成功,从而达到了验证请求密钥的UMF实体是否为能够得到密钥的UMF实体的效果,且简化了密钥的配置流程。
第四方面,本申请实施例提供了一种验证密钥请求方的设备,该设备具有实现上述第一方面、第二方面或第三方面的方法实现中的安全功能实体的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现,所述硬件或软件包括一个或多个与上述功能相对应的模块。
第五方面,本申请实施例提供了一种验证密钥请求方的设备,包括处理
器、存储器和通信接口,其中,存储器中保存有预设的程序,处理器读取存储器中的程序,按照该程序执行上述第一方面、第二方面或第三方面的方法。
第六方面,本申请实施例提供了一种验证密钥请求方的***,包括:用户管理功能UMF实体,用于向安全功能实体发送请求消息;安全功能实体,用于接收所述UMF实体发送的请求消息,采用所述安全功能实体的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息,若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
第七方面,本申请实施例提供了一种验证密钥请求方的***,包括:第一核心网网元,用于向安全功能实体发送请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌;
安全功能实体,用于接收第一第一核心网网元发送的请求消息,根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
第八方面,本申请实施例提供了一种验证密钥请求方的***,包括:安全功能实体,用于获取终端UE附着的用户管理功能UMF实体的标识,为所述UMF实体生成所述UE的密钥以及验证参数,向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;
所述UMF实体,用于接收所述安全功能实体发送的配置信息,采用配置信息中携带的所述密钥对所述验证参数加密后得到验证信息,将所述验证信息发送给所述安全功能实体;
所述安全功能实体,用于接收所述UMF实体返回的验证信息后,确定所述密钥下发成功。
图1为LTE***架构示意图;
图2为5G架构示意图;
图3为现有的5G安全流程示意图;
图4为本申请实施例中***架构示意图;
图5为本申请第一实施例中验证密钥请求方的流程示意图;
图6为本申请具体实施例一中验证密钥请求方的流程示意图;
图7为本申请具体实施例二中验证密钥请求方的流程示意图;
图8为本申请第二实施例中验证密钥请求方的流程示意图;
图9为本申请具体实施例三中验证密钥请求方的流程示意图;
图10为本申请具体实施例四中验证密钥请求方的流程示意图;
图11为本申请第三实施例中验证密钥请求方的流程示意图;
图12为本申请具体实施例五中验证密钥请求方的流程示意图;
图13为本申请第四实施例中验证密钥请求方的设备结构示意图;
图14为本申请第五实施例中验证密钥请求方的设备结构示意图;
图15为本申请第六实施例中验证密钥请求方的设备结构示意图;
图16为本申请第七实施例中验证密钥请求方的设备结构示意图;
图17为本申请第八实施例中验证密钥请求方的设备结构示意图;
图18为本申请第九实施例中验证密钥请求方的设备结构示意图。
在5G网络的初始入网过程中,实现验证密钥请求方是否为能够得到密钥的实体的功能,本申请实施例提供了一种验证密钥请求方的方法及设备。
以下结合附图对本申请的实施方式进行详细说明。
以下各实施例所基于的5G***架构如图4所示,控制面包括AUF、UMF、会话管理功能(Session Management,SMF)、策略控制功能(Policy Control
Function,PCF)、SSF、UDM、网络展出功能(Network Exposure Function,NEF)以及NF存储功能(NF Repository Function,NRF)等。AUF可以进一步分为安全锚点(Security Anchor Function,SEAF)、安全上下文管理功能和安全策略管理功能(Security Policy Control Function,SPCF)、鉴权服务器功能(Authentication Server Function,AUSF)等实体,其中,SEAF实体用于与UE和鉴权服务器交互。ARPF是UDM的一部分。
该***架构中所描述的各实体可以是分别独立设置在不同的设备上,也可以是至少两个实体集成在同一个设备上,其它实体设置在其它设备上,该至少两个实体可以是该***架构所描述的部分实体,也可以是全部实体。以下各实施例中所描述的至少两个实体如果集成在同一个设备上,则该至少两个实体之间的信息交互应当理解为该设备的内容交互。
其中,以AUF作为安全能力协商的中心,由AUF,更具体的是SEAF实体或SCMF实体或AUSF实体,验证请求密钥的核心网网元(如UMF实体)是否为能够得到密钥的实体。
以下各实施例中,安全功能实体可以为5G网络中的AUF实体,具体地,可以为AUF实体中的SCMF实体或SEAF实体或AUSF实体,也可能为独立的SEAF实体,还可以为UMF中的SEAF实体,还可能是独立的AUSF功能实体。以下各实施例中为了简便,只画出SSF逻辑功能,其可以为独立的SSF实体,也可以为具有SSF功能的实体,如UMF实体。UMF实体,是管理UE移动性的实体,类似于LTE中的MME,在5G设计初期被称为MM实体,后期称作AMF实体。
以下各实施例中,UE附着的UMF实体,是指UE最终附着到的UMF实体,不是UE初始附着的时候接入的默认UMF实体。
本申请第一实施例中,如图5所示,验证密钥请求方的详细方法流程如下:
步骤501:安全功能实体接收UMF实体发送的请求消息。
步骤502:安全功能实体采用所述安全功能实体的私钥对所述请求消息中
的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息。
步骤503:安全功能实体若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
本申请第一实施例中,根据请求消息中携带的第一验证参数的获得方式的不同,至少有以下两种具体实施方式:
第一,安全功能实体获取核心网网元提供的所述UE附着的UMF实体的标识;其中,UE附着的UMF实体是指UE最终附着到的UMF实体,不是初始附着的时候接入的默认UMF实体。所述安全功能实体生成所述UE附着的UMF实体的标识所对应的第一新鲜性参数;所述安全功能实体通过所述核心网网元将所述第一新鲜性参数通知给所述UE附着的UMF实体,可选的,安全功能实体将所述安全功能实体的证书也通知给所述UE附着的UMF实体,UMF实体也可以通过其他方式获得安全功能实体的证书。由UE附着的UMF实体将所述第一新鲜性参数作为所述第一验证参数携带在所述请求消息中。例如,第一新鲜性参数可以为随机数、计数器值、当时的时间或该时间的衍生值等,需要说明的是,此处并不限制第一新鲜性参数的具体形式。
该具体实施方式中,安全功能实体确定所述第一验证参数与所述第一新鲜性参数相同或相近,则确定所述安全上下文请求中携带的第一验证参数合法。
具体地,该核心网网元可以为AMF实体,或具有SSF功能的实体。
第二,所述安全功能实体接收用户管理功能UMF实体发送的请求消息之前,所述安全功能实体生成第二新鲜性参数;所述安全功能实体通过核心网网元将所述第二新鲜性参数发送给所述UE附着的UMF实体,可选的,安全功能实体将所述安全功能实体的证书也通知给所述UE附着的UMF实体,UMF实体也可以通过其他方式获得安全功能实体的证书。由所述UE附着的UMF实体将所述第二新鲜性参数作为所述第一验证参数携带在所述请求消息
中。
需要说明的是,此处不限制第二新鲜性参数的具体形式。例如,第二新鲜性参数可以为随机数、时间戳或时间戳的衍生值、计数器等。
一个具体实现中,若第二新鲜性参数在设定范围内有效,则所述安全功能实体若确定所述第二新鲜性参数在设定范围内,则确定所述请求消息中携带的第一验证参数合法。例如,第二新鲜性参数为时间戳,则安全功能实体若确定时间戳在设定的时间范围内,即该时间戳未过期,则确定所述请求消息中携带的第一验证参数合法。
一个具体实施方式中,所述请求消息中还携带第二验证参数,所述第二验证参数由所述UMF实体生成。
需要说明的是,若第一验证参数和第二验证参数属于同一类参数,例如都为随机数,则应保证第一验证参数和第二验证参数的值不相同。
该具体实施方式中,所述安全功能实体向所述UMF实体返回响应消息,其中,所述响应消息中至少携带为所述UMF实体生成的所述密钥以及所述第二验证参数,且所述响应消息中携带的信息采用所述UMF实体的公钥进行加密,由所述UMF实体采用所述UMF实体的私钥对所述响应消息进行解密后,若确定所述响应消息中携带的所述第二验证参数合法,则确定所述响应消息中携带的所述密钥为所述安全功能实体为所述UMF实体生成的密钥。
以下通过两个具体实施例对本申请第一实施例所提供的验证密钥请求方的过程进行详细说明。
具体实施例一,验证密钥请求方的具体过程如图6所示,具体描述如下:
步骤601:UE通过基站中转向SSF实体发送初始附着请求,该初始附着请求中至少携带UE的IMSI;
步骤602:SSF实体向安全功能实体发起鉴权请求;
步骤603:安全功能实体发起对UE的鉴权过程,完全对UE的鉴权;
步骤604:安全功能实体向SSF实体发送鉴权成功消息;
步骤605:SSF实体根据UE的信息为该UE选择合适的UMF实体,并
获取该UMF实体的标识信息,其中,SSF可以查看UE的签约信息,为其找一个合适的UMF实体;
步骤606:SSF实体将为该UE选择的UMF实体的标识发送给安全功能实体,UMF实体的标识可以是运营商分配给每个UMF的身份信息,可以是UMF的地址信息,总之是可以唯一标识UMF的标识,其范围可以是某个运营商内,也可以是国际唯一的标识;
步骤607:安全功能实体生成第一随机数;
步骤608:安全功能实体向SSF实体返回确认消息,该确认消息中至少携带第一随机数和UE的身份标识,可选的,该确认消息中还携带安全功能实体的证书;
步骤609:SSF实体转发初始附着请求给UMF实体,该初始附着请求中增加了第一随机数,可选的,该初始附着请求中还携带安全功能实体的证书;
步骤610:UMF实体生成第二随机数;
步骤611:UMF实体生成安全上下文请求,该安全上下文请求中携带、UMF实体的标识、UE的身份标识、第一随机数、第二随机数,该安全上下文请求采用UMF实体的私钥进行签名后,可选的,该安全上下文请求中还携带UMF实体的证书,采用安全功能实体的公钥进行加密,将该安全上下文请求发送给安全功能实体;
步骤612:安全功能实体接收UMF实体发送的安全上下文请求,并采用该安全功能实体的私钥对安全上下文请求进行解密,以及验证该安全上下文请求的签名是否正确,以及验证安全上下文请求中携带的UMF的标识与SSF实体所提供的UMF实体的标识是否相同;
步骤613:安全功能实体确定采用该安全功能实体的私钥对安全上下文请求解密成功,验证该安全上下文请求的签名正确,以及验证安全上下文请求中携带的UMF的标识与SSF实体所提供的UMF实体的标识相同的情况下,生成UMF实体的密钥(Kmm);
步骤614:安全功能实体向UMF实体发送安全上下文响应(Security
Context Response),该安全上下文响应中携带采用UMF的公钥加密后的密钥以及第二随机数,由UMF实体根据第二随机数验证该安全上下文响应中携带的密钥是否为分配给自己的密钥。
该具体实施例一中,实现了安全功能实体验证请求密钥的UMF实体是否为SSF实体转发消息的UMF实体,并且在向UMF实体发送密钥时,使用了UMF实体的公钥进行加密保护,使得能够在不依赖于底层网元之间的安全连接的情况下,验证密钥请求方是否为能够得到密钥的实体的功能。
具体实施例二,验证密钥请求方的具体过程如图7所示,具体描述如下:
该具体实施例中步骤701至步骤703所描述的鉴权的过程与具体实施例一中的鉴权过程相同,可参见具体实施例一中步骤601至步骤603的描述,此处不再重复,以下仅描述鉴权之后的过程。
步骤704:安全功能实体生成时间戳;
步骤705:安全功能实体发送鉴权成功消息给SSF实体,该鉴权成功消息中包含生成的时间戳,可选的,该鉴权成功消息中还携带安全功能实体的证书;
步骤706:SSF实体根据UE的信息,为该UE选择合适的UMF实体,并获取所选择的UMF实体的标识;
步骤707:SSF实体转发附着请求给UMF实体,该附着请求中包含该时间戳,可选的,该附着请求中还包含安全功能实体的证书,该安全功能实体的证书中包含公钥;
步骤708:UMF实体生成随机数;
步骤709:UMF实体向安全功能实体发送安全上下文请求,该安全上下文请求采用安全功能实体的公钥加密,该安全上下文请求中携带有UMF实体的标识、时间戳以及随机数,可选的,该安全上下文请求中还携带UMF实体的证书,且该安全上下文请求采用UMF实体的私钥签名;
步骤710:安全功能实体验证所述安全上下文请求的签名正确后,采用所述安全功能实体的私钥对所述安全上下文请求进行解密成功后,验证时间戳
是否过期,如果过期,则不处理该安全上下文请求,并告知SSF实体,该时间戳过期;
步骤711:安全功能实体如果确定时间戳未过期,则向SSF实体发送对UMF实体标识的请求消息(UMF ID Request),该请求消息中携带UE的身份标识;
步骤712:SSF实体将UMF实体的标识发送给安全功能实体;
步骤713:安全功能实体验证进行安全上下文请求的UMF实体的标识,与SSF实体提供的UMF实体的标识是否相同;
步骤714:安全功能实体如果确定进行安全上下文请求的UMF实体的标识,与SSF实体提供的UMF实体的标识相同,则生成该UMF实体的安全上下文;
步骤715:安全功能实体向UMF实体回复安全上下文响应消息(Security Context Response),该安全上下文响应消息用UMF实体的公钥加密,该安全上下文响应消息中携带有安全上下文以及随机数。
该具体实施例二中,通过时间戳使得安全功能实体可以控制开启外部接收的时间。该具体实施例中,虽然时间戳的窗口期对多个UMF实体开放,大事,安全功能实体能够知道是对哪个UE开放的窗口,通过该限制也实现验证密钥请求方是否为能够得到密钥的实体的功能。
本申请第二实施例中,如图8所示,验证密钥请求方的过程具体如下:
步骤801:安全功能实体接收第一核心网网元发送的请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌。
步骤802:所述安全功能实体若根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
本申请第二实施例的一个具体实现中:所述安全功能实体接收第一核心网网元发送的请求消息之前,所述安全功能实体生成第一新鲜性参数;所述安全功能实体将所述第一新鲜性参数发送给第二核心网网元,由第二核心网
网元根据所述UE附着的第一核心网网元的标识、所述UE的身份信息、所述第一新鲜性参数以及共享密钥生成所述第一令牌。
其中,共享密钥由安全功能实体生成后发送给第二核心网网元,或者,共享密钥由安全功能实体和第二核心网网元各自生成。
具体实施中,所述安全功能实体根据所述第一核心网网元的标识、所述UE的身份信息、所述第一核心网网元对应的第一新鲜性参数、以及共享密钥生成第二令牌,若确定所述第一令牌与所述第二令牌相同,则确定所述第一令牌合法。
本申请第二实施例的另一个具体实现中,所述第一令牌由第二核心网网元采用所述第二核心网网元的私钥、所述UE附着的第一核心网网元的标识、所述UE的身份信息以及第二新鲜性参数生成。
具体实施中,所述安全功能实体将所述UE的身份信息、所述第一令牌以及所述第一核心网网元的标识发送给第二核心网网元;所述安全功能实体接收所述第二核心网网元返回响应消息,所述响应消息用于指示所述第一令牌合法,其中,所述响应消息由所述第二核心网网元根据所述安全功能实体提供的所述UE的身份信息、所述第一核心网网元的标识、所述UE的身份信息对应的第二新鲜性参数、以及所述第二核心网网元的私钥生成第二令牌,并确定所述第一令牌与所述第二令牌相同后返回。
本申请第二实施例中,第一核心网网元为UMF实体;第二核心网网元为AMF实体或具有SSF功能的实体。
以下通过两个具体实施例对本申请第二实施例所提供的验证密钥请求方的过程进行详细说明。
具体实施例三,验证密钥请求方的具体过程如图9所示,具体描述如下:
该具体实施例中步骤901至步骤903所描述的鉴权的过程与具体实施例一中的鉴权过程相同,可参见步骤601至步骤603的描述,此处不再重复,以下仅描述鉴权之后的过程。
步骤904:安全功能实体生成该安全功能实体与SSF实体之间的共享密
钥,表示为Kssf;
步骤905:安全功能实体生成时间戳;
步骤906:安全功能实体发送鉴权成功消息给SSF实体,该鉴权成功消息中携带有时间戳,可选的,该鉴权成功消息中还携带SSF实体的共享密钥Kssf,该共享密钥由安全功能实体生成,SSF实体的共享密钥Kssf也可以由SSF实体或具有SSF功能的实体自己生成;
步骤907:SSF实体选择合适的UMF实体,并获得该UMF实体的标识;
步骤908:SSF实体生成令牌(token),生成token的参数包括UE的身份信息、UMF的标识、时间戳以及共享密钥;
步骤909:SSF实体转发附着消息给UMF实体,该附着消息中携带有UE的身份信息和该令牌;
步骤910:UMF实体向安全功能实体发送安全上下文请求(Security Context Request),该安全上下文请求中携带UMF实体的标识、UE的身份信息和该令牌;
步骤911:安全功能实体根据安全上下文请求中携带的信息,计算得到新的令牌,将该新的令牌与从UMF实体收到的令牌进行比较;
步骤912:若该新的令牌与从UMF实体收到的令牌相同,则生成密钥Kmm;
步骤913:安全功能实体向UMF实体发送安全上下文响应,该安全上下文响应中携带安全上下文,即密钥Kmm以及KSI。
该具体实施例三中,分别由SSF实体和安全功能实体生成令牌,安全功能实体通过验证这两个令牌是否相同,判决密钥请求方是否为能够得到密钥的实体。该具体实施例需要依赖于底层网元的安全保护,但是与其他具体实施例相比,减少了安全功能实体与SSF实体交互获得UMF标识的过程。
具体实施例四,验证密钥请求方的具体过程如图10所示,具体描述如下:
该具体实施例中步骤1001至步骤1004所描述的鉴权的过程,与具体实施例一中的鉴权过程相同,此处不再重复,以下仅描述鉴权之后的过程。
步骤1005:SSF实体选择合适的UMF实体,并获得该UMF实体的标识,以及生成随机数;
步骤1006:SSF实体采用该SSF实体的私钥、UMF实体的标识、UE的身份信息以及随机数生成令牌;
步骤1007:SSF实体转发附着请求给UMF实体,该附着消息中携带生成的该令牌;
步骤1008:UMF实体向安全功能实体发送安全上下文请求,该安全上下文请求中携带UMF的标识、令牌和UE的身份信息;
步骤1009:安全功能实体向SSF实体发送对UMF标识的请求消息,该请求消息中携带UE的身份信息、令牌以及UMF实体的标识;
步骤1010:SSF实体验证生成的令牌与从安全功能实体获得的令牌是否相同;
步骤1011:SSF实体若确定相同,则向安全功能实体回复响应消息,该响应消息中携带令牌相同的指示信息;
步骤1012:安全功能实体生成UMF实体相关的上下文,如密钥Kmm;
步骤1013:安全功能实体向UMF实体回复安全上下文响应消息,该安全上下文响应消息中携带该UMF实体相关的上下文。
该具体实施例四中,采用SSF实体的私钥生成令牌,并且由SSF实体验证生成的令牌与从安全功能实体获得的令牌是否相同,这样安全功能实体无条件相信SSF实体反馈的信息是正确的。该具体实施例需要依赖于网元之间底层的安全保护。
本申请第三实施例中,如图11所示,验证密钥请求方的过程具体如下:
步骤1101:安全功能实体获取终端UE附着的UMF实体的标识;
步骤1102:所述安全功能实体为所述UMF实体生成所述UE的密钥以及验证参数;
步骤1103:所述安全功能实体向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所
述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;
步骤1104:所述安全功能实体接收所述UMF实体返回的验证信息,所述验证信息由所述UMF实体采用所述密钥对所述验证参数加密后得到;
步骤1105:所述安全功能实体确定所述验证信息合法后,确定所述密钥下发成功。
以下通过一个具体实施例对本申请第三实施例所提供的验证密钥请求方的过程进行详细说明。
具体实施例五,验证密钥请求方的具体过程如图12所示,具体描述如下:
步骤1201:UE通过基站中转向SSF实体发送初始附着请求,该初始附着请求中至少携带UE的IMSI;
步骤1202:SSF实体转发该初始附着请求给安全功能实体,以发起鉴权请求;
步骤1203:安全功能实体发起对UE的鉴权过程,完全对UE的鉴权;
步骤1204:安全功能实体向SSF实体发送鉴权成功消息;
步骤1205:SSF实体根据UE的信息为该UE选择合适的UMF实体,并获取该UMF实体的标识信息;
步骤1206:SSF实体向安全功能实体发送UMF标识提供消息,该UMF标识提供消息中携带所选择的UMF实体的标识信息以及该UMF实体的证书;
步骤1207:安全功能实体生成UMF实体相关的密钥,如Kmm;
步骤1208:安全功能实体生成一个随机数;
步骤1209:安全功能实体根据UMF实体的标识获取该UMF实体的公钥,向该UMF实体发送安全上下文提供消息,该安全上下文提供消息采用UMF实体的公钥加密,并用安全功能实体的私钥进行签名,该安全上下文提供消息中携带该UMF实体的安全上下文(包括UMF实体相关的密钥)、UE的身份信息以及随机数;
步骤1210:UMF实体采用从安全功能实体收到的密钥对随机数进行加密,并向安全功能实体返回安全上下文提供确认消息,该消息中携带加密后
得到的数据;
步骤1211:安全功能实体采用该UMF实体的密钥对收到的数据进行机密后,验证解密后得到的数据与所生成的随机数是否相同,若相同,则向SSF实体返回UMF标识提供确认消息,以通知SSF实体密钥下发成功。
基于同一构思,本申请第四实施例中提供了一种验证密钥请求方的设备,该设备的具体实施可参见本申请第一实施例的描述,重复之处不再赘述,如图13所示,该设备主要包括:
第一处理模块1301,用于接收用户管理功能UMF实体发送的请求消息;
第二处理模块1302,用于采用所述设备的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息;
第三处理模块1303,用于若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
基于同一构思,本申请第五实施例中提供了一种验证密钥请求方的设备,该设备的具体实施可参见本申请第二实施例的描述,重复之处不再赘述,如图14所示,该设备主要包括:
接收模块1401,用于接收第一核心网网元发送的请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌;
处理模块1402,用于若根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
基于同一构思,本申请第五实施例中提供了一种验证密钥请求方的设备,该设备的具体实施可参见本申请第三实施例的描述,重复之处不再赘述,如图15所示,该设备主要包括:
获取模块1501,用于获取终端UE附着的用户管理功能UMF实体的标识;
第一处理模块1502,用于为所述UMF实体生成所述UE的密钥以及验证
参数;
发送模块1503,用于向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;
接收模块1504,用于接收所述UMF实体返回的验证信息,所述验证信息由所述UMF实体采用所述密钥对所述验证参数加密后得到;
第二处理模块1505,用于确定所述验证信息合法后,确定所述密钥下发成功。
基于同一构思,本申请第七实施例中,提供了一种验证密钥请求方的设备,该设备的具体实施可参见本申请第一实施例的相关描述,重复之处不再赘述,如图16所示,该设备主要包括处理器1601、存储器1602和通信接口1603,其中,存储器1602中保存有预设的程序,处理器1601读取存储器1602中的程序,按照该程序执行以下过程:
通过通信接口接收用户管理功能UMF实体发送的请求消息;
采用所述设备的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息;
若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
具体地,处理器用于执行第四实施例中第一处理模块、第二处理模块以及第三处理模块的功能,通信接口用于在处理器的控制下完成第四实施例中各处理模块处理过程中所涉及的通信功能。
基于同一构思,本申请第八实施例中,提供了一种验证密钥请求方的设备,该设备的具体实施可参见本申请第二实施例的相关描述,重复之处不再赘述,如图17所示,该设备主要包括处理器1701、存储器1702和通信接口1703,其中,存储器1702中保存有预设的程序,处理器1701读取存储器1702
中的程序,按照该程序执行以下过程:
通过通信接口接收第一核心网网元发送的请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌;
若根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
具体地,处理器用于执行第五实施例中处理模块的功能,通信接口用于在处理器的控制下完成第五实施例中接收模块的功能。
基于同一构思,本申请第九实施例中,提供了一种验证密钥请求方的设备,该设备的具体实施可参见本申请第二实施例的相关描述,重复之处不再赘述,如图18所示,该设备主要包括处理器1801、存储器1802和通信接口1803,其中,存储器1802中保存有预设的程序,处理器1801读取存储器1802中的程序,按照该程序执行以下过程:
获取终端UE附着的用户管理功能UMF实体的标识;
为所述UMF实体生成所述UE的密钥以及验证参数;
通过通信接口向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;
通过通信接口接收所述UMF实体返回的验证信息,所述验证信息由所述UMF实体采用所述密钥对所述验证参数加密后得到;
确定所述验证信息合法后,确定所述密钥下发成功。
其中,图16至图18中,处理器、存储器和通信接口之间通过总线连接,总线架构可以包括任意数量的互联的总线和桥,具体由处理器代表的一个或多个处理器和存储器代表的存储器的各种电路链接在一起。总线架构还可以将诸如***设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。通信接口可以是多个元件,即包括发送接口和收发接口,提供用于在传输介质上与各种其他装置通信的单元。处理器负责管理总线架构和通
常的处理,存储器可以存储处理器在执行操作时所使用的数据。
本领域内的技术人员应明白,本申请的实施例可提供为方法、***、或计算机程序产品。因此,可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图,应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (22)
- 一种验证密钥请求方的方法,其特征在于,包括:安全功能实体接收用户管理功能UMF实体发送的请求消息;所述安全功能实体采用所述安全功能实体的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息;所述安全功能实体若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
- 如权利要求1所述的方法,其特征在于,所述方法还包括:所述安全功能实体生成新鲜性参数;所述安全功能实体通过核心网网元将所述新鲜性参数通知给所述UE附着的UMF实体,由所述UE附着的UMF实体将所述新鲜性参数作为所述第一验证参数携带在所述请求消息中。
- 如权利要求2所述方法,其特征在于,所述安全功能实体确定所述请求消息中携带的第一验证参数合法,包括:所述安全功能实体确定所述第一验证参数与所述新鲜性参数相同,或,确定所述新鲜性参数在设定范围内,则确定所述安全上下文请求中携带的第一验证参数合法。
- 如权利要求2或3所述的方法,其特征在于,所述请求消息中还携带第二验证参数,所述第二验证参数由所述UMF实体生成;所述方法还包括:所述安全功能实体向所述UMF实体返回响应消息,其中,所述响应消息中至少携带为所述UMF实体生成的所述密钥以及所述第二验证参数,且所述响应消息中携带的信息采用所述UMF实体的公钥进行加密,由所述UMF实体采用所述UMF实体的私钥对所述响应消息进行解密后,若确定所述响应消 息中携带的所述第二验证参数合法,则确定所述响应消息中携带的所述密钥为所述安全功能实体为所述UMF实体生成的密钥。
- 一种验证密钥请求方的方法,其特征在于,包括:安全功能实体接收第一核心网网元发送的请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌;所述安全功能实体若根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
- 如权利要求5所述的方法,其特征在于,所述安全功能实体接收第一核心网网元发送的请求消息之前,所述方法还包括:所述安全功能实体生成第一新鲜性参数;所述安全功能实体将所述第一新鲜性参数发送给第二核心网网元,由所述第二核心网网元根据所述UE附着的第一核心网网元的标识、所述UE的身份信息、所述第一新鲜性参数以及共享密钥生成所述第一令牌。
- 如权利要求6所述的方法,其特征在于,所述共享密钥由所述安全功能实体生成后发送给所述第二核心网网元;或者,所述共享密钥由所述安全功能实体和所述第二核心网网元各自生成。
- 如权利要求5、6或7所述的方法,其特征在于,所述安全功能实体根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,包括:所述安全功能实体根据所述第一核心网网元的标识、所述UE的身份信息、所述第一核心网网元对应的第一新鲜性参数、以及所述共享密钥生成第二令牌,若确定所述第一令牌与所述第二令牌相同,则确定所述第一令牌合法。
- 如权利要求5所述的方法,其特征在于,所述第一令牌由第二核心网网元采用所述第二核心网网元的私钥、所述UE附着的第一核心网网元的标识、所述UE的身份信息以及第二新鲜性参数生成。
- 如权利要求5或9所述的方法,其特征在于,所述安全功能实体根 据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,包括:所述安全功能实体将所述UE的身份信息、所述第一令牌以及所述第一核心网网元的标识发送给第二核心网网元;所述安全功能实体接收所述第二核心网网元返回响应消息,所述响应消息用于指示所述第一令牌合法,其中,所述响应消息由所述第二核心网网元根据所述安全功能实体提供的所述UE的身份信息、所述第一核心网网元的标识、所述UE的身份信息对应的第二新鲜性参数、以及所述第二核心网网元的私钥生成第二令牌,并确定所述第一令牌与所述第二令牌相同后返回。
- 一种验证密钥请求方的方法,其特征在于,包括:安全功能实体获取终端UE附着的用户管理功能UMF实体的标识;所述安全功能实体为所述UMF实体生成所述UE的密钥以及验证参数;所述安全功能实体向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;所述安全功能实体接收所述UMF实体返回的验证信息,所述验证信息由所述UMF实体采用所述密钥对所述验证参数加密后得到;所述安全功能实体确定所述验证信息合法后,确定所述密钥下发成功。
- 一种验证密钥请求方的设备,其特征在于,包括:第一处理模块,用于接收用户管理功能UMF实体发送的请求消息;第二处理模块,用于采用所述设备的私钥对所述请求消息中的信息进行解密,以及采用所述UMF实体的证书中的公钥对解密后的信息进行签名验证通过后,获取所述请求消息中携带的信息;第三处理模块,用于若确定所述请求消息中携带的第一验证参数合法,且确定所述请求消息中携带的所述UMF实体的标识与终端UE附着的UMF实体的标识相同,则确定为所述UMF实体提供所述UE的密钥。
- 如权利要求12所述的设备,其特征在于,所述第一处理模块还用于:生成新鲜性参数;通过所述核心网网元将所述新鲜性参数通知给所述UE附着的UMF实体,由所述UE附着的UMF实体将所述新鲜性参数作为所述第一验证参数携带在所述请求消息中。
- 如权利要求13所述的设备,其特征在于,所述第三处理模块具体用于:确定所述第一验证参数与所述新鲜性参数相同,或,确定所述新鲜性参数在设定范围内,则确定所述安全上下文请求中携带的第一验证参数合法.
- 如权利要求13或14所述的设备,其特征在于,所述请求消息中还携带第二验证参数,所述第二验证参数由所述UMF实体生成;所述第三处理模块还用于:向所述UMF实体返回响应消息,其中,所述响应消息中至少携带为所述UMF实体生成的所述密钥以及所述第二验证参数,且所述响应消息中携带的信息采用所述UMF实体的公钥进行加密,由所述UMF实体采用所述UMF实体的私钥对所述响应消息进行解密后,若确定所述响应消息中携带的所述第二验证参数合法,则确定所述响应消息中携带的所述密钥为所述设备为所述UMF实体生成的密钥。
- 一种验证密钥请求方的设备,其特征在于,包括:接收模块,用于接收第一核心网网元发送的请求消息,所述请求消息中携带所述第一核心网网元的标识、终端UE的身份信息以及第一令牌;处理模块,用于若根据所述第一核心网网元的标识以及所述UE的身份信息确定所述第一令牌合法,则确定为所述第一核心网网元提供所述密钥。
- 如权利要求16所述的设备,其特征在于,所述处理模块还用于:在所述接收模块接收核心网网元发送的请求消息之前,生成第一新鲜性参数;还包括发送模块,用于:将所述第一新鲜性参数发送给第二核心网网元,由所述第二核心网网元根据所述UE附着的第一核心网网元的标识、所述UE的身份信息、所述第一新鲜性参数以及共享密钥生成所述第一令牌。
- 如权利要求17所述的设备,其特征在于,所述共享密钥由所述安全功能实体生成后发送给所述第二核心网网元;或者,所述共享密钥由所述安全功能实体和所述第二核心网网元各自生成。
- 如权利要求16、17或18所述的设备,其特征在于,所述处理模块具体用于:根据所述第一核心网网元的标识、所述UE的身份信息、所述第一核心网网元对应的第一新鲜性参数、以及所述共享密钥生成第二令牌,若确定所述第一令牌与所述第二令牌相同,则确定所述第一令牌合法。
- 如权利要求16所述的设备,其特征在于,所述第一令牌由第二核心网网元采用所述第二核心网网元的私钥、所述UE附着的第一核心网网元的标识、所述UE的身份信息以及第二新鲜性参数生成。
- 如权利要求16或20所述的设备,其特征在于,所述发送模块具体用于:将所述UE的身份信息、所述第一令牌以及所述第一核心网网元的标识发送给第二核心网网元;所述接收模块具体用于:接收所述第二核心网网元返回响应消息,所述响应消息用于指示所述第一令牌合法,其中,所述响应消息由所述第二核心网网元根据所述设备提供的所述UE的身份信息、所述第一核心网网元的标识、所述UE的身份信息对应的第二新鲜性参数、以及所述第二核心网网元的私钥生成第二令牌,并确定所述第一令牌与所述第二令牌相同后返回。
- 一种验证密钥请求方的设备,其特征在于,包括:获取模块,用于获取终端UE附着的用户管理功能UMF实体的标识;第一处理模块,用于为所述UMF实体生成所述UE的密钥以及验证参数;发送模块,用于向所述UMF实体发送配置信息,所述配置信息采用所述安全功能实体的私钥签名后采用所述UMF实体的公钥加密,所述配置信息包括所述密钥、所述UE的身份信息以及所述验证参数;接收模块,用于接收所述UMF实体返回的验证信息,所述验证信息由所述UMF实体采用所述密钥对所述验证参数加密后得到;第二处理模块,用于确定所述验证信息合法后,确定所述密钥下发成功。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2016/113941 WO2018120217A1 (zh) | 2016-12-30 | 2016-12-30 | 验证密钥请求方的方法和设备 |
CN201680086517.4A CN109314693B (zh) | 2016-12-30 | 2016-12-30 | 验证密钥请求方的方法和设备 |
EP16924997.6A EP3550780B1 (en) | 2016-12-30 | 2016-12-30 | Verification method and apparatus for key requester |
US16/453,833 US11445370B2 (en) | 2016-12-30 | 2019-06-26 | Method and device for verifying key requester |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2016/113941 WO2018120217A1 (zh) | 2016-12-30 | 2016-12-30 | 验证密钥请求方的方法和设备 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/453,833 Continuation US11445370B2 (en) | 2016-12-30 | 2019-06-26 | Method and device for verifying key requester |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2018120217A1 true WO2018120217A1 (zh) | 2018-07-05 |
Family
ID=62706714
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2016/113941 WO2018120217A1 (zh) | 2016-12-30 | 2016-12-30 | 验证密钥请求方的方法和设备 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11445370B2 (zh) |
EP (1) | EP3550780B1 (zh) |
CN (1) | CN109314693B (zh) |
WO (1) | WO2018120217A1 (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109314693B (zh) * | 2016-12-30 | 2020-08-25 | 华为技术有限公司 | 验证密钥请求方的方法和设备 |
US11163910B2 (en) * | 2017-06-29 | 2021-11-02 | Salesforce.Com, Inc. | Methods and systems for data migration |
US10749689B1 (en) * | 2017-06-29 | 2020-08-18 | Salesforce.Com, Inc. | Language-agnostic secure application development |
WO2020160139A1 (en) * | 2019-01-29 | 2020-08-06 | Schneider Electric USA, Inc. | Security context distribution service |
US11652646B2 (en) * | 2020-12-11 | 2023-05-16 | Huawei Technologies Co., Ltd. | System and a method for securing and distributing keys in a 3GPP system |
CN113472792B (zh) * | 2021-07-01 | 2023-05-05 | 北京玩蟹科技有限公司 | 一种长连接网络通信加密方法及*** |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101272616A (zh) * | 2008-05-07 | 2008-09-24 | 广州杰赛科技股份有限公司 | 一种无线城域网的安全接入方法 |
CN103188229A (zh) * | 2011-12-30 | 2013-07-03 | 上海贝尔股份有限公司 | 用于安全内容访问的方法和设备 |
CN105577627A (zh) * | 2014-11-11 | 2016-05-11 | 腾讯数码(天津)有限公司 | 通信方法、装置、网络设备、终端设备和通信*** |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI20000760A0 (fi) * | 2000-03-31 | 2000-03-31 | Nokia Corp | Autentikointi pakettidataverkossa |
CA2358083A1 (en) * | 2001-09-28 | 2003-03-28 | Bridgewater Systems Corporation | A method for session accounting in a wireless data networks using authentication, authorization and accounting (aaa) protocols (such as ietf radius or diameter) where there is no session handoff communication between the network elements |
US20070198837A1 (en) * | 2005-04-29 | 2007-08-23 | Nokia Corporation | Establishment of a secure communication |
US9807819B1 (en) * | 2009-09-04 | 2017-10-31 | Sprint Communications Company L.P. | Cross-technology session continuity |
KR101700448B1 (ko) * | 2009-10-27 | 2017-01-26 | 삼성전자주식회사 | 이동 통신 시스템에서 보안 관리 시스템 및 방법 |
US8880026B2 (en) * | 2009-12-22 | 2014-11-04 | Alcatel Lucent | Method and apparatus for providing network services to a mobile user equipment |
CN101951603B (zh) * | 2010-10-14 | 2013-05-22 | 中国电子科技集团公司第三十研究所 | 一种无线局域网接入控制方法及*** |
US8923863B2 (en) * | 2011-12-19 | 2014-12-30 | Cisco Technology, Inc. | Maintaining signaling reduction mode in communication networks |
US9240881B2 (en) * | 2012-04-30 | 2016-01-19 | Alcatel Lucent | Secure communications for computing devices utilizing proximity services |
KR102142576B1 (ko) * | 2013-05-16 | 2020-08-10 | 삼성전자주식회사 | 단말간 통신을 위한 탐색 방법 및 장치 |
WO2016043369A1 (ko) * | 2014-09-17 | 2016-03-24 | 엘지전자 주식회사 | 이종 무선 통신 기술 간의 핸드오버 방법 및 이를 위한 장치 |
CN105577626A (zh) * | 2014-10-28 | 2016-05-11 | 祝永康 | 一种用户名注册和使用方法、***及装置 |
CN106162574B (zh) * | 2015-04-02 | 2020-08-04 | 成都鼎桥通信技术有限公司 | 集群***中应用统一鉴权方法、服务器与终端 |
ES2786261T3 (es) * | 2015-06-09 | 2020-10-09 | Deutsche Telekom Ag | Método para una instalación mejorada de una aplicación de servicio relacionada con un elemento seguro en un elemento seguro que se encuentra en un dispositivo de comunicación, sistema y red de telecomunicaciones para una instalación mejorada de una aplicación de servicio relacionada con un elemento seguro en un elemento seguro que se encuentra en un dispositivo de comunicación, programa que incluye un código de programa legible por ordenador y producto de programa informático |
US10285060B2 (en) * | 2015-10-30 | 2019-05-07 | Alcatel-Lucent Usa Inc. | Preventing attacks from false base stations |
US11234126B2 (en) * | 2015-11-17 | 2022-01-25 | Qualcomm Incorporated | Methods and apparatus for wireless communication using a security model to support multiple connectivity and service contexts |
CN109314693B (zh) * | 2016-12-30 | 2020-08-25 | 华为技术有限公司 | 验证密钥请求方的方法和设备 |
WO2018182759A1 (en) * | 2017-03-30 | 2018-10-04 | Intel IP Corporation | Security for paging messages |
-
2016
- 2016-12-30 CN CN201680086517.4A patent/CN109314693B/zh active Active
- 2016-12-30 EP EP16924997.6A patent/EP3550780B1/en active Active
- 2016-12-30 WO PCT/CN2016/113941 patent/WO2018120217A1/zh unknown
-
2019
- 2019-06-26 US US16/453,833 patent/US11445370B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101272616A (zh) * | 2008-05-07 | 2008-09-24 | 广州杰赛科技股份有限公司 | 一种无线城域网的安全接入方法 |
CN103188229A (zh) * | 2011-12-30 | 2013-07-03 | 上海贝尔股份有限公司 | 用于安全内容访问的方法和设备 |
CN105577627A (zh) * | 2014-11-11 | 2016-05-11 | 腾讯数码(天津)有限公司 | 通信方法、装置、网络设备、终端设备和通信*** |
Non-Patent Citations (2)
Title |
---|
HUAWEI ET AL.: "Solution: Consolidated Architecture Option X", SA WG2 MEETING #117 S2-166170, 21 October 2016 (2016-10-21), XP051154711 * |
See also references of EP3550780A4 * |
Also Published As
Publication number | Publication date |
---|---|
EP3550780A1 (en) | 2019-10-09 |
US20190320320A1 (en) | 2019-10-17 |
CN109314693B (zh) | 2020-08-25 |
EP3550780B1 (en) | 2021-04-14 |
US11445370B2 (en) | 2022-09-13 |
EP3550780A4 (en) | 2019-12-11 |
CN109314693A (zh) | 2019-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110035433B (zh) | 采用共享密钥、公钥和私钥的验证方法及装置 | |
US10849191B2 (en) | Unified authentication for heterogeneous networks | |
JP6612358B2 (ja) | ネットワークアクセスデバイスをワイヤレスネットワークアクセスポイントにアクセスさせるための方法、ネットワークアクセスデバイス、アプリケーションサーバ、および不揮発性コンピュータ可読記憶媒体 | |
CN109699031B (zh) | 采用共享密钥、公钥和私钥的验证方法及装置 | |
US11178584B2 (en) | Access method, device and system for user equipment (UE) | |
WO2018120217A1 (zh) | 验证密钥请求方的方法和设备 | |
US10588015B2 (en) | Terminal authenticating method, apparatus, and system | |
CN111030814B (zh) | 秘钥协商方法及装置 | |
CN111865603A (zh) | 认证方法、认证装置和认证*** | |
CN112312393A (zh) | 5g应用接入认证方法及5g应用接入认证网络架构 | |
WO2008006312A1 (en) | A realizing method for push service of gaa and a device | |
CN108353279B (zh) | 一种认证方法和认证*** | |
AU2020200523A1 (en) | Methods and arrangements for authenticating a communication device | |
US20210165885A1 (en) | Extended Authentication Method And Apparatus For Generic Bootstrapping Architecture, And Storage Medium | |
WO2018076298A1 (zh) | 一种安全能力协商方法及相关设备 | |
WO2015180399A1 (zh) | 一种认证方法及装置*** | |
US9307406B2 (en) | Apparatus and method for authenticating access of a mobile station in a wireless communication system | |
WO2018126791A1 (zh) | 一种认证方法及装置、计算机存储介质 | |
KR101658657B1 (ko) | 네트워크 접속 보안 강화 시스템을 위한 단말장치 및 인증지원장치 | |
WO2019024937A1 (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: 16924997 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: 2016924997 Country of ref document: EP Effective date: 20190702 |