Device for notifying length of common key

Abstract

An ABBA parameter is included in a message transmitted in step (S10) from a SEAF to a base station gNB. The ABBA parameter is used to notify a terminal device UE that a network NW side is compatible with the 256-bit encryption algorithm. This is realized by using four bits in the ABBA parameter, for example as follows: "0001: RAN is compatible with 256 bits"; and "0010: AMF is compatible with 256 bits". Such a configuration of the ABBA parameter notifies the terminal device UE that the RAN or the AMF is compatible with the 256-bit encryption algorithm.

Description

A device that notifies the length of the common key

[0001] The present invention relates to a technique for sharing the length of a common key for a cryptographic algorithm between a terminal device (UE) and a network (NW) in mobile communications. This application claims priority to Japanese Patent Application No. 2023-184320, filed on October 26, 2023, the contents of which are incorporated herein by reference.

[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 will be referred to as a "network NW" hereinafter.

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

[0004] Current mobile communications, including 5G, use cryptographic algorithms with a 128-bit common key length for wireless communication between base stations and terminal devices UE and for communication between core networks and terminal devices UE. Hereinafter, cryptographic algorithms with a 128-bit common key length will be referred to as "128-bit algorithms." Similarly, cryptographic algorithms with a 256-bit common key length will be referred to as "256-bit algorithms."

[0005] Currently, the introduction of a 256-bit algorithm as an encryption algorithm is being considered. Simply including a 256-bit algorithm in the specifications will not change the communication method between the network NW and the mobile phone or the operation of the network NW. Therefore, depending on the AMF or base station (gNB) to which the terminal device UE is connected, the connection security level may be 128 bits or 256 bits, which can pose a problem in that the security level is not unified.

[0006] 3GPP (registered trademark) TS33.4013GPP (registered trademark) TS33.501

[0007] Therefore, it is necessary to confirm that 256 bits are supported between the terminal device UE and the network NW.

[0008] The inventors discovered that data indicating the number of bits of the common key cryptographic algorithm that the network device supports could be included in the message sent from the network device to the terminal device, and this led to the completion of the present invention.

[0009] (1) A network device according to one embodiment of the present invention includes data indicating the number of bits of a common key encryption algorithm that the network device supports in a message sent from the network device to a terminal device, and transmits the message to the terminal device. (2) The network device according to (1) above may include data indicating the number of bits of a common key encryption algorithm that the network device supports in an adaptive Brownian bridge-based symbolic aggregation of time series (ABBA) parameter in the message sent from the network device to the terminal device. (3) The network device according to (2) above may also specify an encryption algorithm using the ABBA parameter. (4) A terminal device according to one embodiment of the present invention receives a message sent from a network device including data indicating the number of bits of a common key encryption algorithm that the network device supports, and notifies the network device of security functions for the encryption algorithm of the terminal device using a tamper detection algorithm different from the tamper detection algorithm selected by the network device. (5) In one embodiment of the present invention, a terminal device includes, in a Globally Unique Temporary UE Identity (GUTI) in an initial connection message sent to a network device, data indicating the number of bits of a shared key encryption algorithm supported by the previously connected Access and Mobility Management Function (AMF). (6) In one embodiment of the present invention, a terminal device includes, in Network Slice Selection Assistance Information (NSSAI) in a message sent to a base station, data indicating the number of bits of a shared key encryption algorithm the terminal device requests to use. (7) The network device described in (1) above includes, in a System Information Block (SIB) in a message sent from the network device to the terminal device, data indicating the number of bits of a shared key encryption algorithm supported by the network device.(8) In one embodiment of the present invention, a terminal device rejects an access stratum security mode command (AS Security Mode Command) when the length of the common key of the encryption algorithm supported by the terminal device does not match the length of the common key of the encryption algorithm presented in the access stratum security mode command message received from a base station. (9) In one embodiment of the present invention, a terminal device receives a message transmitted from the network device of (7), ranks the received system information blocks SIBs according to whether they support a 256-bit encryption algorithm, and selects a network node to connect to based on received signal strength and encryption strength.

[0010] According to the present invention, a network device notifies a terminal device of the number of bits of the common key cryptographic algorithm that the network device supports, so that negotiation can be carried out between the network device and the terminal device regarding the cryptographic algorithm to be used.

[0011] FIG. 10 is a sequence diagram (first half) showing procedures for authentication, key agreement, and NAS SMC between a terminal device UE and a network NW of an embodiment. FIG. 11 is a sequence diagram (second half) showing procedures for authentication, key agreement, and NAS SMC between a terminal device UE and a network NW of an embodiment. FIG. 12 is a diagram showing an example of a man-in-the-middle attacker tampering with a message in an embodiment. FIG. 13 is a sequence diagram showing a procedure for selecting a network slice instance in an embodiment. FIG. 14 is a diagram showing a procedure for selecting a cell in an embodiment. FIG. 15 is a diagram showing a terminal device of an embodiment collecting SIBs of receivable base stations. FIG. 16 is a diagram showing an example result of a terminal device of an embodiment assigning priorities to base stations. FIG. 17 is a diagram showing a terminal device of an embodiment transmitting an attach request to a cell with the strongest signal strength. FIG. 18 is a diagram showing a cell with a priority of 1 in a sixth embodiment of the present invention. FIG. 19 is a flowchart showing assignment of priorities in a sixth embodiment of the present invention.

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0013] 1 and 2 are sequence diagrams showing a series of procedures, illustrating authentication, key agreement, and NAS (Non-Access-Stratum) SMC (Secure Mode Command) procedures between a terminal device UE and a network NW in the prior art and an embodiment of the present invention. When the terminal device UE is powered on, a random access procedure is performed in step S1, and then an RRC connection procedure is performed in step S2. After this, initial connection and authentication are performed.

