Terminal, network node, and communication method

Abstract

The terminal has a transmission section that transmits a connection request message to a network, a reception section that receives a message requesting a certificate in which personal data is stored from the network, and a control section that performs a registration procedure to the network after authentication processing using the certificate is performed in the network after the transmission of the certificate by the transmission section.

Description

Technical Field

[0001] This invention relates to terminals, network nodes, and communication methods in communication systems. Background Technology

[0002] Within the 3GPP (3rd Generation Partnership Project), research was conducted on a wireless communication method known as 5G or NR (New Radio) to further increase system capacity, improve data transmission speed, and reduce latency in the radio space. In 5G, various wireless technologies were introduced to meet requirements such as throughput exceeding 10Gbps and latency below 1ms in the radio space. Furthermore, research has been conducted on 6G as a future communication system.

[0003] In addition, in recent years, as a new approach to identity management, research is being conducted on the concept and implementation technologies of autonomous identity (SSI), which allows users to manage their own identifiers or identities and control the destination without relying on centralized identity providers (ID providers) (W3C Decentralized Identifiers (DID), W3CVerifiable Credentials (VC), etc.).

[0004] In the SSI world, for example, when a user provides a service provider with attributes / certificates such as proof of attributes and qualifications, the service provider can make a decision on whether to provide the service to the user.

[0005] Existing technical documents

[0006] Non-patent literature

[0007] Non-patent literature 1: 3GPP TS 23.502 V18.3.0 (2023-09)

[0008] Non-patent literature 2: W3C Decentralized Identifiers (DIDs) v1.0, https: / / www.w3.org / TR / did-core /

[0009] Non-patent literature 3: W3C Verifiable Credentials Data Model v1.1, https: / / www.w3.org / TR / vc-data-model / Summary of the Invention

[0010] The problem that the invention aims to solve

[0011] In the past, in the network of telecommunications operators, authentication for the connection between the terminal and the network was based on the SUPI contained in the SIM card installed on the terminal (also known as the UE).

[0012] However, in traditional NW, there is no mechanism for NW connectivity of terminals based on attribute / certificate-based authentication.

[0013] The present invention was made in view of the above-mentioned problems, and its object is to provide a technology that enables a terminal to connect to the NW based on attribute / certificate-based authentication.

[0014] Methods for solving problems

[0015] Based on publicly available technology, a terminal is provided, which has: The sending unit sends connection request messages to the network; The receiving unit receives from the network a message requesting a certificate containing personal data; and After the certificate is sent by the sending unit and authentication processing using the certificate is performed in the network, the control unit executes the registration process with the network after authentication processing.

[0016] Invention Effects

[0017] According to the disclosed technology, a technique is provided that enables a terminal to connect to the NW based on attribute / certificate-based authentication. Attached Figure Description

[0018] Figure 1 This is a diagram used to illustrate an example of a communication system.

[0019] Figure 2 This is a diagram used to illustrate an example of a communication system in a roaming environment.

[0020] Figure 3 This is a diagram illustrating a common system structure example for the first to third embodiments.

[0021] Figure 4 This is a diagram illustrating the processing timing example 1 in the first embodiment.

[0022] Figure 5 This is a diagram illustrating the authentication process of S106 in the processing timing example 1 of the first embodiment.

[0023] Figure 6 This is a diagram illustrating the processing timing example 2 in the first embodiment.

[0024] Figure 7 This is a diagram illustrating the authentication process of S107 in the processing timing example 2 of the first embodiment.

[0025] Figure 8 This is a diagram illustrating the processing timing example 1 in the second embodiment.

[0026] Figure 9 This is a diagram illustrating the authentication process of S213 in Example 1 of the processing timing in the second embodiment.

[0027] Figure 10 This is a diagram illustrating the processing timing example 2 in the second embodiment.

[0028] Figure 11 This is a diagram illustrating the authentication process of S214 in the processing timing example 2 of the second embodiment.

[0029] Figure 12 This is a diagram illustrating the processing timing example 1-1 in the third embodiment.

[0030] Figure 13 This is a diagram illustrating the authentication process of S308 in the processing timing example 1-1 of the third embodiment.

[0031] Figure 14 This is a diagram illustrating the processing timing examples 1-2 in the third embodiment.

[0032] Figure 15 This is a diagram illustrating the existing 3GPP Key hierarchy generation process.

[0033] Figure 16 This is a diagram illustrating the processing timing example 2-1 in the third embodiment.

[0034] Figure 17 This is a diagram illustrating the authentication process of S309 in the processing timing example 2-1 of the third embodiment.

[0035] Figure 18 This is a diagram illustrating the processing timing example 2-2 according to the third embodiment.

[0036] Figure 19 This is a diagram illustrating an example of the functional structure of a network node 100 in an embodiment of the present invention.

[0037] Figure 20 This is a diagram illustrating an example of the functional structure of terminal 20 in an embodiment of the present invention.

[0038] Figure 21This is a diagram illustrating an example of the hardware structure of the terminal 20 and network node 100 in an embodiment of the present invention.

[0039] Figure 22 This is a diagram illustrating an example of the structure of a vehicle 2001 according to an embodiment of the present invention. Detailed Implementation

[0040] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. Furthermore, the embodiments described below are merely examples, and the application of the present invention is not limited to the embodiments described below.

[0041] In the operation of the wireless communication system according to embodiments of the present invention, existing technologies are appropriately used. However, these existing technologies are, for example, existing LTE or existing NR, but are not limited thereto.

[0042] Hereinafter, firstly, in this embodiment, an example of the structure of a 5G core network, which is an example of a network that performs authentication based on attributes / certificates, will be described, and then the structure and operation of this embodiment will be explained.

[0043] Figure 1 This is a diagram used to illustrate an example of a communication system equivalent to a core network. For example... Figure 1 As shown, this communication system consists of a UE (User Equipment) as terminal 20 and multiple network nodes. Hereinafter, it is assumed that each function corresponds to one network node; however, multiple functions can be implemented by one network node, or one function can be implemented by multiple network nodes. Furthermore, the term "connection" as used below can refer to either a logical connection or a physical connection.

[0044] A (R)AN (Radio Access Network) is a network node 30 with radio access capabilities, which may include a base station 10 and connect to a UE 20, an AMF (Access and Mobility Management Function) 30, and a UPF (User Plane Function). The AMF 30 is a network node with functions such as RAN interface termination, NAS (Non-Access Stratum) termination, registration management, connection management, reachability management, and mobility management. The UPF is a network node with functions such as PDU (Protocol Data Unit) session points interconnected with the DN (Data Network), packet routing and forwarding, and QoS (Quality of Service) processing on the user plane. The UPF and DN constitute a network slice.

[0045] AMF30 connects with UE20, (R)AN10, SMF (Session Management function), NSSF (Network Slice Selection Function), NEF (Network Exposure Function), NRF (Network Repository Function), UDM (Unified Data Management), AUSF (Authentication Server Function), PCF (Policy Control Function), and AF (Application Function). AMF30, SMF, NSSF, NEF, NRF, UDM40, AUSF80, PCF, and AF are network nodes interconnected via their respective service-based interfaces Namf, Nsmf, Nnssf, Nnef, Nnrf, Nudm, Nausf, Npcf, and Naf.

[0046] The SMF is a network node with functions such as session management, UE IP (Internet Protocol) address allocation and management, DHCP (Dynamic Host Configuration Protocol) function, ARP (Address Resolution Protocol) proxy, and roaming function. The NEF is a network node 30 with the ability to notify other NFs (Network Functions) and handle events. The NSSF is a network node with functions such as selecting the network slice to which the UE20 connects, determining the allowed NSSAI (Network Slice Selection Assistance Information), determining the configured NSSAI, and determining the set of AMFs to which the UE20 connects. The PCF is a network node with the function of network policy control. The AF is a network node with the function of controlling application servers. The NRF is a network node with the function of discovering NF instances that provide services. The UDM40 is a network node that manages subscriber data and authentication data. The UDM40 is connected to the UDR (User Data Repository) that maintains this data.

[0047] Figure 2This is a diagram illustrating an example of a communication system in a roaming environment. For example... Figure 2 As shown, the network consists of a UE (User Equipment) as terminal 20 and multiple network nodes.

[0048] SEPP is a non-transparent proxy used to filter control plane messages between PLMNs (Public Land Mobile Networks). Figure 2 The vSEPP shown is the SEPP in the visited network, and the hSEPP is the SEPP in the home network.

[0049] like Figure 2 As shown, UE20 is in a roaming environment within the VPLMN (Visited PLMN) connected to both the (R)AN and AMF30. The VPLMN and HPLMN (Home PLMN) are connected via vSEPP and hSEPP. UE20 can, for example, communicate with the UDM of the HPLMN via the AMF30 of the VPLMN.

[0050] (Regarding SSI)

[0051] As mentioned above, in recent years, as a new approach to identity management, research is being conducted on the concept and implementation technologies of autonomous identity (SSI), which allows users to manage their own identifiers or identities and control the destination without relying on centralized identity providers (ID providers). These technologies include W3C Decentralized Identifiers (DID), W3CVerifiable Credentials (VC), etc.

[0052] In the world of SSI, there are three entities: Holder, Issuer, and Verifier. The Holder is a user who manages and holds their own digital identity. The Issuer, after verifying the user's attributes (name, age, address, etc.) and qualifications (employee of a company, member of a service, etc.), issues an attribute / qualification certificate (e.g., VC). The Verifier verifies the Holder's attributes / qualifications by receiving the required attribute / qualification certificate (VC) from the Holder, and then makes a service provision decision.

[0053] As an example of an attribute / qualification certificate, there is a VC (Verifiable Credentials). A VC is a signed file that stores personal data. The attribute information and qualification information mentioned above are examples of personal data. Attribute / qualification certificates can be referred to as certificates that store personal data. Furthermore, a certificate storing personal data does not necessarily need to contain information that uniquely identifies an individual; for example, an anonymously issued membership card is also equivalent to a certificate storing personal data.

[0054] Additionally, identifiers for Issuers and Holders can be, for example, used as DIDs (Decentralized Identifiers). DIDs are registered in a distributed ledger, making them easily accessible but difficult to tamper with.

[0055] (Regarding the research topic)

[0056] In the past, in the NW (network) of telecommunications operators, authentication for connecting the UE to the NW was based on the SUPI contained in the SIM installed in the UE.

[0057] NW connectivity for UEs is made possible through authentication based on attributes / certificates such as DID and VC, for example, as follows.

[0058] • Addressing the management needs of autonomous identities

[0059] • Simplified verification process using user attributes / qualification certificates certified by a third party other than the telecommunications operator, and verified by the user themselves (e.g., KYC).

[0060] • Enable new NW connectivity services for specific service subscribers.

[0061] • NW utilization by multiple UEs without relying on SIM

[0062] However, in existing 3GPP NW technologies, there is no mechanism for enabling UE NW connectivity based on attribute / certificate-based authentication.

[0063] The following describes the first, second, and third embodiments as techniques for solving the aforementioned problems. First, an overview of the embodiments and an example of the system structure, common to the first, second, and third embodiments, will be described. Then, the first, second, and third embodiments will be described separately. Furthermore, the first, second, and third embodiments can be implemented in any combination.

[0064] (Summary of the implementation method)

[0065] First, an overview of the implementation method will be provided. In this implementation method, an NW registration and authentication function (an attribute / certificate-based authentication function) using attributes / certificates such as VC is added to the 3GPP NW. In this implementation method, two modes are envisioned for this authentication function: one is to define it as a new NF (Network Function), and the other is to extend existing functions such as AUSF.

[0066] Alternatively, "3GPP NW" can also be referred to as the core network defined by 3GPP (registered trademark). Furthermore, in this embodiment, "3GPP NW" is selected as the "network" for description, but the technology of the present invention can be applied to networks not limited to "3GPP NW".

[0067] In each implementation, a specific example of authentication logic using attributes / certificates is described, but this authentication logic is only one example and is not limited to this authentication logic.

[0068] In this embodiment, an IF (C-Plane) associated with the NW Registration of attributes / certificates between the UE and the 3GPP NW is added to the existing 3GPP NW. Specifically, it is shown in (1) and (2) below.

[0069] (1) The UE sends an additional IF of attributes / qualification certificates to the 3GPP NW via C-Plane communication. There are two modes: defining it as a new IF and adding information sent via a registration request.

[0070] (2) Add an IF that notifies the UE of the result from the authentication function that performs authentication processing using attributes / certificates. There are two modes: defining a new IF and extending an existing IF.

[0071] Furthermore, in this embodiment, additional logic is added for NW Registration license ~D-Plane connectivity after successful authentication using attribute / certificate.

[0072] Furthermore, in this embodiment, by utilizing attribute / certificate information, it is possible to register subscriber information with the UDM for purposes such as enabling billing. This subscriber information registration function was described in the first embodiment, but it is also possible to register with the UDM based on this function in the second and third embodiments.

[0073] (System architecture example)

