Network node, terminal, and communication method

Abstract

The network node has a reception section that receives a trust evaluation request message from a specific network node in a case where authentication using a user's attribute / eligibility certificate is successful, the trust evaluation request message including a terminal or the user's trust certificate, a control section that performs a trust evaluation process using the trust certificate, and a transmission section that transmits a trust evaluation result to the specific network node.

Description

Technical Field

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

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

[0003] The existing 3GPP NW NW connection authentication (NW Registration) is implemented by using a pre-shared key between the SIM card installed on the user's UE and the NW (network) based on the contract between the user and the NW (network).

[0004] 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 does not rely on centralized identity providers (ID providers) and allows users to manage their own identifiers or identities and control the destination of the provided information. These technologies include W3C Decentralized Identifiers (DID) and W3C Verifiable Credentials (VC).

[0005] 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.

[0006] Existing technical documents

[0007] Non-patent literature

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

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

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

[0011] The problem that the invention aims to solve

[0012] In 6G and similar technologies, it is envisioned that authentication-based NW connections will be required even when using UEs without SIM cards, or when there is no prior agreement or shared key sharing between the user / UE and the NW to which they wish to connect. To achieve such NW connections, it is considered to perform NW connections based on attribute / certificate-based authentication.

[0013] However, in existing technologies, there is no reliable trust verification for the user / UE on the NW side, nor is there reliable trust verification for the NW on the UE side. Therefore, there is a risk that reliable NW connections may not be possible.

[0014] The present invention was made in view of the above-mentioned problems, and its object is to provide a technology for achieving a highly reliable NW connection.

[0015] Methods for solving problems

[0016] According to the disclosed technology, a network node is provided, comprising: a receiving unit that receives a trust evaluation request message from a specific network node upon successful authentication using a user's attribute / qualification certificate, wherein the trust evaluation request message includes a trust certificate of a terminal or the user; a control unit that performs trust evaluation processing using the trust certificate; and a sending unit that sends a trust evaluation result to the specific network node.

[0017] The effects of the invention

[0018] Based on publicly available technologies, a technology for achieving highly reliable NW connections is provided. Attached Figure Description

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

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

[0021] Figure 3 This is a diagram illustrating an example of the system structure of Embodiment 1.

[0022] Figure 4 This is a diagram illustrating the processing timing example 1 in Implementation 1.

[0023] Figure 5 This is a diagram illustrating the authentication process of S106 in Example 1 of the processing timing in Implementation 1.

[0024] Figure 6 This is a diagram illustrating the processing timing example 2 in Implementation 1.

[0025] Figure 7 This is a diagram illustrating the authentication process of S107 in Example 2 of the processing timing in Implementation 1.

[0026] Figure 8 This is a diagram illustrating an example of the system structure of Embodiment 2.

[0027] Figure 9 This is a diagram illustrating trust certificate issuance method 1.

[0028] Figure 10 This is a diagram illustrating trust certificate issuance method 2.

[0029] Figure 11 This is a diagram illustrating embodiment 2a.

[0030] Figure 12 This is a diagram illustrating embodiment 2b.

[0031] Figure 13 This is a diagram illustrating embodiment 2c.

[0032] Figure 14 This is a diagram illustrating the user / UE trust evaluation process.

[0033] Figure 15 This is a diagram illustrating the NW trust evaluation process.

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

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

[0036] Figure 18 This 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.

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

[0038] 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.

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

[0040] In addition, in this specification, unless the context clearly indicates otherwise, "A / B" means "A or B". Furthermore, "A or B" includes only A, only B, and "A and B".

[0041] Below, firstly, in this embodiment, an example of the structure of a 5G core network is described, which performs authentication based on attribute / certificate and trust verification based on trust certificate. Then, the structure and operation of this embodiment are explained.

[0042] 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.

[0043] (R)AN (Radio Access Network) 10 is a network node 30 with radio access capabilities, which may include a base station 10 and connect to UE 20, AMF (Access and Mobility Management Function) 30, and UPF (User plane function). 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. UPF is a network node interconnected with DN (Data Network) and has functions such as external PDU (Protocol Data Unit) session points, packet routing and forwarding, and user plane QoS (Quality of Service) processing. UPF and DN constitute a network slice.

[0044] AMF30 is interconnected 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.

[0045] The SMF (Service Provider Function) is a network node with functions such as session management, UE IP (Internet Protocol) address allocation and management, DHCP (Dynamic Host Configuration Protocol) functionality, ARP (Address Resolution Protocol) proxy, and roaming capabilities. The NEF (Network Function Provider Function) is a network node with the ability to notify other NFs (Network Functions) of events. The NSSF (Network Slice Selection Assistance Information) is a network node with functions such as selecting the network slice to which the UE20 connects, determining the permitted NSSAI (Network Slice Selection Assistance Information), determining the configured NSSAI, and determining the AMF set to which the UE20 connects. The PCF (Public Process Control Function) is a network node with the ability to perform network policy control. The AF (Application Provider Function) is a network node with the ability to control application servers. The NRF (Network Provider Function) is a network node with the ability to discover 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.

[0046] 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.

[0047] SEPP is a non-transparent agent that filters 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.

[0048] like Figure 2 As shown, UE20 is in a roaming environment within a 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.

[0049] (An overview of the research topic and its implementation)

[0050] The existing 3GPP NW NW connection authentication (NW Registration) is based on a contract between the user and the NW, and is implemented by using a pre-shared key between the SIM card installed on the user's UE and the NW.

[0051] On the other hand, in 6G, the distributed service provision of multiple NWs or services with different managers was studied. In this way, the following scenario is envisioned: even if the contract or mutual trust relationship (trust) between the user / UE and the NW is not established in advance, or if the user / UE and the NW do not share a shared key, there is a desire to use the NW on demand based on dynamic mutual trust evaluation.

[0052] Furthermore, in the current roaming mechanism between telecommunications operators, NW connection authentication during roaming in a VPLMN (Visited NW, which does not have a direct contractual relationship with the user) is performed as follows: Authentication is conducted in the user's original contracted NW (HPLMN / Home NW) using a shared key between the SIM card installed in the user's UE and the HPLMN, and the result is trusted in the VPLMN. However, in this method, roaming authentication cannot be performed if communication between the VPLMN and HPLMN is interrupted due to large-scale failures, or if there is no prior connection between the VPLMN and HPLMN. Moreover, with the diversification of devices such as wearable terminals and IoT terminals, the demand for connecting terminals without SIM cards to NWs is increasing.

