Network node, terminal, and communication method

Abstract

A network node includes a reception unit that receives a trust evaluation request message including a trust certificate of a terminal or a user from a specific network node that has received a message including the trust certificate from the terminal, a control unit that performs a trust evaluation process using the trust certificate, and a transmission unit 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] Furthermore, within the telecommunications operator's NW (network), roaming services are also provided to users / UEs without a direct contractual relationship. The NW that is not part of the user's original contracted NW is referred to as a VPLMN / Visited NW. NW connection authentication during roaming in the VPLMN is performed as follows: in the user's original contracted NW (HPLMN / Home NW), authentication is performed using the SIM card installed by the user's UE and the shared key in the HPLMN, and the result is trusted in the VPLMN.

[0004] Existing technical documents

[0005] Non-patent literature

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

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

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

[0009] The problem that the invention aims to solve

[0010] 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 problem that reliable VPLMN connections cannot be established. This problem is not limited to VPLMN connections; it may arise in other areas as well as HPLMN connections and post-connection service provision.

[0011] The present invention was made in view of the above-mentioned problems, and its object is to provide a technique for performing highly reliable trust verification in NW or terminals.

[0012] Methods for solving problems

[0013] According to the disclosed technology, a network node is provided, comprising: a receiving unit that receives a trust evaluation request message containing a trust certificate of a terminal or a user from a specific network node, wherein the specific network node receives a message containing the trust certificate from the terminal; 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.

[0014] The effects of the invention

[0015] Based on publicly available technologies, techniques are provided for performing highly reliable trust verification in NW or terminals. Attached Figure Description

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

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

[0018] Figure 3 This is a diagram showing the system structure example A.

[0019] Figure 4 This is a diagram showing the system structure example B.

[0020] Figure 5 This is a diagram showing the system structure example C.

[0021] Figure 6 This is a diagram illustrating trust certificate issuance method 1.

[0022] Figure 7 This is a diagram illustrating trust certificate issuance method 2.

[0023] Figure 8 This is a diagram illustrating embodiment a.

[0024] Figure 9 This is a diagram illustrating implementation method b.

[0025] Figure 10 This is a diagram illustrating embodiment c.

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

[0027] Figure 12 This is a diagram illustrating the NW trust evaluation process.

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

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

[0030] Figure 15 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.

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

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

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

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

[0035] Hereinafter, firstly, in this embodiment, an example of the structure of a 5G core network that performs trust verification based on trust certificates will be described. Then, the structure and operation of this embodiment will be explained.

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

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

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

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

[0040] Figure 2 This 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.

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

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

[0043] (Regarding the research topic)

[0044] As mentioned above, currently, within the NW (Network Wi-Fi) of telecommunications operators, roaming services are also provided to users / UEs who do not have a direct contractual relationship with the NW. NWs that are not part of the user's original contracted NW are referred to as VPLMNs / Visited NWs.

[0045] NW connection authentication during roaming in a VPLMN is performed as follows: authentication is conducted in the user's original contracted NW (HPLMN / Home NW) using the SIM card installed by the user's UE and the shared key in the HPLMN, and the result is trusted in the VPLMN. However, this authentication method has issues as described in (1) and (2) below.

[0046] (1) It has a high dependence on HPLMN, and the reliability (trust) of users depends on the confirmation of the user when signing up for HPLMN. In addition, it cannot reflect the user trust verification strategy in VPLMN.

[0047] (2) When connecting to the VPLMN, only the shared key is verified, without sufficient trust verification for the user / UE. For example, the VPLMN or NW administrator may suffer losses due to NW exploitation by unauthorized users, compromised UEs, etc. Furthermore, from the user / UE's perspective, sufficient trust verification for the NW and its administrator used by the user is not performed.

[0048] Because of the issues mentioned in (1) and (2) above, the following issues exist: When the UE connects to the VPLMN, it is desirable to verify the trust between the user / UE and the NW / NW manager to determine whether the NW connection is valid. However, the information exchange between the user / UE and the NW is not reliable.

[0049] On the other hand, in recent years, technologies for realizing a new identity management concept, 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.

[0050] By utilizing techniques such as VC, the following advantages are available (1) to (5).

[0051] (1) It enables the circulation of highly reliable information certified by the issuer (issuer) such as the government, without requiring users to declare it themselves.

[0052] (2) Through a public key-based mechanism, the recipient (Verifier) ​​of the VC can quickly verify online that it is a formal certificate without asking the Issuer.

