Device using 256-bit root key

Abstract

To notify a mobile terminal of a length of a root key stored in USIM.SOLUTION: USIM includes a file indicating a length of a root key stored therein. In Step S1, a mobile device ME initiates the USIM. In Step S2, the mobile device ME scans a file system and loads related data to a memory. In Step S3, the 256-bit mobile device ME searches for a file indicating that the USIM is compatible with 256-bit. If the USIM is compatible with 256-bit, in Step S5, the mobile device ME presents a UE security function including a 256-bit algorithm to a network NW. Accordingly, the 256-bit algorithm is available when the USIM is compatible with 256-bit.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a technique for informing a mobile equipment (ME) of the length of a root key stored in a universal subscriber identity module (USIM). [Background technology]

[0002] A terminal device UE (User Equipment) is a mobile communication terminal used by a user, such as a smartphone. When terminal devices UE communicate with each other, they communicate via a mobile communication network such as 5G. This mobile communication network is hereinafter referred to as a "network NW."

[0003] When a terminal device UE and a network NW communicate wirelessly, each transmits an encrypted message. The message is then decrypted on the receiving side. The algorithm used to encrypt the message is called an "encryption algorithm." In addition, there is a risk that a third party may tamper with the message during wireless communication. Therefore, the sender creates a code for tamper detection and adds the code to the message before sending it. The algorithm for creating the code for tamper detection is called the "tamper detection algorithm."

[0004] Current mobile communications, including 5G, use 128-bit tamper detection and encryption algorithms for wireless sections between base stations and user equipment (UE) and for communications between core networks and user equipment (UE). However, the introduction of 256-bit algorithms is being considered for 3GPP (Third Generation Partnership Project) SA3. Although it is possible to add algorithms by simply adding 256-bit algorithms to the specification TS33.501, the issue of the lack of standardization of key lengths used for encryption remains.

[0005] In practical use, it is desirable that the entropy of the key used in the cryptographic algorithm is equal to the key length. In 5G, the root key stored in the USIM (Universal Subscriber Identity Module) may be 128 bits long, which provides only 128 bits of entropy for the 256-bit key generated based on the root key. As a result, despite the use of a 256-bit algorithm, the actual strength provided is approximately the same as that of a 128-bit algorithm. In such a situation, not only is it impossible to achieve the expected security level, but it also results in a waste of computing resources.

[0006] The terminal device UE consists of ME (Mobile Equipment) and USIM (Universal Subscriber Identity Module), where the root key is stored and is responsible for authentication. The mobile device ME receives the authentication response and the keys CK and IK, and concatenates these keys to derive further keys. All these keys are generated in 256 bits. However, the mobile device ME does not know the length of the root key, nor the actual entropy of the keys. Currently, this is not a problem since the 3GPP system only supports 128-bit encryption algorithms and the keys are truncated to 128 bits before use. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] 3GPP (registered trademark) SA3, TS24.501 [Non-Patent Document 2] 3GPP (registered trademark) SA3, TS31.102 [Non-Patent Document 3] 3GPP (registered trademark) SA3, TS33.501 [Non-Patent Document 4] 3GPP (registered trademark) SA3, TS35.206 [Non-Patent Document 5] 3GPP (registered trademark) SA3, TS35.231 Summary of the Invention [Problem to be solved by the invention]

[0008] 3GPP (registered trademark) defines several authentication protocols, some of which use 128-bit root keys and some of which use 256-bit root keys. MILENAGE (specified in TS35.206), which is a 128-bit protocol, uses a 128-bit root key and generates 128-bit keys CK and IK. In contrast, TUAK (specified in TS35.231) can use a 256-bit root key and generate 256-bit keys CK and IK. However, which protocol is used is known only to the USIM and AuC (Authentication Center), HSS (home subscriber server), or ARPF (Authentication credentials Repository Function), and the mobile device ME does not know which protocol is used.

[0009] In principle, the 128-bit authentication protocol MILENAGE outputs a 128-bit key CK and a 128-bit key IK, and the TUAK protocol outputs a 256-bit key CK and a 128-bit key IK if it is set to 256 bits. However, the interface specification between the mobile device ME and the USIM (TS31.102) only supports 128-bit keys CK and IK. Therefore, the mobile device ME is not informed of the protocol used or the length of the root key, but simply receives the 128-bit key CK and IK. Therefore, the mobile device ME cannot determine whether it is appropriate to use a 256-bit encryption algorithm.

