Patent Application
20220191696
The present invention relates to a wireless communication system and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The disclosure has particular but not exclusive relevance to improvements relating to multi-SIM devices (multi-SIM user equipment) in the so-called ‘5G’ (or ‘Next Generation’) systems.
The latest developments of the 3GPP standards are the so-called ‘5G’ or ‘New Radio’ (NR) standards which refer to an evolving communication technology that is expected to support a variety of applications and services such as Machine Type Communications (MTC), Internet of Things (IoT) communications, vehicular communications and autonomous cars, high resolution video streaming, smart city services, and/or the like. 5G technologies enable network access to vertical markets and support network (RAN) sharing for offering networking services to third parties and for creating new business opportunities. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core (NGC) network.
Whilst a base station of a 5G/NR communication system is commonly referred to as a New Radio Base Station (‘NR-BS’) or as a ‘gNB’ it will be appreciated that they may be referred to using the term ‘eNB’ (or 5G/NR eNB) which is more typically associated with Long Term Evolution (LTE) base stations (also commonly referred to as ‘4G’ base stations). 3GPP Technical Specification (TS) 38.300 V15.5.0 and TS 37.340 V15.5.0 define the following nodes, amongst others:
3GPP also defined the so-called ‘Xn’ interface as the network interface between neighbouring NG-RAN nodes.
End-user communication devices are commonly referred to as User Equipment (UE) which may be operated by a human or comprise automated (MTC/IoT) devices. There have been multi-SIM capable mobile devices (UEs) in the market in the past years. They provide the ability to use and manage multiple subscriptions in a single device. With the conventional mobile phone that can accommodate only 1 SIM card, a user needs to carry multiple devices when he/she uses multiple subscriptions. One notable example is a business person who carries multiple mobile phones, one for personal use and another for business use (e.g. company-provided phone). In such scenario, multi-SIM capable device provides a convenience to carry only one mobile phone even in such situation.
Typically, a multi-SIM capable mobile device is equipped with two SIM card slots, thus it is also generally referred to as a ‘dual-SIM phone’. In another UE implementation, the mobile device is equipped with one SIM card slot and another SIM functionality is embedded in hardware (‘eSIM’). The mobile device may have an individual IMEI for each SIM, or a single IMEI common to all SIMs in the mobile device. One example of having single IMEI common to all SIMs is when a single UICC card contains multiple USIM applications.
Thus far, the operation and behavior of these multi-SIM capable mobile devices are not standardized in 3GPP and thus they are implementation (manufacturer) dependent. The exact TX and RX operation, and simultaneous use of two subscriptions are largely driven by the hardware implementation. GSMA document in [10] defines three types of multi-SIM devices:
The differences of these operational modes depend on the number of TX and RX chain in the transceiver implementation in the mobile device. The first and second cases implies single TX/RX chain, and the third case implies dual RX/TX chains, respectively.
Subscriptions, call events, billing, and management of the SIM cards are completely independent because the network is not aware of such multi-SIM capable devices. Therefore, use of such device leads to operational implications, for example, how the UE reacts if call events on these subscriptions occurs simultaneously, such as: 1) if two subscriptions are paged simultaneously or within a brief interval; 2) if one subscription is paged while a call is in progress for the other subscription. There are likely other scenarios that impact the behavior of multi-SIM device involving multiple subscriptions.
In addition, GSMA has a set of requirements for multi-SIM devices [10] as follows:
The above requirements imply that the network needs to be aware of multi-SIM devices and need to be able to correlate multiple IMSIs that belong to the same device so that service to all IMEIs can be blocked or ongoing call can be terminated. The reason of blocking may include, for example, a lost or stolen mobile device, a customer being delinquent in subscription fee payment, etc.
One possible outcome of standardization is to define coordination at the system level of these multiple subscriptions within such multi-SIM capable devices. This may include defining mechanisms and procedures to make the network to be aware of such devices in order to allow the network to coordinate call processing events and thus avoid problems or enhance user experience.
In order for the network to become aware of such multi-SIM capable devices, there needs to be a mechanism in place to identify such devices and verify the associated subscriptions together. However, because the usage and operation of these multi-SIM devices has not been standardized, no such mechanism exists yet to achieve such identification and verification. A few possible mechanisms for the network to be aware of the multi-SIM devices are: 1) UE to spontaneously report whether the mobile device is equipped with the multi-SIM capability or not; or 2) the network to query the mobile device and the device responds back whether the device is equipped with the multi-SIM capability or not. However, such mechanism has potential security issues. It is because the network relies on the information provided by the UE and blindly accepts the information simply because the network has no way to verify whether the information provided by the mobile device is real or not. This situation opens possible opportunities by fake devices to attack the network. In other words, this situation leaves a potential security threat where rogue devices are able to: 1) report multi-SIM capability even when it is not; and/or 2) intentionally report incorrect subscription information associated with the SIM cards inserted in the mobile device in order to make the network believe the association of subscriptions being in a single mobile device.
The inventors have realized that there needs to be a security mechanism in place to verify multi-SIM capable UEs and unequivocally identify and verify the subscription information of the SIM cards inserted in the mobile device. In other words, the network needs to be able to verify if and what subscription information resides in the SIM cards in a multi-SIM mobile device.
Accordingly, the present invention seeks to provide methods and associated apparatus that address or at least alleviate (at least some of) the following issues:
In one aspect, the invention provides a method performed by a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the method comprising: receiving, from a network node, at least a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; deriving a first third order token (TAB) by encrypting the received first token (TA) using a second cryptographic key (KB, KNASenc_B) associated with the second SIM; and sending said third order token (TAB) to the network node.
In one aspect, the invention provides a method performed by a network node communicating with a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the method comprising: sending, to said UE, at least a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; and receiving, from said UE, a first third order token (TAB) derived by the UE by encrypting the first token (TA) using a second cryptographic key (KB, KNASenc_B) associated with the second SIM.
In one aspect, the invention provides a method performed by a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the method comprising: receiving, from a network node, a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNAsenc_A) associated with the first SIM; decrypting said first token (TA) using said first cryptographic key (KA, KNASenc_A) associated with the first SIM to derive the seed token (TS); deriving a second token (TB) by encrypting the derived seed token (TS) using a second cryptographic key (KB, KNASenc_A) associated with the second SIM; and sending said second token (TB) to the network node.
In one aspect, the invention provides a method performed by a network node communicating with a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the method comprising: sending, to said UE, a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; and receiving, from said UE, a second token (TB) derived by the UE by decrypting said first token (TA) using said first cryptographic key (KA, KNASenc_A) associated with the first SIM to derive the seed token (TS) and by encrypting the derived seed token (TS) using a second cryptographic key (KB, KNAsenc_B) associated with the second SIM.
In one aspect, the invention provides a method performed by a network node associated with a first mobile network operator (MNO) communicating with a user equipment (UE) comprising a first Subscriber Identity Module (SIM) associated with the first MNO and a second SIM associated with a second MNO, the method comprising: performing a registration procedure with the UE using the first SIM; obtaining information indicating that the UE includes said second SIM associated with the second MNO; and receiving, from a node of said second MNO, information indicating whether or not the second SIM associated with the second MNO is blocked.
In one aspect, the invention provides a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, a controller, and a transceiver, wherein the controller is configured to: receive, from a network node, at least a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; derive a first third order token (TAB) by encrypting the received first token (TA) using a second cryptographic key (KB, KNAsenc_B) associated with the second SIM; and send said third order token (TAB) to the network node.
In one aspect, the invention provides a network node communicating with a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the network node comprising a controller and a transceiver, wherein the controller is configured to: send, to said UE, at least a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNAsenc_A) associated with the first SIM; and receive, from said UE, a first third order token (TAB) derived by the UE by encrypting the first token (TA) using a second cryptographic key (KB, KNAsenc_B) associated with the second SIM.
In one aspect, the invention provides a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, a controller, and a transceiver, wherein the controller is configured to: receive, from a network node, a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; decrypt said first token (TA) using said first cryptographic key (KA, KNASenc_A) associated with the first SIM to derive the seed token (TS); derive a second token (TB) by encrypting the derived seed token (TS) using a second cryptographic key (KB, KNASenc_B) associated with the second SIM; and send said second token (TB) to the network node.
In one aspect, the invention provides a network node communicating with a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the network node comprising a controller and a transceiver, wherein the controller is configured to: send, to said UE, a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; and receive, from said UE, a second token (TB) derived by the UE by decrypting said first token (TA) using said first cryptographic key (KA, KNASenc_A) associated with the first SIM to derive the seed token (TS) and by encrypting the derived seed token (TS) using a second cryptographic key (KB, KNASenc_B) associated with the second SIM.
In one aspect, the invention provides a network node associated with a first mobile network operator (MNO) communicating with a user equipment (UE) comprising a first Subscriber Identity Module (SIM) associated with the first MNO and a second SIM associated with a second MNO, the network node comprising a controller and a transceiver, wherein the controller is configured to: perform a registration procedure with the UE using the first SIM; obtain information indicating that the UE includes said second SIM associated with the second MNO; and receive, from a node of said second MNO, information indicating whether or not the second SIM associated with the second MNO is blocked.
In one aspect, the invention provides a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the UE comprising: means for receiving, from a network node, at least a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; means for deriving a first third order token (TAB) by encrypting the received first token (TA) using a second cryptographic key (Ks, KNAsenc_B) associated with the second SIM; and means for sending said third order token (TAB) to the network node.
In one aspect, the invention provides a network node communicating with a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the network node comprising: means for sending, to said UE, at least a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; and means for receiving, from said UE, a first third order token (TAB) derived by the UE by encrypting the first token (TA) using a second cryptographic key (KB, KNASenc_B) associated with the second SIM.
In one aspect, the invention provides a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the UE comprising: means for receiving, from a network node, a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNAsenc_A) associated with the first SIM; means for decrypting said first token (TA) using said first cryptographic key (KA, KNASenc_A) associated with the first SIM to derive the seed token (TS); and means for deriving a second token (TB) by encrypting the derived seed token (TS) using a second cryptographic key (KB, KNASenc_B) associated with the second SIM; and means for sending said second token (TB) to the network node.
In one aspect, the invention provides a network node communicating with a user equipment (UE) comprising at least a first Subscriber Identity Module (SIM) and a second SIM, the network node comprising: means for sending, to said UE, a first token (TA) derived from a seed token (TS) using a first cryptographic key (KA, KNASenc_A) associated with the first SIM; and means for receiving, from said UE, a second token (TB) derived by the UE by decrypting said first token (TA) using said first cryptographic key (KA, KNASenc_A) associated with the first SIM to derive the seed token (TS) and by encrypting the derived seed token (TS) using a second cryptographic key (KB, KNAsenc_B) associated with the second SIM.
In one aspect, the invention provides a network node associated with a first mobile network operator (MNO) communicating with a user equipment (UE) comprising a first Subscriber Identity Module (SIM) associated with the first MNO and a second SIM associated with a second MNO, the network node comprising: means for performing a registration procedure with the UE using the first SIM; means for obtaining information indicating that the UE includes said second SIM associated with the second MNO; and means for receiving, from a node of said second MNO, information indicating whether or not the second SIM associated with the second MNO is blocked.
Aspects of the invention extend to corresponding systems and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.
Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the invention independently of (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually.
Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:
Overview Under the 3GPP standards, a NodeB (or an ‘eNB’ in LTE, ‘gNB’ in 5G) is a base station via which communication devices (user equipment or ‘UE’) connect to a core network and communicate to other communication devices or remote servers. Communication devices might be, for example, mobile communication devices such as mobile telephones, smartphones, smart watches, personal digital assistants, laptop/tablet computers, web browsers, e-book readers, and/or the like. Such mobile (or even generally stationary) devices are typically operated by a user (and hence they are often collectively referred to as user equipment, ‘UE’) although it is also possible to connect IoT devices and similar MTC devices to the network. For simplicity, the present application will use the term base station to refer to any such base stations and use the term mobile device or UE to refer to any such communication device.
Although for efficiency of understanding for those of skill in the art, the invention will be described in detail in the context of a 3GPP system (a 5G network), the principles of the invention can be applied to other systems in which slice scheduling is performed.
In this network, users of mobile devices 3 (UEs) can communicate with each other and other users via respective base stations 5 and a core network (CN) 7 using an appropriate 3GPP radio access technology (RAT), for example, an E-UTRA and/or 5G RAT. It will be appreciated that a number of base stations 5 form a (radio) access network or (R)AN. As those skilled in the art will appreciate, whilst one mobile device 3 and one base station 5 are shown in
Each base station 5 controls one or more associated cells (either directly or via other nodes such as home base stations, relays, remote radio heads, distributed units, and/or the like). A base station 5 that supports E-UTRA/4G protocols may be referred to as an ‘eNB’ and a base station 5 that supports NextGeneration/5G protocols may be referred to as a ‘gNBs’. It will be appreciated that some base stations 5 may be configured to support both 4G and 5G, and/or any other 3GPP or non-3GPP communication protocols.
The mobile device 3 and its serving base station 5 are connected via an appropriate air interface (for example the so-called ‘Uu’ interface and/or the like). Neighbouring base stations 5 are connected to each other via an appropriate base station to base station interface (such as the so-called ‘X2’ interface, ‘Xn’ interface and/or the like). The base station 5 is also connected to the core network nodes via an appropriate interface (such as the so-called ‘S1’, ‘N1’, ‘N2’, ‘N3’ interface, and/or the like).
The core network 7 typically includes logical nodes (or ‘functions’) for supporting communication in the telecommunication system 1. Typically, for example, the core network 7 of a ‘Next Generation’/5G system will include, amongst other functions, control plane functions (CPFs) 10 and user plane functions (UPFs) 11. A so-called Home Subscriber Server (HSS) 15 is also provided in (or coupled to) the core network 7. Effectively, the HSS 15 is a database that contains user-related and subscriber-related information. The HSS 15 also provides support for mobility management, call and session setup, user authentication, and access authorisation.
From the core network 7, connection to an external IP network 20 (such as the Internet) is also provided (e.g. via a gateway).
In this example, the mobile device 3 is a multi-SIM device which supports two USIMs (although it will be appreciated that the mobile device 3 may also support three or more USIMs, if appropriate).
Beneficially, the components of this system 1 are configured to verify whether a particular mobile device 3 supports (uses) multiple USIMs, and to identify unequivocally the identities of the subscription information associated with these USIMs.
In more detail, in one embodiment, verification of the USIMs in the UE 3 is carried out using the permanent keys associated with the USIMs. In this case, the UE 3 and the network (an appropriate node of the core network 7) perform a cryptographic operation using subscription-unique information to establish that the USIMs in the multi-SIM device are indeed in the device. This involves cross-application of the unique permanent keys from multiple USIMs in a series of cryptographic operations in order to generate a transformed value as a way to fuse elements of multiple subscription information together. Beneficially, such cryptographic operation using the unique keys from multiple subscriptions assures that the cryptographically transformed value is uniquely derived from the specific USIMs and that the USIMs are in the UE 3.
In another embodiment, verification of the USIMs in the UE 3 is carried out using dynamically created keys (instead of the permanent keys). In this case, the UE 3 and the network perform an appropriate cryptographic operation using dynamically-created security context associated with the subscriptions associated with USIMs (after the subscriptions are fully authenticated) in order to determine whether the USIMs are indeed in the UE 3.
In another embodiment, verification of the USIMs in the UE 3 is carried out over multiple NAS connections. In this case, the UE 3 and the network perform an appropriate cryptographic operation using the NAS security context of the subscription (after the subscription associated with the USIM is fully authenticated) in order to determine whether the specific USIMs are indeed in the UE 3.
In yet another embodiment, verification of the USIMs in the UE 3 is carried out based on exchanging USIM information between different MNOs (e.g. the MNOs associated with the USIM(s) in the UE 3/USIM(s) previously used by the UE 3). Specifically, when an MNO obtains subscriber information of the USIM associated with that MNO and another USIM, the MNO sends its subscriber information, such as IMSI, IMEI, and operator-specific status information to the MNO that the other USIM is a subscriber of. The operator-specific status information may include, for example, information identifying whether the subscriber is barred from service and/or the like. The exchange and sharing of subscriber information between the MNOs allows the MNOs to apply the same handling to the user of these subscriptions, such as termination of any ongoing call, or blocking/unblocking of service.
The components of the system 1 may also be configured to perform re-verification (e.g. UE initiated or timer based) of the USIM association, when appropriate. In this case, re-verification may be initiated by the UE 3 when the UE 3 detects a change of at least one USIM. When the UE 3 indicates a change of USIM to the network, the UE 3 and the network proceed to perform an appropriate procedure (e.g. one of the procedures described above) to re-verify the USIM association and update any mapping information held in the network. Alternatively, or additionally, the USIM association may have an associated validity period and re-verification of the USIM association may be performed upon expiry of the validity period (which may be determined using a timer and/or the like).
User Equipment (UE)
The UE 3 may comprise a multi-SIM device in which case it may be equipped with one or more transceiver circuits 31, depending on hardware implementation. When present, such multiple transceiver circuits 31 enable simultaneous connection using multiple SIMs. Further details of an exemplary multi-SIM capable UE 3 are shown in
The term “UE” refers to the mobile phone in general, which includes at least the following components:
The term ‘SIM’ generally refers to the application in the UICC card that is used in 2G GSM mobile system. The term ‘USIM’ generally refers to the application in the UICC card that is used in 3G (UMTS), 4G (LTE), and 5G systems. In addition, ‘eSIM’ is a SIM functionality embedded in the ME 30 itself, rather than being provided using a physical (removable) UICC card. In most technical context, these terms are interchangeable, and the term ‘SIM’ is more generic. From the perspective of the present disclosure, the terms ‘SIM’, ‘USIM’, and ‘eSIM’ are used interchangeably. The SIM and USIM application and eSIM contain the credentials, such as the long term identifier (IMSI in 3GPP) and long term secret key.
In this disclosure, either ‘ME’, ‘mobile device’, or simply ‘device’ is used to refer to the same entity, namely the mobile handset in general for any generation of technology. In addition, ‘SIM’ or ‘USIM’ are used in this disclosure depending on the context. However, they generally refer to the applications that reside in the UICC.
(R)AN Node
Core network node
Assumption/Trust Model
For the purpose of this disclosure, the following assumptions apply:
Solution 1: Verification of the USNs in the ME
This solution (embodiment) aims to address the issue of identification of USIMs inserted in a multi-SIM capable mobile device. The following is a detailed description of this solution and some possible variants thereof.
Solution 1, Variant 1: Verification of the USIMs in the ME Using Permanent Keys
An exemplary procedure for the CN 7 to verify the UE's 3 (ME's 30) multi-SIM capability and identify subscriber information associated with the USIMs 100 inserted in the ME 30 is illustrated in
1. In the first step of this procedure, the UE 3 attaches to the core network using one of the subscriptions associated with one of the USIMs 100 in it according to the defined 3GPP procedure, such as in TS 23.401 [1] or TS 23.502 [3]. In this figure, the UE 3 is attached to the network using the subscription associated with USIM 100A (‘USIM-A’) as an example. As the result of this step, the UE 3 as a whole (including both the ME 30 and the subscription associated with USIM-A 100A) is fully authenticated by the network.
2. Next, the UE 3 attaches to the network using another subscription associated with another USIM 100 in it according to applicable 3GPP procedures. In this example, the UE 3 is attached to the network using the subscription associated with USIM-B 100B as an example. As a result of this step, the UE 3 as a whole (including both the ME 30 and the subscription associated with USIM-B 100B) is fully authenticated by the network.
3. [Alternative procedure 1] The UE 3 reports to the CN 7 (AMF, for example) that it has another USIM 100 (because the ME 30 is a multi-SIM capable device) by sending an appropriately formatted ‘UE Capability Information’ message, for example. In the example shown in the figure above, the UE 3 communicates using the first USIM's 100A subscription. At this time, the UE 3 provides the second USIM's 100B subscription information, e.g. the IMSI of USIM-8100B. Alternatively, the UE 3 may communicate using the second USIM's 100B subscription and provide the first USIM's 100A subscription information.
4. [Alternative procedure 2] Alternative to step 3, the CN 7 (AMF, for example) queries the UE 3 regarding the UE's multi-SIM capability by sending an appropriately formatted ‘UE Capability Query’ message, for example. The UE 3 responds to the CN 7 by sending an appropriate ‘UE Capability Response’ message, for example. In the example shown in
It should be noted that, if appropriate, either one of the alternative procedures described in steps 3 and 4 may be performed as part of the attach procedure (steps 1 and 2).
5. The CN 7 (AMF, for example) generates a seed token (TS) using a Token Generation Function (TGF). An exemplary Token Generation Function is shown in
6. The CN 7 (AMF, for example) requests the server for subscription data (e.g. HSS 15, HLR or UDM, and so on) to transform the seed token by sending an ‘Encryption request’ message, for example. In the exemplary message shown in this figure, the CN 7 sends the seed token (TS), and identities of both USIM-A 100A and USIM-8100B. The identity of these two USIMs 100A, 100B may comprise for example an IMSI and/or the like.
7. The server for subscription data (UDM, for example) looks up the subscription database for the subscribers corresponding to both USIM-A 100A and USIM-B 100B, and locates the permanent keys for these subscribers. In one example, using the permanent key for these subscribers, the server for subscription data encrypts the seed token (TS), and generates a pair of 2nd order tokens (TA and TB).
In this example, the 2rd order token generation function is implemented using the following formulas:
T
A
=Enc(TS,KA)
T
B
=Enc(TS,KB)
, where
It will be appreciated that other suitable formulas/token generation functions may also be used.
8. The server for subscription data returns the pair of 2nd order tokens (TA and TB) to the CN 7 (AMF, for example) e.g. by sending an appropriately formatted ‘Encryption response’ message.
9. The CN 7 (AMF, for example) sends the pair of 2nd order tokens (TA and TB) to the UE 3 e.g. by sending an appropriate NAS message.
10. The ME 30 part of the UE 3 requests the first USIM 100A to transform the received token (TB), and requests the USIM-8100B to transform the received token (TA) e.g. by sending respective ‘Encryption request’ messages to the USIMs 100A, 100B. It should be noted here that the token transformed by the server for subscription data using subscription B's permanent key (KB) is sent to the USIM-A 100A. Similarly, the token transformed by the server for subscription data using subscription A's permanent key (KA) is sent to the USIM-B 100B. Beneficially, this ‘swapping operation’ allows the UE 3 (ME 30 and USIMs 100A/100B collectively) to generate a set of 3rd order tokens that are generated using two permanent keys in two different order.
11. In one example, the first USIM 100A encrypts the received token (TB) using its own permanent key ‘K’ (KA) stored in USIM-A 100A. Similarly, the second USIM 100B encrypts the received token (TA) using its permanent key ‘K’ (KB) stored in USIM-8100B. Then both USIM-A 100A and USIM-8100B provide the generated 3rd order token to the ME 30 by sending an appropriately formatted ‘Encryption response’ message, for example.
In this example, the 3rd order token generation function is implemented using the following formulas:
T
BA
=Enc(TB,KA)
T
AB
=Enc(TA,KB)
, where
It will be appreciated that other suitable formulas/token generation functions may also be used.
12. The ME 30 sends the pair of 3rd order tokens (TAB, TBA) to the CN 7 (AMF, for example) using e.g. an appropriate NAS message (sent via the base station 5).
13. The CN 7 (AMF, for example) requests the server for subscription data (UDM, for example) to de-transform the pair of 3rd order tokens (TAB, TBA) back to the 1st order token. In one example, the CN 7 conveys the 3rd order token pair to the subscription data server along with the identity of USIM-A 100A and USIM-B 100B in a specific order so that the subscription data server can unambiguously identify the sequence the de-transformation is to be carried out (for example, as discussed in step 14 below).
14. The server for subscription data (UDM, for example) de-transforms the received pair of 3rd order tokens (TAB, TBA). In one example, the server for subscription data decrypts the 3rd order token back to 2rd order token, then use this 2nd order token as input and decrypts it to yield the 1st order token.
In this example, the de-generation function is implemented using the following formulas:
T
X
=Dec(Dec(TAB,KB),KA)
T
Y
=Dec(Dec(TBA,KA),KB)
, where
It should be noted that the order of transformation in the earlier steps are un-done in the exact reverse order. In any case, it will be appreciated that other suitable formulas/de-generation functions may also be used.
15. The server for subscription data (UDM, for example) returns the de-transformed 1st order token (TX, TY) to the CN 7 (AMF, for example).
16. The CN 7 (AMF, for example) checks if (TX=TY=TS) is true or not. If true, the CN 7 accepts the result and acknowledge that the first USIM 100A and the second USIM 100B are indeed in the same ME 30. Otherwise, the CN 7 considers the USIM information previously provided by the UE 3 in step 3 and 4 does not accurately reflect the actual USIMs 100 in the ME 30.
Solution 1, Variant 2: Verifying USIMs in the ME Using Dynamically Created Keys
As an alternative to Solution 1 variant 1, the following mechanism uses dynamically created cryptographic keys instead of permanent keys.
An exemplary procedure in accordance with this variant is illustrated in
1. The UE attaches to the core network using one of the subscriptions associated with one of the USIMs 100 in it according to the defined 3GPP procedure, such as in TS 23.401 [1] or TS 23.502 [3]. In this figure, the UE 3 is attached to the network using the first USIM's 100A subscription as an example. At this time, the UE 3 as a whole (including both the ME 30 and the subscription in USIM-A 100A) is fully authenticated by the network, and NAS security context is established in the CN 7 (AMF, for example) and the UE 3 for this subscription. The security context includes information such as the NAS ciphering algorithm, NAS integrity protection algorithm, NAS confidentiality protection (ciphering) key, NAS integrity protection key, etc.
2. The UE 3 also attaches to the network using another subscription associated with another USIM 100 in it according to the defined 3GPP procedure. In this figure, the UE 3 is attached to the network using USIM-B's 100B subscription as an example. At this time, the UE 3 as a whole (including both the ME 30 and the subscription in USIM-B 100B) is fully authenticated by the network, and NAS security context is established in the CN 7 (AMF, for example) and the UE 3 for this subscription. The security context includes information such as the NAS ciphering algorithm, NAS integrity protection algorithm, NAS confidentiality protection (ciphering) key, NAS integrity protection key, etc. 3. [Alternative procedure 1] The UE 3 reports to the CN 7 (AMF, for example) that it has another USIM (because the ME 30 is a multi-SIM capable device) by sending an appropriately formatted ‘UE Capability Information’ message and/or the like. In the example shown in
Alternatively, the UE 3 may communicate using the second USIM's 100B subscription and provide the first USIM's 100A subscription information. 4. [Alternative procedure 2] Alternative to step 3, the CN 7 (AMF, for example) queries the UE 3 regarding the UE's multi-SIM capability by sending an appropriate message, e.g. a ‘UE Capability Query’ message. The UE 3 responds to the CN 7 by sending an appropriately formatted ‘UE Capability Response’ message and/or the like. In the example shown in
It should be noted that the alternative procedures in step 3 and 4 above may be performed as part of the attach procedure (in steps 1 and 2).
5. The CN 7 (AMF, for example) generates a seed token (TS) using an appropriate Token Generation Function (TGF), e.g. using the Token Generation Function shown in
6. The CN 7 (AMF, for example) looks up the NAS security context corresponding to the first USIM 100A and the second USIM 100B, and locates the NAS ciphering keys for these subscribers. In one example, using the NAS ciphering key for these subscribers, the CN 7 encrypts the seed token (TS), and generates a pair of 2rd order tokens (TA and TB).
In this example, the 2rd order token generation function is implemented using the following formulas:
T
A
=Enc(TS,KNASenc_A)
T
B
=Enc(TS,KNASenc_B)
, where
It will be appreciated that other suitable formulas/token generation functions may also be used.
7. The CN 7 (AMF, for example) sends the pair of 2nd order tokens (TA and TB) to the UE 3 by sending a NAS message, for example.
8. The ME 30 part of the UE 3 transforms the received 2nd order tokens (TA and TB) and generates a 3rd order token. It should be noted here that the ME 30 transforms the 2nd order token that is generated by the CN 7 (AMF, for example) using subscription B's derived NAS security context key (for example, KNASenc_B) in step 6, using subscription A's derived NAS security context key (for example, KNASsenc_A). Similarly, the ME 30 transforms the 2nd order token that is generated by the CN using subscription A's derived NAS security context key (for example, KNASenc_A) in step 6, using subscription B's derived NAS security context key (for example, KNASenc_B). This ‘swapping operation’ allows the ME 30 to generate a set of 3rd order tokens that are generated using two derived NAS security context keys in two different order.
In this example, the 3rd order token generation function is implemented using the following formulas:
T
BA
=Enc(TB,KNASenc_A)
T
AB
=Enc(TA,KNASenc_B)
, where
9. The ME 30 sends the pair of 3rd order token (TAB, TBA) to the CN 7 (AMF, for example) by sending an appropriate NAS message, for example.
10. The CN 7 (AMF, for example) de-transforms the received pair of 3rd order tokens (TAB, TBA). In one example, the CN 7 decrypts the 3rd order token back to 2nd order token, then uses this 2nd order token as input and decrypts it to yield the 1st order token. In this case, the CN 7 applies the de-transformation in the reverse order as was done in step 6 and 8.
In this example, the de-generation function is implemented using the following formulas:
T
X
=Dec(Dec(TAB,KNASenc_B),KNASenc_A)
T
Y
=Dec(Dec(TBA,KNASenc_A),KNASenc_B)
, where
11. The CN 7 (AMF, for example) checks if (TX=TY=TS) is true or not. If true, the CN 7 accepts the result and acknowledges that the first USIM 100A and the second USIM 100B are indeed in the same ME 30. Otherwise, the CN 7 considers the USIM information previously provided by the UE 3 in step 3 and 4 does not accurately reflect the actual USIMs 100 in the ME 30.
Solution 1, Variant 3: Verifying USIMs in the ME Using Dynamically Created Keys
As an alternative to Solution 1 variant 1 and variant 2, the following mechanism uses a different cryptographic operation.
An exemplary procedure in accordance with this variant is illustrated in
1-5. These steps are the same as steps 1 to 5 described above with reference to
6. The CN 7 (AMF, for example) looks up the NAS security context corresponding to one of the subscriptions, USIM-A 100A for example, and locates the NAS ciphering key for this subscriber. In one example, using the NAS ciphering key for USIM-A 100A, the CN 7 encrypts the seed token (TS), and generates a 2nd order token (TA). For example, the 2nd order token generation function may be implemented using the formulas shown in step 6 of the second variant.
7. The CN 7 (AMF, for example) sends the 2nd order tokens (TA) to the UE 3 by sending a NAS message, for example.
8. The ME 30 part of the UE 3 transforms the received 2nd order token (TA) and generates a 3rd order token. In one example, the ME 30 first decrypts the received token (TA) using the NAS ciphering key from subscriber A's derived NAS security context key (for example, KNASenc_A).
Following this step, the ME 30 then encrypts the resulting value using the NAS ciphering key from subscriber B's derived NAS security context key (for example, KNASenc_B).
In this example, the 3rd order token generation is implemented using the following formula:
TB=Enc(Dec(TA,KNASenc_A),KNASenc_B)
, where
9. The ME 30 sends the 3rd order token (TB) to the CN 7 (AMF, for example) using e.g. an appropriately formatted NAS message (sent via the base station 5).
10. The CN 7 (AMF, for example) de-transforms the received pair of 3rd order tokens (TB). In one example, the CN 7 decrypts the 3rd order token using subscriber B's NAS ciphering key. In this example, the de-generation function is implemented using the following formula:
T
X
=Dec(TB,KNASenc_B)
, where
11. The CN 7 (AMF, for example) checks if (TX=Ts) is true or not. If true, the CN 7 accepts the result and acknowledge that the first USIM 100A and the second USIM 100B are indeed in the same ME 30. Otherwise, the CN 7 considers the USIM information previously provided by the UE 3 in step 3 and 4 does not accurately reflect the actual USIMs 100 in the ME 30.
Solution 1, Variant 4: Verifying USIMs in the ME Over Multiple NAS Connections
As an alternative to Solution1 variant 1 through 3, the following mechanism uses multiple NAS connections. In this solution variant, transformed tokens are sent between the CN 7 (AMF, for example) and the UE 3 over multiple NAS connections associated with multiple subscriptions.
In this solution variant, as an example, all steps except steps 7, 9, and 10 are the same as the corresponding steps of Solution 1, variant 2 (shown in
1-6. The same as steps 1 to 6 described above with reference to
7. The CN 7 (AMF, for example) sends the 2nd order tokens (TA and TB) to the UE 3 by sending a NAS message over the connection associated with one of the subscriptions, for example the first USIM 100A.
8. The same as step 8 described above with reference to
9. The ME 30 sends the pair of 3rd order tokens (TAB, TBA) to the CN 7 (AMF, for example) by sending a NAS message over the connection associated with the subscription different from the one used in step 7, for example connection using the subscription of USIM-B 100B.
10. The CN 7 (AMF, for example) receives the pair of 3rd order tokens (TAB, TBA) sent over the NAS connections associated with a different subscription from the one sent in step 7, and de-transforms the received pair of 3rd order tokens (TAB, TBA). In one example, the CN 7 decrypts the 3rd order token back to a 2nd order token, then uses this 2nd order token as input and decrypts it to yield the 1st order token. In this case, the CN 7 applies the de-transformation in the reverse order as was done in steps 6 and 8. In this example, the de-generation function is the same as described with reference to step 10 of variant 2 above.
Solution 1, Variant 5: Verifying USIMs in the ME Over Multiple NAS Connections
As an alternative to Solution 1 variants 1 through 4, the following mechanism uses multiple NAS connections. In this solution variant, transformed tokens are sent between the CN 7 (AMF, for example) and the UE 3 over multiple NAS connections associated with multiple subscriptions.
An exemplary procedure in accordance with this variant is illustrated in
1-6. The same as steps 1 to 6 described above with reference to
7. The CN 7 (AMF, for example) sends the 2nd order token (TB) to the UE 3 by sending a NAS message over the connection associated with one of the subscriptions, for example the first USIM 100A. Likewise, the CN 7 also sends the 2nd order token (TA) to the UE 3 by sending a NAS message over the connection associated with another subscription, for example the second USIM 100B. Therefore, the 2nd order token generated by using a NAS key for subscription associated with USIM-A 100A is sent over the connection associated with USIM-B 100B. Similarly, the 2nd order token generated by using a NAS key for subscription associated with USIM-B 100B is sent over the connection associated with USIM-A 100A.
8. The same as step 8 described above with reference to
9. The ME 30 sends the 3rd order token (TBA) to the CN 7 (AMF, for example) by sending a NAS message over the connection associated with the subscription of the first USIM 100A. Similarly, the ME 30 sends the 3rd order token (TAB) to the CN 7 by sending a NAS message over the connection associated with the subscription of the second USIM 100B.
10. The CN 7 (AMF, for example) receives the pair of 3rd order tokens (TAB, TBA) that are separately sent over different NAS connections associated with different subscriptions, for example USIM-A 100A and USIM-B 100B. The CN 7 de-transforms the received pair of 3rd order tokens (TAB, TBA). In one example, the CN 7 decrypts the 3rd order token back to the 2nd order token, then uses this 2nd order token as input and decrypts it to yield the 1st order token. In this case, the CN 7 applies the de-transformation in the reverse order as was done in step 6 and 8. In this example, the de-generation function is the same as described with reference to step 10 of variant 2 above.
Token Generation Function
An exemplary Token Generation Function (TGF) is shown in
In this example, the Token Generation Function uses multiple input parameters such as:
Association Mapping in the Core Network
Using any of the methods described in variants of solution 1, the CN 7 (AMF, for example) is able to verify the multi-SIM devices and their subscription information. Using this information, the CN 7 is able to maintain a mapping table of the multi-SIM devices with the ME 30 hardware itself.
Depending on the ME implementation, the multi-SIM device 30 may have either a common or a unique IMEI for each USIM 100. IMEI is the identity of the device 30 as the hardware. This is illustrated in
Specifically, the left hand side (a) of
In case the device hardware assigns separate unique IMEI value to each USIM 100, the CN 7 (AMF, for example) can trigger multiple identity query procedures to each USIM 100 to obtain all IMEI values in the device. Alternatively, the existing Identification procedure may be expanded so that the UE 3 provides all IMEI values that are assigned to the ME 30 in a single Identity Request and Response message exchange. These procedures establish the identity mapping between the USIM 100 and the IMEI. In addition, the methods described in solution 1 variants allow identification and verification of multiple USIMs 100 within a single device. By combining this information together, the CN 7 can establish the full identity mapping between the USIMs 100 and IMEI(s).
Alternatively, if the attach procedure (as shown in steps 1 and 2 of
Using this mapping information, the set of IMEIs belonging to a single device can be identified to trigger actions in the network, such as blocking service to all subscriptions in a device due to reasons such as lost or stolen device.
An example of the mapping table is shown in
Subscription related information for USIMs 100 contains, for example, administrative information such as whether the subscription associated with a USIM 100 is blocked or not.
What is shown in
Solution 2: Re-Verification of USIMs
This solution (embodiment) aims to address the issue of determining and re-verifying any change of USIMs in a multi-SIM capable mobile device.
The end user can replace the USIM 100 in either SIM slot in the ME 30 at any time. In other words, the USIM association that was previously established in the CN 7 (AMF, for example), as described in solution 1, can become obsolete at any time without the knowledge of the CN 7. Accordingly, solution 2 aims to provide a mechanism to ‘re-sync’ the USIM association in the CN 7 in such situations.
In older feature phones, the SIM slot was typically located behind the battery, thus removal of battery was necessary to replace the USIM card, implying that replacing the USIM cards necessarily require the ME 30 to go through a power cycle (i.e. re-initialization of the ME 30) and have the end user to enter the PIN code to activate the newly inserted USIM card.
However, in the more recent modem smartphones, a USIM card 100 can be removed and inserted without powering down the UE 3. When a new USIM 100 is inserted, the ME 30 queries the end user to enter the associated PIN number. If the correct PIN number is entered, the USIM 100 is activated in the ME 30. Therefore, the ME 30 itself does not necessarily go through a power cycle in modem smartphones.
The differences in ME 30 behaviour related to USIM replacement requires a solution for the CN 7 (AMF, for example) to detect and trigger re-verification of USIM association. In other words, when the previously established USIM association becomes no longer valid, the verification procedure (e.g. as described in solution 1 above) needs to be triggered again in order to keep the USIM association in the ME 30 up-to-date in the network.
The following is a detailed description of this solution and some possible variants thereof.
Solution 2, Variant 1: Re-Verification Based on UE Reporting
In this solution variant, the UE 3 reports a change of USIM pairings to the CN 7 (AMF, for example) whenever this event occurs. A change in USIM pairing may include any of the following scenarios: 1) a new USIM 100 is inserted to an empty slot; 2) a new USIM 100 replaces an existing USIM 100; 3) an existing USIM 100 is removed from a slot (leaving the slot empty); and 4) eSIM is re-programmed. When the ME 30 detects the presence of a USIM 100 in the slot or a change in the eSIM information, the ME 30 and the USIM 100 establish the communication as specified in 3GPP TS 31.101 [8] and TS 31.102 [9].
In scenarios 1), 2), and 4) in the previous paragraph, the insertion of a new USIM 100 or new information in the eSIM triggers an Attach procedure as described in 3GPP TS 23.401 [1] or TS 23.502 [3], for example. At this time, the UE 3 reports the CN 7 of the new association information.
An exemplary procedure for reporting new USIM association information is shown in
1. In this example, both USIM-A 100A and USIM-B 100B are initially in the ME 30 and are attached to the network as defined in 3GPP TS 23.401 [1] or TS 23.502 [3].
2. The end user replaces the USIM-A 100A in slot A with another USIM 100C (denoted as ‘USIM-C’ in
3. The UE 3 and the network completes the successful attach procedure for USIM-C 100C.
4. The UE 3 reports to the CN 7 (AMF, for example) that the USIM association has changed in the ME 30 by sending UE Capability Information message, for example. In the example shown in
5. The CN 7 (AMF, for example) triggers the procedure shown in
6. The CN 7 (AMF, for example) updates the mapping table between the USIM 100 and the device 30 as shown in
Solution 2, Variant 2: Re-Verification Based on Timer Expiration
In this solution variant, the CN 7 (AMF, for example) holds a timer which defines the period for which the CN 7 considers the USIM association to be valid. Upon expiration of this timer, the CN 7 re-initiates the verification procedure as described in solution 1 above.
The exact timer value of this timer can be either static in the system or dynamically configurable based on operator preference, for example.
If neither USIMs 100 is replaced since the last verification as described in solution 1 in this disclosure, then the CN 7 (AMF, for example) arrives at the same conclusion and the same USIM information as the previous verification. On the other hand, if any of the USIM 100 is replaced since the last verification (as described in solution 1 above), then the CN 7 arrives at new association of different USIMs 100. In this case, the CN 7 discards the previous association information and stores the new association information.
An exemplary procedure for a timer based re-verification is shown in
1. As a pre-condition, both the first USIM 100A and the second USIM 100B are in the ME 30 and are attached to the network as defined in 3GPP TS 23.401 [1] or TS 23.502 [3].
2. The CN 7 (AMF, for example) starts a timer (denoted for example as a ‘USIM association timer’) at the end of the verification procedure as described in solution 1 above. The timer may be set to a predetermined starting value and count down to zero or it may be set to zero and count up to a predetermined end value.
3. (optional) The end user replaces the USIM 100 in either slot in the ME 30 with a different USIM 100C (denoted ‘USIM-C’ in
It should be noted that this optional step does not occur if the end user kept the USIMs 100 as-is and thus does not change the USIM 100 in the ME 30.
4. The USIM Association Timer expires (e.g. when an associated timer end value is reached, for example ‘0’ when counting down).
5. The CN 7 (AMF, for example) triggers the re-verification procedure as described in solution 1 above. At this time, if the optional step 3 did not occur, then the CN 7 arrives at the same association of the same USIMs 100 as in the previous verification. However, if the optional step 3 did occur, then the CN 7 arrives at new association of different USIMs 100. At this time, the CN 7 discards the previous USIM association information and stores the new USIM association information.
6. The CN 7 (AMF, for example) updates the mapping table between the USIM 100 and the device as shown in
Solution 3: Verification of USIM Information Through Coordination Across Multiple MNOs
This solution (embodiment) aims to address the issue of identifying USIMs 100 in a multi-SIM device when multiple MNOs are involved. Specifically, this solution allows verification of USIMs 100 by exchanging information across multiple MNOs. This scenario is relevant if the USIMs 100 in the multi-SIM device 30 are subscribed to different MNOs that have business relationship with each other, such as roaming partners in different countries.
For example, MNO-1 in
An exemplary procedure in accordance with this solution is shown in
1. The user is under MNO-1 (USIM-A's H-PLMN) and the UE 3 registers itself with MNO-1 using the first USIM's 100A subscription information. The CN 7 (AMF, for example) in MNO-1 obtains the UE mapping information using Identification procedure as in 3GPP TS 23.401 [2], TS 23.501 [3], TS 24.301 [4], or TS 24.501 [5], for example. In the Identification procedure, the CN 7 queries the IMSI and IMEI of USIM-A 100A, and at least either the IMSI or IMEI of USIM-B 100B. The Identification procedure may be repeated multiple times to query one identity at a time as in the existing specifications in [4] and [5]. Alternatively, the procedure can be expanded to query multiple identities in one request and response message exchange, for example, to query different types of identities from the same subscription (e.g. IMSI and IMEI of USIM-A 100A) or same type of identities from different subscriptions (IMEI of USIM-A 100A and USIM-B 1008), for example.
2. The user moves to an area under MNO-2's network.
3. The UE 3 registers itself with MNO-2 using the second USIM's 100B subscription information. The CN 7 (AMF, for example) in MNO-2 obtains the UE mapping information using Identification procedure as in 3GPP TS 23.401 [2], TS 23.501 [3], TS 24.301 [4], or TS 24.501 [5], for example. In the Identification procedure, the CN 7 queries the IMSI and IMEI of USIM-B 100B, and at least either IMSI or IMEI of USIM-A 100A. The Identification procedure may be repeated multiple times to query one identity at a time as in the existing specifications in TS 24.301 [4] and TS 24.501 [5]. Alternatively, the procedure can be expanded to query multiple identities in one request/response message exchange, for example, to query different types of identities from the same subscription (e.g. IMSI and IMEI of USIM-B 100B) or same type of identities from different subscriptions (IMEI of USIM-A 100A and USIM-B 100B), for example.
In this example, The MNO-2 queries the IMSI of USIM-A 100A. By looking at the PLMN-ID (MCC and MNC) part of the IMSI of MNO-1, the MNO-2 identifies that the MNO-1 needs to be contacted in the following step.
4. MNO-2 communicates with MNO-1 using the UE identities established in step 3, for example, the mapping information between the IMSI and IMEI of USIM-8100B by sending Inter-MNO message, for example. At this time, MNO-2 includes, if applicable, associated subscriber related information, such as whether or not service is being blocked to the subscription in USIM-B 100B, for example, due to lost or stolen device. Similarly, MNO-1 communicates with MNO-2 using the UE identities established in step 1, for example, the mapping information between the IMSI and IMEI of USIM-A 100A by sending Inter-MNO Message, for example. At this time, MNO-1 includes, if applicable, associated subscriber related information, such as service is being blocked to the subscription in USIM-A 100A, for example, due to lost or stolen device. 5. Using the information received in step 4, both MNO-1 and MNO-2 update their own UE ID mapping table, as shown in
6. The MNO-2 takes an appropriate action based on the mapping information established in step 5. In one example, MNO-2 receives that MNO-1 has already blocked the service to the subscription associated with USIM-A 100A. In this case, MNO-2 also applies the same rule and blocks the subscription for USIM-B 100B. In another example, the subscriber related information from MNO-1 indicates that the subscription for USIM-A 100A was formerly blocked but now changed to unblocked. In this case, the MNO-2 also unbiocks the subscription to USIM-B 100B.
Beneficially, the above described exemplary embodiments include, although they are not limited to, one or more of the following functionalities.
Solution 1, Variant 1:
Solution 1, Variant 2, Variant 3:
Solution 1, Variant 4 and Variant 5:
Solution 2, Variant 1:
Solution 2, Variant 2:
Solution 3:
2) The exchange and sharing of subscriber information between the MNOs allows the MNOs to apply the same handling to the user of these subscriptions, such as termination of ongoing call, or blocking or unblocking of service.
Benefits
Some of the benefits associated with the above described embodiments include, although not limited to, one or more of the following:
1. The network can unambiguously identify and verify the identities of the USIMs inserted in the mobile device and correlate them to device identity (IMEI(s)).
2. Using the above described methods, it is not possible for the ME or any 3rd party entity to lie about the identity of the USIMs and the associated subscription. This is ensured by methods such as use of permanent key stored in the USIM and server for subscription data, or use of dynamically derived security context as the result of successful mutual authentication between the network and the UE, to transform a token. In other words, the use of shared secret, which only the legitimate UE (USIMs and ME) and network, can only successfully execute the operation described in this disclosure, thus preventing 3rd party entity to impersonate a subscription or mobile device.
3. The network can correlate the subscriptions associated with USIMs in the mobile device and carry out necessary administrative operation against the user. For example, if one subscription is blocked, then the other subscription in the same mobile device can also be blocked. This way, the above described mechanisms satisfy the relevant GSMA requirements. It will be appreciated that these benefits may be achieved even when the subscriptions of USIMs are from different operators (e.g. roaming partner operators in 2 different countries).
Modifications and Alternatives
Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.
The messages shown in the procedure in
In the above embodiments, the encryption function used in the USIM 100 and the server for subscription data (solution 1 variant 1) or in the ME 30 and the CN 7 (solution 1 variant 2 through variant 6) comprises a symmetric cryptographic function, such as EEA0, EEA1, EEA2, EEA3 as defined in 3GPP TS 33.401 [6] or NEA0, NEA1, NEA2, NEA3 as defined in 3GPP TS 33.501 [7]. Alternatively, it may comprise any other suitable symmetric cryptographic algorithm that is supported in both the USIM 100 and the server for subscription data (in solution 1 variant 1) or the ME 30 and the CN 7 (in solution 1 variant 2 through variant 6).
Further, it will be appreciated that the symmetric cryptographic algorithm used in the USIM 100 and the server for subscription data (solution 1 variant 1) or in the ME 30 and the CN 7 (solution 1 variant 2 through variant 6) may be pre-determined in these entities or dynamically signaled to them at the time of cryptographic operation.
The verification mechanism described in solution 1 variant 1 employs an encryption function using the permanent keys that are known only in the USIMs 100 and the server for subscription data. By definition, these permanent keys are neither accessible nor readable by the ME 30 or any other network elements. Due to the use of permanent keys, it is not possible for the ME 30 or any 3rd party intermediate entity to forge the 2rd or 3rd order tokens which correctly de-generate into the original seed token. Therefore, the mechanism described in solution 1 variant 1 may be used to prevent security threats such as a “man-in-the-middle” (MitM) attack.
Similarly, the verification mechanisms described in solution 1 variant 2 through variant 6 employ an encryption function using the derived keys that are uniquely established for the subscription (USIM-A 100A and USIM-8100B in
Therefore, using any of the verification mechanisms in these solution variants, if the ME 30 previously provided the USIM 100 subscription information (e.g. IMSI stored in the USIMs 100) by sending NAS messages to the CN 7, for example, it is not possible to lie about them.
In addition, if the permanent key (K) is used for the cryptographic operation (as described in solution 1 variant 1), it is independent of any specific generation of mobile system. Therefore, the above described verification mechanism may be applied in any generation of mobile systems, such as 5G, 4G (LTE), 3G (UMTS, or CDMA2000 or its variants), or 2G (GSM). It is not limited to any particular generation of system.
In the above description, the UE, the (R)AN node, and the core network node are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.
Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories/caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like.
In the above embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE, the (R)AN node, and the core network node as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE, the (R)AN node, and the core network node in order to update their functionalities.
The above embodiments are also applicable to ‘non-mobile’ or generally stationary user equipment.
The method performed by the UE may further comprise: receiving, from the network node, a second token (TB) derived from the seed token (TS) using the second cryptographic key (KB, KNASenc_B) associated with the second SIM; deriving a second third order token (TBA) by encrypting the second token (TB) using the first cryptographic key (KA, KNASenc_A) associated with the first SIM; and sending said second third order token (TBA) to the network node.
The first cryptographic key (KA, KNASenc_A) associated with the first SIM may comprise at least one of a permanent key (KA) associated with the first SIM and a UE specific key (KNASenc_A) associated with the first SIM.
The second cryptographic key (KB, KNASenc_B) associated with the second SIM may comprise at least one of a permanent key (KB) associated with the second SIM and a UE specific key (KNASenc_B) associated with the second SIM.
The method performed by the UE may further comprise indicating to said network node that said UE comprises said first SIM and said second SIM upon at least one of: the UE performing an attach procedure with the network node using said first SIM or said second SIM; the UE detecting that at least one of said first SIM and said second SIM has been activated in said UE; and expiry of a timer associated with a third order token.
The third order tokens (TAB, TBA) may be derived by employing at least one predetermined cryptographic function to said first token (TA) and/or said second token (TB).
The UE may send said third order tokens (TAB, TBA) to the network node by sending at least one non-access stratum (NAS) message comprising at least one of said third order tokens (TAB, TBA). The UE may receive at least one of said first and second token (TA, TB) in a NAS message over a first connection associated with the first SIM and send at least one of said third order tokens (TAB, TBA) in a NAS message over a second connection associated with the second SIM.
The method performed by the network node may further comprise: sending, to said UE, a second token (TB) derived from the seed token (TS) using the second cryptographic key (KB, KNAsenc_B) associated with the second SIM; and receiving a second third order token (TBA) derived by the UE by encrypting the second token (TB) using the first cryptographic key (KA, KNASenc_A) associated with the first SIM.
The third order tokens (TAB, TBA) may be used by the network node in verifying whether said first SIM and said second SIM are comprised in said UE. The verification by the network node may comprise at least one of: deriving a first de-transformed token (TX) by decrypting said first third order token (TAB) using, in sequence, the second cryptographic key (KB, KNAsenc_A) and the first cryptographic key (KA, KNASenc_A), and comparing said first de-transformed token (TX) to the seed token (TS); and deriving a second de-transformed token (TY) by decrypting said second third order token (TBA) using, in sequence, the first cryptographic key (KA, KNASenc_A) and the second cryptographic key (KB, KNASenc_B); and comparing said second de-transformed token (TY) to the seed token (TS).
The method performed by the network node may further comprise determining that at least one of said first SIM and said second SIM is to be blocked, and blocking both said first SIM and said second SIM when it has been verified that said first SIM and said second SIM are comprised in the UE.
The method performed by the network node may further comprise sending at least one of said first and second token (TA, TB) in a NAS message over a first connection associated with the first SIM and receiving at least one of said third order tokens (TAB, TBA) in a NAS message over a second connection associated with the second SIM.
The method performed by the network node associated with the first MNO may further comprise blocking said first SIM card when said received information indicates that said second SIM is blocked.
The above cryptographic functions and keys (KA, KB, KNASenc_A, KNASenc_B etc.) are used as examples only and any suitable function and key may be used by the UE and the network node. In particular, the keys KA, KB etc. are intended to represent any cryptographic keys that are appropriate in a given system. They are not to be construed as limiting the scope of the claims to any specific type of keys.
Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2019/053548 | 4/30/2019 | WO | 00 |
