Device for notifying length of common key

Abstract

To provide a method for confirming that an encryption algorithm for a public key longer than current 128 bits is supported between a terminal device UE and a network NW.SOLUTION: A message transmitted from a SEAF to a base station gNB in step S10 includes an ABBA parameter. Using the ABBA parameter, a terminal device UE is notified that a network NW side supports a 256-bit encryption algorithm. For example, using 4 bits in the ABBA parameter, it is achieved such that "0001: RAN is compatible with 256 bits" and "0010: AMF is compatible with 256 bits." By setting the ABBA parameter, the terminal device UE is notified that the RAN or AMF is compatible with the 256-bit encryption algorithm.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a technique for sharing the length of a common key for an encryption algorithm between a terminal device UE and a network NW in mobile communications. [Background technology]

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

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

[0004] Current mobile communications, including 5G, use an encryption algorithm with a common key length of 128 bits for the wireless section between base stations and terminal devices UE and for communications between the core network and terminal devices UE. Hereinafter, an encryption algorithm with a common key length of 128 bits will be referred to as a "128-bit algorithm." Similarly, an encryption algorithm with a common key length of 256 bits will be referred to as a "256-bit algorithm."

[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 mobile phones 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, and the lack of a unified security level may become an issue. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] 3GPP (registered trademark) SA3, TS33.401 [Non-Patent Document 2] 3GPP (registered trademark) SA3, TS33.501 Summary of the Invention [Problem to be solved by the invention]

[0007] Therefore, it is necessary to realize a system for confirming compatibility with 256 bits between the terminal device UE and the network NW. [Means for solving the problem]

[0008] The inventors discovered that data indicating how many bits of a common key encryption algorithm the network device supports could be included in a message sent from a network device to a terminal device, and thus completed the present invention.

[0009] (1) A network device that includes data indicating how many bits of a common key the network device supports in an encryption algorithm in a message sent from the network device to a terminal device, and transmits the message to the terminal device. (2) A network device according to (1) above, which includes in an ABBA parameter in a message sent from the network device to a terminal device data indicating how many bits of a common key the network device supports for an encryption algorithm. (3) A network device according to (2) above, which also specifies an encryption algorithm using ABBA parameters. (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 as an 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 network slice selection assistance information (NSSAI) in a message sent to a base station. (7) A network device according to (1) above, which includes data indicating how many bits of a common key the network device supports as an encryption algorithm in a system information block SIB in a message sent 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 shared key of the encryption algorithm that it supports does not match the length of the shared 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 of (7) above, which ranks multiple received system information blocks SIBs according to whether or not they support a 256-bit encryption algorithm, and selects a network node to connect to based on received signal strength and encryption strength. Effect of the Invention

[0010] According to the present invention, a network device notifies a terminal device of the number of bits of a common key encryption algorithm that the network device supports, thereby enabling negotiation between the network device and the terminal device regarding the encryption algorithm to be used. [Brief description of the drawings]

[0011] [Figure 1] This is a diagram (first half) showing the procedures of authentication, key agreement, and NAS SMC between the terminal device UE and the network NW. [Diagram 2] This is the second half of the diagram showing the procedures of authentication, key agreement, and NAS SMC between the terminal device UE and the network NW. [Diagram 3] FIG. 1 illustrates an example of a man-in-the-middle attacker tampering with a message. [Figure 4] A diagram showing the procedure for selecting a network slice instance. [Diagram 5] FIG. 13 is a diagram showing a procedure for selecting a cell. [Figure 6] A diagram showing a terminal device collecting SIBs of base stations that it can receive. [Figure 7] FIG. 11 is a diagram showing an example of the result of a terminal device assigning priorities to base stations. [Figure 8] FIG. 1 illustrates a terminal device sending an attach request to the cell with the strongest signal strength. [Figure 9] FIG. 23 is a diagram showing a cell with a priority level of 1 in the sixth embodiment of the present invention. [Figure 10] FIG. 13 is a schematic diagram of priority allocation in a sixth embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0013] 1 and 2 are a series of diagrams showing the procedures of authentication, key agreement, and NAS (Non-Access-Stratum) SMC (Secure Mode Command) 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, followed by initial connection and authentication.