[0053] On the other hand, in recent years, technologies for realizing a new approach to identity management, namely Self-Sovereign Identity (SSI), have been researched, including W3C Decentralized Identifiers (DID) and W3C Verifiable Credentials (VC). In the world of SSI, there are three entities: the Holder (user) who manages / holds their own digital identity; the Issuer (issuer) who issues attribute / credential certificates (VC) after proving the user's attribute information (name, age, address, etc.) and qualification information (employee of a company, member of a service, etc.); and the Verifier (verifier) ​​who verifies the Holder's attributes / qualifications and makes service provision decisions by requesting / receiving the required attribute / credential certificates (VC) from the Holder.

[0054] Distributed NW connection authentication (NW Registration) can be achieved by using user attributes / certificates implemented using W3C Decentralized Identifiers (DID) and W3C Verifiable Credentials (VC). This technology will be described later as Implementation Method 1.

[0055] The technology in Implementation 1 enables NW connection even when using a UE without a SIM card, and when there is no prior subscription or shared key sharing between the user / UE and the NW to be connected. Furthermore, roaming authentication / NW connection in Visited NW (VPLMN) can be performed without querying the Home NW (HPLMN).

[0056] It is envisioned that the aforementioned 6G use cases can be partially addressed by using the technology of Implementation 1. However, in order to establish mutual trust between the user / UE and the NW for secure NW utilization, it is desirable that the NW, in addition to evaluating the user's identity through attributes / certificates, also evaluate the trust (security breaches, etc.) of the UE connected to the NW on the NW side, and evaluate the trust of the NW administrator and NW equipment on the user / UE side, to determine whether the NW connection is feasible. The implementation method of determining the feasibility of NW connection based on trust evaluation will be described later as Implementation 2.

[0057] Implementation method 1 and implementation method 2 can be combined. That is, by using the techniques of implementation method 1 and implementation method 2, it is possible to determine the feasibility of a UE-NW connection based on mutual trust verification between the user / UE and the NW to be connected, while satisfying the conditions that "no prior shared key sharing is required between the user / UE and the NW to be connected," "it can also handle UEs without SIM cards," and "it does not require direct communication between the user's connected NW (VPLMN) and the user's subscribed NW (HPLMN)." Thus, a highly reliable NW connection can be achieved.

[0058] The following describes Embodiment 1 and Embodiment 2. It is envisioned that Embodiment 2 is implemented in combination with Embodiment 1. However, this is not a limitation; Embodiment 1 and Embodiment 2 can also be implemented independently.

[0059] (Summary of Implementation Method 1)

[0060] First, an overview of Implementation 1 will be provided. In Implementation 1, an NW Registration authentication function (an attribute / certificate-based authentication function) using attributes / certificates such as VC is added to the 3GPP NW. In this implementation, 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.

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

[0062] In Implementation 1, 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.

[0063] In Implementation 1, an IF (C-Plane; Control Plane) is added to the existing 3GPP NW that uses the NW Registration associated with the attributes / certificates between the UE and the 3GPP NW. Specifically, as shown in (1) and (2) below.

[0064] (1) Add an IF for sending attributes / certificates from the UE to the 3GPP NW via C-Plane communication. There are two modes: defining it as a new IF and appending the information to be sent in the Registration Request.

[0065] (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.

[0066] Furthermore, in Implementation 1, additional logic was added for NW Registration license ~ D-Plane connection after successful authentication of attribute / certificate.

[0067] In addition, in Implementation 1, by utilizing attribute / certificate information, it is possible to register subscriber information with the UDM for purposes such as enabling the collection of fees.

[0068] (Implementation Method 1: System Structure Example)

[0069] Figure 3 An example of the system structure for Implementation Method 1 is shown. For example... Figure 3 As shown, the communication system of Embodiment 1 includes UE 20, (R)AN 10, authentication function 60 based on attribute / certificate authentication, UDM / UDR (40), and VDR (VDR: Verifiable Data Registry) 70. UDM 40 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 a device that extends the functionality of an existing device (e.g., AUSF). Furthermore, in the description of Embodiment 1, "authentication function 60" is referred to as a newly defined device (network node).

[0070] 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.

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

[0072] 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 a common 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.

[0073] In implementation 1, VDR70 is configured outside the 3GPP NW. However, VDR70 is not limited to a structure configured outside the 3GPP NW; VDR70 can also be configured inside the 3GPP NW.

[0074] VDR70 is a device that can be implemented through web servers, distributed ledgers, etc. VDR70 has user information DB71, issuer information DB72, definition information DB73, and management information DB74.

[0075] 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.

[0076] 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.

[0077] (Implementation Method 1: Processing Timing Example 1)

[0078] Reference Figure 4 Here, we will explain the processing timing example 1 in the first embodiment. Processing timing example 1 is an example using the new NF and the new IF. The premise of the processing is as follows.

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

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

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

[0082] The certificate issuer stores the format (template or definition) of its issued certificates and information used to verify the validity of the certificates in a VDR70 located in a place accessible by 3GPP NW. The timing is described below.

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

[0084] 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.

[0085] 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.

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

[0087] 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.

[0088] 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.

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

[0090] In the subsequent S108, connection processing (also known as registration processing) is performed. Specifically, the NW Registration process is completed by executing the steps following the authentication process in step 9 of the 3GPPTS 23.502 4.2.2.2 registration procedure (Figure 4.2.2.2.2-1: Registration procedure), namely step 10 and subsequent processes.

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

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

[0093] 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.

[0094] 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.

[0095] Next, refer to Figure 5The 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 processing used to authenticate the user (or terminal 20) using the attribute / qualification certificate.

[0096] 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.

[0097] 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.

[0098] Additionally, communication between the authentication function 60 within the 3GPP NW and the VDR70 outside the 3GPP NW can also be achieved through 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.

[0099] 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 retrieve (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 that the VP's Holder signature and the VC's Issuer signature are both based on the signatures of the private keys associated with the corresponding public keys (the legitimacy of the signatures and the absence of message tampering).

[0100] 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.

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

[0102] In S106-7, authentication function 60 requests certificate information from UDM / UDR (40) that can be used for NW connection, and 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 being used for NW connection (e.g., it is a personal identification number VC containing the required information (e.g., name, address)). Furthermore, it is assumed that the personal identification number VC is obtained by converting information equivalent to the current personal identification number into VC form.

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

[0104] (Implementation Method 1: Processing Timing Example 2)

[0105] 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.

[0106] 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.

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

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

[0109] Reference Figure 6 Explain the timing sequence.

[0110] 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).

[0111] 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.

[0112] 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.

[0113] 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 attribute / qualification certificate-based authentication as the authentication method. Furthermore, if both SUPI or SUCI and attribute / qualification certificate are included, the authentication method is selected based on a pre-registered authentication method selection policy or a user request.

[0114] 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.

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

[0116] 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).

[0117] 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.

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

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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).

[0123] 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 that the VP's Holder signature and the VC's Issuer signature are based on the signature of the private key associated with these public keys (the legitimacy of the signature and the absence of message tampering).