[0010] As a simple solution, there is a method of realizing the interface between the mobile equipment ME and the USIM by exchanging a 256-bit key. However, with this method, when a new USIM is inserted into a legacy mobile equipment ME, the mobile equipment ME waits for a 128-bit key CK and key IK, and the USIM transmits a 256-bit key, so compatibility cannot be ensured. Therefore, a method is required to solve this problem without causing compatibility issues between a USIM capable of generating a 256-bit key CK and key IK and a mobile equipment ME compatible with the USIM, and between a USIM generating a 128-bit key CK and key IK and a mobile equipment ME compatible with a 256-bit key.

[0011] The information exchanged between the USIM and the mobile equipment ME can be summarized as follows (A) to (C). (a) When the mobile equipment ME starts up, it obtains information such as the IMSI (International Mobile Subscriber Identity) and networks to scan from relevant files in the USIM. (i) If the terminal device UE is not authenticated, the mobile device ME then sends an AUTHENTICATE command and provides RAND (random number) and AUTN (authentication token) to the USIM. (c) The USIM writes the key CK and the key IK to a file accessible to the mobile equipment ME, and provides a RES (response) to the mobile equipment ME.

[0012] If the root key stored in the USIM is 128 bits long, generating a 256-bit key from it will only provide 128 bits of entropy. As a result, even if a 256-bit algorithm is used, the actual strength of the security provided is approximately the same as that of a 128-bit algorithm. Therefore, by notifying the mobile equipment ME that the root key stored in the USIM is 256 bits long, the 256-bit algorithm is used preferentially, thereby achieving higher security.

[0013] The present invention aims to achieve interoperability so that when a 256-bit algorithm is used to improve the security of a 5G system, the USIM can provide a 256-bit key CK and key IK, and the mobile equipment ME can use them. [Means for solving the problem]

[0014] The inventors have discovered that a USIM has a file indicating the length of a stored root key, and that a mobile device ME reads the file from the USIM, and have completed the present invention.

[0015] (1) A first terminal device of the present invention is a terminal device comprising a mobile device and a USIM in which a root key is stored, the USIM comprising a file indicating the length of the stored root key.

[0016] (2) The mobile device of the first terminal device may read from the USIM a file indicating a length of a root key stored in the USIM.

[0017] (3) The mobile device of the first terminal device may create a list of algorithms it supports and remove from the list any algorithms with a key length longer than the length of a root key stored in the USIM.

[0018] (4) The mobile device of the first terminal device may specify the required key length to the USIM by an AUTHENTICATE command.

[0019] (5) The file indicating the length of the stored root key of the first terminal device may be a file indicating that the length of the stored root key is 256 bits.

[0020] (6) A second terminal device of the present invention is a terminal device comprising a mobile device and a USIM in which a root key is stored, wherein the mobile device determines the length of the root key used by the USIM based on the length of a parameter and / or data in an AMF field included in an authentication request received from a network device.

[0021] (7) The parameters of the second terminal device may be RAND and / or AUTN.

[0022] (8) The mobile device of the second terminal device may determine that the length of the root key used by the USIM is 256 bits if the length of RAND and / or AUTN is longer than 128 bits.

[0023] (9) The mobile device of the second terminal device may determine the length of the root key used by the USIM based on data set by specifications among the two bytes of data in the AMF field.

[0024] (10) A third terminal device of the present invention is a terminal device comprising a mobile device and a USIM in which a root key is stored, wherein the mobile device determines the length of the root key used by the USIM based on the length of a response (RES) included in an authentication response message.

[0025] (11) The mobile device of the third terminal device may determine that the length of the root key used by the USIM is 256 bits if the length of the response (RES) included in the authentication response message is longer than 64 bits.

[0026] (12) The second or third terminal device may determine a length of the root key upon receiving a request from a network, and may communicate the supported root key lengths to the network.

[0027] (13) When the second or third terminal device determines that the root key is less than 256 bits in the authentication and key agreement and the authentication and key agreement are successful, the second or third terminal device may store a result obtained from the authentication and key agreement and use the stored result to generate a key having higher entropy than the entropy of the root key in subsequent authentication and key agreement. Effect of the Invention

[0028] According to the present invention, the USIM is provided with a file indicating the length of the stored root key, and the mobile device ME reads the file in the USIM, so that the mobile device ME can know the length of the root key stored in the USIM. If the length of the root key stored in the USIM is 256 bits, the USIM can provide a 256-bit key CK and key IK, which the mobile device ME can use. [Brief description of the drawings]