[0014] In step S3, the terminal device UE transmits an initial connection message to the base station gNB. The initial connection message includes the security function 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 transfers the initial connection message to an Access and Mobility Management Function (AMF) / Security Anchor Functionality (SEAF) of the core network. In step S5, if the initial connection message contains a SUCI or SUPI (Subscription Permanent Identifier), i.e., if the terminal device UE has not yet been authenticated, the AMF / SEAF initiates an authentication procedure with the UDM (Unified Data Management) / AUSF (Authentication Server Function) / ARPF (Authentication credentials Repository Function).

[0015] In step S6, the SEAF sends a Nausf_UEAuthentication_Authenticate Request message to the AUSF. This message includes a 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 the 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 a SUCI is received, the UDM calls the SIDF to decrypt the SUCI and obtain a SUPI. In step S7, based on the SUPI, the UDM / ARPF selects whether to use EAP-AKA' or 5G-AKA. 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, 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 in step S17, 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, and if there is a match, sends the anchor key KSEAF and SUPI to the SEAF in a 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 is 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, which contains the security capabilities of the UE, the tamper detection and encryption algorithms selected by the AMF, and possibly the ABBA parameters and the ngKSI. The base station gNB receives the message and forwards the NAS message to the UE in step S24.

[0021] In step S25, the terminal device UE verifies the message using its tamper detection function to verify that the security capabilities of the terminal device UE have not been tampered with. If everything is OK, the terminal device 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 device UE and the requested NSSAI.

[0022] In step S28, the AMF verifies that the received message can be correctly decoded and has not been tampered with, and in step S29, sends a registration accept message, which includes the allowed NSSAI, the new GUTI assigned to the terminal device UE, and the capabilities supported by the network. The authentication, key agreement, and NAS SMC procedures in the prior art and in the 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] 256-bit notification using ABBA parameters The message transmitted from the SEAF to the base station gNB in ​​step S10 in Fig. 1 includes an ABBA parameter. The ABBA parameter is used to notify the terminal device UE that the network NW supports the 256-bit algorithm. For example, this can be achieved as follows using 4 bits of the ABBA parameter. 0001: RAN can support 256 bits 0010:AMF supports 256 bits

[0024] By setting the ABBA parameters, the terminal device UE is notified that the RAN or AMF is capable of supporting 256 bits. Therefore, the terminal device UE can use the ABBA parameters in step S25 of the procedure in FIG. 2 as follows. 1. If the ABBA parameter is set to 0010 and the terminal device UE is capable of supporting 256 bits, the terminal device UE can check whether the network NW has selected a 256-bit algorithm. If a.256-bit algorithm is selected, the terminal device UE accepts the message and sends a Secure Mode Complete message protected by the selected algorithm. b. If the 256-bit algorithm is not selected, the terminal device 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, there are multiple types of "256-bit security algorithms" even when they are called "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 the terminal device UE may reject. 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 device UE is notified that there is no 256-bit algorithm supported by both the AMF and the terminal device UE. If this bit is set, the terminal device UE accepts the 128-bit algorithm selected by the AMF. (Method 2) A logic based on the UE security capabilities sent by the terminal device UE in steps S3 and S4 is added to the SEAF. If the terminal device 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 the 256-bit algorithm cannot be selected. If the ABBA parameter is not set, the terminal device UE accepts the 128-bit algorithm.

[0027] In this embodiment, it is important for the terminal device UE to confirm that the security functions it sent in step S3 match the security functions it received in step S12, thereby preventing attacks by a man-in-the-middle located between the terminal device UE and the network NW (hereinafter referred to as a "man-in-the-middle attack"). In addition, unless the tamper detection algorithm can be attacked within a reasonable time, an attacker cannot make the terminal device UE 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] How to specify a 256-bit algorithm using the ABBA parameter In addition to the first embodiment, it is also conceivable that the SEAF selects the type of algorithm and notifies the terminal device UE using the ABBA parameters. This will be described with reference to Figs. 1 and 2. The SEAF receives the security capabilities of the UE in the message of step S4, and in step S5, the SEAF checks whether the security capabilities of the UE include a 256-bit algorithm. If the UE can use a 256-bit algorithm, the SEAF selects the highest priority 256-bit NAS encryption and tamper detection algorithm supported by the UE (it can also select a RAN security algorithm).

