WO2021238280A1

WO2021238280A1 - Communication method, apparatus and system

Info

Publication number: WO2021238280A1
Application number: PCT/CN2021/073668
Authority: WO
Inventors: 邓娟
Original assignee: 华为技术有限公司
Priority date: 2020-05-29
Filing date: 2021-01-25
Publication date: 2021-12-02
Also published as: CN113810903B; CN113810903A

Abstract

Embodiments of the present application provide a communication method, apparatus and system, for use in solving the problem of updating an access and mobility management function (AMF) key when an AMF change occurs. The method comprises: a first AMF determines a security characteristic of a terminal device and a key of a second AMF; an AMF determines a first ABBA parameter according to the security characteristic of the terminal device and a security characteristic of the first AMF; the first AMF determines a key of the first AMF according to the first ABBA parameter and the key of the second AMF.

Description

Communication method, device and system

Cross-references to related applications

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on May 29, 2020, with an application number of 202010479818.1, and the application title is "a communication method and device", the entire content of which is incorporated into this application by reference.

Technical field

The embodiments of the present application relate to the field of communication technologies, and in particular, to a communication method, device, and system.

Background technique

In the 5th generation (5G) communication system, the security features supported by terminal devices and network functions are constantly evolving. In addition to supporting the security features supported by the low-level version of the terminal device, the high-end version of the terminal device will also support the new and low-level version of the terminal device that does not support the security features. In the same way, in addition to supporting the security features supported by the low-level version of the network function, the high-level version of the network function will also support the new and low-level version of the network function that does not support the security features. Before terminal equipment and network functions use a certain security feature for communication, both parties need to negotiate security features to ensure that the other party supports the security feature. If one party does not support it, the two communicating parties cannot use the security feature. For example, the high-level version of the terminal device supports both 256-bit key encryption and 128-bit key encryption, while the low-level version of the network function only supports 128-bit key encryption, so the communication between the terminal device and the network function is only A 128-bit key supported by both parties can be used for encryption.

Among them, the third generation partnership protection (3GPP) standard 33.501, which is the 5G system security architecture and process, defines the security requirements of the 5G system in version 15 (release 15, Rel-15), including Preventing dimensionality reduction attacks (bidding down attacks), also known as anti-dimensionality reduction attacks. A dimensionality reduction attack means that an attacker makes the terminal device or network function each think that the opposite end does not support the security features of the high-end version, but in fact both the terminal device and network function support the security features of the high-end version. After the attack is successful, the terminal device and the network function can only communicate with the low-level version of the security features, which leads to the reduction of the security features and degrades the communication security between the terminal device and the network function.

At present, in a scenario, when the network function of the serving terminal device changes, for example, the first access and mobile management function (Access and Mobile Management Function, AMF) function is changed to the second AMF function. Since the security features supported by the first AMF function and the second AMF function may be different, how to update the AMF key at this time is a problem to be solved currently.

Summary of the invention

The embodiments of the present application provide a communication method, device, and system to realize the update of the access and mobility management function AMF key.

In a first aspect, a communication method is provided. The first AMF in the method may also be a component (such as a chip, a circuit, or others) configured in the first AMF. The method includes: the first AMF determines the terminal device The first AMF determines the anti-dimensionality reduction ABBA parameters between the first architectures according to the security characteristics of the terminal device and the security characteristics of the first AMF; the first AMF obtains the key of the second AMF; the first AMF Determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.

In the foregoing method, the first AMF may be a Target AMF, the second AMF may be an Old AMF, and the terminal device may be a UE. When the AMF registered by the UE or the AMF serving the UE is changed, the Target AMF can generate the ABBA_New parameter according to the security features supported between the UE and the Target AMF, and use ABBA_New as the input parameter to generate a new K _AMF key, It is used by UE and Target AMF to ensure the safety of communication between UE and Target AMF.

In a possible design, the first AMF determining the security feature of the terminal device includes: the first AMF sends a request message for requesting the context of the terminal device to the second AMF; the first AMF receives In the terminal device context sent by the second AMF, the terminal device context carries the security feature of the terminal device.

In the above method, the first AMF can negotiate security features with the second AMF and the terminal device to resist dimensionality reduction attacks.

In a possible design, obtaining the key of the second AMF by the first AMF includes: the first AMF sends a request message for requesting the context of the terminal device to the second AMF; the first AMF receives the key sent by the second AMF The terminal device context, the terminal device context carries the key of the second AMF.

In a possible design, before the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, the method further includes: the first AMF The security feature of the second AMF is determined; the first AMF determines that the security feature of the first AMF is different from the security feature of the second AMF.

In the above method, when the security features of the two AMFs registered by the UE or the two AMFs serving the UE are inconsistent, the AMF key is updated, otherwise the AMF key is no longer updated, so as to avoid the overhead waste of updating the AMF key .

In a possible design, after the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, the method further includes: the first AMF Send the first ABBA parameter and first indication information to the terminal device, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter.

In the foregoing method, the foregoing first indication information is optional. That is, the first AMF may only send the first ABBA parameter to the terminal device. The terminal device can update the AMF key according to the first ABBA parameter. Furthermore, according to the AMF key, the communication between the two is protected to resist dimensionality reduction attacks.

In a second aspect, a communication method is provided. The terminal device in the method may also be a component in the terminal device (for example, a chip, a circuit, or other components). The method includes: the terminal device receives the first AMF sent by the first AMF. ABBA parameters and optional first indication information, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter; the terminal device according to the first ABBA parameter and the second The key of the AMF determines the key of the first AMF.

In the above method, when the registered AMF of the terminal device is changed, or the AMF serving the terminal device is changed, the terminal device can update the AMF key according to the security characteristics of the changed AMF to meet the communication requirements and resist degradation. Dimensional attack.

In a possible design, the first ABBA parameter includes the security feature of the terminal device and the security feature of the first AMF.

In a possible design, the method further includes: the terminal device sends a registration request to the first AMF, and the registration request carries the security feature of the terminal device or the second ABBA parameter.

In a third aspect, a communication method is provided. In the method, both the first AMF and the second AMF can be components of the AMF (for example, a chip, a circuit, or other components), including: the second AMF communicates with the first AMF The security feature of the terminal device and the key of the second AMF are sent. The second ABBA parameter includes the security feature of the terminal device and the security feature of the second AMF; the first AMF is based on the The security feature of the terminal device and the security feature of the first AMF determine the first ABBA parameter; the first AMF determines the first AMF parameter according to the first ABBA parameter and the key of the second AMF Key.

In a possible design, the second AMF sending the security feature of the terminal device and the key of the second AMF to the first AMF includes: sending the first AMF to the second AMF for A request message for requesting a terminal device context; the second AMF sends a terminal device context to the first AMF, and the terminal device context carries the security feature of the terminal device and the key of the second AMF.

In a possible design, before the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the key of the first AMF, the method further includes: the first AMF The security feature of the second AMF is determined; the first AMF determines that the security features of the first AMF and the second AMF are different.

In a fourth aspect, a device is provided. For beneficial effects, please refer to the description of the first aspect. The communication device has the function of realizing the behavior in the method embodiment of the first aspect described above. The functions can be implemented by corresponding hardware or software. The piece or software includes one or more units corresponding to the above-mentioned functions.

In the fifth aspect, a device is provided, and the beneficial effects can be referred to the description of the second aspect. The communication device has the function of realizing the behavior in the method embodiment of the second aspect described above. The functions can be implemented by corresponding hardware or software. The piece or software includes one or more units corresponding to the above-mentioned functions.

In a sixth aspect, a device is provided, and the device may be the first AMF in the foregoing method embodiment, or a chip set in the first AMF. The device includes a communication interface, a processor, and optionally, a memory. The memory is used to store a computer program or instruction, and the processor is coupled with the memory and a communication interface. When the processor executes the computer program or instruction, the communication device executes the method executed by the first AMF in the above aspects.

In a seventh aspect, a device is provided, and the device may be the terminal device in the foregoing method embodiment, or a chip set in the terminal device. The device includes a communication interface, a processor, and optionally, a memory. Wherein, the memory is used to store a computer program or instruction, and the processor is coupled with the memory and a communication interface. When the processor executes the computer program or instruction, the communication device executes the method executed by the terminal device in the foregoing aspects.

In an eighth aspect, a computer program product is provided, the computer program product comprising: computer program code, when the computer program code is running, causes the method executed by the first AMF or the terminal device in the above aspects to be executed .

In a ninth aspect, the present application provides a chip system, which includes a processor, configured to implement the functions of the first AMF or terminal device in the methods of the foregoing aspects. In a possible design, the chip system further includes a memory for storing program instructions and/or data. The chip system can be composed of chips, and can also include chips and other discrete devices.

In a tenth aspect, the present application provides a computer-readable storage medium that stores a computer program, and when the computer program is executed, the method executed by the first AMF or the terminal device in the above aspects is implemented .

In an eleventh aspect, this application provides a system including at least one of the first AMF, the second AMF, or the terminal device described in the foregoing aspects.

Description of the drawings

FIG. 1 is a flowchart of using ABBA to resist dimensionality reduction attacks according to an embodiment of this application;

FIG. 2a is a flowchart of the security processing of the UE moving in an idle state according to an embodiment of this application;

2b and 2c are schematic diagrams of different scenarios provided by an embodiment of the application;

FIG. 3 is a flowchart of the security processing of N2 handover provided by an embodiment of this application;

FIG. 4 is a flowchart of the security processing of the N2 handover of the UE from EPS handover to 5GS provided by an embodiment of the application;

FIG. 5 is a flowchart of the security processing of UE moving from EPS idle state to 5GS according to an embodiment of this application;

FIG. 6 is a schematic diagram of a network architecture provided by an embodiment of this application;

Figures 7a and 7b are flowcharts of communication methods provided by embodiments of this application;

FIG. 8a is a flowchart of a communication method provided in Embodiment 1 of this application;

FIG. 8b is a flowchart of the security feature negotiation and key update process in the idle state mobile registration of the UE in 5GS according to an embodiment of the application;

FIG. 9 is a flowchart of the security feature negotiation and key update of the UE in the N2 handover provided by the embodiment of this application;

10 is a flowchart of security feature negotiation and key update in UE handover from EPS to 5GS according to an embodiment of this application;

FIG. 11 is a flowchart of security feature negotiation and key update of UE moving from EPS to 5GS in idle state according to an embodiment of this application;

FIG. 12 is a flowchart of the communication method provided in the second embodiment of this application;

FIG. 13 is a flowchart of a UE moving from Old AMF to Target AMF in an idle state in 5GS according to an embodiment of the application;

FIG. 14 is a flowchart of the communication method provided in the third embodiment of this application;

FIG. 15 is a flowchart of a UE moving in an idle state of 5G according to an embodiment of this application;

FIG. 16 is a flowchart of the communication method provided by the fourth embodiment of this application;

FIG. 17 is a flowchart of a UE moving in an idle state of 5G according to an embodiment of this application;

18 and 19 are a flowchart of the communication method provided by the fourth embodiment of this application;

FIG. 20 is a flowchart of a communication method provided by an embodiment of this application;

FIG. 21 is a flowchart of UE mobile registration in 5GS idle state according to an embodiment of the application;

FIG. 22 is a flowchart of a UE's N2 handover process provided by an embodiment of this application;

FIG. 23 and FIG. 24 are a flowchart of the communication method provided in the seventh embodiment of this application;

FIG. 25 is a flowchart of the N2 handover of the UE according to an embodiment of this application;

FIG. 26 is a schematic diagram of a communication device provided by an embodiment of this application;

FIG. 27 is another schematic diagram of a communication device provided by an embodiment of this application.

Detailed ways

In order to facilitate understanding, the communication terms or terms involved in the embodiments of the present application are explained first, and the communication terms or terms are also part of the content of the invention.

1. Anti-bidding down between architectures (ABBA) parameters.

Rel-15 (release 15, Rel-15) of 3GPP standard 33.501 is the first version of 5G communication system architecture and process security. With the continuous evolution of 5G communication system architecture and process security, it will evolve to a high-end version in the future. For example, version 16 (release 16, Rel-16) and version 17 (release 17, Rel-17), etc. In order to prevent dimensionality reduction attacks in the future, the ABBA parameters are defined in version 15 of 33.501. ABBA parameters can include:

(1) Security features supported by UE;

(2) The security features supported by the network function, or the security features selected by the network function;

(3) Optional, others;

In a possible implementation, 16 bits in the ABBA parameter can be used to indicate the security features supported by the UE, and 16 bits indicate the security features supported or selected by the network device.

In the embodiments of the present application, in order to facilitate the distinction, when the UE is registered with Old AMF (Access and Mobile Management Function, access and mobility management function), the ABBA set on the network side is called ABBA_Old. The ABBA_Old may include the security features supported or selected by Old AMF and the security features supported by the UE. When the UE can be registered to Target AMF, the ABBA set on the network side is called ABBA_New. The ABBA_New may include the security features supported or selected by the Target AMF and the security features supported by the UE. In this application, Old AMF is the AMF that serves the UE before the UE moves in the idle state or before the N2 handover, and Target AMF is the AMF that serves the UE after the UE moves in the idle state or after the N2 handover; that is, the AMF that serves the UE changes , Change from Old AMF to Target AMF.