[0014] In step S3, the terminal device UE sends an initial connection message to the base station gNB. The initial connection message includes the security capabilities of the terminal device UE and a Globally Unique Temporary UE Identity (GUTI) or a Subscription Concealed Identifier (SUCI). In step S4, the base station gNB forwards the initial connection message to the Access and Mobility Management Function (AMF) / Security Anchor Functionality (SEAF) of the core network. In step S5, if the initial connection message includes a SUCI or Subscription Permanent Identifier (SUPI), that is, if the terminal device UE has not yet been authenticated, the AMF / SEAF starts an authentication procedure with the Unified Data Management (UDM) / Authentication Server Function (AUSF) / Authentication Credentials Repository Function (ARPF).

[0015] In step S6, the SEAF sends a Nausf_UEAuthentication_Authenticate Request message to the AUSF. This message includes SUCI or SUPI. In step S7, the AUSF checks whether the SEAF that sent the request message is allowed to use the service network name. In step S7, the AUSF temporarily stores the received service network name and sends a Nudm_UEAuthentication_Get Request message including SUCI or SUPI and the service network name to the UDM / ARPF / SIDF (Subscription Identifier De-concealing function).

[0016] In step S7, when the UDM receives the Nudm_UEAuthentication_Get Request message, if SUCI is received, the UDM calls the SIDF to decrypt the SUCI and obtain the SUPI. In step S7, based on the SUPI, the UDM / ARPF selects whether to use EAP (Extensible Authentication Protocol)-AKA' or 5G-AKA (Authentication and Key Agreement). In step S7, the UDM / ARPF generates an authentication vector (AV) consisting of (RAND, AUTN, XRES, CK', IK') and sends the authentication vector AV to the AUSF together with the Nudm_UEAuthentication_Get Response.

[0017] If the authentication method is set to 5G-AKA, the AUSF sends a message including an AKA Challenge message to the SEAF in step S8. At this time, the AKA-Challenge message also includes the expected response. The SEAF forwards this to the base station gNB in ​​step S10. The message sent to the base station gNB in ​​step S10 includes an Authentication Request message, which is a NAS (Non-Access-Stratum) message. This Authentication Request message sent in steps S10 and S12 includes an ngKSI (5G system key configuration identifier) ​​and an ABBA parameter set to 0x0000 according to TS 33.501.

[0018] In step S12, the base station gNB forwards the received message to the terminal device UE. In step S13, the terminal device UE calculates a response from the received message and checks whether the AUTN (authentication token) is correct. If the AUTN is correct, in step S14, the terminal device UE sends a message as a response, which the base station gNB forwards to the SEAF in step S16.

[0019] If EAP-AKA' is selected as the authentication method, the SEAF transfers the response received in step S16 to the AUSF in step S18. On the other hand, if 5G-AKA is selected as the authentication method, in step S17, the SEAF compares the response from the terminal device UE with the hash value of the expected response received from the AUSF in step S8, and if they match, transfers the expected response to the AUSF in step S18. In step S19, the AUSF compares the response from the terminal device UE with the expected response. If they match, it sends the anchor key KSEAF and SUPI to the SEAF in the Nausf_UEAuthentication_Authenticate Response in step S20.

[0020] In step S21, the SEAF verifies that the AUSF has successfully authenticated the terminal UE. If the terminal UE has been successfully authenticated, in step S22, the AMF sends an authentication success message to the terminal UE. In step S21, the AMF creates a NAS message called Secure Mode Command. This message includes the security capabilities of the terminal UE, the tamper detection and encryption algorithm selected by the AMF, and optionally the ABBA parameters and ngKSI. The base station gNB receives the message and forwards the NAS message to the terminal UE in step S24.

[0021] In step S25, the terminal apparatus UE verifies the message using a tampering detection function to verify that the security capabilities of the terminal apparatus UE have not been tampered with. If everything is OK, the terminal apparatus UE sends a Secure Mode Complete message to the AMF via the base station gNB (steps S26 and S27). This Secure Mode Complete message includes the security capabilities of the terminal apparatus UE and the requested NSSAI.

[0022] In step S28, the AMF verifies that the received message can be correctly decrypted and has not been tampered with, and then sends a registration accept message in step S29. The registration accept message includes the authorized NSSAI, the new GUTI assigned to the terminal device UE, and network supported capabilities, etc. The authentication, key agreement, and NAS SMC procedures in the prior art and embodiments of the present invention have been described above.

[0023] The present invention uses a conventional message to notify the terminal device UE from the network NW side that the network NW side supports the 256-bit algorithm. [First embodiment] Notification of 256-bit compatibility using ABBA parameter The message transmitted from the SEAF to the base station gNB in ​​step S10 of FIG. 1 includes the ABBA parameter. This ABBA parameter is used to notify the terminal device UE that the network NW side supports the 256-bit algorithm. For example, this is realized as follows using 4 bits of the ABBA parameter. 0001: RAN is capable of supporting 256 bits 0010: AMF is capable of supporting 256 bits

[0024] By setting this ABBA parameter, the terminal apparatus UE is notified that the RAN or AMF is capable of supporting 256 bits. Therefore, the terminal apparatus UE can use the ABBA parameter in step S25 of the procedure of Figure 2 as follows: 1. If the ABBA parameter is set to 0010 and the terminal apparatus UE is capable of supporting 256 bits, the terminal apparatus UE can check whether the network NW has selected a 256-bit algorithm. a. If a 256-bit algorithm is selected, the terminal apparatus UE accepts the message and sends a Secure Mode Complete message protected by the selected algorithm. b. If a 256-bit algorithm is not selected, the terminal apparatus UE rejects the Secure Mode Command sent in step S24 and sets a bit in the rejection message indicating that it desires to use the 256-bit algorithm.

[0025] However, even if it is called a "256-bit security algorithm," there are multiple types of "256-bit security algorithms." If the terminal device UE and the network NW do not support the same type of 256-bit security algorithm, the AMF may select a 128-bit algorithm, which may be rejected by the terminal device UE. Therefore, the following method is used to solve this problem.