[0074] Figure 3 Examples of common system structures in the first to third embodiments are shown. For example... Figure 3 As shown, the communication system according to this embodiment includes UE20, (R)AN10, authentication function 60 based on attribute / certificate authentication, UDM / UDR (40), and VDR (VDR: Verifiable Data Registry) 70. UDM40 is used in conjunction with UDR and is therefore referred to as UDM / UDR. The "authentication function 60" shown here can be a newly defined device (network node) or an extension of the functionality of an existing device (e.g., AUSF). Furthermore, in the description of each embodiment, "authentication function 60" is referred to as a newly defined device (network node).

[0075] UE20 has NW connection function 21. NW connection function 21 performs the actions in the timing sequence described later. In addition, UE20 may also be referred to as terminal 20.

[0076] like Figure 3 As shown, UDM / UDR (40) has NW information DB (database) 41, certificate information DB 42, and policy DB 43.

[0077] NW Information DB41 stores the NW's identifier, public key, and private key. Certificate Information DB42 stores information about certificates that can be used for NW connections. Policy DB43 stores the authentication method selection policy. Additionally, the aforementioned NW is a 3GPP NW. For example, the "NW identifier" (and similarly the NW's public and private keys) can be an identifier shared by multiple network nodes within the 3GPP NW, or it can be an identifier used by a specific network node within the 3GPP NW.

[0078] In this embodiment, VDR70 is configured outside the 3GPP NW. However, it is not limited to the structure where VDR70 is configured outside the 3GPP NW; VDR70 can also be configured inside the 3GPP NW.

[0079] VDR70 is a device that can be implemented using a web server, distributed ledger, etc. VDR70 includes user information DB71, issuer information DB72, definition information DB73, and management information DB74.

[0080] User Information DB71 stores the user's identifier and public key. Issuer Information DB72 stores the issuer's identifier and public key for the attribute / certificate used for NW connection authentication. Definition Information DB73 stores the attribute / certificate schema and definition information. Management Information DB74 stores management information indicating the validity / expiration of the attribute / certificate.

[0081] Additionally, "user" and "UE" (or "terminal") are sometimes used interchangeably. As long as the context does not contradict each other, "user" in the following description can be replaced with either "UE" or "terminal".

[0082] (First Implementation Method: Overview)

[0083] First, the first implementation method will be described. The first implementation method is the most basic implementation method. Hereinafter, an example using the newly defined network node, namely authentication function 60, as the "authentication function" will be described as processing sequence example 1, and an example using AUSF80 as the "authentication function" will be described as processing sequence example 2.

[0084] (First implementation method: Processing timing example 1)

[0085] Reference Figure 4 The processing timing example 1 in the first embodiment will be explained. Processing timing example 1 is an example using the new NF and the new IF. The premise of the processing is as follows.

[0086] Users hold a public / private key pair corresponding to their own identifier and store it in a VDR70 located in a place accessible by 3GPP NW.

[0087] Users hold attribute / qualification certificates (certificates that can be used for NW connections) issued by any entity (enterprise, other users, etc.).

[0088] The certificate issuer holds a public / private key pair corresponding to its own identifier and stores the identifier and public key in a VDR70 located in a place accessible by 3GPP NW.

[0089] The certificate issuer stores the form (mode or definition) of its issued certificates, along with information used to verify the validity of the certificates, in a VDR70 located in a place accessible by 3GPP NW. The timing is explained below.

[0090] exist Figure 4 In step S101 (step 101), NW connection processing based on attributes / certificates is initiated, triggered by user NW connection application operations or power-on of UE20.

[0091] In S102, UE20 sends an NW connection request message to the (R)AN20 of the 3GPP NW, containing the user's identifier (e.g., DID) and the user's attributes / certificates (e.g., VC), requesting an NW connection based on the attributes / certificates. In this NW connection request message, UE20 attaches a signature (e.g., VP: Verifiable Presentation) generated using the private key corresponding to the user's identifier. Alternatively, the "NW connection request message" can also be referred to as a "connection request message." An example of a "connection request message" is the registration request message, described later.

[0092] In addition to the information used for authentication, this NW connection request message contains the same information as that contained in the registration request message when making an NW connection authentication request based on SUPI / SUCI.

[0093] In S103, (R)AN20 forwards the NW connection request message received from UE20 to AMF30.

[0094] In S104, upon receiving an NW connection request message requesting an NW connection based on attributes / certificates, AMF30 selects authentication function 60 as the authentication request target. In S105, AMF30 sends an authentication request message to authentication function 60 containing the attributes / certificates included in the NW connection request message.

[0095] In S106, authentication function 60 verifies the received attribute / qualification certificate by performing authentication processing using the attribute / qualification certificate. This processing is equivalent to step 9 of 3GPP TS 23.502 4.2.2.2 Registration Procedure. S106'-1 to S106'-3 will be described later.

[0096] In S107, authentication function 60 sends an authentication response containing the authentication result (success / failure) to AMF30.

[0097] In the subsequent S108, connection processing (also known as registration processing) is performed. Specifically, this is done by executing 3GPP TS 23.502 4.2.2.2 Registration Procedure (…). Figure 42.2.2.2-1: The steps following the authentication process in step 9 of the Registration procedure, namely step 10 and subsequent steps, complete the NWRegistration process.

[0098] In addition, as part of the UE20 processing in step 10 and thereafter, there are, for example, receiving Registration Accept and sending Registration Complete.

[0099] After successful authentication in S106, for purposes such as fee requests, the following processes S106′-1 to S106′-3 may optionally be performed.

[0100] In S106'-1, the authentication function 60 sends a subscriber information registration request to the UDM / UDR (40). This subscriber information registration request includes the identifier of the received user, the user's name and address contained in the received attribute / qualification certificate, and other information. The UDM / UDR (40) registers this information as the user's subscriber information and returns a subscriber information registration response in S106'-3.

[0101] In the above-mentioned optional method, it is envisioned that the message sent in S102 includes not only the attributes / qualification certificates used for NW connection, but also other attributes / qualification certificates containing information required such as fee requests. Furthermore, when described as "attributes / qualification certificates," it can also be interpreted as including, in addition to the attributes / qualification certificates used for NW connection, other attributes / qualification certificates containing information required such as fee requests.

[0102] Next, refer to Figure 5 The authentication process in S106 is explained in detail. Here, as an example of authentication / verification processing logic, the verification of attribute / qualification certificates in the form of W3C DID / VC / VP is envisioned. Furthermore, in various embodiments, attribute / qualification certificate-based authentication processing refers to the process of authenticating the user (or terminal 20) using attribute / qualification certificates.

[0103] When the authentication process based on attribute / certificate is initiated, in S106-1, authentication function 60 requests from VDR70 the public key corresponding to the issuer's identifier and the public key corresponding to the user's identifier. In S106-2, VDR70 responds with these public keys to authentication function 60.

[0104] In S106-3, authentication function 60 verifies the legitimacy of the certificate issuer's signature and the user's signature, as well as the absence of message tampering.

[0105] Additionally, communication between the authentication function 60 within the 3GPP NW and the VDR70 outside the 3GPP NW can also be facilitated by a node (e.g., NEF, SCEF) that mediates the interaction between the authentication function 60 within the 3GPP NW and the VDR70 outside the 3GPP NW.

[0106] More specifically regarding S106-1 to S106-3, in S106-1 and S106-2, authentication function 60 receives DID0 (certificate issuer identifier) ​​and DID1 (user identifier) ​​contained in the VP / VC as input, and uses any DID method to obtain (resolve) the DID Document (public key) corresponding to DID0 and the DIDDocument (public key) corresponding to DID1 from VDR70. In S106-3, authentication function 60 verifies the VP's Holder signature and the VC's Issuer signature based on the signature of the private key associated with the corresponding public key (verifying the legitimacy of the signature and the absence of message tampering).

[0107] In S106-4, authentication function 60 requests information from VDR70 regarding the certificate's format and status (expiration status, etc.). In S106-5, VDR70 responds with the certificate's format and status information. In S106-6, authentication function 60 verifies the certificate's validity.

[0108] More specifically regarding S106-4 to S106-6, authentication function 60 obtains VC mode and definition information from VDR70 and verifies the correctness of the VC syntax. Additionally, authentication function 60 obtains VC validity / invalidity information from VDR70 and verifies the validity of the received VC.

[0109] In S106-7, authentication function 60 requests certificate information from UDM / UDR (40) that can be used for NW connection. In S106-8, UDM / UDR (40) responds with the certificate information. In S106-9, authentication function 60 performs a certificate qualification verification. More specifically, authentication function 60 verifies that the VC meets the conditions for use in NW connection (e.g., it is a Personal Number (MyNumber) VC containing the necessary information (e.g., name, address)). Furthermore, the Personal Number VC envisions transforming information equivalent to the current Personal Number into VC form.

[0110] If all the above verification results are deemed OK, the authentication function 60 determines that the authentication is successful.

[0111] (First implementation method: Processing timing example 2)

[0112] Next, refer to Figure 6 This section describes a processing sequence example 2 in the first embodiment. Processing sequence example 2 is an example of extending existing NFs and existing IFs. In processing sequence example 2, AUSF80 includes a function for attribute / certificate-based authentication. This function performs authentication processing as described later in S107.

[0113] In UDM40, the authentication method selection function based on attribute / certificate when selecting authentication method is maintained (S105), and the following information is used in the attribute / certificate method.

[0114] • The identifier of NW, the public key associated with that identifier, and the private key.

[0115] • Information about certificates that can be used for NW connections (certificate type, data format, information that should be included in the certificate, etc.)

[0116] Reference Figure 6 Explain the timing sequence.

[0117] In S101, UE20 includes the attribute / qualification certificate in a Registration Request message and sends a Registration Request message containing the attribute / qualification certificate to (R)AN10. In S102, (R)AN10 sends a Registration Request message containing the attribute / qualification certificate to AMF / SEAF (30).

[0118] In S103, AMF / SEAF (30) includes the attribute / certificate in the Nausf_UEAuthentication_Authenticate request message and sends the Nausf_UEAuthentication_Authenticate request message containing the attribute / certificate to AUSF80 as an authentication request.

[0119] In S104, AUSF80 includes the attribute / certificate in the Nudm_UEAuthentication_Get Request message and sends the Nudm_UEAuthentication_Get Request message containing the attribute / certificate to UDM / ARPF / SIDF (40) as an authentication request.

[0120] In S105, UDM / ARPF / SIDF (40) performs authentication method selection. Specifically, if the received message does not contain SUPI or SUCI but contains an attribute / qualification certificate, UDM / ARPF / SIDF (40) selects authentication based on the attribute / qualification certificate as the authentication method. When both SUPI or SUCI and the attribute / qualification certificate are included, the authentication method is selected based on a pre-registered authentication method selection policy or a user request.

[0121] In S106, UDM / ARPF / SIDF (40) includes a string indicating that the attribute / certificate authentication method has been selected (e.g., Credential Auth) in the Nudm_UEAuthentication_Get response message and sends the Nudm_UEAuthentication_Get response message containing the string to AUSF80.

[0122] In S107, AUSF80 performs attribute / certificate-based authentication processing.

[0123] In S108, AUSF80 includes a string indicating successful attribute / certificate authentication (e.g., CredentialAuth Success) in a Nausf_UEAuthentication_Authenticate response message and sends the Nausf_UEAuthentication_Authenticate response message containing that string to AMF / SEAF (30).

[0124] Then, in S109, step 10 and subsequent processing of 3GPP TS 23.502 4.2.2.2 Registration Procedure are executed to complete the NW registration process. In this NW registration process, the API based on SUPI / SUCI and the subscriber information registration process based on SUPI / SUCI are extended to be able to be performed using the user's identifier (DID, etc.) contained in the attributes / qualification certificate.

[0125] In addition, similar to the Registration Request message, attributes / certificates are also added to the Mobility Registration Update / Periodic Registration Update message.

[0126] Reference Figure 7 This section details the authentication process for S107. Similar to Example 1, as an example of the verification processing logic, we envision the verification of attributes / certificates in the form of W3C DID / VC / VP. In the following sequence, all communication between AUSF80 and VDR70 or UDM40 is conducted via new C-Plane messages.

[0127] When the authentication process based on attribute / certificate is initiated, in S107-1, AUSF80 requests from VDR70 the identifier corresponding to the issuer's identifier and the public key corresponding to the user's identifier. In S107-2, VDR70 responds to AUSF80 with these public keys.

[0128] In S107-3, AUSF80 verifies the legitimacy of the certificate issuer's signature and the user's signature, as well as the absence of message tampering.

[0129] In addition, communication between AUSF80 within 3GPP NW and VDR70 outside 3GPP NW can also be configured to be via a node that mediates the communication (e.g., NEF, SCEF).