[0029] [Figure 1] FIG. 1 is a flow diagram of a first embodiment of the present invention. [Diagram 2] FIG. 11 illustrates step S6 adjusted for the second embodiment of the present invention. [Diagram 3] FIG. 13 is a diagram showing details of authentication in the third and fourth embodiments of the present invention. [Figure 4] FIG. 2 illustrates a key derivation process in an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Broadly speaking, two solutions are proposed to solve the problem. The first solution is to add a file to the USIM indicating that the USIM has a 256-bit root key. The mobile equipment ME recognizes that the USIM has a 256-bit root key by reading the file from the USIM. If the USIM has a 256-bit root key, the mobile equipment ME configures the USIM to use the 256-bit algorithm, and if the USIM does not have a 256-bit root key, it disables the 256-bit algorithm. In this specification, examples in which the first solution is applied will be described as the first and second embodiments.

[0031] In the second solution, the mobile device ME checks the field length etc. from the request or response it receives, and determines that the USIM uses a 256-bit root key based on the field length etc. If it is confirmed that the USIM supports 256 bits, the mobile device ME sets it to use the 256-bit algorithm. In this specification, examples in which the second solution is applied will be described as a third and fourth embodiments. Neither of the proposed methods affects the functionality of the legacy mobile equipment ME, and the USIM operating in the legacy mobile equipment ME is not modified.

[0032] [Key Points of the First Embodiment] The first embodiment is a first example of the first solution, and relates to a mobile device ME and a USIM. (1) Add a new file to the USIM that indicates that the USIM holds a 256-bit key. (2) A mobile device ME that supports 256-bit data reads the file (1) above and confirms that the USIM supports 256-bit data. If the file (1) above does not exist, the mobile device ME determines that the USIM may not support 256-bit data. (3) In algorithm negotiation with the serving network, the mobile equipment ME enables the 256-bit encryption algorithm if the USIM supports 256-bit encryption, and disables the 256-bit encryption algorithm if the USIM does not support 256-bit encryption.

[0033] [Key Points of the Second Embodiment] The second embodiment is a second example of the first solution, and relates to a mobile device ME and a USIM. (1) Add a new file to the USIM that indicates that the USIM holds a 256-bit key. (2) A mobile device ME that supports 256-bit data reads the file (1) above and confirms that the USIM supports 256-bit data. If the file (1) above does not exist, the mobile device ME determines that the USIM may not support 256-bit data. (3) When using the AUTHENTICATE command, the mobile equipment ME notifies the USIM that it wishes to use a 256-bit algorithm if the USIM supports 256 bits. (4) The USIM returns a 256-bit key and the mobile equipment ME validates the 256-bit algorithm.

[0034] [Key Points of the Third Embodiment] The third embodiment is a first example of the second solution, and relates to the mobile device ME alone. (1) Upon receiving an authentication request, the mobile equipment ME examines the authentication request and checks whether: a. The length of each input parameter b. AMF bit set (2) If a predefined value is set, the mobile equipment ME determines that the USIM uses a 256-bit root key and configures the USIM to use a 256-bit algorithm.

[0035] [Key Points of the Fourth Embodiment] The fourth embodiment is a second example of the second solution, and relates to the mobile device ME alone. (1) Upon receiving the Authenticate Response, the mobile equipment ME checks the length of the RES (response) and whether the RES (response) was calculated from a 256-bit root key or a 128-bit root key. (2) If the RES (response) is longer than 32 bits, the mobile equipment ME determines that the USIM uses a 256-bit root key and configures it to use a 256-bit algorithm.

[0036] [First embodiment] The first embodiment operates as follows in conjunction with FIG. Step S1: The mobile equipment ME initializes the USIM. Initialization can occur, for example, when the terminal equipment UE is started up, restarted, when a new UICC (Universal Integrated Circuit Card) is inserted into the mobile equipment ME, or when a new SIM profile is downloaded and activated via remote provisioning of an eSIM (Embedded Subscriber Identity Module). In any case, the result is that the mobile equipment ME reads the USIM and, if necessary, provides a PIN (Personal Identification Number) code to unlock the USIM.

[0037] Step S2: The mobile equipment ME scans its file system and loads relevant data into its memory (IMSI, PLMN ID, etc.). Step S3-a: The mobile device ME, which is 256-bit capable, searches for a file indicating that the USIM is 256-bit capable, and if found, sets a bit in memory to 1 to indicate that the USIM is 256-bit capable. If not found, the mobile device ME sets the bit to 0.