[0026] (Method 1) By adding a new field to the NAS Secure Mode Command to indicate "256-bit compatible algorithm selection error," the terminal UE is notified that there is no 256-bit algorithm supported by both the AMF and the terminal UE. If this bit is set, the terminal UE accepts the 128-bit algorithm selected by the AMF. (Method 2) Logic based on the UE security capabilities sent by the terminal UE in steps S3 and S4 is added to the SEAF. If the terminal UE indicates that it supports 256-bit encryption, the SEAF checks whether the network supports the same type of algorithm, and if so, sets the ABBA parameter as described above to indicate that the AMF or RAN supports the 256-bit algorithm. However, if there is no common algorithm, the SEAF does not set the ABBA parameter, thereby indicating that it cannot select a 256-bit algorithm. If the ABBA parameter is not set, the terminal UE accepts the 128-bit algorithm.

[0027] In this embodiment, it is important that the terminal device UE confirms that the security capabilities it sent in step S3 match the security capabilities it received in step S12, thereby preventing attacks by a man-in-the-middle (MIM) located between the terminal device UE and the network NW (hereinafter referred to as a "man-in-the-middle attack"). Furthermore, unless the tampering detection algorithm is attacked within a reasonable time, an attacker cannot force the terminal device UE to select the 128-bit algorithm. If a serious vulnerability is found in the 128-bit algorithm, it is safer to reject the NAS Secure Mode Command if the 256-bit algorithm is not selected.

[0028] [Second embodiment] Method of specifying a 256-bit algorithm using an ABBA parameter In addition to the first embodiment, it is also possible for the SEAF to select the type of algorithm and notify the terminal device UE using the ABBA parameter. This will be explained using Figures 1 and 2. The SEAF receives the security capabilities of the terminal device UE in the message of step S4, and in step S5, the SEAF checks whether the security capabilities of the terminal device UE include a 256-bit algorithm. If the terminal device UE can use a 256-bit algorithm, the SEAF selects the 256-bit NAS encryption / tamper detection algorithm with the highest priority supported by the terminal device UE (it is also possible to select a RAN security algorithm in the same way).

[0029] After the selection by SEAF is completed, SEAF specifies the selected algorithm in the ABBA parameter. For example, it is possible to specify the algorithm as shown in Table 1 using the first byte. The second byte is set as shown in Table 2.

[0030] The SEAF operates as in Method 3 or Method 4 below. (Method 3) The SEAF is configured with a prioritized list of algorithms for the AS and NAS, and uses the same logic that the base station gNB and AMF use to select an appropriate algorithm. In this case, the SEAF needs to notify the base station gNB and AMF of the algorithm it has selected, which can be explicitly notified by a new message called "Algorithm Selected by SEAF." Alternatively, the base station gNB and AMF can be configured to check the ABBA parameters and set the selected algorithm. (Method 4) The SEAF sends an "Algorithm Selection Request" including the security capabilities of the terminal device UE to the AMF and base station gNB, and sets the corresponding bits of the ABBA parameters based on the responses of the AMF and base station gNB.

[0031] The ABBA parameter is K ＡＭＦSince the ABBA parameter is used in the derivation of the 128-bit algorithm and is independent of the selected algorithm, it can be used to select the 256-bit algorithm even if a vulnerability is found in the 128-bit algorithm. Also, if the terminal device UE does not support the 256-bit algorithm, the ABBA parameter is not set, so it is possible to connect a legacy terminal device UE to the network.

[0032] If the ABBA parameter is set, the 256-bit compatible terminal device UE verifies in step S25 that the message received in step S24 indicates the same algorithm. If the same algorithm is not indicated, the terminal device UE must reject the SMC (Secure Mode Command) using an SMC rejection message and indicate an algorithm mismatch as the cause. This allows the AMF to know the reason why the terminal device UE rejected the NAS Secure Mode Command sent in step S24.

[0033] [Third Embodiment] Exchanging UE Security Capabilities If an attacker exists between a terminal device UE and a network NW, even if both the terminal device UE and the network NW support a 256-bit algorithm, an attack is possible in which the attacker tamper with messages to select a weaker algorithm. An example of an attacker tampering with messages will be described using FIG. 3. FIG. 3 shows the same flow as FIG. 1 and FIG. 2, but only shows NAS messages between the terminal device UE and the AMF, and shows a procedure in which a Man-in-the-middle (MITM) (short for Att) tamper with messages. Tampered messages have "'" added.

[0034] The unauthenticated terminal UE sends a registration request or initial NAS message M1, which includes UE security capabilities and other elements. The attacker Att deletes all UE security capabilities except those that can be attacked. For example, if the terminal UE sends in message M1 that it supports the following encryption algorithms: 128-NEA1, 128-NEA2, 128-NEA3, 256-NEA4, 256-NEA5, and 256-NEA6, and the following tamper detection algorithms: 128-NIA1, 128-NIA2, 128-NIA3, 256-NIA4, 256-NIA5, and 256-NIA6, the attacker Att tampers with message M1 to make it appear as if it supports only the attackable algorithms. For example, if 128-NEA2 and 128-NIA2 are attackable, the attacker tampers with the message, assuming that only these two are supported. Then, the attacker Att sends the tamped message 1' to the AMF.

[0035] The AMF responds with a normal authentication request message M2, which the attacker forwards to the terminal UE without modifying it. The terminal UE processes the authentication request message, verifies its validity, and if valid, creates an authentication response message M3, which the attacker forwards to the AMF without modifying it.

[0036] The AMF then selects an algorithm based on the UE security capabilities received in message M1' modified by the attacker, and sends a Secure Mode Command message M4 to the terminal device UE protected by the tamper detection algorithm selected by the attacker Att. Since the SMC message includes the UE security capabilities received in message M1', the attacker Att obtains message M4, replaces the UE security capabilities with those of message M1, and verifies that the MAC (Message Authentication Code) matches the message. The modified message is sent to the terminal device UE as message M4'.

[0037] When the terminal UE receives message M4', it verifies that the UE security capabilities are correct and the MAC, and if correct, uses the selected encryption and tamper detection algorithm. The terminal UE then creates a Secure Mode Complete message M5, encrypts it with the selected algorithm, and protects it with the tamper detection algorithm.

