Devices that use a 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] This invention relates to a technology for informing a Mobile Equipment (ME) of the length of the root key stored in a Universal Subscriber Identity Module (USIM). [Background technology]

[0002] User Equipment (UE) refers to mobile communication devices used by users, such as smartphones. When UEs communicate with each other, they do so via a mobile communication network, such as 5G. This mobile communication network will henceforth be referred to as the "Network (NW)."

[0003] When a terminal device (UE) and a network (NW) communicate wirelessly, they encrypt the messages they send before transmitting them. The receiving end then decrypts the messages. The algorithm used to encrypt messages is called an "encryption algorithm." Furthermore, there is a risk that a third party may tamper with a message during wireless communication. Therefore, the sender creates a code for detecting tampering and attaches that code to the message before sending it. The algorithm used to create this tampering detection code is called a "tampering detection algorithm."

[0004] Current mobile communications, including 5G, use 128-bit tamper detection and encryption algorithms for the radio section between base stations and terminal equipment (UE), and for communication between the core network and terminal equipment (UE). However, 3GPP® (Third Generation Partnership Project) SA3 is considering introducing a 256-bit algorithm. While adding a 256-bit algorithm to specification TS33.501 would allow for the addition of algorithms, the challenge remains that the length of the encryption keys is not standardized.