[0038] Step S3-b: As an alternative to step S3-a, the 256-bit capable mobile device ME searches for a file indicating the length of the root key and, if found, retrieves the length of the root key from the file. If the length of the root key is 128 bits, the mobile device ME sets a bit in memory indicating that a 128-bit algorithm is used. If the length of the root key is 256 bits, the mobile device ME sets a bit in memory indicating that the USIM is 256-bit capable.

[0039] In addition, if the root key length is 512 bits, the mobile device ME sets a bit indicating that the root key is 512 bits. At present, there are no plans to introduce a 512-bit encryption algorithm, but this can be used in the future to expand to other key sizes. Furthermore, if the root key length is larger than the key size required for the algorithm (e.g., the root key length is 512 bits and the mobile device ME is 256-bit capable but does not support the 512-bit algorithm), the mobile device ME can also enable an algorithm with a sufficient key size (a 256-bit algorithm in the above example).

[0040] For example, if the mobile equipment ME supports cryptographic algorithms using 128-bit, 256-bit and 512-bit keys and the USIM can provide a 256-bit root key, the algorithms using 128-bit and 256-bit keys will be enabled, but the algorithms requiring a 512-bit key will be disabled. If the USIM becomes capable of providing a 512-bit root key, the mobile equipment ME can enable all algorithms. If a legacy USIM is inserted into the mobile equipment ME and the file indicating the key length is not found, the mobile equipment ME assumes that the root key is 128 bits and disables the 256-bit and 512-bit algorithms.

[0041] In step S4, the above logic is executed in the mobile device ME. As a result of the execution of the logic, the mobile device ME creates a list of security capabilities that it provides to the network NW. In the prior art, the security capabilities of the terminal device UE are a list of cryptographic algorithms that the mobile device ME supports, regardless of the root key size. In this first solution, the mobile device ME gets a list of all cryptographic algorithms and removes from the list those for which it does not have a sufficient key length. An example of this operation is given below.

[0042] [Table 1]

[0043] In Table 1, the first three digits indicate the required key size, and EA and IA indicate the encryption algorithm and tamper detection algorithm.

[0044] Although there is no column for the AEAD (Authenticated Encryption with Associated Data) algorithm in Table 1, it is expected that AEAD may be selected as an option other than EA / IA for the mobile device ME security capabilities. For example, if the mobile device ME security capabilities are as listed in Table 1 and 512-EA7 is specified as the AEAD algorithm, and the mobile device ME wants to indicate that it supports AEAD, it can do so by indicating that it supports 512-EA7 (there is no need to add a new identifier such as 512-IEA7 as AEAD).

[0045] Thereafter, if the network NW prioritizes an AEAD algorithm and supports 512-EA7, it selects this algorithm and the corresponding tamper detection algorithm. Here, it is assumed that the network NW selects 512-IA7 so that it matches the encryption algorithm selected last time. The network NW transmits a Secure Mode Command (a message indicating the selected algorithm) and specifies 512-EA7 as the encryption algorithm and 512-IA7 as the tamper detection algorithm. Since the mobile device ME supports only 512-EA7, it determines that the network NW has selected to use 512-EA7 in AEAD mode, and uses 512-EA7 in AEAD mode.

[0046] In the above, the AEAD algorithm is 512-EA7, but it is possible that an algorithm other than 512-bit key is used for AEAD. Therefore, it is possible to select 128-bit or 256-bit AEAD in the same way, and there is no need to add a column indicating the AEAD algorithm.

[0047] The difference between the selection of EA and IA algorithms and the selection of AEAD algorithms is that the network NW prioritizes the AEAD mode algorithm. Suppose that the algorithms supported by the mobile device ME are 512-EA6, which is an encryption algorithm, 512-IA6, which is a tamper detection algorithm, and 512-EA7, which is an AEAD algorithm.

[0048] Here, these three algorithms may be the same AEAD. Since an AEAD algorithm can be used for encryption only or for tamper detection only, 512-EA6 may provide encryption only (by skipping the tamper detection step of the AEAD algorithm or by simply discarding the MAC (Message Authentication Code)). In that case, any algorithm may be selected as the tamper detection algorithm. Similarly, 512-IA6 provides tamper detection only (by skipping the encryption step or by discarding the generated ciphertext) and may be used with any encryption algorithm.