[0038] The attacker Att checks message M5 and checks whether the UE security function is included. If it is included, the attacker again modifies the UE security function, encrypts the message, and ensures that the MAC matches the message. The attacker sends message 5' to the AMF, and the AMF considers that the NAS SMC is completed, and the authentication of the terminal device UE is completed.

[0039] The above attack by the attacker Att can be solved by the following steps: 1) securely notifying the terminal device UE that a 256-bit algorithm is available in the core network, and 2) notifying the AMF of security capabilities without using the selected algorithm, so that the AMF can verify that the message has not been tampered with by a man-in-the-middle attacker (Att).

[0040] Specifically, the process is as follows: Step 1: During the authentication process, the SEAF uses the ABBA parameter to indicate that the core network is 256-bit capable or to indicate the algorithms supported by the core network. The SEAF includes the ABBA parameter in message M2 of FIG. 3. Step 2: During Secure Mode Complete, the terminal device UE verifies that the message has not been tampered with and verifies the received UE security capabilities. Furthermore, the terminal device UE adds a MAC of the UE security capabilities using a different tamper detection algorithm in addition to the selected tamper detection algorithm. Here, the "algorithm different from the selected tamper detection algorithm" must be an algorithm supported by both the terminal device UE and the network, and can be, for example, Key Derivation Function (KDF) or HMAC-SHA-256.

[0041] When the terminal device UE generates a MAC using KDF, K NASint_256 Using this as the key, the MAC for the Initial NAS message can be calculated as follows: UE_Capabilities_Hash = KDF(K NASint_256 , Initial NAS message) Similarly, the MAC for UE Security Capabilities can be calculated as follows: UE_Capabilities_Hash = KDF(K NASint_256 , UE Security Capabilities) The terminal device UE includes this in a Secure Mode Complete message and sends it to the AMF.

[0042] Step 3: The AMF receives the Secure Mode Complete message and calculates the MAC for the UE security function. If the results match, the AMF can determine that the correct algorithm has been selected. If the results do not match, the AMF reconfigures the NAS security protocol using the newly selected algorithm and sends a NAS Secure Mode Command to the UE again, and repeats the above process from step 1.

[0043] The key used for MAC calculation may be any key that can be used by the AMF and the terminal device UE, and the following may be assumed: K, which is the root key of the AMF ＡＭＦ -K ＮＡＳＩｎｔ and K. ＮＡＳＥｎｃ Any of these keys may be input to the KDF as long as the terminal device UE and the AMF use the same key. However, if a 128-bit algorithm is selected, the session key is typically truncated to 128 bits, and the 256-bit key may be discarded. Therefore, the input key is a 128-bit K ＮＡＳＩｎｔ and K. ＮＡＳＥｎｃ may be connected together.

[0044] This embodiment can prevent attacks that force the selection of a 128-bit algorithm as follows: Since the ABBA parameters are used as input for key derivation, if an attacker tampers with the ABBA parameters, the generated K ＡＭＦ changes. ＡＭＦ With input K ｇＮＢ , K. ＮＡＳｉｎｔ , K. ＮＡＳｅｎｃ Therefore, tampering with the ABBA parameters will generate different keys between the terminal device UE and the AMF, resulting in a failure to establish a connection. If the terminal device UE supports a 256-bit algorithm, an additional MAC is assigned in addition to the 32-bit MAC assigned in the conventional technology. The AMF can determine whether the terminal device UE supports the 256-bit algorithm by checking the additional MAC. The AMF verifies the two MACs and successfully completes the NAS Secure Mode Command only if both verifications are successful. If either one fails, the connection can be terminated or the NAS Secure Mode Command can be re-executed. In this way, if a man-in-the-middle attacker tampers with a message, it can be detected and the attack can be prevented.

[0045] [Fourth embodiment] Method for selecting a 256-bit algorithm when returning from an idle state When authentication of the terminal apparatus UE is completed, a 5G GUTI is assigned to the terminal apparatus UE by the AMF. In TS23.501, the 5G GUTI is <guami><5G-TMSI> is defined as <5G-TMSI>, and GUAMI (Globally Unique AMF Identifier) ​​is defined as follows: <guami> :＝ <mcc> <mnc><AMF Region ID> <AMF Set ID> <AMF Pointer>

[0046] This GUAMI is used when the authenticated terminal device UE continues the session using the previous set of keys when reconnecting to the network. In FIG. 1, the terminal device UE includes a 5G GUTI in the message of step S3. The GUAMI portion of the 5G GUTI is used by the base station gNB to identify the set of AMFs. However, if the base station gNB is not connected to the target AMF (for example, if the AMF does not serve the specific area where the terminal device UE is currently located), the base station gNB selects another AMF that obtains the security context from the previous AMF.

[0047] Here, the base station gNB cannot determine whether the terminal device UE was previously using a 256-bit algorithm (and therefore needs to preferentially connect to a 256-bit compatible AMF), or whether the terminal device UE was using a 128-bit algorithm (whether it can connect to an AMF that only supports the 128-bit algorithm).

[0048] To determine this in the base station gNB, the 256-bit compatible function of AMF can be included in the GUAMI part of GUTI. For example, a field indicating the 256-bit compatible function is added to extend GUAMI as follows: <guami> ：= <mcc> <mnc><AMF region ID> <AMF set ID> <AMF pointer> <256-bit compatible> The base station gNB checks GUAMI and selects a 128-bit MAC compatible AMF based on whether the previous AMF is 128-bit MAC compatible.

[0049] or <guami>Another method is to classify the <AMF Set ID> into 128-bit compatible AMF and 256-bit compatible AMF for each operator without changing the field. The operator places a 256-bit compatible AMF in a specific set and sets the set ID value in the base station gNB, so that the base station gNB can select an AMF based on the AMF Set ID value even if the region ID is different. By applying this to the entire network, once a terminal device UE is connected to an environment that supports 256 bits, it will always be connected to a 256-bit compatible AMF thereafter.