[0124] 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.

[0125] More specifically regarding S107-4 to S107-6, the AUSF80 obtains VC mode and definition information from the VDR70 and verifies the correctness of the VC's syntax. Additionally, the AUSF80 obtains VC validity / invalidity information from the VDR70 and verifies the validity of the received VC.

[0126] 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 required information (e.g., name, address)).

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

[0128] 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.

[0129] (Effects of Implementation Method 1)

[0130] According to the technology of the first embodiment, the terminal 20 is able to connect to the NW based on authentication based on the user's attributes / certificates.

[0131] (Summary of Implementation Method 2)

[0132] Next, implementation method 2 will be described. It is envisioned that implementation method 2 is combined with implementation method 1. For functions or network nodes (such as VDR) with the same names in implementation method 1 and implementation method 2, it can be considered that the function / network node of implementation method 1 has been added to the function / network node of implementation method 2, or that the function / network node of implementation method 2 has been added to the outside of the function / network node of implementation method 1.

[0133] In Implementation 2, a trust evaluation function using trusted certificates, implemented via DID / VC, is added to both the 3GPP NW and the UE. Furthermore, a trusted certificate issuance system is added to issue trusted certificates to "users, UEs, NW administrators, and NW devices." In Implementation 2, the trust evaluation function is envisioned to be defined in two modes: one is a new NF (Network Function), and the other is an extension of the functionality of authentication systems such as AUSF.

[0134] Alternatively, "3GPP NW" can also be referred to as the core network defined by 3GPP (registered trademark). Furthermore, in Embodiment 2, "3GPP NW" is cited as a "network" in the description, but the technology of the present invention can be applied to networks not limited to "3GPP NW".

[0135] In Implementation 2, a trust evaluation association IF (C-Plane; control plane) using a trust certificate is added between the UE and the existing 3GPP NW. Specifically, as shown in (1) and (2) below.

[0136] (1) Add an IF that sends a trust certificate from the UE to the 3GPP NW via C-Plane communication. There are two modes: defining it as a new IF and adding information from an existing IF such as a Registration Request.

[0137] (2) Add an IF that notifies the UE of the result from the trust evaluation function, and an IF that sends the trust certificate of NW to the UE. There are two modes: defining a new IF and extending an existing IF.

[0138] Furthermore, additional controls are added to determine whether NW connectivity is feasible after trust evaluations are performed on both the UE and NW sides.

[0139] (Implementation Method 2: System Structure Example)

[0140] Figure 8 This represents a system architecture example. This system architecture example is a common structure for both HPLMN and VPLMN access.

[0141] like Figure 8 As shown, the communication system in the system architecture example includes UE 20, (R)AN 10, AMF 30, trust evaluation function 260, UDM / UDR (40), VDR (Verifiable Data Registry) 70, UE trust certificate issuance system 80, user trust certificate issuance system 90, trust certificate management function 210, and NW trust certificate issuance system 220. Furthermore, the system in Embodiment 2 may have the aforementioned authentication function 60 separately from the trust evaluation function 260, or the authentication function 60 may be included within the trust evaluation function 260, or the trust evaluation function 260 may be included within the authentication function 60 included in the system of Embodiment 2. The "authentication function 60" may also be AUSF.

[0142] UE20 includes a trust evaluation function 22, an NW connectivity function 21, and a trust certificate management function 23. The trust certificate management function 23 includes, for example, an ID wallet.

[0143] like Figure 8 As shown, UDM / UDR (40) includes NW information DB (database) 41, trust certificate DB42 and policy DB43.

[0144] NW Information DB41 stores the NW's identifier, public key, and private key. Trust Certificate DB42 stores the trust certificate. Policy DB43 stores policy information related to trust verification. Furthermore, the aforementioned NW is a 3GPP NW. For example, the term "NW identifier" (and similarly, the NW's public key and private key) can be a common 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.

[0145] In embodiment 2, VDR70 is configured outside the 3GPP NW. However, VDR70 is not limited to a structure configured outside the 3GPP NW; VDR70 can also be configured inside the 3GPP NW.

[0146] VDR70 is a device that can be implemented through web servers, distributed ledgers, etc. VDR70 has information DB71, issuer information DB72, definition information DB73, and management information DB74.

[0147] Information DB71 stores the "identifier and public key information" of the "user / UE / NW administrator / NW device". Issuer Information DB72 stores the "identifier and public key information" of the issuer of the trust certificate. Definition Information DB73 stores the template (schema) and definition information of the trust certificate. Management Information DB74 stores management information indicating the validity / invalidity of the trust certificate.

[0148] Alternatively, the VDR70 can also be held within the NW and provided to users / UEs / trusted certificate issuance systems via APIs provided by the NW.

[0149] Alternatively, the trust evaluation function 260 can also be a way to add trust evaluation processing functionality to existing authentication functions (e.g., AUSF).

[0150] The UE Trusted Certificate Issuance System 80 and the User Trusted Certificate Issuance System 90 are equivalent to the Issuer in the W3C VC. Furthermore, the UE Trusted Certificate Issuance System 80 and the User Trusted Certificate Issuance System 90 can each have more than one certificate issuing authority.

[0151] Trust certificate management function 210, for example, is an ID wallet. Additionally, regarding the NW trust certificate issuance system 220, there can be more than one trust certificate issuer / system in both the NW administrator's trust evaluation and the NW device's trust evaluation.

[0152] In addition, Figure 8 In the example, NW is a 3GPP NW, but it is not limited to this. NW can be any type of NW such as WLAN or fixed NW.

[0153] Furthermore, in this system architecture, in cases of roaming authentication and where the user has signed up for a New Warehouse (HPLMN), the trust evaluation strategy on the HPLMN side can also be used for trust evaluation. In this case, the trust evaluation strategy on the HPLMN side can be shared with the HPLMN on the VPLMN side in advance, or it can be stored in a location accessible from the VPLMN side (e.g., a VDR on a public blockchain).

[0154] (Information used for trust evaluation and examples of trust certificate issuers)

[0155] This section illustrates information used for trust evaluation and examples of trust certificate issuers.

[0156] <User trust rating information>