[0053] (3) There is no need to prepare for the sharing of shared keys between the Verifier and the Holder in advance.

[0054] (4) By utilizing structures such as blockchain, the tamper resistance of VC can be improved.

[0055] (5) It can be used by multiple related parties such as the user (Holder), the certificate issuer (Issuer), and the certificate user (Verifier).

[0056] However, in the existing technology, there is no mechanism to determine whether an NW connection based on mutual trust verification can be combined with the above-mentioned technologies.

[0057] In this embodiment, a technique for solving the above-mentioned problem is described. Specifically, in this embodiment, a mechanism for determining the viability of an NW connection based on mutual trust verification between the user / UE and the NW (which can be applied to both parties in HPLMMN and VPLMN connections) is described. The mutual trust verification uses techniques such as DID / VC and uses reliable information.

[0058] Furthermore, the application scope of the trust verification technology in this embodiment is not limited to determining whether NW connection is possible. For example, the trust verification technology in this embodiment can be applied to determining whether NW service provision is possible. In this case, for example, if the NW successfully verifies the user's / UE's trust, it determines that it can provide NW service to the user / UE; if the user / UE successfully verifies the NW's trust, it determines that it can receive NW service from the NW.

[0059] (Summary of the implementation method)

[0060] First, an overview of the implementation method will be provided. In this implementation, a trust evaluation function using trust certificates, implemented via DID / VC, is added to both the 3GPP NW and the UE. Furthermore, a trust certificate issuance system is added to issue trust certificates to "users, UEs, NW administrators, and NW devices." In this implementation, the trust evaluation function is envisioned in two modes: one defined as a new NF (Network Function), and the other extending the functionality of authentication systems 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 this embodiment, a trust evaluation association IF (C-Plane; control plane) with a trust certificate is added between the UE and the existing 3GPP NW. Specifically, it is shown in (1) and (2) below.

[0063] (1) The UE adds an IF to the 3GPP NW to send the trust certificate via C-Plane communication. There are two modes: defining it as a new IF and adding the sending information in an existing IF such as a Registration Request.

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

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

[0066] Hereinafter, system structure examples A to C will be described as examples of system structures in this embodiment.

[0067] (System structure example A)

[0068] Figure 3 This represents system architecture example A. System architecture example A is a structure that envisions the scenario where UE20 accesses the HPLMN.