[0050] [Fifth Embodiment] Request for 256-bit security using NSSAI A method of notifying the base station gNB that a 256-bit algorithm will be used using network slice selection assistance information (NSSAI) is also possible. The NSSAI is included in the message transmitted in step S3 of FIG. 2, and the NSSAI is composed of up to eight S-NSSAIs. Each S-NSSAI is defined as a combination of an SST (Slice / Service Type) and an SD (Slice Differentiator). The currently defined SST values ​​are as shown in Table 3. The first 127 of the SSTs are defined by 3GPP (registered trademark), and the remaining 128 values ​​can be independently set by operators. The SD value can also be independently set by operators. Currently defined slices are related to the type of service provided by the network, and do not define information about security or algorithms.

[0051] However, since slice information is used to select an appropriate AMF, a problem occurs when only some AMFs in the network support the 256-bit algorithm. For example, if a 256-bit capable terminal device UE requests SST4, the terminal device UE cannot use the 256-bit algorithm if the AMF processing SST4 does not support 256 bits. This problem can be solved by defining a new slice. An example is shown below.

[0052] A terminal device UE capable of supporting 256 bits can notify the network NW that it prioritizes the use of the 256-bit algorithm by including this NSSAI in the connection request. This allows the base station gNB to select an appropriate AMF capable of supporting 256 bits based on the slice information. Although the connection request may be modified by a man-in-the-middle attacker, including the slice information in Secure Mode Complete together with the security function of the terminal device UE makes it possible to detect tampering by MAC, thereby avoiding the problem of modification by a man-in-the-middle attacker.

[0053] This embodiment also has the advantage that the home network can confirm the need for 256-bit security. Figure 4 shows the network slice instance selection procedure. This procedure is usually initiated by the first AMF as part of the registration procedure. The terminal device UE sends the requested NSSAI in both the RRC setup complete and the NAS registration request. The base station gNB uses this information for AMF selection and provisional processing before obtaining the authorized NSSAI.

[0054] The AMF obtains the slice permitted by the user's contract and, in cooperation with the Network Slice Selection Function (NSSF), selects an appropriate network slice instance based on the permitted S-NSSAI, PLMN ID (Public Land Mobile Network ID), etc. At this time, a change to another AMF may occur if necessary. For example, if the AMF determines that a 256-bit compatible AMF is required, the AMF can initiate a change to another AMF.

[0055] As shown in FIG. 4, the AMF sends a slice information request to the UDM to check the slices permitted by the contract (S102). The UDM returns a slice information response indicating the slices permitted by the contract (S103). This function can be used by the home network to control the use of 256-bit encryption algorithms. For example, if a visited network charges an additional fee for the use of a 256-bit encryption algorithm, the AMF can deny a roaming terminal device UE from using a 256-bit slice. In addition, if an operator provides 256-bit security for a fee, the AMF may direct the terminal device UE to a 128-bit slice if the subscriber has not paid the fee.

[0056] Since a registration request from a terminal device UE can only include eight slices, if the terminal device UE acquires a 256-bit slice or a 128-bit slice and wants to gain access to five or more slices, it cannot transmit a request including that information. To solve this problem, the introduction of a virtual 256-bit slice is being considered. If the terminal device UE wants to use 256-bit security in the slice requested in the NSSAI, it can notify the network side by requesting this virtual slice. In other words, a terminal device UE requesting 256-bit security indicates a "virtual 256-bit slice" in addition to the normal slice. In this case, the slice table will be as shown in Table 5. This allows the base station gNB to determine whether 256-bit security is required by simply checking one slice identifier.

[0057] Sixth Embodiment: Method for Notifying 256-bit Support Status Using SIB Two methods are proposed for notifying a terminal device UE that a RAN is 256-bit capable. The first method modifies the system information block (SIB) to add an indicator indicating whether each cell supports 256-bit security. The second method uses the PLMN ID, which is a value in the SIB, and a list of 256-bit capable PLMNs to find a match. In either method, optimal cell selection is achieved by checking 256-bit compatibility in addition to other factors evaluated in conventional methods.

[0058] When selecting a cell, the terminal device UE acquires Master Information Block (MIB), SIB1, and SIB2. The MIB is used by the terminal device UE to find the associated SIB. The SIB is system information of the cell acquired by the terminal device UE when selecting a cell, and 24 types are defined (5G is SIB1 to SIB24), and SIB1 and SIB2 are used when selecting a cell. SIB1 is ultimately used for cell selection, cell access, and SI (System Information) scheduling.

[0059] SIB1 includes cell access-related information, i.e., cell selection information and scheduling information. This embodiment applies to SIB1. The cell access-related information includes a PLMN ID list, PLMN ID, TA code, cell ID, and cell status. The cell selection information includes a minimum reception level. The scheduling information includes SI message type and periodicity, SIB mapping information, and the SI window length required for the terminal device UE to identify other SIBs (SIBs 2 to 9 for LTE, or SIBs 2 to 24 for NR). It is assumed that "Operator-controlled PLMN Selector with Access Technology" is used for PLMN selection. This method is defined in TS 23.122 and is performed using information stored locally in the Mobile Equipment (ME) and the USIM. Furthermore, the PLMN ID consists of a Mobile Country Code (MCC) and a Mobile Network Code (MNC). Similarly, the IMSI consists of a PLMN ID and a subscriber identifier within the PLMN. The PLMN ID in the IMSI is called the Home PLMN ID or HPLMN ID.

[0060] The ME contains a list of "equivalent PLMNs" that are known to be equivalent to other PLMNs. This list is updated after each round of the Location Update procedure, Routing Area Update procedure, GPRS Attach procedure, Tracking Area Update procedure, EPS Attach procedure, and Registration procedure. Therefore, this list may be modified by the mobile network operator to which the terminal device UE is currently connected. This list allows the ME to identify and connect to equivalent PLMN IDs. It also uses this information to identify cells with stronger reception and to identify the same PLMN in other wireless communications, such as GSM, UMTS, LTE, and NR. Furthermore, the USIM may contain a list of "equivalent home PLMNs." This list is used to identify PLMNs that the ME can access and that can be treated similarly to the home PLMN ID. The ME selects the home PLMN in preference to other PLMN IDs. The ME always uses this file when it is available, and prioritizes the PLMN IDs listed in it.