In this application, Target AMF also serves the AMF of the UE after the UE moves from the EPS idle state to 5GS or after switching from the EPS to 5GS.

2. Security features

Rel-15 was released due to the current standard 33.501. Therefore, in the 5G communication system, both the UE and network functions support the Rel-15 version. In the future 5G communication system, multiple versions may coexist. For example, some UEs support Rel-15, and some UEs support post Rel-15 (that is, versions after Rel-15). Some base stations support Rel-15, and some base stations support post Rel-15. In the future 5G communication system, before the UE is registered, neither the UE nor the network device knows the version of the other party, that is, they do not know the security features supported by the other party. Therefore, the security feature needs to be negotiated between the UE and the network equipment. In the embodiments of the present application, Rel-16, Rel-17, etc., are collectively referred to as post Rel-15.

It should be noted that in the description of this application, unless otherwise specified, "/" means that the associated objects before and after are in an "or" relationship, for example, A/B can mean A or B; in this application, " "And/or" is just an association relationship describing the associated objects, which means that there can be three relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone. , Where A and B can be singular or plural. Also, in the description of this application, unless otherwise specified, "plurality" means two or more than two. "The following at least one item (a)" or similar expressions refers to any combination of these items, including any combination of a single item (a) or a plurality of items (a). For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple . In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish the same items or similar items with substantially the same function and effect. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and order of execution, and the words "first" and "second" do not limit the difference.

In addition, the network architecture and business scenarios described in the embodiments of this application are intended to illustrate the technical solutions of the embodiments of this application more clearly, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Those of ordinary skill in the art will know that With the evolution of the network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

Figure 1 shows the specific process of using ABBA to resist dimensionality reduction attacks in standard 33.501, including:

Step 101: The UE sends a registration request (registration request, RR) message to the AMF, where the RR message carries security features supported by the UE. Optionally, the RR message may be unprotected, so the attacker may tamper with the security features supported by the UE, so that the network side thinks that the UE supports low-version security features, causing a dimensionality reduction attack.

Step 102: SEAF (Security Anchor Function) decides to initiate a master authentication. Among them, AMF and SEAF are co-located, which can be regarded as a network function (network fuction, NF).

Step 103: The SEAF sends an authentication service request to an authentication service function (AUthentication Server Function, AUSF). For example, the authentication service request may be Nausf_UEAuthentication_Authenticate Request. AUSF returns an authentication service response to SEAF. For example, the authentication service response may be Nausf_UEAuthentication_AuthenticateResponse.

In step 104, the SEAF may set the inter-architecture anti-bidding down between architectures (ABBA) parameters according to the security features supported by the UE and the security features supported or selected by the AMF sent in step 101.

Step 105: The SEAF sends an authentication request to the UE through the AMF. For example, the authentication request may be an authentication request. The authentication request includes ABBA parameters.

Wherein, after the UE receives the authentication request in step 105, it can obtain ABBA parameters. According to ABBA parameters, the security features supported or selected by AMF can be determined. However, since the authentication request in step 105 is not protected, the attacker may still tamper with the ABBA parameters. Therefore, a follow-up authentication process is required to check whether the ABBA parameters have been tampered with.

Step 106: The UE returns an authentication response to the SEAF through AMF. For example, the authentication response may be authentication response.

Step 107: SEAF sends an authentication service request to AUSF. For example, the authentication service request may be Nausf_UEAuthentication_Authenticate request.

Step 108, AUSF returns an authentication service response to SEAF. For example, the authentication service response may be Nausf_UE Authentication_Authenticage response. The authentication service response may include the SEAF key, that is, K _SEAF .

In step 109, the SEAF may generate K _AMF according to the ABBA parameters set in the above step 104 and the K _SEAF carried in the above step 108. And SEAF sends K _AMF to AMF.

In step 1010, the AMF generates a non-access-stratum (non-access-stratum, NAS) integrity key K _NASint and a NAS encryption key K _NASenc _{according to the received K AMF} .

In step 1011, the AMF sends a NAS security mode command (SMC) to the UE. The NAS SMC carries the ABBA parameter, and the NAS SMC uses K _NASint for integrity protection.

Step 1012, since the above-mentioned NAS SMC only performs integrity protection, it does not perform encryption protection. Therefore, it can be considered that the above ABBA parameters are transmitted in plain text. After receiving the NAS SMC, the UE can obtain ABBA parameters. The UE can generate the K _AMF key according to the above ABBA and K _SEAF. Further, according to the K _AMF key, K _NASint and K _{NASenc are} generated. And use K _{NASint to} verify the integrity of the above-mentioned NAS SMC. If the verification is successful, the ABBA has not been tampered with. According to the fact that the ABBA has not been tampered with, the UE can determine that the security features supported by the UE sent by the UE to the network side have not been tampered with; the security features supported or selected by the network side sent by the network side to the UE have not been tampered with either. Before step 1012, the method may further include: UE generating K _SEAF . The UE can generate the K _SEAF at any time after the UE receives the authentication request (that is, step 105).

Step 1013: After successfully verifying the NAS SMC, the UE may send a NAS security mode complete (SMP) message to the AMF. The above-mentioned NAS SMP message is _{encrypted by K NASenc} , and K _{NASint is} used for integrity protection.

Among them, after the AMF receives the NAS SMP, it can use K _NASint to verify the integrity of the NAS SMF, and use K _NASenc to decrypt the NAS SMP. The order of the two is not limited. If the verification is successful, the network side can confirm that the security features supported by the UE received by the network side have not been tampered with, and the ABBA parameters received by the UE have not been tampered with.

Optionally, if the UE fails to verify the integrity of the NAS SMC in step 1012, it means that the ABBA parameters may be tampered with. Therefore, the above step 1013 can be replaced by: the UE sends a NAS security mode rejection message to the AMF. After the AMF receives the NAS security mode rejection message, the AMF terminates the registration process.

Through the above process: the UE and the network side have negotiated security features, and use ABBA as one of the parameters to generate the K _AMF key, and further generate the NAS integrity key and the encryption key _{according to the K AMF key.} If a dimensionality reduction attack occurs (the security feature sent by the UE and/or the network device is tampered with), the UE and the network device can detect the tampering and terminate the process.

Furthermore, it can be seen from the above-mentioned process of FIG. 1 that in the above-mentioned anti-dimensionality reduction attack process, the UE and the SEAF respectively generate the K _AMF key according to the ABBA parameters. Further, according to the K _AMF key, a NAS integrity key and an encryption key are generated. After that, the UE uses the NAS integrity key to verify the NAS SMC. If the verification is successful, the UE can determine that the security features supported by the UE sent by the UE to the network side have not been tampered with. The security features supported or selected by the network side sent to the UE by the network side have not been tampered with either. SEAF can use the integrity key and/or encryption key to verify the NAS SMP. If the verification is successful, the SEAF can determine that the security features supported by the network side sent by the network side to the UE have not been tampered with, and the security features supported by the UE sent by the UE to the network side have not been tampered with either.

To provide a scenario for the above, when an AMF change occurs, for example, the UE moves in an idle state, the AMF serving the UE changes from the old AMF (Old AMF) to the target AMF (Target AMF), or N2 handover occurs, and the UE serving the UE AMF changes from Old AMF to Target AMF, and there may be differences between the security features of Old AMF and Target AMF. At this time, how to _{update the above-mentioned K AMF} key is a problem to be solved in the embodiment of this application.

As shown in Figures 2a to 5, there are several possible scenarios in which the AMF serving UE changes from Old AMF to Target AMF, or the network function serving UE changes from MME to Target AMF, and the problems that may arise in each scenario.

Figure 2a shows the specific flow of the security processing of the UE's 5GS idle state mobility defined in the standard 33.501, and the flow includes:

Step 201: The UE registers with Old AMF. Among them, a security context is established between the Old AMF and the UE. Old AMF can assign a 5G global unique temporary UE identity (5G-GUTI) to the UE.

In step 202, the UE moves in an idle state. For example, the UE moves to the registration area (reregistration area, RA) of Target AMF.

Step 203: The UE sends a registration request (registration request, RR) message to the Target AMF, and the RR message may carry the 5G-GUTI of the UE.

Step 204: If there is a 5G-GUTI in the RR, the Target AMF determines the Old AMF according to the 5G-GUTI, and requests the UE's security context from the Old AMF. For example, the Target AMF may send the UE's Security Context Transfer Request (Namf_communication_UEContextTransfer Request) message to the Old AMF.

Step 205: The Old AMF sends the security context of the UE to the target AMF, and the security context of the UE includes the AMF key, that is, K _AMF . For example, the Old AMF may send a UE context transfer response (Namf_Communication_UEContextTransfer Response) message to the Target AMF, and the UE context transfer response message may carry the security context of the UE.

Step 206, Target AMF can choose to use the received UE’s security context according to the local policy, that is, use the received AMF key (ie K _AMF ), and generate NAS encryption and integrity keys based on the received AMF key. , To protect the communication between the UE and the target AMF. Alternatively, Target AMF may choose not to use the received security context according to local policies and initiate the authentication process.

In the process of UE mobile registration in idle state, dimensionality reduction attacks may occur. As shown in Figure 2b, consider the following scenario 1: UE supports post Rel-15 security features, Old AMF supports Rel-15 security features, Target AMF supports post Rel-15 security features.

When the UE is registered with the Old AMF and the Old AMF serves the UE, the security features used by the UE and the Old AMF can only be Rel-15. In the derivation of the AMF key, the ABBA parameters (called ABBA_Old) used include: UE security features (post Rel-15 security features), Old AMF security features (rel-15 security features).

The UE moves in an idle state and is registered with Target AMF. The UE and Target AMF support the security features of post Rel-15 at the same time. According to the existing process, if the Target AMF decides to use the security context sent by the Old AMF, the Target AMF will not negotiate the security features with the UE. The following problems exist:

1) Target AMF and UE do not know the security features supported by each other. The UE and Target AMF use the security features of Rel-15. In fact, the UE and Target AMF support the post Rel-15 feature at the same time, so that security feature reduction occurs.

2) The ABBA at this time should also be updated to include: the security features supported by the UE (the security features of post Rel-15) and the security features supported by the Target AMF (the security features of Post Rel-15). Further, it is necessary to use the updated ABBA (called ABBA_new) as a new parameter to generate the K _AMF key. However, in the above process of Figure 2a, when Target AMF decides to use the security context sent by Old AMF, the AMF key in it is still generated by ABBA_Old.

Therefore, in the above scenario 1, the following problem needs to be solved: when the UE is moving in an idle state, how the UE and the network side negotiate security features, generate a new ABBA (referred to as ABBA_New), and use ABBA_New to generate the AMF key.

As shown in Figure 2c, consider the following scenario 2c: Old AMF and UE support post Rel-15 security features at the same time, Target AMF supports Rel-15 security features, as shown in the following figure.

When the UE is registered with Old AMF, and the Old AMF serves the UE, the Old AMF and the UE use the post Rel-15 security feature. After the UE is registered to the Target AMF in the idle state, there is no security feature negotiation between the Target AMF and the UE, and the Target AMF and the UE do not know the security features supported by each other. The UE still uses the security features of post Rel-15, and Target AMF does not support the security features of post Rel-15, which will cause the communication between the UE and the Target AMF to fail. In this scenario, the same needs to be solved: when the UE is moving in an idle state, how the UE and the network side negotiate security features, generate a new ABBA (referred to as ABBA_new), and use ABBA_new to generate a key.

Figure 3 shows the specific flow of the security processing of N2 handover defined in the standard 33.501, which includes:

In step 301, the UE registers with the Old AMF, and a security context is established between the UE and the Old AMF.

Step 302: Old AMF initiates N2 handover.

Step 303: The Old AMF sends a context creation request to the Target AMF. The context creation request carries the UE security context, and the UE security context includes the AMF key. For example, the context creation request may be Namf_Communication_CreateUEContext Request.

Step 304, other processes in N2 handover.

Step 305: The UE initiates a registration request. For example, the UE may send an RR message to Target AMF.

In step 306, Target AMF can choose to use the received UE security context according to the current policy; or, according to the local policy, it can also choose not to use the received UE security context and initiate an authentication process.

Also considering the above scenario 1, the UE and Target AMF support the post Rel-15 security feature, and the Old AMF supports the Rel-15 security feature. When the UE switches from the Old AMF to the Target AMF, the Target AMF and the UE do not know the security features supported by the other party, which may lead to a reduction in the security features. It is also necessary to solve the technical problem of scenario 1 above.