[0029] Once the SEAF selection is complete, it specifies the selected algorithm in the ABBA parameters. For example, the first byte can be used to specify the algorithm as shown in Table 1. [Table 1] The second byte is set as shown in Table 2. [Table 2]

[0030] SEAF operates as follows: Method 3 or Method 4. (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 stations gNB and AMF use to select the appropriate algorithm. In this case, the SEAF needs to inform the base stations gNB and AMF of the algorithm it has selected, which can be explicitly notified by a new message called "algorithm selected by SEAF". Alternatively, it can be configured that the base stations gNB and AMF 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 the base station gNB, and sets the corresponding bits of the ABBA parameters based on the responses of the AMF and the base station gNB.

[0031] The ABBA parameters are AMF Since it 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 equipment UE does not support the 256-bit algorithm, the ABBA parameter is not set, so it is possible to connect legacy terminal equipment UE to the network.

[0032] If the ABBA parameter is set, the 256-bit capable terminal device UE verifies in step S25 that the message received in step S24 indicates the same algorithm. If not, the terminal device UE must reject the SMC (Secure Mode Command) using an SMC reject message and indicate 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] UE Security Function Exchange If an attacker is present between the terminal device UE and the network NW, an attack is possible in which the attacker tampers with messages to select a weaker algorithm, even if both the terminal device UE and the network NW support the 256-bit algorithm. An example of an attacker tampering with a message will be described with reference to Figure 3. Figure 3 shows the same flow as Figures 1 and 2, but only shows the NAS message between the terminal device UE and the AMF, and shows the procedure in which a Man-in-the-middle (MITM) (short for Att) tampers with a message. "'" is added to the tampered message.

[0034] The terminal device UE is unauthenticated and sends a registration request or an initial NAS message in 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 device UE sends in message M1 that it supports encryption algorithms 128-NEA1, 128-NEA2, 128-NEA3, 256-NEA4, 256-NEA5, and 256-NEA6 and tamper detection algorithms 128-NIA1, 128-NIA2, 128-NIA3, 256-NIA4, 256-NIA5, and 256-NIA6, the attacker Att tampers with message M1 as if it supports only attackable algorithms from among them. For example, if 128-NEA2 and 128-NIA2 are attackable, the attacker Att tampers with the message M1 as if it supports only these two. Then, the attacker Att sends the tampered 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 modification. The terminal UE processes the authentication request message, verifies its validity, and if valid, creates an authentication response message M3. The attacker forwards the authentication response message to the AMF without modification.