[0130] More specifically regarding S107-1 to S107-3, in S107-1 and S107-2, the AUSF80 receives DID0 (the certificate issuer's identifier) ​​and DID1 (the user's identifier) ​​contained in the VP / VC as input. Using any DID method, it retrieves (resolves) the DID Document (public key) corresponding to DID0 and the DID Document (public key) corresponding to DID1 from the VDR70. In S107-3, the AUSF80 verifies the VP's Holder signature and the VC's Issuer signature based on the signature of the private key associated with these public keys (verification of the signature's legitimacy and absence of message tampering).

[0131] In S107-4, AUSF80 requests information from VDR70 regarding the certificate's format and status (expiration condition, etc.). In S107-5, VDR70 responds with the certificate's format and status information. In S107-6, AUSF80 verifies the certificate's validity.

[0132] Regarding S107-4 to S107-6, in more detail, the AUSF80 obtains the VC mode and definition information from the VDR70 and verifies the correctness of the VC syntax. Additionally, the AUSF80 obtains the VC validity / failure information from the VDR70 and verifies the validity of the received VC.

[0133] In S107-7, AUSF80 requests certificate information from UDM / UDR (40) that can be used for NW connection, and in S107-8, UDM / UDR (40) responds with the certificate information. In S107-9, AUSF80 performs a certificate eligibility verification. More specifically, AUSF80 verifies that the VC meets the conditions for being used for NW connection (e.g., it is a personal identification number VC that contains the necessary information (e.g., name, address)).

[0134] If all the above verification results are deemed OK, AUSF80 determines that the authentication is successful.

[0135] Alternatively, the certificate information obtained in S107-7 to S107-8 above can be included in Figure 6 The message is sent in S106, thus omitting S107-7 to S107-8.

[0136] (Effects of the first implementation method)

[0137] According to the technology of the first embodiment, terminal 20 is able to connect to NW based on attribute / certificate-based authentication.

[0138] (Summary of the second embodiment)

[0139] Next, the second embodiment will be described. In the second embodiment, compared with the basic method described in the first embodiment, an additional method and IF are added, in which the NW side notifies the UE of the attributes / certificates that are desired for NW authentication, or negotiates such information.

[0140] The following example uses the newly defined network node, namely authentication function 60, as an example of "authentication function" as processing sequence example 1, and uses AUSF80 as an example of "authentication function" as processing sequence example 2.

[0141] (Second Implementation Method: Processing Timing Example 1)

[0142] Reference Figure 8 The processing timing example 1 in the second embodiment will be explained. Processing timing example 1 is an example using the new NF and the new IF. The premise of the processing is as follows.

[0143] Users hold a public / private key pair corresponding to their own identifier and store it in a VDR70 located in a place accessible by 3GPP NW.

[0144] Users hold attribute / qualification certificates (certificates that can be used for NW connections) issued by any entity (enterprise, other users, etc.).

[0145] The certificate issuer holds a public / private key pair corresponding to its own identifier and stores the identifier and public key in a VDR70 located in a place accessible by 3GPP NW.

[0146] The certificate issuer stores the form (mode or definition) of the certificate it issues, as well as the information used to verify the validity of the certificate, in a VDR70 located in a place accessible by 3GPP NW.

[0147] The timing sequence is explained below.

[0148] exist Figure 8 In S201, NW connection processing based on attributes / certificates is initiated, triggered by user NW connection application operations or power-on of UE20.

[0149] In S202, UE20 sends an NW connection request message to (R)AN10 of 3GPP NW requesting an NW connection based on attributes / certificates.

[0150] The NW connection request message may include the user's identifier (e.g., DID). Alternatively, the message can be signed using the private key corresponding to the user's identifier before being sent.

[0151] In addition, this NW connection request message contains, in addition to the information used for authentication, the same information contained in the registration request message when making an NW connection authentication request based on SUPI / SUCI.

[0152] In S203, (R)AN20 forwards the NW connection request message received from UE20 to AMF30.

[0153] In S204, upon receiving an NW connection request message requesting an NW connection based on attributes / certificates, AMF30 selects the attribute / certificate-based authentication function 60 as the authentication request target. In S205, AMF30 sends an authentication request message requesting authentication based on attributes / certificates to the authentication function 60. Here, it is assumed that the authentication request message does not include attributes / certificates.

[0154] When authentication function 60 confirms that the received authentication request message does not contain an attribute / qualification certificate, it sends a message to AMF30 requesting the attribute / qualification certificate that UE20 wishes to provide for NW connectivity. This message contains information (conditions) indicating the attribute / qualification certificate to be provided. Examples of conditions are described below. This message may contain one or more of the following five pieces of information. Additionally, this message may also contain information other than the following five pieces of information.

[0155] • Types of certificates (e.g., Personal Identification Number, VC)

[0156] • Certificate data format / encoding format (W3C VC, JWT, etc.)

[0157] • Information that should be included in the certificate (name, age, etc.)

[0158] ·Signature algorithm or signature form

[0159] ·Version

[0160] Additionally, information (conditions) regarding attributes / qualification certificates that can be used for NW connection can be held by the memory of authentication function 60, or information stored in UDM40, etc., can also be obtained.

[0161] In S207, AMF30 forwards the message received from authentication device 60 to (R)AN10. In S208, (R)AN10 forwards the message to UE20.

[0162] In S209, UE20 displays the information contained in the message received from (R)AN10 on the display, and the user of UE20 confirms the conditions of the requested attribute / certificate.

[0163] When the user agrees to provide information, in S210, a response message containing the requested attribute / qualification certificate (e.g., VC) and user identifier (e.g., DID) is sent. In this response message, a signature (e.g., VP) generated using the private key corresponding to the user's identifier is appended by UE20.

[0164] Furthermore, in the example above, it is set as a user (person) confirmation condition, but it can also be set as an automatic confirmation condition by UE20.

[0165] Upon receiving the response message, (R)AN10 forwards the response message to AMF30 in S211. In S212, AMF30 forwards the response message to authentication function 60.

[0166] In S213, authentication function 60 verifies the received attribute / qualification certificate by performing attribute / qualification certificate-based authentication processing. In S214, authentication function 60 sends an authentication response containing the authentication result (success / failure) to AMF30.

[0167] In the subsequent S215, connection processing is performed. Specifically, NW registration is completed by executing step 10 and subsequent processes of the 3GPP TS 23.502 4.2.2.2 Registration Procedure.

[0168] Next, refer to Figure 9 The details of S213 are explained below. Here, as an example of authentication / verification processing logic, the verification of attribute / qualification certificates in the form of W3C DID / VC / VP is envisioned. Furthermore, regarding authentication processing using attribute / qualification certificates, the same processing is described in each embodiment.

[0169] When the authentication process based on attribute / certificate is initiated, in S213-1, authentication function 60 requests from VDR70 the public key corresponding to the issuer's identifier and the public key corresponding to the user's identifier. In S213-2, VDR70 responds with these public keys to authentication function 60.

[0170] In S213-3, authentication function 60 verifies the legitimacy of the certificate issuer's signature and the user's signature / no message tampering.

[0171] Alternatively, communication between authentication function 60 and VDR70 can be configured via a node (e.g., NEF, SCEF) that mediates the interaction between authentication function 60 within 3GPP NW and VDR70 outside 3GPP NW.

[0172] More specifically regarding S213-1 to S213-3, in S213-1 and S213-2, authentication function 60 receives DID0 (certificate issuer identifier) ​​and DID1 (user identifier) ​​contained in the VP / VC as input, and uses any DID Method to obtain (resolve) the DID Document (public key) corresponding to DID0 and the DID Document (public key) corresponding to DID1 from VDR70. In S213-3, authentication function 60 verifies the VP's Holder signature and the VC's Issuer signature based on the signature of the private key associated with these public keys (the legitimacy of the signature, and the absence of message tampering).

[0173] In S213-4, authentication function 60 requests information from VDR70 regarding the certificate's format and status (expiration status, etc.). In S213-5, VDR70 responds with the certificate's format and status information. In S213-6, authentication function 60 verifies the certificate's validity.

[0174] More specifically regarding S213-4 to S213-6, authentication function 60 obtains VC mode and definition information from VDR70 and verifies the correctness of the VC syntax. Additionally, authentication function 60 obtains VC validity / invalidity information from VDR70 and verifies the validity of the received VC.

[0175] In S213-7, authentication function 60 performs qualification verification of the certificate. More specifically, authentication function 60 verifies that the VC meets the conditions for use in NW connection (e.g., it is a personal identification number VC containing necessary information such as name and address). Furthermore, these conditions are for the purpose of... Figure 8 It has been obtained in accordance with the request of S206.

[0176] If all the above verification results are deemed OK, the authentication function 60 determines that the authentication is successful.

[0177] (Second Implementation Method: Processing Timing Example 2)

[0178] Next, refer to Figure 10 This section describes the processing sequence example 2 in the second embodiment. Processing sequence example 2 is an example of extending existing NFs and existing IFs. In processing sequence example 2, AUSF80 includes a function for performing attribute / certificate-based authentication. Through this function, authentication processing such as S207, described later, is performed.

[0179] UDM40 retains the authentication method selection function based on attribute / certificate when selecting authentication method (utilized in S205), and the following information is used in attribute / certificate selection.

[0180] • The identifier of NW, the public key associated with that identifier, and the private key.

[0181] • Information about certificates that can be used for NW connections (certificate type, data format, information that should be included in the certificate, etc.)

[0182] Reference Figure 10 Explain the timing sequence.

[0183] In S201, UE20 includes information indicating that it is entrusting the performance of attribute / certificate-based authentication (e.g., an arbitrary string) in a Registration Request message and sends a Registration Request message containing this information to (R)AN10. In S202, (R)AN10 sends a Registration Request message containing this information to AMF / SEAF (30).

[0184] In S203, AMF / SEAF (30) includes information indicating that the delegated authentication based on attribute / certificate is performed in a Nausf_UEAuthentication_Authenticate Request message and sends the Nausf_UEAuthentication_Authenticate Request message containing this information as an authentication request to AUSF80.

[0185] In S204, AUSF80 sends a Nudm_UEAuthentication_Get Request message containing the above information to UDM / ARPF / SIDF (40) as an authentication request.

[0186] In S205, UDM / ARPF / SIDF (40) performs authentication method selection. Specifically, if the received message does not contain SUPI or SUCI but contains execution delegation information for attribute / qualification certificate authentication, UDM / ARPF / SIDF (40) selects attribute / qualification certificate-based authentication as the authentication method. Alternatively, if the message contains both SUPI or SUCI and attribute / qualification certificate authentication execution delegation information, the authentication method is selected based on a pre-registered authentication method selection policy or user request.

[0187] In S206, UDM / ARPF / SIDF (40) includes a string indicating that the attribute / certificate authentication method has been selected (e.g., Credential Auth) in the Nudm_UEAuthentication_Get response message, and sends the Nudm_UEAuthentication_Get response message containing the string to AUSF80.

[0188] Upon receiving the Nudm_UEAuthentication_Get response message containing the string, the AUSF80 sends a message to the AMF / SEAF (30) in S207 requesting the attribute / certificate that can be used for the NW connection.

[0189] Furthermore, the information (conditions) regarding attributes / qualification certificates that can be used for NW connection, as specified in the above request, can be held by the memory of AUSF80, or obtained from information stored in UDM40, etc. In the latter case, this information (conditions) can be included in the message of S206 to notify the user, or it can be obtained from AUSF80 to UDM40 by receiving the message of S206, etc.

[0190] In S208, AMF / SEAF (30) sends the message to (R)AN10, and in S209, (R)AN10 sends the message to UE20.

[0191] In S210, UE20 displays the information contained in the message received from (R)AN10 on the display, and the user of UE20 confirms the conditions of the requested attribute / certificate.

[0192] When the user agrees to provide information, in S211, UE20 sends a response message containing the requested attribute / qualification certificate (e.g., VC) and user identifier (e.g., DID). Furthermore, confirmation of the conditions can also be performed automatically by UE20. In this response message, UE20 appends a signature (e.g., VP) generated using the private key corresponding to the user's identifier.

[0193] Upon receiving the response message, (R)AN10 forwards the message to AMF30 in S212. In S213, AMF30 forwards the response message to authentication function 60.

[0194] In S214, the authentication function 60 verifies the received attribute / qualification certificate by performing an authentication process based on the attribute / qualification certificate.

[0195] In S215, authentication function 60 includes a string indicating successful authentication based on attribute / credential (e.g., Credential Auth Success) in a Nausf_UEAuthentication_Authenticate response message and sends the Nausf_UEAuthentication_Authenticate response message containing that string to AMF / SEAF (30).

[0196] In the subsequent S216, connection processing is performed. Specifically, NW registration processing is completed by executing step 10 and subsequent processes of the 3GPP TS 23.502 4.2.2.2 Registration Procedure. Furthermore, in this NW registration process, the API-based or SUPI / SUCI-based subscriber information registration processing is extended to allow the use of the user's identifier (DID, etc.) contained in the attributes / qualification certificates.

[0197] In addition, Figure 10 In the timing sequence, the new C-Plane message is used in S207~S209 and S211~S213.

[0198] In addition, similar to the example above, attributes / certificates are also added to the Mobility Registration Update / Periodic Registration Update message.

[0199] Reference Figure 11 This section details S214. Here, similarly to the above, as an example of authentication / verification processing logic, we envision the verification of attribute / qualification certificates in the form of W3C DID / VC / VP.

[0200] When the authentication process based on attribute / certificate is initiated, in S214-1, AUSF80 requests from VDR70 the public key corresponding to the issuer's identifier and the public key corresponding to the user's identifier. In S214-2, VDR70 responds to AUSF80 with these public keys.

[0201] In S214-3, AUSF80 verifies the legitimacy of the certificate issuer's signature and the user's signature / the message has not been tampered with.

[0202] In addition, communication between AUSF80 and VDR70 can also be achieved through nodes (e.g., NEF, SCEF) that mediate the interaction between AUSF80 within the 3GPP NW and VDR70 outside the 3GPP NW.

[0203] More specifically regarding S214-1 to S214-3, in S214-1 and S214-2, the AUSF80 receives DID0 (the certificate issuer's identifier) ​​and DID1 (the user's identifier) ​​contained in the VP / VC as input. Using any DID Method, it retrieves (resolves) the DID Document (public key) corresponding to DID0 and the DID Document (public key) corresponding to DID1 from the VDR70. In S214-3, the AUSF80 verifies the VP's Holder signature and the VC's Issuer signature based on the signature of the private key associated with these public keys (verification of the signature's legitimacy and absence of message tampering).

[0204] In S214-4, AUSF80 requests information from VDR70 regarding the certificate's format and status (expiration condition, etc.). In S214-5, VDR70 responds with the certificate's format and status information. In S213-6, AUSF80 verifies the certificate's validity.

[0205] Regarding S214-4 to S214-6, in more detail, the AUSF80 obtains VC mode and definition information from the VDR70 and verifies the correctness of the VC syntax. Additionally, the AUSF80 obtains VC validity / failure information from the VDR70 and verifies the validity of the received VC.

[0206] In S214-7, AUSF80 implements certificate eligibility verification. More specifically, AUSF80 verifies that a VC meets the conditions for use in NW connections (e.g., it is a Personal Identification VC containing the necessary information such as name and address).

[0207] If all the above verification results are deemed OK, AUSF80 considers the authentication successful. Additionally, Figure 11 In the process, all communication between AUSF80 and VDR70 or UDM40 is performed using the new C-Plane message.

[0208] (Effects of the second implementation method)

[0209] According to the technology of the second embodiment, terminal 20 can connect to NW based on attribute / certificate-based authentication.

[0210] Furthermore, in the second embodiment, authentication function 60 / AUSF80 can request attribute / qualification certificates for NW connection from UE20, and UE20 can send the agreed attribute / qualification certificates to NW. Therefore, UE20 can avoid sending unnecessary attribute / qualification certificates to NW, and NW can obtain the necessary attribute / qualification certificates for authentication.

[0211] (Summary of the third embodiment)

[0212] Next, the third embodiment will be described. In the third embodiment, compared with the basic method described in the first embodiment, logic and IF statements for "D-Plane communication encryption method, key generation, and key sharing" in UE20 and 3GPP NW are added, as well as a method for 3GPP NW authentication based on UE20 and an IF statement for that method are added. Alternatively, only one of the following additions may be made: the logic and IF statements for "D-Plane communication encryption method, key generation, and key sharing" in UE20 and 3GPP NW, and the method for 3GPP NW authentication based on UE20.

[0213] The following example uses the newly defined network node, namely authentication function 60, as an example of "authentication function" as processing sequence example 1, and uses AUSF80 as an example of "authentication function" as processing sequence example 2.

[0214] In the third embodiment, processing timing example 1 has processing timing example 1-1 and processing timing example 1-2, and processing timing example 2 has processing timing example 2-1 and processing timing example 2-2.

[0215] In processing sequence examples 1-1 and 2-1, the communication is encrypted using the NW / user's public key. In processing sequence examples 1-2 and 2-2, a root key K is generated, and the communication is encrypted using a shared key derived from the root key K.

[0216] The following describes the processing sequence examples.

[0217] (Third implementation method: Processing timing example 1-1)

[0218] Reference Figure 12 The processing timing example 1-1 in the third embodiment will be explained. The summary of the encryption method here is as follows.

[0219] • Communication between UE and NW is encrypted using NW's public key and decrypted using NW's private key.

[0220] • Communication between NW and UE is encrypted using the user's public key and decrypted using the user's private key.

[0221] The NW's private key is used to sign the message in the NW→UE direction, and the NW's public key is used to verify it on the UE side, thereby realizing UE-based NW authentication.

[0222] In addition, the user's private key (the private key corresponding to the user's identifier) ​​is used to sign the messages in the UE→NW direction, and the user's public key (the public key corresponding to the user's identifier) ​​is used to verify them on the NW side, thereby realizing NW-based UE authentication.