[0157] As information for trust evaluation, there are identity certificates (passports, personal identification cards, residence certificates, etc.) issued by the government / self-governing bodies, employee certificates issued by enterprises, possession certificates of certain public qualifications (doctor's licenses, etc.), information proving capabilities such as payment (asset information, tax payment certificates, etc.), and certificates of actual usage of certain services, etc.

[0158] The issuers of trust certificates are the government, self-governing bodies, financial institutions, communication operators, the enterprises where the user works, qualification bodies, etc.

[0159] <Regarding the trust evaluation of devices>

[0160] As information for trust evaluation, there are certificates proving that the latest patches have been applied, certificates proving the effectiveness of security measures, certificates showing that security inspections by security vendors, etc. have been completed without problems, and system logs of hardware / software.

[0161] The issuers of trust certificates are device vendors, security vendors, etc.

[0162] <NW: Regarding the trust evaluation of NW administrators>

[0163] As information used in trust evaluation, there are registration matter certificates of the government, etc., seal registration certificates, tax payment certificates, certificates obtained for services / SDGs / system certifications, etc., and the actual operation status of the NW (no security intrusion in X years, etc.).

[0164] The issuers of trust certificates are the government, self-governing bodies, various enterprise certification / recognition bodies, etc.

[0165] <NW: Regarding the trust evaluation of NW devices>

[0166] As information for trust evaluation, there are security inspection results of NW devices (hardware, software), delivery certificates showing that communication has reached correctly, and system logs of hardware / software.

[0167] The issuers of trust certificates are device vendors, security vendors, communication destination service providers of UEs, etc.

[0168] (Examples of trust certificate issuance methods)

[0169] Next, examples of trust certificate issuance methods will be described. In Embodiment 2, pull type (Method 1) and push type (Method 2) are envisioned.

[0170] Refer to Figure 9This section illustrates an example of pull-based trust certificate issuance. In S1, the trust certificate management function of the UE / NW accesses service windows such as physical stores or websites to request a trust certificate issuance from the trust certificate issuance system. More specifically, in S1, the trust certificate management function prompts the trust certificate issuance system with the identifier of the user / UE / NW administrator / NW device that it wants to record in the certificate as the object of the trust certificate issuance (equivalent to the subject in W3C VC).

[0171] In S2, the Trust Certificate Issuance System issues trust certificates and registers validity / expiration management information related to newly issued trust certificates with the VDR. Additionally, if previously issued certificates of the same type exist, their information is registered as expired.

[0172] In S3, the trust certificate issuance system uses remote communication methods such as the network or proximity communication methods such as Bluetooth to forward trust certificates to the trust certificate management function of the UE / NW.

[0173] Reference Figure 10 This section illustrates an example of push-based trust certificate issuance. Here, the recipient of the trust certificate (equivalent to the W3C VC subject) is pre-provided to the trust certificate issuance system with the identifiers of the user / UE / NW administrator / NW device that are intended to be included in the certificate.

[0174] In S1, the Trust Certificate Issuance System periodically checks the system status and security measures of UE / NW devices, etc., through the Trust Certificate Management function.

[0175] In S2, the Trust Certificate Issuance System registers validity / expiration management information related to newly issued Trust Certificates with the VDR. Additionally, if previously issued certificates of the same type exist, these certificates are registered as expired.

[0176] In S3, the trust certificate issuance system can issue trust certificates based on the inspection results at any time for the trust certificate management function. The issuance process of trust certificates can be performed before the trust evaluation process described later, or it can be performed on demand, such as when trust certificates are required during the trust evaluation process.

[0177] Hereinafter, specific processing examples from Implementation Method 2 will be described for Implementation Method 2, and Implementation Methods 2a to 2c will be explained.

[0178] (Implementation Method 2a)

[0179] First, refer to Figure 11The timing diagram shown illustrates implementation method 2a. Implementation method 2a is an implementation method of "the case where the authentication function and the trust evaluation function are different + the case where authentication and trust evaluation are implemented independently." It is assumed that the authentication function is the authentication function 60 in implementation method 1. The premise is as follows.

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

[0181] Users hold user trust certificates and UE trust certificates issued by any entity (enterprise, other users, etc.). NW holds NW trust certificates issued by any entity.

[0182] The certificate issuer holds a public / private key pair corresponding to its own identifier and saves its own identifier and public key association in a VDR70 located in a place accessible to the user / UE and 3GPP NW.

[0183] The certificate issuer stores the format (template or definition) of its issued certificates and information used to verify the validity of the certificates in a VDR70 located in a place accessible to the user / UE and 3GPP NW. The timing is described below.

[0184] exist Figure 11 In S201, at any time such as during user operation, the UE20 sends a trust evaluation request message containing at least one of the user trust certificate and the UE trust certificate to the (R)AN10 of the 3GPP NW. Furthermore, in this embodiment, the trust evaluation process is initiated based on a request from the user / UE, but it is not limited to this; the trust evaluation can also be initiated based on a request from the NW side.

[0185] In S202, (R)AN10 forwards the trust evaluation request message to AMF30.

[0186] In S203, AMF30 sends a trust evaluation request message, including the trust certificate, to the trust evaluation function 260. In S204, the trust evaluation function 260 performs trust evaluation processing for the user / UE. Details of the trust evaluation processing will be described later.

[0187] In S205, the trust evaluation function 260 sends a response to the AMF30, including the trust evaluation result (success / failure).

[0188] In S206, if the trust evaluation result is successful, AMF30 sends a trust authorization message including the NW trust certificate to (R)AN10. If it fails, NW cutoff processing of UE20 under NW leadership is performed.

[0189] The aforementioned NW trust certificate includes at least one of the trust certificate of the NW device and the trust certificate of the NW administrator.

[0190] In S207, (R)AN10 forwards a trust permission message to UE20.

[0191] In S208, UE20 performs a trust evaluation process for the NW. In S209, if the trust evaluation is successful, UE20 sends a trust evaluation completion message to (R)AN10. In the event of failure, UE20-led disconnection from the NW is performed.

[0192] In S210, (R)AN10 forwards the trust evaluation completion message to AMF30. In S211, AMF30 continues to provide NW to the user / UE.

[0193] Furthermore, the trust certificate contained in the S201 message is envisioned to be in the form of, for example, W3C VC. This trust certificate includes at least "an identifier for uniquely identifying the certificate itself", "an identifier of the issuer and a signature based on the private key associated with the issuer's identifier", "an identifier of the subject", and "information on which the trust is evaluated".

[0194] For a VC message containing information that records the user's identifier (e.g., DID) as the certificate's subject, the message is sent in the form of a W3C VP signed with the private key corresponding to the identifier of the same user. On the receiving side, the signature is verified using the public key based on the private key, thereby verifying that the certificate's subject is the same as the sender.

[0195] Similarly, in the case of UE and NW certificates, for certificates containing information about the issuing object of these identifiers, the UE or NW, as the sending source, signs the certificate with the private key corresponding to each identifier, thereby enabling the receiving side to verify that the issuing object of the certificate is the same as the sender.

[0196] According to implementation method 2a, authentication and trust evaluation can be performed independently, thus enabling flexible processing by performing authentication and trust evaluation at any time.

[0197] (Implementation Method 2b)

[0198] Next, refer to Figure 12 The timing diagram shown illustrates implementation method 2b. Implementation method 2b is a case of "different authentication and trust evaluation functions + joint implementation of authentication and trust evaluation". The premise of processing is the same as that of implementation method 2a.

[0199] In S301, UE20 starts NW connection processing triggered by user NW connection application operation or UE power-on.

[0200] In S302, UE20 sends an NW connection request message to (R)AN10 of 3GPP NW.

[0201] At this point, UE20 may include at least one of the user trust certificate and UE trust certificate in the NW connection request message. The user trust certificate is signed with the private key corresponding to the user's identifier, and the UE trust certificate is signed with the private key corresponding to the UE20's identifier.

[0202] Apart from the information used for trust evaluation, the content to be included in this message should be the same as the existing NW connection authentication request message, i.e., the Registration Request message.

[0203] In addition, the NW connection request message sent in S302 can be an extension of existing messages such as Registration Request message, or it can be a new message.

[0204] In S303, (R)AN10 forwards the NW connection request message to AMF30. In S304, AMF30 sends an authentication request to authentication function 60. In S204, authentication function 60 performs the authentication process described in Embodiment 1. In S306, authentication function 60 sends a response message including the authentication result (success / failure) to AMF30.

[0205] The information (attributes / certificates, etc.) required for authentication processing by authentication function 60 can be included in a message sent from UE20 in S302, or it can be notified to authentication function 60 through a message different from the message sent from UE20 in S302.

[0206] In case S302, if a certificate is not held because the message does not contain a trust certificate, or if a trust certificate is held but the latest certificate is desired, the processing in S307-1 to S307-4 shall be performed.

[0207] In S307-1, AMF30 sends a Trust Certificate Request message to (R)AN10. This message can be an extension of an existing message such as the Identity Request message, or it can be a new message.

[0208] In S307-2, (R)AN10 forwards a trust certificate request message to UE20.

[0209] In S307-3, UE20 sends a response message to (R)AN10 containing at least one of the user trust certificate and UE trust certificate. In S307-4, (R)AN10 forwards the response message to AMF30.

[0210] In S308, AMF30 sends a trust evaluation request message containing the trust certificate to the trust evaluation function 260.

[0211] In S309, the trust evaluation function 260 performs trust evaluation processing for the user / UE 20. In S310, the trust evaluation function 60 sends a response message to the AMF 30, including the trust evaluation result (success / failure).

[0212] If the trust evaluation is successful, proceed with connection processing after S311. If it fails, abort the NW connection processing.

[0213] In S311, 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. As part of the NW Registration process, S311-1 to S311-6 are executed.

[0214] In S311-1, AMF30 sends a trust authorization message, including the NW trust certificate, to (R)AN10. In S211-2, (R)AN10 forwards the trust authorization message to UE20.

[0215] In S311-3, UE20 performs NW trust evaluation processing. In S311-4, if successful, UE20 sends a trust evaluation completion message to (R)AN10. If unsuccessful, NW connection processing is aborted.

[0216] In S311-5, (R)AN10 forwards the trust evaluation completion message to AMF30. In S311-6, AMF30 continues to provide NW to user / UE20.

[0217] According to implementation method 2b, authentication and trust evaluation can be carried out jointly, thus enabling efficient processing.

[0218] (Implementation method 2c)

[0219] Next, refer to Figure 13The timing diagram shown illustrates implementation method 2c. Implementation method 2c is an implementation method of "adding trust evaluation processing to the authentication function + jointly implementing authentication and trust evaluation". The premise of the processing is the same as that of implementation methods 2a and 2b. In implementation method 2a, the authentication function 60 includes the trust evaluation function 260. Alternatively, the authentication function 60 may be included in the trust evaluation function 260.

[0220] In S401, UE20 starts NW connection processing when triggered by user NW connection application operation or UE power-on.

[0221] In S402, UE20 sends an NW connection request message to 3GPP NW (R)AN10 containing at least one of the user trust certificate and UE trust certificate.

[0222] The user trust certificate is assigned a signature generated using the private key corresponding to the user's identifier, and the UE trust certificate is assigned a signature generated using the private key corresponding to the UE's identifier. Apart from information used for trust evaluation, the content included in this message should be the same as the existing NW connection authentication request message, i.e., the Registration Request message.

[0223] In addition, the NW connection request message sent in S402 can be an extension of existing messages such as Registration Request message, or it can be a new message.

[0224] In S403, (R)AN10 forwards the NW connection request message to AMF30. In S404, AMF30 sends an authentication / trust evaluation request message including a trust certificate to authentication function 60. In S405, authentication function 60 performs the authentication process of implementation method 1.

[0225] The information (attributes / certificates, etc.) required for authentication processing by authentication function 60 can be included in a message sent from UE20 in S402, or it can be notified to authentication function 60 through a message different from the message sent from UE20 in S402.

[0226] In S406, authentication function 60 performs trust evaluation processing for user / UE20.

[0227] In S407, authentication function 60 sends a response message to AMF30 including the authentication result (success / failure) and trust evaluation result (success / failure). On the authentication function 60 side, based on confirmation of the authentication result and trust evaluation result, it can respond as a success notification if both parties succeed, and as a failure notification otherwise.

[0228] If both the authentication result and the trust evaluation result are successful, proceed with the connection processing after S408. If either fails, abort the NW connection processing.

[0229] In S408, 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. As part of the NW Registration process, S408-1 to S408-6 are executed.

[0230] In S408-1, AMF30 sends a trust authorization message, including the NW trust certificate, to (R)AN10. In S408-2, (R)AN10 forwards the trust authorization message to UE20.

[0231] In S408-3, UE20 performs NW trust evaluation processing. In S408-4, if successful, UE20 sends a trust evaluation completion message to (R)AN10. If unsuccessful, NW connection processing is aborted.

[0232] In S408-5, (R)AN10 forwards the trust evaluation completion message to AMF30. In S408-6, AMF30 continues to provide NW to user / UE20.

[0233] According to implementation method 2c, authentication and trust evaluation can be carried out jointly, thus enabling efficient processing.

[0234] (User / UE trust evaluation processing)

[0235] Next, as a common process in embodiments 2a to 2c, refer to Figure 14 This section provides a specific example of user / UE trust evaluation processing in NW.

[0236] Here, as an example of user / UE trust evaluation logic, we envision the verification of trust certificates in the form of W3C DID / VC / VP.

[0237] When the trust evaluation process based on the trusted certificate begins, in S1, the trust evaluation function 260 / authentication function 60 requests the public key corresponding to the identifier of the certificate issuer, the public key corresponding to the identifier of the user, and the public key corresponding to the identifier of the UE20 from the VDR70. In S2, the VDR70 responds to the trust evaluation function 260 / authentication function 60 with these public keys.

[0238] In S3, the trust evaluation function 260 / authentication function 60 verifies the legitimacy of the certificate issuer's signature, the user's signature, and the UE's signature, as well as the absence of message tampering.

[0239] Additionally, communication between the Trust Evaluation Function 260 / Authentication Function 60 within the 3GPP NW and the VDR70 outside the 3GPP NW can also be achieved from the Trust Evaluation Function 60 / Authentication Function 230 within the 3GPP NW via a node (e.g., NEF, SCEF) that mediates the exchange with the VDR70 outside the 3GPP NW.

[0240] More specifically regarding S1 to S3, in S1 and S2, the trust evaluation function 260 / authentication function 60 receives DID0 (identifier of the certificate issuer), DID1 (identifier of the user), and DID2 (identifier of the UE20) contained in the VP / VC as input, and uses any DID method to obtain (resolve) the DID Document (public key) corresponding to DID0, DID1, and DID2 from the VDR70. In S3, the trust evaluation function 260 / authentication function 60 verifies the following: the signature of the VP's source user, the signature of the VP's source UE, and the issuer signature of the VC are all based on the signature of the private key associated with the corresponding public key (signature legitimacy, no message tampering).

[0241] In S4, the trust evaluation function 260 / authentication function 60 requests information from the VDR 70 regarding the certificate's format and status (expiration status, etc.). In S5, the VDR 70 responds with the certificate's format and status information. In S6, the trust evaluation function 260 / authentication function 60 verifies the certificate's validity.

[0242] More specifically regarding S4 to S6, the trust evaluation function 260 / authentication function 60 obtains the VC template, definition information, etc., from the VDR70 and verifies the correctness of the VC's syntax, etc. Additionally, the trust evaluation function 260 / authentication function 60 obtains the VC's validity / invalidity information from the VDR70 and verifies the validity of the received VC.

[0243] In S7, the trust evaluation function 260 / authentication function 60 requests trust evaluation policy information from the UDM / UDR (40), and in S8, the UDM / UDR (40) responds with the trust evaluation policy information. In S9, the trust evaluation function 260 / authentication function 60 performs certificate conformity verification. More specifically, the trust evaluation function 260 / authentication function 60 verifies that the content of the certificate meets the trust evaluation policy in the NW.

[0244] An example of a trust evaluation strategy in NW is described below.

[0245] • User trust evaluation status: If the trust certificate is a nationally issued Personal Number (My Number) VC, then the trust evaluation is successful.

[0246] • UE Trust Evaluation Status: If the trust certificate (VC) is proof that the security vendor has verified the UE's security without any issues, then the trust evaluation is successful.

[0247] In addition, we can imagine that the Personal Identification Number (VC) is obtained by converting information equivalent to the current Personal Identification Number into VC form.

[0248] If all the above verification results are judged to be OK, the trust evaluation function 260 / authentication function 60 is judged to be successful.

[0249] Furthermore, the trust evaluation logic is not limited to the above content, and trust evaluation logic other than those mentioned above can also be used.

[0250] Furthermore, as a trust evaluation method, we envision "setting the user's or UE's trust evaluation as successful on the NW side based on the content that the certificate issuer has evaluated the user's or UE's trust and there are no issues" and "evaluating whether the user or UE can be trusted on the NW side based on comparing the evidence information contained in the certificate for trust evaluation (e.g., user's asset information, medical license information, UE's system information or security logs) with the trust evaluation strategy on the NW side," but either method can be used.

[0251] When both the user trust certificate and the UE trust certificate are received, the trust evaluation can be performed by combining the information from both parties, or by the user side and the UE side performing the trust evaluation separately. If there is no NG (Not Acceptable Error), the trust evaluation is considered successful.

[0252] In addition, regarding the trust evaluation strategy when connecting to a VPLMN, either the strategy on the VPLMN side or the strategy on the HPLMN side can be used.

[0253] (NW Trust Evaluation Processing)

[0254] Next, as part of the common procedures for implementing 2a to 2c, refer to Figure 15 This section provides a specific example of NW trust evaluation processing in the UE.

[0255] Here, as an example of NW trust evaluation logic, we envision the verification of trust certificates in the form of W3C DID / VC / VP.

[0256] When trust processing based on a trusted certificate begins, in S1, the trust evaluation function 22 requests from the VDR 70 the public key corresponding to the identifier of the certificate issuer, the public key corresponding to the identifier of the NW administrator, and the public key corresponding to the identifier of the NW device. In S2, the VDR 70 responds to the trust evaluation function 22 with these public keys.

[0257] In S3, the trust evaluation function 22 verifies the legitimacy of the signatures of the certificate issuer, the NW administrator, and the NW device, as well as the absence of message tampering.

[0258] Furthermore, communication between the Trust Evaluation Function 22 and the VDR70 outside the 3GPP NW can also be achieved from the Trust Evaluation Function 22 within the 3GPP NW via a node (e.g., NEF, SCEF) that mediates the exchange with the VDR70 outside the 3GPP NW.

[0259] More specifically regarding S1 to S3, in S1 and S2, the trust evaluation function 22 receives DID3 (identifier of the certificate issuer), DID4 (identifier of the NW administrator), and DID5 (identifier of the NW device) contained in the VP / VC as input. Using any DID method, it retrieves (resolves) the DID Document (public key) corresponding to DID3, DID4, and DID5 from the VDR70. In S3, the trust evaluation function 22 verifies that the signature of the VP's sending source NW administrator, the signature of the sending source NW device, and the VC's Issuer signature are all based on the private key associated with the corresponding public key (the legitimacy of the signature and the absence of message tampering).

[0260] In S4, the trust evaluation function 22 requests information from the VDR 70 regarding the certificate's format and status (expiration status, etc.). In S5, the VDR 70 responds with the certificate's format and status information. In S6, the trust evaluation function 22 verifies the certificate's validity.

[0261] More specifically regarding S4 to S6, the trust evaluation function 22 obtains VC templates, definition information, etc. from VDR70 and verifies the correctness of the VC's syntax, etc. Additionally, the trust evaluation function 22 obtains VC validity / invalidity information from VDR70 and verifies the validity of the received VC.

[0262] In S7, the trust evaluation function 22 requests trust evaluation policy information from the UE's internal database, etc., and in S8, the UE's internal database, etc., responds with the trust evaluation policy information. In S9, the trust evaluation function 22 performs certificate qualification verification. More specifically, the trust evaluation function 22 verifies whether the content of the certificate meets the trust evaluation policy in UE 20.

[0263] The following is an example of a trust evaluation strategy in UE20.

[0264] • Trust evaluation status for NW managers: If the trust certificate is a State Registered Item Certificate (VC) issued by the state, then the trust evaluation is successful.

[0265] • Trust evaluation status for NW devices: If the trust certificate (VC) is proof from the security vendor that the NW device's security check has no issues, then the trust evaluation is successful.

[0266] If all the above verification results are judged to be OK, the trust evaluation function 22 is judged to be successful.

[0267] Furthermore, the trust evaluation logic is not limited to the above content, and trust evaluation logic other than those mentioned above can also be used.

[0268] Furthermore, as a trust evaluation method, it is envisioned that "based on the content that the issuer of the certificate has evaluated that the trust of the NW manager or NW device is not problematic, the trust evaluation of the NW manager or NW device is set to successful on the user / UE side", and "based on comparing the evidence information for trust evaluation contained in the certificate (e.g., information contained in the registration certificate, system information of the NW device, or security logs, etc.) with the trust evaluation policy on the UE side, the trust evaluation can be performed on the UE side", but any method can also be used.

[0269] Furthermore, in Implementation 2, the user's attributes / qualification certificate can be the same as the user's trust certificate. Additionally, if authentication is successful based on the user's attributes / qualification certificate from authentication function 60, trust evaluation function 260 (including cases included in authentication function 60) can also verify only the UE's trust certificate and the UE's trust certificate within the user's trust certificate.

[0270] (Supplementary matters)

[0271] As an implementation means to obtain the information required for trust evaluation of NW (public key, certificate template or expiration information, evaluation policy corresponding to the identifier of issuer / NW manager / NW device on VDR) before registration with NW, for example, the following (1) to (4) are envisioned.

[0272] (1) During processing, UE20 utilizes other available NWs, accesses VDRs and strategies for trust evaluation.

[0273] (2) In the past, a certain NW timing was used to download evaluation strategies in UE20 (in the case of VDR, synchronize with the VDR node on UE20).

[0274] (3) Pre-install the information required for trust evaluation in the UE20 or the SIM card mounted on the UE20.

[0275] (4) Only the systems required for trust evaluation such as VDR may be accessible through the NW prior to NW Registration.

[0276] (Device structure)

[0277] Next, the functional structure of the "trust evaluation function 260, authentication function 60, AMF30, etc." and the terminal 20 (UE20) that have implemented the processing and actions described above will be explained. Hereinafter, the network nodes such as trust evaluation function 260, authentication function 60, and AMF30 will be collectively referred to as "network node 100".

[0278] <Network Node 100>

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

[0280] like Figure 16 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 16 The functional structure shown is only one example. The functional divisions and names of the functional units can be arbitrary, as long as the actions involved in the embodiments of this invention can be implemented.

[0281] The transmitting unit 110 includes the function of generating signals to be transmitted to the terminal 20 or other network nodes and transmitting the signals in a wired or wireless manner. 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.

[0282] 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.

[0283] Terminal 20

[0284] Figure 17 This is a diagram illustrating an example of the functional structure of terminal 20. For example... Figure 17 As shown, terminal 20 has a transmitting unit 310, a receiving unit 320, a setting unit 330, and a control unit 340. Figure 14 The functional structure shown is only one example. The functional divisions and names of the functional units can be arbitrary, as long as the actions involved in the embodiments of this invention can be implemented.

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

[0286] The setting unit 330 stores various setting information received by the receiving unit 320 from the network node into a storage device, and reads it from the storage device as needed. In addition, the setting unit 330 also stores preset setting information.

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

[0288] (Hardware structure)

[0289] The block diagram used in the description of the above embodiments ( Figure 16 and Figure 17The diagram illustrates blocks organized by function. These functional blocks (structural units) 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.

[0290] 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, a functional block (structural unit) that performs the sending function is called a transmitting unit or transmitter. In short, as mentioned above, there are no particular limitations on the implementation method.

[0291] For example, in one embodiment of this disclosure, the network node 100 and terminal 20 can also function as computers for processing the communication methods of this disclosure. Figure 18 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 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.

[0292] Additionally, 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 to not include any of them.

[0293] 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.

[0294] 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 340 described above can also be implemented using the processor 1001.

[0295] 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 16 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. And, for example, Figure 17 The control unit 340 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.

[0296] Storage device 1002 is a computer-readable recording medium, and may be composed of at least one of ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory), etc. 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.

[0297] 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.

[0298] 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.

[0299] 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).

