WO2019023632A1 - Modèle de clé de sécurité pour prendre en charge une double connectivité - Google Patents

Modèle de clé de sécurité pour prendre en charge une double connectivité Download PDF

Info

Publication number
WO2019023632A1
WO2019023632A1 PCT/US2018/044178 US2018044178W WO2019023632A1 WO 2019023632 A1 WO2019023632 A1 WO 2019023632A1 US 2018044178 W US2018044178 W US 2018044178W WO 2019023632 A1 WO2019023632 A1 WO 2019023632A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
node
radio bearer
key
bearer
Prior art date
Application number
PCT/US2018/044178
Other languages
English (en)
Inventor
Suresh P. Nair
Henri Koskinen
Original Assignee
Nokia Technologies Oy
Nokia Usa Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy, Nokia Usa Inc. filed Critical Nokia Technologies Oy
Publication of WO2019023632A1 publication Critical patent/WO2019023632A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation

Definitions

  • Wireless communication systems can support multiple radio access technologies (RATs).
  • RATs radio access technologies
  • Examples of the RATs that are supported in multi-RAT systems include Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Fifth Generation (5G), as well as wireless local area networks that operate according to IEEE 802.1 1 standards and Wi-Fi.
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • 5G Fifth Generation
  • Wireless local area networks that operate according to IEEE 802.1 1 standards and Wi-Fi.
  • UE User equipment
  • Dual connectivity allows a user equipment to communicate concurrently with base stations or access points that operate according to two separate RATs.
  • a multiple Rx/Tx UE is configured to utilise radio resources provided by two distinct schedulers in two different nodes connected via non-ideal backhaul, one providing E-UTRA access and the other one providing neighbour cell relation (NR) access.
  • One scheduler is located in a master node (MN) and the other scheduler is located in a secondary node (SN).
  • MN and SN are connected via a network interface and at least the MN is connected to the core network.
  • the MN initiates a connection with the UE and subsequently adds the SN based on UE measurements of candidate nodes.
  • the MN then provides information to the UE indicating an identifier of the SN and other configuration parameters.
  • FIG. 1 is a block diagram of a first communication system that implements dual connectivity and a second communication system that implements dual connectivity according to some embodiments.
  • FIG. 2 illustrates a user plane radio protocol architecture for MCG, MCG split, SCG and SCG split bearers in MR-DC with an evolved packet core (EPC) as in EN-DC according to some embodiments.
  • EPC evolved packet core
  • FIG. 3 illustrates a user plane radio protocol architecture for MCG, MCG split, SCG and SCG split bearers in MR-DC with 5GC as in NGEN-DC or NE-DC.
  • FIG. 4 illustrates a radio protocol architecture that allocates a different security key for each bearer according to some embodiments.
  • FIG. 5 illustrates a conventional key model
  • FIG. 6 illustrates a key model that is used to implement allocation of a different security key for each bearer according to some embodiments.
  • FIG. 7 is a block diagram of a dual connectivity transmitter that encrypts information using keys that are allocated on a per-bearer basis according to some embodiments.
  • FIG. 8 is a block diagram of a dual connectivity receiver that decrypts information using keys that are allocated on a per-bearer basis according to some embodiments.
  • FIG. 9 is a block diagram of a dual connectivity transmitter that implements an integrity protection algorithm to generate message authentication codes using keys that are allocated on a per-bearer basis according to some embodiments.
  • FIG. 10 is a block diagram of a dual connectivity receiver that implements an integrity protection algorithm to verify the integrity of received message based on appended message authentication codes that are generated using keys that are allocated on a per-bearer basis according to some embodiments.
  • FIG. 1 1 is a flow diagram of a method of generating encryption and integrity keys on a per- bearer basis according to some embodiments.
  • FIG. 12 is a flow diagram of a method of selectively rekeying security keys for a radio bearer in response to handover of radio bearer according to some embodiments.
  • FIG. 13 is a block diagram of a communication system that allocates keys to radio bearers on a per-bearer basis in a dual connectivity scenario according to some embodiments.
  • Dual connectivity is supported by a corresponding radio bearer architecture.
  • a set of serving cells for a UE is partitioned into two subsets: a Master Cell Group (MCG) containing the serving cells of a master node (referred to herein as an MeNB) and a MCG containing the serving cells of a master node (referred to herein as an MeNB) and a MCG containing the serving cells of a master node (referred to herein as an MeNB) and a Master Cell Group (MCG) containing the serving cells of a master node (referred to herein as an MeNB) and a master node (referred to herein as an MeNB) and a master node (referred to herein as an MeNB) and a MCG containing the serving cells of a master node (referred to herein as an MeNB) and a MCG containing the serving cells of a master node (referred to herein as an MeNB) and a MCG containing the serving cells of a master node (referred to here
  • the nodes that operate as the master node (MN) or the secondary node (SN) may be either an LTE eNB or a 3GPP-New Radio (NR) gNB, independently of each other. Messages or packets transmitted or received by the MN and SN are
  • the bearer architecture supports four different types of radio bearers: (1) an MCG bearer that is anchored in the MN, (2) a split MCG that is anchored in the MN and includes lower layers in the MN and SN to allow duplicate transmission of radio resource control (RRC) and data radio bearer (DRB) packet data unit (PDUs) via a direct path through the MN and an additional path through the SN, (3) an SCG bearer that is anchored in the SN, and (4) a split SCG bearer that is anchored in the SN and includes lower layers in the MN and SN to allow duplicate transmission of RRC and DRB PDUs via a direct path through the SN and an additional path through the MN.
  • RRC radio resource control
  • DRB data radio bearer
  • Security is conventionally provided for dual connectivity using a first security key for the MCG and a second security key for the SCG.
  • managing two types of keys distributed over four types of radio bearers is complex.
  • One option is to allocate a different key to each network termination point such as the packet data convergence protocol (PDCP) layers in the MCG and SCG.
  • PDCP packet data convergence protocol
  • the MCG and split MCG bearers use a first security key and the SCG and split SCG bearers use a second security key. Rekeying occurs in response to the bearer changing from the MCG to the SCG and vice versa, which causes a temporary disruption of services to the user equipment.
  • Bearer changes between the MCG and the SCG are expected to occur relatively frequently and therefore frequent rekeying and reduction in the customer experience due to frequent data/link disruption are expected in this option. Moreover, rekeying would be required for bearer changes between the MCG and the SCG even if the MCG and SCG bearers are terminated in a PDCP layer hosted by the same central unit (CU) entity in a cloud-based system.
  • Another option is to allocate different keys based on the bearer type. For example, MCG bearers would use the first security key and SCG bearers would use the second security key. Both split MCG and split SCG bearers could use the second security key because the second security key is generated by the MeNB.
  • This approach reduces the amount of rekeying (relative to the first option) because the first security key is used for the MCG, split MCG, and split SCG bearers.
  • bearer changes between the MCG bearer and the SCG bearer would still result in rekeying even if the MCG and SCG bearers are terminated in a PDCP layer hosted by the same CU.
  • FIGs 1 -13 disclose embodiments of techniques that reduce rekeying due to bearer changes, particularly in cloud deployments, by allocating a different key to each bearer in a dual connectivity system, regardless of the type of bearer.
  • an integrity key and an encryption key are derived from the key of a first radio bearer to support secure communication between a user equipment and a first base station (such as a gNB or an eNB).
  • the first radio bearer is a first type and is terminated by a PDCP layer that is implemented in a first cell group.
  • the first radio bearer can be an MCG bearer that is terminated by a PDCP in an MCG.
  • the first radio bearer is subsequently modified to a different type of radio bearer.
  • the first radio bearer can be modified to a split MCG bearer, a split SCG bearer, or an SCG bearer that is terminated by a PDCP in an SCG.
  • the modification occurs in response to the user equipment adding a dual connectivity link to a second base station in a second cell group having a second type that is different than the first type.
  • the first radio bearer is therefore terminated by a different PDCP layer implemented in the second cell group.
  • rekeying is not performed in response to the modification of the first radio bearer and the first radio bearer retains the previously derived integrity key and encryption key.
  • the termination point of the first radio bearer can move from a PDCP layer in an MCG to a PDCP layer in an SCG while retaining the same integrity key and encryption key.
  • Some embodiments of the techniques disclosed herein therefore reduce or eliminate rekeying due to the move of a termination point of a radio bearer between PDCP entities implemented in the same central unit (CU) of a cloud architecture that implements lower layers in distributed units (DU).
  • CU central unit
  • DU distributed units
  • FIG. 1 is a block diagram of a first communication system 100 that implements dual connectivity and a second communication system 105 that implements dual connectivity according to some embodiments.
  • dual connectivity refers to a capability that permits a user equipment with multiple transceivers (or combinations of transmitters and receivers) to maintain a connected state and utilize resources provided by two distinct schedulers that are located in separate base stations or eNodeBs, which are connected via a non-ideal backhaul interface such as an X2 interface.
  • the first communication system 100 implements a control plane architecture to support E-UTRAN New Radio-Dual Connectivity (EN-DC) and the second communication system 105 implements a control plane architecture for multi-RAT Dual Connectivity (MR-DC).
  • EN-DC E-UTRAN New Radio-Dual Connectivity
  • MR-DC multi-RAT Dual Connectivity
  • the first communication system 100 includes a master base station (MeNB) 1 10, a secondary base station (SgNB) 1 15, and a user equipment 120 that is configured to support dual connectivity with the master and secondary base stations 1 10, 1 15.
  • the master base station 1 10 is connected to the secondary base station 1 15 by an interface 125 such as an X2-c interface.
  • the user equipment 120 is connected to the master base station 1 10 and the secondary base station by corresponding interfaces 126, 127, such as Uu interfaces.
  • the master base station 1 10 maintains a radio resource control (RRC) state 130, the secondary base station 1 15 maintains an RRC state 135, and the user equipment maintains an RRC state 140.
  • RRC radio resource control
  • the second communication system 105 includes a master node 145, a secondary node 150, and the user equipment 155.
  • the master node 145 is connected to the secondary node 150 by an interface 160 such as an Xn-C interface.
  • the user equipment 155 is connected to the master node 150 and the secondary node 155 via corresponding interfaces 161 , 162, such as Uu interfaces.
  • the master node 145 maintains an RRC state 165 and the secondary node 150 maintains an RRC state 170.
  • the user equipment 155 maintains a single RRC state that is based on the RRC state 165 and a single control plane connection 175 towards a Core Network.
  • Each of the radio nodes 145, 150, 155 has its own RRC entity (E-UTRA version if the node is an eNB or new radio, NR, version if the node is a gNB), which can generate RRC packet data units (PDUs) to be sent to the user equipment 120, 155.
  • the RRC PDUs generated by the secondary base station 1 15 or the secondary node 150 can be transported via the corresponding master base station 1 10 or master node 145 to the corresponding user equipment 120, 155.
  • the master base station 110 or master node 145 sends the initial SN RRC configuration via MCG signalling radio bearer (SRB), but subsequent reconfigurations may be transported via master base station 1 10, the master node 145, the secondary base station 1 15, or the secondary node 150.
  • SRB MCG signalling radio bearer
  • the master base station 1 10 or master node 145 does not modify the configuration of the corresponding user equipment 120, 155 provided by the secondary base station 1 15 or the secondary node 150.
  • Some embodiments of the user equipment 120, 155 are configured to establish a signalling radio bearer (SRB) with the secondary base station 1 15 or the secondary node 150 (e.g., a SCG SRB) to enable RRC PDUs for the secondary base station 1 15 or the secondary node 150 to be sent directly between the user equipment 120, 155 and the secondary base station 1 15 or the secondary node 150.
  • SRB signalling radio bearer
  • the RRC PDUs for the secondary base station 1 15 or the secondary node 150 are transported directly to the user equipment 120, 155 for SN RRC reconfiguration not requiring any coordination with the master base station 1 10 or master node 145.
  • Measurement reporting for mobility within the secondary base station 1 15 or the secondary node 150 can be done directly from the user equipment 120, 155 to the secondary base station 115 or the secondary node 150 if a SCG SRB is configured.
  • An MCG split SRB is supported for all MR-DC options, allowing duplication of RRC PDUs generated by the master node 145, via the direct path over the interface 161 and via the secondary node 150.
  • An SCG split SRB is supported in some embodiments.
  • FIG. 2 illustrates a user plane radio protocol architecture 200 for MCG, MCG split, SCG and SCG split bearers in MR-DC with an evolved packet core (EPC) as in EN-DC according to some embodiments.
  • the architecture 200 includes a master node (MN) 205 and a secondary node (SN) 210 that are interconnected by an interface 215 such as an X2 interface.
  • the MN 205 and SN 210 in the radio protocol architecture 200 include
  • the MN 205 and SN 210 in the radio protocol architecture 200 also include corresponding lower layers such as radio link control (RLC) 230, 235 layers and media access control (MAC) layers 240, 245.
  • the architecture 200 supports bearers 250, 255 that are terminated by the MN PDCP layer 220 and bearers 260, 265 that are terminated by the SN PDCP layer 225.
  • the bearers 250, 255 include an MCG bearer 250 and an MCG split bearer 255 that uses lower layers in both the MN 205 and the SN 210.
  • the bearers 260, 265 include an SCG bearer 260 and an SCG split bearer 265 that uses lower layers in both the MN 205 and the SN 210.
  • FIG. 3 illustrates a user plane radio protocol architecture 300 for MCG, MCG split, SCG and SCG split bearers in MR-DC with 5GC as in NGEN-DC or NE-DC.
  • the architecture 200 includes a master node (MN) 305 and a secondary node (SN) 310 that are interconnected by an interface 315 such as an X2 interface.
  • the MN 305 and SN 310 in the radio protocol architecture 300 include corresponding service data adaptation protocol (SDAP) layers 320, 325 that map between quality-of-service flows and radio bearers.
  • SDAP service data adaptation protocol
  • the MN 305 and SN 310 in the radio protocol architecture 300 also include corresponding PDCP layers 330, 335, RLC layers 340, 345, and MAC layers 350, 355.
  • the architecture 300 supports bearers 360, 365 that are terminated by the MN PDCP layer 330 and bearers 370, 375 that are terminated by the SN PDCP layer 335.
  • the bearers 360, 365 include an MCG bearer 360 and an MCG split bearer 365 that uses lower layers in both the MN 305 and the SN 310.
  • the bearers 370, 375 include an SCG bearer 370 and an SCG split bearer 375 that uses lower layers in both the MN 305 and the SN 310.
  • the radio protocol architecture that a particular radio bearer uses depends on how the radio bearer is set up. As discussed herein, there are four bearer types in some embodiments: MCG bearer, MCG split bearer, SCG bearer and SCG split bearer. An SCG split bearer is not supported for NE-DC.
  • Security keys are allocated to provide secure communication in the different architectures 200, 300.
  • a different key can be allocated per network termination point, i.e. one for all MCG bearers and MCG-anchored split bearers and another one for all SCG bearers and SCG-anchored split bearers.
  • a different key can be allocated per bearer type, e.g., 3 separate keys for MCG, SCG and Split Bearers.
  • a different key can be allocated for each bearer.
  • the first option allocating a different key per network termination point, makes the UE sensitive to the PDCP termination point on the network.
  • MCG and MCG split bearers use the key KeNB.
  • the SCG and SCG split bearers use the key S-KeNB. If the bearer changes from MCG to SCG, the UE would have to rekey. Rekeying results in temporary disruption of services to the UE. Since this bearer change is expected more often in EN-DC, this scheme would result in frequent rekeying and customer experience with frequent data/link disruption. Even if the MCG and SCG bearers are terminated in a PDCP layer hosted by a same central unit (CU) entity, this would still require the rekeying.
  • CU central unit
  • the second option allocating a different key per bearer type, makes the UE sensitive to bearer type.
  • the MCG bearers use the key K e NB
  • the SCG bearers use the key S-K e NB
  • the MCG split + SCG split bearer use the key S-K e NB, which is possible because MeNB has access to S-K e NB.
  • the MCG and SCG bearers have the same disadvantage as in the first option, but bearers are maintained as split bearers, which provides an advantage. If the bearers assigned to the UE are split bearers, this wouldn't result in overly frequent rekeying. Hence performance-wise this looks better than the first option.
  • MeNB Since MeNB has access to both keys ⁇ ⁇ ⁇ and S-KeNB, it is possible for MeNB to use S-KeNB for MCG split bearer and SeNB can uses KeNB for all its bearers. There are no new security concerns that result from allocating a different key per bearer type. The other option of using KeNB for SCG split bearer is not possible because SCG has no access to it. Thus, using S- ⁇ ⁇ ⁇ for both split bearers and non-split SCG bearers effectively reduces frequent rekeying.
  • FIG. 4 illustrates a radio protocol architecture 400 that allocates a different security key for each bearer according to some embodiments.
  • the radio protocol architecture 400 is implemented as a cloud network that includes a central unit 405 and multiple distributed units 410, 41 1 . Although two distributed units 410, 41 1 are shown in FIG. 4, some embodiments of the radio protocol architecture 400 include more than two distributed units associated with the central unit 405. Moreover, the radio protocol architecture 400 can also include or be associated with other central units.
  • the radio protocol architecture 400 is used to implement a master node and a secondary node to support dual connectivity.
  • a PDCP 415 for the master node and a PDCP 420 for the secondary node are implemented in the central unit 405.
  • Lower layers for the master node and the secondary node are implemented in the distributed units 410, 41 1 .
  • the RLC layers 425, 430 for the master node are implemented in the distributed unit 410, as is the MCG MAC layer 435 for the master node.
  • the RLC layers 440, 445 for the secondary node are implemented in the distributed unit 41 1 , as is the SCG MAC layer 450.
  • a first bearer type 451 is an MCG bearer
  • a second bearer type 452 is a split MCG bearer type
  • a third bearer type 453 is a split SCG bearer type
  • a fourth bearer type 454 is an SCG bearer type.
  • a radio bearer that is initially established as one of the bearer types 451-454 can subsequently be modified into another one of the bearer types 451 -454, e.g. , in response to handover of a user equipment or a measurement report received from the user equipment.
  • security keys are allocated on a per-bearer basis in response to establishing a radio bearer to support communication with the user equipment.
  • an encryption key and an integrity key are generated for the user equipment based on an identifier of the radio bearer.
  • the encryption key and the integrity key are maintained even if the type of the radio bearer is modified, e.g., from an MCG bearer to a split MCG bearer.
  • rekeying is performed in response to the radio bearer being handed off to a PDCP that is not implemented in the CU 405.
  • some embodiments of the CU 405 host two PDCPs 415, 420 belonging to MCG and SCG.
  • the CU can also host addition PDCPs, which are not shown in FIG. 4 in the interest of clarity.
  • the DUs 410, 41 1 and the cell identifier are different because different radios are being used for the two PDCPs 425, 420, e.g., radios that operate according to LTE and 5G. In this scenario, it doesn't make much sense to differentiate the bearers based on whether the bearers are MCG or SCG, and to make the keys different based on this split. At the same time, it cannot be assumed that all implementations would use a CU-DU split.
  • FIG. 5 illustrates a conventional key model 500.
  • the key model 500 illustrates keys that are shared by a universal subscriber identity module (USIM), an authentication center (AuC), a UE, a home subscription server (HSS), a mobility
  • USIM universal subscriber identity module
  • AuC authentication center
  • HSS home subscription server
  • a master key (K) 505 is shared by the USIM and AuC, as indicated by the layer 510.
  • the master key 505 is used to generate the keys CK, IK 515 that are shared by the UE and the HSS, as indicated by the layer 520.
  • the keys 515 are used to generate a key (K_ASME) 525 that is shared by the UE and MME, as indicated by the layer 530.
  • the key 525 is used to generate a nonaccess stratum encryption key (K_NAS_ENC) 535 and an NAS integrity key (K_NAS_INT) 540.
  • the key 525 is also used to generate an eNodeB key (K_ENB/NH) 545, which is used to generate integrity and encryption keys 550, 555, 560, 565 that are shared by the UE and eNodeB, as indicated by the layer 570.
  • K_ENB/NH eNodeB key
  • FIG. 6 illustrates a key model 600 that is used to implement allocation of security keys for each bearer on a per-bearer basis according to some embodiments.
  • the key model 600 differs from the conventional key model 500 by including an encryption key (enc) and an integrity key (int) for each radio bearer.
  • the key model 600 illustrates keys that are shared by a universal subscriber identity module (USIM), an authentication center (AuC), a UE, a home subscription server (HSS), an access/mobility management function (AMF), and a base station (eNB).
  • a master key (K) 605 is shared by the USIM and AuC, as indicated by the layer 610.
  • the master key 605 is used to generate the keys CK, IK 615 that are shared by the UE and the HSS, as indicated by the layer 620.
  • the keys 615 are used to generate a key (K_AMF) 625 that is shared by the UE and MME, as indicated by the layer 630.
  • the key 625 is used to generate a nonaccess stratum encryption key (K_NAS_ENC) 635 and an NAS integrity key (K_NAS_INT) 640.
  • K_ENB/NH eNodeB key
  • the eNodeB key 645 is also used to generate per-bearer integrity and encryption keys.
  • the eNodeB key 645 is used to generate integrity and encryption keys 660, 665 for a first radio bearer (K_RB1_INT, K_RB1_ENC), integrity and encryption keys 670, 675 for a first radio bearer (K_RB2_INT, K_RB2_ENC), and additional integrity and encryption keys for any additional radio bearers.
  • the integrity and encryption keys 650, 655, 660, 665, 670, 675 are shared by the UE and eNodeB, as indicated by the layer 680.
  • FIG. 7 is a block diagram of a dual connectivity transmitter 700 that encrypts information using keys that are allocated on a per-bearer basis according to some embodiments.
  • the transmitter 700 is implemented in some embodiments of the nodes 1 10, 1 15, 120, 145, 150, 155 shown in FIG. 1.
  • the transmitter 700 receives a plaintext message 705 that includes information that is to be transmitted over an interface to a receiver.
  • the transmitter 700 includes a New Radio (NR) encryption algorithm (NEA) 710 that generates encryption information that is used to encrypt the plaintext message 705.
  • NR New Radio
  • NDA New Radio
  • the NEA 710 implements an algorithm that generates the encryption information based on an encryption key (K_DRB_ID_ENC) 715 that is generated for the radio bearer that is carrying the plaintext message 705.
  • the encryption key 715 is known by the transmitter 700 and a corresponding receiver. Allocation of the encryption key 715 to the radio bearer is performed based on the key model 600 shown in FIG. 6.
  • Some embodiments of the NEA 710 receive other information as input that is used to generate the encryption information. For example, the NEA 710 receives a value of a PDCP counter 720, an identifier of the radio bearer (DRB) 725, information indicating a direction 730 of the transmission, and a length 735 of the plaintext message 705.
  • DRB radio bearer
  • FIG. 8 is a block diagram of a dual connectivity receiver 800 that decrypts information using keys that are generated on a per-bearer basis according to some embodiments.
  • the receiver 800 is implemented in some embodiments of the nodes 1 10, 1 15, 120, 145, 150, 155 shown in FIG. 1.
  • the receiver 800 receives a ciphertext message 805 that includes encrypted information received from a transmitter such as the transmitter 700 shown in FIG. 7.
  • the receiver 800 includes an NEA 810 that generates encryption information that is used to decrypts the ciphertext message 805.
  • the NEA 810 implements an algorithm that generates the encryption information based on an encryption key (K_DRB_ID_ENC) 815 that is generated for the radio bearer that is carrying the ciphertext message 805.
  • the encryption key 815 is known to the receiver 800 and a corresponding transmitter such as the transmitter 700 shown in FIG. 7. Allocation of the encryption key 815 to the radio bearer is performed based on the key model 600 shown in FIG. 6.
  • Some embodiments of the NEA 810 receive other information as input that is used to generate the encryption information.
  • the NEA 810 receives a value of a PDCP counter 820, an identifier of the DRB 825, information indicating a direction 830 of the transmission, and a length 835 of the ciphertext message 805.
  • the encryption information generated by the NEA 810 is provided to a combiner 840, which combines the encryption information with the ciphertext message 805 to generate a plaintext message 845.
  • FIG. 9 is a block diagram of a dual connectivity transmitter 900 that implements an integrity protection algorithm to generate message authentication codes using keys that are allocated on a per-bearer basis according to some embodiments.
  • the transmitter 900 is implemented in some embodiments of the nodes 1 10, 1 15, 120, 145, 150, 155 shown in FIG. 1.
  • the transmitter 900 includes an NR integrity algorithm (NIA) 905 that generates a message authentication code such as a 32-bit message authentication code (MAC-I/NAS-MAC) 910.
  • NIA 905 implements an algorithm that generates the message authentication code 910 based on an integrity key (K_DRB_ID_INT) 915 that is allocated to the radio bearer.
  • K_DRB_ID_INT integrity key
  • the integrity key 915 is known to the transmitter 900 and a corresponding receiver. Allocation of the integrity key 915 to the radio bearer is performed based on the key model 600 shown in FIG. 6. Some embodiments of the NIA 905 receive other information as input that is used to generate the message authentication code 910. For example, the NIA 905 receives a value of a PDCP counter 920, a message 925 (the message authentication code 910 will be appended to the message 925), information indicating a direction 930 of the transmission, and an identifier 935 of the radio bearer. The message authentication code 910 is then appended to the message 925 when sent so that a corresponding receiver is able to verify the integrity of the message 925.
  • FIG. 10 is a block diagram of a dual connectivity receiver 1000 that implements an integrity protection algorithm to verify the integrity of received message based on appended message authentication codes that are generated using keys that are allocated on a per-bearer basis according to some embodiments.
  • the receiver 1000 is implemented in some embodiments of the nodes 1 10, 1 15, 120, 145, 150, 155 shown in FIG. 1.
  • the receiver 1000 includes an NIA 1005 that generates a message authentication code such as a 32-bit message authentication code (XMAC-I/XNAS-MAC) 1010.
  • the NIA 1005 implements an algorithm that generates the message authentication code 1010 based on an integrity key (K_DRB_ID_INT) 1015 that is allocated to the radio bearer.
  • K_DRB_ID_INT integrity key
  • the integrity key 1015 is known to the receiver 1000 and a corresponding transmitter such as the transmitter 900 shown in FIG. 9. Allocation of the integrity key 1015 to the radio bearer is performed based on the key model 600 shown in FIG. 6.
  • Some embodiments of the NIA 1005 receive other information as input that is used to generate the message authentication code 1010. For example, the NIA 1005 receives a value of a PDCP counter 1020, a received message 1025 having an appended message authentication code, information indicating a direction 1030 of the transmission, and an identifier 1035 of the radio bearer. The message authentication code 1010 is then compared to the message authentication code that is appended to the received message 1025.
  • Integrity of the received message 1025 is verified if the computed message authentication code 1010 is the same as the received message authentication code.
  • the receiver 1000 computes the expected message authentication code (XMAC-I/XNAS-MAC) 1010 on the message 1025 received in the same way as the sender computed its message authentication code on the message sent and verifies the data integrity of the message by comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC.
  • FIG. 1 1 is a flow diagram of a method 1 100 of generating encryption and integrity keys on a per-radio bearer basis according to some embodiments.
  • the method 1 100 is implemented in some embodiments of the architectures 100, 105 shown in FIG. 1.
  • Generation of the encryption and integrity keys according to the method 1 100 is performed based on the key model 600 shown in FIG. 6.
  • the encryption and integrity keys are generated based on a key (K_AMF) 1 105 that is shared by the UE and AMF, such as the key 625 in the layer 630 shown in FIG. 6.
  • a base station key (such as a key K_GNB 645 shown in FIG. 6) is generated based on the key 1 105.
  • Some embodiments of the base station key are generated according to the following key generation algorithm:
  • K gNB KDF ⁇ K AMFl NH/NCC
  • K C u Keys generated according to the above key generation algorithm can be used in cloud radio access network (RAN) implementations, e.g., if the gNB is implemented in a split CU and DU architecture, Kcu is treated as the KgNB.
  • RAN radio access network
  • a key that is specific to the radio bearer (K_DRB_ID) is generated using the base station key (or other keys, e.g., in cloud RAN implementations).
  • the per-bearer integrity key and per-bearer encryption key are generated using the bearer-specific key.
  • Some embodiments of the integrity and encryption keys are generated for the radio bearer using an encryption algorithm that receives input including the bearer-specific key generated at block 1 1 15, an identifier of the encryption or integrity algorithm, and an algorithm identifier:
  • K-DRBid-upenc KDF (K DRBid , N - UP - Encryption Algorithm, Algorithm - ID)
  • KDRBid-upint KDF(K DRBid , N - UP - Integrity Algorithm, Algorithm - ID)
  • the per-bearer encryption and integrity keys are then used to encrypt plaintext messages and provide integrity verification for the encrypted messages that are transmitted using the associated radio bearer.
  • FIG. 12 is a flow diagram of a method 1200 of selectively rekeying security keys for a radio bearer in response to handover of radio bearer according to some embodiments.
  • the method 1200 is implemented in some embodiments of the radio protocol architecture 400 shown in FIG. 4.
  • generation of the encryption and integrity keys for rekeying is performed according to the method 1 100 is performed based on the key model 600 shown in FIG. 6.
  • a radio bearer is established to convey information between a dual connectivity user equipment and a master cell group or a secondary cell group.
  • the type of bearer can include an MCG bearer, a split MCG bearer, and SCG bearer, or a split SCG bearer.
  • the MCG PDCP and the SCG PDCP are implemented in a central unit (CU) of a distributed cloud network.
  • the method 1200 can be implemented in some embodiments of the radio protocol architecture 400 shown in FIG. 4.
  • security keys are generated on a per-bearer basis to the radio bearer.
  • an encryption key and an integrity key are generated to the radio bearer according to the method 1 100 shown in FIG. 1 1 .
  • the encryption key and the integrity key are then used to perform encryption and integrity verification for messages transmitted between the user equipment and the network using the established radio bearer.
  • the encryption key and the integrity key are maintained in the event that the type of the radio bearer is modified, e.g., if an MCG bearer is modified to a split MCG bearer.
  • Some embodiments of the user equipment and the base stations or eNodeBs in the master cell group for the secondary cell group implement some embodiments of the transmitters 700, 900 and the receivers 800, 1000 shown in FIGs. 7-10.
  • a termination point of the radio bearer is moved, e.g., by handing off from one base station to another base station.
  • the user equipment determines whether the PDCP that terminates the radio bearer subsequent to the move is in the same CU as the PDCP that terminated the radio bearer prior to the hand off. For example, the MCG PDCP is in the same CU as the SCG PDCP and so moving the radio bearer from the MCG PDCP to the SCG PDCP would remain in the same CU. If the PDCP that terminates the radio bearer after the move is not in the same CU as the previous PDCP, the method 1200 flows to block 1225. If the PDCP that terminates the radio bearer after the handoff is in the same CU as the previous PDCP, the method flows to the block 1230.
  • the security keys for the radio bearer are rekeyed in response to the handover to a PDCP that is not in the same CU as the previous PDCP. For example, new encryption and integrity keys can be allocated to the radio bearer in response to the handover.
  • the security keys for the radio bearer are maintained in response to the handover, thereby avoiding the frequent rekeying that can occur due to handover is between PDCP that are within the same CU in a distributed cloud network.
  • FIG. 13 is a block diagram of a communication system 1300 that allocates keys to radio bearers on a per-bearer basis in a dual connectivity scenario according to some
  • the communication system 1300 includes a first base station (eNB) 1305 that operates according to a first RAT such as LTE, a second base station (gNB) 1310 that operates according to a second RAT such as 5G, and a user equipment 1315 that operates in a dual connectivity mode to support concurrent radio bearers 1320, 1325 with the first base station 1305 and the second base station 1310.
  • the first and second base stations 1305, 1310 are depicted as separate entities in FIG. 13.
  • the radio bearers 1320, 1325 can be supported by a single base station.
  • the radio bearers 1320, 1325 can operate according to the same RAT in some embodiments.
  • the base station 1305 includes a transceiver 1322 that is configured to support radio bearers according to the first RAT.
  • the transceiver 1322 is a terminating endpoint of the radio bearer 1320.
  • the base station 1305 also includes a processor 1325 and a memory 1330.
  • the processor 1325 can be used to execute instructions stored in the memory 1330 and to store information in the memory 1330 such as the results of the executed instructions.
  • the memory 1330 is also configured to store security keys that are allocated to radio bearers supported by the transceiver 1322.
  • the memory 1330 can store a first encryption key and a first integrity key for the radio bearer 1320.
  • the base station 1305 can therefore implement portions of some embodiments of the method 1100 shown in FIG. 1 1 and some embodiments of the method 1200 shown in FIG. 12.
  • the base station 1310 includes a transceiver 1335 that is configured to support radio bearers according to the second RAT.
  • the transceiver 1335 is a terminating endpoint of the second radio bearer 1325.
  • the base station 1310 also includes a processor 1340 and a memory 1345.
  • the processor 1340 can be used to execute instructions stored in the memory 1345 and to store information in the memory 1345 such as the results of the executed instructions.
  • the memory 1345 is also configured to store security keys that are allocated to the radio bearers supported by the transceiver 1335.
  • the memory 1345 can store a second encryption key and a second integrity key for the radio bearer 1325.
  • the user equipment 1315 uses a split bearer type in which case the radio bearer 1320 and the radio bearer 1325 represent different legs of the same radio bearer. In that case, the first and second encryption keys are the same and the first and second integrity keys are the same.
  • the base station 1310 can therefore implement portions of some embodiments of the method 1 100 shown in FIG. 11 and some embodiments of the method 1200 shown in FIG. 12.
  • the user equipment 1315 includes a transceiver 1350 that is connected to an antenna 1355 to transmit and receive signals over the air interface.
  • the transceiver implements two or more radios 1360, 1365 that operate according to the first and second RAT, respectively.
  • the radios 1360, 1365 can therefore be configured as terminating endpoints of the radio bearers 1320, 1325, respectively.
  • the user equipment 1315 also includes a processor 1370 and a memory 1375.
  • the processor 1370 can be used to execute instructions stored in the memory 1375 and to store information in the memory 1375 such as the results of the executed instructions.
  • the memory 1375 is also configured to store first and second security keys that are allocated to the different radio bearers.
  • the memory 1375 can store first and second encryption keys and first and second integrity keys for the radio bearers 1320, 1325, respectively.
  • the user equipment 1315 can therefore implement portions of some embodiments of the method 1 100 shown in FIG. 1 1 and some embodiments of the method 1200 shown in FIG. 12.
  • certain aspects of the techniques described above may implemented by one or more processors of a processing system executing software.
  • the software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium.
  • the software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above.
  • the non-transitory computer readable storage medium can include, for example, a magnetic or optical disk storage device, solid state storage devices such as Flash memory, a cache, random access memory (RAM) or other non-volatile memory device or devices, and the like.
  • the executable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.
  • a computer readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and/or data to the computer system.
  • Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc , magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media.
  • optical media e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc
  • magnetic media e.g., floppy disc , magnetic tape, or magnetic hard drive
  • volatile memory e.g., random access memory (RAM) or cache
  • non-volatile memory e.g., read-only memory (ROM) or Flash memory
  • MEMS microelect
  • the computer readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).
  • NAS network accessible storage