[0223] The prerequisites for processing in timing are as follows.

[0224] Users hold a public / private key pair corresponding to their own identifier and store it in a VDR70 located in a place accessible by 3GPP NW.

[0225] Users hold attribute / qualification certificates (certificates that can be used for NW connections) issued by any entity (enterprise, other users, etc.).

[0226] The certificate issuer holds a public / private key pair corresponding to its own identifier and stores the identifier and public key in a VDR70 located in a place accessible by 3GPP NW.

[0227] The certificate issuer stores the form (mode or definition) of the certificate it issues, as well as the information used to verify the validity of the certificate, in a VDR70 located in a place accessible by 3GPP NW.

[0228] In 3GPP NW, a public / private key pair is held that corresponds to its own identifier.

[0229] The method of distributing the NW public key to UE20 is not limited to a specific method, for example, the following methods (1) or (2) can be used.

[0230] Method (1): In a VDR70 located in a location accessible to UE20, the identifier of the NW is pre-stored along with the public key. The public key is obtained by UE20 when accessing VDR70 at any given time. This method relies on the premise that the identifier information of the NW, which serves as the key for VDR access, is pre-stored on the UE20 side.

[0231] Method (2): The public key is pre-installed in the UE20 along with the UE20's NW connectivity features / applications.

[0232] exist Figure 12 In the timeline, we envision using method (1). Figure 12 In S301-1, UE20 requests the public key associated with the identifier of the 3GPP NW from VDR70. In S301-2, VDR70 responds to UE20 with the public key associated with the identifier of the 3GPP NW.

[0233] That is, in S301-1 to S301-2, UE20 takes the identifier of 3GPP NW as input and obtains the corresponding public key from VDR70.

[0234] S301-1 to S301-2 can be performed, for example, by means of communication other than the 3GPP NW of the connection object. Alternatively, S301-1 to S301-2 can be implemented by extending the UE and the 3GPP NW so that this communication can be performed via the 3GPP NW even before the connection to the 3GPP NW of the connection object.

[0235] In S302, NW connection processing based on attributes / certificates is initiated, triggered by user NW connection application operations or power-on of UE20.

[0236] In S303, UE20 sends an NW connection request message to 3GPP NW's (R)AN20, containing the user's identifier (e.g., DID) and the user's attributes / qualification certificates (e.g., VC), to request an attribute / qualification certificate-based NW connection. The information contained in this NW connection request message is signed by UE20 using the private key corresponding to the user's identifier (e.g., VP). Furthermore, this information is encrypted by UE20 using the 3GPP NW's public key. UE20 may also include the public key corresponding to the user's identifier in the NW connection request message and send an NW connection request message containing that public key.

[0237] The information contained in the NW connection request message includes attributes / certificates. Alternatively, the information contained in the NW connection request message can also be the entire NW connection request message. That is, the signed or encrypted information can be just attributes / certificates, attributes / certificates and other information, or the entire NW connection request message.

[0238] In the future, when signing or encrypting the information contained in a message, the process can be similar to the above, either signing or encrypting only the information within the message or signing or encrypting the entire message.

[0239] That is, in the third embodiment, regarding the signature, in both the UE→NW direction message and the NW→UE direction message, the message as a whole can be signed, or the information contained in the message (attributes / certificates, etc.) can be signed.

[0240] Furthermore, regarding encryption in both the UE→NW and NW→UE communication, the entire message can be encrypted, or only the information contained within the message (attributes / certificates, etc.) can be encrypted.

[0241] In addition to the authentication information, the NW connection request message may also contain the same information as that contained in the registration request message when making an NW connection authentication request based on SUPI / SUCI.

[0242] In S304, (R)AN20 forwards the NW connection request message requesting an NW connection based on attributes / certificates to AMF30.

[0243] In S305, upon receiving an NW connection request message requesting an NW connection based on attribute / certificate, AMF30 selects the authentication function 60, which performs attribute / certificate-based authentication, as the authentication request target. In S306, AMF30 sends an authentication request message to the authentication function 60 containing an attribute / certificate encrypted using the 3GPP NW public key.

[0244] In S307, authentication function 60 uses its own (3GPP NW) private key to decrypt the information contained in the received message. The 3GPP NW private key can be pre-set in each NF (network node) or stored in a database such as UDM / UDR, and obtained by each NF through API, etc.

[0245] Additionally, regarding S306 mentioned above, in AMF30, the message can be decrypted using NW's private key, and the plaintext attributes / certificate can be presented to the authentication function 60.

[0246] In S308, authentication function 60 verifies the received attribute / certificate by performing attribute / certificate-based authentication processing. More specifically, in the attribute / certificate-based Primary Authentication process (certificate verification step), authentication function 60 obtains the public key corresponding to the user's identifier from VDR 70 and utilizes that public key. Furthermore, if the user's public key is contained in the message in S303, the user's public key can also be extracted from the message and utilized.

[0247] In S309, authentication function 60 sends an authentication response containing the authentication result (success / failure) to AMF30. For subsequent communication from 3GPP NW to UE20, this is implemented by signing the message using the NW's private key and then encrypting it using the user's public key.

[0248] In S310, the NW registration process is completed by executing step 10 and subsequent processes of the 3GPP TS 23.502 4.2.2.2 Registration Procedure. The following processes are performed as part of the S310 process.

[0249] In S310-1, the AMF30 sends an authentication authorization message. The information contained in this message is signed by the AMF30 using the NW's private key and encrypted using the user's public key.

[0250] In S310-2, (R)AN10 forwards the authentication authorization message to UE20. The information contained in the authentication authorization message is signed using the NW's private key and encrypted using the user's public key.

[0251] In S310-3, UE20 uses the user's private key to decrypt the information contained in the received authentication authorization message and uses the NW's public key to perform signature verification. Since signature verification can detect NW impersonation, it is equivalent to NW authentication.

[0252] After confirming that the source of the authentication authorization message is not impersonating NW, UE20 uses the 3GPP NW's public key to encrypt the information contained in the authentication completion message, sends the authentication completion message containing the encrypted information, and continues communication with NW.

[0253] Reference Figure 13 This section details S308. Here, as an example of authentication / verification processing logic, we envision the verification of attribute / qualification certificates in the form of W3CDID / VC / VP.

[0254] When authentication processing based on attribute / certificate is initiated, in S308-1, authentication function 60 requests from VDR70 the public key corresponding to the issuer's identifier and the public key corresponding to the user's identifier. In S308-2, VDR70 responds to authentication function 60 with the public key.

[0255] In S308-3, authentication function 60 verifies the legitimacy of the certificate issuer's signature and the user's signature, as well as that there has been no message tampering.

[0256] Alternatively, the communication between the authentication function 60 within the 3GPP NW and the VDR70 outside the 3GPP NW can also be configured via a node (e.g., NEF, SCEF) that mediates the interaction between the authentication function 60 within the 3GPP NW and the VDR70 outside the 3GPP NW.

[0257] More specifically regarding S308-1 to S308-3, in S308-1 and S308-2, authentication function 60 receives DID0 (certificate issuer identifier) ​​and DID1 (user identifier) ​​contained in the VP / VC as input, and uses any DID Method to obtain (resolve) the DID Document (public key) corresponding to DID0 and the DID Document (public key) corresponding to DID1 from VDR70. In S308-3, authentication function 60 verifies the VP's Holder signature and the VC's Issuer signature based on the signature of the private key associated with these public keys (the legitimacy of the signature, and the absence of message tampering).

[0258] In S308-4, authentication function 60 requests information from VDR70 regarding the certificate's format and status (expiration status, etc.). In S308-5, VDR70 responds with the certificate's format and status information. In S308-6, authentication function 60 verifies the certificate's validity.

[0259] Regarding S308-4 to S308-6, more specifically, authentication function 60 obtains VC mode, definition information, etc. from VDR70, and verifies the correctness of the VC syntax, etc. Additionally, authentication function 60 obtains VC validity / invalidity information from VDR70, verifying the validity of the received VC.

[0260] In S308-7, authentication function 60 requests certificate information from UDM / UDR (40) that can be used for NW connection. In S308-8, UDM / UDR (40) responds with the certificate information. In S308-9, authentication function 60 performs a certificate qualification verification. More specifically, authentication function 60 verifies that the VC meets the conditions for being used for NW connection (e.g., it is a personal identification number VC containing the necessary information (e.g., name, address)). If all the above verification results are OK, authentication function 60 determines that the authentication is successful.

[0261] In addition, Figure 12 If the S303 message contains the user's public key, S308-1 and S308-2 can be omitted.

[0262] (Third implementation method: Processing timing example 1-2)

