Satellite acting as local 5g standalone network to address intermittent / temporary connectivity

Abstract

A method for a user equipment to perform identification, followed by authentication and key agreement procedures with a satellite hosting a security database for AKA and acting as a local network provider with intermittent / temporary connectivity, the method comprising the steps of: detecting, by the user equipment, a service link and selecting a network provided by the satellite; transmitting, by the user equipment, a connection request to the satellite; generating, by the satellite, an AUTHENTICATE request for a local security database for AKA for a requested subscriber identifier; generating, by the security database for AKA, an authentication vector (AV) from a key 5 K_nsat derived from a master key for the satellite nsat and proprietary bits of an authentication management field (AMF); returning, by the local security database for AKA, an authentication response. Other aspects are described.

Description

Application areas

[0001] This disclosure relates to a method for performing authentication of 5G or higher compatible user equipment to network elements with intermittent / temporary connectivity, and a user equipment and local unified data management (UDM) for implementing the method. Background Technology

[0002] Store-and-forward operations in 5G systems with satellite access are designed to provide a certain level of communication service for user equipment (UE) under satellite coverage with intermittent / temporary satellite connectivity (e.g., when the satellite is not connected to the terrestrial network via a feeder link or via ISL) for latency-tolerant communication services.

[0003] Support for S&F satellite operations is particularly well-suited for delivering delay-tolerant / non-real-time IoT satellite services using NGSO (non-geostationary) satellites.

[0004] For example, 3GPP TS 33.501 The authentication process described in 6.1.3.2 is not suitable for this use case because it should achieve continuous connectivity between the UE and the core network within tens of seconds, and the store-and-forward use case cannot guarantee such conditions. Summary of the Invention

[0005] One aspect of this disclosure relates to a method for user equipment to perform identification, followed by authentication and key negotiation processes on a satellite that hosts a security database for AKA and acts as a local network provider with intermittent / temporary connectivity, the method comprising the following steps:

[0006] The user equipment detects the service link and selects the network provided by the satellite;

[0007] The user equipment transmits a connection request to the satellite;

[0008] The satellite generates an AUTHENTICATE request for the requested subscriber identifier from the local security database used for AKA.

[0009] The authentication vector (AV) is generated by the security database used by AKA based on the key K_nsat derived from the master key of the satellite nsat and the proprietary bits of the authentication management field (AMF) used to indicate that authentication is performed using the satellite acting as the local network.

[0010] The local security database used for AKA returns an authentication response to the satellite, which includes a random number RAND, an authentication token AUTN, a key, and the expected user response.

[0011] The mobile equipment is questioned by satellite using RAND and AUTN;

[0012] The mobile equipment uses RAND and AUTN with a dedicated bit of AMF to interrogate USIM to indicate that authentication is performed using a satellite acting as the local network for the AUTHENTICATE command.

[0013] K_nsat is derived from the master key MK by USIM;

[0014] The AMF value is checked by USIM and K_nsat is derived from MK based on KDF, where n=nsat was previously stored;

[0015] The USIM returns the user response RES that matches the expected user response and the key calculated using K_nsat; and

[0016] The ATTACH process continues normally.

[0017] Therefore, one of the advantages of this disclosure is that it enables use cases with low / intermittent connectivity, such as store-and-forward use cases, while maintaining a practical security consensus (each entity maintains the same level of key / security); if a satellite is stolen, there is no security impact on other satellites; and there is no limit to the number of satellites that the UE can communicate with, because the "n" value is no longer sent due to the proprietary bit of the AMF.

[0018] In one aspect of this disclosure, the subscriber identity is IMSI, and the connection response is an ATTACH request that includes the IMSI.

[0019] One aspect of this disclosure relates to adding the E-UTRAN cell ID (ECI) as a parameter to a command for USIM to perform derivation; and retrieving nsat from the ECI by USIM.

[0020] In one aspect of this disclosure, the security database used for AKA is HSS / AUC.

[0021] In one aspect of this disclosure, the subscriber identity is SUPI, and the connection request is a REGISTRATION request that includes SUCI.

[0022] One aspect of this disclosure relates to pre-provisioning user equipment using the secret SUCI master key SUCI_MK and the public key of the master SUCI key pair.