[0061] The USIM file may specify a combination of PLMN ID and radio access technology, which is used by the operator to specify which combination of PLMN ID and radio access technology should be prioritized by the ME. TS 23.122 defines the automatic network selection mode procedure as shown in Table 6.

[0062] In this embodiment, a new priority is added, which is whether a cell or network supports 256 bits. Cell selection is typically divided into two steps, as shown in FIG. 5: 1) PLMN ID selection; and 2) selection of the cell with the strongest reception strength within that PLMN ID. 1. In FIG. 6, the terminal device UE collects all SIBs of base stations gNBs that can receive SIBs. Similar collection is also possible for radio accesses that can receive SIBs (gNB for NR, eNB for LTE, NodeB for UMTS, etc.). After receiving the SIBs, the terminal device UE performs the following comparisons for each SIB: ・Whether the PLMN ID corresponds to the PLMN ID of its own IMSI. ・If not, whether the PLMN ID is an "equivalent home PLMN ID." ・Whether it is included in the list of allowed PLMN IDs.

[0063] 2. The terminal device UE assigns priorities to these base stations gNBs according to the PLMN IDs indicated in the SIB. The highest priority is given to those corresponding to LPMNs with a contract or equivalent HLPMNs, and the terminal device UE compares signal strength and assigns priorities according to the signal strength. The results of the priority assignment are shown in Table 7 and Figure 7. Here, it is assumed that operator 1 is an HPLMN. The terminal device UE sorts the received SIBs 1) according to an ordered list of preferred PLMN IDs obtained from a storage in the terminal device UE, and 2) according to signal strength within the same PLMN ID.

[0064] 3. According to instructions received from different base stations gNB, the terminal device UE sends an attach request to the cell with the strongest signal strength. In the example of Table 7, based on the signal strength, as shown in FIG. 8, the terminal device UE selects to attach to cell 2 of operator 1 and sends an attach request.

[0065] In this embodiment, an extended SIB1 is applied, and information provided to the terminal apparatus UE is added to the conventional network selection mode. This allows the terminal apparatus UE to select whether the base station gNB supports 128 bits or 256 bits. A new item (1-bit flag) is added to SIB1 to indicate whether the base station gNB supports a 256-bit encryption algorithm. It is also possible to add an item indicating the maximum length supported by the base station gNB (for example, 1: 128 bits, 2: 256 bits, 3: 512 bits). Alternatively, each bit can indicate the supported algorithm or algorithm strength, and the algorithm supported by the base station gNB can be indicated by setting the corresponding bit to 1. In either method, the supported bit size can be notified to the terminal apparatus UE by extending SIB1.

[0066] The following is an example in which the terminal device UE of this embodiment preferentially selects a base station gNB that supports 256 bits. 1. The terminal device UE collects receivable SIBs from the base station gNB. Receivable radio access (gNB for NR, eNB for LTE, NodeB for UMTS, etc.) can also be collected in the same way. After receiving the SIB, the terminal device UE performs the following comparisons for each SIB: ・Whether the PLMN ID corresponds to the PLMN ID of its own IMSI ・If not, whether the PLMN ID is an "equivalent home PLMN ID" ・Whether it is included in the list of allowed PLMN IDs When checking the PLMN ID, it also checks whether the corresponding base station supports 128-bit MAC. This indicates the priority to each base station.

[0067] 2. Based on the support status of 128-bit MAC indicated in the SIB, the terminal device UE deletes all cells that do not support 128-bit MAC. Next, it assigns a priority to the base station gNB of the contracted carrier and compares the signal strength for each received SIB. An example of the result is shown in Table 8.

[0068] The terminal device UE sorts the received SIBs according to 1) the order of the preferred PLMN IDs retrieved from the terminal device UE's internal storage, 2) signal strength, and 3) whether or not they support 256 bits. In Table 8, Cell 1 of Operator 1 is set to priority 1. Next, cells that do not support 256 bits are removed. Cell 2 of Operator 2 in the fourth row may have a different PLMN ID than the terminal device UE because its PLMN ID belongs to a different operator, but it may have the same PLMN ID subset or may not be a prohibited PLMN ID. Furthermore, since it supports 256 bits, it remains as an available base station and is prioritized over base stations that do not support 256 bits. Figure 9 shows Cell 1 of Operator 1 with priority 1.

[0069] This embodiment is effective for operators who gradually update their base stations gNBs. This makes it possible to deploy 256-bit compatible base stations gNBs throughout the country without the need to upgrade all base stations gNBs, which is more efficient. In addition, the terminal device UE can search for a base station gNB that supports 256 bits and connect to a network that supports the security functions supported by the terminal device UE. Since the base station gNB is expected to continue to support the 128-bit encryption algorithm, legacy terminal devices UE or terminal devices UE that do not support 256 bits can continue to be used, and there is no adverse effect from this embodiment.

[0070] In this embodiment, the terminal device UE is notified of its support for 256-bit data by changing the cell selection method. However, as an alternative, this can be achieved by adding a 256-bit PLMN ID that is independent of other PLMN IDs. This allows the terminal device UE to search only for 256-bit PLMN IDs as needed, and if no receivable PLMN ID is found, it selects a PLMN ID according to the prioritization criteria defined in TS 23.122. The operator creates a list of 256-bit PLMN IDs in a file on the subscriber's USIM. Specifically, with the transition to 256-bit data, the operator notifies each 256-bit-compatible base station that it is "256-bit compatible" using a PLMN ID list. The terminal device UE uses this list to prioritize PLMN IDs.

[0071] The list of Home PLMN IDs or equivalent Home PLMN IDs will be called "File 1". A new file (hereinafter referred to as "File 2") containing a list of PLMN IDs corresponding to 256 bits is created. This File 2 is provisioned on the USIM by the contracted operator and is updated periodically. When performing cell selection, the terminal device UE performs the following steps:

[0072] 1. The terminal device UE reads File 1 and File 2 from the USIM. 2. The terminal device UE receives the SIB broadcast and creates a list of "available PLMN IDs." 3. The terminal device UE selects "available PLMN IDs" from the list of home PLMN IDs or equivalent home PLMN IDs (File 1), as defined in the prior art. 4. The terminal device UE checks whether each PLMN ID in the available PLMN ID list is included in the 256-bit compatible PLMN ID list (File 2). 5. The terminal device UE prioritizes PLMN IDs in the "available PLMN ID" list depending on whether the PLMN IDs support 256-bit compatibility. 6. After creating the prioritized PLMN ID list, the terminal device UE selects a cell to connect to based on the highest-priority PLMN ID and the cell's signal strength. Figure 10 shows the operation flow. Although Figure 10 illustrates an example of a 64-bit MAC, any MAC length can be supported.

[0073] The following is an example of how this method works: (1) The terminal device UE receives a list of PLMN IDs from the base station gNB and creates a list of available PLMN IDs. Assume the created list of available PLMN IDs is as follows: 1.440 15 2.440 16 3.440 27 4.440 29 5.440 43 6.440 48 7.440 49 8.440 51 9.440 52 10.440 79 In this example, it is assumed that the home PLMN ID of the terminal device UE is 440 43 and the equivalent home PLMN IDs are 440 15, 440 16, 440 43, 440 48, 440 49, 440 51, and 440 52. For convenience, this list is arranged in MNC (Mobile Network Code) order, but this need not be the case in an actual implementation.

[0074] (2) In step 2, the terminal device UE filters the "Available PLMN ID" list based on the input of file 1 depending on whether it is a home PLMN ID. If the home PLMN ID is present in the list, the terminal device UE proceeds to step (2-a). (2-a) The terminal device UE uses file 2, which is a 256-bit compatible PLMN ID list, and if the found home PLMN ID (440 43) is 256-bit compatible, assigns priority 1 to this PLMN ID. File 2 indicating that the home PLMN supports 256 bits looks like this: 1. 440 43 2. 440 48 3. 440 49 4. 440 51 PLMN ID 440 43 is assigned priority 1 and written to a file or list in memory. If the HPLMN is not found in file 2, it assigns priority 3 to the same list / file in memory.

[0075] (3) In the next step 3, the terminal device UE returns to the list of available PLMN IDs and selects PLMN IDs included in the equivalent home PLMN ID list available in file 1. In this example, the selection results are 440 15, 440 16, 440 43, 440 48, 440 49, 440 51, 440 52. For each PLMN ID included in the "available PLMN IDs" and file 1, the terminal device UE performs step (3-a).

[0076] (3-a) The terminal device UE uses file 2 in the same way as in step 2 to check whether the PLMN ID supports 256 bits. If it does support 256 bits, priority 2 is assigned and the PLMN ID is written to memory together with the priority. For example, priority 2 is assigned to the following PLMN IDs: 440 48 440 49 440 51 If the PLMN ID is not listed in file 2, priority 4 is assigned. For example, priority 4 is assigned to the following PLMN IDs: 440 15 440 16 440 51

[0077] (4) If the terminal device UE does not find the Home PLMN ID or any PLMN ID included in the equivalent Home PLMN ID list, the terminal device UE selects a PLMN ID from the "Available PLMN IDs". In the prior art, the terminal device UE checks whether there is an "Operator Controlled PLMN Selector with Access Technology" file on the SIM card and checks whether each PLMN ID is included in that file.

[0078] The terminal device UE assigns a priority to each PLMN ID using the same logic as in (2-a) and (3-a), that is, assigning a priority of 5 to a PLMN ID listed in the 256-bit compatible PLMN ID list and a priority of 6 to a PLMN ID not listed in the list. However, this logic is applied only when the terminal device UE finds a PLMN ID included in the "Operator Controlled PLMN Selector with Access Technology" file.

[0079] If no HPLMN ID is found in step 3, the terminal device UE may have multiple PLMN IDs with priority 3 or 4. For example, the terminal device UE may find four PLMN IDs with priority 3 and three PLMN IDs with priority 4. In this case, the terminal device UE can determine the PLMN to connect to using the same logic as a terminal device UE that does not support 256 bits. Since the order of PLMN IDs in the equivalent HPLMN ID list (file 1) indicates the priority, the terminal device UE attempts to connect to the PLMN listed in file 1 with the highest priority of priority 3, and if unsuccessful, moves on to the next PLMN.

[0080] A similar logic can be applied in step 4, where for a list of PLMN IDs with priority 5, the terminal device UE first tries to connect to the PLMN with the highest priority in the "Operator Controlled PLMN Selector with Access Technology" file, or if not included in the list, the terminal device UE randomly selects one and tries to connect to it.

[0081] The advantage of this approach is that an operator can provision the USIM with an "Operator Controlled PLMN Selector with Access Technology" and an "equivalent Home PLMN" list that are optimal for terminal equipment UEs that do not support 256 bits. By adding a 256-bit compatible PLMN ID file, an operator can change the priority for the terminal equipment UE to select a PLMN ID. For example, suppose an operator configures an equivalent Home PLMN ID list as shown in Table 9. Table 10 shows the PLMN IDs corresponding to 256 bits, with the display order indicating the priority.

[0082] In this case, a terminal device UE that does not support 256 bits attempts to connect to PLMN IDs in the order of the equivalent home PLMN ID list, and a terminal device UE that supports 256 bits prioritizes PLMN IDs as shown in Table 11.

[0083] In Table 11, 256-bit capable PLMN IDs (43, 48, 49, 51) are assigned priority 3 and are listed in the order of their appearance in the equivalent HPLMN list, while PLMN IDs that only support 128 bits are assigned priority 4 and are also listed in the order of their appearance in the equivalent HPLMN list (52, 15, 16). The same logic applies in roaming scenarios, where the "Operator Controlled list with Access Technologies" is used instead of the equivalent HPLMN ID list. There is no change to the 256-bit MAC capable PLMN IDs.