[0263] Next, refer to Figure 14 The processing timing examples 1-2 in the third embodiment are explained. The encryption method is different from that in processing timing example 1-1. In processing timing example 1-2, (R)AN10 and AMF30 have the same functions as in processing timing example 1-1, and are responsible for forwarding new messages that are unique to processing timing example 1-2.

[0264] The processing of (R)AN10 and AMF30 in processing timing example 1-2 is basically the same as the processing of (R)AN10 and AMF30 in processing timing example 1-1. Therefore, in Figure 14 The records of (R)AN10 and AMF30 are omitted.

[0265] The encryption method in the processing sequence example 1-2 is summarized below.

[0266] • As part of the successful authentication process, in 3GPP NW, a root key K is generated for exporting the shared key and shared with the UE20 side.

[0267] Based on K, following the existing 3GPP Key hierarchy generation process, various keys for encryption are derived on both the NW side and the UE20 side.

[0268] The NW's private key is used to sign the message in the NW→UE direction, and the NW's public key is used to verify it on the UE20 side, thereby realizing NW authentication based on UE20.

[0269] The premises in processing timing example 1-2 are the same as those in processing timing example 1-1.

[0270] exist Figure 14 In S301-1, UE20 requests the public key associated with the 3GPP NW identifier from VDR70. In S301-2, VDR70 responds to UE20 with the public key associated with the 3GPP NW identifier. That is, in S301-1 to S301-2, UE20 uses the 3GPP NW identifier as input to obtain the corresponding public key from VDR70.

[0271] S301-1 to S301-2 can be performed, for example, by means of communication other than the 3GPP NW of the connection object. Alternatively, S301-1 to S301-2 can be implemented by extending UE20 and 3GPP NW so that this communication can be performed via 3GPP NW even before the connection to the 3GPP NW of the connection object.

[0272] Similar to the processing timing example 1-1, S301-1 to S301-2 can also be omitted by pre-installing the NW's public key along with the NW connection function / application, etc., on the UE20.

[0273] In S302, NW connection processing based on attributes / certificates is initiated, triggered by user NW connection application operations or power-on of UE20.

[0274] In S303, UE20 sends an NW connection request message to authentication device 60, including the user's identifier (e.g., DID) and the user's attribute / qualification certificate (e.g., VC), to request an attribute / qualification certificate-based NW connection. The information contained in this NW connection request message is signed by UE20 using the private key corresponding to the user's identifier (e.g., VP). Furthermore, the information contained in this NW connection request message is encrypted by UE20 using the 3GPP NW public key. UE20 may also include the public key corresponding to the user's identifier in the NW connection request message and send the NW connection request message containing that public key.

[0275] In S304, authentication function 60 uses its own (3GPP NW) private key to decrypt the received message. The 3GPP NW private key can be preset in each NF or stored in a DB such as UDM / UDR (40), and obtained by each NF through API, etc.

[0276] In S305, authentication function 60 verifies the received attribute / certificate by performing attribute / certificate-based authentication processing. More specifically, in the attribute / certificate-based Primary Authentication process (certificate verification step), authentication function 60 obtains the public key corresponding to the user's identifier from VDR 70 and utilizes that public key. Furthermore, if the user's public key is included in the message of S303, the user's public key can also be extracted from the message and utilized. The details of S305 are the same as the authentication processing described above.

[0277] After successful authentication, authentication function 60 generates the root key K in S306, which is used in the export of the shared key for encryption.

[0278] In S307, authentication function 60 encrypts K using the user's public key and sends a message containing the encrypted K to UE20. Through authentication function 60, the information contained in the message is appended with a signature generated using NW's private key. The "information contained in the message" can be the "message" itself.

[0279] In S308, UE20 uses the user's private key to decrypt the information contained in the received message, extracts K, and performs signature verification using NW's public key. Signature verification is used by UE20 to detect NW impersonation, essentially serving as NW authentication based on UE20.

[0280] In S309, UE20 and NW are respectively based on K, and processed according to the existing 3GPP key hierarchy generation. Figure 15 This process derives various keys for encryption. Subsequent communication between the 3GPP NW and UE20 is implemented using these derived keys for encryption.

[0281] (Third implementation method: Processing timing example 2-1)

[0282] Next, refer to Figure 16 The following describes the processing sequence example 2-1 in the third embodiment. In processing sequence example 2-1, AUSF80 includes a function for performing attribute / certificate-based authentication. Through this function, authentication processing such as S309, described later, is performed.

[0283] In UDM40, the authentication method selection function based on attribute / certificate when selecting authentication method is retained (utilized in S307), and the following information is utilized in attribute / certificate method.

[0284] • The identifier of NW, the public key associated with that identifier, and the private key.

[0285] • Certificate information that can be used for NW connection (certificate type, data format, information that should be included in the certificate, etc.)

[0286] Reference Figure 16 Explain the timing sequence.

[0287] In S301-1, UE20 requests the public key associated with the identifier of the 3GPP NW from VDR70. In S301-2, VDR70 responds to UE20 with the public key associated with the identifier of the 3GPP NW.

[0288] That is, in S301-1 to S301-2, UE20 takes the identifier of 3GPP NW as input and obtains the corresponding public key from VDR70.

[0289] S301-1 to S301-2 can be performed, for example, by using a communication method other than the 3GPP NW for preparing the connection target. Alternatively, S301-1 to S301-2 can be implemented by extending the UE and the 3GPP NW so that this communication can be performed via the 3GPP NW even before connecting to the 3GPP NW of the connection target. Alternatively, S301-1 to S301-2 can be pre-installed on the UE20 along with the NW connection functions / applications, thus omitting S301-1 to S301-2.

[0290] In S302, UE20 includes the attribute / qualification certificate in a Registration Request message and sends a Registration Request message containing the attribute / qualification certificate to (R)AN10. The information (attribute / qualification certificate, etc.) included in the Registration Request message is signed by UE20 using a private key corresponding to the user's identifier (e.g., VP). Furthermore, this information is encrypted by UE20 using the public key of the 3GPP NW.

[0291] In S303, (R)AN10 forwards the registration request message containing the attribute / certificate encrypted using the public key of 3GPP NW to AMF / SEAF (30).

[0292] In S304, AMF / SEAF (30) includes an attribute / certificate encrypted with the public key of 3GPP NW in the Nausf_UEAuthentication_Authenticate Request message, and sends the Nausf_UEAuthentication_Authenticate Request message containing the attribute / certificate as an authentication request to AUSF80.

[0293] In S305, AUSF80 includes the attribute / certificate encrypted with the public key of 3GPP NW in the Nudm_UEAuthentication_Get Request message, and sends the Nudm_UEAuthentication_Get Request message containing the attribute / certificate as an authentication request to UDM / ARPF / SIDF (40).

[0294] In S306, UDM / ARPF / SIDF (40) uses its own (3GPP NW) private key to decrypt the information (attributes / certificates, etc.) contained in the received message. It is assumed that the 3GPP NW's private key is kept by UDM / UDR (40). Furthermore, the 3GPP NW's private key can be processed only within the UDM, shared with other nodes such as AUSF80 as needed, or stored in the memory of each node.

[0295] In S307, UDM / ARPF / SIDF (40) performs authentication method selection.

[0296] Specifically, if the received message contains attributes / certificates but not SUPI or SUCI, then authentication based on attributes / certificates is selected as the authentication method. When both SUPI or SUCI and attributes / certificates are included, the authentication method is selected based on a pre-registered authentication method selection policy or a user request.

[0297] In S308, UDM / ARPF / SIDF (40) includes a string indicating the selected attribute / certificate authentication method (e.g., Credential Auth) in the Nudm_UEAuthentication_Get response message, and sends the Nudm_UEAuthentication_Get response message containing this string to AUSF80. This message contains the attribute / certificate decrypted by UDM40. Furthermore, this message may contain the encrypted attribute / certificate and the private key of the NW stored in UDM40. In this case, the attribute / certificate is decrypted in AUSF80.

[0298] In S309, AUSF80 performs authentication processing based on attributes / certificates.

[0299] In S310, AUSF80 includes a string indicating successful attribute / certificate authentication (e.g., CredentialAuth Success) in a Nausf_UEAuthentication_Authenticate response message and sends the Nausf_UEAuthentication_Authenticate response message containing that string to AMF / SEAF (30).

[0300] Subsequently, in S311, step 10 and subsequent processing of the 3GPP TS 23.502 4.2.2.2 Registration Procedure are executed to complete the NW registration process. In this NW registration process, the SUPI / SUCI-based API or SUPI / SUCI-based subscriber information registration process is extended to be able to be performed using the user's identifier (DID, etc.) contained in the attributes / qualification certificate.

[0301] As part of the process in S311, the following process is performed.

[0302] In S311-1, AMF / SEAF (30) sends a Registration Accept message. The information contained in the Registration Accept message is signed by AMF / SEAF (30) using NW's private key and encrypted using the user's public key.

[0303] In S311-2, (R)AN10 forwards the Registration Accept message to UE20. The information contained in the Registration Accept message is signed with the NW's private key and encrypted with the user's public key.

[0304] In S311-3, UE20 uses the user's private key to decrypt the information contained in the received RegistrationAccept message and uses NW's public key to perform signature verification.

[0305] After confirming that the source of the Registration Accept message is not impersonating NW, UE20 uses the 3GPP NW's public key to encrypt the information contained in the Registration Complete message, sends the Registration Complete message containing the encrypted information, and continues communication with NW.

[0306] Additionally, similar to the example above, attributes / certificates are also added to the Mobility Registration Update / Periodic Registration Update message.

[0307] Reference Figure 17 This section details S309. Here, similarly to the above, as an example of verification processing logic, we envision the verification of attributes / certificates in the form of W3C DID / VC / VP. In the following sequence, all communication between AUSF and VDR or UDM is conducted via new C-Plane messages.

[0308] When starting attribute / certificate-based authentication processing, in S309-1, AUSF80 requests from VDR70 the public key corresponding to the issuer's identifier and the public key corresponding to the user's identifier. In S309-2, VDR70 responds to AUSF80 with the public key.

[0309] In S309-3, AUS F80 verifies the legitimacy of the certificate issuer's signature and the user's signature / the message has not been tampered with.

[0310] In addition, communication between AUSF80 within the 3GPP NW and VDR70 outside the 3GPP NW can also be configured to be via a node that mediates the communication (e.g., NEF, SCEF).