[0023] One aspect of this disclosure relates to transmitting a context-specific GET IDENTITYCOMMAND from a mobile device to a USIM to provide the NR cell ID (NCI) as a parameter.

[0024] One aspect of this disclosure relates to retrieving nsat from NCI using USIM, deriving the SUCI public key for nsat, calculating the SUCI, and responding using the SUCI.

[0025] In one aspect of this disclosure, the security database used for AKA is AUSF / UDM / ARPF / SIDF.

[0026] In one aspect of this disclosure, the derived key K_nsat acts as a permanent subscriber K to perform the AKA process.

[0027] One aspect of this disclosure relates to user equipment and satellite systems, wherein a remote communication system is configured to have the satellite system perform the identification of the user equipment, followed by authentication and key negotiation processes.

[0028] In one aspect of this disclosure, user equipment communicates with a satellite system without using a feeder link. Attached Figure Description

[0029] The following description and accompanying drawings illustrate certain exemplary aspects in detail and indicate only a few of the various ways in which the principles of the embodiments may be adopted. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the accompanying drawings, and the disclosed embodiments are intended to include all such aspects and their equivalents.

[0030] • Figure 1 An example is illustrated of the key allocation according to the present disclosure in the local LUDM_nSUCI;

[0031] • Figure 2 An example of generating a hidden identifier according to this disclosure is shown;

[0032] • Figure 3 The registration of user equipment disclosed herein is illustrated;

[0033] • Figure 4 Examples of remote communication systems according to this disclosure are illustrated;

[0034] • Figure 5 Examples of authentication performed by network elements according to this disclosure are illustrated;

[0035] • Figure 6 Examples of authentication according to the protocol disclosed herein are illustrated; and

[0036] • Figure 7 An example of authentication under another protocol pursuant to this disclosure is illustrated. Detailed Implementation

[0037] In the following detailed description, reference is made to the accompanying drawings, which illustrate by way of example specific embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present disclosure. It should be understood that the various embodiments of the present disclosure, while different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented in other embodiments without departing from the spirit and scope of the present disclosure. Furthermore, it should be understood that the position or arrangement of the various elements within each disclosed embodiment may be modified without departing from the spirit and scope of the present disclosure. Therefore, the following detailed description should not be construed as limiting, and the scope of the present disclosure is defined only by the appended claims (as properly interpreted) and the full scope of the equivalents granted by the claims. In the drawings, the same reference numerals consistently refer to the same or similar functionality in several views.

[0038] The following description includes references to various methods executed by a processor of an integrated circuit chip. As is common in the art, phrases may appear herein indicating that these methods or method steps are executed by software instructions or software modules. As those skilled in the art will appreciate, such descriptions should be understood to mean that the processor actually executes the methods, software instructions, and software modules.

[0039] This disclosure relates to the evolution of 3GPP IOPS services (tactical bubbles) to accommodate use cases with intermittent / temporary connectivity to networks, such as 5G satellites. Satellites operating in satellite store-and-forward mode include eNB / gNB functionality and potential CN functionality. For example, a satellite can be considered a complete PLMN as seen by a UE with registration capabilities.

[0040] To provide registration capabilities in the event of feeder link unavailability, one possible solution would be to equip the satellite with HSS / AuC (or, for 5G protocols, AUSF / UDM / ARPF / SIDF) capabilities to run the traditional AKA process. However, HSS / AuC (and correspondingly AUSF / UDM / ARPF / SIDF) contains subscriber key credentials, and deploying such credentials on a satellite may pose security risks. For example, if the satellite is lost or stolen, the user's subscription credentials could be compromised.

[0041] To mitigate this risk, the disclosure presented herein considers the security architecture and principles of satellite reuse in store-and-forward modes as described in Annex F of TS 33.401[aa] "Isolated E-UTRAN Operation for Public Safety".

[0042] For 4G systems, this means that the satellite will act as a local EPC with at least MME and HSS functionality, and the HSS / AuC carried on the satellite will only contain a key derived from the master key MK for a given satellite.

[0043] In this way, the master key associated with the subscription will never be compromised. On the user equipment side, the subscriber master key MK is securely stored in the USIM.