[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 with the tamper detection algorithm selected by the attacker Att. Since the SMC message includes the UE security capabilities received in message 1', the attacker Att takes 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 so, uses the selected encryption and tamper detection algorithms. 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 it contains a UE security function. If it does, the attacker modifies the UE security function again, encrypts the message, and ensures that the MAC matches the message. The attacker sends message 5´ to the AMF, which considers the NAS SMC to be complete and the authentication of the terminal device UE is completed.

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

[0040] Specifically, follow the steps below. Step 1: In the authentication process, the SEAF uses the ABBA parameter to indicate that the core network is 256-bit capable or indicates the algorithms that the core network supports. The SEAF includes the ABBA parameter in the message M2 in FIG. Step 2: In Secure Mode Complete, the terminal UE verifies that the message has not been tampered with, and verifies the received UE security capability. In addition to the selected tamper detection algorithm, the terminal UE adds a MAC of the UE security capability using another 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 may be, for example, Key Derivation Function (KDF) or HMAC-SHA-256.

[0041] When the terminal device UE generates a MAC using the KDF, K NASint_256 Using this key, we can calculate the MAC for the Initial NAS message as follows: UE_Capabilities_Hash = KDF(K NASint_256 , Initial NAS message) Similarly, the MAC for the 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, sends a NAS Secure Mode Command to the terminal device UE again, and repeats the above process from step 1.

[0043] The key used for the MAC calculation may be any key that can be used by the AMF and the terminal device UE, and the following are assumed. - K, the AMF root key AMF -K NASInt and K NASEnc Session keys such as As long as the terminal device UE and the AMF use the same key, any of these keys may be input to the KDF. However, if a 128-bit algorithm is selected, the session key is usually truncated to 128 bits and the 256-bit key may be discarded. Therefore, the input key is a 128-bit K NASInt and K. NASEnc may be connected together.

[0044] According to this embodiment, an attack that causes a 128-bit algorithm to be selected can be prevented as follows. Since the ABBA parameters are used as inputs for key derivation, if an attacker tampers with the ABBA parameters, the generated K AMF changes. K AMF With input, K gNB , K NASint , K NASenc Therefore, if the ABBA parameters are tampered with, different keys will be generated between the terminal device UE and the AMF, and connection establishment will fail. If the terminal UE supports the 256-bit algorithm, an additional MAC is added in addition to the 32-bit MAC added in the conventional technology, so the AMF can determine whether the terminal UE supports the 256-bit algorithm by checking the additional MAC. The AMF verifies the two MACs and only terminates the NAS Secure Mode Command successfully 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 tampers with a message, it can be detected and the attack can be thwarted.

[0045] [Fourth embodiment] How to select the 256-bit algorithm when resuming from idle When the authentication of the terminal device UE is completed, the AMF assigns the 5G GUTI to the terminal device UE. In TS23.501, the 5G GUTI is: <guami>It is defined as <5G-TMSI>, and GUAMI (Globally Unique AMF Identifier) ​​is defined as follows: - <guami> := <mcc> <mnc><AMFリージョンID><AMFセットID><AMFポインタ>

[0046] This GUAMI is used when the authenticated terminal device UE reconnects to the network and continues the session using a set of conventional keys. In FIG. 1, the terminal device UE includes a 5G GUTI in the message of step S3. The GAUMI part 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 particular area where the terminal device UE is currently located), the base station gNB selects another AMF from which to obtain 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 (and can connect to an AMF that only supports 128-bit algorithms).

[0048] In order for the base station gNB to distinguish this, it can be realized by including the 256-bit compatible function of AMF in the GUAMI part of GUTI. For example, GUAMI is extended by adding a field indicating the 256-bit compatible function as follows: - <guami> := <mcc> <mnc><AMFリージョンID><AMFセットID><AMFポインタ><256-bit support> The base station gNB checks the GUAMI and is able to select an AMF that supports 128-bit MAC based on whether the previous AMF supports 128-bit MAC.

[0049] or <guami>Without changing the fields,<AMFセットID> Another method is to classify the AMFs into 128-bit compatible AMFs and 256-bit compatible AMFs. The operator places the 256-bit compatible AMFs in a specific set and sets the set ID value in the base station gNB, so that the base station gNB can select the 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] Requirement for 256-bit security using NSSAI A method of notifying the base station gNB that the 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 SST (Slice / Service Type) and SD (Slice Differentiator). The currently defined SST values ​​are shown in Table 3. [Table 3] The first 127 of the SST are defined by 3GPP, and the remaining 128 values ​​can be set independently by operators. The value of SD can also be set independently by operators. Currently defined slices are related to the type of service the network provides, and no information about security or algorithms is defined.

[0051] However, the slice information is used to select the appropriate AMF, which poses a problem when only some AMFs in the network support the 256-bit algorithm. For example, if a terminal device UE capable of supporting 256 bits requests SST4, the terminal device UE cannot use the 256-bit algorithm if the AMF that processes SST4 does not support 256 bits. We can solve this problem by defining a new slice, for example: [Table 4]

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

[0053] This embodiment also has the advantage that the home network can check the need for 256-bit security. Figure 4 shows the network slice instance selection procedure. This procedure is typically 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 tentative processing before obtaining the allowed NSSAI.