[0311] More specifically regarding S309-1 to S309-3, in S309-1 and S309-2, the AUSF80 receives DID0 (the certificate issuer's identifier) ​​and DID1 (the user's identifier) ​​contained in the VP / VC as input, and uses any DID Method to retrieve (resolve) the DID Document (public key) corresponding to DID0 and the DID Document (public key) corresponding to DID1 from the VDR70. In S309-3, the AUSF80 verifies the VP's Holder signature and the VC's Issuer signature based on the signature of the private key associated with these public keys (verification of the signature's legitimacy and absence of message tampering).

[0312] exist Figure 16 If the user's public key is included in the S302 message, S309-1 to S309-3 can be omitted.

[0313] In S309-4, AUSF80 requests information from VDR70 regarding the certificate's format and status (expiration condition, etc.). In S309-5, VDR70 responds with the certificate's format and status information. In S309-6, AUSF80 verifies the certificate's validity.

[0314] In S309-4 to S309-6, more specifically, the AUSF80 obtains VC mode and definition information from the VDR70 and verifies the correctness of the VC syntax. Additionally, the AUSF80 obtains VC validity / failure information from the VDR70 and verifies the validity of the received VC.

[0315] In S309-7, AUSF80 requests certificate information from UDM / UDR (40) that can be used for NW connection, and in S309-8, UDM / UDR (40) responds with the certificate information. In S309-9, AUSF80 performs a certificate eligibility verification. More specifically, AUSF80 verifies that the VC meets the conditions for being used for NW connection (e.g., it is a personal identification number VC that contains the necessary information (e.g., name, address)).

[0316] If all the above verification results are deemed OK, AUSF80 considers the authentication successful. Alternatively, it can also be done through... Figure 16 The S308 message includes certificate information and is sent accordingly, thus omitting S309-7 to S309-8.

[0317] (Third implementation method: Processing timing example 2-2)

[0318] Next, refer to Figure 18The following describes the processing sequence example 2-2 in the third embodiment. In processing sequence example 2-2, AUSF80 also includes a function for authentication based on attributes / certificates. This function enables the authentication processing described later in S309.

[0319] In UDM40, the authentication method selection function based on attribute / certificate when selecting authentication method is retained (utilized in S307), and the following information is utilized in attribute / certificate method.

[0320] • The identifier of NW, the public key associated with that identifier, and the private key.

[0321] • Certificate information that can be used for NW connection (certificate type, data format, information that should be included in the certificate, etc.)

[0322] Reference Figure 18 Explain the timing sequence.

[0323] In S301-1, UE20 requests the public key associated with the identifier of the 3GPP NW from VDR70. In S301-2, VDR70 responds to UE20 with the public key associated with the identifier of the 3GPP NW.

[0324] That is, in S301-1 to S301-2, UE20 takes the identifier of 3GPP NW as input and obtains the corresponding public key from VDR70.

[0325] S301-1 to S301-2 can be performed, for example, by means of communication other than the 3GPP NW of the connection object. Alternatively, S301-1 to S301-2 can be implemented by extending the UE and the 3GPP NW so that this communication can be performed via the 3GPP NW even before the connection to the 3GPP NW of the connection object.

[0326] Alternatively, the NW public key can be pre-installed on the UE20 along with the NW connection function / application, thus omitting S301-1~S301-2.

[0327] In S302, UE20 includes the attribute / qualification certificate in a Registration Request message and sends a Registration Request message containing the attribute / qualification certificate to (R)AN10. The information (attribute / qualification certificate, etc.) included in the Registration Request message is signed by UE20 using a private key corresponding to the user's identifier (e.g., VP). Furthermore, this information is encrypted by UE20 using the public key of the 3GPP NW.

[0328] In S303, (R)AN10 forwards the registration request message containing the attribute / certificate encrypted using the public key of 3GPP NW to AMF / SEAF (30).

[0329] In S304, AMF / SEAF (30) includes an attribute / certificate encrypted with the public key of 3GPP NW in the Nausf_UEAuthentication_Authenticate Request message, and sends the Nausf_UEAuthentication_Authenticate Request message containing the attribute / certificate as an authentication request to AUSF80.

[0330] In S305, AUSF80 includes the attribute / certificate encrypted with the public key of 3GPP NW in the Nudm_UEAuthentication_Get Request message, and sends the Nudm_UEAuthentication_Get Request message containing the attribute / certificate as an authentication request to UDM / ARPF / SIDF (40).

[0331] In S306, UDM / ARPF / SIDF (40) uses its own (3GPP NW) private key to decrypt the information (attributes / certificates, etc.) contained in the received message. It is assumed that the 3GPP NW's private key is kept by UDM / UDR (40). Furthermore, the 3GPP NW's private key can be processed only within the UDM, shared with other nodes such as AUSF80 as needed, or stored in the memory of each node.

[0332] In S307, UDM / ARPF / SIDF (40) performs authentication method selection.

[0333] Specifically, if the received message contains an attribute / qualification certificate but not SUPI or SUCI, attribute / qualification certificate authentication is selected as the authentication method. When both SUPI or SUCI and attribute / qualification certificates are included, the authentication method is selected based on a pre-registered authentication method selection strategy or a user request.

[0334] In S308, UDM / ARPF / SIDF (40) includes a string indicating the selected attribute / certificate authentication method (e.g., Credential Auth) in the Nudm_UEAuthentication_Get response message, and sends the Nudm_UEAuthentication_Get response message containing this string to AUSF80. This message contains the attribute / certificate decrypted by UDM40. Furthermore, this message may contain the encrypted attribute / certificate and the private key of the NW stored in UDM40. In this case, the attribute / certificate is decrypted in AUSF80.

[0335] In S309, AUSF80 performs attribute / certificate-based authentication processing. The details of the authentication processing are the same as those described above.

[0336] In S310, AUSF80 generates the root key K of the shared key, which is common to both UE20 and NW.

[0337] In S311, AUSF80 includes a string indicating successful attribute / credential authentication (e.g., Credential Auth Success) and the root key K in the Nausf_UEAuthentication_Authenticate response message and sends the Nausf_UEAuthentication_Authenticate response message containing the string and the root key K to AMF / SEAF (30).

[0338] Subsequently, in S312, step 10 and subsequent processing of the 3GPP TS 23.502 4.2.2.2 Registration Procedure are executed to complete the NW registration process. In this NW registration process, the SUPI / SUCI-based API or SUPI / SUCI-based subscriber information registration process is extended to be able to be performed using the user's identifier (DID, etc.) contained in the attributes / qualification certificate.

[0339] As part of the process in S312, the following process is performed.

[0340] In S312-1, the AMF / SEAF (30) includes the root key K in the Registration Accept message and sends a Registration Accept message containing the root key K. The information contained in the Registration Accept message is signed by the AMF / SEAF (30) using the NW's private key and encrypted using the user's public key. Furthermore, the message in which the root key K is included to notify the UE20 is not limited to the Registration Accept message; any message can be used.

[0341] In S312-2, (R)AN10 forwards the registration acceptance message to UE20. The information contained in the registration acceptance message is signed with the NW's private key and encrypted with the user's public key.

[0342] In S313-3, UE20 uses the user's private key to decrypt the information contained in the received RegistrationAccept message and uses NW's public key for signature verification. Here, the root key K is extracted.

[0343] In S312-4, based on K, various keys for encryption are derived on the NW side and UE20 respectively in accordance with the existing 3GPP NAS Security Procedure, and subsequent communications are implemented using these keys for encryption.

[0344] In S312-4, UE20 uses the key derived from K to encrypt the information contained in the Registration Complete message, sends the encrypted Registration Complete message, and continues communication with NW.

[0345] AUSF80 can also replace the generation of the root key K, which is instead generated by AMF / SEAF (30). In this case, AMF / SEAF (30) can include the root key K with a signature generated by the private key of NW in the message S312-1 and send it. The "root key K with a signature generated by the private key of NW" is sent to UE20 for signature verification.

[0346] Additionally, similar to the example above, attributes / certificates are also added to the Mobility Registration Update / Periodic Redistration Update message.

[0347] (Effects of the third implementation method)

[0348] According to the technology of the third embodiment, terminal 20 can connect to NW based on attribute / certificate-based authentication.

[0349] Furthermore, in the third embodiment, security is enhanced because the user identifier and attribute / qualification certificate are encrypted before transmission. Impersonation and other improper actions on the NW side can be detected in messages sent from the NW side to the UE20, resulting in improved security.

[0350] (Other common examples in the first to third embodiments)

[0351] Hereinafter, other examples common to the first to third embodiments will be described. Furthermore, matters related to specific embodiments are also described.

[0352] NW connectivity feature 21 may also include, for example, a digital identity wallet responsible for managing user identifiers, attributes / certificates, and public / private keys associated with the identifiers.

[0353] In addition to the usual storage area within the UE20, the storage location for user identifiers, attributes / certificates, and public / private keys associated with the identifiers in NW connection function 21 can also be within the HSM (Hardware Security Module) within the UE20, or a storage device outside the UE20 that can be accessed from the UE20.

[0354] In addition to third parties, the issuer of attribute / certificate can also be the 3GPP NW operator itself.

[0355] In UE20, when both SIM and attribute / qualification certificates can be used, or when multiple attribute / qualification certificates can be used in NW connection, the user can select which information to include in the message and prompt to the NW side based on user operation / settings. In the second embodiment, the request message for attribute / qualification certificates from the NW side to UE20 may also include conditions in the form of multiple attribute / qualification certificates, and the user can select which information to include in the message and prompt to the NW side based on user operation / settings.

[0356] In existing 3GPP NWs, SUPI or SUCI are used to identify UEs and provide unified services to them. SUPI or SUCI are often required in messages exchanged between NFs or in the input of APIs for services provided by NFs. In contrast, in this implementation, even if UE20 cannot provide SUPI or SUCI to the 3GPP NW, UE20 identification / management can still be performed based on user identifiers (DID, etc.) and identifiers that uniquely determine attributes / certificates (VC's own ID, etc.).

[0357] In addition, in the databases of AMF30, UDM / UDR (40) and other nodes, the mechanism of managing information with SUPI or SUCI as the key can be matched with the management with user identifier (DID, etc.) or identifier that can uniquely identify attributes / certificates as the key.

[0358] (Device structure)

[0359] Next, the functional structure example of "Authentication Function 60, AMF30, UDM40, VDR70, AUSF80, etc." and Terminal 20 (UE20) that implement the processing and actions described so far will be explained. Hereinafter, the network nodes such as Authentication Function 60, AMF30, UDM40, VDR70, and AUSF80 will be collectively referred to as "Network Node 100".

[0360] <Network Node 100>

[0361] Figure 19 This is a diagram illustrating an example of the functional structure of network node 100.

[0362] like Figure 19 As shown, the network node 100 has a transmitting unit 110, a receiving unit 120, a setting unit 130, and a control unit 140. Figure 19 The functional structure shown is merely one example. The functional distinctions and names of the functional units can be arbitrary, as long as the actions of the embodiments of the present invention can be implemented.

[0363] The transmitting unit 110 includes the function of generating a signal to be transmitted to the terminal 20 or other network nodes and transmitting the signal via wired or wireless means. The receiving unit 120 includes the function of receiving various signals transmitted from the terminal 20 or other network nodes and obtaining, for example, higher-level information from the received signals. A communication unit including the transmitting unit 110 and the receiving unit 120 may also be configured.

[0364] The setting unit 130 stores preset setting information and various setting information sent to the terminal 20 into a storage device, and reads it from the storage device as needed. The control unit 140 controls the network node 100. Alternatively, the signal transmission-related functions of the control unit 140 can be included in the transmitting unit 110, and the signal reception-related functions of the control unit 140 can be included in the receiving unit 120. Alternatively, the transmitting unit 110 and the receiving unit 120 can be referred to as a transmitter and a receiver, respectively.

[0365] Terminal 20

[0366] Figure 20 This is a diagram illustrating an example of the functional structure of terminal 20. (As shown...) Figure 20 As shown, the terminal 20 includes a transmitting unit 210, a receiving unit 220, a setting unit 230, and a control unit 240. Figure 16 The functional structure shown is merely one example. The functional distinctions and names of the functional units can be arbitrary, as long as the actions of the embodiments of the present invention can be implemented.

[0367] The transmitting unit 210 generates a transmission signal based on the transmission data and transmits the signal wirelessly. The receiving unit 220 wirelessly receives various signals and extracts higher-layer signals from the received physical layer signals. Furthermore, the receiving unit 220 has the function of receiving NR-PSS, NR-SSS, NR-PBCH, DL / UL control signals, or reference signals transmitted from the network node 30. A communication unit including the transmitting unit 210 and the receiving unit 220 may also be configured.

[0368] The setting unit 230 stores various setting information received from the network node by the receiving unit 220 in a storage device, and reads it from the storage device as needed. In addition, the setting unit 230 also stores preset setting information.

[0369] The control unit 240 controls the terminal 20. Alternatively, the signal transmission-related functions of the control unit 240 can be included in the transmitting unit 210, and the signal reception-related functions of the control unit 240 can be included in the receiving unit 220. Furthermore, the transmitting unit 210 and the receiving unit 220 can be referred to as a transmitter and a receiver, respectively.

[0370] (Hardware structure)

[0371] The block diagrams used in the description of the above embodiments ( Figure 19 as well as Figure 20The diagram illustrates blocks organized by function. These functional blocks (components) are implemented through any combination of at least one of hardware and software. Furthermore, there are no particular limitations on the implementation method of each functional block. That is, each functional block can be implemented using a single device that is physically or logically combined, or by directly or indirectly (e.g., using wired, wireless, etc.) connecting two or more physically or logically separate devices. Functional blocks can also be implemented by combining software within the aforementioned single or multiple devices.

[0372] The functions include judgment, decision, determination, calculation, calculation, processing, derivation, investigation, search, confirmation, receiving, sending, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, consideration, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, and assigning, but are not limited to these. For example, the functional block (structural part) that performs the sending function is called the transmitting unit or transmitter. In short, as mentioned above, there are no particular limitations on the implementation method.

[0373] For example, in one embodiment of this disclosure, the network node 100 and terminal 20 can also function as a computer for processing the communication method of this disclosure. Figure 21 This is a diagram illustrating an example of the hardware structure of a network node 100 and a terminal 20 according to an embodiment of the present disclosure. The EES 30 and the terminal 20 described above can also be configured as a computer device that physically includes a processor 1001, a storage device 1002, an auxiliary storage device 1003, a communication device 1004, an input device 1005, an output device 1006, and a bus 1007, etc.

[0374] Furthermore, in the following description, the term "device" can be replaced with "circuit," "device," "unit," etc. The hardware structure of network node 100 and terminal 20 can be configured to include one or more of the devices shown in the figures, or it can be configured not to include any of the devices.

[0375] The functions of network node 100 and terminal 20 are implemented by reading predetermined software (programs) into hardware such as processor 1001 and storage device 1002, so that processor 1001 performs calculations and controls the communication of communication device 1004 or controls at least one of reading and writing data in storage device 1002 and auxiliary storage device 1003.

[0376] The processor 1001 controls the computer as a whole by instructing the operating system to operate. The processor 1001 may also be a central processing unit (CPU) that includes interfaces with peripheral devices, control units, arithmetic units, registers, etc. For example, the control unit 140 and control unit 240 described above can also be implemented using the processor 1001.

[0377] Furthermore, the processor 1001 reads programs (program code), software modules, or data from at least one of the auxiliary storage devices 1003 and communication devices 1004, and performs various processes accordingly. As a program, a program is used that causes the computer to perform at least a portion of the actions described in the above embodiments. For example, Figure 19 The control unit 140 of the network node 100 shown can also be implemented by a control program stored in the storage device 1002 and operated in the processor 1001. Alternatively, for example, Figure 20 The control unit 240 of the terminal 20 shown can also be implemented by a control program stored in the storage device 1002 and operated in the processor 1001. Although it has been described that the various processes described above are executed by one processor 1001, the various processes described above can also be executed simultaneously or sequentially by two or more processors 1001. The processor 1001 can also be implemented by more than one chip. In addition, the program can also be sent from the network via a telecommunications line.

[0378] Storage device 1002 is a computer-readable recording medium, and may be composed of at least one of the following: ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory). Storage device 1002 may also be referred to as a register, cache, main memory (main storage device), etc. Storage device 1002 can store programs (program code), software modules, etc., that are executable for implementing the communication method according to one embodiment of this disclosure.

[0379] The auxiliary storage device 1003 is a computer-readable recording medium, such as at least one of the following: CD-ROM (CompactDisc ROM) or other optical discs, hard disks, floppy disks, magneto-optical discs (e.g., compact discs, digital multifunction discs, Blu-ray discs), smart cards, flash memory (e.g., cards, sticks, key drives), floppy disks, magnetic stripes, etc. The aforementioned storage medium may, for example, be a database, server, or other suitable media that includes at least one of the storage device 1002 and the auxiliary storage device 1003.

[0380] The communication device 1004 is hardware (transceiver) used for communication between computers via at least one of a wired network and a wireless network. It may also be referred to as a network device, network controller, network interface card (NIC), communication module, etc. The communication device 1004 may, for example, be configured to include a high-frequency switch, duplexer, filter, frequency synthesizer, etc., to implement at least one of frequency division duplex (FDD) and time division duplex (TDD). For example, transceiver antennas, amplifiers, transceiver units, transmission path interfaces, etc., can also be implemented using the communication device 1004. The transceiver unit may also be physically or logically separated into a transmitting unit and a receiving unit.

[0381] Input device 1005 is an input device that accepts input from external sources (e.g., keyboard, mouse, microphone, switch, button, sensor, etc.). Output device 1006 is an output device that performs output to external sources (e.g., display, speaker, LED, etc.). Alternatively, input device 1005 and output device 1006 can also be integrated (e.g., a touch panel).

[0382] Furthermore, the processor 1001 and storage device 1002, among other devices, are connected via a bus 1007 for communicating information. The bus 1007 can be configured using a single bus or different buses can be used between each device.

[0383] Furthermore, network node 100 and terminal 20 can be configured to include hardware such as microprocessors, digital signal processors (DSPs), ASICs (Application Specific Integrated Circuits), PLDs (Programmable Logic Devices), and FPGAs (Field Programmable Gate Arrays), and can also use this hardware to implement some or all of the functional blocks. For example, processor 1001 can also be implemented using at least one of these hardware components.

[0384] Figure 22 An example of the structure of vehicle 2001 is shown. For example... Figure 22 As shown, the vehicle 2001 includes a drive unit 2002, a steering unit 2003, an accelerator pedal 2004, a brake pedal 2005, a gearshift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, an electronic control unit 2010, various sensors 2021-2029, an information service unit 2012, and a communication module 2013. The various forms / implementations described in this disclosure can also be applied to communication devices mounted on the vehicle 2001, for example, to the communication module 2013. For example, a network node 100 or a terminal 20 may also be included in the communication module 2013.

[0385] The drive unit 2002 may be composed, for example, an engine, a motor, or a hybrid power system of an engine and a motor. The steering unit 2003 includes at least a steering wheel (also called a steering wheel) and is configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel operated by the user.

[0386] The electronic control unit 2010 consists of a microprocessor 2031, a memory (ROM, RAM) 2032, and a communication port (I / O port) 2033. Signals from various sensors 2021 to 2029 of the vehicle 2001 are input to the electronic control unit 2010. The electronic control unit 2010 can also be referred to as an ECU (Electronic Control Unit).

[0387] The signals from various sensors 2021 to 2029 include current signals from current sensor 2021 that monitors the current of the motor, speed signals of the front and rear wheels obtained by speed sensor 2022, air pressure signals of the front and rear wheels obtained by air pressure sensor 2023, vehicle speed signals obtained by vehicle speed sensor 2024, acceleration signals obtained by acceleration sensor 2025, accelerator pedal depress signal obtained by accelerator pedal sensor 2029, brake pedal depress signal obtained by brake pedal sensor 2026, gear lever operation signal obtained by gear lever sensor 2027, and detection signals obtained by object detection sensor 2028 for detecting obstacles, vehicles, pedestrians, etc.

[0388] The Information Service Unit 2012 comprises various devices such as a car navigation system, audio system, speakers, television, and radio, used to provide (output) various information such as driving information, traffic information, and entertainment information, and one or more ECUs that control these devices. The Information Service Unit 2012 uses information obtained from external devices via a communication module 2013, etc., to provide various multimedia information and multimedia services to the occupants of the vehicle 2001. The Information Service Unit 2012 may include input devices that accept input from external sources (such as keyboards, mice, microphones, switches, buttons, sensors, touch panels, etc.), and may also include output devices that perform output to external sources (such as displays, speakers, LED lights, touch panels, etc.).

[0389] The Driver Assistance System 2030 comprises various devices used to prevent accidents or reduce driver workload, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, positioning devices (e.g., GNSS), map information (e.g., high-definition (HD) maps, autonomous vehicle (AV) maps), gyroscope systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System)), AI (Artificial Intelligence) chips, and AI processors, as well as one or more ECUs that control these devices. Furthermore, the Driver Assistance System 2030 transmits and receives various information via the communication module 2013 to achieve driver assistance or autonomous driving functions.