[0300] 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 as a single bus or as different buses used between the devices.

[0301] 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.

[0302] Figure 19 An example of the structure of vehicle 2001 is shown. For example... Figure 19 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 be included in the communication module 2013.

[0303] 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), configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel by the user.

[0304] 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).

[0305] The signals from various sensors 2021 to 2029 include current signals from current sensor 2021 that senses 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 input signals obtained by accelerator pedal sensor 2029, brake pedal input signals obtained by brake pedal sensor 2026, gear lever operation signals obtained by gear lever sensor 2027, and detection signals obtained by object detection sensor 2028 for detecting obstacles, vehicles, pedestrians, etc.

[0306] 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.).

[0307] 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.

[0308] 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 2029 in the vehicle 2001 via the communication port 2033.

[0309] 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.

[0310] 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 mentioned above, the information obtained based on the 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 an input unit that receives input.

[0311] 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 (e.g., outputting information to devices such as displays and speakers based on PDSCH received by the communication module 2013 (or data / information decoded from that PDSCH). Furthermore, 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, gearshift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021-2029, etc., of the vehicle 2001 based on the information stored in the memory 2032.

[0312] Furthermore, when the communication module 2013 includes a network node 100 (or a terminal 20), the communication module 2013 can execute the actions of the aforementioned network node 100 (or terminal 20).

[0313] The structure described in the following notes is disclosed at least in this specification.

[0314] <Postscript>

[0315] (Note 1)

[0316] A network node having: The receiving unit receives a trust evaluation request message from a specific network node when the authentication using the user's attribute / qualification certificate is successful. The trust evaluation request message contains the trust certificate of the terminal or the user. The control unit performs trust evaluation processing using the aforementioned trust certificate; and The sending unit sends the trust evaluation result to the specific network node.

[0317] (Note 2)

[0318] According to the network nodes described in Note 1, wherein, If the trust evaluation of the terminal or the user is successful, and the trust evaluation of the network in the terminal is successful, the terminal continues to connect to the network.

[0319] (Note 3)

[0320] A network node having: The receiving unit receives a trust evaluation request message containing a trust certificate of a terminal or user from a specific network node, wherein the specific network node receives a message containing the trust certificate from the terminal. The control unit performs authentication processing using the user's attributes / qualification certificates and trust evaluation processing using the trusted certificates; and The sending unit sends a response message related to the authentication result and trust evaluation result to the specific network node.

[0321] (Note 4)

[0322] A terminal having: The receiving unit receives a message containing the network's trust certificate from a specific network node when the network side successfully authenticates the user's attributes / qualification certificate and successfully evaluates the trust of the terminal or the user. The control unit performs trust evaluation processing using the aforementioned trust certificate; and The sending unit sends a trust evaluation completion message to the specific network node if the trust evaluation result is successful.

[0323] (Note 5)

[0324] A communication method, executed by a network node, comprises the following steps: Upon successful authentication using the user's attributes / qualification certificate, a trust evaluation request message is received from a specific network node, wherein the trust evaluation request message contains the trust certificate of the terminal or the user; Perform trust evaluation processing using the trusted certificate; and Send the trust evaluation result to the specific network node.

[0325] (Note 6)

[0326] A communication method, executed by a terminal, comprises the following steps: If the authentication of the user's attributes / qualification certificates is successful on the network side and the trust evaluation of the terminal or the user is successful, a message containing the network's trust certificate is received from a specific network node. Perform trust evaluation processing using the trusted certificate; and If the trust evaluation result is successful, a trust evaluation completion message is sent to the specific network node.

[0327] A highly reliable NW connection can be achieved by using any one of notes 1 through 6. Note 2 clarifies the conditions for continuing the connection to the network.

[0328] (Supplement to the implementation method)

[0329] The embodiments of the present invention have been described above, but the disclosed invention is not limited to these 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. Software operating according to embodiments of the present invention via the processor of EES30 and software operating according to embodiments of the present invention via the processor of terminal 20 may also 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 other suitable storage media, respectively.

[0330] 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, the notification of information 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. Additionally, RRC signaling may be referred to as an RRC message, for example, it may also be an RRC Connection Setup message, an RRC Connection Reconfiguration message, etc.

[0331] 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), 6G (6th generation mobile communication system), xG (xth generation mobile communication system) (xG (x is, for example, an integer or a decimal)), FRA (Future Radio Access), NR (new Radio), NX (new radio access), FX (Future generation radio access), 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 these systems that have been extended, modified, created, or specified. Furthermore, multiple systems may be combined (e.g., a combination of at least one of LTE and LTE-A with 5G, etc.).