[0069] like Figure 3As shown, the communication system of system architecture example A includes UE20, (R)AN10, AMF30, trust evaluation function 60, UDM / UDR (40), VDR (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.

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

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

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

[0073] In this embodiment, 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 information DB71, issuer information DB72, definition information DB73, and management information DB74.

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

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

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

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

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

[0080] In addition, Figure 3 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.

[0081] (System structure example B)

[0082] Figure 4 This represents system architecture example B. System architecture example B envisions the scenario where UE20 accesses a Visited PLMN (i.e., during roaming). When accessing a Visited PLMN, the authentication function of the HPLMN is utilized.

[0083] Figure 4 It shows the relationship with Figure 3 The same structure is shown as the system architecture in UE20 and Visited NW (visited network). Here, only the structure shown is described. Figure 3 Different parts of the structure.

[0084] like Figure 4 As shown, the Visited NW includes vSEPP260. The Home NW (home network) includes authentication functions 230 (e.g., AUSF), UDM240, and hSEPP250.

[0085] (System structure example C)

[0086] Figure 5 This illustrates system architecture example C. System architecture example C envisions a scenario where the UE20 accesses a Visited PLMN (i.e., during roaming), utilizing the HPLMN-side trust evaluation function and trust evaluation policy in conjunction with the SIM authentication function on the HPLMN side. The differences from system architecture example B will be explained below. Furthermore, although not illustrated in the Home NW diagram, it also includes trust certificate management functions required for trust evaluation.

[0087] The UDM 240 of the HPLMN also maintains the "NW identifier, public key, private key information, trust certificate, trust evaluation policy" for trust evaluation. The authentication function 230 of the HPLMN includes a trust evaluation function and accesses the VDR 70 during trust evaluation. In addition, after performing a trust evaluation based on the trust evaluation policy on the HPLMN side, the authentication function (trust evaluation function) 230 notifies the result to the VPLMN.

[0088] The trust evaluation function 60 of the VPLMN sends the NW trust certificate of the VPLMN as the NW trust certificate for NW trust evaluation on the user / UE side. In addition, in the case of forwarding D-Plane (data plane) communication via the HPLMN, the trust evaluation function 60 can also evaluate the trust certificate of the HPLMN.

[0089] (Examples of information for trust evaluation and issuers of trust certificates)

[0090] Here, examples of information for trust evaluation and issuers of trust certificates are described.

[0091] <Case of user's trust evaluation>

[0092] As information for trust evaluation, there are identity certificates (passports, personal number cards, resident cards, etc.) issued by the government / autonomous regions, employee certificates issued by enterprises, certificates of holding certain public qualifications (such as medical licenses), information proving payment capabilities (asset information, tax certificates, etc.), certificates of actual usage of certain services, etc.

[0093] Issuers of trust certificates are the government, autonomous regions, financial institutions, communication operators, the user's employer enterprise, qualification groups, etc.

[0094] <Case of device's trust evaluation>

[0095] As information for trust evaluation, there are certificates proving the application of the latest patches, certificates proving the effectiveness of security measures, certificates indicating no problems after security inspections by security vendors, etc., and system logs of hardware / software.

[0096] Issuers of trust certificates are device vendors, security vendors, etc.

[0097] <Case of NW: trust evaluation of NW administrator>

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

[0099] The issuers of trust certificates are the government, local autonomous bodies, various enterprise certification / recognition organizations, etc.

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

[0101] As information for trust evaluation, there are security inspection results of NW devices (hardware, software), delivery certificates indicating correct communication arrival, system logs of hardware / software, etc.

[0102] The issuers of trust certificates are device suppliers, security suppliers, service providers of the communication destinations of UEs, etc.

[0103] (Examples of trust certificate issuance methods)

[0104] Next, examples of trust certificate issuance methods will be described. In this embodiment, a pull type (Method 1) and a push type (Method 2) are assumed.

[0105] Refer to Figure 6 , and an example of the pull type trust certificate issuance will be described. In S1, the trust certificate management function possessed by the UE / NW accesses the service window or website, etc. of an entity store, etc., and makes a trust certificate issuance application to the trust certificate issuance system. More specifically, in S1, the trust certificate management function presents the identifiers of the user / UE / NW manager / NW device that are desired to be recorded in the certificate as the issuance target of the trust certificate (equivalent to the subject of W3C VC) to the trust certificate issuance system.

[0106] In S2, the trust certificate issuance system issues a trust certificate, and registers the validity / invalidity management information of the newly issued trust certificate with the VDR. Additionally, in the case where there are previously issued certificates of the same type, the information of these certificates is registered as invalid.

[0107] In S3, the trust certificate issuance system forwards the trust certificate to the trust certificate management function of the UE / NW using remote communication means such as the network or proximity communication means such as Bluetooth.

[0108] Refer to Figure 7 , and an example of the push type trust certificate issuance will be described. Here, as the issuance target of the trust certificate (equivalent to the subject of W3C VC), it is assumed that the identifiers of the user / UE / NW manager / NW device that are desired to be recorded in the certificate have been provided to the trust certificate issuance system in advance.

[0109] In S1, the trust certificate issuance system periodically checks the system status, security countermeasure status, etc. of the UE / NW device, etc. of the trust certificate management function.

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

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

[0112] The following describes implementation methods a to c as specific processing examples.

[0113] (Implementation method a)

[0114] First, refer to Figure 8 The timing diagram shown illustrates implementation method a. Implementation method a is an implementation method for "the case where the authentication function and the trust evaluation function are different + the case where authentication and trust evaluation are implemented independently." Implementation method a can be implemented using any structure from system structure examples A to C. The premises for processing are as follows.

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

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

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

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

[0119] exist Figure 8 In S101, 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.

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

[0121] In S103, AMF30 sends a trust evaluation request message, including the trust certificate, to the trust evaluation function 60. In S104, the trust evaluation function 60 performs trust evaluation processing for the user / UE. Details of the trust evaluation processing will be described later.

[0122] In S105, the trust evaluation function 60 sends a response to the AMF30, including the trust evaluation result (success / failure).

[0123] In S106, 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 disconnection processing of UE20 under NW leadership is performed.

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

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

[0126] In S108, UE20 performs a trust evaluation process for the NW. In S109, 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.

[0127] In S110, (R)AN10 forwards the trust evaluation completion message to AMF30. In S111, AMF30 continues to provide NW to the user / UE.

[0128] Furthermore, the trust certificate contained in the S101 message is envisioned to be in the form of, for example, W3C VC. This trust certificate contains 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".

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

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

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

[0132] (Implementation method b)

[0133] Next, refer to Figure 9 The timing diagram shown illustrates implementation method b. Implementation method b is a combination of "different authentication and trust evaluation functions + joint implementation of authentication and trust evaluation". Implementation method b can be implemented using any of the system architecture examples A to C. During VPLMN access, the HPLMN authentication function 230 is utilized. The processing prerequisites are the same as in implementation method a.

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

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

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

[0137] Apart from the 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.

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

[0139] S203–S206 are existing processes, therefore only a summary is provided. In S203, (R)AN10 forwards the NW connection request message to AMF30. In S204, AMF30 sends an authentication request to authentication function 230. In S205, authentication function 230 performs authentication processing. This authentication processing is equivalent to step 9 of 3GPP TS 23.502 4.2.2.2 Registration Procedure. In S206, authentication function 230 sends a response message to AMF30 including the authentication result (success / failure).

[0140] In case of not having a certificate because the message does not contain a trust certificate, or in case of having a trust certificate but wanting to obtain the latest certificate, S207-1 to S207-4 are executed in case of S202.

[0141] In S207-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.

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

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

[0144] In S208, AMF30 sends a trust evaluation request message containing the trust certificate to the trust evaluation function 60.

[0145] In S209, the trust evaluation function 60 performs a trust evaluation process for the user / UE20. In S210, the trust evaluation function 60 sends a response message to the AMF30, including the trust evaluation result (success / failure).

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

[0147] In S211, 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, S211-1 to S211-6 are executed.

[0148] In S211-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.

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

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

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

[0152] (Implementation method c)

[0153] Next, refer to Figure 10 The timing diagram shown illustrates implementation method c. Implementation method c is the implementation method of "adding trust evaluation processing to the authentication function + jointly implementing authentication and trust evaluation". It is envisioned that implementation method c is implemented with a system architecture example A or C. The premise of the processing is the same as that of implementation methods a and b.

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

[0155] In S302, 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.

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

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

[0158] In S303, (R)AN10 forwards the NW connection request message to AMF30. In S304, AMF30 sends an authentication / trust evaluation request message, including a trusted certificate, to authentication function 230. In S305, authentication function 230 performs authentication processing. This authentication processing is equivalent to step 9 of 3GPP TS 23.502 4.2.2.2 Registration Procedure.

[0159] In S306, authentication function 230 performs trust evaluation processing for user / UE20.

[0160] In S307, authentication function 230 sends a response message to AMF30 including the authentication result (success / failure) and trust evaluation result (success / failure). On the authentication function 230 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.

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

[0162] In S308, 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, S308-1 to S308-6 are executed.

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

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

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

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

[0167] (User / UE trust evaluation processing)

[0168] Next, as a common process in implementation methods a to c, refer to... Figure 11 This section provides a specific example of user / UE trust evaluation processing in NW.

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

[0170] When the trust evaluation process based on the trusted certificate begins, in S1, the trust evaluation function 60 / authentication function 230 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 60 / authentication function 230 with these public keys.

[0171] In S3, the trust evaluation function 60 / authentication function 230 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.

[0172] Additionally, communication between the Trust Evaluation Function 60 / Authentication Function 230 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.

[0173] More specifically regarding S1 to S3, in S1 and S2, the trust evaluation function 60 / authentication function 230 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 60 / authentication function 230 verifies the signature of the VP's source user, the signature of the VP's source UE, and the VC's Issuer signature based on the signature of the private key associated with the corresponding public key (the legitimacy of the signature and the absence of message tampering).

[0174] In S4, the trust evaluation function 60 / authentication function 230 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 60 / authentication function 230 verifies the certificate's validity.

[0175] More specifically regarding S4 to S6, the trust evaluation function 60 / authentication function 230 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 60 / authentication function 230 obtains the VC's validity / invalidity information from the VDR70 and verifies the validity of the received VC.

[0176] In S7, the trust evaluation function 60 / authentication function 230 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 60 / authentication function 230 performs a certificate conformity verification. More specifically, the trust evaluation function 60 / authentication function 230 verifies that the content of the certificate satisfies the trust evaluation policy in the NW.

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

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

[0179] • 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.

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

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

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

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

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

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

[0186] (NW Trust Evaluation Processing)

[0187] Next, as a common process in implementation methods a to c, refer to... Figure 12 This section provides a specific example of NW trust evaluation processing in the UE.

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

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

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

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

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

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

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

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

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

[0197] • 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.

[0198] • 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.

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

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

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

[0202] (Supplementary matters)

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

[0204] (1) During processing, UE20 utilizes other available NWs to access policies for VDR and trust evaluation.

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

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

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

[0208] (Device structure)

[0209] Next, the functional structure of the "trust evaluation function 60, authentication function 230, 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 60, authentication function 230, and AMF30 will be collectively referred to as "network node 100".

[0210] <Network Node 100>

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

[0212] like Figure 13 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 13 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.

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

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

[0215] Terminal 20

[0216] Figure 14 This is a diagram illustrating an example of the functional structure of terminal 20. For example... Figure 14 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.

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

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

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

[0220] (Hardware structure)

[0221] The block diagram used in the description of the above embodiments ( Figure 13 and Figure 14 The 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.

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

[0223] 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 15 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.

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

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

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

[0227] 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 13 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 14 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.

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

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

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

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

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

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

[0234] Figure 16 An example of the structure of vehicle 2001 is shown. For example... Figure 16 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.

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

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

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

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

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

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

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

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

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

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

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

[0246] <Postscript>

[0247] (Note 1)

[0248] 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 trust evaluation processing using the aforementioned trust certificate; and The sending unit sends the trust evaluation result to the specific network node.

[0249] (Note 2)

[0250] According to the network nodes described in Note 1, wherein, The control unit performs the authentication process and the trust evaluation process. The sending unit sends the authentication result and the trust evaluation result to the specific network node, or... If both the authentication result and the trust evaluation result are successful, the sending unit sends a success message to the specific network node.

[0251] (Note 3)

[0252] A terminal having: The receiving unit receives messages containing the network's trust certificates from specific network nodes; 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.

[0253] (Note 4)

[0254] In the terminal described in Note 3 If the network side successfully evaluates the trust of the terminal or user, the receiving unit receives the message containing the trust certificate.

[0255] (Note 5)

[0256] A communication method, executed by a network node, comprises the following steps: Receive 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 the message containing the trust certificate from the terminal; Perform trust evaluation processing using the trusted certificate; and Send the trust evaluation result to the specific network node.

[0257] (Note 6)

[0258] A communication method, executed by a terminal, comprises the following steps: Receive a message containing the network's trust certificate 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.

[0259] According to any one of Appendix 1 to Appendix 6, a technique for performing highly reliable trust verification in the NW or terminal is provided. According to Appendix 2, control using both authentication results and trust evaluation results is possible. According to Appendix 3, trust evaluation in the UE based on trust evaluation in the NW is possible.

[0260] (Supplement to the implementation method)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0295] Label Explanation

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

[0297] 20: Terminal (UE)

[0298] 21: NW connectivity function

[0299] 22, 60: Trust Evaluation Function

[0300] 30: AMF

[0301] 40, 240: UDM

[0302] 41: NW Information DB

[0303] 42: Trusted Certificate DB

[0304] 43: Strategy DB

[0305] 70: VDR

[0306] 71: User Information DB

[0307] 72: Issuer Information DB

[0308] 73: Define Information DB

[0309] 74: Management Information DB

[0310] 80: AUSF

[0311] 100: Network Node

[0312] 110: Sending Department

[0313] 120: Receiving Department

[0314] 130: Setting Department

[0315] 140: Control Department

[0316] 230: Authentication Function

[0317] 310: Sending Department

[0318] 320: Receiving Department

[0319] 330: Setting Department

[0320] 340: Control Department

[0321] 1001: Processor

[0322] 1002: Storage device

[0323] 1003: Auxiliary storage device

[0324] 1004: Communication device

[0325] 1005: Input device

[0326] 1006: Output device

Claims

1. 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 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, The control unit performs the authentication process and the trust evaluation process. The sending unit sends the authentication result and the trust evaluation result to the specific network node, or... If both the authentication result and the trust evaluation result are successful, the sending unit sends a success message to the specific network node.

3. A terminal having: The receiving unit receives messages containing the network's trust certificates from specific network nodes; 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.

4. The terminal according to claim 3, wherein, If the network side successfully evaluates the trust of the terminal or user, the receiving unit receives the message containing the trust certificate.

5. A communication method, performed by a network node, comprising the following steps: Receive a trust evaluation request message containing the trusted certificate of the terminal or user from a specific network node, wherein... The specific network node receives a message containing the trust certificate from the terminal; 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: Receive a message containing the network's trust certificate 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.

Images