[0390] The communication module 2013 can communicate with the microprocessor 2031 and the components of the vehicle 2001 via the communication port. For example, the communication module 2013 can send and receive data with the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, gear shift lever 2006, front wheel 2007, rear wheel 2008, axle 2009, microprocessor 2031 in the electronic control unit 2010, memory (ROM, RAM) 2032, and sensors 2021 to 29 in the vehicle 2001 via the communication port 2033.

[0391] The communication module 2013, controlled by the microprocessor 2031 of the electronic control unit 2010, is a communication device capable of communicating with external devices. For example, it can transmit and receive various types of information with external devices via wireless communication. The communication module 2013 can be located inside or outside the electronic control unit 2010. External devices may include, for example, base stations, terminals, network nodes, etc.

[0392] The communication module 2013 can also wirelessly transmit at least one of the signals input to the electronic control unit 2010 from the various sensors 2021-2028 described above, the information obtained based on those signals, and the information obtained via the information service unit 2012 based on input from an external source (user) to an external device. The electronic control unit 2010, the various sensors 2021-2028, the information service unit 2012, etc., can also be referred to as input units that receive input.

[0393] The communication module 2013 receives various information (traffic information, signal information, vehicle-to-vehicle information, etc.) sent from external devices and displays it on the information service unit 2012 of the vehicle 2001. The information service unit 2012 can also be referred to as an output unit for outputting information (for example, outputting information to devices such as displays and speakers based on the PDSCH received by the communication module 2013 (or data / information decoded from the PDSCH). In addition, the communication module 2013 stores the various information received from external devices in a memory 2032 available to the microprocessor 2031. The microprocessor 2031 can also control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, gear lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021 to 2029, etc., of the vehicle 2001 based on the information stored in the memory 2032.

[0394] In addition, if the communication module 2013 includes a network node 100 (or terminal 20), the communication module 2013 can perform the aforementioned actions of the network node 100 (or terminal 20).

[0395] The structures described in at least the following notes 1 to 3 are disclosed in this specification.

[0396] <Postscript 1>

[0397] (Note 1)

[0398] A terminal that has: The sending unit sends a connection request message to the network containing a certificate storing personal data; and After performing authentication processing using the certificate in the network, the control unit executes the registration process with the network following the authentication processing.

[0399] (Note 2)

[0400] According to the terminal described in Appendix 1, the connection request message is a registration request message requesting registration with the network.

[0401] (Note 3)

[0402] A network node that possesses: The receiving unit receives an authentication request message containing a certificate storing personal data from a specific network node, wherein the specific network node receives a connection request message containing the certificate from a terminal; The control unit performs authentication processing using the certificate; and The sending unit sends the authentication result to the specific network node.

[0403] (Note 4)

[0404] According to the network node described in Appendix 3, the sending unit requests the registration of the personal data contained in the certificate from the management node that manages the user data.

[0405] (Note 5)

[0406] The network node described in Note 3 is an AUSF.

[0407] (Note 6)

[0408] A communication method in which network nodes perform the following steps: Receive an authentication request message containing a certificate storing personal data from a specific network node, wherein the specific network node receives a connection request message containing the certificate from the terminal; Perform authentication processing using the certificate; and Send the authentication result to the specific network node.

[0409] According to any one of Appendix 1 to Appendix 6, a technology is provided that enables a terminal to connect to the NW based on attribute / certificate-based authentication. According to Appendix 2 and 5, by extending the messages or nodes defined in existing 3GPP standards, a technology enabling a terminal to connect to the NW based on attribute / certificate-based authentication can be implemented. According to Appendix 4, in attribute / certificate-based authentication, information such as billing information can be registered in the management node.

[0410] <Appendix 2>

[0411] (Note 1)

[0412] A terminal that has: The sending unit sends connection request messages to the network; The receiving unit receives from the network a message requesting a certificate containing personal data; and After the certificate is sent by the sending unit and authentication processing using the certificate is performed in the network, the control unit executes the registration process with the network after authentication processing.

[0413] (Note 2)

[0414] According to the terminal described in Appendix 1, the connection request message is a registration request message requesting registration with the network.

[0415] (Note 3)

[0416] A network node that possesses: The receiving unit receives authentication request messages from a specific network node, wherein the specific network node receives connection request messages from the terminal; The sending unit sends a message to the terminal requesting a certificate containing personal data; and The control unit performs authentication processing using the certificate sent from the terminal based on the message.

[0417] (Note 4)

[0418] According to the network node described in Note 3, the message includes conditions for requesting a certificate from the terminal.

[0419] (Note 5)

[0420] The network node described in Note 3 is an AUSF.

[0421] (Note 6)

[0422] A communication method in which network nodes perform the following steps: Receive authentication request messages from a specific network node, wherein the specific network node receives connection request messages from the terminal; Send a message to the terminal requesting a certificate containing personal data; and The authentication process is performed using the certificate sent from the terminal based on the message.

[0423] According to any one of Appendix 1 to Appendix 6, a technology is provided that enables a terminal to connect to the NW based on attribute / qualification certificate-based authentication. According to Appendix 2 and 5, by extending the messages or nodes defined in existing 3GPP standards, a technology enabling a terminal to connect to the NW based on attribute / qualification certificate-based authentication can be implemented. According to Appendix 4, an attribute / qualification certificate that meets the conditions desired by the NW can be requested from the terminal.

[0424] <Appendix 3>

[0425] (Note 1)

[0426] A terminal that has: The sending unit sends a connection request message containing a certificate storing personal data to the network; and After performing authentication processing using the certificate in the network, the control unit executes the registration process with the network following the authentication processing. The sending unit uses the network's public key to encrypt the certificate or the connection request message and then sends it.

[0427] (Note 2)

[0428] According to the terminal described in Appendix 1, wherein, The terminal also includes a receiving unit that, after the authentication process using the certificate has been performed in the network, receives from the network a message containing information signed using the network's private key. The control unit uses the public key to verify the signature.

[0429] (Note 3)

[0430] According to the terminal described in Appendix 2, wherein, The receiving unit receives a message encrypted using the public key of the terminal from the network.

[0431] (Note 4)

[0432] According to the terminal described in Appendix 1, wherein, The terminal also includes a receiving unit for receiving the root key from the network. The control unit uses the root key to generate a common key between the network and the terminal.

[0433] (Note 5)

[0434] A network node that possesses: The receiving unit receives an authentication request message containing a certificate from a specific network node, which in turn receives a connection request message containing the certificate storing personal data from a terminal. The control unit performs authentication processing using the decrypted certificate; and The sending unit sends the authentication result to the specific network node. The connection request message received by the specific network node, or the certificate contained in the connection request message, is encrypted using the network's public key.

[0435] (Note 6)

[0436] According to the network node described in Appendix 5, the transmitting unit sends a root key to the terminal for generating a public key between the network and the terminal.

[0437] According to any one of notes 1 through 6, a technology is provided that enables a terminal to connect to the NW based on attribute / certificate-based authentication. According to note 2, impersonation on the network side can be detected. According to note 3, security can be improved. According to notes 4 and 6, encrypted communication using a shared key can be implemented.

[0438] (Supplement to the implementation method)

[0439] The embodiments of the present invention have been described above, but the disclosed invention is not limited to such embodiments. Those skilled in the art should understand various modifications, alterations, substitutions, and replacements. Specific numerical examples have been used to facilitate understanding of the invention, but unless otherwise specified, these values ​​are merely examples, and any appropriate values ​​may be used. The distinctions between items in the above description are not essential to the present invention. Items described in two or more items may be combined as needed, and items described in one item may be applied to items described in another item (as long as there is no contradiction). The boundaries of functional units or processing units in the functional block diagram do not necessarily correspond to the boundaries of physical components. Multiple functional units may be operated by a single physical component, or a single functional unit may be operated by multiple physical components. Regarding the processing described in the embodiments, the order of processing may be interchanged unless there is a contradiction. For ease of explanation, a functional block diagram is used to illustrate network node 100 and terminal 20, but such a device may also be implemented by hardware, software, or a combination thereof. According to embodiments of the present invention, software operating via the processor of the EES30 and software operating via the processor of the terminal 20 can be stored in random access memory (RAM), flash memory, read-only memory (ROM), EPROM, EEPROM, registers, hard disk (HDD), removable disk, CD-ROM, database, server, and any other suitable storage medium.

[0440] Furthermore, the notification of information is not limited to the forms / implementations described in this disclosure, and other methods may also be used. For example, information notification may be implemented through physical layer signaling (e.g., DCI (Downlink Control Information), UCI (Uplink Control Information)), higher layer signaling (e.g., RRC (Radio Resource Control) signaling, MAC (Medium Access Control) signaling), broadcast information (MIB (Master Information Block), SIB (System Information Block)), other signals, or combinations thereof. In addition, RRC signaling may also be referred to as an RRC message, for example, an RRC connection setup message, an RRC connection reconfiguration message, etc.

[0441] The various forms / implementations described in this disclosure can also be applied to systems utilizing LTE (Long Term Evolution), LTE-A (LTE-Advanced), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system), 6th generation mobile communication system (6G), xth generation mobile communication system (xG) (xG (x is, for example, an integer or a decimal)), FRA (Future Radio Access), NR (new Radio), New radio access (NX), Future generation radio access (FX), W-CDMA (registered trademark), GSM (registered trademark), CDMA2000, UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), IEEE The system may include at least one of 802.20, UWB (Ultra-Wideband), Bluetooth (registered trademark), other suitable systems, and next-generation systems based on, modified, created, or defined by these systems. Furthermore, multiple systems may be combined (e.g., a combination of at least one of LTE and LTE-A with 5G, etc.).