Also consider the above scenario 2, UE and Old AMF support post Rel-15 security feature, Target AMF supports Rel-15 security feature. When the UE switches from Old AMF to Target AMF, Target AMF does not negotiate security features with UE, Target AMF and UE do not know the security features supported by each other, UE uses Post Rel-15 security features, Target AMF uses Rel-15 security features , Causing the communication between the UE and the Target AMF to fail. It is also necessary to solve the technical problems in Scenario 2 above.

Figure 4 shows the security processing flow of the N26 handover of UE from an evolved packet system (evolved packet system, EPS) (ie 4G system) to a 5G system (5G system, 5GS) defined in the standard 33.501, which includes:

Step 400: The UE registers with a mobility management entity (MME).

Step 401: MME decides to initiate N26 handover.

Step 402: The MME sends a forwarding relocation request to the Target AMF. For example, the forwarding relocation request may be Forward Relocation Request. The forwarding relocation request includes the EPS security context of the UE, and the EPS security context of the UE includes the MME key K _ASME .

Step 403: Target AMF creates a 5G security context according to the received EPS security context of the UE. The AMF key in the 5G security context, namely K _AMF, is generated according to the key K _ASME. Optionally, Target AMF can generate a NAS encryption key and an integrity key _{according to the generated AMF key K AMF and the selected 5G security algorithm.}

Step 404: The Target AMF sends a forwarding relocation response to the MME. For example, the forwarding relocation response may be Forward Relocation Response. The forwarding relocation response includes a NAS container (NASC). The NASC includes the security parameters required to create a 5G security context, such as 5G security algorithms.

Step 405: The MME sends a handover command to the UE, and the handover command carries NASC.

Step 406: The UE creates a 5G security context according to the received security parameters included in the NASC and the EPS security context of the UE.

Step 407: The UE sends a registration request RR message to the Target AMF. Optionally, after the Target AMF receives the registration request RR message, it can choose not to perform the primary authentication or perform the primary authentication according to the local policy.

In the above process in Figure 4, after the Target AMF receives the RR message of the UE, when the Target AMF decides not to perform authentication, a dimensionality reduction attack may occur. Because both the Target AMF and the UE create a 5G security context based on the EPS security context of the UE, the UE and the Target AMF do not negotiate security features. The UE and the Target AMF do not know the security capabilities supported by the other party, and both the UE and the Target AMF adopt the security capabilities of Rel-15. In fact, both UE and Target AMF may support post Rel-15 security features. In addition, the ABBA_New parameter is not used in the AMF keys used by the UE and Target AMF. The issues that need to be resolved include the following:

1. After the UE switches from EPS to 5GS, it needs to negotiate security features with Target AMF.

2. According to the security features supported by the UE and Target AMF, generate the ABBA_New parameter, and use ABBA_New as the key input parameter to generate a new key.

Figure 5 shows the specific flow of the security processing of UE moving from EPS idle state to 5GS defined in the standard 33.501. The flow includes:

In step 500, the UE registers with the MME.

In step 501, the UE moves to 5GS in the idle state.

Step 502: The UE sends an RR message to Target AMF. Optionally, the RR message may include 5G-GUTI.

Step 503: After the Target AMF receives the RR message sent by the UE, it sends a context request to the MME that previously served the UE. For example, the context request may be Context Request.

Step 504: The MME sends a context response to the Target AMF. For example, the context response may be Context Response. The context response includes the EPS security context of the UE. The EPS security context of the UE includes the key K _{ASME of the} MME.

Step 505: Target AMF creates a 5G security context according to the received EPS security context of the UE. The 5G security context includes the AMF key K _AMF _{derived from the above K ASME} .

Step 506, if the Target AMF receives the 5G-GUTI in the RR message. Then the Target AMF can find the Old AMF to which the 5G-GUTI is allocated according to the received 5G-GUTI. And send a UE context request message to Old AMF. For example, the UE context request message may be Namf_Communication_UEContextTransfer Request.

Step 507: The Old AMF finds the 5G security context of the UE according to the 5G-GUTI, and returns it to the Target AMF. For example, the Old AMF may send a UE context response to the Target AMF, and the UE context response includes the 5G security context. For example, the UE context response may be Namf_Communication_UEContextTransfer Response.

It should be noted that if the Target AMF receives the 5G security context from the Old AMF, the Target AMF discards the 5G security context generated according to the EPS security context in step 505, and instead uses the 5G security context received from the Old AMF.

In step 508, if the Target AMF fails to obtain the 5G security context from the Old AMF, the Target AMF may choose to use the 5G security context generated in step 505 according to the local policy, or initiate a master authentication to generate a new 5G security context.

Step 509: The Target AMF sends a NAS SMC to the UE, which is used to negotiate the security context to be used and establish a security association with the UE.

Step 510: The UE replies to the NAS SMP to the Target AMF. The establishment of the security association between the UE and the Target AMF is complete.

In the process shown in Figure 5 above, it can be seen that the security context used by the Target AMF and UE to communicate can have any of the following situations:

1. Target AMF generates a 5G security context (called a mapped 5G security context, that is, a mapped 5G security context) based on the EPS security context obtained from the MME;

2. Target AMF obtains 5G security context from Old AMF.

3. Target AMF and UE perform master authentication to generate a new 5G security context.

In the first two cases mentioned above, there is no security feature negotiation between the UE and the Target AMF. The UE and the Target AMF do not know the security features of each other, and Rel-15 is used by default. In fact, both the UE and Target AMF may support the Post Rel-15 security feature, so dimensionality reduction attacks have occurred. In addition, according to the security features supported by the UE and Target AMF, it is possible to generate a new ABBA parameter, namely the ABBA_New parameter, and ABBA_New should be used as the parameter to generate a key for the UE and AMF to use. However, in the existing process, the UE and Target AMF are based on the key obtained from the MME or Old AMF and do not use the ABBA_New parameter. The problems that need to be resolved include:

1. Security feature negotiation between UE and Target AMF.

2. According to the security features supported by the UE and Target AMF, the ABBA_New parameter is generated. And use the ABBA_New parameter as the input parameter to generate a new key.

Based on the description of the scenarios shown in Figures 2a to 5 above, when the UE registers or switches to a Target AMF, the following two problems need to be solved:

1. Negotiation of security features between UE and Target AMF.

2. According to the security features supported between the UE and the Target AMF, generate the ABBA_New parameter, and use ABBA_New as the input parameter to generate a new K _AMF key for the UE and the Target AMF to use.

Based on the foregoing, embodiments of the present application provide a communication method, device, and system. The method includes: Target AMF determines the security features of the UE; Target AMF determines the security features of the UE in any of the following ways: Target AMF can communicate with the UE The security feature of the UE is negotiated to obtain the security feature of the UE; or the Target AMF can obtain the security feature of the UE from the Old AMF; or the Target AMF is obtained according to the local storage and configuration. Target AMF determines the ABBA_New parameter according to the security features of the UE and Target AMF. Target AMF uses ABBA_New to derive a new AMF key; specifically, Target AMF obtains the AMF key used by Old AMF, and generates a new AMF key based on the AMF key of Old AMF and ABBA_New.

The communication method of the embodiment of the present application can be applied to a network architecture. As shown in Figure 6, a schematic diagram of the network architecture is provided, including the access network and the core network.

Among them, the access network is used to implement functions related to wireless access, and the access network device is a device that provides access for terminal devices. Access network equipment includes radio access network (RAN) equipment and/or access network (access network, AN) equipment. The RAN device may be an access network device defined in the 3rd generation partnership project (3GPP). The AN device may be an access network device defined by non-3GPP (non-3GPP).

RAN equipment is mainly responsible for radio resource management, quality of service (QoS) management, data compression, and security processing on the air interface side. The RAN equipment may include various forms of base stations. For example, a macro base station, a micro base station (small station), a relay station, or an access point, etc. RAN equipment includes, but is not limited to: next-generation base stations (gNB) in 5G, evolved node B (evolved node B, eNB), radio network controller (RNC), node B (node B, NB), base station controller (BSC), base transceiver station (base transceiver station, BTS), home base station (for example, home evolved nodeB, or home node B, HNB), baseband unit (BBU) , Transmitting and receiving point (TRP), transmitting point (TP), mobile switching center, etc. The RAN device may also be a wireless controller, a centralized unit (CU), and/or a distributed unit (DU) in a cloud radio access network (cloud radio access network, CRAN) scenario, or the RAN device may It is relay station, access point, in-vehicle equipment, terminal equipment, wearable equipment, and access network equipment in the future 6G network or access network equipment in the public land mobile network (PLMN) network that will evolve in the future Wait.

AN equipment is used to enable non-3GPP technology to be used for interconnection and intercommunication between terminal equipment and the 3GPP core network. The non-3GPP technologies include but are not limited to: wireless fidelity (WIFI), worldwide interoperability for microwave access (WiMAX), code division multiple access (CDMA) network technologies, etc. .

Among them, the core network equipment may include one or more of the following network elements: access and mobility management function (AMF) network elements, session management function (session management function, SMF network elements) network elements, User plane function (UPF network element) network element, policy control function (PCF) network element, application function (AF) network element, unified data management (UDM) network Element, authentication server function (authentication server function, AUSF) network element, network slice selection function (network slice selection function, NSSF) network element.