[0084] Finally, it is possible that no base station supporting 128-bit MAC can be found, such as in the case of Table 12. Table 11 uses 128-bit MAC as an example, but is applicable to any MAC length. In the case of Table 12, fallback occurs, and the priority is updated according to the prioritized PLMN ID order retrieved from the storage in the terminal device UE, and then updated according to signal strength. Also, if an operator adds a 256-bit compatible base station but does not assign an independent PLMN ID (when 128-bit and 256-bit compatible base stations (gNBs) coexist within a single PLMN ID), it becomes difficult to distinguish between them. Even in such cases, this can be addressed by extending the SIB (e-SIB) and adding a 256-bit compatible PLMN ID file, and can be applied according to the operator's deployment plan.

[0085] In the case of roaming, the terminal device UE has a list of forbidden PLMN IDs, and the terminal device UE records the PLMN ID when a connection attempt is rejected. In this case, the target PLMN ID is added to the "forbidden PLMN ID" list. Similarly, in a roaming scenario, the terminal device UE can record which PLMN IDs are 256-bit compatible and stores these PLMN IDs in its memory as a "256-bit compatible PLMN ID" list. The terminal device UE erases this list at appropriate times, such as after a certain period of time has passed, after being turned off, or after reconnecting to the home PLMN.

[0086] During the UP security activation process, the base station gNB sends an AS Security Mode Command indicating the security algorithm used between the terminal device UE and the base station gNB. If the Security Mode Command message is received, the terminal device UE verifies the MAC-I. If successful, the terminal device UE decrypts the message.

[0087] The terminal device UE also checks whether the algorithm indicated in the SMC is a 256-bit algorithm. If the terminal device UE supports a 256-bit algorithm but the algorithm indicated in the SMC is 128-bit, the terminal device UE rejects the AS SMC and restarts the process. The terminal device UE notifies the base station gNB of the reason for the rejection by sending an error code indicating "algorithm mismatch" or "256-bit algorithm required." After receiving the error code, if the base station gNB can select a 256-bit algorithm, it sends a new AS SMC message.

[0088] In the first and second embodiments, it has been described that the terminal device UE may receive a notification indicating that the RAN supports a 256-bit encryption algorithm. Even if the terminal device UE receives a notification indicating that the RAN supports a 256-bit encryption algorithm, if the AS SMC specifies a 128-bit encryption algorithm, it is desirable for the terminal device UE to reject the AS SMC. In this case, the terminal device UE is notified by the ABBA parameter that the network device supports a 256-bit encryption algorithm, and a mismatch occurs with the 128-bit encryption algorithm selected by the RAN.

[0089] Another case in which the terminal device UE rejects AS SMC is when a 256-bit encryption algorithm is specified in the NAS SMC, but the base station gNB selects a 128-bit encryption algorithm. If there is a difference in the security level of the encryption algorithm, the terminal device UE rejects AS SMC due to a "256-bit compatible encryption algorithm selection error". Then, AS SMC is performed again.

[0090] As in the first embodiment, the base station gNB can indicate to the terminal device UE that there is a mismatch in support for the 256-bit encryption algorithm between the terminal device UE and the base station gNB. The base station gNB executes the following method 5.

[0091] (Method 5) By adding a new field to the AS Secure Mode Command to indicate a "256-bit compatible encryption algorithm selection error," the base station gNB notifies the terminal device UE that there is no 256-bit encryption algorithm supported by both the base station gNB and the terminal device UE. If the bit in this field is set, the terminal device UE accepts the 128-bit encryption algorithm selected by the base station gNB.

[0092] Alternatively, the terminal device UE may resend the attach request, and the network NW may re-perform authentication and key agreement, in which case new NAS SMC and AS SMC will be generated. It is also possible to send an attach request to a specific PLMN ID to check whether the target PLMN ID supports the required algorithm. It is also possible to keep a list of PLMN IDs that do not support the 256-bit algorithm as a file and lower the priority of those PLMN IDs.

[0093] The present invention enables the terminal device UE and the network NW to share support for a longer common key encryption algorithm, thereby contributing to Goal 9 of the United Nations-led Sustainable Development Goals (SDGs), which is to "build resilient infrastructure, promote sustainable industrialization, and foster innovation."

[0094] 210 Selecting a PLMN ID 220 Selecting a cell within the selected PLMN ID< / guami> < / mnc> < / mcc> < / guami> < / mnc> < / mcc> < / guami> < / guami>

Claims

1. A network device that includes data indicating how many bits of a common key the network device supports for an encryption algorithm in a message sent from the network device to a terminal device, and transmits the data to the terminal device.

2. The network device according to claim 1, wherein an ABBA parameter in a message transmitted from the network device to the terminal device includes data indicating how many bits of a common key the network device supports for an encryption algorithm.

3. The network device according to claim 2, wherein the ABBA parameters also specify an encryption algorithm.

4. A terminal device that receives a message sent from a network device including data indicating how many bits of a common key the network device supports for its encryption algorithm, and notifies the network device of the security functions for the encryption algorithm of the terminal device using a tamper detection algorithm different from the tamper detection algorithm selected by the network device.

5. A terminal device that includes data indicating how many bits of a common key encryption algorithm the previously connected AMF supported in the GUTI in an initial connection message sent to a network device.

6. A terminal device that includes data indicating how many bits of a common key encryption algorithm the terminal device requests to use in the network slice selection assistance information NSSAI in a message sent to a base station.

7. The network device according to claim 1, wherein data indicating how many bits of a common key the network device supports for an encryption algorithm is included in a system information block SIB in a message transmitted from the network device to a terminal device.

8. A terminal device that rejects an access stratum security mode command when the length of the common key of the encryption algorithm that it supports does not match the length of the common key of the encryption algorithm presented in the access stratum security mode command (AS Security Mode Command) message received from a base station.

9. A terminal device that receives a message transmitted from the network device according to claim 7, the terminal device ranking a plurality of received system information blocks SIBs according to whether they support a 256-bit encryption algorithm, and selecting a network node to connect to based on received signal strength and encryption strength.

Images