[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 means that the 256-bit key generated based on that root key will only have 128 bits of entropy. As a result, even though a 256-bit algorithm is being used, the actual strength will only be roughly equivalent to that of a 128-bit algorithm. In such a situation, not only will the expected level of security not be achieved, but computational resources will also be wasted.

[0006] The terminal device UE consists of an ME (Mobile Equipment) and a USIM (Universal Subscriber Identity Module), where the root key is stored and responsible for authentication. The mobile device ME receives the authentication response, key CK, and key IK, and concatenates these keys to derive another key. All of these keys are generated with 256 bits. However, the mobile device ME does not know the length of the root key, nor is it aware of the actual entropy of the key. Currently, the 3GPP® system only supports 128-bit cryptographic algorithms, and keys are truncated to 128 bits before use, so this is not a problem at present. [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 a plurality of authentication protocols. Some authentication protocols use a 128-bit root key, while others use a 256-bit root key. MILENAGE, which is a 128-bit protocol specified in TS35.206, uses a 128-bit root key to generate a 128-bit cipher key CK and a 128-bit integrity key IK. In contrast, TUAK, which is specified in TS35.231, can use a 256-bit root key and can generate a 256-bit cipher key CK and a 256-bit integrity key IK. However, only the USIM and the AuC (Authentication Center), HSS (home subscriber server), or ARPF (Authentication credentials Repository Function) know which protocol is used, and the mobile device ME does not know which protocol is being used.

[0009] In principle, MILENAGE, which is a 128-bit authentication protocol, outputs a 128-bit cipher key CK and a 128-bit integrity key IK, and if the TUAK protocol is configured for 256 bits, it outputs a 256-bit cipher key CK and a 256-bit integrity key IK. However, the interface specification (TS31.102) between the mobile device ME and the USIM only supports 128-bit cipher key CK and 128-bit integrity key IK. Therefore, the mobile device ME is not notified of the used protocol nor the length of the root key, and merely receives 128-bit cipher key CK and 128-bit integrity key IK. Accordingly, the mobile device ME cannot determine whether it is appropriate to use a cryptographic algorithm with a 256-bit length.

[0010] As a simple solution, there is a method of implementing the interface between a mobile device ME and a USIM through 256-bit key exchange. However, in this method, when a new USIM is inserted into a legacy mobile device ME, the mobile device ME waits for 128-bit cipher key CK and 128-bit integrity key IK, while the USIM sends a 256-bit key, so compatibility cannot be ensured. Therefore, there is a need for a method that solves the compatibility problem between USIMs capable of generating 256-bit CK and IK and corresponding mobile devices MEs, as well as between USIMs that generate 128-bit CK and IK and mobile devices MEs corresponding to 256-bit keys, without causing compatibility issues.

[0011] The information exchange between a USIM and a mobile device ME can be summarized as the following (a) to (c). (a) When the mobile device ME is started up, it acquires information such as IMSI (International Mobile Subscriber Identity) and the network to be scanned from relevant files on the USIM. (b) When the user equipment UE is unauthenticated, the mobile device ME next sends an AUTHENTICATE command, and provides RAND (random number) and AUTN (authentication token) to the USIM. (c) The USIM writes the cipher key CK and the integrity key IK into a file accessible by the mobile device ME, and provides RES (response) to the mobile device ME.

[0012] When the length of a root key stored in a USIM is 128 bits, even if a 256-bit key is generated therefrom, only 128 bits of entropy is provided. As a result, despite using a 256-bit algorithm, the actual strength can only provide approximately the same level of security as a 128-bit algorithm. Therefore, by notifying the mobile device ME that the root key stored in the USIM is 256 bits, the 256-bit algorithm is preferentially used, thereby achieving higher security.

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

[0014] The inventors of the present invention have found that a USIM has a file indicating the length of the root key in which it is stored, and that a mobile device ME reads the said file from the USIM, thus completing the present invention.

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

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

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

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

[0019] (5) The file indicating the length of the stored root key in 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 according to 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 the parameters included in the authentication request received from the network device and / or the data in the AMF field.

[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 the data set according to the specifications from among the two bytes of data in the AMF field.

[0024] (10) A third terminal device according to 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 the response (RES) included in the 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, upon receiving a request from the network, determine the length of the root key and transmit the supported root key length to the network.

[0027] (13) The second or third terminal device may, if it is determined in authentication and key sharing that the root key is less than 256 bits and authentication and key sharing is successful, save the result obtained from authentication and key sharing and use the saved result in subsequent authentication and key sharing to generate a key with an entropy higher than the entropy of the root key. [Effects of the Invention]

[0028] According to the present invention, the USIM includes a file indicating the length of the root key in which it is stored, and the mobile device ME reads the file from the USIM, so the mobile device ME can know the length of the root key stored in the USIM, and if the length of the root key stored in the USIM is 256 bits, the USIM can provide 256-bit key CK and key IK, which the mobile device ME can use. [Brief explanation of the drawing]

[0029] [Figure 1] This is a flowchart of the first embodiment of the present invention. [Figure 2] This figure shows step S6 adjusted for a second embodiment of the present invention. [Figure 3] This figure shows the details of the certification of the third and fourth embodiments of the present invention. [Figure 4] This figure shows the key derivation process in an embodiment of the present invention. [Modes for carrying out the invention]

[0030] Embodiments of the present invention will be described below with reference to the drawings. To address the problem, I propose two main solutions. The first solution involves adding a file to the USIM indicating that it possesses a 256-bit root key. The mobile device ME recognizes that the USIM possesses a 256-bit root key by reading this file from the USIM. If the USIM possesses a 256-bit root key, the mobile device ME configures it to use the 256-bit algorithm; otherwise, it disables the 256-bit algorithm. In this specification, examples of applying the first solution are described as the first and second embodiments.

[0031] The second solution involves the mobile device ME checking the field length and other information from the request or response it receives, and then determining whether the USIM uses a 256-bit root key based on that information. If it is confirmed that the USIM supports 256 bits, the mobile device ME configures itself to use a 256-bit algorithm. In this specification, examples of applying the second solution are described as the third and fourth embodiments. Neither of the proposed methods affects the functionality of legacy mobile devices (MEs), and the USIM operating on legacy mobile devices (MEs) remains unchanged.

[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 USIM. (1) Add a new file to USIM that indicates that USIM possesses a 256-bit key. (2) A 256-bit compatible mobile device ME reads the file mentioned in (1) above and confirms that the USIM is 256-bit compatible. If the file mentioned in (1) above does not exist, the mobile device ME determines that the USIM may not be 256-bit compatible. (3) In algorithm negotiation with the serving network, the mobile device ME will enable the 256-bit encryption algorithm if the USIM is 256-bit compatible. If the USIM is not 256-bit compatible, it will disable the 256-bit encryption algorithm.

[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 USIM. (1) Add a new file to USIM that indicates that USIM possesses a 256-bit key. (2) A 256-bit compatible mobile device ME reads the file mentioned in (1) above and confirms that the USIM is 256-bit compatible. If the file mentioned in (1) above does not exist, the mobile device ME determines that the USIM may not be 256-bit compatible. (3) When using the AUTHENTICATE command, the mobile device ME notifies the USIM that it wants to use a 256-bit algorithm if the USIM is 256-bit compatible. (4) The USIM returns a 256-bit key, and the mobile device ME enables 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 a mobile device ME alone. (1) Upon receiving an authentication request, the mobile device ME inspects the authentication request and verifies the following: a. Length of each input parameter b. Set AMF bit (2) If a predefined value is set, the mobile device ME will determine that the USIM is using a 256-bit root key and will configure it 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 a mobile device ME alone. (1) Upon receiving the Authenticate Response, the mobile device ME checks the length of the RES (response) and verifies 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 device ME determines that the USIM is using a 256-bit root key and configures it to use a 256-bit algorithm.

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

[0037] Step S2: The mobile device ME scans the file system and loads the relevant data into memory (IMSI, PLMN ID, etc.). Step S3-a: The 256-bit compatible mobile device ME searches for a file indicating that the USIM is 256-bit compatible. If found, it sets the bit in memory to 1 to indicate that the USIM is 256-bit compatible. 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 compatible mobile device ME searches for a file indicating the root key length, and if found, retrieves the root key length from the file. If the root key length is 128 bits, the mobile device ME sets a bit in memory to indicate that it will use a 128-bit algorithm. If the root key length is 256 bits, the mobile device ME sets a bit in memory to indicate that the USIM is 256-bit compatible.

[0039] In addition to the above, if the root key length is 512 bits, the mobile device ME sets a bit to indicate that the root key is 512 bits. While there are currently no plans to introduce 512-bit cryptographic algorithms, this can be used in the future if we expand to other key sizes. Furthermore, if the root key length is greater than the key size required for the algorithm (for example, if the root key length is 512 bits and the mobile device ME is 256-bit compatible but does not support 512-bit algorithms), the mobile device ME can also enable an algorithm with a sufficient key size (in the above example, a 256-bit algorithm).

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

[0041] In step S4, the above logic is executed on the mobile device ME. As a result of the logic being executed, the mobile device ME creates a list of security functions to provide to the network NW. In conventional technology, the security functions of the terminal device UE are a list of cryptographic algorithms supported by the mobile device ME, regardless of the root key size. In this first solution, the mobile device ME obtains a list of all cryptographic algorithms and removes algorithms from the list for which it cannot secure a sufficient key length. An example of this operation is shown below.

[0042] [Table 1]

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

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

[0045] Subsequently, if the network NW prioritizes the AEAD algorithm and supports 512-EA7, it selects this algorithm and the corresponding tamper detection algorithm. Here, let's assume the network NW selected 512-IA7 to match the previously selected encryption algorithm. The network NW sends a Secure Mode Command (a message indicating the selected algorithm), specifying 512-EA7 as the encryption algorithm and 512-IA7 as the tamper detection algorithm. Since the mobile device ME only supports 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] Although the AEAD algorithm is assumed to be 512-EA7 above, it is possible that algorithms other than 512-bit keys may also be used for AEAD. Therefore, 128-bit and 256-bit AEAD can also be selected in the same way, and there is no need to add a column indicating the AEAD algorithm.

[0047] The difference between selecting the EA and IA algorithms and selecting the AEAD algorithm lies in the fact that the network (NW) prioritizes the AEAD mode algorithm. Let's assume that the mobile device (ME) supports the following algorithms: the encryption algorithm 512-EA6, the tamper detection algorithm 512-IA6, and the AEAD algorithm 512-EA7.

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

[0049] When the same algorithm is referred to as 512-EA7, encryption and tamper detection can be realized in one operation. In the 3GPP (registered trademark) specification, this means that 512-EA7 uses only one key as an input. For example, k NASenc , k RRCenc , k UPenc , k NASint , k RRCint , k UPint any one of them can be used to realize cipher and message authentication code (MAC) calculation. When 512-EA6 is used together with 512-IA6, two different keys are used even if they are the same algorithm as 512-EA7. One is used as an input to the cipher algorithm (k NASenc , k RRCenc , k UPenc ), and the other is used as an input to the tamper detection algorithm (k NASint , k RRCint , k UPint ).

[0050] Therefore, even if 512-EA6 and 512-EA7 use the same algorithm, if the network NW prioritizes AEAD, the network NW will select 512-EA7, which is AEAD. After confirming that it supports AEAD, the network NW will select 512-IA7, which is pre-configured as the IA algorithm corresponding to the selected AEAD, and notify the mobile device ME to use 512-EA7 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 may still be specified.

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

[0052] [Table 2]

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

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

[0055] If authentication is successful in step S6, in step S7, the network NW sends a Secure Mode Command (SMC) to the terminal device UE. When it is sent from the AMF (Access and Mobility Management Function) to the terminal device UE, it is called a NAS SMC, and when it is sent from the 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 achieved, but the method described below can be applied equally to both NAS security and RRC security.

[0056] The network NW compares the security features of the received terminal device UE with the security features of the network NW to determine which algorithm to use. Since the mobile device ME eliminates algorithms that require a key size larger than the root key size, the network NW can select only algorithms with sufficient root key length. This eliminates the need for the AMF and base station gNB to notify the root key length, and also eliminates the need for additional logic at each node to consider the root key length. Furthermore, this embodiment prevents resource consumption due to the selection of algorithms that use unnecessarily long keys, thereby achieving power savings and low costs.

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

[0058] [Second Embodiment] The second embodiment performs the actions disclosed in Figure 2 in addition to those of the first embodiment. In step S6 of Figure 1, the mobile device ME uses the AUTHENTICATE command to send RAND (random number) and AUTN (authentication token) to the USIM. If authentication is successful, the USIM returns RES (response), key CK, and key IK. At this time, a 256-bit (or 512-bit) compatible mobile device ME can determine the key length supported by USIM (128-bit, 256-bit, 512-bit, etc.) from the results of steps S1 to S4. However, since USIM is not aware of the capabilities of the mobile device ME, it provides the mobile device ME with only a 128-bit key CK and key IK.

[0059] Therefore, in the second embodiment, step S6.1 is modified so that the mobile device ME instructs the USIM to provide a key of a specific length. To achieve this, the mobile device ME adds a new field to include the required key length in the AUTHENTICATE command. Alternatively, this can be achieved by updating the USIM to support AUTHENTICATE commands of different 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 length of input keys 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 expected that this will be notified using ABBA parameters).

[0060] The mobile device ME requests the USIM to use the minimum of the three values ​​mentioned above as the key length. For example, if the root key is 256 bits and the mobile device ME supports 512 bits, the mobile device ME will request 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 512-bit cryptographic algorithms, the mobile device ME will request a 512-bit key.

[0061] USIM performs authentication in step S6.2, executes the algorithm, derives a key, and provides a key of the required length in step S6.3. A key of the required length means that either the key CK and key IK each have the required length, or the concatenation of the key CK and key IK has the required length.

[0062] [Third and Fourth Embodiments] The third and fourth embodiments relate to the mobile device ME and are performed in step S6 of Figure 1. Details of the communication between the mobile device ME and the USIM in step S6 are shown in Figure 3. Figure 3 shows the USIM, the mobile device ME, and the network NW. The 5G mobile network NW spans the Home PLMN and the Visited PLMN and consists of several different network functions.

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

[0064] In the case of EAP-AKA', the ARPF (Authentication credentials Repository Function) generates EAP-AKA' AV (RAND, AUTN, XRES, CK', IK') and forwards it to the AUSF (authentication server function). The AUSF forwards RAND (random number) and AUTN (authentication token) in the authentication response message to the SEAF / AMF, and the SEAF / AMF forwards 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 along with the key CK and key IK. The mobile device ME then sends the RES (response) to the SEAF, which (after an optional comparison step) forwards it to the AUSF.

[0066] 4G networks also perform authentication and key sharing in a similar manner. The home network's HSS (Home Subscriber Server) prepares authentication vectors (RAND, AUTN, XRES, KASME) and sends them to the visiting network's MME (Mobility Management Entity). The MME sends an authentication request to the terminal device UE via the access network, and the terminal device UE responds with an RES (Response).

[0067] Figure 3 shows the operation on the network side (NW). In step S21, each network function generates an authentication request consisting of at least RAND (random number) and AUTN (authentication token). In step S22, 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 verifies RAND (random number) and AUTN (authentication token), and in step S24, it uses the AUTHENTICATE command to transfer RAND (random number) and AUTN (authentication token) to the USIM.

[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, key IK, and RES (response) from the USIM. In step S27, the mobile device ME can also verify the RES (response) and the key. In some authentication methods, the RES (response) may be modified in step S27. For example, the RES (response) may be concatenated with the network ID or mobile ID and entered 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 explained above, the mobile device ME is not notified of whether the root key is 128 bits or 256 bits, so the mobile device ME cannot determine the length of the root key. Therefore, the USIM or network NW notifies the mobile device ME of the length of the key being used.

[0070] For example, a mobile device (ME) can verify the 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 128-bit random number generated by the home network. AUTN (authentication token) is a 128-bit value composed of the concatenation of three fields of different lengths. 48 bits: Sequence Number (SQN) encrypted by XORing with Anonymity Key (AK). 16-bit: Authentication Management Field, AMF 64-bit: Message Authentication Code, MAC

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

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

[0073] Option 1: (Third Embodiment) The mobile device ME checks the lengths of the RAND (random number) and AUTN (authentication token) parameters, and if either of these is greater 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 set by the standard. Currently, one AMF bit is set, indicating that authentication is being performed for a 3G or higher network (LTE or 5G). Therefore, by setting another bit to indicate that it is a 256-bit compatible authentication method, the mobile device ME determines that the root key is 256 bits.

[0075] Option 3: (Fourth Embodiment) The mobile device ME checks the length of the RES (Response). MILENAGE outputs a 64-bit RES, while TUAK outputs a 32-bit to 128-bit RES. Therefore, if a carrier configures a USIM using TUAK to return a 128-bit RES, the mobile device ME can determine from the length of the RES that "the carrier has configured a 256-bit TUAK algorithm within the USIM." The three options above are backward compatible, and older mobile devices (ME) simply accept long values. Furthermore, since these fields are already in use, they can be implemented without any modifications.

[0076] Option 4: The network (NW) transmits the required key length or key generation algorithm, and the mobile device (ME) verifies whether the USIM can meet those requirements. For example, a network can notify this using an Identity Request that it sends initially. EAP-AKA' requests an identifier using the EAP-AKA' / AKA-Identity Request message defined in RFC4187. This message includes one of the following attributes: AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, or AT_FULLAUTH_ID_REQ. Each of these attributes has 2 bytes (16 bits) reserved for future feature additions. A network can include the use of a 256-bit algorithm for the ID request by setting one of these bits.

[0077] Legacy terminal UEs ignore these bits, so setting them does not affect their operation. Updated terminal UEs can check if the bits are set, check if they support the required key length, reply with their own ID in an Identity Response message, and add new attributes such as AT_KEYLENGTH to indicate that the terminal UE supports a 256-bit key length.

[0078] This method can support not only 128-bit and 256-bit keys, but also keys of other lengths by extending the bits in the Identity request message.

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

[0080] Option 5: If the key length required by the network is not supported by USIM, it may be possible to use pre-shared randomness to generate a longer root key. Randomness can be extracted from messages such as RES (Responses) and MAC (Message Authentication Codes) exchanged in past sessions. However, the shared randomness must be input into the authentication algorithm (such as TUAK) or the visiting network for key derivation.

[0081] Option 5-1: If the initial authentication (n=1) is successful, the network NW and USIM store the RES (Response) and MAC (Message Authentication Code) used in this authentication. If authentication fails, the RES (Response) and MAC (Message Authentication Code) are not stored.

[0082] In subsequent authentication (n=m), the USIM and the network NW use the persistent root key k as RES. m-1 and MAC m-1 Connect to k m The input parameters are changed by creating [this]. The authentication algorithm is k as usual. m If you take k instead, and it is successful, USIM and network NW will be RES m and MAC m RES m-1 and MAC m-1 Overwrite the previous value. In the next authentication run (n=m+1), the USIM and network NW will use the newly saved parameter RES. m and MAC m Using k m+1 Create one, and continue creating others in the same manner. If authentication fails, both the USIM and the network (NW) will clear the parameters and re-authenticate.

[0083] Option 5-2: This process is similar to option 5-1, but differs in how the terminal device UE and the network NW store the random source. In this case, since the visiting network is involved, the terminal device UE needs to maintain a registry of previous RES (Responses) and MAC (Message Authentication Codes) obtained from successful authentication to this network NW. The mobile device ME maintains a registry as shown below:

[0084] [Table 3]

[0085] In option 5-1, a random source is inserted into the authentication algorithm, but in option 5-2, KAMF to K SEAF A random source is used in the key derivation derived from the input S of the Key Derivation Function (KDF). Specifically, the terminal device UE and the network NW use the following parameters to derive K SEAF From K AMF Derive the following. 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 then, input key K SEAF This is used. Compared to conventional technology, two new parameters have been set, and the length of each has been added. As an alternative, input key K SEAF The MAC (Message Authentication Code) and RES (Response) are concatenated into K SEAF´ It is also possible to create a [this], in which case the input key is K. SEAF Not K SEAF´ It will become. Other than that, the operation is the same as option 5-1, and for the first authentication to PLMN (n=1), the RES (response) and MAC (message authentication code) used for this authentication are saved only if the authentication is successful. If authentication fails, the RES (response) and MAC (message authentication code) are not saved.

[0087] In the subsequent authentication (n=m), the terminal device UE and the network NW are K SEAFModify the derivation as described above. If NAS security can be successfully established (not only indicating successful authentication, but also indicating that the key was properly derived), the terminal device UE and SEAF (Security Anchor Functionality) will be RES m-1 and MAC m-1 to m and MAC m It will be overwritten. In the next authentication run (n=m+1), the terminal device UE and SEAF will use these parameters K SEAF To generate the newly saved parameter RES m and MAC m Use this. If authentication fails, both the terminal device UE and SEAF will clear the parameters and re-authenticate.

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

[0089] This invention enables mobile devices to use cryptographic algorithms and / or tamper detection algorithms that match the length of the root key stored in the USIM, thereby contributing to Goal 9 of the United Nations-led Sustainable Development Goals (SDGs), "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, The aforementioned USIM is a terminal device that includes a file indicating the length of the root key stored within it.

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

3. The terminal device according to claim 2, wherein the mobile device creates a list of supported algorithms and removes algorithms with a key length longer than the length of the root key stored in the USIM from the list.

4. The terminal device according to claim 2, wherein the mobile device specifies the required key length to the USIM using the AUTHENTICATE command.

5. The terminal device according to any one of claims 1 to 4, 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 aforementioned mobile device is a terminal device that determines the length of the root key used by the USIM based on the length of the parameters included in the authentication request received from the network device and / or the data in the AMF field.

7. The terminal device according to claim 6, wherein the parameter is RAND and / or AUTO.

8. The terminal device according to claim 7, wherein the mobile device determines that the length of the root key used by the USIM is 256 bits when the length of RAND and / or AUTO is longer 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 the data set according to the specifications from among the 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 is a terminal device that determines the length of the root key used by the USIM based on the length of the response (RES) contained in the authentication response message.

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 when the length of the response (RES) included in the authentication response message is longer than 64 bits.

12. The terminal device according to claim 6 or 10, wherein the terminal device receives a request from the network, determines the length of the root key, and transmits the supported root key length to the network.

13. A terminal device according to claim 6 or 10, wherein authentication and key sharing are successfully performed, and the root key is determined to be less than 256 bits, the terminal device according to claim 6 or 10, wherein the results obtained from authentication and key sharing are stored, and the stored results are used in subsequent authentication and key sharing to generate a key with an entropy higher than the entropy of the root key.

Images