AMF network element: Mainly responsible for the mobility management in the mobile network, such as user location update, user registration network, user handover, etc. SMF network element: Mainly responsible for session management in the mobile network, such as session establishment, modification, and release. Specific functions include assigning IP addresses to users and selecting UPF network elements that provide message forwarding functions. UPF network element: Mainly responsible for the forwarding and receiving of user data. In the downlink transmission, the UPF network element can receive user data from the data network (DN) and transmit it to the terminal device through the access network device; in the uplink transmission, the UPF network element can receive the user data from the terminal device through the access network device User data, forward the user data to the DN. Optionally, the transmission resources and scheduling functions in the UPF network element that provide services for the terminal device can be managed and controlled by the SMF network element. PCF network element: It mainly supports the provision of a unified policy framework to control network behavior, provides policy rules to the control layer network functions, and is responsible for obtaining user subscription information related to policy decisions. AF network element: It mainly supports interaction with the 3GPP core network to provide services, such as influencing data routing decisions, policy control functions, or providing third-party services to the network side. UDM network elements are mainly used to generate authentication credential, user identification processing (such as storage and management of user permanent identities, etc.), access authorization control and contract data management, etc. The AUSF network element is mainly used to perform authentication when the terminal device accesses the network, including receiving authentication requests sent by the security anchor function (SEAF), selecting the authentication method, and sending the authentication storage and processing function ( authentication repository and processing function (ARPF) request authentication vector, etc. NSSF network elements are mainly used to select network slice instances for terminal devices, determine allowed network slice selection assistance information (NSSAI), configure NSSAI, and determine the AMF set that serves the UE.

Optionally, the network architecture shown in FIG. 6 may further include: terminal equipment. A terminal device can be referred to as a terminal for short. It is a device with a wireless transceiver function. The terminal device can be deployed on land, including indoor or outdoor, handheld or vehicle-mounted; it can also be deployed on the water (such as ships, etc.); it can also be deployed on In the air (for example, airplanes, balloons, satellites, etc.). The terminal device may be a mobile phone (mobile phone), a tablet computer (pad), a computer with wireless transceiver function, virtual reality (VR) terminal equipment, augmented reality (AR) terminal equipment, industrial control ( Wireless terminal equipment in industrial control, wireless terminal equipment in self-driving, wireless terminal equipment in remote medical, wireless terminal equipment in smart grid, transportation safety (transportation) Wireless terminal equipment in safety), wireless terminal equipment in a smart city (smart city), wireless terminal equipment in a smart home (smart home), and may also include user equipment (UE), etc. The terminal device can also be a cellular phone, a cordless phone, a session initiation protocol (session initiation protocol, SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (personal digital assistant, PDA), with wireless communication Functional handheld devices, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in the 5th generation (5G) network in the future, or public land mobile communication networks that will evolve in the future ( Public land mobile network (PLMN) terminal equipment, etc. Terminal equipment can sometimes be called terminal equipment, user equipment (UE), access terminal equipment, vehicle terminal equipment, industrial control terminal equipment, UE unit, UE station, mobile station, mobile station, remote station, remote terminal Equipment, mobile equipment, UE terminal equipment, terminal equipment, wireless communication equipment, UE agent or UE device, etc. The terminal device can also be fixed or mobile. The embodiments of the present application are not limited thereto. As an example and not a limitation, in the embodiment of the present application, the terminal device may be a wearable device. Wearable devices can also be called wearable smart devices. It is a general term for using wearable technology to intelligently design daily wear and develop wearable devices, such as glasses, gloves, watches, clothing and shoes. A wearable device is a portable device that is directly worn on the body or integrated into the user's clothes or accessories. A wearable device is not only a hardware device, but also a device that achieves powerful functions through software support, data interaction, and cloud interaction. In a broad sense, wearable smart devices include full-featured, large-sized, complete or partial functions that can be achieved without relying on smart phones, such as smart watches or smart glasses, and only focus on a certain type of application function, which need to cooperate with other devices such as smart phones. Use, such as all kinds of smart bracelets and smart jewelry for physical sign monitoring. In this application, the terminal device can be a terminal in the Internet of Things (IoT) system. IoT is an important part of the development of information technology in the future. Its main technical feature is to connect objects to the network through communication technology to achieve An intelligent network of interconnection of humans and machines, and interconnection of things. The terminal device in this application may be a terminal device in machine type communication (MTC). The terminal device of the present application may be an in-vehicle module, an in-vehicle module, an in-vehicle component, an in-vehicle chip, or an in-vehicle unit that is built into a vehicle as one or more components or units. Components, on-board chips or on-board units can implement the method of the present application. Therefore, the embodiments of the present application can be applied to the Internet of Vehicles, such as vehicle to everything (V2X), long term evolution vehicle (LTE-V), and vehicle to vehicle (V2V). Wait.

Optionally, the network architecture shown in FIG. 6 may further include: DN. DN can be a service network that provides users with data service services. For example, the DN may be an IP multi-media service (IP multi-media service) network or the Internet (Internet), etc. Among them, the terminal device can establish a protocol data unit (protocol data unit, PDU) session from the terminal device to the DN to access the DN.

It should be noted that in different communication systems, the network elements in the above-mentioned core network may have different names. In the schematic diagram shown in FIG. 6 above, the fifth generation mobile communication system is taken as an example for description, and it is not intended to limit the application. Further, the core network element in FIG. 6 is only a schematic illustration, and is not intended as a limitation to the embodiment of the present application. For example, in the network architecture shown in Figure 6, the core network elements may also include: network exposure function (NEF), network storage function (network repository function, NRF), or service control point (service control point) , SCP), etc., one or more network elements, etc.

In the description of this application, the first AMF is Target AMF, the second AMF is Old AMF, the terminal device is UE, the ABBA_New parameter is the first ABBA parameter, and the ABBA_Old parameter is the second ABBA parameter as an example.

In the description of this application, the security feature of the UE may specifically be a security feature supported by the UE or a security feature selected by the UE. The security features of the Target AMF may be specifically the security features supported by the Target AMF, or the security features selected by the Target AMF. The security features of Old AMF may specifically be security features supported by Old AMF, or security features selected by Old AMF.

In the description of this application, "security features", "supported security features" and "selected security features" can be substituted for each other without distinction. In addition, in the description of this application, ABBA_Old and ABBA_old can be substituted for each other. ABBA_New and ABBA_new can replace each other. The AMF key can be K _AMF , and the MME key can be K _ASME . ABBA_New includes the security features of the UE and the security features of Target AMF; or ABBA_New includes the indication of the security features of the UE and the indication of the security features of the Target AMF. ABBA_Old includes the security features of the UE and the security features of Old AMF; or ABBA_Old includes the indication of the security features of the UE and the indication of the security features of Old AMF.

In the description of this application, the Old AMF AMF key or Old AMF key refers to the AMF key used by the UE and Old AMF when the UE is registered with the Old AMF (or the Old AMF serving UE). The UE generates the AMF key during the authentication process. Old AMF is the AMF key sent by SEAF to Old AMF.

In this application, the Old AMF key, Old AMF AMF key, Old AMF sent AMF key to Target AMF, and Target AMF received Old AMF sent AMF key are all the same, and can be used interchangeably .

Please refer to FIG. 7a, which is a flowchart of a communication method provided by an embodiment of this application. Including but not limited to the following steps:

Step 701a: Target AMF determines the security features of the UE.

Step 701a: Target AMF determines the AMF key of Old AMF.

Optionally, it can be seen from the above description that the UE and Target AMF can support one or more security features. For example, in the current standard 33.501, the UE and Target AMF may only support the security features of Rel-15. In the future evolution, UE and Target AMF can support security features such as Rel-16 and Rel-17.

In a possible implementation, Target AMF can obtain the security features supported by the UE in any of the following ways: Old AMF sends the security features supported by the UE to the Target AMF; Target AMF obtains the security supported by the UE from the local storage Features: Old AMF sends the ABBA_Old parameter to Target AMF. The AABA_Old parameter includes the UE’s security feature or the UE’s security feature indication, and the Old AMF’s security feature or Old AMF’s security feature indication.

In a possible implementation manner, the Target AMF can obtain the AMF key of the Old AMF in the following manner: Old AMF sends the AMF key of the Old AMF to the Target AMF. For example, the Target AMF can send a request message for requesting the context of the terminal device to the Old AMF. When the Old AMF receives the above request, it sends the UE context to the Target AMF, and the UE context carries the AMF key of the Old AMF. For another example, the Old AMF sends a context creation request to the Target AMF, and the request includes the AMF key of the Old AMF. In the middle of this application, the AMF key sent by the Old AMF to the Target AMF may be the current AMF key of the Old AMF, or the old AMF derived from the _{current AMF key by horizontal K AMF.}

Step 702a: The Target AMF determines the ABBA_New parameter according to the security features of the UE and the security features of the Target AMF.

In step 703a, the Target AMF determines the AMF key of the Target AMF according to the ABBA_New parameter and the AMF key of the Old AMF, which also becomes the new AMF key. Afterwards, the Target AMF can derive the NAS integrity key and encryption key based on the AMF key of the Target AMF. And according to the NAS integrity key and encryption key, integrity protection and encryption protection are performed on the communication between the UE and the network device. Ensure communication security.

Optionally, in step 704a, the Target AMF sends the ABBA_New parameter and optional first indication information to the UE. In this application, the first indication information is used to instruct the UE to update the AMF key according to the ABBA_New parameter or to instruct the UE to update the AMF key.

When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE is receiving the first indication information, it may generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key, and uses the AMF keys of ABBA_New and Old AMF in the same way as the network side.

Optionally, before the Target AMF determines the ABBA_New parameter according to the security features of the UE and the security features of the Target AMF, the method further includes that the Target AMF determines the security features of the Old AMF; when the security features of the Target AMF and the Old AMF are different, Re-execute the steps in the above steps 702a-704a, otherwise, do not execute it again.

Please refer to FIG. 7b, which is another flowchart of the communication method provided in this embodiment of the application, including but not limited to the following steps:

Step 701b: Target AMF determines the security features of the UE. Refer to the description of 701a for the method for Target AMF to determine the security features of the UE.

Step 701b, Target AMF determines the MME key K _ASME of the MME.

In a possible implementation manner, the Target AMF may obtain the MME key of the MME in the following manner: the MME sends the MME key to the Target AMF. For example, the Target AMF sends a context request to the MME, and the MME replies with a context response, and includes the MME key K _ASME of the MME in the response. For another example, the MME sends a Forward Relocation Request (Forward Relocation Request) to the Target AMF, and the request includes the MME key K _ASME of the MME, etc., which is not limited. Regarding the manner in which the Target AMF determines the security feature of the UE, refer to the record in FIG. 7a above, which will not be described here.

Step 702b: The Target AMF determines the ABBA_New parameter according to the security features of the UE and the security features of the Target AMF.

Step 703b: The Target AMF determines the AMF key of the Target AMF according to the ABBA_New parameter and the MME key.

Optionally, in step 704b, the Target AMF may send the ABBA_New parameter and optional first indication information to the UE. When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE is receiving the first indication information, it may generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side, and the parameters used include ABBA_New and MME key.

Example one

In the following embodiments, unless otherwise specified, AMF and SEAF are co-located and regarded as the same network function (network fuction, NF), that is, Target AMF and SEAF are the same NF and can be used interchangeably.

Referring to Figure 8a, in a possible implementation manner, Target AMF can obtain the security features supported by the UE. For example, the Target AMF can receive the security features supported by the UE sent by the Old AMF, or the Target AMF can obtain the security features supported by the UE from the local storage, or the Target AMF can receive the ABBA_Old parameter sent by the Old AMF. After that, Target AMF sets ABBA_New according to the security features supported by UE and Target AMF. Target AMF derives a new AMF key, namely K _AMF . The Target AMF sends the ABBA_New parameter to the UE. Optionally, Target AMF may also send Indicator1 to the UE. Indicator1 is used to instruct the UE to update the AMF key or use ABBA_New to generate the key. When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE is receiving the first indication information, it may generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side.

Figure 8b shows a specific process of the first embodiment. For example, the process may be a schematic diagram of the security feature negotiation and key update process in the idle state mobile registration of the UE in 5GS, including but not limited to the following steps:

In step 801, the UE registers with Old AMF.

Step 802, the UE moves in an idle state.

Step 803: The UE sends a registration request RR message to the Target AMF. The RR message may carry the 5G-GUTI of the UE.

Step 804: If there is a 5G-GUTI in the RR, the Target AMF sends a UE context request message to the Old AMF. For example, the UE context request message may be Namf_Communication_UEContextTransfer Request.

Step 805: OldAMF sends a UE context response message to Target AMF. For example, the UE context response message may be Namf_Communication_UEContextTransfer Response. The UE context response message carries the security features supported by the UE, or the ABBA_Old parameter. The UE context response message also includes the AMF key of Old AMF. The AMF key may be an AMF key used by Old AMF, or a new key generated by _{Old AMF performing horizontal K AMF derivation on the used AMF key.} In this application, the AMF keys sent by Old AMF to Target AMF are collectively referred to as Old AMF AMF keys, which can be any of the above two types (ie, the AMF key used by Old AMF, or the AMF key used by the Old AMF). The key is _{a new key generated after horizontal K AMF} deduction), which will not be explained one by one later.

Step 806: The Target AMF generates an ABBA_New parameter according to the security features supported by the UE and the security features supported by the Target AMF. Target AMF can obtain the security features of the UE in the following ways: UE security features sent by Old AMF; ABBA_Old sent by Old AMF; Target AMF is obtained from local configuration and storage. Target AMF generates a new AMF key. The parameters used to generate a new AMF key include: the AMF key received from Old AMF and ABBA_New. Target AMF uses the generated new AMF key to generate NAS encryption key and integrity key.

Step 807: The Target AMF sends the NAS SMC to the UE, and the NAS SMC carries the ABBA_New parameter. Optionally, the NAS SMC may also include a first indication. The first indication may be called indicator1, which is used to instruct the UE to derive the AMF key or use ABBA_News to generate the AMF key.

In step 808, when the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE is receiving the first indication information, it may generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key, and uses the AMF keys of ABBA_New and Old AMF in the same way as the network side. Then the UE generates a NAS encryption key and an integrity key according to the generated new AMF key.

Figure 9 shows another specific process of the first embodiment. For example, the process may be the process of UE security feature negotiation and key update in N2 handover. The process includes but is not limited to:

Step 901, the UE registers with Old AMF.

Step 902: Old AMF initiates handover.

In step 903, the Old AMF requests the Target AMF to create a UE context. For example, Old AMF may send a UE context creation request message to Target AMF. For example, the UE context creation request message may be Namf_Communication_CreateUEContext Request. The UE context creation request message may carry security features supported by the UE, or the ABBA_Old parameter.

Step 904: Target AMF according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features supported by the Target AMF, Set ABBA_New. Target AMF generates a new AMF key. The parameters used to generate the new AMF key include: the Old AMF AMF key and ABBA_New received from the Old AMF. Target AMF uses the derived new key as the AMF key, and generates the NAS encryption key and the integrity key according to the new AMF key.

Step 905: The Target AMF returns a response message for creating a UE context to the Old AMF. The response message for creating the UE context may be Namf_Communication_CreateUEContext Response. The response message for creating the UE context includes ABBA_New. Optionally, the response message for creating the UE context may also include Indicator1. The Indicator1 is used to instruct the UE to derive the AMF key, or use ABBA_New to generate the AMF key.

Step 906: The Old AMF sends ABBA_New and optional Indicator1 to the UE through the access network. If Old AMF receives Indicator1 from Target AMF, it will forward the Indicator1 to the UE.

In step 907, when the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key, and uses the AMF keys of ABBA_New and Old AMF in the same way as the network side. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

Figure 10 is another specific process of the first embodiment. For example, the process can be a security feature negotiation and key update process in the UE handover from EPS to 5GS. The process includes but is not limited to:

Step 1000: UE registers with MME.

Step 1001: MME decides to initiate N26 handover.

Step 1002: The MME sends a forwarding relocation request message to the Target AMF. For example, the forwarding relocation request message may be Forward Relocation Request.

Step 1003: Target AMF creates a 5G security context.

Step 1004: The Target AMF sends a forwarding relocation response message to the MME. For example, the forwarding relocation response message may be Forward Relocation Response. The forwarding relocation response message carries NASC.

Step 1005: The MME sends a handover command to the UE. For example, the handover command may be Handover Command.

Step 1006: The UE creates a 5G security context.

Step 1007: The UE sends an RR message to Old AMF, and the RR message may include 5G-GUTI.

Step 1008: If the RR includes 5G-GUTI, the Target AMF sends a UE context request message to the Old AMF, and the context request message may be Namf_Communication_UEContextTransfer Request.

Step 1009: The Old AMF sends a UE context request response message to the Target AMF. The context request response message may be Namf_Communication_UEContextTransfer Response. The context request response message may include the security features supported by the UE, or the ABBA_Old parameter. The context request response message includes the AMF key of Old AMF.

Step 10010: Target AMF according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features supported by the Target AMF, Generate the ABBA_New parameter. Furthermore, Target AMF derives a new AMF key according to the ABBA_New parameter. Target AMF generates NAS encryption key and integrity key according to the new AMF key.

Step 10011: The Target AMF sends the NAS SMC to the UE. The NAS SMC carries the ABBA_New parameter and optional Indicator1. The Indicator1 is used to instruct the UE to use the ABBA_New parameter to derive a new AMF key; or to instruct the UE to perform AMF key deduction.

Step 10012: If the UE receives Indicator1, the UE derives a new AMF key in the same manner as the network side according to the received Indicator1. If the UE receives ABBA_New but not indicator1, the UE uses ABBA_New to derive the new AMF key in the same manner as the network side. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

Figure 11 is another specific process of the first embodiment. For example, the process may be a process of security feature negotiation and key update when the UE moves from EPS to 5GS in an idle state. This process includes but is not limited to:

Step 1100: UE registers with MME.

Step 1101: The UE moves in an idle state.

Step 1102: The UE sends an RR message to the Target AMF. The RR may carry 5G-GUTI.

Step 1103: The Target AMF sends a context request message to the MME, and the context request message may be Context Request.

Step 1104: The MME sends a context response message to the Target AMF, and the context response message may be Context Response. The context response message may include the EPS security context.

Step 1105: Target AMF creates a 5G security context.

Step 1106: If the RR carries 5G-GUTI, the Target AMF sends a UE context request to the Old AMF, and the UE context request may be Namf_Communication_UEContextTransfer Request.

Step 1107: The Old AMF sends a UE context response to the Target AMF, and the UE context response may be Namf_Communication_UEContextTransfer Response. The UE context response includes the security features supported by the UE, or the ABBA_Old parameter. The UE context response includes the AMF key of Old AMF.

Step 1108: Target AMF according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features supported by the Target AMF, Determine the ABBA_New parameter. And according to the ABBA_New parameter, a new AMF key is generated. Target AMF generates NAS encryption key and integrity key according to the new AMF key. The parameters used by Target AMF to generate new AMF keys include ABBA_New and Old AMF AMF keys.

Step 1109: The Target AMF sends the NAS SMC to the UE. The NAS SMC carries the ABBA_New parameter and optional Inicator1. The Indicator1 is used to instruct the UE to use the ABBA_New parameter to update the AMF key; or to instruct the UE to perform AMF key derivation.

Step 11010: When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same manner as the network side, and the parameters used include ABBA_New and Old AMF AMF keys. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

In the first embodiment above, the security feature negotiation between the Target AMF and the UE is realized, and ABBA_New is used as the key for deriving the AMF.

Example two

The second embodiment is different from the first embodiment. After the Target AMF obtains the security features supported by the UE, the Target AMF initiates the main authentication process. Through the main authentication process, the UE and Target AMF will negotiate security features, generate the ABBA_New parameter, and derive the new AMF key according to the ABBA_New parameter.

As shown in Figure 12, in a possible implementation, the Target AMF obtains the security features supported by the UE from the Old AMF. For example, the Old AMF may send the security features supported by the UE or the ABBA_Old parameter to the Target AMF. Alternatively, Target AMF can obtain the security features supported by the UE from local storage. After that, the Target AMF sets ABBA_New according to the security features supported by the UE and the security features supported by the Target AMF, initiates the main authentication process, and sends the set ABBA_New to the UE. For example, the Target AMF may send an authentication request (authentication request) to the UE, and the authentication request carries the aforementioned ABBA_New.

As shown in FIG. 13, a specific process of the second embodiment is provided. For example, the process may be a process in which the UE moves in an idle state in 5GS. This process includes but is not limited to:

Step 1301: UE registers with Old AMF.

Step 1302, the UE moves in an idle state.

Step 1303: The UE sends a registration request (registration requst, RR) message to the Target AMF, and the RR message may optionally carry 5G-GUTI.

Step 1304: If there is a 5G-GUTI in the RR, the Target AMF sends a UE context request message to the Old AMF. For example, the UE context request message may be Namf_Communication_UEContextTransfer Request.

Step 1305: The Old AMF sends a UE context response message to the Target AMF. For example, the UE context response message may be Namf_Communication_UEContextTransfer Response. The UE context response message may include security features supported by the UE or ABBA_Old.

Step 1306: Target AMF according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features supported by the Target AMF, Set ABBA_New.

Step 1307: The Target AMF sends an authentication request (authentication request) to the UE, and the authentication request carries the aforementioned ABBA_New. The UE uses the received ABBA_New to generate the AMF key.

It should be noted that in the embodiment of the present application, the process of N2 handover, handover from EPS to 5GS, and idle state movement from EPS to 5GS for the UE are similar to the above.

For the UE N2 handover (switch from Old AMF to Target AMF) scenario, except for the following steps, it is the same as the description of the process shown in Figure 3, and the different steps are:

Step 303: The Old AMF requests the Target AMF to create a UE context. For example, Old AMF may send a UE context creation request message to Target AMF. For example, the UE context creation request message may be Namf_Communication_CreateUEContext Request. The UE context creation request message may carry security features supported by the UE, or the ABBA_Old parameter.

The Target AMF generates ABBA_New according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features of the Target AMF. The Target AMF generating ABBA_New can occur at any time between steps 303 and 306.

Step 306: Target AMF sends an authentication request to the UE, and carries ABBA_New in the authentication request.

The UE uses ABBA_New to generate the AMF key.

For the UE handover scenario from EPS to 5GS, except for the following steps, it is the same as the process shown in Figure 10, with the different steps as follows:

Step 10010: Target AMF according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features supported by the Target AMF, Generate the ABBA_New parameter.

Step 10011: Target AMF initiates an authentication request to the UE, and the authentication request carries ABBA_New.

Step 10012: The UE uses the received ABBA_New to generate an AMF key.

For the scenario where the UE moves from EPS to 5GS in idle state, except for the following steps are the same as the process shown in Figure 11, the different steps are:

Step 1108: Target AMF according to the received security features supported by the UE (or the security features supported by the UE indicated in the received ABBA_Old, or the security features supported by the UE stored locally) and the security features supported by the Target AMF, Determine the ABBA_New parameter.

Step 1109: Target AMF sends an authentication request to the UE, and includes ABBA_New in the authentication request.

Step 11010: The UE uses the received ABBA_New to generate an AMF key.

In the second embodiment above, the security feature negotiation between the Target AMF and the UE is realized, and ABBA_New is used as the key derivation parameter to derive the AMF key.

Example three

As shown in Figure 14, in a possible implementation, the Target AMF obtains the security features supported by the Old AMF and the security features supported by the UE. For example, the Target AMF can receive the security features supported by the UE sent by the Old AMF and the security features supported by the Old AMF. Alternatively, the Target AMF may receive ABBA_Old sent by the Old AMF, and the ABBA_Old includes the security features supported by the UE and the security features supported by the Old AMF. Alternatively, the Target AMF may obtain the security features supported by the UE and/or the security features supported by the Old AMF based on local storage. Afterwards, the Target AMF can determine whether the security features supported by the Target AMF and the Old AMF are the same. If the security features supported by Old AMF are different from those supported by Target AMF, Target AMF can set ABBA_New according to the security features supported by UE and Target AMF. Target AMF derives a new AMF key according to the set ABBA_New, and notifies the UE to derive the AMF key. For example, the Target AMF may send a NAS SMC to the UE. The NAS SMC carries ABBA_New and optional Indicator1, which is used to instruct the UE to update the AMF key or generate a new AMF key according to ABBA_New.

The third embodiment is different from the above-mentioned first embodiment in:

1. Target AMF needs to obtain the security features supported by Old AMF.

2. Target AMF judges whether the security features supported by Target AMF and Old AMF are the same. If they are different, then Target AMF sets ABBA_New and derives the key. Otherwise, ABBA_New is no longer set.

FIG. 15 shows a process of the third embodiment. The process may be a specific process of the UE moving in the idle state of 5G, including but not limited to:

In step 1501, the UE registers with Old AMF.

In step 1502, the UE moves in an idle state.

Step 1503: The UE sends a registration request (registration request, RR) message to the Target AMF. The RR message may optionally include 5G-GUTI.

Step 1504: The Target AMF sends a UE context request to the Old AMF. For example, the UE context request may be Namf_Communicaiton_UEContextTransfer Request.

Step 1505: The Old AMF sends a UE context response to the Target AMF. For example, the UE context response may be Namf_Communicaiton_UEContextTransfer Request. The UE context response carries the security features supported by the UE and/or the security features supported by Old AMF, and/or ABBA_Old. ABBA_Old includes the security features of UE and the security features of Old AMF. Further, the UE context response also carries the AMF key of Old AMF.

Step 1506: If the security features supported by the Old AMF are different from the security features supported by the Target AMF, the Target AMF determines ABBA_New according to the security features of the UE and the Target AMF. Target AMF uses ABBA_New to derive the AMF key. The AMF key derived by Target AMF can also use the AMF key of Old AMF. In other words, Target AMF can derive the AMF key based on the AMF keys of ABBA_New and Old AMF. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

Step 1507: The Target AMF sends a NAS SMC to the UE, and the NAS SMC carries ABBA_New and optional Indicator1. The Indicator1 is used to instruct the UE to perform AMF key derivation, or to generate a new AMF key according to ABBA_New.

Step 1508: When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same manner as the network side, and the parameters used include ABBA_New and Old AMF AMF keys. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

Regarding the UE's N2 handover, the UE idle state moves from EPS to 5GS, and the UE switches from EPS to 5GS, the procedure is similar to the above.

For the UE N2 handover (switch from Old AMF to Target AMF) scenario, except that the following steps are the same as the process and description shown in Figure 9, the different steps are:

In step 903, the Old AMF requests the Target AMF to create a UE context. For example, Old AMF may send a UE context creation request message to Target AMF. For example, the UE context creation request message may be Namf_Communication_CreateUEContext Request. The UE context creation request message may carry the security features supported by the UE, and/or the security features of Old AMF, and/or the ABBA_Old parameter.

Step 904: If the security features supported by the Old AMF are different from the security features supported by the Target AMF, the Target AMF determines ABBA_New according to the security features of the UE and the Target AMF. Target AMF uses ABBA_New to derive the AMF key. Target AMF derives the AMF key and also uses the AMF key of Old AMF. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

For the UE handover scenario from EPS to 5GS, except that the following steps are the same as the process shown in Figure 10, the different steps are:

Step 1009: The Old AMF sends a UE context request response message to the Target AMF. The context request response message may be Namf_Communication_UEContextTransfer Response. The context request response message may include the security features supported by the UE, and/or the security features of Old AMF, and/or the ABBA_Old parameter.

Step 10010: If the security features supported by the Old AMF are different from the security features supported by the Target AMF, the Target AMF determines ABBA_New according to the security features of the UE and the Target AMF. Target AMF uses ABBA_New to derive the AMF key. Target AMF derives the AMF key and also uses the AMF key of Old AMF. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

For the scenario where the UE moves from EPS to 5GS in the idle state, except for the following steps are the same as the process shown in Figure 11, the different steps are:

Step 1107: The Old AMF sends a UE context response to the Target AMF, and the UE context response may be Namf_Communication_UEContextTransfer Response. The UE context response includes the security features supported by the UE, and/or the security features of Old AMF, and/or the ABBA_Old parameter.

Step 1108: If the security features supported by the Old AMF are different from the security features supported by the Target AMF, the Target AMF determines ABBA_New according to the security features of the UE and the Target AMF. Target AMF uses ABBA_New to derive the AMF key. Target AMF derives the AMF key and also uses the AMF key of Old AMF. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

In the third embodiment above, the security feature negotiation between the Target AMF and the UE is realized, and ABBA_New is used as the key derivation parameter and used as the AMF key.

Embodiment four

As shown in FIG. 16, in the fourth embodiment, the Target AMF obtains the security features supported by the UE and the security features supported by the Old AMF. If the security features supported by Old AMF are different from those supported by Target AMF, Target AMF sets the ABBA_New parameter according to the acquired security features supported by the UE and the security features supported by Target AMF, initiates the main authentication process, and sets the ABBA_New The parameters are sent to the UE through the main authentication process. For example, the Target AMF may send an authentication request (authentication request) to the UE, and the authentication request carries the ABBA_New parameter.

Target AMF can obtain the security features supported by the UE and/or the security features supported by the Old AMF in any of the following ways:

1. The Old AMF sends the security features supported by the UE and/or the security features supported by the Old AMF to the Target AMF.

2. Old AMF sends ABBA_Old to Target AMF.

3. The Target AMF obtains the security features supported by the UE and/or the security features supported by the Old AMF according to local storage or configuration.

The difference between the fourth embodiment and the second embodiment is:

1. Target AMF needs to obtain the security features supported by Old AMF.

2. Target AMF judges whether the security features supported by Target AMF and Old AMF are the same. If they are different, Target AMF sets the ABBA_New parameter and initiates the master authentication.

As shown in FIG. 17, a process of the fourth embodiment is provided. The process may be a specific process of the UE moving in the idle state of 5G, and the process includes but is not limited to:

Step 1701: The UE registers with Old AMF.

Step 1702, the UE moves in an idle state.

Step 1703: The UE sends a registration request (reqistration request, RR) to the Target AMF. The registration request optionally carries 5G-GUTI.

Step 1704: If 5G-GUTI is in the RR, the Target AMF sends a UE context request message to the Old AMF. For example, the UE context request message may be Namf_Communicaiton_UEContextTransfer Request.

Step 1705: The Old AMF sends a UE context response message to the Target AMF. For example, the UE context response message may be Namf_Communicaiton_UEContextTransfer Response. The UE context response message includes UE security security features, and/or security features supported by Old AMF, and/or ABBA_Old.

Step 1706: If the security features supported by the Old AMF and the Target AMF are different, the Target AMF determines ABBA_New according to the security features supported by the UE and the security features supported by the Target AMF.

Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

Step 1707: The Target AMF sends an authentication request (authentication request) to the UE, and the authentication request includes ABBA_New.

Regarding the N2 handover of the UE, the idle state of the UE moves from EPS to 5GS, and the UE switches from EPS to 5GS, similar to the above process.

For the UE N2 handover (switch from Old AMF to Target AMF) scenario, except that the following steps are the same as the process and description shown in Figure 3, the different steps are:

Step 303: The Old AMF requests the Target AMF to create a UE context. For example, Old AMF may send a UE context creation request message to Target AMF. For example, the UE context creation request message may be Namf_Communication_CreateUEContext Request. The UE context creation request message may carry the security features supported by the UE, and/or the security features of Old AMF, and/or the ABBA_Old parameter.

If the security features supported by Old AMF and Target AMF are different, Target AMF determines ABBA_New according to the security features supported by the UE and the security features supported by Target AMF. Target AMF setting ABBA_New can occur at any time between steps 303 and 306. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

The UE uses ABBA_New to generate the AMF key.

Step 10010: If the security features supported by the Old AMF and the Target AMF are different, the Target AMF determines ABBA_New according to the security features supported by the UE and the security features supported by the Target AMF. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

Step 10012: The UE uses the received ABBA_New to generate an AMF key.

For the scenario where the UE moves from EPS to 5GS in the idle state, except that the following steps are the same as the process shown in Figure 11, the different steps are:

Step 1107: Old AMF sends a UE context response to Target AMF, and the UE context response may be Namf_Communication_UEContextTransferResponse. The UE context response includes the security features supported by the UE, and/or the ABBA_Old parameter, and/or the security features of Old AMF.

Step 1108: If the security features supported by Old AMF and Target AMF are different, Target AMF determines ABBA_New according to the security features supported by the UE and the security features supported by Target AMF. Target AMF can obtain UE security features or Old AMF security features in any of the following ways: according to the UE security features or Old AMF security features sent by Old AMF; according to ABBA_Old sent by Old AMF; according to this configuration or storage.

Step 11010: The UE uses the received ABBA_New to generate an AMF key.

In the fourth embodiment above, the security feature negotiation between the Target AMF and the UE is realized, and ABBA_New is used as the parameter to derive the AMF.

Embodiment five

The fifth embodiment is different from the foregoing embodiments 1 to 4 in that the Target AMF obtains the UE security features and/or ABBA_Old from the UE, and ABBA_Old includes the security features supported by the UE and the security features supported by the Old AMF. Target can also obtain UE security features and/or Old AMF security features from local configuration or storage. After the Target AMF obtains the security features supported by the UE and/or the security features supported by the Old AMF, it can perform any one of the following four operations. This can be seen in Figure 18.

Operation 1: Determine ABBA_New according to the acquired security features of the UE and the security features supported by the Target AMF; Target AMF acquires the security features of the UE, which can be the security features of the UE received from the RR or the security features received from the RR The security features of the UE in ABBA_Old, or the security features of the UE configured or stored locally. Target AMF generates an AMF key according to ABBA_New. The parameters used to generate the AMF key include the set ABBA_New. The Target AMF sends the set ABBA_New and optional Indicator1 to the UE. When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side, and the parameters used include ABBA_New. Then the UE generates a NAS encryption key and an integrity key according to the newly generated AMF key. With reference to the first embodiment, the difference from the first embodiment is that the target AMF obtains the security feature in a different way.

Operation 2: Determine ABBA_New according to the acquired UE's security features and Target AMF's security features. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF uses ABBA_New when generating a new AMF key later. The Target AMF initiates the authentication process and sends ABBA_New to the UE; referring to the second embodiment, the difference from the second embodiment is that the target AMF obtains the security feature in a different way.

Operation 3: If the acquired security features supported by the Old AMF are different from those supported by the Target AMF, the Target AMF sets ABBA_New according to the acquired security features supported by the UE and the security features supported by the Target AMF. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF obtains the security features of Old AMF, which may be the security features of Old AMF in ABBA_Old received from the RR, or the security features of Old AMF that are locally configured or stored. Target AMF generates an AMF key according to ABBA_New. The parameters used to generate the AMF key include the set ABBA_New. The Target AMF sends ABBA_New and an optional indication Indicator1 to the UE. When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side, and the parameters used include ABBA_New. The parameters used by the UE to generate the AMF key include the received ABBA_New. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key. With reference to the third embodiment, the difference lies in the way in which the Target AMF obtains the security feature.

Operation 4: If the acquired security features supported by the Old AMF are different from those supported by the Target AMF, the Target AMF sets ABBA_New according to the acquired security features supported by the UE and the security features supported by the Target AMF. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF obtains the security features of Old AMF, which may be the security features of Old AMF in ABBA_Old received from the RR, or the security features of Old AMF that are locally configured or stored. Target AMF initiates the authentication process and sends the set ABBA_New to the UE. With reference to the fourth embodiment, note that the difference lies in the way in which the Target AMF obtains the security feature.

As shown in Figure 19, a specific process of Embodiment 5 is provided, and the process includes but is not limited to:

Step 1901: The UE sends a registration request (reqistration request, RR) message to the Target AMF, and ABBA_Old and/or the security feature of the UE in the RR message. The RR may carry 5G-GUTI.

Step 1902: If the RR carries 5G-GUTI, the Target AMF sends a UE context request message to the Old AMF. For example, the request message of the UE context may be Namf_Communication_UEContextTransfer Request.

Step 1903: The Old AMF receives the UE context response message sent by the Target AMF, where the UE context response message includes the AMF key of the Old AMF. For example, the response message of the UE context may be Namf_Communication_UEContextTransfer Response. The UE context response message includes the AMF key of Old AMF.

Optionally, in a possible implementation manner, the following operation one can be performed:

In step 1904a, the Target AMF determines ABBA_New according to the acquired security features of the UE and the security features of the Target AMF. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF generates a new AMF key. To generate a new AMF key, use ABBA_New. The new AMF key is derived, and the Old AMF AMF key is also used.

In step 1905a, the Target AMF sends the NAS SMC to the Old AMF, and the NAS SMC includes the ABBA_New parameter and the optional Indicator1. Indicator1 is used to instruct the UE to derive the AMF key, or to instruct the UE to use ABBA_New to generate the AMF key.

In step 1906a, when the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side, and the parameters used include ABBA_New. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

Optionally, in another possible implementation manner, the following operation two can be performed:

In step 1904b, the Target AMF determines ABBA_New according to the acquired security features of the UE and the security features of the Target AMF. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF uses ABBA_New when deriving a new AMF key later.

Step 1905b, Target AAMF initiates the main authentication process, and sends an authentication request (authentication request) to the UE. The authentication request includes the ABBA_New parameter. The UE uses the ABBA_New to generate the AMF key.

Optionally, in another possible implementation manner, the following operation three can be performed:

Step 1904c, if the acquired security features supported by the Old AMF are different from the security features supported by the Target AMF, the Target AMF sets ABBA_New according to the acquired security features supported by the UE and the security features supported by the Target AMF. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF obtains the security features of Old AMF, which may be the security features of Old AMF in ABBA_Old received from the RR, or the security features of Old AMF that are locally configured or stored. Target AMF uses ABBA_New to generate a new AMF key.

In step 1905c, the Target AMF sends a NAS message to the UE. The NAS message includes the ABBA_New parameter and optional Indicator1. Indicator1 is used to instruct the UE to derive the AMF key, or to instruct the UE to use ABBA_New to generate the AMF key.

In step 1906c, when the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side, and the parameters used include ABBA_New. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

Optionally, in another possible implementation manner, the following operation four can be performed:

In step 1904d, if the acquired security features supported by the Old AMF are different from those supported by the Target AMF, the Target AMF determines ABBA_New according to the acquired security features of the UE and the target AMF. The Target AMF obtains the security features of the UE, which may be the security features of the UE received from the RR, or the security features of the UE in ABBA_Old received from the RR, or the security features of the UE that are locally configured or stored. Target AMF obtains the security features of Old AMF, which may be the security features of Old AMF in ABBA_Old received from the RR, or the security features of Old AMF that are locally configured or stored. Target AMF uses ABBA_New when deriving a new AMF key later.

Step 1905d, Target AMF initiates the main authentication process, and sends an authentication request (authentication request) to the UE. The authentication request includes the ABBA_New parameter. After that, the UE generates a new AMF key according to ABBA_New.

In the fourth embodiment above, the security feature negotiation between the Target AMF and the UE is implemented, and ABBA_New is used as an input parameter to generate a new AMF key.

Example Six

In the first to fifth embodiments above, Target AMF acquires security features, sets ABBA_New, and derives the AMF key. In the sixth embodiment of this application, Old AMF obtains the security feature and sets ABBA_New. Old AMF can also derive the key based on ABBA_New. For example, see Figure 20.

Old AMF acquires the security features of Target AMF. Old AMF obtains Old AMF to obtain the security features of Target AMF through: Target AMF can send Target AMF security features to Old AMF; or Old AMF obtains Target AMF security features based on local storage or configuration.

Old AMF determines ABBA_New according to the security features of UE and Target AMF.

Old AMF derives a new AMF key. The parameters used to derive the new AMF key include ABBA_New. The parameters used to derive the new AMF key can also include any of the following:

1. The current AMF key, that is, the key of Old AMF.

2. The key generated by _{horizontal K AMF} deduction on the current AMF key.

Optionally, before Old AMF determines ABBA_New, Old AMF determines whether the security features of Target AMF are the same as those supported by Old AMF; if they are different, Old AMF determines ABBA_New according to UE security features and Target AMF security features, and generates a new one. The AMF key.

Old AMF sends the parameters ABBA_New and optional Indicator1 required to derive the new AMF key to the UE. Alternatively, Old AMF can also send ABBA_New and optional Indicator2 to Target AMF. Then it is sent to the UE by Target AMF. The Target AMF sends the received ABBA_New to the UE. If the Target AMF receives Indicator2, the Target AMF sends Indicator1 to the UE.

In this application, the Indicator1 is used to instruct the UE to derive the AMF key, or to instruct the UE to use ABBA_New to generate the AMF key. The meaning of Indicator2 indication is the same as Indicator1. Indicator2 and Indicator1 can be the same indicator or different indicators.

When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key.

As shown in FIG. 21, a specific process of the sixth embodiment is provided. For example, the procedure may be a mobile registration procedure of the UE in the 5GS idle state. This procedure is also applicable to the registration procedure after the UE switches from EPS to 5GS, and the registration procedure when UE moves from EPS idle state to 5GS. This process includes but is not limited to:

Step 2103: The UE sends a registration request RR message to the Target AMF, where the registration request RR message may optionally carry 5G-GUTI.

Step 2104: If there is a 5G-GUTI in the RR, the Target AMF sends a UE context request to the Old AMF, and the UE context request carries the security features supported by the Target AMF. For example, the UE context request may be Namf_Communication_UEContextTransfer Request.

Step 2105: The Old AMF determines ABBA_New according to the security features of the UE and the security features of the Target AMF. The Old AMF can obtain the security features of the Target AMF by: receiving the security features of the Target AMF sent by the Target AMF, or obtaining it from local storage or configuration. Old AMF generates a new AMF key. The key used to generate the new AMF key includes the set ABBA_New. The parameters used to derive the new AMF key can also use the current AMF key of Old AMF, or the key generated by _{horizontal K AMF derivation based on the current AMF key.}

Optionally, before Old AMF generates ABBA_New, Old AMF compares the security features supported by Target AMF with the security features supported by Old AMF. If the two are different, Old AMF determines ABBA_New according to the security features supported by the UE and Target AMF. Target AMF generates a new AMF key.

Step 2106: The Old AMF sends a response message for the UE context request to the Target AMF. For example, the UE context request message may be Namf_Communication_UEContextTransfer Response message. The message includes ABBA_New, and optional indication Indicator2.

Step 2107: The Target AMF sends the received ABBA_New and optional Indicator1 to the UE. For example, Target AMF sends NAS SMC to UE. The NAS SMC includes ABBA_New and optional Indicator1. If the Target AMF receives Indicator2, the Target AMF sends Indicator1 to the UE.

Step 2108: When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side. The UE generates a NAS encryption key and an integrity key according to the generated new AMF key.

Fig. 22 shows another process of the sixth embodiment. For example, the procedure may be the procedure of the N2 handover procedure of the UE. This process includes but is not limited to:

In step 2201, the UE registers with Old AMF.

Step 2202: Old AMF initiates handover.

Step 2203: The Old AMF sends a UE context request message to the Target AMF. For example, the UE context request message may be Namf_Communication_CreateUEContextRequest.

Step 2204: The Target AMF sends a UE context request response to the Old AMF. For example, the UE context request response may be Namf_Communication_CreateUEContext Response. The UE context request response includes the security features supported by Target AMF.

Step 2205 is the same as step 2105.

Step 2206: The Old AMF sends the generated ABBA_New and optional Indicator1 to the UE. For example, Old AMF sends a NAS SMC message to the UE, and the NAS SMC includes the set ABBA_New and optional Indicator1.

Step 2207 is the same as step 2108.

In the sixth embodiment above, the security feature negotiation between the Target AMF and the UE is implemented, and ABBA_New is used as an input parameter to derive the new AMF key.

Example Seven

As shown in Figure 23, in the seventh embodiment, AMF and SEAF are not co-located, and are two independent network functions. In this embodiment, the AMF requests the key from SEAF. SEAF generates ABBA_New based on the security features of the UE and the target AMF. SEAF generates the AMF key and uses ABBA_New. SEAF generates AMF keys, you can also use K _SEAF or K _AMF .

SEAF sends the generated AMF key and optional Indicator3 to Target AMF. The Target AMF sends ABBA_New and optional Indicator1 to the UE. If the Target AMF receives Indicator3, the Target AMF sends Indicator1 to the UE.

In this application, Indicator3 has the same meaning as Indicator1. Indicator3 and Indicator1 can be the same indicator or different indicators.

Among them, the UE security features and Target AMF security features used by SEAF to generate ABBA_New can be obtained in the following ways.

1. SEAF obtains UE security features from local storage or configuration, or Target AMF sends UE security features to SEAF.

2. SEAF obtains Target AMF security features from local storage or configuration, or Target AMF sends Target AMF security features to SEAF.

SEAF can also directly obtain ABBA_New from Target AMF without generating ABBA_New, that is, Target AMF sends ABBA_New to SEAF.

Fig. 24 shows a specific process provided in the seventh embodiment. The process may specifically be the idle state mobile registration process of the UE in 5G, the registration process of the UE moving from the EPS idle state to the 5GS, or the registration process of the UE switching from the EPS to the 5GS, etc. This process includes but is not limited to:

Step 2403: The UE sends an RR message to the Target AMF. The RR message carries optional 5G-GUTI, optional ABBA_Old, and optional UE security features.

Step 2404: If there is a 5G-GUTI in the RR, the Target AMF sends a UE context request message to the Old AMF. For example, the UE context request message may be Namf_Communication_UEContextTransfer Request.

Step 2405: The Old AMF sends a UE context response message to the Target AMF. For example, the UE context response message may be Namf_Communication_UEContextTransfer Response. The message may optionally include security features supported by the UE, and/or security features supported by Old AMF, and/or ABBA_Old.

Therefore, the Target AMF obtains the UE security feature or the Old AMF security feature through: the UE sends it to the TargetAMF, or stores or configures it locally, or sends it to the Old AMF. Target AMF obtains ABBA_Old, which can be sent by UE or Old AMF.

Step 2406: The Target AMF sends a key request message to the SEAF, which is used to request the SEAF to generate an AMF key. The key request message carries the identity of the UE, for example, the UE's subscription permanent identifier (SUPI) or 5G-GUTI. The key request message may also include any one or more of the following: acquired security features supported by the UE, security features supported by Old AMF, security features supported by Target AMF, ABBA_Old.

Optionally, the Target AMF may determine whether the acquired security features supported by the Old AMF are the same as the security features supported by the Target AMF; if they are different, the above Target AMF sends a key request message to the SEAF. Alternatively, the Target AMF determines ABBA_New according to the security features supported by the UE and the Target AMF. Target AMF sends a key request message to SEAF, which carries ABBA_New.

Step 2407, SEAF generates an AMF key. The parameters used by SEAF to generate the AMF key include the SEAF key or the AMF key, and ABBA_New.

Among them, the ABBA_New used by SEAF to generate the AMF key can be obtained in any of the following ways:

1. Target AMF sends ABBA_New to SEAF.

2. The SEAF obtains the security features supported by the UE and Target AMF, and the SEAF generates ABBA_New.

3. SEAF obtains the security features supported by Old AMF and Target AMF. If the security features supported by Old AMF and Target AMF are different, SEAF generates ABBA_New.

Further, the SEAF obtains the security features supported by the UE or Target AMF or Old AMF through any of the following methods:

1. SEAF is obtained from local storage or configuration.

2. The Target AMF sends the security features supported by the UE or Target AMF or Old AMF to the SEAF.

Optionally, before generating the AMF key or ABBA_New, the SEAF may also make a judgment first: if the security features supported by the Old AMF are different from those supported by the Target AMF, the SEAF generates the AMF key or ABBA_New.

Step 2408, SEAF sends the AMF key, optional ABBA_New, and optional Indicator3 to Target AMF.

Step 2409: The Target AMF sends ABBA_New and optional Indicator1 to the UE. For example, Target AMF sends NAS SMC to UE, and NAS SMC includes ABBA_New and optional Indicator1.

Target AMF sends Indicator1, which can be based on any one or more of the following: Target AMF receives Indicator3 sent by SEAF; Target AMF receives the AMF key sent by SEAF; Target AMF receives ABBA_New sent by SEAF.

Step 2410: When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key derived.

FIG. 25 shows another process of the seventh embodiment. This process is the N2 handover process of the UE. The process includes but is not limited to:

In step 2501, the UE registers with Old AMF.

Step 2502: Old AMF initiates handover.

Step 2503: The Old AMF sends a UE context creation request message to the Target AMF. For example, the UE context request message may be Namf_Communication_CreateUEContext Request message. The message may optionally include any one or more of the following: security features supported by the UE; security features supported by Old AMF, ABBA_Old.

Possibly: Target AMF may also obtain the security features supported by the UE and/or the security features supported by Old AMF, and/or ABBA_Old from the UE or local storage.

For the specific description of the foregoing steps 2504 to 2506, please refer to the foregoing steps 2406 to 2408 in FIG. 24, and no additional description is required.

Step 2507: The Target AMF sends a UE context response message to the Old AMF. For example, the UE context response message may be Namf_Communication_CreatUEContext Response. The message carries ABBA_new and optional Indicator4.

In this application, Indicator4 has the same meaning as Indicator3. Indicator4 and Indicator3 can be the same indicator or different indicators.

Step 2508: The Old AMF sends ABBA_new and optional Indicator1 to the UE. If Old AMF receives Indicator4, Old AMF sends Indicator1 to the UE.

In this application, the aforementioned Indicator4 and Indicator1 may be the same indication or different indications, which is not limited.

Step 2509: When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key derived.

As another process of the seventh embodiment, the process includes but is not limited to:

The UE is registered with Old AMF.

Old AMF initiates handover.

Old AMF sends a UE context creation request message to Target AMF. For example, the UE context request message may be Namf_Communication_CreateUEContext Request message.

The Target AMF sends the morning and afternoon response messages of creating the UE to the Old AMF. For example, the UE context request message may be Namf_Communication_CreateUEContext Response message. The Response message includes the security features of Target AMF.

The Old AMF sends a key request message to the SEAF to request the SEAF to generate an AMF key. The key request message carries the identity of the UE, for example, the UE's subscription permanent identifier (SUPI) or 5G-GUTI. The key request message may also include any one or more of the following: security features supported by the UE, security features supported by Old AMF, security features supported by Target AMF, ABBA_Old.

Optionally, the Old AMF may determine whether the acquired security features supported by the Target AMF are the same as those supported by the Old AMF; if they are different, the Old AMF sends a key request message to the SEAF. Or, Old AMF determines ABBA_New according to the security features supported by the UE and Target AMF. Old AMF sends a key request message to SEAF, which carries ABBA_New.

SEAF generates an AMF key. The parameters used by SEAF to generate the AMF key include the SEAF key or the AMF key, and ABBA_New.

1. Old AMF sends ABBA_New to SEAF.

1. SEAF is obtained from local storage or configuration.

2. The Old AMF sends the security features supported by the UE or Target AMF or Old AMF to the SEAF.

SEAF sends the AMF key, optional ABBA_New, and optional Indicator5 to Old AMF.

Old AMF sends ABBA_new and optional Indicator1 to the UE. If Old AMF receives Indicator5, Old AMF sends Indicator1 to the UE.

In this application, the aforementioned Indicator5 and Indicator1 may be the same indication or different indications, which is not limited.

When the UE receives ABBA_New, it can generate a new AMF key according to ABBA_New. If the UE receives the first indication information, it can generate a new AMF key under the indication of the first indication information. The UE generates a new AMF key in the same way as the network side. Then the UE generates a NAS encryption key and an integrity key according to the new AMF key derived.

In this application, the indicators Indicator1, Indicator2, Indicator3, Indicator4, and Indicator5 all indicate the same content. They are not described one by one in this application.

In the seventh embodiment above, the security feature negotiation between the Target AMF and the UE is implemented, and ABBA has been used as the key derivation parameter. When the AMF changes, from Old AMF to Target AMF, how the Target AMF and the UE negotiate the supported security features and generate ABBA, and generate a new key based on the ABBA.

Through the foregoing embodiment 1 to embodiment 7, the possible dimensionality reduction attacks in the process of UE idle state mobile registration, N2 handover, UE idle state moving from EPS to 5GS, and UE switching from EPS to 5GS in 5G are solved.

The method provided by the embodiment of the present application is described in detail above with reference to FIG. 1 to FIG. 25. The device provided by the embodiment of the present application will be described in detail below with reference to FIG. 26 and FIG. 27. It should be understood that the description of the device embodiment and the description of the method embodiment correspond to each other. Therefore, for the content that is not described in detail, please refer to the description in the method embodiment above.

FIG. 26 is a schematic block diagram of an apparatus 2600 provided by an embodiment of the present application. For example, the device may be a software unit or a chip system. The chip system may be composed of chips, or may include chips and other discrete devices. The device includes a communication unit 2601 and may also include a processing unit 2602. The communication unit 2601 may communicate with the department, and the communication unit 2601 may include a sending unit and/or a receiving unit, and so on. The processing unit 2602 is used for processing.

In an example, the device 2600 can implement the steps performed by the first AMF in the above method embodiment, and the device 2600 can be the first AMF, or a chip or circuit configured in the first AMF. The processing unit 2602 is configured to perform processing operations on the first AMF side in the foregoing method embodiment, and the communication unit 2601 is configured to perform transceiving related operations on the first AMF side in the foregoing method embodiment.

For example, the processing unit 2602 is used to determine the security features of the terminal device; the processing unit 2602 is also used to determine the first inter-architecture anti-dimensionality reduction ABBA parameters based on the security features of the terminal device and the security features of the first AMF; The unit 2602 is further configured to obtain the key of the second AMF; the processing unit 2602 is further configured to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.

Optionally, the processing unit 2602 determines the security features of the terminal device, including: controlling the communication unit 2601 to send a request message for requesting the terminal device context to the second AMF; controlling the communication unit 2601 to receive the terminal device context sent by the second AMF, so The terminal device context carries the security features of the terminal device.

Optionally, the processing unit 2602 determining the security feature of the terminal device includes: controlling the communication unit 2601 to receive a registration request sent by the terminal device, and the registration request carries the security feature of the terminal device.

Optionally, the processing unit 2602 acquiring the key of the second AMF includes: controlling the communication unit 2601 to send a request message for requesting the terminal device context to the second AMF, and controlling the communication unit 2601 to receive the terminal device context sent by the second AMF, The terminal device context carries the key of the second AMF.

Optionally, before the processing unit 2602 determines the first ABBA parameter according to the security characteristics of the terminal device and the security characteristics of the first AMF, the processing unit 2602 is further configured to: determine the security characteristics of the second AMF; determine the first AMF The security feature of is different from the security feature of the second AMF.

Optionally, after the processing unit 2602 determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, the communication unit 2601 is further configured to: send the first ABBA parameter to the terminal device and First indication information, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter.

In another example, the apparatus 2600 may implement the steps performed by the terminal device in the above method embodiment, and the apparatus 2600 may be a terminal device, or a chip or circuit configured in the terminal device. The communication unit 2601 performs the transceiving operations of the terminal device in the above method embodiment, and the processing unit 2602 is configured to perform the processing related operations of the terminal device in the above method embodiment.

For example, the communication unit 2601 is configured to receive the first ABBA parameter and first indication information sent by the first AMF, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter; processing The unit 2602 is configured to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.

Optionally, the first ABBA parameter includes the security feature of the terminal device and the security feature of the first AMF.

Optionally, the communication unit 2601 is further configured to send a registration request to the first AMF, where the registration request carries the security feature of the terminal device.

The division of units in the embodiments of this application is illustrative, and is only a logical function division. In actual implementation, there may be other division methods. In addition, the functional units in each embodiment of this application can be integrated into one processing unit. In the device, it can also exist alone physically, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.

It can be understood that the functions of the communication unit in the foregoing embodiments may be implemented by a transceiver, and the functions of the processing unit may be implemented by a processor. The transceiver may include a transmitter and/or a receiver, etc., which are used to implement the functions of the transmitting unit and/or the receiving unit, respectively. The following description will be given with reference to FIG. 27 as an example.

FIG. 2700 is a schematic block diagram of a device 2700 provided in an embodiment of the present application. The device 2700 shown in FIG. 2700 may be a hardware circuit implementation of the device shown in FIG. 2600. For ease of description, FIG. 27 only shows the main components of the communication device.

The communication device 2700 shown in FIG. 2700 includes at least one processor 2701. The communication device 2700 may also include at least one memory 2702 for storing program instructions and/or data. The memory 2702 and the processor 2701 are coupled. The coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, and is used for information exchange between devices, units, or modules. The processor 2701 may cooperate with the memory 2702, the processor 2701 may execute program instructions stored in the memory 2702, and at least one of the at least one memory 2702 may be included in the processor 2701.

The apparatus 2700 may further include a communication interface 2703 for communicating with other devices through a transmission medium, so that the communication apparatus 2700 can communicate with other devices. In the embodiment of the present application, the communication interface may be a transceiver, a circuit, a bus, a module, or other types of communication interfaces. In the embodiment of the present application, when the communication interface is a transceiver, the transceiver may include an independent receiver and an independent transmitter; it may also be a transceiver with integrated transceiver functions, or an interface circuit.

It should be understood that the connection medium between the processor 2701, the memory 2702, and the communication interface 2703 is not limited in the embodiment of the present application. In the embodiment of the present application in FIG. 27, the memory 2702, the processor 2701, and the communication interface 2703 are connected by a communication bus 2704. The bus is represented by a thick line in FIG. 27. The connection mode between other components is only a schematic illustration. , Not as a limitation. The bus may include an address bus, a data bus, a control bus, and so on. For ease of representation, only one thick line is used to represent in FIG. 27, but it does not mean that there is only one bus or one type of bus.

In an example, the device 2700 is used to implement the steps performed by the first AMF in the above method embodiment. The communication interface 2703 is used to perform the transceiving-related operations of the first AMF in the above method embodiment, and the processor 2701 is used to perform the processing related operations of the first AMF in the above method embodiment.

For example, the processor 2701 is configured to determine the security feature of the terminal device; the processor 2701 is also configured to determine the first inter-architecture anti-dimensionality reduction ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF; The processor 2701 is further configured to obtain the key of the second AMF; the processor 2701 is further configured to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.

Optionally, the processor 2701 determining the security feature of the terminal device includes: controlling the communication interface 2703 to send a request message for requesting the terminal device context to the second AMF, and controlling the communication interface 2703 to receive the terminal device context sent by the second AMF, The terminal device context carries the security features of the terminal device.

Optionally, the processor 2701 determining the security feature of the terminal device includes: controlling the communication interface 2703 to receive a registration request sent by the terminal device, and the registration request carries the security feature of the terminal device.

Optionally, the processor 2701 obtaining the key of the second AMF includes: controlling the communication interface 2703 to send a request message for requesting the context of the terminal device to the second AMF; controlling the communication interface 2703 to receive the key sent by the second AMF The terminal device context, the terminal device context carries the key of the second AMF.

Optionally, before the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, the processor 2701 is further configured to: determine the security feature of the second AMF; It is determined that the security feature of the first AMF is different from the security feature of the second AMF.

Optionally, after the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, the communication interface 2703 is further configured to: send the terminal device The first ABBA parameter and first indication information, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter.

In an example, the apparatus 2700 is used to implement the steps of the terminal device in the above method embodiment. The communication interface 2703 is used to perform the transceiving-related operations of the terminal device in the above embodiment, and the processor 2701 is used to perform the processing related operations of the terminal device in the above method embodiment.

For example, the communication interface 2703 is configured to receive the first ABBA parameter and first indication information sent by the first AMF, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter; processing The device 2701 is configured to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.

Optionally, the communication interface 2703 is further configured to send a registration request to the first AMF, where the registration request carries the security feature of the terminal device.

Further, an embodiment of the present application also provides a system, which includes at least one of the first AMF, the second AMF, or the UE in the above method embodiment. A device for executing the method in the above method embodiment. A computer-readable storage medium includes a program, and when the program is executed by a processor, the method in the above method embodiment is executed. A computer program product, the computer program product includes computer program code, when the computer program code runs on a computer, the computer realizes the method in the above method embodiment. A chip includes: a processor, the processor is coupled with a memory, the memory is used to store a program or an instruction, when the program or an instruction is executed by the processor, the device executes the above method embodiment Methods.

In the embodiments of the present application, the processor may be a general-purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, which can implement or execute The methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

In the embodiment of the present application, the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or a volatile memory (volatile memory), for example Random-access memory (random-access memory, RAM). The memory is any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and that can be accessed by a computer, but is not limited to this. The memory in the embodiments of the present application may also be a circuit or any other device capable of realizing a storage function for storing program instructions and/or data.

The methods provided in the embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center. Transmission to another website, computer, server, or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center integrated with one or more available media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a digital video disc (digital video disc, DVD for short)), or a semiconductor medium (for example, SSD).