[0054] The AMF obtains the slice permitted by the user's contract and selects the appropriate network slice instance based on the permitted S-NSSAI, PLMN ID (Public Land Mobile Network ID), etc. in cooperation with the NSSF (Network Slice Selection Function). 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 Figure 4, in order to confirm the slices permitted by the contract, the AMF sends a slice information request to the UDM (S102). The UDM returns a slice information response indicating the slices permitted by the contract (S103). This feature can be used by the home network to control the use of 256-bit encryption algorithms. For example, if the visited network charges extra for the use of 256-bit encryption algorithms, it can deny the roaming UE from using 256-bit slicing. Also, if the operator offers 256-bit security for a fee, it can steer the UE to 128-bit slicing if the subscriber does not pay.

[0056] Since a registration request from a terminal device UE can only include eight slices, if the terminal device UE wants to obtain a 256-bit slice or a 128-bit slice and obtain access to five or more slices, it cannot transmit a request including that information. To solve this problem, we consider introducing a virtual 256-bit slice. If the terminal device UE wants to use 256-bit security in the slice requested by the NSSAI, it can notify the network side by requesting this virtual slice. In other words, a terminal device UE that requests 256-bit security indicates a "virtual 256-bit slice" in addition to a normal slice. In this case, the slice table will be as shown in Table 5. [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] How to notify 256-bit support status using SIB We propose two methods to inform the terminal device UE that the RAN supports 256-bit. The first method modifies the System Information Block (SIB) to add an indicator for each cell indicating whether it 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. Either method achieves optimal cell selection by checking 256-bit support in addition to other factors evaluated in conventional methods.

[0058] When selecting a cell, the terminal equipment UE acquires a Master Information Block (MIB), SIB1, and SIB2. The MIB is used by the terminal equipment UE to find an associated SIB. The SIB is system information of a cell acquired by the terminal equipment UE when selecting a cell, and 24 types are defined (SIB1 to SIB24 for 5G), 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 selection information and scheduling information, which are information related to cell access, and this embodiment is applied to this SIB1. The information related to cell access includes a PLMN ID list, a PLMN ID, a TA code, a cell ID, and a cell state. The cell selection information includes a minimum reception level. The scheduling information includes an SI message type & periodicity, SIB mapping information, and an SI window length required for the terminal device UE to identify other SIBs (from 2 to 9 in the case of LTE, or from SIB2-24 in the case of NR). For PLMN selection, it is assumed that "Operator controlled PLMN Selector with Access Technology" is used. This method is defined in TS23.122 and is performed using information stored locally in the ME (Mobile Equipment) and information stored locally in the USIM. Furthermore, the PLMN ID is composed of the Mobile Country Code (MCC) and the Mobile Network Code (MNC), and similarly, the IMSI is composed of the PLMN ID and the subscriber identifier in 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 modified after each round of the Location Information Update procedure, the Routing Area Update procedure, the GPRS Attach procedure, the Tracking Area Update procedure, the EPS Attach procedure and the Registration procedure. Therefore, this list may be modified by the mobile operator to which the UE is connected at the moment. 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 radio communications such as GSM, UMTS, LTE and NR. In addition, the USIM may contain a list of "equivalent home PLMNs", which are used to identify PLMNs that the ME has access to and which it can treat as equivalent to a home PLMN ID. The ME selects a home PLMN in preference to other PLMN IDs. The ME uses this file whenever it is available, and treats the order of the PLMN IDs listed as the priority.

[0061] The USIM file may also specify combinations of PLMN IDs and radio access technologies, and is used by the operator to specify which PLMN ID and radio access combinations should be prioritized by the ME. TS23.122 defines the automatic network selection mode procedure as shown in Table 6. [Table 6]

[0062] In this embodiment, a new priority is added based on whether the cell or network supports 256 bits. Cell selection is usually divided into two steps, as shown in Figure 5: 1) selection of a PLMN ID, 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 signals. It can also collect SIBs for radio accesses that can be received (gNB for NR, eNB for LTE, NodeB for UMTS, etc.) in the same way. After receiving the SIBs, the terminal device UE performs the following comparison for each SIB: ·Whether the PLMN ID corresponds to the PLMN ID of your 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. Depending on the PLMN IDs indicated in the SIB, the terminal device UE assigns priorities to these base stations gNBs. The ones corresponding to the LPMNs with a contract or equivalent HLPMNs are given the highest priority, and the terminal device UE compares the signal strengths and assigns priorities depending on the signal strengths. The results of the priority assignment are shown in Table 7 and Figure 8. [Table 7] Here, it is assumed that operator 1 is HPLMN. The terminal device UE sorts the received SIBs 1) according to the ordered list of prioritized PLMN IDs obtained from the storage in the terminal device UE, and 2) according to signal strength within the same PLMN ID.