[0049] If the same algorithm is referred to as 512-EA7, it can achieve encryption and tamper detection in one operation. In the 3GPP specification, 512-EA7 means that only one key is used as input. For example, k NASenc , k RRCenc , k UPenc , k NASint , k RRCint , k UPint The encryption and MAC (Message Authentication Code) calculations can be realized using one of the following: When 512-EA6 is used with 512-IA6, even though these are the same algorithms as 512-EA7, two different keys are used. One is the encryption algorithm (k NASenc , k RRCenc , k UPenc ) and the other is used as the input for the tamper detection algorithm (k NASint , k RRCint , k UPint ) is used as input for

[0050] Therefore, even if 512-EA6 and 512-EA7 are the same algorithm, if the network NW prioritizes AEAD, the network NW selects 512-EA7, which is an AEAD. After confirming that AEAD is supported, the network NW selects 512-IA7, which is pre-set as the IA algorithm corresponding to the selected AEAD, and notifies the mobile device ME that 512-EA7 will be used for both encryption and tamper detection. At this time, even if 512-IA7 has not been notified by the mobile device ME as a supported tamper detection algorithm, it can be specified.

[0051] When the mobile device ME confirms that the root key is 256 bits, the UE security capabilities that the terminal device UE notifies to the network NW in the initial attach message (and other NAS messages requested by the network NW) sent in step S5 of Figure 1 will be as shown in Table 2 below.

[0052] [Table 2]

[0053] The mobile equipment ME removes an algorithm from the list if the length of the root key (in the above example, 256 bits) is shorter than the algorithm's key. The mobile equipment ME can store this list in case a network node requests UE security functionality.

[0054] In step S6, authentication is performed according to conventional methods. The USIM derives the 128-bit keys CK and IK and provides them to the mobile device ME. In conventional methods, the mobile device ME concatenates the CK and IK keys and uses the result to derive a 256-bit key. If the same method were used to support a 512-bit encryption algorithm, 256-bit keys CK and IK would be required.

[0055] If the authentication is successful in step S6, the network NW transmits a Secure Mode Command (SMC) to the terminal device UE in step S7. When transmitted from an AMF (Access and Mobility Management Function) to the terminal device UE, it is called a NAS SMC, and when transmitted from a base station gNB to the terminal device UE, it is called an RRC SMC. In the conventional method, RRC security is executed after NAS security is realized, but the method described below can be applied to NAS security and RRC security in the same way.

[0056] The network NW compares the security capabilities of the received terminal device UE with the security capabilities of the network NW to determine which algorithm to use. Since the mobile device ME deletes algorithms that require a key size larger than the size of the root key, the network NW can select only algorithms with a sufficient key length for the root key. This eliminates the need for the AMF and base station gNB to notify the length of the root key, and also eliminates the need for additional logic to consider the length of the root key at each node. Furthermore, this embodiment prevents resources from being consumed by selecting an algorithm that uses a key longer than necessary, thereby realizing power saving and low cost.

[0057] In step S8, the terminal device UE uses the selected algorithm and, if the process is performed correctly, the NAS SMC or RRC SMC is completed with a Secure Mode Complete message sent in step S9.

[0058] [Second embodiment] The second embodiment implements the matters disclosed in FIG. 2 in addition to the first embodiment. In step S6 of FIG. 1, the mobile device ME uses the AUTHENTICATE command to send RAND (random number) and AUTN (authentication token) to the USIM, which returns RES (response), a key CK, and a key IK if authentication is successful. At this time, the mobile equipment ME that supports 256 bits (or 512 bits) can know the key length (128 bits, 256 bits, 512 bits, etc.) supported by the USIM from the execution result of steps S1 to S4. However, since the USIM does not recognize the functions of the mobile equipment ME, the USIM provides only the 128-bit key CK and key IK to the mobile equipment ME.

[0059] Therefore, in a second embodiment, step S6.1 is modified so that the mobile equipment ME instructs the USIM to provide a key of a particular length. To achieve this, the mobile device ME can add a new field to the AUTHENTICATE command to include the required key length, or the USIM can be updated to support different AUTHENTICATE command lengths (e.g. AUTHENTICATE128, AUTHENTICATE256, AUTHENTICATE512, etc.). The mobile device ME determines the required key length based on the following information: Root key length Maximum input key length for supported algorithms - The length of the input key for the algorithm supported by the network NW to which the terminal device UE can connect (for example, it is assumed that this is notified using the ABBA parameter)