[0332] 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.

[0333] In this specification, certain actions performed by base station 10 ((R)AN10) are sometimes also 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 a case where there is 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).

[0334] 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.

[0335] 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.

[0336] 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).

[0337] 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.

[0338] In addition, software, commands, and information can also be sent and received via transmission media. 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 transmission media.

[0339] 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 as a whole can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or photons, or any combination of these.

[0340] 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.

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

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

[0343] 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.

[0344] 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.

[0345] 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.

[0346] 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.

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

[0348] 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.

[0349] 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. Additionally, 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. This 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, two-wheeled trailers, rickshaws, ships (ships and other watercraft), airplanes, rockets, artificial satellites, Drone (registered trademark), multi-rotor helicopters, quadcopter helicopters, balloons, and objects mounted on them. Furthermore, the mobile body can also be a mobile body that moves autonomously based on operating commands. The mobile body can be a means of transportation (e.g., automobiles, airplanes, etc.), a mobile body that moves unmanned (e.g., drones, autonomous vehicles, etc.), or a robot (humanized or unmanned). In addition, 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.

[0350] 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 inter-terminal communication (e.g., "side"). For example, uplink channel, downlink channel, etc., can also be replaced with side channel.

[0351] Similarly, the user terminal in this disclosure can 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.

[0352] 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." Additionally, "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.