[0064] 3. According to the instructions received from the 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 in Figure 9, 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 device UE is added to the conventional network selection mode, which enables the terminal device UE to select according to 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 (e.g., 1: 128 bits, 2: 256 bits, 3: 512 bits). Alternatively, each bit can indicate the supported algorithm or algorithm strength, and the base station gNB can indicate the algorithms it supports by setting the corresponding bit to 1. In either case, the supported bit size can be notified to the terminal device UE by extending SIB1.

[0066] Below, an example will be shown in which the terminal device UE of this embodiment preferentially selects a base station gNB with 256-bit support. 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 SIBs, the terminal device UE performs the following comparison for each SIB: Whether the PLMN ID corresponds to the PLMN ID of your 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, which indicates the priority of each base station.

[0067] 2. Based on the support status of 128-bit MAC indicated in the SIB, the terminal device UE removes all cells that do not support 128-bit MAC. It then assigns a priority to the base stations gNBs of the contracted carrier and compares the signal strength for each received SIB. An example of the result is shown in Table 8. [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 storage, 2) signal strength, and 3) whether they are 256-bit capable. In Table 8, the priority of cell 1 of operator 1 is set to 1. Then, cells that do not support 256-bit are removed. For cell 2 of operator 2 in row 4, the PLMN ID is from a different operator, so it may be different from the terminal device UE, but it may have the same PLMN ID subset or may not be a forbidden PLMN ID. And since it supports 256-bit, it remains as an available base station and is prioritized over base stations that do not support 256-bit. FIG. 9 is a diagram showing cell 1 of operator 1 with priority level 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 function supported by the terminal device UE. Since the base station gNB is expected to continue to support the 128-bit encryption algorithm, legacy terminal equipment UE or terminal equipment UE that does not support 256 bits can continue to be used, and there is no adverse effect due to this embodiment.

[0070] In this embodiment, the terminal device UE is notified that 256 bits are supported by changing the cell selection method, but as an alternative method, this can be achieved by adding a 256-bit compatible PLMN ID that is independent of other PLMN IDs. This allows the terminal device UE to search only for 256-bit compatible PLMN IDs as necessary, and if a receivable PLMN ID is not found, the terminal device UE selects according to the prioritization criteria defined in TS23.122. The operator configures a list of 256-bit compatible PLMN IDs in a file on the subscriber's USIM. Specifically, with the transition to 256 bits, the operator advertises the "256-bit compatible" status in each 256-bit compatible base station using the PLMN ID list. The terminal device UE uses this list to prioritize the PLMN IDs.

[0071] The list of home PLMN IDs or equivalent home PLMN IDs shall be called "File 1". A new file (hereinafter "File 2") containing a list of PLMN IDs corresponding to the 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 UE selects an "available PLMN ID" from the Home PLMN ID or a list of 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 the PLMN IDs in the "Available PLMN IDs" list depending on whether they support 256-bit compatibility. 6. After creating the prioritized PLMN ID list, the UE selects a cell to connect to based on the highest priority PLMN ID and the cell's signal strength. The flow of operation is shown in Figure 10. Although a 64-bit MAC is used as an example in Figure 10, any MAC length can be supported.

[0073] Below is an example showing how the 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. It is assumed that the list of available PLMN IDs created 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 UE's Home PLMN ID is 440 43 and the equivalent Home PLMN IDs are 440 15, 440 16, 440 43, 440 48, 440 49, 440 51, 440 52. For convenience, this list is written in Mobile Network Code (MNC) order, although 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 according to whether it is a home PLMN ID or not based on the input of file 1. 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 list of PLMN IDs that support 256 bits, and if the found home PLMN ID (440 43) supports 256 bits, assigns this PLMN ID priority 1. 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 in-memory list. If the HPLMN is not found in file 2, it is assigned priority 3 to the same list / in-memory file.

