U.S. patent application number 17/245991 was filed with the patent office on 2022-09-15 for anchor key generation method, device, and system.
The applicant listed for this patent is Huawei Technologies Co., Ltd.. Invention is credited to Lu Gan, Rong Wu, Bo Zhang.
Application Number | 20220295271 17/245991 |
Document ID | / |
Family ID | 1000006560465 |
Filed Date | 2022-09-15 |
United States Patent
Application |
20220295271 |
Kind Code |
A9 |
Wu; Rong ; et al. |
September 15, 2022 |
Anchor Key Generation Method, Device, and System
Abstract
An anchor key generation method, device, and system, where the
method includes generating, by a unified data management network
element (UDM), an intermediate key based on a cipher key (CK), an
integrity key (IK), and indication information regarding an
operator; sending, by the UDM, the intermediate key to an
authentication server function (AUSF); receiving, by the AUSF, the
intermediate key; generating, by the AUSF, an anchor key based on
the intermediate key; sending, by the AUSF, the anchor key to a
security anchor function (SEAF); and generating, by the SEAF, a key
(Kamf) based on the anchor key, where the Kamf is used to derive a
3.sup.rd Generation Partnership Project (3GPP) key.
Inventors: |
Wu; Rong; (Shenzhen, CN)
; Zhang; Bo; (Shenzhen, CN) ; Gan; Lu;
(Shenzhen, CN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Huawei Technologies Co., Ltd. |
Shenzhen |
|
CN |
|
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20210258780 A1 |
August 19, 2021 |
|
|
Family ID: |
1000006560465 |
Appl. No.: |
17/245991 |
Filed: |
April 30, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16388606 |
Apr 18, 2019 |
11012855 |
|
|
17245991 |
|
|
|
|
PCT/CN2018/084416 |
Apr 25, 2018 |
|
|
|
16388606 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W 76/25 20180201;
H04W 8/08 20130101; H04W 76/11 20180201; H04L 9/08 20130101; H04W
80/10 20130101; H04W 12/041 20210101; H04L 63/0869 20130101; H04W
12/04 20130101; H04W 12/043 20210101; H04W 88/023 20130101 |
International
Class: |
H04W 12/041 20060101
H04W012/041; H04W 80/10 20060101 H04W080/10; H04W 88/02 20060101
H04W088/02; H04W 76/11 20060101 H04W076/11; H04W 76/25 20060101
H04W076/25; H04W 8/08 20060101 H04W008/08; H04L 9/08 20060101
H04L009/08; H04L 29/06 20060101 H04L029/06; H04W 12/04 20060101
H04W012/04; H04W 12/043 20060101 H04W012/043 |
Foreign Application Data
Date |
Code |
Application Number |
May 5, 2017 |
CN |
201710313519.9 |
Sep 29, 2017 |
CN |
201710908017.0 |
Claims
1. A method implemented in a communication system, comprising:
generating, by a user equipment, an intermediate key based on a
cipher key (CK), an integrity key (IK), and an operator type
identifier comprising a service network (SN) identifier;
generating, by the user equipment, an anchor key based on the
intermediate key, wherein the anchor key is to implement
compatibility with various access modes; generating, by the user
equipment, a key (Kamf) based on the anchor key; deriving, by the
user equipment, a base station key based on the Kamf; and deriving,
by the user equipment based on the base station key, a user plane
cipher key, a user plane integrity key, a control plane cipher key,
and a control plane integrity key.
2. The method according to claim 1, wherein generating, by the user
equipment, the anchor key based on the intermediate key comprises:
generating, by the user equipment, an extended master session key
(EMSK') based on the intermediate key; generating, by the user
equipment, a key (K.sub.left) by truncating a bit of the EMSK'; and
obtaining, by the user equipment, the anchor key based on the
K.sub.left and the SN identifier.
3. The method according to claim 1, further comprising deriving, by
the user equipment, a non-access stratum (NAS) key based on the
Kamf.
4. The method according to claim 1, wherein the SN identifier is an
SN name.
5. The method according to claim 1, wherein the intermediate key is
generated according to a formula comprising: intermediate
key=KDF(SQN.sym.AK,NAI,CK.parallel.IK), wherein KDF is a key
derivation function, wherein SQN is a latest sequence number,
wherein NAI is a network access identifier, which comprises the SN
identifier, wherein AK is an anonymity key, and wherein .sym.
represents an exclusive OR operation.
6. The method according to claim 1, wherein the operator type
identifier further comprises an access type identifier.
7. The method according to claim 6, wherein the access type
identifier indicates a generation of communication system.
8. A user equipment, comprising: a processor; and a memory coupled
to the processor and configured to store computer program
instructions, which when executed by the processor, cause the user
equipment to: generate an intermediate key based on a cipher key
(CK), an integrity key (IK), and an operator type identifier
comprising a service network (SN) identifier; generate an anchor
key based on the intermediate key, wherein the anchor key is to
implement compatibility with various access modes; generate a key
based on the anchor key; derive a base station key based on the
key; and derive, based on the base station key, a user plane cipher
key, a user plane integrity key, a control plane cipher key, and a
control plane integrity key.
9. The user equipment according to claim 8, wherein the computer
program instructions, when executed by the processor, further cause
the user equipment to: generate an extended master session key
(EMSK') based on the intermediate key; generate a key (K.sub.left)
by truncating a bit of the EMSK'; and obtain the anchor key based
on the K.sub.left and a service network identifier.
10. The user equipment according to claim 8, wherein the computer
program instructions, when executed by the processor, further cause
the user equipment to derive a non-access stratum (NAS) key based
on the Kamf.
11. The user equipment according to claim 8, wherein the SN
identifier is an SN name.
12. The user equipment according to claim 8, wherein the
intermediate key is generated according to a formula comprising:
intermediate key=KDF(SQN.sym.AK,NAI,CK.parallel.IK), wherein KDF is
a key derivation function, wherein SQN is a latest sequence number,
wherein NAI is a network access identifier which comprises the SN
identifier, wherein AK is an anonymity key, and wherein .sym.
represents an exclusive OR operation.
13. The user equipment according to claim 8, wherein the operator
type identifier further comprises an access type identifier.
14. The user equipment according to claim 13, wherein the access
type identifier indicates a generation of communication system.
15. A non-transitory computer readable storage medium configured to
store instructions, which when executed by a processor of a user
equipment, cause the user equipment to implement a method
comprising: generating an intermediate key based on a cipher key
(CK), an integrity key (IK), and an operator type identifier
comprising a service network (SN) identifier; generating an anchor
key based on the intermediate key, wherein the anchor key is to
implement compatibility with various access modes; generating a key
(Kamf) based on the anchor key; deriving a base station key based
on the Kamf; and deriving, based on the base station key, a user
plane cipher key, a user plane integrity key, a control plane
cipher key, and a control plane integrity key.
16. The non-transitory computer readable storage medium according
to claim 15, wherein generating the anchor key based on the
intermediate key comprises: generating an extended master session
key (EMSK') based on the intermediate key; generating a key
(K.sub.left) by truncating a bit of the EMSK'; and obtaining the
anchor key based on the K.sub.left and the SN identifier.
17. The non-transitory computer readable storage medium according
to claim 15, wherein the method further comprises deriving a
non-access stratum (NAS) key based on the Kamf.
18. The non-transitory computer readable storage medium according
to claim 15, wherein the SN identifier is an SN name.
19. The non-transitory computer readable storage medium according
to claim 15, wherein the operator type identifier further comprises
an access type identifier.
20. The non-transitory computer readable storage medium according
to claim 19, wherein the access type identifier indicates a
generation of communication system.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 16/388,606, filed on Apr. 18, 2019, which is a
continuation of International Patent Application No.
PCT/CN2018/084416, filed on Apr. 25, 2018, which claims priority to
Chinese Patent Application No. 201710908017.0, filed on Sep. 29,
2017, which claims priority to Chinese Patent Application No.
201710313519.9, filed on May 5, 2017. All of the aforementioned
patent applications are hereby incorporated by reference in their
entireties.
TECHNICAL FIELD
[0002] The present disclosure relates to the communications field,
and in particular, to an anchor key generation method, device, and
system.
BACKGROUND
[0003] A key is critical to an encryption operation, a decryption
operation, and a cryptosystem. Therefore, in an information
security system, key negotiation is an important part in an
authentication process. FIG. 1 shows a key negotiation process in
an existing fourth generation (4G) system. Network elements
required for executing the process include a user equipment (UE),
an evolved NodeB (eNodeB), a mobility management entity (MME), a
home subscriber server (HSS), an authentication center (AuC), and
the like. The execution process is roughly as follows below.
[0004] Step 1: The AuC generates an integrity key (IK) and a cipher
key (CK) based on a root key K, and sends the IK and the CK to the
HSS. Correspondingly, the HSS receives the IK and the CK sent by
the AuC.
[0005] Step 2: The HSS generates an intermediate key (K.sub.ASME)
based on the IK and the CK, and sends the K.sub.ASME to the MME.
Correspondingly, the MME receives the K.sub.ASME sent by the
HSS.
[0006] Step 3: The MME generates, based on the K.sub.ASME, a
non-access stratum (NAS) integrity key (K.sub.NASenc) or performing
encryption protection on an NAS message, and a NAS integrity
protection key (K.sub.NASint) for performing integrity
protection.
[0007] Step 4: The MME generates a base station key (K.sub.eNB)
based on the K.sub.ASME, and sends the K.sub.eNB to the eNodeB.
Correspondingly, the eNodeB receives the K.sub.eNB sent by the
MME.
[0008] Step 5: The eNodeB separately generates, based on the
K.sub.eNB, a user plane cipher key (K.sub.UPenc) for performing
encryption protection on user plane data, a user plane integrity
key (K.sub.UPint) for performing integrity protection on the user
plane data, a control plane cipher key (K.sub.RRCenc) for
performing encryption protection on control plane data, and a
control plane integrity key (K.sub.RRCint) for performing integrity
protection on the control plane data.
[0009] Step 6: The UE generates by itself an integrity key (IK), a
cipher key (CK), an intermediate key (K.sub.ASME), a user plane
cipher key (K.sub.UPenc), a user plane integrity key (K.sub.UPint),
a control plane cipher key (K.sub.RRCenc), and a control plane
integrity key (K.sub.RRCint) based on the root key K.
[0010] After the key negotiation process shown in FIG. 1 is
completed, a key architecture shown in FIG. 2 is generated in the
4G system.
[0011] It may be understood that FIG. 1 shows a key negotiation
process in a process of accessing a core network by a terminal in a
3rd Generation Partnership Project (3GPP) access mode in a 4G
application scenario. To meet requirements of various application
scenarios, the terminal may access the core network in various
different access modes, for example, a 3GPP access mode, a trusted
non-3GPP access mode, and an untrusted 3GPP access mode. In
different access modes, key negotiation processes are also
different. In a fifth generation (5G) standard, it is specified
that one unified anchor key needs to be generated in key
negotiation processes of different access modes, in order to
implement compatibility with various access modes. However, how to
generate the unified anchor key is a problem that a person skilled
in the art needs to resolve.
SUMMARY
[0012] Embodiments of this application provide an anchor key
generation method, device, and system, to generate a unified anchor
key for different access modes, and implement separation between an
anchor key of different access modes and a lower-layer key
generated based on the anchor key.
[0013] A first aspect provides an anchor key generation method
including: receiving, by a first communications device, an
indication identifier sent by a second communications device, where
the indication identifier is used to indicate an access mode of a
terminal; sending, by the first communications device, the
indication identifier to a third communications device; receiving,
by the first communications device, an intermediate key returned by
the third communications device, where the intermediate key is
generated based on the indication identifier; generating, by the
first communications device, an anchor key based on the
intermediate key, where the anchor key is corresponding to the
access mode of the terminal; and sending, by the first
communications device, the anchor key to the second communications
device, such that the second communications device derives a
lower-layer key for the access mode based on the anchor key.
[0014] In some possible implementations, the access mode is
distinguished based on at least one of an access type or an
operator type.
[0015] In some possible implementations, the generating, by the
first communications device, an anchor key based on the
intermediate key includes generating, by the first communications
device, the anchor key based on the following formula: anchor
key=KDF(IK.sub.1'.parallel.CK.sub.1'), where anchor key is the
anchor key, (IK.sub.1', CK.sub.1') is the intermediate key,
IK.sub.1' is an intermediate integrity key, CK.sub.1' is an
intermediate cipher key, and .parallel. means concatenation,
indicating that characters on both sides of the symbol are
connected in series.
[0016] The first communications device may generate the
intermediate key in at least the following two manners described
below.
[0017] When the indication identifier includes an access type
identifier and an operator type identifier, the intermediate key is
generated based on the following formula: (CK.sub.1',
IK.sub.1')=KDF(SQN.sym.AK, ANT, SNT, CK.parallel.IK), where the
access type identifier is used to indicate the access type, the
operator type identifier is used to indicate the operator type,
(CK.sub.1', IK.sub.1') is the intermediate key, CK.sub.1' is the
intermediate cipher key, IK.sub.1' is the intermediate integrity
key, KDF is a key derivation function (which may also be referred
to as a key generation algorithm), SQN is a latest sequence number,
ANT is the access type identifier, SNT is the operator type
identifier, CK is an initial cipher key, IK is an initial integrity
key, AK is an anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND),
RAND is a random number, f3, f4, and f5 are generation algorithms,
and .sym. means an exclusive OR operation.
[0018] When the indication identifier is an NAI, the intermediate
key is generated based on the following formula: (CK.sub.1',
IK.sub.1')=KDF(SQN.sym.AK, NAI, CK.parallel.IK), where (CK.sub.1',
IK.sub.1') is the intermediate key, CK.sub.1' is the intermediate
cipher key, IV is the intermediate integrity key, KDF is a key
generation algorithm, SQN is a latest sequence number, NAI is the
indication identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0019] In some possible implementations, the first communications
device generates the intermediate key based on the following
formula: (CK.sub.2', IK.sub.2')=KDF(SQN.sym.AK, ANT,
CK.parallel.IK), where (CK.sub.2', IK.sub.2') is the intermediate
key, CK.sub.2' is the intermediate cipher key, IK.sub.2' is the
intermediate integrity key, KDF is a key generation algorithm, SQN
is a latest sequence number, ANT is the access type identifier, CK
is an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0020] The first communications device generates an EMSK' based on
the following formula EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'),
where EMSK' is an extended master session key, (IK.sub.2',
CK.sub.2') is the intermediate key, IK.sub.2' is the intermediate
integrity key, CK.sub.2' is the intermediate cipher key, and
.parallel. means concatenation, indicating that characters on both
sides of the symbol are connected in series.
[0021] The first communications device generates the anchor key
based on the following formula: anchor key=KDF(EMSK', SNT), where
anchor key is the anchor key, and SNT is the operator type
identifier.
[0022] In some possible implementations, the first communications
device generates the intermediate key based on the following
formula (CK.sub.2', IK.sub.2')=KDF(SQN.sym.AK, SNT, where
(CK.sub.2', IK.sub.2') is the intermediate key, CK.sub.2' is the
intermediate cipher key, IK.sub.2' is the intermediate integrity
key, KDF is a key generation algorithm, SQN is a latest sequence
number, SNT is the operator type identifier, CK is an initial
cipher key, IK is an initial integrity key, AK is an anonymity key,
CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3,
f4, and f5 are generation algorithms, and .sym. means an exclusive
OR operation.
[0023] The first communications device generates an EMSK' based on
the following formula: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'),
where EMSK' is an extended master session key, (IK.sub.2',
CK.sub.2') is the intermediate key, IK.sub.2' is the intermediate
integrity key, CK.sub.2' is the intermediate cipher key, and
.parallel. means concatenation, indicating that characters on both
sides of the symbol are connected in series.
[0024] The first communications device generates the anchor key
based on the following formula: anchor key=KDF(EMSK', ANT), where
anchor key is the anchor key, and ANT is the access type
identifier.
[0025] A second aspect provides a communications device including a
receiving module, a sending module, and a generation module. The
receiving module is configured to receive an indication identifier
sent by a second communications device, where the indication
identifier is used to indicate an access mode of a terminal. The
sending module is configured to send the indication identifier to a
third communications device. The receiving module is configured to
receive an intermediate key returned by the third communications
device, where the intermediate key is generated based on the
indication identifier. The generation module is configured to
generate an anchor key based on the intermediate key, where the
anchor key is corresponding to the access mode of the terminal. The
sending module is further configured to send the anchor key to the
second communications device, such that the second communications
device derives a lower-layer key for the access mode based on the
anchor key.
[0026] In some possible implementations, the access mode is
distinguished based on at least one of an access type or an
operator type.
[0027] In some possible implementations, the generation module is
configured to generate the anchor key based on the following
formula: anchor key=KDF(IK.sub.1'.parallel.CK.sub.1'), where anchor
key is the anchor key, (IK.sub.1', CK.sub.1') is the intermediate
key, IK.sub.1' is an intermediate integrity key, CK.sub.1' is an
intermediate cipher key, and .parallel. means concatenation,
indicating that characters on both sides of the symbol are
connected in series.
[0028] The first communications device may generate the
intermediate key in at least the following two manners below.
[0029] When the indication identifier includes an access type
identifier and an operator type identifier, the generation module
is configured to generate the intermediate key based on the
following formula: (CK.sub.1', IK.sub.1')=KDF(SQN.sym.AK, ANT, SNT,
CK.parallel.IK), where the access type identifier is used to
indicate the access type, the operator type identifier is used to
indicate the operator type, (CK.sub.1', IK.sub.1') is the
intermediate key, CK.sub.1' is the intermediate cipher key,
IK.sub.1' is the intermediate integrity key, KDF is a key
generation algorithm, SQN is a latest sequence number, ANT is the
access type identifier, SNT is the operator type identifier, CK is
an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0030] When the indication identifier is an NAI, the generation
module is configured to generate the intermediate key based on the
following formula: (CK.sub.1', IK.sub.1')=KDF(SQN.sym.AK, NAI,
CK.parallel.IK), where (CK.sub.1', IK.sub.1') is the intermediate
key, CK.sub.1' is the intermediate cipher key, IK.sub.1' is the
intermediate integrity key, KDF is a key generation algorithm, SQN
is a latest sequence number, NAI is the indication identifier, CK
is an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0031] In some possible implementations, the generation module is
configured to generate the intermediate key based on the following
formula: (CK.sub.2', IK.sub.2')=KDF(SQN.sym.AK, ANT,
CK.parallel.IK), where (CK.sub.2', IK.sub.2') is the intermediate
key, CK.sub.2' is the intermediate cipher key, IK.sub.2' is the
intermediate integrity key, KDF is a key generation algorithm, SQN
is a latest sequence number, ANT is the access type identifier, CK
is an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0032] The generation module is configured to generate an EMSK'
based on the following formula:
EMSK'=PRF'(IV.sub.2'.parallel.CK.sub.2'), where EMSK' is an
extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0033] The generation module is configured to generate the anchor
key based on the following formula: anchor key=KDF(EMSK', SNT),
where anchor key is the anchor key, and SNT is the operator type
identifier.
[0034] In some possible implementations, the generation module is
configured to generate the intermediate key based on the following
formula: (CK.sub.2', IK.sub.2')=KDF(SQN.sym.AK, SNT,
CK.parallel.IK), where (CK.sub.2', IK.sub.2') is the intermediate
key, CK.sub.2' is the intermediate cipher key, IK.sub.2' is the
intermediate integrity key, KDF is a key generation algorithm, SQN
is a latest sequence number, SNT is the operator type identifier,
CK is an initial cipher key, IK is an initial integrity key, AK is
an anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0035] The generation module is configured to generate an EMSK'
based on the following formula:
EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is an
extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0036] The generation module is configured to generate the anchor
key based on the following formula: anchor key=KDF(EMSK', ANT),
where anchor key is the anchor key, and ANT is the access type
identifier.
[0037] A third aspect provides a communications device including a
memory, a processor coupled to the memory, and a communications
module. The communications module is configured to send or receive
data sent from the outside, the memory is configured to store
implementation code of the method described in the first aspect,
and the processor is configured to execute the program code stored
in the memory, namely, execute the method described in the first
aspect.
[0038] A fourth aspect provides a computer readable storage medium.
The computer readable storage medium stores an instruction. When
the instruction is run on a computer, the computer executes the
method described in the first aspect.
[0039] A fifth aspect provides a computer program product that
includes an instruction. When the instruction is run on a computer,
the computer executes the method described in the first aspect.
[0040] A sixth aspect provides a communications system including an
access and mobility control function network element, a session
management network element, an authentication server, and a unified
data management network element that are connected to each other.
The authentication server is the authentication server according to
the second aspect or the third aspect in the claims.
BRIEF DESCRIPTION OF DRAWINGS
[0041] To describe the technical solutions in the embodiments of
the present disclosure or in the background more clearly, the
following briefly describes the accompanying drawings required for
describing the embodiments of the present disclosure or the
background.
[0042] FIG. 1 is a schematic diagram of a key negotiation process
in a 3GPP access mode according to a 4G application scenario;
[0043] FIG. 2 is a key architectural diagram of the key negotiation
process shown in FIG. 1;
[0044] FIG. 3 is a network architectural diagram of accessing a 5G
core network in a 3GPP access mode related to an embodiment of this
application;
[0045] FIG. 4 is a network architectural diagram of accessing a 5G
core network in a non-3GPP access mode related to an embodiment of
this application;
[0046] FIG. 5 is an interaction diagram of a first anchor key
generation method according to an embodiment of this
application;
[0047] FIG. 6A and FIG. 6B are interaction diagrams of the anchor
key generation method shown in FIG. 5 in a 3GPP mode and in a
non-3GPP mode, respectively;
[0048] FIG. 7 is a key architectural diagram obtained using the
anchor key generation method shown in FIG. 5;
[0049] FIG. 8 is an interaction diagram of a second anchor key
generation method according to an embodiment of this
application;
[0050] FIG. 9 is an interaction diagram of a third anchor key
generation method according to an embodiment of this
application;
[0051] FIG. 10 is a key architectural diagram obtained using the
anchor key generation method shown in FIG. 9;
[0052] FIG. 11A and FIG. 11B are interaction diagrams of a fourth
anchor key generation method according to an embodiment of this
application;
[0053] FIG. 12 is a key architectural diagram obtained using the
anchor key generation method shown in FIG. 11A and FIG. 11B;
[0054] FIG. 13 is an interaction diagram of a fifth anchor key
generation method according to an embodiment of this
application;
[0055] FIG. 14A and FIG. 14B are interaction diagrams of the anchor
key generation method shown in FIG. 13 in a 3GPP mode and in a
non-3GPP mode, respectively;
[0056] FIG. 15 is a key architectural diagram obtained using the
anchor key generation method shown in FIG. 13;
[0057] FIG. 16 is an interaction diagram of a sixth anchor key
generation method according to an embodiment of this
application;
[0058] FIG. 17A and FIG. 17B are interaction diagrams of the anchor
key generation method shown in FIG. 16 in a 3GPP mode and in a
non-3GPP mode, respectively;
[0059] FIG. 18 is a key architectural diagram obtained using the
anchor key generation method shown in FIG. 16;
[0060] FIG. 19 is an interaction diagram of a seventh anchor key
generation method according to an embodiment of this
application;
[0061] FIG. 20 is a key architectural diagram obtained using the
anchor key generation method shown in FIG. 19;
[0062] FIG. 21 is a schematic structural diagram of a
communications device according to an embodiment of this
application; and
[0063] FIG. 22 is a schematic structural diagram of another
communications device according to an embodiment of this
application.
DESCRIPTION OF EMBODIMENTS
[0064] The following separately describes a plurality of
embodiments of this application with reference to the accompanying
drawings and disclosed embodiments.
[0065] FIG. 3 is a network architectural diagram related to an
embodiment of this application. The network architecture is mainly
applicable to a scenario in which a 5G core network is accessed in
a 3GPP mode. FIG. 4 is another network architectural diagram
related to an embodiment of this application. The network
architecture is mainly applicable to a scenario in which a 5G core
network is accessed in a non-3GPP mode. Both the network
architectures shown in FIG. 3 and FIG. 4 include network elements
related to key negotiation: a terminal, an access node (AN)
(namely, a non-3GPP interworking function (N3IWF) in FIG. 4), an
access and mobility control function network element (AMF), a
session management network element (SMF), an authentication server
(AUSF), and a unified data management network element (UDM).
[0066] It should be noted that a security anchor such as a Security
Anchor Function (SEAF) may be deployed in the AMF, and an
authentication credential repository and processing function
network element (ARPF) may be deployed in the UDM. Certainly, the
SEAF may not be deployed in the AMF, but is deployed independently
of the AMF. Similarly, the ARPF may not be deployed in the UDM, but
is deployed independently of the UDM.
[0067] The following separately and briefly describes the network
elements related to key negotiation (the terminal, the AN, the AMF,
the SMF, the AUSF, and the UDM).
[0068] The terminal may be any one of a UE, a communications
device, or an Internet of Things (IoT) device. The user equipment
may be a smartphone, a smartwatch, a smart tablet, or the like. The
communications device may be a server, a gateway (GW), a base
station, a controller, or the like. The Internet of Things device
may be a sensor, an electricity meter, a water meter, or the
like.
[0069] The AN may be a wireless access point, for example, a base
station, a Wi-Fi access point, or a Bluetooth access point.
Alternatively, the AN may be a wired access point, for example, a
gateway, a modem, fiber access, or IP access.
[0070] The AMF is responsible for access control and mobility
management, and is a forwarding and processing node of non-access
stratum (NAS) signaling.
[0071] The SMF is configured to execute establishment and
management of a session, a slice, a flow, or a bearer.
Subsequently, a physical entity that executes the function of the
session management network element may be referred to as a session
management (SM) device. The establishment and management of the
slice, the flow, or the bearer are in the charge of the mobility
management network element.
[0072] The AUSF is responsible for generating, managing, and
negotiating a key. The AUSF may be separately deployed as an
independent logical functional entity, or may be integrated into a
Mobility Management network element, namely, a device such as the
AMF or the session management network element (e.g., SMF).
Additionally, the AUSF may be an authentication node of Evolved
Packet System (EPS) Authentication and Key Agreement (EPS AKA) or
Extensible Authentication Protocol (EAP) AKA (EAP AKA'), or a node
of another authentication protocol.
[0073] The UDM means unified data management and mainly includes
two parts. One part is a front end of a service or an application,
and the other part is a user database. Further, the unified data
management includes credential processing, location management,
subscription data management, policy control, and the like, and
also includes information storage of the related processing.
[0074] The SEAF, as a node that has a security authentication
function, may be an authentication node of EAP AKA or EAP AKA' or a
node of another authentication protocol. For example, when an
authentication process is EPS AKA, the SEAF is to receive an
intermediate key K.sub.asme.
[0075] The ARPF stores a security credential and uses the security
credential to perform a security-related operation, for example,
generating a key and storing a security file. The ARPF should be
deployed at a physically secure position, and can interact with the
AUSF. In actual deployment, the ARPF may be a module of the UDM or
is a separate network entity deployed with the UDM.
[0076] It should be noted that, FIG. 3 and FIG. 4 show a logical
relationship between network elements. In practice, some network
elements may be deployed separately, or two or more network
elements may be integrated into one entity during deployment.
[0077] To generate a unified anchor key for different access modes,
an embodiment of this application provides an anchor key generation
method. In the method, not only the unified anchor key can be
generated, but also the anchor key of different access modes can be
separated from a lower-layer key generated based on the anchor
key.
[0078] As shown in FIG. 5, an embodiment of this application
provides a first anchor key generation method. In this embodiment,
an AUSF may be the first communications device in the claims, an
AMF or an SEAF may be the second communications device in the
claims, and an ARPF may be the third communications device in the
claims. The method may be implemented based on the network
architectures shown in FIG. 3 and FIG. 4, and the method includes
but is not limited to the following steps below.
[0079] 101. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0080] In this embodiment of this application, the terminal
identifier may be a fixed identifier, for example, a media access
control (MAC) address, an Internet Protocol (IP) address, a mobile
number, an International Mobile Equipment Identity (IMEI), an
international mobile subscriber identity (IMSI), an IP multimedia
private identity (IMPI), or an IP multimedia public identity
(IMPU). Alternatively, the terminal identifier may be a temporarily
allocated identifier, for example, a temporary mobile subscriber
identity (TMSI) or a globally unique temporary UE identity
(GUTI).
[0081] It may be understood that, in addition to the terminal
identifier, the UE may send, to the AN, at least one of an access
network parameter, a registration type, a security parameter, a 5G
network capability of the UE, or a PDU session status. The access
network parameter may be a parameter related to a service network,
such as a frequency of an access network, a temporary user
identity, or NSSAI. The registration type may indicate an initial
registration of a user, registration caused by a movement, a
periodic registration update, or the like, in order to distinguish
between user registration behaviors. The security parameter is a
parameter related to authentication and integrity protection. The
NSSAI is short for network slice selection assistance information.
The 5G network capability of the UE may include a configuration
capability that supports access to the network. The PDU session is
a service connection of a PDU between the UE and a data network,
and a type of the service connection may be an IP or Ethernet
service connection.
[0082] 102. The AN sends the terminal identifier and an indication
identifier to the AMF (or the SEAF). Correspondingly, the AMF (or
the SEAF) receives the terminal identifier and the indication
identifier sent by the AN.
[0083] In this embodiment of this application, the indication
identifier is used to indicate an access mode of the terminal. In a
5G standard, the access mode of the terminal may be classified
based on different classification bases. For example, the
classification bases of the access mode may include an access type
and an operator type. The access type may be classified into a 3GPP
access type, a trusted non-3GPP access type, and an untrusted
non-3GPP access type. The operator type may be classified into an
operator type A or an operator type B. It may be understood that
there may be more operator types. The operator types are merely
examples herein, and are not specifically limited.
[0084] For example, the classification bases include the access
type and the operator type. Classification of the access mode may
be as shown in Table 1.
TABLE-US-00001 TABLE 1 Access mode table Access type Trusted
Untrusted 3GPP access non-3GPP non-3GPP access Operator type type
access type type Operator type A Access mode 1 Access mode 2 Access
mode 3 Operator type B Access mode 4 Access mode 5 Access mode
6
[0085] It should be noted that the classification bases are not
limited to the foregoing two types of classification bases. The
classification basis of the access mode may be another type of
classification basis, for example, a medium type (wired access or
wireless access). This is not specifically limited herein. In
addition, the classification bases are not limited to the two
classification bases: the access type and the operator type. There
may be one, three, four, or more classification bases of the access
mode, that is, the access mode may be classified by more dimensions
or fewer dimensions. For example, the access mode may be
distinguished only by a dimension including the 3GPP access type
and the non-3GPP access type.
[0086] The indication identifier may be carried in the access
network parameter. The indication identifier may be any one of the
following manners. The indication identifier may be a Network
Access Identifier (NAI) used to indicate both the access type and
the operator type. Alternatively, the indication identifier may
include an access type identifier and an operator type identifier,
where the access type identifier is used to indicate the access
type, and the operator type identifier is used to indicate the
operator type. It may be understood that the foregoing example is
merely used as an example, and does not constitute a specific
limitation.
[0087] In some possible implementations, the network access
identifier may be an SN identity an access network identity, that
is, may particularly indicate a type of access of an operator, for
example, wireless local area network (WLAN) access of China Unicom.
The SN identity herein is defined in a 4G network, and the access
network identity is defined in a non-3GPP network in 4G It is also
possible to upgrade the SN identity or access network identity
mode, such that it can represent a particular access type of a
particular operator.
[0088] In some possible implementations, the access type identifier
indicates that the access type is a 3GPP access type, a trusted
non-3GPP access type, and an untrusted non-3GPP access type. For
example, the access type identifier access network type (ANT) may
be directly character strings such as "3GPP network", "Trusted
Non-3GPP network", and "Untrusted Non-3GPP network", or may be only
character strings such as "3GPP network" and "Non-3GPP
network".
[0089] In some possible implementations, the operator type
identifier may include two parts: One part is used to indicate an
operator, and the other part is used to indicate a specific access
type. For example, the operator type identifier may indicate
Long-Term Evolution (LTE) access of China Mobile or WLAN access of
China Unicom. In application, a combination of the SN Identity and
the Access Network Identity may be used as an operator type
identifier. Alternatively, the operator type identifier may only
indicate an operator, such as China Mobile, China Unicom, and China
Telecom.
[0090] In some possible implementations, it may be possible that
the indication identifier is only an operator type identifier.
[0091] In some possible implementations, it may be possible that
the indication identifier is only an access type identifier.
[0092] 103. The AMF (or the SEAF) sends the terminal identifier and
the indication identifier to the AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the AMF (or the SEAF).
[0093] 104. The AUSF sends the terminal identifier and the
indication identifier to the ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0094] 105. The ARPF generates an intermediate key based on a
cipher key CK, an integrity key (IK), and the indication
identifier.
[0095] In this embodiment of this application, the ARPF may
generate the intermediate key based on a key generation algorithm
in the following several manners.
[0096] In a first manner, when the indication identifier is an NAI,
the ARPF generates the intermediate key based on the following key
generation algorithm: (CK.sub.1', IK.sub.1')=KDF(SQN.sym.AK, NAI,
CK.parallel.IK), where (CK.sub.1', IK.sub.1') is the intermediate
key, CK.sub.1' is the intermediate cipher key, IK.sub.1' is the
intermediate integrity key, KDF is the key generation algorithm,
SQN is a latest sequence number, NAI is the indication identifier,
CK is an initial cipher key, IK is an initial integrity key, AK is
an anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0097] In a second manner, when the indication identifier includes
an access type identifier and an operator type identifier, the ARPF
generates the intermediate key based on the following key
generation algorithm: (CK.sub.1', IK.sub.1')=KDF(SQN.sym.AK, ANT,
SNT, CK.parallel.IK), where (CK.sub.1', IK.sub.1') is the
intermediate key, CK.sub.1' is the intermediate cipher key,
IK.sub.1' is the intermediate integrity key, KDF is the key
generation algorithm, SQN is a latest sequence number, ANT is the
access type identifier, SNT is the operator type identifier, CK is
an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0098] In some possible implementations, SQN may be a latest
sequence number generated by an AuC, and after generating SQN, the
AuC sends SQN to the ARPF. Similarly, RAND may be a random number
generated by the AuC, and after generating RAND, the AuC sends RAND
to the ARPF. In addition to the foregoing manner, SQN and RAND may
be generated by another communications device in the network
architecture and sent to the ARPF. SQN and RAND may be even
generated by the ARPF itself. This is not specifically limited
herein.
[0099] In some possible implementations, CK may be generated by the
AuC based on a formula CK=f3(RAND), IK may be generated by the AuC
based on a formula IK=f4(RAND), and AK may be generated by the AuC
based on a formula AK=f5(RAND). In addition to the foregoing
manner, CK, IK, and AK may be generated by another communications
device in the network architecture and sent to the ARPF. CK, IK,
and AK may be even generated by the ARPF itself. This is not
specifically limited herein.
[0100] 106. The ARPF sends the intermediate key to the AUSF.
Correspondingly, the AUSF receives the intermediate key sent by the
ARPF.
[0101] 107. The AUSF generates an anchor key based on the
intermediate key.
[0102] In this embodiment of this application, the AUSF generates
the anchor key based on the following formula: anchor
key=KDF(IK.sub.1'.parallel.CK.sub.1'), where anchor key is the
anchor key, (IK.sub.1', CK.sub.1') is the intermediate key,
IK.sub.1' is the intermediate integrity key, CK.sub.1' is the
intermediate cipher key, and .parallel. means concatenation,
indicating that characters on both sides of the symbol are
connected in series. The AUSF may also generate the anchor key
based on the following formula: anchor key=KDF(IK.sub.1',
CK.sub.1').
[0103] 108. The AUSF sends the anchor key to the AMF (or the SEAF).
Correspondingly, the AMF (or the SEAF) receives the anchor key sent
by the AUSF.
[0104] 109. The AMF (or the SEAF) generates a lower-layer key based
on the anchor key. The lower-layer key is a key obtained by
performing one or more times of derivation based on the anchor
key.
[0105] In this embodiment of this application, the anchor key is
generated based on the intermediate key, and the intermediate key
is generated based on the indication identifier. Therefore, a
relationship between the anchor key and the indication identifier
may be represented as anchor key=f(ANT, SNT) or anchor key=f(NAI),
where f indicates a mapping function between the indication
identifier and the anchor key, NAI is the network access
identifier, ANT is the access type identifier, and SNT is the
operator type identifier. According to the mapping relationship
between the anchor key and the indication identifier, it can be
learned that, when the indication identifier is different, a value
of the anchor key is also different. That is, when the access mode
is different, the value of the anchor key is different, in other
words, anchor keys of different access modes are separated. In
addition, the AMF (or the SEAF) separately derives lower-layer keys
of different access modes based on anchor keys of the different
access modes, in order to implement separation between the
lower-layer keys. To be more specific, it is assumed that when the
access mode is an access mode A, an anchor key obtained through
calculation is an anchor key a; and when the access mode is an
access mode B, an anchor key obtained through calculation is an
anchor key b. Then, a lower-layer key of the access mode A may be
derived based on the anchor key a, and a lower-layer key of the
access mode B may be derived based on the anchor key b.
[0106] 110. The AMF (or the SEAF) sends the lower-layer key to the
AN.
[0107] 111. The UE generates an anchor key based on a root key, and
then derives a lower-layer key based on the anchor key. It may be
understood that a process of deriving, by the UE, the lower-layer
key is substantially similar to the foregoing process, and details
are not described herein again.
[0108] It may be understood that, in step 108, the AUSF may further
generate a key K.sub.AMF or a key K.sub.SEAF based on the anchor
key, and then send the key K.sub.AMF or the key K.sub.SEAF to the
AMF or the SEAF, instead of sending the anchor key to the AMF or
the SEAF. Therefore, in step 109, the AMF or the SEAF generates the
lower-layer key based on the key K.sub.AMF or the key
K.sub.SEAF.
[0109] It should be noted that, when access modes are different,
step 109 to step 111 are different. The following provides detailed
description by separately using an example that the access mode is
a 3GPP access mode and an example that the access mode is a
non-3GPP access mode.
[0110] As shown in FIG. 6A, it is assumed that the access mode is
the 3GPP access mode, and the anchor key is an anchor key 1. Then,
step 109 to step 111 may be replaced with the following steps 1111
to 1117.
[0111] 1111. The AMF (or the SEAF) generates a lower-layer key
K.sub.amf1 key and/or K.sub.seaf1 key based on the following
formulas:
K.sub.amf1=KDF(anchor key1,AMF ID);
K.sub.seaf1=KDF(anchor key1,SEAF ID),
where anchor key1 is an anchor key in the 3GPP access mode, KDF is
a key generation algorithm, AMF ID is an identifier of the AMF, and
SEAF ID is an identifier of the SEAF.
[0112] The identifier of the AMF may be a MAC address, an IP
address, or the like of the AMF, and the identifier of the SEAF may
be a MAC address, an IP address, or the like of the SEAF.
[0113] 1113. The AMF (or the SEAF) then generates a base station
key K.sub.gNB, a 3GPP-NAS cipher key K-3GPP.sub.NASenc, and a
3GPP-NAS integrity protection key K-3GPP.sub.NASint in the 3GPP
access mode based on the following formulas:
K.sub.gNB=KDF(K.sub.amf1 and/or Kseaf1,NAS Count1);
K-3GPP.sub.NASint=KDF(K.sub.amf1 and/or
Kseaf1,NAS-int-alg,alg-ID);
K-3GPP.sub.NASenc=KDF(K.sub.amf1 and/or
Kseaf1,NAS-enc-alg,alg-ID),
where NAS Count1 is a count value of a NAS message passing a 3GPP
access point gNB, and may be an uplink count value or may be a
downlink count value, NAS-int-alg is an integrity algorithm
corresponding to the NAS message, such as `AES`, `SNOW 3G`, or
`ZUC`, alg-ID is an algorithm distinguisher, and NAS-enc-alg is an
encryption algorithm corresponding to the NAS message, such as
`AES`, `SNOW 3G`, or `ZUC`.
[0114] 1115. The AMF (or the SEAF) sends the base station key
K.sub.gNB to the AN. In this case, the AN correspondingly receives
the base station key K.sub.gNB sent by the AMF (or the SEAF).
[0115] 1117. The AN generates a user plane cipher key K.sub.UPenc,
a user plane integrity key K.sub.UPint, a control plane cipher key
K.sub.RRCenc, and a control plane integrity key K.sub.RRCint based
on the base station key K.sub.gNB.
[0116] In this embodiment of this application, the AN separately
generates the user plane cipher key K.sub.UPenc, the user plane
integrity key K.sub.UPint, the control plane cipher key
K.sub.RRCenc, and the control plane integrity key K.sub.RRCint
based on the following formulas:
K.sub.UPenc=KDF(K.sub.gNB,UP-enc-alg,alg-ID);
K.sub.UPint=KDF(K.sub.gNB,UP-int-alg,alg-ID);
K.sub.RRCenc=KDF(K.sub.gNB,RRC-enc-alg,alg-ID);
K.sub.RRCint=KDF(K.sub.gNB,RRC-int-alg,alg-ID),
where KDF is a key generation algorithm, K.sub.gNB is the base
station key, alg-ID is an algorithm distinguisher. For definitions
of NAS-int-alg, NAS-enc-alg, UP-enc-alg, UP-int-alg, RRC-enc-alg,
and RRC-int-alg, refer to the algorithm distinguisher definition
table in 4G shown in Table 2, which is as follows below.
TABLE-US-00002 TABLE 2 Algorithm distinguisher definition Algorithm
distinguisher (Algorithm distinguisher) Value (Value) NAS-enc-alg 0
.times. 01 NAS-int-alg 0 .times. 02 RRC-enc-alg 0 .times. 03
RRC-int-alg 0 .times. 04 UP-enc-alg 0 .times. 05 UP-int-alg 0
.times. 06
[0117] 1119. The UE generates an anchor key based on a root key,
and then derives a user plane cipher key (K.sub.UPenc), a user
plane integrity key (K.sub.UPint), a control plane cipher key
(K.sub.RRCenc), and a control plane integrity key (K.sub.RRCint)
based on the anchor key.
[0118] It may be understood that after receiving the anchor key,
the AMF (or the SEAF) may not derive the K.sub.amf1 key and/or the
K.sub.seaf1 key based on the anchor key, or then derive the base
station key K.sub.gNB, the 3GPP-NAS cipher key K-3GPPNAS.sub.enc,
and the 3GPP-NAS integrity protection key K-3GPPNAS.sub.int based
on the K.sub.amf1 key and/or the K.sub.seaf1 key. Instead, the AMF
(or the SEAF) may directly derive the base station key K.sub.gNB,
the 3GPP-NAS cipher key K-3GPPNAS.sub.enc, and the 3GPP-NAS
integrity protection key K-3GPPNAS.sub.int based on the anchor
key.
[0119] As shown in FIG. 6B, it is assumed that the access mode is
the non-3GPP access mode, and the anchor key is an anchor key 2.
Then, step 109 to step 111 may be replaced with the following steps
1112 to 1116.
[0120] 1112. The AMF (or the SEAF) generates a key K.sub.amf2
and/or a key K.sub.seaf2 based on the following formulas:
K.sub.amf2=KDF(anchor key2,AMF ID);
K.sub.seaf2=KDF(anchor key2,SEAF ID),
where anchor key2 is an anchor key in the non-3GPP access mode, KDF
is a key generation algorithm, AMF ID is an identifier of the AMF,
and SEAF ID is an identifier of the SEAF.
[0121] 1114. The AMF (or the SEAF) then generates an access point
key K.sub.N3IWF, a non-3GPP-NAS cipher key K-N3GPP.sub.NASenc, and
a non-3GPP-NAS integrity protection key K-N3GPP NASint in the
non-3GPP access mode based on the following formulas:
K.sub.N3IWF=KDF(K.sub.amf2 and/or K.sub.seaf2,NAS Count2);
K-N3GPP.sub.NASint=KDF(K.sub.amf2 and/or
K.sub.seaf2,NAS-int-alg,alg-ID);
K-N3GPP.sub.NASenc=KDF(K.sub.amf2 and/or
K.sub.seaf2,NAS-enc-alg,alg-ID),
where NAS Count2 is a count value of a NAS message passing a
non-3GPP access point N3IWF, and may be an uplink count value or
may be a downlink count value, NAS-int-alg is an integrity
algorithm corresponding to the NAS message, such as `AES`, `SNOW
3G`, or `ZUC`, alg-ID is an algorithm distinguisher, and
NAS-enc-alg is an encryption algorithm corresponding to the NAS
message, such as `AES`, `SNOW 3G`, or `ZUC`.
[0122] 1116. The AMF (or the SEAF) sends the access point key
K.sub.N3IWF to the AN. In this case, the AN correspondingly
receives the access point key K.sub.N3IWF sent by the AMF (or the
SEAF).
[0123] 1118. The UE generates an anchor key based on a root key,
and then derives an access point key K.sub.N3IWF based on the
anchor key.
[0124] Similarly, it may be understood that, in step 1114, the AMF
(or the SEAF) does not receive the anchor key sent by the AUSF, but
the K.sub.AMF key or the K.sub.SEAF key generated by the AUSF based
on the anchor key.
[0125] It may be understood that, the key generation algorithm in
the embodiment shown in FIG. 5 is not limited to the KDF algorithm.
In application, the key generation algorithm may be another
algorithm, such as a Trunc algorithm: a Trunc algorithm for
truncating least significant bits, or another HASH algorithm. This
is not specifically limited in this application. In addition, an
independent variable of the key generation algorithm may also
include another parameter, such as NSSAI, a random number, a Number
used once (Nonce), a sequence number, a registration type, an
non-access stratum message count (NAS Count), a security algorithm
distinguisher, a security identifier, a length of SQN.sym.AK, or a
length corresponding to a parameter used for generating a key. In
application, one or more parameters may be selected therefrom based
on requirements as independent variables of the key generation
algorithm.
[0126] It may be understood that after receiving the anchor key,
the AMF (or the SEAF) may not derive the K.sub.amf1 key and/or the
K.sub.seaf1 key based on the anchor key, or then derive the access
point key K.sub.N3IWF, the non-3GPP-NAS cipher key
K-N3GPP.sub.NASenc, and the non-3GPP-NAS integrity protection key
K-N3GPP.sub.NASint based on the K.sub.amf1 key and/or the
K.sub.seaf1 key; but directly derives the access point key
K.sub.N3IWF, the non-3GPP-NAS cipher key K-N3GPP.sub.NASenc, and
the non-3GPP-NAS integrity protection key K-N3GPP.sub.NASint based
on the anchor key.
[0127] After the anchor key generation method shown in FIG. 5 is
executed, a key architecture shown in FIG. 7 is to be generated. On
the left of a separation line in FIG. 7, there is a key
architecture generated by performing the process shown in FIG. 6A.
On the right of the separation line in FIG. 7, there is a key
architecture generated by performing the process shown in FIG. 6B.
The two key architectures can be well separated.
[0128] As shown in FIG. 8, an embodiment of this application
provides a second anchor key generation method. In this embodiment,
an AUSF may be the first communications device in the claims, an
AMF or an SEAF may be the second communications device in the
claims, and an ARPF may be the third communications device in the
claims. The method may be implemented based on the network
architectures shown in FIG. 3 and FIG. 4, and the method includes
but is not limited to the following steps.
[0129] 201. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0130] 202. The AN sends the terminal identifier and an indication
identifier to the AMF (or the SEAF). Correspondingly, the AMF (or
the SEAF) receives the terminal identifier and the indication
identifier sent by the AN. The indication identifier includes an
ANT and an SNT.
[0131] 203. The AMF (or the SEAF) sends the terminal identifier and
the indication identifier to the AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the AMF (or the SEAF).
[0132] 204. The AUSF sends the terminal identifier and the
indication identifier to the ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0133] 205. The ARPF generates an intermediate key based on a
cipher key CK, an integrity key IK, and the ANT.
[0134] In this embodiment of this application, the ARPF may
generate the intermediate key based on a key generation algorithm
in the following several manners.
[0135] In a first manner, the ARPF generates the intermediate key
based on the following key generation algorithm: (CK.sub.1',
IK.sub.1')=KDF(SQN.sym.AK, ANT, CK.parallel.IK), where (CK.sub.1',
IK.sub.1') is the intermediate key, CK.sub.1' is the intermediate
cipher key, IK.sub.1' is the intermediate integrity key, KDF is the
key generation algorithm, SQN is a latest sequence number, ANT is
the access type identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0136] In a second manner, the ARPF generates the intermediate key
based on the following key generation algorithm: (CK.sub.1',
IK.sub.1')=KDF(SQN.sym.AK, SNT, CK.parallel.IK), where (CK.sub.1',
IK.sub.1') is the intermediate key, CK.sub.1' is the intermediate
cipher key, IK.sub.1' is the intermediate integrity key, KDF is the
key generation algorithm, SQN is a latest sequence number, SNT is
the operator type identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0137] 206. The ARPF sends the intermediate key to the AUSF.
Correspondingly, the AUSF receives the intermediate key sent by the
ARPF.
[0138] 207. The AUSF generates an anchor key based on the
intermediate key.
[0139] For the first manner of generating the intermediate key in
step 205, the AUSF generates the anchor key based on the
intermediate key in the following manner.
[0140] First, the AUSF generates an EMSK' based on the intermediate
key: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is an
extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0141] Then, the AUSF generates the anchor key based on the
following formula: anchor key=KDF(EMSK', SNT), where anchor key is
the anchor key, and SNT is the operator type identifier.
[0142] For the second manner of generating the intermediate key in
step 205, the AUSF generates the anchor key based on the
intermediate key in the following manner.
[0143] First, the AUSF generates an EMSK' based on the intermediate
key: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is an
extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0144] Then, the AUSF generates the anchor key based on the
following formula: anchor key=KDF(EMSK', ANT), where anchor key is
the anchor key, and ANT is the access type identifier.
[0145] Alternatively, the anchor key may be generated based on the
EMSK' and another parameter, which is not limited to the indication
identifier.
[0146] It may be understood that the anchor key may also be
generated based on an MSK', and using the EMSK' to generate the
anchor key herein is only used as an example.
[0147] 208. The AUSF sends the anchor key to the AMF (or the SEAF).
Correspondingly, the AMF (or the SEAF) receives the anchor key sent
by the AUSF.
[0148] 209. The AMF (or the SEAF) generates a lower-layer key based
on the anchor key. The lower-layer key is a key obtained by
performing one or more times of derivation based on the anchor
key.
[0149] 210. The AMF (or the SEAF) sends the lower-layer key to the
AN.
[0150] 211. The UE generates an anchor key based on a root key, and
then derives a lower-layer key based on the anchor key.
[0151] As shown in FIG. 9, an embodiment of this application
provides a third anchor key generation method. In this embodiment,
an AUSF may be the first communications device in the claims, an
AMF or an SEAF may be the second communications device in the
claims, and an ARPF may be the third communications device in the
claims. The method may be implemented based on the network
architectures shown in FIG. 3 and FIG. 4, and the method includes
but is not limited to the following steps.
[0152] 221. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0153] 222. The AN sends the terminal identifier and an indication
identifier to the AMF (or the SEAF). Correspondingly, the AMF (or
the SEAF) receives the terminal identifier and the indication
identifier sent by the AN. The indication identifier includes an
ANT and an SNT.
[0154] 223. The AMF (or the SEAF) sends the terminal identifier and
the indication identifier to the AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the AMF (or the SEAF).
[0155] 224. The AUSF sends the terminal identifier and the
indication identifier to the ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0156] 225. The ARPF generates an intermediate key based on a
cipher key CK, an integrity key IK, and the ANT.
[0157] In this embodiment of this application, the ARPF may
generate the intermediate key based on a key generation algorithm
in the following several manners.
[0158] In a first manner, the ARPF generates the intermediate key
based on the following key generation algorithm: (CK.sub.1',
IK.sub.1')=KDF(SQN.sym.AK, ANT, CK.parallel.IK), where (CK.sub.1',
IK.sub.1') is the intermediate key, CK.sub.1' is the intermediate
cipher key, IK.sub.1' is the intermediate integrity key, KDF is the
key generation algorithm, SQN is a latest sequence number, ANT is
the access type identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0159] In a second manner, the ARPF generates the intermediate key
based on the following key generation algorithm: (CK.sub.1',
IK.sub.1')=KDF(SQN.sym.AK, SNT, CK.parallel.IK), where (CK.sub.1',
IK.sub.1') is the intermediate key, CK.sub.1' is the intermediate
cipher key, IK.sub.1' is the intermediate integrity key, KDF is the
key generation algorithm, SQN is a latest sequence number, SNT is
the operator type identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0160] 226. The ARPF sends the intermediate key to the AUSF.
Correspondingly, the AUSF receives the intermediate key sent by the
ARPF.
[0161] 227. The AUSF generates an anchor key based on the
intermediate key.
[0162] For the first manner of generating the intermediate key in
step 225, the AUSF generates the anchor key based on the
intermediate key in the following manner.
[0163] First, the AUSF generates an EMSK' based on the intermediate
key: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is an
extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0164] Then, the AUSF generates the anchor key based on the
following formula: anchor key=KDF(EMSK', SNT), where anchor key is
the anchor key, and SNT is the operator type identifier.
[0165] For the second manner of generating the intermediate key in
step 225, the AUSF generates the anchor key based on the
intermediate key in the following manner.
[0166] First, the AUSF generates an EMSK' based on the intermediate
key: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is an
extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0167] Then, the AUSF generates the anchor key based on the
following formula: anchor key=KDF(EMSK', ANT), where anchor key is
the anchor key, and ANT is the access type identifier.
[0168] It may be understood that, the anchor key may be generated
based on the EMSK' and another parameter, which is not limited to
the indication identifier.
[0169] It may be understood that the anchor key may also be
generated based on an MSK', and using the EMSK' to generate the
anchor key herein is only used as an example.
[0170] 228. The AUSF generates a key K.sub.AMF and/or a key
K.sub.SEAF based on the anchor key.
[0171] In this embodiment of this application, the AUSF generates
the key K.sub.AMF or the key K.sub.SEAF based on the following key
generation algorithms:
K.sub.AMF=KDF(anchor key,AMF ID);
K.sub.SEAF=KDF(anchor key,SEAF ID),
where anchor key is the anchor key, KDF is the key generation
algorithm, AMF ID is an identifier of the AMF, and SEAF ID is an
identifier of the SEAF.
[0172] 229. The AUSF sends the key K.sub.AMF and/or the key
K.sub.SEAF to the AMF (or the SEAF). Correspondingly, the AMF (or
the SEAF) receives the key K.sub.AMF and/or the key K.sub.SEAF sent
by the AUSF.
[0173] 230. The AMF (or the SEAF) generates a lower-layer key based
on the key K.sub.AMF and/or the key K.sub.SEAF. The lower-layer key
is a key obtained by performing one or more times of derivation
based on the key K.sub.AMF and/or the key K.sub.SEAF.
[0174] 231. The AMF (or the SEAF) sends the lower-layer key to the
AN.
[0175] 232. The UE generates an anchor key based on a root key, and
then derives a lower-layer key based on the anchor key.
[0176] It may be understood that after generating the anchor key,
the AUSF may also directly send the anchor key to the AMF, and then
the AMF generates the lower-layer key based on the anchor key and
sends the lower-layer key to the AN.
[0177] After the anchor key generation method shown in FIG. 9 is
executed, a key architecture shown in FIG. 10 is to be generated.
On the left of a separation line in FIG. 9, there is a key
architecture corresponding to the UE and a 3GPP network, and on the
right of the separation line in FIG. 10, there is a key
architecture corresponding to the UE and a non-3GPP network. The
key architectures can be well separated.
[0178] It may be understood that, for step 227, the AUSF may
further generate two keys based on the intermediate key: an MSK'
and an EMSK', respectively. The MSK' and the EMSK' are different
parts of a key generated by PRF'(IK.sub.2'.parallel.CK.sub.2'), for
example, the MSK' is the first 512 bits, and the EMSK' is the last
512 bits.
[0179] Then, the anchor key is generated based on the MSK', namely,
anchor key=KDF(MSK', ANT), as described above.
[0180] The EMSK' is reserved by the AUSF or a key obtained after
the AUSF performs derivation based on the EMSK' is reserved for
subsequent extension.
[0181] As shown in FIG. 11A and FIG. 11B, an embodiment of this
application provides a fourth anchor key generation method. In this
embodiment, an AUSF may be the first communications device in the
claims, an SEAF may be the second communications device in claim 2,
and an ARPF may be the third communications device in the claims.
The method may be implemented based on the network architectures
shown in FIG. 3 and FIG. 4. In addition, in this embodiment, there
are m AMFs, which are named AMF_1 to AMF_m, respectively. The
method includes but is not limited to the following steps.
[0182] 301. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0183] 302. The AN sends the terminal identifier and an indication
identifier to the AMF_1 to the AMF_m. Correspondingly, the AMF_1 to
the AMF_m receive the terminal identifier and the indication
identifier sent by the AN.
[0184] 303. The AMF_1 to the AMF_m send the terminal identifier and
the indication identifier to the SEAF. Correspondingly, the SEAF
receives the terminal identifier and the indication identifier sent
by the AMF_1 to the AMF_m.
[0185] 304. The SEAF sends the terminal identifier and the
indication identifier to the AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the SEAF.
[0186] 305. The AUSF sends the terminal identifier and the
indication identifier to the ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0187] 306. The ARPF generates an intermediate key based on a
cipher key CK, an integrity key IK, and an ANT.
[0188] 307. The ARPF sends the intermediate key to the AUSF.
Correspondingly, the AUSF receives the intermediate key sent by the
ARPF.
[0189] 308. The AUSF generates an anchor key based on the
intermediate key.
[0190] 309. The AUSF sends the anchor key to the SEAF.
Correspondingly, the SEAF receives the anchor key sent by the
AUSF.
[0191] 310. The SEAF separately generates K.sub.AMF_1 to
K.sub.AMF_m based on the anchor key and identifiers of the AMF_1 to
the AMF_m.
[0192] In this embodiment of this application, the SEAF separately
generates K.sub.AMF_1 to K.sub.AMF_m based on the following
formulas:
K.sub.AMF_1=KDF(anchor key,AMF_1 ID);
K.sub.AMF_2=KDF(anchor key,AMF_2 ID);
. . .
K.sup.AMF_m=KDF(anchor key,AMF_m ID),
where anchor key is the anchor key, and AMF_1 ID to AMF_m ID are
the identifiers of the AMF_1 to the AMF_m respectively.
[0193] 311. The SEAF delivers K.sub.AMF_1 to K.sub.AMF_m to the
AMF_1 to the AMF_m respectively. Correspondingly, the AMF_1 to the
AMF_2 respectively receive K.sub.AMF_1 to K.sub.AMF_m sent by the
SEAF.
[0194] 312. The AMF_1 to the AMF_m separately generate lower-layer
keys based on K.sub.AMF_1 to K.sub.AMF_m.
[0195] In this embodiment of this application, the AMF_1 generates
a lower-layer key 1 based on K.sub.AMF_1; the AMF_2 generates a
lower-layer key 2 based on K.sub.AMF_2; . . . ; and the AMF_m
generates a lower-layer key m based on K.sub.AMF_m.
[0196] That the AMF_1 generates the lower-layer key 1 based on
K.sub.AMF_1 is used as an example for description in the
following.
[0197] The AMF_1 generates a base station key K.sub.gNB1, a
3GPP-NAS cipher key K-3GPP.sub.NASenc1, and a 3GPP-NAS integrity
protection key K-3GPP.sub.NASint1 in a 3GPP access mode based on
the following formulas:
K.sub.gNB1=KDF(K.sub.AMF_1,NAS Count1);
K-3GPP.sub.NASint=KDF(K.sub.AMF_1,NAS-int-alg,alg-ID);
K-3 GPP.sub.NASenc=KDF(K.sub.AMF_1,NAS-enc-alg,alg-ID),
where NAS Count1 is a count value of a NAS message passing a 3GPP
access point gNB, and may be an uplink count value or may be a
downlink count value, NAS-int-alg is an integrity algorithm
corresponding to the NAS message, such as `AES`, `SNOW 3G`, or
`ZUC`, alg-ID is an algorithm distinguisher, and NAS-enc-alg is an
encryption algorithm corresponding to the NAS message, such as
`AES`, `SNOW 3G`, or `ZUC`.
[0198] 313. The AMFs send the lower-layer keys to the AN.
[0199] 314. The UE generates an anchor key based on a root key, and
then derives a lower-layer key based on the anchor key.
[0200] After the anchor key generation method shown in FIG. 11A and
FIG. 11B is executed, a key architecture shown in FIG. 12 is to be
generated. On the left of a separation line in FIG. 12, there is a
key architecture corresponding to the UE and a 3GPP network, and on
the right of the separation line in FIG. 12, there is a key
architecture corresponding to the UE and a non-3GPP network. The
key architectures can be well separated.
[0201] It may be understood that the embodiments shown in FIG. 8,
FIG. 9, and FIG. 11A and FIG. 11B evolve based on the embodiment
shown in FIG. 5. For brevity, the embodiments shown in FIG. 8, FIG.
9, and FIG. 11A and FIG. 11B describe only a part that is different
from the embodiment shown in FIG. 5. For a part that is in the
embodiments shown in FIG. 8, FIG. 9, and FIG. 11A and FIG. 11B and
that is the same as that in the embodiment shown in FIG. 5, refer
to FIG. 5 and related content. Details are not described herein
again.
[0202] As shown in FIG. 13, an embodiment of this application
provides a fifth anchor key generation method. The method may be
implemented based on the network architectures shown in FIG. 3 and
FIG. 4, and the method includes but is not limited to the following
steps.
[0203] 401. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0204] In this embodiment of this application, the terminal
identifier may be a fixed identifier, for example, a media access
control (MAC) address, an Internet Protocol (IP) address, a mobile
number, an international mobile equipment identity (International
Mobile Equipment Identity, IMEI), an international mobile
subscriber identity (IMSI), an IP multimedia private identity
(IMPI), or an IP multimedia public identity (IMPU); or may be a
temporarily allocated identifier, for example, a temporary mobile
subscriber identity (TMSI) or a globally unique temporary UE
identity (GUTI).
[0205] It may be understood that, in addition to the terminal
identifier, the UE may send, to the AN, at least one of an access
network parameter, a registration type, a security parameter, a 5G
network capability of the UE, or a PDU session status. The access
network parameter may be a parameter related to a service network,
such as a frequency of an access network, a temporary user
identity, or NSSAI. The registration type may indicate that a user
is performing initial registration, registration caused by a
movement, a periodic registration update, or the like, in order to
distinguish between user registration behaviors. The security
parameter is a parameter related to authentication and integrity
protection. The NSSAI is short for network slice selection
assistance information. The 5G network capability of the UE may
include a configuration capability that supports access to the
network. The PDU session is a service connection of a PDU between
the UE and a data network, and a type of the service connection may
be an IP or Ethernet service connection.
[0206] 402. The AN sends the terminal identifier and an indication
identifier to an AMF (or an SEAF). Correspondingly, the AMF (or the
SEAF) receives the terminal identifier and the indication
identifier sent by the AN.
[0207] In this embodiment of this application, the indication
identifier is used to indicate an access mode of a terminal. In a
5G standard, the access mode of the terminal may be classified
based on different classification bases. For example, the
classification bases of the access mode may include an access type
and an operator type. The access type may be classified into a 3GPP
access type, a trusted non-3GPP access type, and an untrusted
non-3GPP access type. The operator type may be classified into an
operator type A or an operator type B. It may be understood that
there may be more operator types. The operator types are merely
examples herein, and are not specifically limited.
[0208] For example, the classification bases include the access
type and the operator type. Classification of the access mode may
be shown in Table 1. It should be noted that the classification
bases are not limited to the foregoing two types of classification
bases. The classification basis of the access mode may be another
type of classification basis, for example, a medium type (wired
access or wireless access). This is not specifically limited
herein. In addition, the classification bases are not limited to
the two classification bases: the access type and the operator
type. There may be one, three, four, or more classification bases
of the access mode, that is, the access mode may be classified by
more dimensions or fewer dimensions.
[0209] The indication identifier may be carried in the access
network parameter. The indication identifier may be any one of the
following manners. The indication identifier may be a network
access identifier (NAI), used to indicate both an access type and
an operator type. Alternatively, the indication identifier may
include an access type identifier and an operator type identifier,
where the access type identifier is used to indicate the access
type, and the operator type identifier is used to indicate the
operator type. It may be understood that the foregoing example is
merely used as an example, and does not constitute a specific
limitation.
[0210] In some possible implementations, the network access
identifier may be an SN identity an access network identity, that
is, may particularly indicate a type of access of an operator, for
example, WLAN access of China Unicom. The SN identity herein is
defined in a 4G network, and the access network identity is defined
in a non-3GPP network in 4G It is also possible to upgrade the SN
identity or access network identity mode, such that it can
represent a particular access type of a particular operator.
[0211] In some possible implementations, the access type identifier
indicates that the access type is a 3GPP access type, a trusted
non-3GPP access type, and an untrusted non-3GPP access type. For
example, the access type identifier access network type (ANT) may
be directly character strings such as "3GPP network", "Trusted
Non-3GPP network", and "Untrusted Non-3GPP network", or may be only
character strings such as "3GPP network" and "Non-3GPP
network".
[0212] In some possible implementations, the operator type
identifier may include two parts, where one part is used to
indicate an operator, and the other part is used to indicate a
specific access type. For example, the operator type identifier may
indicate LTE access of China Mobile or WLAN access of China Unicom.
In application, a combination of the SN Identity and the Access
Network Identity may be used as an operator type identifier.
Alternatively, the operator type identifier may only indicate an
operator, such as China Mobile, China Unicom, and China
Telecom.
[0213] In some possible implementations, it may be possible that
the indication identifier is only an operator type identifier.
[0214] In some possible implementations, it may be possible that
the indication identifier is only an access type identifier.
[0215] 403. The AMF (or the SEAF) sends the terminal identifier and
the indication identifier to an AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the AMF (or the SEAF).
[0216] 404. The AUSF sends the terminal identifier and the
indication identifier to an ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0217] 405. The ARPF generates an anchor key based on a cipher key
CK, an integrity key
[0218] IK, and the indication identifier.
[0219] In this embodiment of this application, the ARPF may
generate the anchor key in the following several manners.
[0220] In a first manner, the ARPF generates the anchor key based
on the following formula: anchor key=KDF(SQN.sym.AK, NAI,
CK.parallel.IK), where anchor key is the anchor key, KDF is a key
generation algorithm, SQN is a latest sequence number, NAI is the
indication identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0221] In a second manner, the ARPF generates the anchor key based
on the following formula: anchor key=KDF(SQN.sym.AK, ANT, SNT,
CK.parallel.IK), where anchor key is the anchor key, KDF is a key
generation algorithm, SQN is a latest sequence number, ANT is the
access type identifier, SNT is the operator type identifier, CK is
an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0222] In some possible implementations, SQN may be a latest
sequence number generated by an AuC, and after generating SQN, the
AuC sends SQN to the ARPF. Similarly, RAND may be a random number
generated by the AuC, and after generating RAND, the AuC sends RAND
to the ARPF. In addition to the foregoing manner, SQN and RAND may
also be generated by another communications device in the network
architecture and sent to the ARPF. SQN and RAND may be even
generated by the ARPF itself. This is not specifically limited
herein.
[0223] In some possible implementations, CK may be generated by the
AuC based on a formula CK=f3(RAND), IK may be generated by the AuC
based on a formula IK=f4(RAND), and AK may be generated by the AuC
based on a formula AK=f5(RAND). In addition to the foregoing
manner, CK, IK, and AK may also be generated by another
communications device in the network architecture and sent to the
ARPF. CK, IK, and AK may be even generated by the ARPF itself. This
is not specifically limited herein.
[0224] 406. The ARPF sends the anchor key to the AUSF.
Correspondingly, the AUSF receives the anchor key sent by the
ARPF.
[0225] 407. The AUSF generates K.sub.amf/K.sub.seaf based on the
anchor key.
[0226] In this embodiment of this application, the AUSF generates
K.sub.amf/K.sub.seaf based on the following formulas:
K.sub.amf=KDF(anchor key,AMF ID);
K.sub.seaf=KDF(anchor key,SEAF),
where anchor key is the anchor key, KDF is a key generation
algorithm, AMF ID is an identifier of the AMF, and SEAF ID is an
identifier of the SEAF. The identifier of the AMF_may be a MAC
address, an IP address, or the like of the AMF, and the identifier
of the SEAF may be a MAC address, an IP address, or the like of the
SEAF.
[0227] 408. The AUSF sends K.sub.amf/K.sub.seaf to the AMF (or the
SEAF). Correspondingly, the AMF (or the SEAF) receives
K.sub.amf/K.sub.seaf sent by the AUSF.
[0228] 409. The AMF (or the SEAF) generates a lower-layer key based
on K.sub.amf/K.sub.seaf. The lower-layer key is a key obtained by
performing one or more times of derivation based on the anchor
key.
[0229] 410. The AMF (or the SEAF) sends the lower-layer key to the
AN.
[0230] 411. The UE generates through derivation by itself a
lower-layer key based on a CK, an IK, and an indication identifier.
It may be understood that a process of deriving, by the UE, the
lower-layer key is substantially similar to the foregoing process,
and details are not described herein again.
[0231] It may be understood that after generating the anchor key,
the AUSF may also directly send the anchor key to the AMF, and then
the AMF generates the lower-layer key based on the anchor key and
sends the lower-layer key to the AN.
[0232] It should be noted that, when access modes are different,
step 409 to step 411 are different. The following provides detailed
description by separately using an example that the access mode is
a 3GPP access mode and an example that the access mode is a
non-3GPP access mode.
[0233] As shown in FIG. 14A, it is assumed that the access mode is
the 3GPP access mode, and the anchor key is an anchor key 1. Then,
step 409 to step 411 may be replaced with the following steps 4111
to 4117.
[0234] 4111. The AMF (or the SEAF) generates a base station key
K.sub.gNB, a 3GPP-NAS cipher key K-3GPP NASenc, and a 3GPP-NAS
integrity protection key K-3GPP NASint based on
K.sub.amf1/K.sub.seaf1.
[0235] In some embodiments, the AMF (or the SEAF) generates the
base station key K.sub.gNB, the 3GPP-NAS cipher key K-3GPP NASenc,
and the 3GPP-NAS integrity protection key K-3GPP.sub.NASint in the
3GPP access mode based on the following formulas:
K.sub.gNB=KDF(K.sub.amf1 and/or Kseaf1,NAS Count1);
K-3GPP.sub.NASint=KDF(K.sub.amf1 and/or
K.sub.seaf1,NAS-int-alg,alg-ID);
K-3GPP.sub.NASenc=KDF(K.sub.amf1 and/or
K.sub.seaf1,NAS-enc-alg,alg-ID),
where NAS Count1 is a count value of a NAS message passing a 3GPP
access point gNB, and may be an uplink count value or may be a
downlink count value, NAS-int-alg is an integrity algorithm
corresponding to the NAS message, such as `AES`, `SNOW 3G`, or
`ZUC`, alg-ID is an algorithm distinguisher, and NAS-enc-alg is an
encryption algorithm corresponding to the NAS message, such as
`AES`, `SNOW 3G`, or `ZUC`.
[0236] 4113. The AMF (or the SEAF) sends the base station key
K.sub.gNB to the AN. In this case, the AN correspondingly receives
the base station key K.sub.gNB sent by the AMF (or the SEAF).
[0237] 4115. The AN generates a user plane cipher key K.sub.UPenc,
a user plane integrity key K.sub.UPint, a control plane cipher key
K.sub.RRCenc, and a control plane integrity key K.sub.RRCint based
on the base station key K.sub.gNB.
[0238] In this embodiment of this application, the AN separately
generates the user plane cipher key K.sub.UPenc, the user plane
integrity key K.sub.UPint, the control plane cipher key
K.sub.RRCenc, and the control plane integrity key K.sub.RRCint
based on the following formulas:
K.sub.UPenc=KDF(K.sub.gNB,UP-enc-alg,alg-ID);
K.sub.UPint=KDF(K.sub.gNB,UP-int-alg,alg-ID);
K.sub.RRCenc=KDF(K.sub.gNB,RRC-enc-alg,alg-ID);
K.sub.RRCint=KDF(K.sub.gNB,RRC-int-alg,alg-ID),
where KDF is a key generation algorithm, K.sub.gNB is the base
station key, alg-ID is an algorithm distinguisher; and for
definitions of UP-enc-alg, UP-int-alg, RRC-enc-alg, and
RRC-int-alg, refer to the algorithm distinguisher definition table
in 4G shown in Table 2.
[0239] 4117. The UE derives an anchor key by itself based on a CK,
an IK, and an indication identifier, and then derives by itself a
user plane cipher key K.sub.UPenc, a user plane integrity key
K.sub.UPint, a control plane cipher key K.sub.RRCenc, and a control
plane integrity key K.sub.RRCint based on the anchor key.
[0240] As shown in FIG. 14B, it is assumed that the access mode is
the non-3GPP access mode, and the anchor key is an anchor key 2.
Then, step 409 to step 411 may be replaced with the following steps
4112 to 4116.
[0241] 4112. The AMF (or the SEAF) generates an access point key
K.sub.N3IWF, a non-3GPP-NAS cipher key K-N3GPP NASenc, and a
non-3GPP-NAS integrity protection key K-N3GPP.sub.NASint based on
the anchor key anchor key 2.
[0242] In some embodiments, the AMF (or the SEAF) then generates
the access point key K.sub.N3IWF, the non-3GPP-NAS cipher key
K-N3GPP.sub.NASenc, and the non-3GPP-NAS integrity protection key
K-N3GPP NASint in the non-3GPP access mode based on the following
formulas:
K.sub.N3IWF=KDF(K.sub.amf2 and/or K.sub.seaf2,NAS Count2);
K-N3GPP.sub.NASint=KDF(K.sub.amf2 and/or
K.sub.seaf2,NAS-int-alg,alg-ID);
K-N3GPP.sub.NASenc=KDF(K.sub.amf2 and/or
K.sub.seaf2,NAS-enc-alg,alg-ID),
where NAS Count2 is a count value of a NAS message passing a
non-3GPP access point N3IWF, and may be an uplink count value or
may be a downlink count value, NAS-int-alg is an integrity
algorithm corresponding to the NAS message, such as `AES`, `SNOW
3G`, or `ZUC`, alg-ID is an algorithm distinguisher, and
NAS-enc-alg is an encryption algorithm corresponding to the NAS
message, such as `AES`, `SNOW 3G`, or `ZUC`.
[0243] 4114. The AMF (or the SEAF) sends the access point key
K.sub.N3IWF to the AN. In this case, the AN correspondingly
receives the access point key K.sub.N3IWF sent by the AMF (or the
SEAF).
[0244] 4116. The UE derives by itself an anchor key based on a CK,
an IK, and an indication identifier, and then derives by itself an
access point key K.sub.N3IWF based on the anchor key.
[0245] It may be understood that, the key generation algorithm in
the embodiment shown in FIG. 13 is not limited to the KDF
algorithm. In application, the key generation algorithm may be
another algorithm, such as a Trunc algorithm: a Trunc algorithm for
truncating least significant bits, or another HASH algorithm. This
is not specifically limited in this application. In addition, an
independent variable of the key generation algorithm may also
include another parameter, such as NSSAI, a random number, a nonce,
a sequence number, a registration type, an access stratum message
count, a security algorithm distinguisher, a security identifier, a
length of SQN .sym. AK, or a length corresponding to a parameter
used for generating a key. In application, one or more parameters
may be selected therefrom based on requirements as independent
variables of the key generation algorithm.
[0246] After the anchor key generation method shown in FIG. 13 is
executed, a key architecture shown in FIG. 15 is to be generated.
On the left of a separation line in FIG. 15, there is a key
architecture generated by performing the process shown in FIG. 14A.
On the right of the separation line in FIG. 15, there is a key
architecture generated by performing the process shown in FIG. 14B.
The two key architectures can be well separated.
[0247] As shown in FIG. 16, an embodiment of this application
provides a sixth anchor key generation method. The method may be
implemented based on the network architectures shown in FIG. 3 and
FIG. 4, and the method includes but is not limited to the following
steps.
[0248] 501. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0249] In this embodiment of this application, the terminal
identifier may be a fixed identifier, for example, a media access
control (MAC) address, an Internet Protocol (IP) address, a mobile
number, an international mobile equipment identity (International
Mobile Equipment Identity, IMEI), an international mobile
subscriber identity (IMSI), an IP multimedia private identity
(IMPI), or an IP multimedia public identity (IMPU); or may be a
temporarily allocated identifier, for example, a temporary mobile
subscriber identity (TMSI) or a globally unique temporary UE
identity (GUTI).
[0250] It may be understood that, in addition to the terminal
identifier, the UE may send, to the AN, at least one of an access
network parameter, a registration type, a security parameter, a 5G
network capability of the UE, or a PDU session status. The access
network parameter may be a parameter related to a service network,
such as a frequency of an access network, a temporary user
identity, or NSSAI. The registration type may indicate that a user
is performing initial registration, registration caused by a
movement, a periodic registration update, or the like, in order to
distinguish between user registration behaviors. The security
parameter is a parameter related to authentication and integrity
protection. The NSSAI is short for network slice selection
assistance information. The 5G network capability of the UE may
include a configuration capability that supports access to the
network. The PDU session is a service connection of a PDU between
the UE and a data network, and a type of the service connection may
be an IP or Ethernet service connection.
[0251] 502. The AN sends the terminal identifier and an indication
identifier to an AMF (or an SEAF). Correspondingly, the AMF (or the
SEAF) receives the terminal identifier and the indication
identifier sent by the AN.
[0252] In this embodiment of this application, the indication
identifier is used to indicate an access mode of a terminal. In a
5G standard, the access mode of the terminal may be classified
based on different classification bases. For example, the
classification bases of the access mode may include an access type
and an operator type. The access type may be classified into a 3GPP
access type, a trusted non-3GPP access type, and an untrusted
non-3GPP access type. The operator type may be classified into an
operator type A or an operator type B. It may be understood that
there may be more operator types. The operator types are merely
examples herein, and are not specifically limited.
[0253] For example, the classification bases include an access type
and an operator type. Classification of the access mode may be
shown in Table 1. It should be noted that the classification bases
are not limited to the foregoing two types of classification bases.
The classification basis of the access mode may be another type of
classification basis, for example, a medium type (wired access or
wireless access). This is not specifically limited herein. In
addition, the classification bases are not limited to the two
classification bases: the access type and the operator type. There
may be one, three, four, or more classification bases of the access
mode, that is, the access mode may be classified by more dimensions
or fewer dimensions.
[0254] The indication identifier may be carried in the access
network parameter. The indication identifier may include an access
type identifier and an operator type identifier, where the access
type identifier is used to indicate the access type, and the
operator type identifier is used to indicate the operator type. It
may be understood that the foregoing example is merely used as an
example, and does not constitute a specific limitation.
[0255] In some possible implementations, the access type identifier
indicates that the access type is a 3GPP access type, a trusted
non-3GPP access type, and an untrusted non-3GPP access type. For
example, the access type identifier access network type (ANT) may
be directly character strings such as "3GPP network", "Trusted
Non-3GPP network", and "Untrusted Non-3GPP network", or may be only
character strings such as "3GPP network" and "Non-3GPP
network".
[0256] In some possible implementations, the operator type
identifier may include two parts: One part is used to indicate an
operator, and the other part is used to indicate a specific access
type. For example, the operator type identifier may indicate LTE
access of China Mobile or WLAN access of China Unicom. In
application, a combination of the SN Identity and the Access
Network Identity may be used as an operator type identifier.
Alternatively, the operator type identifier may only indicate an
operator, such as China Mobile, China Unicom, and China
Telecom.
[0257] In some possible implementations, it may be possible that
the indication identifier is only an operator type identifier.
[0258] In some possible implementations, it may be possible that
the indication identifier is only an access type identifier.
[0259] 503. The AMF (or the SEAF) sends the terminal identifier and
the indication identifier to an AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the AMF (or the SEAF).
[0260] 504. The AUSF sends the terminal identifier and the
indication identifier to an ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0261] 505. The ARPF generates a shared key based on a cipher key
CK, an integrity key IK, and the indication identifier.
[0262] In this embodiment of this application, the ARPF may
generate the shared key in the following several manners.
[0263] In a first manner, the ARPF generates the shared key based
on the following formula: shared key=KDF(SQN.sym.AK, ANT,
CK.parallel.IK), where KDF is a key generation algorithm, SQN is a
latest sequence number, ANT is the access type identifier, CK is an
initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0264] In a second manner, the ARPF generates the shared key based
on the following formula: shared key=KDF(SQN.sym.AK, SNT,
CK.parallel.IK), where KDF is a key generation algorithm, SQN is a
latest sequence number, SNT is the operator type identifier, CK is
an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0265] In some possible implementations, SQN may be a latest
sequence number generated by an AuC, and after generating SQN, the
AuC sends SQN to the ARPF. Similarly, RAND may be a random number
generated by the AuC, and after generating RAND, the AuC sends RAND
to the ARPF. In addition to the foregoing manner, SQN and RAND may
also be generated by another communications device in the network
architecture and sent to the ARPF. SQN and RAND may be even
generated by the ARPF itself. This is not specifically limited
herein.
[0266] In some possible implementations, CK may be generated by the
AuC based on a formula CK=f3(RAND), IK may be generated by the AuC
based on a formula IK=f4(RAND), and AK may be generated by the AuC
based on a formula AK=f5(RAND). In addition to the foregoing
manner, CK, IK, and AK may also be generated by another
communications device in the network architecture and sent to the
ARPF. CK, IK, and AK may be even generated by the ARPF itself. This
is not specifically limited herein.
[0267] 506. The ARPF sends the shared key to the AUSF.
Correspondingly, the AUSF receives the shared key sent by the
ARPF.
[0268] 507. The AUSF sends the shared key to the AMF (or the SEAF).
Correspondingly, the AMF (or the SEAF) receives the shared key sent
by the AUSF.
[0269] 508. The AMF (or the SEAF) generates an anchor key based on
the shared key.
[0270] For the first manner of generating the shared key in step
S05, the AMF generates the anchor key based on the shared key in
the following manner: anchor key=KDF(shared key, SNT), where anchor
key is the anchor key, KDF is a key generation algorithm, and SNT
is the operator type identifier.
[0271] For the second manner of generating the shared key in step
S05, the AMF generates the anchor key based on the shared key in
the following manner: anchor key=KDF(shared key, ANT), where anchor
key is the anchor key, KDF is a key generation algorithm, and ANT
is the access type identifier.
[0272] 509. The AMF (or the SEAF) generates a lower-layer key based
on the anchor key. The lower-layer key is a key obtained by
performing one or more times of derivation based on the anchor
key.
[0273] It may be understood that a process in which the AMF (or the
SEAF) generates the lower-layer key based on a key K.sub.amf/a key
K.sub.seaf is basically the same as the processes shown in FIG. 6A
and FIG. 6B. For details, refer to FIG. 6A and FIG. 6B and related
content. Details are not described herein again.
[0274] 510. The AMF (or the SEAF) sends the lower-layer key to the
AN.
[0275] 511. The UE generates a lower-layer key based on an AK, an
IK, an SNT, and an ANT. It may be understood that a process of
deriving, by the UE, the lower-layer key is substantially similar
to the foregoing process, and details are not described herein
again.
[0276] It should be noted that, when access modes are different,
step S09 to step S11 are different. The following provides detailed
description by separately using an example that the access mode is
a 3GPP access mode and an example that the access mode is a
non-3GPP access mode.
[0277] As shown in FIG. 17A, it is assumed that the access mode is
the 3GPP access mode, and the anchor key is an anchor key 1. Then,
step 509 to step 511 may be replaced with the following steps 5111
to 5117.
[0278] 5111. The AMF (or the SEAF) generates a base station key
K.sub.gNB, a 3GPP-NAS cipher key K-3GPP NASenc, and a 3GPP-NAS
integrity protection key K-3GPP NASint based on the anchor key
1.
[0279] In some embodiments, the AMF (or the SEAF) generates the
base station key K.sub.gNB, the 3GPP-NAS cipher key K-3GPP NASenc,
and the 3GPP-NAS integrity protection key K-3GPP.sub.NASint in the
3GPP access mode based on the following formulas:
K.sub.gNB=KDF(anchor key 1,NAS Count1);
K-3GPP.sub.NASint=KDF(anchor key 1,NAS-int-alg,alg-ID);
K-3GPP.sub.NASenc=KDF(anchor key 1,NAS-enc-alg,alg-ID),
where NAS Count1 is a count value of a NAS message passing a 3GPP
access point gNB, and may be an uplink count value or may be a
downlink count value, NAS-int-alg is an integrity algorithm
corresponding to the NAS message, such as `AES`, `SNOW 3G`, or
`ZUC`, alg-ID is an algorithm distinguisher, and NAS-enc-alg is an
encryption algorithm corresponding to the NAS message, such as
`AES`, `SNOW 3G`, or `ZUC`.
[0280] 5113. The AMF (or the SEAF) sends the base station key
K.sub.gNB to the AN. In this case, the AN correspondingly receives
the base station key K.sub.gNB sent by the AMF (or the SEAF).
[0281] 5115. The AN generates a user plane cipher key K.sub.UPenc,
a user plane integrity key K.sub.UPint, a control plane cipher key
K.sub.RRCenc, and a control plane integrity key K.sub.RRCint based
on the base station key K.sub.gNB.
[0282] In this embodiment of this application, the AN separately
generates the user plane cipher key K.sub.UPenc, the user plane
integrity key K.sub.UPint, the control plane cipher key
K.sub.RRCenc, and the control plane integrity key K.sub.RRCint
based on the following formulas:
K.sub.UPenc=KDF(K.sub.gMB,UP-enc-alg,alg-ID);
K.sub.UPint=KDF(K.sub.gMB,UP-int-alg,alg-ID);
K.sub.RRCenc=KDF(K.sub.gMB,RRC-enc-alg,alg-ID);
K.sub.RRCint=KDF(K.sub.gMB,RRC-int-alg,alg-ID),
where KDF is a key generation algorithm, K.sub.gNB is the base
station key, alg-ID is an algorithm distinguisher; and for
definitions of UP-enc-alg, UP-int-alg, RRC-enc-alg, and
RRC-int-alg, refer to the algorithm distinguisher definition table
in 4G shown in Table 2.
[0283] 5117. The UE generates an anchor key by itself based on an
AK, an IK, an SNT, and an ANT, and then derives by itself a user
plane cipher key K.sub.UPenc, a user plane integrity key
K.sub.UPint, a control plane cipher key K.sub.RRCenc, and a control
plane integrity key K.sub.RRCint based on the anchor key.
[0284] As shown in FIG. 17B, it is assumed that the access mode is
the non-3GPP access mode, and the anchor key is an anchor key 2.
Then, step 509 to step 511 may be replaced with the following steps
5112 to 5116.
[0285] 5112. The AMF (or the SEAF) generates an access point key
K.sub.N3IWF, a non-3GPP-NAS cipher key K-N3GPP.sub.NASenc, and a
non-3GPP-NAS integrity protection key K-N3GPP.sub.NASint based on
the anchor key 2.
[0286] In some embodiments, the AMF (or the SEAF) then generates
the access point key K.sub.N3IWF, the non-3GPP-NAS cipher key
K-N3GPP.sub.NASenc, and the non-3GPP-NAS integrity protection key
K-N3GPP.sub.NASint in the non-3GPP access mode based on the
following formulas:
K.sub.N3IWF=KDF(anchor key 2,NAS Count2);
K-N3GPP.sub.NASint=KDF(anchor key 2,NAS-int-alg,alg-ID);
K-N3GPP.sub.NASenc=KDF(anchor key 2,NAS-enc-alg,alg-ID),
where NAS Count2 is a count value of a NAS message passing a
non-3GPP access point N3IWF, and may be an uplink count value or
may be a downlink count value, NAS-int-alg is an integrity
algorithm corresponding to the NAS message, such as `AES`, `SNOW
3G`, or `ZUC`, alg-ID is an algorithm distinguisher, and
NAS-enc-alg is an encryption algorithm corresponding to the NAS
message, such as `AES`, `SNOW 3G`, or `ZUC`.
[0287] 5114. The AMF (or the SEAF) sends the access point key
K.sub.N3IWF to the AN. In this case, the AN correspondingly
receives the access point key K.sub.N3IWF sent by the AMF (or the
SEAF).
[0288] 5116. The UE generates by itself an anchor key based on an
AK, an IK, an SNT, and an ANT, and then derives by itself an access
point key K.sub.N3IWF based on the anchor key.
[0289] It may be understood that, the key generation algorithm in
the embodiment shown in FIG. 16 is not limited to the KDF
algorithm. In application, the key generation algorithm may be
another algorithm, such as a Trunc algorithm: a Trunc algorithm for
truncating least significant bits, or another HASH algorithm. This
is not specifically limited in this application. In addition, an
independent variable of the key generation algorithm may also
include another parameter, such as NSSAI, a random number, a nonce,
a sequence number, a registration type, an access stratum message
count, a security algorithm distinguisher, a security identifier, a
length of SQN .sym. AK, or a length corresponding to a parameter
used for generating a key. In application, one or more parameters
may be selected therefrom based on requirements as independent
variables of the key generation algorithm.
[0290] After the anchor key generation method shown in FIG. 16 is
executed, a key architecture shown in FIG. 18 is to be generated.
On the left of a separation line in FIG. 18, there is a key
architecture generated by performing the process shown in FIG. 17A.
On the right of the separation line in FIG. 18, there is a key
architecture generated by performing the process shown in FIG. 17B.
The two key architectures can be well separated.
[0291] As shown in FIG. 19, an embodiment of this application
provides a seventh anchor key generation method. The method may be
implemented based on the network architectures shown in FIG. 3 and
FIG. 4, and the method includes but is not limited to the following
steps.
[0292] 601. UE sends a terminal identifier to an AN.
Correspondingly, the AN receives the terminal identifier sent by
the UE.
[0293] In this embodiment of this application, the terminal
identifier may be a fixed identifier, for example, a media access
control (MAC) address, an Internet Protocol (IP) address, a mobile
number, an international mobile equipment identity (International
Mobile Equipment Identity, IMEI), an international mobile
subscriber identity (IMSI), an IP multimedia private identity
IMPI), or an IP multimedia public identity (IMPU); or may be a
temporarily allocated identifier, for example, a temporary mobile
subscriber identity (TMSI) or a globally unique temporary UE
identity (GUTI).
[0294] It may be understood that, in addition to the terminal
identifier, the UE may send, to the AN, at least one of an access
network parameter, a registration type, a security parameter, a 5G
network capability of the UE, or a PDU session status. The access
network parameter may be a parameter related to a service network,
such as a frequency of an access network, a temporary user
identity, or NSSAI. The registration type may indicate that a user
is performing initial registration, registration caused by a
movement, a periodic registration update, or the like, in order to
distinguish between user registration behaviors. The security
parameter is a parameter related to authentication and integrity
protection. The NSSAI is short for network slice selection
assistance information. The 5G network capability of the UE may
include a configuration capability that supports access to the
network. The PDU session is a service connection of a PDU between
the UE and a data network, and a type of the service connection may
be an IP or Ethernet service connection.
[0295] 602. The AN sends the terminal identifier and an indication
identifier to an AMF (or an SEAF). Correspondingly, the AMF (or the
SEAF) receives the terminal identifier and the indication
identifier sent by the AN.
[0296] In this embodiment of this application, the indication
identifier is used to indicate an access mode of a terminal. In a
5G standard, the access mode of the terminal may be classified
based on different classification bases. For example, the
classification bases of the access mode may include an access type
and an operator type. The access type may be classified into a 3GPP
access type, a trusted non-3GPP access type, and an untrusted
non-3GPP access type. The operator type may be classified into an
operator type A or an operator type B. It may be understood that
there may be more operator types. The operator types are merely
examples herein, and are not specifically limited.
[0297] For example, the classification bases include an access type
and an operator type. Classification of the access mode may be
shown in Table 1. It should be noted that the classification bases
are not limited to the foregoing two types of classification bases.
The classification basis of the access mode may be another type of
classification basis, for example, a medium type (wired access or
wireless access). This is not specifically limited herein. In
addition, the classification bases are not limited to the two
classification bases: the access type and the operator type. There
may be one, three, four, or more classification bases of the access
mode, that is, the access mode may be classified by more dimensions
or fewer dimensions.
[0298] The indication identifier may be carried in the access
network parameter. The indication identifier may include an access
type identifier and an operator type identifier, where the access
type identifier is used to indicate the access type, and the
operator type identifier is used to indicate the operator type. It
may be understood that the foregoing example is merely used as an
example, and does not constitute a specific limitation.
[0299] In some possible implementations, the access type identifier
indicates that the access type is a 3GPP access type, a trusted
non-3GPP access type, and an untrusted non-3GPP access type. For
example, the access type identifier access network type (ANT) may
be directly character strings such as "3GPP network", "Trusted
Non-3GPP network", and "Untrusted Non-3GPP network", or may be only
character strings such as "3GPP network" and "Non-3GPP
network".
[0300] In some possible implementations, the operator type
identifier may include two parts, where one part is used to
indicate an operator, and the other part is used to indicate a
specific access type. For example, the operator type identifier may
indicate LTE access of China Mobile or WLAN access of China Unicom.
In application, a combination of the SN Identity and the Access
Network Identity may be used as an operator type identifier.
Alternatively, the operator type identifier may only indicate an
operator, such as China Mobile, China Unicom, and China
Telecom.
[0301] In some possible implementations, it may be possible that
the indication identifier is only an operator type identifier.
[0302] In some possible implementations, it may be possible that
the indication identifier is only an access type identifier.
[0303] 603. The AMF (or the SEAF) sends the terminal identifier and
the indication identifier to an AUSF. Correspondingly, the AUSF
receives the terminal identifier and the indication identifier sent
by the AMF (or the SEAF).
[0304] 604. The AUSF sends the terminal identifier and the
indication identifier to an ARPF. Correspondingly, the ARPF
receives the terminal identifier and the indication identifier sent
by the AUSF.
[0305] 605. The ARPF generates an anchor key based on a root key K
and the indication identifier.
[0306] In this embodiment of this application, the ARPF may
generate the anchor key based on a key generation algorithm in the
following several manners.
[0307] In a first manner, when the indication identifier is an NAI,
the ARPF generates the anchor key based on the following key
generation algorithm: anchor key=KDF(SQN.sym.AK, NAI, K), where KDF
is the key generation algorithm, SQN is a latest sequence number,
NAI is the indication identifier, K is the root key, AK is an
anonymity key, AK=f5(RAND), RAND is a random number, f3 is a
generation algorithm, .sym. means an exclusive OR operation.
[0308] In a second manner, when the indication identifier includes
an access type identifier and an operator type identifier, the ARPF
generates the anchor key anchor key based on the following key
generation algorithm: anchor key=KDF(SQN.sym.AK, ANT, SNT, K),
where KDF is the key generation algorithm, SQN is a latest sequence
number, ANT is the access type identifier, SNT is the operator type
key, AK is an anonymity key, AK=f5(RAND), RAND is a random number,
f5 is a generation algorithm, .sym. means an exclusive OR
operation.
[0309] In some possible implementations, SQN may be a latest
sequence number generated by an AuC, and after generating SQN, the
AuC sends SQN to the ARPF. Similarly, RAND may be a random number
generated by the AuC, and after generating RAND, the AuC sends RAND
to the ARPF. In addition to the foregoing manner, SQN and RAND may
also be generated by another communications device in the network
architecture and sent to the ARPF. SQN and RAND may be even
generated by the ARPF itself. This is not specifically limited
herein.
[0310] In some possible implementations, AK may be generated by the
AuC based on a formula AK=f5(RAND). In addition to the foregoing
manner, AK may also be generated by another communications device
in the network architecture and sent to the ARPF. AK may be even
generated by the ARPF itself. This is not specifically limited
herein.
[0311] 606. The ARPF sends the anchor key to the AUSF.
Correspondingly, the AUSF receives the anchor key sent by the
ARPF.
[0312] 607. The AUSF generates a key K.sub.amf and/or a key
K.sub.seaf based on the anchor key.
[0313] In this embodiment of this application, the AUSF generates
the key K.sub.amf and/or the key K.sub.seaf based on the following
formulas:
K.sub.amf=KDF(anchor key,AMF ID);
K.sub.seaf=KDF(anchor key,SEAF ID),
where anchor key is the anchor key, KDF is a key generation
algorithm, AMF ID is an identifier of the AMF, and SEAF ID is an
identifier of the SEAF.
[0314] 608. The AUSF sends the key K.sub.amf/the key K.sub.seaf to
the AMF/the SEAF. Correspondingly, the AMF/the SEAF receives the
key K.sub.amf/the key K.sub.seaf sent by the AUSF.
[0315] 609. The AMF (or the SEAF) generates a lower-layer key based
on the key K.sub.amf/the key K.sub.seaf. The lower-layer key is a
key obtained by performing one or more times of derivation based on
the anchor key.
[0316] It may be understood that a process in which the AMF (or the
SEAF) generates the lower-layer key based on the key K.sub.amf/the
key K.sub.seaf is basically the same as the processes shown in FIG.
12A and FIG. 12B. For details, refer to FIG. 12A and FIG. 12B and
related content. Details are not described herein again.
[0317] 610. The AMF (or the SEAF) sends the lower-layer key to the
AN.
[0318] 611. The UE generates a lower-layer key based on K, an SNT,
and an ANT. It may be understood that a process of deriving, by the
UE, the lower-layer key is substantially similar to the foregoing
process, and details are not described herein again.
[0319] It may be understood that after generating the anchor key,
the AUSF may also directly send the anchor key to the AMF, and then
the AMF generates the lower-layer key based on the anchor key and
sends the lower-layer key to the AN.
[0320] It may be understood that, the key generation algorithm in
the embodiment shown in FIG. 19 is not limited to the KDF
algorithm. In application, the key generation algorithm may be
another algorithm, such as a Trunc algorithm: a Trunc algorithm for
truncating least significant bits, or another HASH algorithm. This
is not specifically limited in this application. In addition, an
independent variable of the key generation algorithm may also
include another parameter, such as NSSAI, a random number, a nonce,
a sequence number, a registration type, an access stratum message
count, a security algorithm distinguisher, a security identifier, a
length of SQN .sym. AK, or a length corresponding to a parameter
used for generating a key. In application, one or more parameters
may be selected therefrom based on requirements as independent
variables of the key generation algorithm.
[0321] After the anchor key generation method shown in FIG. 19 is
executed, a key architecture shown in FIG. 20 is to be generated.
On the left of a separation line in FIG. 20, there is a key
architecture generated by performing the process of the 3GPP access
mode. On the right of the separation line in FIG. 20, there is a
key architecture generated by performing the process of the
non-3GPP access mode. The two key architectures can be well
separated.
[0322] In another embodiment of the present disclosure, an
implementation of reserving a key on an AUSF is disclosed. The
reserved key may be K.sub.left for short.
[0323] It should be noted that the AUSF sends an anchor key to a
second communications device SEAF, and in a possible deployment
scenario, the SEAF is a security network element of a service
network, and the AUSF is a security network element of a home
network. Especially in a roaming scenario, if authentication occurs
between UE and a security network element of the home network, the
UE and the AUSF may generate a final protection key based on a
reserved key obtained after the authentication, in order to
implement end-to-end security protection or higher security
protection between the UE and the home network.
[0324] It should be noted that the reserved key may be generated by
an ARPF, and then sent to the AUSF, or the reserved key may be
directly generated by the AUSF.
[0325] Method 1: The ARPF may generate the reserved key K.sub.left
based on a parameter such as an IK, a CK, an SQN, an AK, a service
network identifier, a key characteristic identifier, a RAND, or a
nonce.
[0326] The SQN is a latest sequence number, the CK is an initial
cipher key, the IK is an initial integrity key, the AK is an
anonymity key, and both the RAND and the Nonce may be considered as
random numbers. The key characteristic identifier may be a
character string such as KEYLEFT, AUSFKEY, KEYAUSF, KEYSEAF, and
SEAFKEY.
[0327] A subsequently related generation function KDF may also be a
pseudo random function (pseudo random function, PRF), or the like.
For details, refer to the definition in Section 3.4.1 in
RFC5448.
[0328] For example, K.sub.left=KDF(IK, CK, SQN.sym.AK, optional
parameter), and KDF is a key generation algorithm.
[0329] The optional parameter is one or more of an authentication
method name, the service network identifier, the key characteristic
identifier, the RAND, or the nonce.
[0330] The authentication method name may be an identifier of an
identifier authentication method such as `EAP-AKA`, `5G-EAP`, or
`EP S-AKA*`.
[0331] For EPS-AKA*, the ARPF may generate K.sub.left based on
parameters such as K.sub.asme*, the authentication method name, the
service network identifier, a network type identifier, the key
characteristic identifier, the RAND, and the nonce.
[0332] K.sub.asme* is a key similar to K.sub.asme in 4G LTE.
[0333] For example, K.sub.left=KDF(K.sub.asme*, first parameter
group).
[0334] The first parameter group is one or more of the
authentication method name, the service network identifier, the
network type identifier, the key characteristic identifier, the
RAND, or the nonce.
[0335] It should be noted that a process of generating the reserved
key described in Method 1 may be separately combined with the
methods described in FIG. 5, FIG. 8, FIG. 9, FIG. 11A and FIG. 11B,
FIG. 13, and FIG. 16.
[0336] Method 2: For EAP-AKA', the ARPF may generate K.sub.left
based on one or more of parameters such as an IK', a CK', the
authentication method name, the service network identifier, the key
characteristic identifier, an AUSF ID, the RAND, or the nonce.
[0337] For example, K.sub.left=KDF(IK', CK', service network
identifier, key characteristic identifier, second parameter
group).
[0338] The second parameter group is one or more of the
authentication method name, the AUSF ID, the RAND, or the
nonce.
[0339] It should be noted that, alternatively, the ARPF may send
the IK' and the CK' to the AUSF, and the AUSF generates the
K.sub.left.
[0340] It should be noted that a process of generating the reserved
key described in Method 2 may be separately combined with the
methods described in FIG. 5, FIG. 8, FIG. 9, and FIG. 11A and FIG.
11B.
[0341] Method 3: The AUSF may generate K.sub.left based on
parameters such as an EMSK and an MSK. The EMSK is short for
extended master session key. Refer to RFC5448. The MSK is short for
master session key. Refer to RFC5448.
[0342] For example, K.sub.left=trunc (EMSK or MSK). This formula
means that some bits of the EMSK or the MSK are directly truncated
as K.sub.left, and trunc is used to truncate a value. For example,
trunc(number) indicates truncating a number; trunc(date) indicates
truncating a date. Format: TRUNC(n1, n2), where n1 indicates a
to-be-truncated number, n2 indicates truncating to which digit, n2
may be a negative number, meaning truncating to a digit on the left
of a decimal point. It should be noted that TRUNC truncation is not
rounding off.
[0343] For example, K.sub.left=KDF(EMSK or MSK, key characteristic
identifier, third parameter group).
[0344] The third parameter group is one or more of the service
network identifier, the authentication method name, the random
number, or the like.
[0345] For example, K.sub.left may also be understood as the
EMSK.
[0346] It should be noted that a process of generating the reserved
key described in Method 3 may be separately combined with the
methods described in FIG. 8, FIG. 9, and FIG. 11A and FIG. 11B.
[0347] It may be understood that when K.sub.left exists, the anchor
key may be a key generated based on K.sub.left.
[0348] For example, the anchor key may be generated based on a
parameter such as K.sub.left, the service network identifier, the
key characteristic identifier, the RAND, or the nonce.
[0349] In addition, in another embodiment of the present
disclosure, step 1114 in FIG. 6B, step 4112 in FIG. 14B, and step
5112 in FIG. 17B may be replaced with the following described
below.
[0350] The AMF (or the SEAF) generates an access point key
K.sub.N3IWF in a non-3GPP access mode based on parameters such as
K.sub.amf2, K.sub.seaf2, NAS Count2, a NAS connection
differentiation identifier, and an N3IWF identifier.
[0351] For example, Kmiwr=KDF(K.sub.amf2 and/or K.sub.seaf2, NAS
Count2), where NAS Count2 is a count value of a NAS message passing
a non-3GPP access point N3IWF, and may be an uplink count value, or
may be a downlink count value. A and/or B represents three
possibilities: A, B, or (A and B).
[0352] The formula, K.sub.N3IWF=KDF(K.sub.amf2 and/or K.sub.seaf2,
NAS Count2), includes three possibilities:
[0353] 1: K.sub.N3IWF=KDF(K.sub.amf2, NAS Count2);
[0354] 2: K.sub.N3IWF=KDF(K.sub.seaf2, NAS Count2);
[0355] 3: K.sub.N3IWF=KDF(K.sub.amf2, K.sub.seaf2, NAS Count2).
[0356] FIG. 21 shows a schematic structural diagram of a
communications device. In this implementation, the communications
device includes a receiving module 710, a sending module 720, and a
generation module 730. The following provides detailed
description.
[0357] The receiving module 710 is configured to receive an
indication identifier sent by a second communications device, where
the indication identifier is used to indicate an access mode of a
terminal.
[0358] The sending module 720 is configured to send the indication
identifier to a third communications device.
[0359] The receiving module 710 is configured to receive an
intermediate key returned by the third communications device, where
the intermediate key is generated based on the indication
identifier.
[0360] The generation module 730 is configured to generate an
anchor key based on the intermediate key, where the anchor key is
corresponding to the access mode of the terminal.
[0361] The sending module 720 is configured to send the anchor key
to the second communications device, such that the second
communications device derives a lower-layer key for the access mode
based on the anchor key.
[0362] It should be noted that, for content not mentioned in the
embodiment in FIG. 21 and implementations of each function unit,
refer to FIG. 5 to FIG. 10 and related content, and details are not
described herein again.
[0363] Based on a similar concept, an embodiment of the present
disclosure further provides an apparatus (shown in FIG. 22). The
apparatus is configured to implement the methods described in the
foregoing embodiments of FIG. 5 to FIG. 12. As shown in FIG. 22, an
apparatus 800 includes a transmitter 803, a receiver 804, a memory
802, and a processor 801 coupled to the memory 802 (there may be
one or more processors 801, and one processor is used as an example
in FIG. 20). The transmitter 803, the receiver 804, the memory 802,
and the processor 801 may be connected to each other using a bus or
in another manner (using a bus 805 to implement connection is used
as an example in FIG. 22). The transmitter 803 is configured to
send data to the outside, and the receiver 804 is configured to
receive data from the outside. The memory 802 is configured to
store program code, and the processor 801 is configured to invoke
and run the program code stored in the memory 802.
[0364] The receiver 804 receives an indication identifier sent by a
second communications device, where the indication identifier is
used to indicate an access mode of a terminal.
[0365] The transmitter 803 sends the indication identifier to a
third communications device. The receiver 804 receives an
intermediate key returned by the third communications device, where
the intermediate key is generated based on the indication
identifier.
[0366] The processor 801 generates an anchor key based on the
intermediate key, where the anchor key is corresponding to the
access mode of the terminal.
[0367] The transmitter 803 sends the anchor key to the second
communications device, such that the second communications device
derives a lower-layer key for the access mode based on the anchor
key.
[0368] In some possible implementations, the access mode is
distinguished based on at least one of an access type or an
operator type.
[0369] In some possible implementations, the processor 801
generates the anchor key based on the following formula: anchor
key=KDF(IK.sub.1'.parallel.CK.sub.1'), where anchor key is the
anchor key, (IK.sub.1', CV) is the intermediate key, IK.sub.1' is
an intermediate integrity key, CK.sub.1' is an intermediate cipher
key, and .parallel. means concatenation, indicating that characters
on both sides of the symbol are connected in series.
[0370] The processor 801 may generate the intermediate key based on
at least the following two manners.
[0371] When the indication identifier includes an access type
identifier and an operator type identifier, the intermediate key is
generated by the processor 801 based on the following formula:
(CK.sub.1', IK.sub.1')=KDF(SQN.sym.AK, ANT, SNT, CK.parallel.IK),
where the access type identifier is used to indicate the access
type, the operator type identifier is used to indicate the operator
type, (CK.sub.1', IK.sub.1') is the intermediate key, CK.sub.1' is
the intermediate cipher key, IK.sub.1' is the intermediate
integrity key, KDF is a key generation algorithm, SQN is a latest
sequence number, ANT is the access type identifier, SNT is the
operator type identifier, CK is an initial cipher key, IK is an
initial integrity key, AK is an anonymity key, CK=f3(RAND),
IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3, f4, and f5
are generation algorithms, and .sym. means an exclusive OR
operation.
[0372] When the indication identifier is an NAI, the intermediate
key is generated by the processor 801 based on the following
formula: (CK.sub.1', IK.sub.1')=KDF(SQN.sym.AK, NAI,
CK.parallel.IK), where (CK.sub.1', IK.sub.1') is the intermediate
key, CK.sub.1' is an intermediate cipher key, IK.sub.1' is an
intermediate integrity key, KDF is a key generation algorithm, SQN
is a latest sequence number, NAI is the indication identifier, CK
is an initial cipher key, IK is an initial integrity key, AK is an
anonymity key, CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a
random number, f3, f4, and f5 are generation algorithms, and .sym.
means an exclusive OR operation.
[0373] In some possible implementations, the processor 801
generates the intermediate key based on the following formula:
(CK.sub.2', IK.sub.2')=KDF(SQN.sym.AK, ANT, CK.parallel.IK), where
(CK.sub.2', IK.sub.2') is the intermediate key, CK.sub.2' is the
intermediate cipher key, IK.sub.2' is the intermediate integrity
key, KDF is the key generation algorithm, SQN is a latest sequence
number, ANT is the access type identifier, CK is an initial cipher
key, IK is an initial integrity key, AK is an anonymity key,
CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3,
f4, and f5 are generation algorithms, and .sym. means an exclusive
OR operation.
[0374] The processor 801 generates an EMSK' based on the following
formula: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is
an extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0375] The processor 801 generates the anchor key based on the
following formula: anchor key=KDF(EMSK', SNT), where anchor key is
the anchor key, and SNT is the operator type identifier.
[0376] In some possible implementations, the processor 801
generates the intermediate key based on the following formula:
(CK.sub.2', IK.sub.2')=KDF(SQN.sym.AK, SNT, CK.parallel.IK), where
(CK.sub.2', IK.sub.2') is the intermediate key, CK.sub.2' is the
intermediate cipher key, IK.sub.2' is the intermediate integrity
key, KDF is the key generation algorithm, SQN is a latest sequence
number, SNT is the operator type identifier, CK is an initial
cipher key, IK is an initial integrity key, AK is an anonymity key,
CK=f3(RAND), IK=f4(RAND), AK=f5(RAND), RAND is a random number, f3,
f4, and f5 are generation algorithms, and .sym. means an exclusive
OR operation.
[0377] The processor 801 generates an EMSK' based on the following
formula: EMSK'=PRF'(IK.sub.2'.parallel.CK.sub.2'), where EMSK' is
an extended master session key, (IK.sub.2', CK.sub.2') is the
intermediate key, IK.sub.2' is the intermediate integrity key,
CK.sub.2' is the intermediate cipher key, and .parallel. means
concatenation, indicating that characters on both sides of the
symbol are connected in series.
[0378] The processor 801 generates the anchor key based on the
following formula: anchor key=KDF(EMSK', ANT), where anchor key is
the anchor key, and ANT is the access type identifier.
[0379] A person skilled in the art should understand that the
embodiments of the present disclosure may be provided as a method,
a system, or a computer program product. Therefore, embodiments of
the present disclosure may be in a form of hardware, software, or
with a combination of software and hardware. Moreover, the present
disclosure may use a form of a computer program product that is
implemented on one or more computer-usable storage media (including
but not limited to a disk memory, a CD-ROM, an optical memory, and
the like) that include computer-usable program code.
[0380] The embodiments of the present disclosure is described with
reference to the flowcharts and/or block diagrams of the method,
the device (system), and the computer program product. It should be
understood that computer program instructions may be used to
implement each process and/or each block in the flowcharts and/or
the block diagrams and a combination of a process and/or a block in
the flowcharts and/or the block diagrams. These computer program
instructions may be provided for a general-purpose computer, a
dedicated computer, an embedded processor, or a processor of any
other programmable data processing device to generate a machine,
such that the instructions executed by a computer or a processor of
any other programmable data processing device generate an apparatus
for implementing a function in one or more processes in the
flowcharts and/or in one or more blocks in the block diagrams.
[0381] These computer program instructions may also be stored in a
computer readable memory that can instruct the computer or any
other programmable data processing device to work in a manner, such
that the instructions stored in the computer readable memory
generate an artifact that includes an instruction apparatus. The
instruction apparatus implements a function in one or more
processes in the flowcharts and/or in one or more blocks in the
block diagrams.
[0382] These computer program instructions may also be loaded onto
a computer or another programmable data processing device, such
that a series of operations and steps are performed on the computer
or the other programmable device, thereby generating
computer-implemented processing. Therefore, the instructions
executed on the computer or the other programmable device provide
steps for implementing a function in one or more processes in the
flowcharts and/or in one or more blocks in the block diagrams.
[0383] A person skilled in the art can make various modifications
and variations to the present disclosure without departing from the
spirit and scope of the present disclosure. The present disclosure
is intended to cover these modifications and variations provided
that they fall within the scope of protection defined by the
following claims and their equivalent technologies.
* * * * *