Abstract

Un support radio est établi pour une communication avec un équipement utilisateur qui est configuré pour une connectivité double au niveau d'un premier nœud qui met en œuvre un premier ordonnanceur et d'un second nœud qui met en œuvre un second ordonnanceur. Les premier et second nœuds sont connectés par une interface. Un type du support radio est sélectionné parmi un premier type qui utilise uniquement des ressources du premier nœud, un deuxième type qui utilise uniquement des ressources du second nœud et un troisième type qui utilise des ressources des premier et second nœuds. Une clé de chiffrement et une clé d'intégrité sont générées pour le support radio sur la base d'un identifiant du support radio.
PCT/US2018/044178 2017-07-28 2018-07-27 Modèle de clé de sécurité pour prendre en charge une double connectivité WO2019023632A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762538485P 2017-07-28 2017-07-28
US62/538,485 2017-07-28

Publications (1)

Publication Number Publication Date
WO2019023632A1 true WO2019023632A1 (fr) 2019-01-31

Family

ID=63245029

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/044178 WO2019023632A1 (fr) 2017-07-28 2018-07-27 Modèle de clé de sécurité pour prendre en charge une double connectivité

Country Status (1)

Country Link
WO (1) WO2019023632A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220030425A1 (en) * 2020-07-27 2022-01-27 Samsung Electronics Co., Ltd. Methods and systems for deriving cu-up security keys for disaggregated gnb architecture

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security architecture (Release 15)", 3GPP DRAFT; 33401-F00, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. ;20170601, 12 June 2017 (2017-06-12), XP051310313, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_87_Ljubljana/SA/> [retrieved on 20170612] *
3GPP RAN2: "LS to SA3 on security keys in EN-DC and actions upon DRB IP check failure", 3GPP DRAFT; S3-171722 R2-1707501, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Dali,China; 20170807 - 20170811, 5 July 2017 (2017-07-05), XP051310337, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_88_Dali/Docs/> [retrieved on 20170705] *
ERICSSON: "On the different bearer options", 3GPP DRAFT; R2-1704414 - ON THE DIFFERENT BEARER OPTIONS, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Hangzhou, China; 20170515 - 20170519, 14 May 2017 (2017-05-14), XP051274987, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN2/Docs/> [retrieved on 20170514] *
NOKIA ET AL: "Security Handling for UP in NR", 3GPP DRAFT; R2-1700068 SECURITY HANDLING, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Spokane, USA; 20170117 - 20170119, 17 January 2017 (2017-01-17), XP051210655, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN2/Docs/> [retrieved on 20170117] *
NOKIA: "Further comments to Discussion on incoming LS R2-1706151 Questions on ENDC security questions", 3GPP DRAFT; S3-172069-FURTHER COMMENTS TO NOKIA S3-171814 DISCUSSION ON R2-1706151-ENDC SECURITY QUESTIONS V1, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Dali City, China; 20170807 - 20170811, 2 August 2017 (2017-08-02), pages 1 - 6, XP051312544, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_88_Dali/Docs/> [retrieved on 20170802] *
QUALCOMM INCORPORATED: "Proposed inputs to the security algorithms at PDCP layer", 3GPP DRAFT; S3-170954, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Busan, Korea; 20170327 - 20170331, 4 April 2017 (2017-04-04), XP051258620, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_86b_Busan/Docs/> [retrieved on 20170404] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220030425A1 (en) * 2020-07-27 2022-01-27 Samsung Electronics Co., Ltd. Methods and systems for deriving cu-up security keys for disaggregated gnb architecture
US11722890B2 (en) * 2020-07-27 2023-08-08 Samsung Electronics Co., Ltd. Methods and systems for deriving cu-up security keys for disaggregated gNB architecture