[0044] Compared to traditional 4G AKA, the UE should first decode the E-UTRAN cell identity and provide it to the USIM, which will then derive the subscriber master key to obtain the symmetric key K_nsat for that satellite. The nominal AKA procedure can be performed after utilizing the symmetric key K_nsat.

[0045] For 5G systems, this means that the satellite will act as a local 5GC with at least AMF and AUSF / UDM / ARPF / SIDF functionality. The concepts described in Annex F of TS 33.401 [aa] can be reused, where ECI is replaced by NR cell Id (NCI), and the SUPI / SUCI (de)hiding step should be added.

[0046] According to this disclosure, the satellite can be considered a local 5G standalone network for authenticable user equipment. If a satellite is stolen, there is no security impact on databases hosted on other satellites.

[0047] This disclosure utilizes SUCI key pair derivation (such as for a local 5G standalone network) to calculate the SUCI for a satellite acting as a local network. It modifies the AUTHENTICATE command defined by IOPS to enable addressing a large number of satellites. There is no longer a limit to the number of satellites that a user equipment UE can communicate with.

[0048] User equipment can be computing devices, such as laptops, tablets, telephones, media players or other portable electronic devices, wearable devices, headphones, embedded devices, televisions, gaming devices, navigation devices, electronic devices with Internet of Things (IoT) functionality, equipment that enables the functionality of two or more of these devices, or other electronic equipment. Any other type of electronic computing device with wireless communication capabilities is also considered, which may include communication via one or more wireless communication protocols, such as those for communicating over: Wireless Wide Area Network (WWAN), Wireless Metropolitan Area Network (WMAN), Wireless Local Area Network (WLAN), Wireless Personal Area Network (WPAN), Near Field Communication (NFC), cellular wireless networks, 4G Long Term Evolution (LTE), LTE-A Advanced, 5G and / or 6G, or other currently or future advanced cellular wireless networks. Other types of network-linked systems and devices are also considered, such as, for example, vehicles and M2M devices, provided they are interacting with the network.

[0049] Figure 1 An example is provided of the allocation of keys in the local unified data management / authentication credential repository and the processing function LUDM_nSUCI according to this disclosure.

[0050] Macro Unified Data Management (MUDM), typically coupled with subscription identifier de-hiding functionality and authentication credential storage and processing functions, has a master SUCI key pair (dM, QM) and a SUCI master secret key SUCI_MK as prerequisites. The SUCI master secret key SUCI_MK can be used to derive local SUCI key pairs used to compute SUCI. The SUCI master secret key SUCI_MK can have appropriate entropy to keep dM secure even if several private keys dnSUCI of several local UDMs are stolen. The Macro Unified Data Management (MUDM) can also store local UDM identifiers (called nSUCI) and an association function f(nSUCI) for each local LUDM_nSUCI.

[0051] Therefore, the value nSUCI identifies the local network element associated with the unified data management LUDM_nSUCI to define a local SUCI key pair.

[0052] nSUCI can be determined directly or via a mapping table, either entirely or partially, from the NR Cell Global Identifier (NCGI) (Mobile Country Code MCC | Mobile Network Code MNC | gNB ID | Cell ID). In other words, nSUCI can take the value of the NCGI.

[0053] In the first step S1, the Macro Unified Data Management (MUDM) derives the local private key dnSUCI for the local unified data management (LUDM_nSUCI) key pair. Typically, the local private key is calculated as follows:

[0054] dnSUCI = KDF(SUCI_MK|nSUCI|f(nSUCI)) x dM mod N, where N is the curve order. KDF here represents a cryptographic key derivation function based on a strong pseudo-random function. KDF can be, for example, a pseudo-random function based on a hash function, also known as HKDF (RFC5869). It should also be noted that a value of 0 mod N must be avoided for the derivation key dnSUCI to work, even though the chance of it occurring given the size of the KDF output is very low.

[0055] Therefore, the derivation of the local private key uses the secret SUCI master key SUCI_MK, the master key pair dM master private key, and the value nSUCI associated with the local 5G standalone network.