[0060] The mobile device ME requests the minimum of the above three values ​​as the key length from the USIM. For example, if the root key is 256 bits and the mobile device ME supports 512 bits, the mobile device ME requests a 256-bit key. Conversely, if the root key is 512 bits and both the mobile device ME and the network NW (if known) support a 512-bit encryption algorithm, the mobile device ME requests a 512-bit key.

[0061] The USIM performs authentication in step S6.2, runs the algorithm and derives the key, providing in step S6.3 a key of the required length, meaning that key CK and key IK each have the required length, or that the concatenation of key CK and key IK has the required length.

[0062] [Third and fourth embodiments] The third and fourth embodiments relate to the mobile equipment ME and are executed in step S6 in Fig. 1. Details of the communication between the mobile equipment ME and the USIM in step S6 are shown in Fig. 3. Fig. 3 shows the USIM, the mobile equipment ME, and the network NW. The 5G mobile network NW is composed of multiple different network functions across the Home PLMN and the Visited PLMN.

[0063] In particular, for authentication and key exchange using 5G-AKA, the ARPF (Authentication credentials Repository Function) uses authentication vectors (RAND, AUTN, XRES * , and KAUSF) and transfers it to the AUSF (authentication server function). The AUSF converts the authentication vector AV (RAND, AUTN, HXRES * , and KSEAF) to the SEAF (Security Anchor Functionality) of the visited network. The SEAF (which may coexist with the AMF) sends an authentication request (RAND, AUTN) to the terminal device UE via an access network such as a radio access network, a fixed network, or a Wi-Fi network.

[0064] In the case of EAP-AKA', the ARPF (Authentication credentials Repository Function) generates the EAP-AKA' AV (RAND, AUTN, XRES, CK', IK') and transfers it to the AUSF (Authentication Server Function). The AUSF transfers RAND (random number) and AUTN (authentication token) in an authentication response message to the SEAF / AMF, and the SEAF / AMF transfers RAND and AUTN (authentication token) to the terminal device UE.

[0065] In both 5G-AKA and EAP-AKA', the USIM verifies the AUTN (authentication token), calculates the RES (response) and provides it to the mobile device ME together with the keys CK and IK. The mobile device ME then sends the RES (response) to the SEAF, which forwards it (after an optional comparison step) to the AUSF.

[0066] 4G networks perform authentication and key agreement in a similar way. The home network's HSS (home subscriber server) prepares an authentication vector (RAND, AUTN, XRES, KASME) and sends it to the visited network's MME (Mobility Management Entity). The MME sends an authentication request to the UE via the access network, and the UE replies with a RES (response).

[0067] Figure 3 shows the operation on the network NW side. In step S21, each network function generates an authentication request consisting of at least RAND (random number) and AUTN (authentication token). In step S22, the RAND (random number) and AUTN (authentication token) are transferred to the mobile device ME via the access network NW. In step S23, the mobile device ME checks the RAND (random number) and AUTN (authentication token), and in step S24, transfers the RAND (random number) and AUTN (authentication token) to the USIM using the AUTHENTICATE command.

[0068] In step S25, the USIM verifies the AUTN (authentication token) and calculates the RES (response). In step S26, the mobile device ME receives the key CK, the key IK and the RES (response) from the USIM. In step S27, the mobile device ME may also verify the RES (response) and the key. In some authentication methods, the RES (response) may be modified in this step S27. For example, the RES (response) may be concatenated with a network ID or a mobile ID and input into a cryptographic hash. In step S28, the mobile device ME forwards the RES (response) or the modified RES (response) to the network NW.

[0069] As described above, the mobile apparatus ME is not notified of information indicating whether the root key is 128 bits or 256 bits, so the mobile apparatus ME cannot know the length of the root key. Therefore, the USIM or the network NW notifies the mobile apparatus ME of the length of the key being used.

[0070] For example, the mobile device ME can verify RAND (random number) and AUTN (authentication token) received from the network NW before sending them to the USIM. In the current specification (TS33.102), RAND (random number) is defined as a random number of length 128 bits, generated by the home network. AUTN (authentication token) is a 128-bit value composed of a concatenation of three fields of different lengths. 48 bits: Sequence Number (SQN) encrypted by XORing with the Anonimity Key (AK) 16 bits: Authentication Management Field, AMF 64-bit: Message Authentication Code, MAC

[0071] The RES (response) calculated by the USIM can vary from 32 to 128 bits, but if the MILENAGE algorithm (TS35.206) is used the length is fixed at 64 bits.