Similar Documents

Publication Publication Date Title
US11785510B2 (en) Communication system
CN109922051B (zh) 用于使能用于enb间的传输的安全通信的方法和系统
KR102040036B1 (ko) 보안 패스워드 변경 방법, 기지국, 및 사용자 기기
US20170359719A1 (en) Key generation method, device, and system
CN110637451B (zh) 用在通信网络中的网络节点、通信设备和操作其的方法
WO2015176462A1 (fr) Procédés et dispositifs de traitement pour migration et de migration de supports radio à double connexion
JP6633745B2 (ja) 通信ネットワークにおいて使用するためのノード、および、それを動作させるための方法
CN109246696B (zh) 密钥处理方法以及相关装置
US20170164244A1 (en) Path switching method, mobility anchor, and base station
US9801052B2 (en) Method and system for securing control packets and data packets in a mobile broadband network environment
WO2019158117A1 (fr) Système et procédé pour assurer la sécurité dans un système de communication sans fil avec séparation de plan utilisateur
CN114765502A (zh) 消息处理方法、装置、终端及网络侧设备
WO2019023632A1 (fr) Modèle de clé de sécurité pour prendre en charge une double connectivité
US10412056B2 (en) Ultra dense network security architecture method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18756033

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18756033

Country of ref document: EP

Kind code of ref document: A1