[0056] In step S2, the macro UDM_MUDM pairs the corresponding private key dnSUCI with the local LUDM_nSUCI. Therefore, each local LUDM_nSUCI is identified by the identifier "nSUCI" and stores the private SUCI key dnSUCI.

[0057] Figure 2 A mechanism for local key derivation for each local network's SUCI, according to one aspect of this disclosure, is illustrated. To achieve this key derivation, advantageously, the necessary parameters for implementing this disclosure are pre-configured to the security component USIM in the User Equipment (UE) intended to use local UDM connections. This configuration is performed during the personalization phase or using over-the-air (OTA) configuration. Typically, this configuration is performed by involving macro-unified data management (MUDM) prior to any registration by the UE to a local 5G standalone network with local unified data management (LUDM_nSUCI).

[0058] Therefore, the security component is not only configured with the SUPI allocated for the local 5G network, but also with the secret SUCI master key SUCI_MK and the public key QM of the master SUCI key pair.

[0059] In one aspect of this disclosure, as shown in step S3, the mobile equipment ME may transmit a command (typically an identity acquisition cmd) to the security component USIM, which includes a specific context providing sufficient information as parameters related to the local 5G network identifier nSUCI.

[0060] The Acquire Identity command is the actual command a mobile device uses to request SUCI from the USIM. This command contains context parameters that allow the card to adapt SUCI calculations. For example, there might be two possible contexts: a base case called "SUCI" and another base case called "SUCI NSWO," because in the case of non-seamless WLAN offloading of NSWO, the card must generate a different SUCI.

[0061] In one aspect of this disclosure, a third context for IOPS may exist in an identity acquisition command as defined in the standard, where the user equipment (typically a cellular phone) inputs data to the security component to infer nSUCI.

[0062] In one aspect of this disclosure, the SUCI is generated by the mobile equipment ME, and the security component only returns the derived public key to the ME. In this case, a new command is introduced according to the invention to obtain the derived public key.

[0063] The reception of a specific context triggers step S4 on the USIM side using the master public key QM, the master secret key SUCI_MK, and the value nSUCI, which is also derived by the function KDF used by the macro unified data management MUDM.

[0064] As mentioned above, the function f(nSUCI) is advantageously used as an input parameter for the KDF. Therefore, the calculation is advantageously performed as follows:

[0065] QnSUCI = KDF(SUCI_MK|nSUCI|f(nSUCI)).QM, where “.” in this formula represents the elliptic curve dot product.

[0066] The local public key QnSUCI then acts as the home network public key used for SUCI hiding, as defined in the registry's standardized specifications.

[0067] In step S5, if the USIM is configured to generate its own SUCI, the security component USIM returns the SUCI; or if the USIM is configured to have a SUCI generated by the ME, the security component USIM returns the derived public key QnSUCI to the ME.

[0068] Figure 3 This illustration demonstrates the registration of a User Equipment (UE) to a network element with a Local Unified Data Management (LUDM) system (LUDM_nSUCI), with a Mobile Equipment (ME) connected to the LUDM_nSUCI system as illustrated by the double arrows. Registration procedures already defined in 5G specifications and other specifications can benefit from this disclosure.

[0069] This disclosure proposes to derive the secret SUCI master key SUCI_MK and the master SUCI key pair based on the value nSUCI associated with the local network LUDM_nSUCI in order to hide SUPI.

[0070] Therefore, as Figure 3 As shown, in step S6, the ME extracts a specific context as a parameter from its connection to the local network LUDM_n, providing sufficient information related to the local 5G network identifier nSUCI. This extraction is based on the associated Tracking Area Code (TAC) and / or the NR Cell Global Identifier (NCGI), used directly or in whole or in part via a mapping table. The value nSUCI is thus determined.

[0071] Then, in step S3, the ME sends commands to the security component USIM, such as... Figure 2 As described herein, the command includes the value of the local LUDM_nSUCI or all necessary parameters that determine its value using the security component USIM.