[0072] When moving to 256-bit encryption algorithms, it may be necessary to change the length of input and output parameters as well. For example, increasing the size of RAND (random number) and MAC (message authentication code) makes attacks more difficult. Similarly, increasing the size of RES (response) can improve security. Therefore, the mobile equipment ME can determine which key length is appropriate to use by checking the input and output sizes.

[0073] Option 1: (Third embodiment) The mobile device ME checks the length of the RAND (random number) and AUTN (authentication token) parameters, and if either of them is larger than specified in the current specification, the mobile device ME determines that a 256-bit algorithm is being used.

[0074] Option 2: (Third embodiment) The mobile device ME checks the value of the AMF bit. The AMF field is divided into two bytes, one set by the operator and the other by the standard. Currently, one AMF bit is set, indicating that the authentication is for a 3G or higher network (LTE or 5G). Therefore, another bit is set to indicate that the authentication method supports 256 bits, and the mobile device ME determines that the root key is 256 bits.

[0075] Option 3: (Fourth embodiment) The mobile equipment ME checks the length of the RES (response). MILENAGE outputs a 64-bit RES (response), while TUAK outputs a 32-bit to 128-bit RES (response). Therefore, if the operator configures the USIM that uses TUAK to return a 128-bit RES, the mobile equipment ME can determine from the length of RES that "the operator has configured a 256-bit TUAK algorithm in the USIM." These three options are backward compatible, older mobile equipment MEs simply accept the longer values, and these fields are already in use, so they can be implemented without any changes.

[0076] Option 4: The network NW transmits the key length or key generation algorithm to be used, and the mobile equipment ME checks whether the USIM can meet it. For example, the network NW can indicate this using the Identity Request it initially sends. In EAP-AKA', an identity is requested using the EAP-AKA' / AKA-Identity Request message defined in RFC4187. The message contains one of the following attributes: AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, or AT_FULLAUTH_ID_REQ. Each of these attributes reserves two bytes (16 bits) for future functionality. The network NW can include the use of a 256-bit algorithm in the Identity Request by setting one of these bits.

[0077] Legacy UEs ignore these bits and therefore have no impact on their operation if they are set. An updated UE can see if the bits are set, check if it supports the required key length, and reply with its identity in an Identity Response message and add new attributes such as AT_KEYLENGTH to indicate that the UE supports a key length of 256 bits.

[0078] This method not only supports 128-bit and 256-bit keys, but can also accommodate other key lengths by expanding the bits in the Identity request message.

[0079] Similarly, in 5G AKA, 4 bits are left unused in the Identity Request NAS message defined in TS 24.501. The network NW can use these bits to signal the key length in a similar way. The terminal device UE can respond which key lengths it supports by adding a new field to the Identity response message to indicate the supported key lengths.

[0080] Option 5: If the key length required by the network is not supported by the USIM, it is possible to use pre-shared randomness to generate a longer root key. The randomness can be extracted from messages such as RES (Response) and MAC (Message Authentication Code) exchanged in previous sessions. However, the shared randomness must be input to the authentication algorithm (e.g. TUAK) or key derivation in the visited network.

[0081] Option 5-1: If the first authentication (n=1) is successful, the network NW and USIM store the RES (response) and MAC (message authentication code) used in this authentication. If the authentication fails, the RES (response) and MAC (message authentication code) are not stored.

[0082] In the subsequent authentication (n=m), the USIM and the network NW transfer the persistent root key k to the RES m-1 and MAC m-1 Connect to k m The authentication algorithm proceeds as usual by modifying the input parameters by creating m Instead of k, if successful, the USIM and the network NW m and MAC m In RES m-1 and MAC m-1 In the next authentication run (n=m+1), the USIM and the network NW use the newly saved parameters RES m and MAC m Using k m+1 If authentication fails, both the USIM and the network NW erase the parameters and re-authenticate.

[0083] Option 5-2: This process is similar to option 5-1, but differs in how the random source is stored in the UE and in the network NW. In this case, a visited network is involved, so the UE needs to keep a registry of previous RES (Responses) and MAC (Message Authentication Codes) resulting from successful authentications to this network NW. The mobile equipment ME keeps a registry as shown below:

[0084] [Table 3]