[0353] 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.

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

[0355] 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".

[0356] 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, references to the first and second elements do not imply that only two elements can be taken, or that in any form the first element must precede the second element.

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

[0358] 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.

[0359] 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.

[0360] In this disclosure, the phrase "A and B are different" can mean "A and B are not the same." Additionally, 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."

[0361] 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 notification of "It is X") is not limited to being explicit, but can also be implicit (e.g., without notification of the predetermined information).

[0362] 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.

[0363] Label Explanation

[0364] 10: Base station ((R)AN)

[0365] 20: Terminal (UE)

[0366] 21: NW connectivity function

[0367] 22, 260: Trust Evaluation Function

[0368] 30: AMF

[0369] 40, 240: UDM

[0370] 41: NW Information DB

[0371] 42: Trusted Certificate DB

[0372] 43: Strategy DB

[0373] 60: Authentication Function

[0374] 70: VDR

[0375] 71: User Information DB

[0376] 72: Issuer Information DB

[0377] 73: Define Information DB

[0378] 74: Management Information DB

[0379] 80: AUSF

[0380] 100: Network Node

[0381] 110: Sending Department

[0382] 120: Receiving Department

[0383] 130: Setting Department

[0384] 140: Control Department

[0385] 310: Sending Department

[0386] 320: Receiving Department