Obviously, those skilled in the art can make various changes and modifications to the application without departing from the scope of the application. In this way, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalent technologies, this application also intends to include these modifications and variations.

Claims

A communication method, characterized in that it comprises:

The first access and mobility management function AMF determines the security features of the terminal equipment;

The first AMF determines the first inter-architecture anti-dimensionality reduction ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF;

Obtaining the key of the second AMF by the first AMF;

The first AMF determines the key of the first AMF according to the first ABBA parameter and the key of the second AMF.
The method according to claim 1, wherein the first AMF determining the security feature of the terminal device comprises:

Sending, by the first AMF, a request message for requesting the context of the terminal device to the second AMF;

The first AMF receives the terminal device context sent by the second AMF, and the terminal device context carries the security feature of the terminal device.
The method according to claim 1, wherein the first AMF determining the security feature of the terminal device comprises:

The first AMF receives a registration request sent by a terminal device, and the registration request carries the security feature of the terminal device.
The method according to any one of claims 1 to 3, wherein the first AMF acquiring the key of the second AMF comprises:

Sending, by the first AMF, a request message for requesting the context of the terminal device to the second AMF;

The first AMF receives the terminal device context sent by the second AMF, and the terminal device context carries the key of the second AMF.
The method according to any one of claims 1 to 4, characterized in that, before the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, The method also includes:

The first AMF determines the security feature of the second AMF;

The first AMF determines that the security feature of the first AMF is different from the security feature of the second AMF.
The method according to any one of claims 1 to 5, wherein after the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF, The method also includes:

The first AMF sends the first ABBA parameter and first indication information to the terminal device, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter.
A communication method, characterized in that it comprises:

The terminal device receives the first inter-architecture anti-dimensionality reduction ABBA parameter and first indication information sent by the first access and mobility management function AMF, where the first indication information is used to instruct the terminal device to update according to the first ABBA parameter AMF key;

The terminal device determines the key of the first AMF according to the first ABBA parameter and the key of the second AMF.
The method according to claim 7, wherein the first ABBA parameter includes the security feature of the terminal device and the security feature of the first AMF.
The method according to claim 7 or 8, further comprising:

The terminal device sends a registration request to the first AMF, and the registration request carries the security feature of the terminal device.
A communication method, characterized in that it comprises:

The second access and mobility management function AMF sends the security feature of the terminal device and the key of the second AMF to the first AMF;

The first AMF determines the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF;

The first AMF determines the key of the first AMF according to the first ABBA parameter and the key of the second AMF.
The method according to claim 10, wherein the sending, by the second AMF, the security feature of the terminal device and the key of the second AMF to the first AMF comprises:

Sending, by the first AMF, a request message for requesting the context of the terminal device to the second AMF;

The second AMF sends a terminal device context to the first AMF, and the terminal device context carries the security feature of the terminal device and the key of the second AMF.
The method according to claim 10 or 11, characterized in that, before the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the key of the first AMF, the method further include:

Determining the security feature of the second AMF by the first AMF;

The first AMF determines that the security characteristics of the first AMF and the second AMF are different.
A communication device, characterized in that it comprises:

The processing unit is used to determine the security features of the terminal equipment;

The processing unit is further configured to determine the first inter-architecture anti-dimensionality reduction ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF;

The processing unit is also used to obtain the key of the second AMF;

The processing unit is further configured to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.
The apparatus according to claim 13, wherein the processing unit determining the security feature of the terminal device comprises:

Control the communication unit to send a request message for requesting the context of the terminal device to the second AMF;

The control communication unit receives the terminal device context sent by the second AMF, and the terminal device context carries the security feature of the terminal device.
The apparatus according to claim 13, wherein the processing unit determining the security feature of the terminal device comprises:

The control communication unit receives a registration request sent by a terminal device, and the registration request carries the security feature of the terminal device.
15. The device according to any one of claims 13 to 15, wherein the processing unit acquiring the key of the second AMF comprises:

Control the communication unit to send a request message for requesting the context of the terminal device to the second AMF;

The communication unit is controlled to receive the terminal device context sent by the second AMF, and the terminal device context carries the key of the second AMF.
The device according to any one of claims 13 to 16, wherein the processing unit is further configured to:

Determine the security features of the second AMF;

It is determined that the security feature of the first AMF is different from the security feature of the second AMF.
The device according to any one of claims 13 to 17, wherein the communication interface is further used for:

Send the first ABBA parameter and first indication information to the terminal device, where the first indication information is used to instruct the terminal device to update the AMF key according to the first ABBA parameter.
A communication device, characterized in that it comprises:

The communication unit is configured to receive the first inter-architecture anti-dimensionality reduction ABBA parameter and first indication information sent by the first access and mobility management function AMF, where the first indication information is used to instruct the terminal device according to the first ABBA parameters update AMF key;

The processing unit is configured to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.
The apparatus according to claim 19, wherein the first ABBA parameter includes a security feature of the terminal device and a security feature of the first AMF.
The device according to claim 19 or 20, wherein the communication unit is further configured to:

Send a registration request to the first AMF, where the registration request carries the security feature of the terminal device.
A communication system, characterized in that it comprises:

The second access and mobility management function AMF is used to send the security feature of the terminal device and the key of the second AMF to the first AMF;

The first AMF is configured to determine the first ABBA parameter according to the security feature of the terminal device and the security feature of the first AMF;

The first AMF is also used to determine the key of the first AMF according to the first ABBA parameter and the key of the second AMF.
The system according to claim 22, wherein the sending of the security feature of the terminal device and the key of the second AMF by the second AMF to the first AMF comprises:

Receiving a request message sent by the first AMF for requesting the context of a terminal device;

Send a terminal device context to the first AMF, where the terminal device context carries the security feature of the terminal device and the key of the second AMF.
The system according to claim 22 or 23, wherein before the first AMF determines the first ABBA parameter according to the security feature of the terminal device and the key of the first AMF, the first AMF is also used to:

Determine the security feature of the second AMF;

It is determined that the security characteristics of the first AMF and the second AMF are different.
A communication device, characterized in that it comprises a processor and a memory, and instructions are stored in the memory. When the processor executes the instructions, the communication device is caused to execute the communication device described in any one of claims 1 to 6. The method, or the communication device is caused to execute the method according to any one of claims 7 to 9, or the communication device is caused to execute the method according to any one of claims 10 to 12.
A computer-readable storage medium, characterized in that instructions are stored in the computer-readable storage medium, which when run on a computer, cause the computer to execute the method according to any one of claims 1 to 6, or, The computer is caused to execute the method according to any one of claims 7 to 9, or the computer is caused to execute the method according to any one of claims 10 to 12.