[0085] In option 5-1, a random source is inserted into the authentication algorithm, whereas in option 5-2, KAMF K SEAF Specifically, the terminal device UE and the network NW derive the key K from the input S of the KDF (Key Derivation Function) using the following parameters: SEAF From K AMF Derive. FC=0x6D P0=SUPI ·L0=P0 length number of octets in P0 P1=ABBA parameter ·L1=P1 length - number of octets in P1 P2=MAC L2=Length of MAC P3=RES L3=Length of RES

[0086] And the input key K SEAF Compared to the conventional technique, two new parameters are set and their lengths are added. Alternatively, the input key K SEAF Concatenate MAC (Message Authentication Code) and RES (Response) to K SEAF´ It is also possible to create a key K SEAF Instead, K SEAF´ become. Other operations are the same as in option 5-1, except that in the first authentication to the PLMN (n=1), the RES (response) and MAC (message authentication code) used in this authentication are stored only if the authentication is successful. If the authentication fails, the RES (response) and MAC (message authentication code) are not stored.

[0087] In the subsequent authentication (n=m), the terminal device UE and the network NW SEAFIf the NAS security can be successfully established (indicating not only successful authentication but also that the key has been properly derived), the terminal device UE and the Security Anchor Functionality (SEAF) will m-1 and MAC m-1 RES m and MAC m In the next authentication run (n=m+1), the terminal device UE and the SEAF use these parameters to overwrite K SEAF To generate the new saved parameter RES m and MAC m If authentication fails, both the terminal device UE and the SEAF clear the parameters and re-authenticate.

[0088] These proposals can also be combined. For example, an operator can set a specific AMF bit to instruct the USIM to use an authentication algorithm compatible with 256 bits. Conversely, it is also possible to set a bit to instruct the USIM to use an authentication algorithm compatible with 128 bits. This allows the home operator to flexibly switch authentication mechanisms, for example, when the terminal device UE is roaming in a network NW that does not support 256-bit encryption algorithms. This allows the home operator to flexibly change the operation of the mobile device ME by changing the length of output parameters by changing the AMF (Authentication Management Field).

[0089] The present invention enables mobile devices to use cryptographic and / or tamper detection algorithms that match the length of the root key stored in the USIM, making it possible to contribute to Goal 9 of the United Nations Sustainable Development Goals (SDGs), which is to "build resilient infrastructure, promote sustainable industrialization and foster innovation."

Claims

1. A terminal device comprising a mobile device and a USIM in which a root key is stored, A terminal device, wherein the USIM comprises a file indicating the length of a stored root key.

2. The terminal device of claim 1 , wherein the mobile device reads from the USIM a file indicating a length of the root key stored in the USIM.

3. 3. The terminal device of claim 2, wherein the mobile device creates a list of algorithms it supports and removes from the list algorithms with a key length greater than the length of a root key stored in the USIM.

4. 3. The terminal device of claim 2, wherein the mobile device specifies the required key length to the USIM by means of an AUTHENTICATE command.

5. The terminal device according to claim 1 , wherein the file indicating the length of the stored root key is a file indicating that the length of the stored root key is 256 bits.

6. A terminal device comprising a mobile device and a USIM in which a root key is stored, The mobile device determines the length of the root key used by the USIM based on the length of a parameter and / or data in an AMF field included in an authentication request received from a network device.

7. 7. The terminal device according to claim 6, wherein the parameters are RAND and / or AUTN.

8. 8. The terminal device of claim 7, wherein the mobile device determines that the length of the root key used by the USIM is 256 bits if the length of the RAND and / or the AUTN is greater than 128 bits.

9. The terminal device according to claim 6, wherein the mobile device determines the length of the root key used by the USIM based on data set by a specification among two bytes of data in the AMF field.

10. A terminal device comprising a mobile device and a USIM in which a root key is stored, The mobile device determines the length of the root key used by the USIM based on the length of a response (RES) included in an authentication response message.

11. 11. The terminal device according to claim 10, wherein the mobile device determines that the length of the root key used by the USIM is 256 bits if the length of a response (RES) included in an authentication response message is longer than 64 bits.

12. 11. The terminal device according to claim 6 or 10, wherein the terminal device is adapted to determine a length of the root key upon request from a network and to communicate supported root key lengths to the network.

13. The terminal device according to claim 6 or claim 10, in which the root key is determined to be less than 256 bits in the authentication and key agreement and the authentication and key agreement are successful, stores the results obtained from the authentication and key agreement, and uses the stored results to generate a key having an entropy higher than the entropy of the root key in subsequent authentication and key agreement.

Images