[0387] 330: Setting Department

[0388] 340: Control Department

[0389] 1001: Processor

[0390] 1002: Storage device

[0391] 1003: Auxiliary storage device

[0392] 1004: Communication device

[0393] 1005: Input device

[0394] 1006: Output device

Claims

1. A network node having: The receiving unit, upon successful authentication using the user's attributes / qualification certificates, receives a trust evaluation request message from a specific network node, wherein... The trust evaluation request message contains the trust certificate of the terminal or the user; The control unit performs trust evaluation processing using the aforementioned trust certificate; and The sending unit sends the trust evaluation result to the specific network node.

2. The network node according to claim 1, wherein, If the trust evaluation of the terminal or the user is successful, and the trust evaluation of the network in the terminal is successful, the terminal continues to connect to the network.

3. A network node having: The receiving unit receives a trust evaluation request message containing the trust certificate of the terminal or user from a specific network node. The specific network node receives a message containing the trust certificate from the terminal; The control unit performs authentication processing using the user's attributes / qualification certificates and trust evaluation processing using the trusted certificates; as well as The sending unit sends a response message related to the authentication result and trust evaluation result to the specific network node.

4. A terminal having: The receiving unit receives a message containing the network's trust certificate from a specific network node when the network side successfully authenticates the user's attributes / qualification certificate and successfully evaluates the trust of the terminal or the user. The control unit performs a trust evaluation process that uses the trusted certificate; as well as The sending unit sends a trust evaluation completion message to the specific network node if the trust evaluation result is successful.

5. A communication method, performed by a network node, comprising the following steps: Upon successful authentication using the user's attributes / qualification certificates, a trust evaluation request message is received from a specific network node, wherein... The trust evaluation request message contains the trust certificate of the terminal or the user; Perform a trust evaluation process that uses the trusted certificate; as well as Send the trust evaluation result to the specific network node.

6. A communication method, executed by a terminal, comprising the following steps: If the authentication of the user's attributes / qualification certificates is successful on the network side and the trust evaluation of the terminal or the user is successful, a message containing the network's trust certificate is received from a specific network node. Perform a trust evaluation process that uses the trusted certificate; as well as If the trust evaluation result is successful, a trust evaluation completion message is sent to the specific network node.

Images