[0072] Due to such Figure 2 The process illustrated involves the security component USIM conforming to the operation of utilizing the local unified data management LUDM_nSUCI, i.e., conforming to IOPS operation. Specifically, the security component USIM knows the PLMN identity assigned to IOPS, the SUPI assigned to IOPS, and the SUCI master secret key SUCI_MK. It also has access to a table of f(nSUCI) for use in derivation mechanisms when needed. The purpose of this invention is to enable precise updating of this table, typically via over-the-air relocation in the event of the local unified data management LUDM_nSUCI being stolen. This invention not only provides diversity of key sets used by each local network within the local network but also enables updating of the key set to be used by the same operating local network when snooping and / or forgery is suspected.

[0073] In step S4, the security component USIM, as Figure 2 The process is as described herein. In step S5, the necessary cryptographic materials are transmitted to the ME for use in seeking registration with the local unified data management system, such as... Figure 3 The large double arrow in the diagram illustrates this. This registration process is as described in already defined or future standardized registration processes, and therefore will not be described in detail here. This invention relates to all registration processes using hidden SUPI.

[0074] One advantage of this disclosure is that if a local UDM / ARPF has been corrupted, tables in the USIM can be updated using OTA. When it is suspected that the tactical bubble «nSUCI» has been corrupted, the function f(n SUCI Allows the restoration of the tactical bubble «nSUCI».

[0075] Figure 4 An exemplary system for store-and-forward operations between a satellite and user equipment 403 is illustrated. User equipment 403 may be a mobile equipment 410 paired with a security component 407, such as a USIM, and an example of user equipment 403 has been previously described. User equipment 403 may communicate with satellite system 412. Satellite system 412 may be an orbital telecommunication device 413, which may contain a security database for AKA 417 (such as a local unified data management (UDM) network product with authentication credential repository and processing capabilities (ARPF)) or otherwise communicate with such a security database. Satellite system 412 may be identified using the identifier “nSUCI” and may store the private key of the SUCI for this “local network”. Satellite system 412 may also store K_n for the AKA process for each subscriber of the telecommunication system (such as for users of user equipment 410 and / or for user equipment 410 itself). Similarly, user equipment 403 can be pre-configured with the secret SUCI master key SUCI_MK and the public key of the master SUCI key pair, as well as the master key MK for the AKA process.

[0076] Figure 5 One aspect of this disclosure is illustrated, wherein a network connection is located between a user equipment (UE) including a USIM and a mobile equipment (ME) and a network element (NE). The network element may have a connection to the UE characterized by intermittent / temporary connectivity. For example, such a network element (NE) may be a satellite. The satellite may have an associated local unified data management LUDM_nSUCI. Therefore, the satellite can be identified using the identifier nSUCI. The satellite may store a private key for storing the SUCI on this local network. Additionally, the satellite may store K_n for each subscriber (e.g., for the AKA procedure).

[0077] The aspects of this process may be combined or otherwise resemble the previously described process. For example, during step S508, the mobile equipment ME may use an "identity acquisition command" toward the security component USIM, where the local 5G network identifier "nSUCI" is provided as a parameter in a specific context.

[0078] In S510, the Security Element USIM can derive the SUCI public key for the local network. The SUCI public key represents the value of nSUCI. In the case where the local network is a satellite, then nSUCI is the NR Cell Global Identifier (NCGI). The Security Element USIM can also perform SUCI calculations. Furthermore, the Security Element USIM can store the value of nSUCI.

[0079] In S513, the Secure Element USIM can send a SUCI for the local network (in this case, the satellite) to the Mobile Equipment ME. The Mobile Equipment ME then uses the SUCI to register with the satellite, as in S517.

[0080] In S520, the satellite can initiate the authentication process. This can trigger the AUTHENTICATE command performed by the mobile equipment (ME), as in S523. For example, the network element (NE) can use a dedicated bit of the AMF to instruct the user equipment (UE) to perform authentication, where the satellite acts as the local network.

[0081] USIM can derive K_n from MK, as in S525. The security element USIM can check the AMF value and derive K_n from MK due to KDF, where "n" is considered the stored value for nSUCI. The derived key K_n can act as the permanent subscriber key K, such as to perform the AKA procedure.

[0082] Figure 6 This is an example of satellites that act as nodes for Evolved Packet Core (EPC) operations, such as satellites used to provide converged voice and data services on 4G Long Term Evolution (LTE) networks. Several initial conditions may exist for operation:

[0083] -The USIM is configured with an IMSI and a master key MK for the local PLMN.

[0084] - The HSS / AuC carried on the satellite is equipped with IMSI and the key K_nsat for deriving the satellite's Nsat.

[0085] - The satellite identifier nsat matches the eNodeB_Id.

[0086] The operation can be performed as follows:

[0087] 1. UE detects the service link and selects the local PLMN.

[0088] 2. The UE sends a connection request (ATTACH request) to the local MME.

[0089] 3. The local MME generates an AUTHENTICATE REQ to the local HSS / AuC based on the requested IMSI.

[0090] 4. The local HSS / Auc generates an authentication vector (AV) from the key Knsat derived from the MK used for satellite nsat. A proprietary bit of the AV is used to indicate that authentication is performed with the satellite acting as the local network.

[0091] 5. The local HSS returns an authentication response to the local MME.

[0092] 6. The local MME uses RAND and AUTN to interrogate the UE.

[0093] 7. The ME uses RAND and the AUTN with the AMF's dedicated bit to challenge the USIM to indicate that authentication is performed using a satellite acting as the local network against the AUTHENTICATE CMD. The ECI (E-UTRAN Cell ID) is also added as a parameter to the command used by the USIM to perform the derivation.

[0094] 8. USIM retrieves nsat from ECI

[0095] 9. Derive K_nsat from MK using USIM. USIM checks the AMF value and derives K_nsat from MK due to KDF, where n = the previously stored nsat. The derived key K_nsat acts as the permanent subscriber K to perform the AKA procedure.

[0096] 10. USIM returns RES and the key calculated using this K_nsat.

[0097] 11. Normal continuation of the ATTACH process.

[0098] There may be some effects on the operating components, such as the following:

[0099] USIM:

[0100] - Retrieve nsat from the ECI provided by the UE in AUTHENTICATE cmd.

[0101] - Use nsat to derive K_nsat from MK.

[0102] UE:

[0103] -AUTHENTICATE - New parameter ECI on cmd.

[0104] HSS / AuC:

[0105] - The HSS / AuC carried on the satellite is equipped with IMSI and the key K_nsat for deriving the satellite's nsat.

[0106] Figure 7 This demonstrates the workflow for using satellites as network nodes for store-and-forward operations for different framework protocols. For example, this operation can be used with the 5GS protocol. Several initial conditions may exist:

[0107] - The USIM is configured with the SUPI and master key MK for the local PLMN, and the master key and certificate for SUPI / SUCI: master key SUCI_MK, master SUCI_PK_QM

[0108] - The local AUSF / UDM / ARPF / SIDF onboard the satellite is configured with SUPI and a key K_nsat for derivation of the satellite nsat, as well as a private key for SUCI (described in this document as nsat, which may correspond to the previous nSUCI).

[0109] - The satellite identifier nsat matches gNodeB_Id.

[0110] The specific steps are as follows:

[0111] 1. UE detects the service link and selects the local PLMN.

[0112] 2. GET IDENTITY COMMAND with a specific context to provide NCI (NR cell ID) as a parameter.

[0113] 3. USIM retrieves nsat from NCI.

[0114] 4. USIM is used to derive the SUCI public key from "nsat".

[0115] 5. USIM calculates SUCI.

[0116] 6. USIM uses SUCI for response.

[0117] 7. The UE sends a connection request (REGISTRATION REQUEST) to the local AMF.

[0118] 8. The local AMF generates an AUTHENTICATE REQ for the request SUCI from the local AUSF / UDM / ARPF / SIDF.

[0119] 9. Remove the hiding of SUCI using local AUSF / UDM / ARPF / SIDF.

[0120] 10. The local AMF / UDM / ARPF / SIDF generates the AV from the key K_nsat derived for the satellite nsat. The proprietary bits of the AMF are used to indicate that authentication is performed with the satellite acting as the local network.

[0121] 11. The local AUSF / UDM / ARPF / SIDF returns an authentication response to the local AMF.

[0122] 12. The local AMF uses RAND and AUTN to question the UE.

[0123] 13. The ME uses RAND and AUTN with a dedicated AMF bit to interrogate the USIM to indicate that authentication is performed using satellites acting as the local network against the AUTHENTICATE CMD.

[0124] 14. Derive K_nsat from MK using USIM. USIM checks the AMF value and derives K_nsat from MK due to KDF, where n = the previously stored nsat. The derived key K_nsat acts as the permanent subscriber key to perform the AKA process.

[0125] 15. USIM returns RES and the key calculated using the K_nsat.

[0126] 16. The REGISTRATION process continues normally. There may be some effects on the operating components, such as the following:

[0127] USIM:

[0128] - Retrieve nsat from the NCI provided by the UE in the GET IDENTITY cmd.

[0129] - Use nsat to derive K_nsat from MK

[0130] UE:

[0131] The new parameter NCI is used in the -GET IDENTITY cmd command.

[0132] Local AUSF / UDM / ARPF / SIDF:

[0133] - The AUSF / UDM / ARPF / SIDF carried on the satellite is equipped with SUPI and a key K_nsat for deriving the satellite nsat, as well as a private key for SUCI calculation.

[0134] In the detailed description above, reference has been made to the accompanying drawings, which illustrate by way of example specific embodiments in which the invention may be practiced. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the invention. Therefore, the detailed description above should not be construed as limiting, and the scope of the invention is to be properly interpreted only by the appended claims.

Claims

1. A method for user equipment to perform identification, followed by authentication and key negotiation processes on a satellite, said satellite hosting a security database for an AKA and acting as a local network provider with intermittent / temporary connectivity, said method comprising the following steps: The user equipment detects the service link and selects the network provided by the satellite; The user equipment transmits a connection request to the satellite; The satellite generates an AUTHENTICATE request for a requesting subscriber identifier from the local security database used for AKA. The security database used for AKA generates an authentication vector (AV) based on a key K_nsat derived from the master key of the satellite nsat and a proprietary bit of the authentication management field (AMF) indicating that the authentication is performed using a satellite acting as a local network. The local security database used for AKA returns an authentication response to the satellite, the authentication response including a random number RAND, an authentication token AUTN, a key, and an expected user response; The satellite uses RAND and AUTN to interrogate the mobile equipment; The mobile equipment uses RAND and the AUTN with the proprietary bit having AMF to interrogate the USIM to indicate that the authentication is performed using a satellite acting as the local network in response to the AUTHENTICATE command. K_nsat is derived from the master key MK using the USIM; The USIM checks the AMF value and derives K_nsat from MK according to KDF, where n=nsat was previously stored; The USIM returns the user response RES that matches the expected user response and the key calculated using the K_nsat; as well as The ATTACH process continues normally.

2. The method of claim 1, wherein the subscriber identity is an IMSI, and the connection response is an ATTACH request including the IMSI.

3. The method according to claim 2, further comprising: The E-UTRAN cell ID (ECI) is added as a parameter to the command so that the USIM can perform the derivation; And the USIM retrieves nsat from the ECI.

4. The method according to claim 2 or 3, wherein the security database used for AKA is HSS / AUC.

5. The method of claim 1, wherein the subscriber identity is SUPI, and the connection request is a REGISTRATION request including SUCI.

6. The method according to claim 5, further comprising: The user equipment is pre-configured using the secret SUCI master key SUCI_MK and the public key of the master SUCI key pair.

7. The method according to claim 5 or 6, further comprising: The mobile equipment transmits a context-specific GET IDENTITY COMMAND to the USIM, providing the NR Cell ID (NCI) as a parameter.

8. The method according to claim 7, further comprising: The USIM retrieves the nsat from the NCI, derives the SUCI public key for the nsat, calculates the SUCI, and uses the SUCI to respond.

9. The method according to any one of claims 5 to 8, wherein the security database used for AKA is AUSF / UDM / ARPF / SIDF.

10. The method according to any one of the preceding claims, wherein the derived key K_nsat acts as a permanent subscriber K to perform the AKA process.

11. A remote communication system comprising user equipment (403) and a satellite system (412), wherein the remote communication system is configured to have the satellite system (412) perform the identification of the user equipment (403) according to the method of claim 1, followed by an authentication and key negotiation process.

12. The remote communication system of claim 11, wherein the user equipment (403) communicates with the satellite system (412) without using a feeder link.

Images