[0075] (3) In the next step 3, the terminal device UE goes back 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 manner as in step 2 to check whether the PLMN ID supports 256 bits. If it supports 256 bits, priority 2 is assigned and the PLMN ID is written to memory together with the priority. As an example, priority 2 is assigned to the following PLMN ID: 440 48 440 49 440 51 If the PLMN ID is not listed in file 2, assign it priority 4. As an example, assign priority 4 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 the file.

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

[0079] If no HPLMN ID was found in step 3, the terminal UE may have multiple PLMN IDs with priority 3 or 4. For example, the terminal UE may find four PLMN IDs with priority 3 and three with priority 4. In this case, the terminal UE can use the same logic as a terminal UE that does not support 256-bit to determine the PLMN to connect to. Since the order of the PLMN IDs in the equivalent HPLMN ID list (file 1) indicates the priority, the terminal UE will try to connect to the PLMN in the list with the highest priority of priority 3 in file 1, and if that fails, it will move on to the next PLMN.

[0080] A similar logic can be applied in step 4: for a list of PLMN IDs with priority 5, the UE will first try to connect to the PLMN with the highest priority in the "Operator Controlled PLMN Selector with Access Technology" file. If it is not included in the list, the UE will randomly select one and try to connect to it.

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

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

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

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

[0085] In case of roaming, the terminal UE has a list of forbidden PLMN IDs, which it records if a connection attempt is rejected. In that case, the PLMN ID in question is added to the "forbidden PLMN ID" list. Similarly, in a roaming scenario, the terminal UE can record which PLMN IDs were 256-bit compatible and records these PLMN IDs in the terminal UE memory as a "256-bit compatible PLMN ID" list. The terminal UE erases this list at appropriate times, e.g. after a certain time has elapsed, after being switched 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 to be 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 UE also checks whether the algorithm indicated in the SMC is a 256-bit algorithm. If the terminal UE supports a 256-bit algorithm but the algorithm indicated in the SMC is 128-bit, the terminal UE rejects the AS SMC and restarts the process. The terminal UE informs 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 the 256-bit algorithm, it sends a new AS SMC message.

[0088] In the first and second embodiments, the terminal device UE may receive a notification indicating that the RAN supports a 256-bit encryption algorithm. If the terminal device UE receives a notification indicating that the RAN supports a 256-bit encryption algorithm but 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 the NAS SMC specifies a 256-bit encryption algorithm, but the base station gNB selects a 128-bit encryption algorithm. If there is a difference in the security level of the encryption algorithms, the terminal device UE rejects AS SMC with a "256-bit compatible encryption algorithm selection error" and then performs AS SMC again.

[0090] As in the first embodiment, the base station gNB can indicate to the terminal device UE that there is a mismatch between the terminal device UE and the base station gNB regarding support for the 256-bit encryption algorithm. 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] The terminal device UE may also resend the attach request and the network NW may re-perform authentication and key agreement, in which case new NAS SMC and AS SMC are generated. It may also be possible to send an attach request to a particular PLMN ID to check whether the target PLMN ID supports the required algorithm. It may also be possible to keep a file containing a list of PLMN IDs that do not support the 256-bit algorithm and lower the priority of those PLMN IDs.

[0093] This invention enables the terminal device UE and the network NW to share support for longer common key encryption algorithms, making it possible to contribute to Goal 9 of the United Nations-led Sustainable Development Goals (SDGs), which is to "build resilient infrastructure, promote sustainable industrialization and foster innovation." [Explanation of symbols]

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

Claims

1. A network device that transmits to a terminal device a message including data indicating how many bits of a common key the network device supports for an encryption algorithm.

2. 2. 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 an ABBA parameter in a message transmitted from the network device to the terminal device.

3. 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 including data indicating how many bits of a common key an encryption algorithm the network device supports, the message including: A terminal device that notifies a network device of security functionality regarding an encryption algorithm of the terminal device by using a tamper detection algorithm different from a 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 supports 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 network slice selection assistance information NSSAI in a message sent to a base station.

7. 2. 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 receiving a message transmitted from the network device described in claim 7, which ranks the received multiple system information blocks SIB 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.

Images