[0442] The processing procedures, timing, and flow of the various forms / implementations described in this specification may be rearranged in order, provided there is no contradiction. For example, the elements of various steps are indicated using an illustrative order for the methods described in this disclosure, but are not limited to the specific order indicated.

[0443] In this specification, specific actions performed by base station 10 ((R)AN10) may sometimes also be performed by its upper node, depending on the circumstances. In a network consisting of one or more network nodes having base station 10, it is obvious that various actions performed to communicate with terminal 20 can be performed by at least one of base station 10 and other network nodes besides base station 10 (e.g., considering MME or S-GW, but not limited to these). The above example illustrates the case where there is only one other network node besides base station 10, but other network nodes can also be a combination of multiple other network nodes (e.g., MME and S-GW).

[0444] The information or signals described in this disclosure can be output from a higher (or lower) layer to a lower (or higher) layer. They can also be input or output via multiple network nodes.

[0445] Input or output information can be stored in a specific location (e.g., memory) or managed using a management table. Input or output information can be overwritten, updated, or appended. Output information can also be deleted. Input information can also be sent to other devices.

[0446] The determination in this disclosure can be made by a value represented by 1 bit (0 or 1), by a Boolean value (Boolean: true or false), or by a comparison of numerical values ​​(e.g., a comparison with a predetermined value).

[0447] Software, whether called software, firmware, middleware, microcode, hardware description language, or by other names, should be broadly interpreted as referring to commands, command sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc.

[0448] In addition, software, commands, information, etc., can be sent and received via a transmission medium. For example, when software is sent from a webpage, server, or other remote source using at least one of wired technologies (coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) etc.) and wireless technologies (infrared, microwave, etc.), at least one of these wired and wireless technologies is included within the definition of a transmission medium.

[0449] The information, signals, etc., described in this disclosure can also be represented using any of a variety of different technologies. For example, the data, commands, instructions, information, signals, bits, symbols, chips, etc., that may be involved in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or photons, or any combination of these.

[0450] Furthermore, the terms used in this disclosure and those necessary for understanding this disclosure may be replaced with terms that have the same or similar meanings. For example, at least one of the channel and symbol may also be a signal (signaling). Additionally, a signal may also be a message. Furthermore, a component carrier (CC) may also be referred to as carrier frequency, cell, frequency carrier, etc.

[0451] The terms “system” and “network” as used in this disclosure are used interchangeably.

[0452] Furthermore, the information, parameters, etc., described in this disclosure can be represented using absolute values, relative values ​​to predetermined values, or other corresponding information. For example, wireless resources can be indicated using indexes.

[0453] The names used for the above parameters are non-limiting in any respect. Furthermore, the formulas, etc., using these parameters sometimes differ from those explicitly disclosed in this disclosure. Various channels (e.g., PUCCH, PDCCH, etc.) and information elements can be identified by all appropriate names, therefore the various names assigned to these channels and information elements are non-limiting in any respect.

[0454] In this disclosure, the terms "base station (BS)," "wireless base station," "base station device," "fixed station," "NodeB," "eNodeB (eNB)," "gNodeB (gNB)," "access point," "transmission point," "reception point," "transmission / reception point," "cell," "sector," "cell group," "carrier," and "component carrier" are used interchangeably. Sometimes, terms such as macro cell, small cell, femtocell, and picocell are also used to refer to base stations.

[0455] A base station can accommodate one or more (e.g., three) cells. When a base station accommodates multiple cells, its coverage area can be divided into several smaller areas, each of which can provide communication services through a base station subsystem (e.g., a small indoor base station RRH: Remote Radio Head). Terms such as "cell" or "sector" refer to a portion or all of the coverage area of ​​at least one of the base station and base station subsystem providing communication services within that coverage area.

[0456] In this disclosure, the base station sending information to the terminal can also be replaced by the base station instructing the terminal on information-based control / actions.

[0457] In this disclosure, the terms "Mobile Station (MS)," "User Terminal (user terminal)," "User Equipment (UE)," and "Terminal" can be used interchangeably.

[0458] For mobile stations, those skilled in the art sometimes also use the following terms: subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handheld device, user agent, mobile client, client, or some other appropriate terms.

[0459] At least one of the base station and the mobile station (terminal 20) can also be referred to as a transmitting device, a receiving device, a communication device, etc. Furthermore, at least one of the base station and the mobile station can also be a device mounted on a mobile body, the mobile body itself, etc. The mobile body refers to an object capable of movement, with an arbitrary speed. It also includes situations where the mobile body is stationary. Examples of mobile bodies include, but are not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, rear cars, rickshaws, ships and other watercraft, airplanes, rockets, artificial satellites, Drone (registered trademark), multi-rotor helicopters, quadcopter helicopters, balloons, and objects mounted on them. Additionally, the mobile body can also be a mobile body that moves autonomously based on operating commands. It can be a means of transportation (e.g., car, airplane, etc.), a mobile body that moves unmanned (e.g., drone, autonomous vehicle, etc.), or a robot (humanized or unmanned). Furthermore, at least one of the base station and the mobile station may also include devices that are not necessarily mobile during communication operations. For example, at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.

[0460] Furthermore, the base station in this disclosure can also be replaced by a user terminal. For example, the communication between the base station and the user terminal can be replaced by communication between multiple terminals 20 (e.g., D2D (Device-to-Device), V2X (Vehicle-to-Everything), etc.), and various forms / implementations of this disclosure can also be applied. In this case, the terminal 20 can also be configured to have the functions of the base station 10 described above. In addition, terms such as "uplink" and "downlink" can be replaced with terms corresponding to communication between terminals (e.g., "side"). For example, uplink channel, downlink channel, etc. can also be replaced with side channel.

[0461] Similarly, the user terminal in this disclosure can also be replaced by a base station. In this case, the base station can also be configured to have the functions of the aforementioned user terminal.

[0462] The terms "determining" and "determining" as used in this disclosure sometimes encompass a variety of actions. For example, "determining" or "determining" may include actions such as judging, calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, database, or other data structure), and ascertaining, which are considered as actions of "determining" or "determining." Furthermore, "determining" or "determining" may include actions such as receiving (e.g., receiving information), transmitting (e.g., sending information), inputting, outputting, and accessing (e.g., accessing data in memory), which are considered as actions of "determining" or "determining." Moreover, "determining" or "determining" may include actions such as resolving, selecting, choosing, establishing, and comparing, which are considered as actions of "determining" or "determining." That is, "judgment" and "decision" can include matters that are considered as having been "judged" or "decided". In addition, "judgment (decision)" can also be replaced by "assuming", "expecting", "considering", etc.

[0463] The terms “connected,” “coupled,” or any variations thereof are intended to indicate any direct or indirect connection or combination between two or more elements, including cases where there is one or more intermediate elements between the two elements that are “connected” or “coupled.” The combination or connection between elements can be physical, logical, or a combination of these. For example, “access” can be used instead of “connected.” In the context of this disclosure, it can be understood that two elements are “connected” or “coupled” to each other using at least one of one or more wires, cables, and printed electrical connections, and, as some non-limiting and non-inclusive examples, using electromagnetic energy with wavelengths in the wireless frequency domain, microwave region, and light (including both visible and invisible regions) to “connect” or “couple” to each other.

[0464] The reference signal can be simply called RS (Reference Signal), or, depending on the standard applied, pilot.

[0465] As used in this disclosure, the word "based on" does not mean "based on only" unless otherwise expressly stated. In other words, the word "based on" means both "based on only" and "based on at least".

[0466] Any reference to elements using the designations "first," "second," etc., as used in this disclosure does not necessarily limit the number or order of these elements. These designations may be used in this disclosure as a convenient method of distinguishing between two or more elements. Therefore, reference to a first element and a second element does not imply that only two elements can be used, or that in any form the first element must precede the second element.

[0467] Alternatively, the "unit" in the structure of the above devices can be replaced with "section", "circuit", "equipment", etc.

[0468] When the terms "include," "including," and their variations are used in this disclosure, these terms, like the term "comprising," imply inclusion. Furthermore, the term "or" as used in this disclosure does not refer to XOR.

[0469] In this disclosure, for example, in cases where articles are added through translation, such as in English (a, an, and the), this disclosure also includes cases where the noun following these articles is in a plural form.

[0470] In this disclosure, the phrase "A and B are different" can mean "A and B are not the same." Furthermore, this phrase can also mean "A and B are each different from C." Terms such as "separate" and "combined" can also be interpreted in the same way as "different."

[0471] The various forms / implementations described in this disclosure can be used individually or in combination, and can be switched depending on the execution. Furthermore, the notification of predetermined information (e.g., a "It is X" notification) is not limited to being explicit, but can also be implicit (e.g., not being notified of the predetermined information).

[0472] The present disclosure has been described in detail above, but it will be clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented as modifications and variations without departing from the spirit and scope of the present disclosure as defined by the claims. Therefore, the present disclosure is for illustrative purposes only and is not intended to be limiting.

[0473] Label Explanation

[0474] 10 Base Stations (R)AN

[0475] 20. Terminal (UE)

[0476] 21 NW connectivity function

[0477] 30 AMF

[0478] 40 UDM

[0479] 41 NW Information DB

[0480] 42 Certificate Information DB

[0481] 43 Strategy DB

[0482] 60 Authentication Function

[0483] 70 VDR

[0484] 71 User Information DB

[0485] 72 Issuer Information DB

[0486] 73 Definition Information DB

[0487] 74 Management Information DB

[0488] 80 AUSF

[0489] 100 network nodes

[0490] 110 Dispatch Department

[0491] 120 Receiving Department

[0492] 130 Setting Department

[0493] 140 Control Department

[0494] 210 Sending Department

[0495] 220 Receiving Department

[0496] 230 Setting Department

[0497] 240 Control Department

[0498] 1001 processor

[0499] 1002 Storage device

[0500] 1003 Auxiliary storage device

[0501] 1004 Communication device

[0502] 1005 Input Device

[0503] 1006 Output Device

Claims

1. A terminal, comprising: The sending unit sends connection request messages to the network; The receiving unit receives from the network a message requesting a certificate containing personal data; and After the sending unit sends the certificate and performs authentication processing using the certificate in the network, the control unit executes the registration process with the network following the authentication processing.

2. The terminal according to claim 1, wherein, The connection request message is a registration request message that requests registration with the network.

3. A network node, which possesses: The receiving unit receives authentication request messages from specific network nodes, wherein... The specific network node receives a connection request message from the terminal; The sending unit sends a message to the terminal requesting a certificate containing personal data; as well as The control unit performs authentication processing using the certificate sent from the terminal based on the message.

4. The network node according to claim 3, wherein, The message contains the conditions for requesting a certificate from the terminal.

5. The network node according to claim 3, wherein, The network node is AUSF.

6. A communication method in which a network node performs the following steps: Receive authentication request messages from specific network nodes, where, The specific network node receives a connection request message from the terminal; Send a message to the terminal requesting a certificate containing personal data; as well as The authentication process is performed using the certificate sent from the terminal based on the message.

Images