Self-managed trust in internet of things networks

Abstract

Apparatuses, methods, and computer-readable media for facilitating self-managed trust in Internet of Things networks are disclosed herein. An example method of trust management at a network manager includes registering a network endpoint with a network managed by the network manager. The example method also includes receiving trusted reference information for the network endpoint based on the registered network endpoint. Additionally, the example method includes performing verification of the network endpoint based on at least one of attestation received from the network endpoint or the trusted reference information. Moreover, the example method includes enforcing a policy on the network endpoint based on a result of the verification. Such trust management can improve privacy and security at the network, as well as reduce latency in responding to trust events.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 072,031, filed August 28, 2020, entitled “Self-Managed Trust in Internet of Things Networks”; U.S. Provisional Application No. 63 / 072,040, filed August 28, 2020, entitled “Methods and Appraisals to Facilitate Surrogate-Based Access Management Using Testation Results”; and U.S. Patent Application No. 17 / 458,012, filed August 26, 2021, entitled “Self-Managed Trust in Internet of Things Networks”, all of which are expressly incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to communication systems, and more specifically to communication systems including trust management and / or access management. Background Technology

[0004] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone communication, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0005] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol enabling different wireless devices to communicate at the municipal, national, regional, and even global levels. An example of a telecommunications standard is 5G New Radio (NR). 5G NR is part of the Continuous Mobile Broadband Evolution program promulgated by the 3rd Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with the Internet of Things (IoT)), and others. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC). Some aspects of 5G NR can be based on the 4G Long Term Evolution (LTE) standard. There is a need for further improvements to 5G NR technology. These improvements can also be applied to other multiple access technologies and telecommunications standards that adopt them. Summary of the Invention

[0006] The following is a brief overview of one or more aspects to provide a basic understanding of them. This overview is not a comprehensive review of all anticipated aspects, and it is intended neither to identify key or essential elements of all aspects, nor to depict the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a concise form as an introduction to the more detailed descriptions that follow.

[0007] In this disclosure, a method, computer-readable medium, and apparatus for trust management at a network manager are provided. An example apparatus registers a network endpoint with a network managed by a network manager. The example apparatus also receives trusted reference information for the network endpoint based on the registered network endpoint. Furthermore, the example apparatus performs verification of the network endpoint based on at least one of trusted reference information received from one or more trusted third parties or a certificate received from the network endpoint. The example apparatus also implements policies on the network endpoint based on the verification results.

[0008] In another aspect of this disclosure, a method, computer-readable medium, and apparatus for trust management at a network endpoint are provided. An example apparatus provides a temporary credential for the network endpoint to a network manager. In some examples, the temporary credential may be based on a permanent credential for the network endpoint. Additionally, the example apparatus receives access or authorization for a service or resource from the network manager. In some examples, the access or authorization may be based on device verification based on the temporary credential for the network endpoint.

[0009] In another aspect of this disclosure, a method, computer-readable medium, and apparatus for trust management at a network manager are provided. An example apparatus registers a network endpoint with a network managed by a network manager. The example apparatus also receives trusted reference information for the network endpoint based on the registered network endpoint. Additionally, the example apparatus queries device information from the network endpoint according to a network manager policy implemented by the network manager. When a trust event occurs, the example apparatus also performs one or more trust event remediation measures according to a network manager policy, the occurrence of which is based on a comparison of the device information and the trusted reference information for the network endpoint.

[0010] In this disclosure, a method, computer-readable medium, and apparatus for access management of a trusted broker are provided. An example apparatus receives authentication information from a device requesting access to a service or resource provided by a service management entity. The example apparatus also evaluates the authentication information for the device based on an updatable policy. Furthermore, based on the evaluation of the authentication information, the example apparatus implements an updatable policy on the device for the service or resource provided by the service management entity.

[0011] In another aspect of this disclosure, a method, computer-readable medium, and apparatus for access management at a device are provided. When access to a service or resource provided by a service management entity is requested, an example apparatus provides authentication information associated with the device to a trust agent. Additionally, the example apparatus receives access to the service or resource provided by the service management entity from the trust agent based on an evaluation of the authentication information regarding an updatable policy.

[0012] To achieve the foregoing and related objectives, one or more aspects include the features fully described below and specifically pointed out in the claims. The following description and drawings set forth certain illustrative features of one or more aspects in detail. However, these features indicate only a few of the various ways in which the principles of the various aspects may be employed, and this description is intended to include all such aspects and their equivalents. Attached Figure Description

[0013] Figure 1 This is a diagram illustrating an example of a wireless communication system and access network.

[0014] Figure 2 This is a self-generating example communication system for electronic identifiers (eIDs) based on the teachings disclosed herein.

[0015] Figure 3 This is a diagram illustrating examples of a first wireless device and a second wireless device in an access network according to the teachings disclosed herein.

[0016] Figure 4 This is an example communication flow for identity registration of a self-generated eID, based on the teachings disclosed in this article.

[0017] Figure 5 This is an example communication system for eID registration based on the teachings disclosed herein.

[0018] Figure 6 This is a diagram illustrating an example eID registration environment based on the teachings disclosed herein.

[0019] Figure 7A An example communication flow is shown for a first example model that facilitates remote proofs between provers, dependents, and verifiers in accordance with the teachings disclosed herein.

[0020] Figure 7B An example communication flow is shown for a second example model that facilitates remote proofs between provers, dependents, and verifiers in accordance with the teachings disclosed herein.

[0021] Figure 7C An example communication flow is shown for a third example model that facilitates remote proofs among a prover, a first dependent party, a second dependent party, and a verifier, in accordance with the teachings disclosed herein.

[0022] Figure 8 An example information exchange between a network, a network health manager, and a remote third party is shown in accordance with the teachings disclosed herein.

[0023] Figure 9 An example communication flow between a device, a network health manager, and a trusted third party, as disclosed in this document, is shown.

[0024] Figure 10 An example information exchange is shown in a self-managed virtual radio access network (vRAN) trusted environment comprising UE, base node, edge node and IoT framework, in accordance with the teachings disclosed herein.

[0025] Figure 11 An example self-managed, highly guaranteed IoT network, including users, devices, network health managers, trusted third parties, and edge nodes, is described in accordance with the teachings disclosed herein.

[0026] Figure 12 An example communication flow between a device, a network health manager, and a trusted third party, as disclosed in this document, is shown.

[0027] Figure 13 An example information exchange between a device, a service management entity, and an agent of the service management entity, as disclosed herein, is shown.

[0028] Figure 14 An example communication flow between a device, a service management entity, a proxy of the service management entity, and a third-party authentication entity, as disclosed in this document, is shown.

[0029] Figure 15 This is a flowchart of a method for performing device verification at a first device in accordance with the teachings disclosed herein.

[0030] Figure 16 This is a flowchart of a method for performing device verification at a first device in accordance with the teachings disclosed herein.

[0031] Figure 17 This is a flowchart of a method for performing device verification at a first device in accordance with the teachings disclosed herein.

[0032] Figure 18 This is a flowchart of the method for verifying equipment at the device location based on the teachings disclosed herein.

[0033] Figure 19 This is a flowchart of the method for verifying equipment at the device location based on the teachings disclosed herein.

[0034] Figure 20 This is a flowchart of a method for performing device verification at a first device in accordance with the teachings disclosed herein.

[0035] Figure 21 This is a diagram illustrating an example hardware implementation of an example device based on the teachings disclosed herein.

[0036] Figure 22 This is a flowchart of a method for performing access management at a first device in accordance with the teachings disclosed herein.

[0037] Figure 23 This is a flowchart of a method for performing access management at a first device in accordance with the teachings disclosed herein.

[0038] Figure 24 This is a flowchart of the method for access management at the device location based on the teachings disclosed herein.

[0039] Figure 25 This is a flowchart of the method for access management at the device location based on the teachings disclosed herein.

[0040] Figure 26 This is a diagram illustrating an example hardware implementation of an example device based on the teachings disclosed herein. Detailed Implementation

[0041] The aspects presented herein provide a system that enables devices (e.g., user equipment, UE, network endpoints, etc.) to access services or devices based on identity information and / or credentials associated with the device. Some of the aspects presented herein can be implemented via wireless communication systems.

[0042] In remote attestation, a dependent party (e.g., a service provider) may require evidence generated by a remote peer entity (e.g., a device or person) to assess the credibility of that remote peer entity. Generally, credibility refers to the quality assessed via evidence. For example, based on the type of evidence generated by the remote peer entity, the dependent party may be able to determine whether the remote peer entity is the entity they claim to be and / or whether they trust the remote peer entity. In some examples, performing remote attestation involves a verifier who evaluates the evidence generated by the remote peer entity via an evaluation strategy and creates an attestation result to support the dependent party's decision.

[0043] For example, a network such as an IoT network may include one or more network endpoints that access services (e.g., wireless communication, internet access, messaging, networking, etc.) provided by a service provider (e.g., gateways, routers, access points, base stations, etc.). To protect the integrity of the network, the service provider may utilize a remote attestation process to determine whether one or more devices are qualified to access the network. For example, the service provider may request a device to provide information about itself (e.g., evidence), which the service provider can use to determine the trustworthiness of the device. A verifier (e.g., a trusted third party, such as the device manufacturer) may evaluate the evidence (e.g., using an evaluation strategy) to create an attestation result that supports the service provider in determining the trustworthiness of the network endpoint (e.g., IoT devices, etc.). In some examples, the network endpoint may send the evidence to the verifier. In some examples, the network endpoint may send the evidence to the service provider, which then forwards the evidence to the verifier.

[0044] However, it is understandable that in some examples, performing remote proofs may raise privacy, administrative, and / or scalability issues. For example, each time a remote proof is performed, information (e.g., evidence) is sent from a network (e.g., a network provided by a service provider) to the verifier via a remote network (e.g., an IoT framework) to facilitate the management of the network endpoint.

[0045] The example techniques disclosed herein utilize agent devices located within a network to facilitate self-managed trust for the network (e.g., an IoT network). For example, the disclosed techniques can facilitate reduced information transmission from the network to remote networks (e.g., an IoT framework) by configuring a network health manager (e.g., an agent device) to manage the health and trust of network endpoints connected to the network. The network health manager can assume the role of a validator by utilizing information provided by one or more trusted third parties. Therefore, the network health manager can operate as both a service provider and a validator, limiting the information transmitted from the network to remote networks.

[0046] The aspects presented herein provide a system that enables network endpoints to access services or devices based on identity information and / or credentials associated with the network endpoint. Some of the aspects presented herein can be implemented via wireless communication systems.

[0047] As used herein, the term "trusted third party" is not limited to the entity that creates the network endpoint (e.g., the maker of the network endpoint) and may include any entity that provides one or more resources or services for the operation of the network endpoint, as presented herein. For example, a trusted third party may include the maker of the network endpoint, a cloud-based device management service (e.g., an IoT framework), an entity that hosts policies for enforcement against the network endpoint (e.g., a web server), an entity that hosts device authentication information (e.g., a web server), an entity configured to perform device authentication associated with the network endpoint, and so on.

[0048] In some examples, service access may be based on verifying information about an entity. For instance, before granting access to a device (e.g., user equipment, UE, network endpoint, etc.), the service management entity may verify that the device is trustworthy. However, in some examples, access to a service may be based on verifying various information about the service access entity (e.g., the device). In some such examples, the service management entity may verify various information about the device via one or more verification entities.

[0049] The example techniques disclosed herein utilize proxy devices to manage access to services provided by a service management entity. For example, the disclosed techniques can configure a device to operate as a proxy for a service management entity and manage access to services based on multiple provable parameters. In some examples, the proxy can facilitate the verification of provable information about the device corresponding to the provable parameters. The example proxy can then assess a trust score for the device based on the corresponding verification results and enforce policies on the device based on the trust score.

[0050] The detailed description that follows, taken in conjunction with the accompanying drawings, is intended as a description of various configurations, and not as representing the only configuration in which the concepts described herein can be practiced. To provide a thorough understanding of the various concepts, the detailed description includes specific details. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring these concepts.

[0051] Various apparatuses and methods will now be used to present several aspects of a telecommunications system. These apparatuses and methods will be described in detail below and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively, “elements”). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether these elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0052] For example, an element, any part of an element, or any combination of elements can be implemented as a "processing system" including one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this disclosure. One or more processors in a processing system can execute software. Software should be interpreted broadly as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or others.

[0053] Therefore, in one or more example aspects, the described functionality can be implemented in hardware, software, or any combination thereof. If implemented in software, these functions can be stored on a computer-readable medium or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media. Storage media can be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media can include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of computer-readable media types, or any other medium that can be used to store computer-executable code in the form of instructions or data structures that can be accessed by a computer.

[0054] While aspects and implementations are described herein by way of example, those skilled in the art will understand that additional implementations and use cases can arise in many different arrangements and scenarios. The innovations described herein can be implemented across many different platform types, devices, systems, shapes, sizes, and package arrangements. For example, implementations and / or uses can be achieved through integrated chip implementations and other non-modular component-based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial devices, retail / purchasing devices, medical devices, artificial intelligence (AI) enabled devices, etc.). While some examples may or may not be specific to a particular use case or application, a wide range of applicability to the described innovations is possible. The range of implementations can extend from chip-level or modular components to non-modular, non-chip-level implementations, and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more aspects of the described innovations. In some practical settings, devices incorporating the described aspects and features may also include additional components and features for implementing and practicing the claimed and described aspects. For example, the transmission and reception of wireless signals necessarily involve numerous components for analog and digital purposes (e.g., hardware components including antennas, RF chains, power amplifiers, modulators, buffers, processors (multiple), interleavers, adders / summers, etc.). The intention is that the innovations described herein can be implemented in a variety of devices, chip-level components, systems, distributed arrangements, aggregated or decomposed components, end-user equipment, etc., of various sizes, shapes, and structures.

[0055] Figure 1 This diagram illustrates an example of a wireless communication system and access network 100 including base stations 102, 180, and UE 104. The example of the wireless communication system (also known as a wireless wide area network (WWAN)) includes base station 102, UE 104, an evolved packet core (EPC) (e.g., EPC 160), and another core network 190 (e.g., a 5G core (5GC)). Base station 102 may include macro cells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Macro cells include base stations. Cells may include femtocells, picocells, and microcells.

[0056] Base station 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with EPC 160 via backhaul link 132 (e.g., S1 interface). Base station 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN)) can interface with core network 190 via second backhaul link 184. Among other functions, base station 102 can perform one or more of the following functions: transmission of user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), subscriber and device tracking, RAN information management (RIM), paging, location, and warning message delivery. Base station 102 can communicate directly or indirectly with each other (e.g., via EPC 160 or core network 190) via third backhaul link 134 (e.g., X2 interface). First backhaul link 132, second backhaul link 184 and third backhaul link 134 can be wired or wireless.

[0057] Base station 102 can wirelessly communicate with UE 104. Each of base stations 102 can provide communication coverage for its respective geographic coverage area. Overlapping geographic coverage areas may exist. For example, small cell 102' may have a coverage area 110' that overlaps with the geographic coverage areas 110 of one or more macro base stations. A network that includes both small cells and macro cells can be referred to as a heterogeneous network. Heterogeneous networks may also include evolved home B (eNB) (HeNB), which can provide services to restricted groups called closed subscriber groups (CSGs). The communication link 120 between base station 102 and UE 104 may include uplink (UL) (also known as reverse link) transmission from UE to base station or downlink (DL) (also known as forward link) transmission from base station to UE. Communication link 120 may use multiple-input multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may use one or more carriers. Base station 102 / UE 104 can use spectrum with a bandwidth of up to Y MHz (e.g., 5, 10, 15, 20, 100, 400, etc.) per carrier allocated in carrier aggregation for a total of up to Y x MHz (x component carriers) for transmission in each direction. Carriers may be adjacent to each other or not. Carrier allocation may be asymmetrical relative to DL and UL (e.g., more or fewer carriers may be allocated to DL than to UL). Component carriers may include primary component carriers and one or more secondary component carriers. The primary component carrier may be referred to as the primary cell (PCell), and the secondary component carriers may be referred to as secondary cells (SCells).

[0058] In some scenarios, one or more UEs 104 can communicate with each other using a device-to-device (D2D) communication link such as D2D communication link 158. D2D communication link 158 can use DL / UL WWAN spectrum. D2D communication link 158 can use one or more sidelink channels, such as the Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Shared Channel (PSSCH), and Physical Sidelink Control Channel (PSCCH). D2D communication can be conducted through various wireless D2D communication systems, such as, for example, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0059] The wireless communication system may also include a Wi-Fi access point (AP) 150 communicating with a Wi-Fi station (e.g., STA 152) via a communication link 154, for example, in an unlicensed 5 GHz spectrum. When communicating in an unlicensed spectrum, the STA 152 / AP 150 may perform a free channel assessment (CCA) before communication to determine whether the channel is available.

[0060] Cell 102' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, cell 102' can employ NR and use the same unlicensed spectrum (e.g., 5 GHz, etc.) as the Wi-Fi AP 150. Employing NR in unlicensed spectrum can enhance coverage of the access network and / or increase its capacity.

[0061] The electromagnetic spectrum is typically subdivided into different categories, bands, channels, etc., based on frequency / wavelength. In 5G NR, the two initial operating bands have been designated as frequency range names FR1 (410MHz-7.125GHz) and FR2 (24.25GHz-52.6GHz). Although a portion of FR1 is greater than 6GHz, in various documents and articles, FR1 is often (interchangeably) referred to as the "sub-6GHz" band. Similar naming issues sometimes arise regarding FR2; although different from the Extremely High Frequency (EHF) band (30GHz-300GHz) designated as the "millimeter wave" band by the International Telecommunication Union (ITU), FR2 is often (interchangeably) referred to as the "millimeter wave" band in documents and articles.

[0062] The frequencies between FR1 and FR2 are generally referred to as intermediate frequency (IF) frequencies. Recent 5G NR research has designated the operating bands of these IF frequencies as the frequency range name FR3 (7.125GHz-24.25GHz). Bands falling within FR3 can inherit FR1 and / or FR2 characteristics, thus effectively extending the characteristics of FR1 and / or FR2 to the IF frequencies. Furthermore, higher frequency bands are currently being explored to extend 5G NR operation above 52.6GHz. For example, three higher operating frequency bands have been designated as the frequency range names FR4a or FR4-1 (52.6GHz-71GHz), FR4 (52.6GHz-114.25GHz), and FR5 (114.25GHz-300GHz). Each of these higher frequency bands falls within the EHF band.

[0063] In light of the foregoing, unless otherwise specified, it should be understood that the use of terms such as "below 6 GHz" herein can broadly refer to frequencies that may be less than 6 GHz, may be within FR1, or may include mid-band frequencies. Furthermore, unless otherwise specified, it should be understood that the use of terms such as "millimeter wave" herein can broadly refer to frequencies that may include mid-band frequencies, may be within FR2, FR4, FR4-a, or FR4-1 and / or FR5, or may be within the EHF band.

[0064] Base stations, whether small cell 102' or large cell (e.g., macro base stations), may include and / or be referred to as eNBs, gNodeBs (gNBs), or other types of base stations. Some base stations, such as base station 180 (e.g., gNB), may communicate with UE 104 in conventional sub-6 GHz spectrum, millimeter wave frequencies, and / or near-millimeter wave frequencies. When base station 180 operates in millimeter wave or near-millimeter wave frequencies, base station 180 (e.g., gNB) may be referred to as a millimeter wave base station. The millimeter wave base station may utilize beamforming 182 with UE 104 to compensate for path loss and short range. Base station 180 and UE 104 may each include multiple antennas, such as antenna elements, antenna panels, and / or antenna arrays, to facilitate beamforming.

[0065] Base station 180 may transmit beamforming signals to UE 104 in one or more transmit directions 182'. UE 104 may receive beamforming signals from base station 180 in one or more receive directions 182'. UE 104 may also transmit beamforming signals to base station 180 in one or more transmit directions. Base station 180 may receive beamforming signals from UE 104 in one or more receive directions. Base station 180 / UE 104 may perform beamforming training to determine the optimal receive and transmit directions for each of base station 180 / UE 104. The transmit and receive directions of base station 180 may be the same or different. The transmit and receive directions of UE 104 may be the same or different.

[0066] EPC 160 may include a Mobility Management Entity (MME) (e.g., MME 162), other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway (e.g., PDN Gateway 172). MME 162 may communicate with a Home Subscriber Server (HSS) (e.g., HSS 174). MME 162 is the control node that handles signaling between UE 104 and EPC 160. Typically, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are transmitted through Serving Gateway 166, which is itself connected to PDN Gateway 172. PDN Gateway 172 provides UE IP address allocation and other functions. PDN Gateway 172 and BM-SC 170 are connected to IP Service 176. IP service 176 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming service, and / or other IP services. BM-SC 170 can provide functionality for MBMS user service provisioning and delivery. BM-SC 170 can act as an entry point for content provider MBMS transmissions, can be used to authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and can be used to schedule MBMS transmissions. MBMS gateway 168 can be used to distribute MBMS services to base station 102 belonging to a Broadcast-Specific Service Multicast Single Frequency Network (MBSFN) area, and can be responsible for session management (start / stop) and collection of eMBMS-related billing information.

[0067] Core network 190 may include Access and Mobility Management Functions (AMF) (e.g., AMF 192), other AMFs 193, Session Management Functions (SMF) 194, and User Plane Functions (UPF) (e.g., UPF 195). AMF 192 may communicate with Unified Data Management (UDM) (e.g., UDM 196). AMF 192 is the control node that handles signaling between UE 104 and core network 190. Typically, AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are transmitted through UPF 195. UPF 195 provides UE IP address allocation and other functions. UPF 195 connects to IP service 197. IP service 197 may include the Internet, intranet, IP Multimedia Subsystem (IMS), Packet Switched (PS) Streaming (PSS) service, and / or other IP services.

[0068] Base stations may include and / or be referred to as gNB, Node B, eNB, access point, base transceiver, radio base station, radio transceiver, transceiver function, Basic Services Set (BSS), Extended Services Set (ESS), Transmitter Receiver Point (TRP), or any other suitable term. Base station 102 provides UE 104 with access to EPC 160 or core network 190. Examples of UE 104 include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablet computers, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, medical devices, implants, sensors / actuators, displays, or any other similarly functional devices. Some of UE 104 may be referred to as IoT devices (e.g., parking timers, air pumps, toasters, vehicles, heart monitors, etc.). UE 104 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, radio unit, remote unit, mobile device, radio device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, radio terminal, remote terminal, handheld device, user agent, mobile client, client, or any other suitable term. In some scenarios, the term UE may also apply to one or more companion devices, such as in a device constellation arrangement. One or more of these devices may jointly access the network and / or individually access the network.

[0069] like Figure 1 As shown, the communication system and access network 100 may include one or more devices (e.g., user equipment, UE, network endpoint, etc.) that enable access to services or devices based on an identity or credentials associated with user equipment 103. In some examples, user equipment 103 may be UE 104. In some examples, the user and / or user equipment 103 may register user equipment 103 with registration system 198. Registration system 198 may generate an electronic identifier (eID) and provide the eID to an identity management (IDM) system (e.g., IDM system 199). User equipment 103 may then perform device authentication, feature activation, credential provisioning, access to services, etc., via the IDM system.

[0070] Identity and associated credentials are a crucial aspect of the electronic transaction ecosystem. Different identifier (ID) types have different requirements. For example, to obtain a government-issued ID, an individual may provide or present proof of birth, Social Security number, proof of residence, fingerprints, and other items. For a bank ID, an individual may provide a government-issued ID, Social Security number, proof of residence or address, and other items. For a payment system ID, an individual or entity may provide or present proof of bank account, credit card number, contact number (such as a telephone or mobile phone number), and other items. To obtain an insurance ID, an individual may provide or present a government-issued ID, Social Security number, etc. For a health record ID, an individual may provide or present a government-issued ID, Social Security number, etc. Obtaining each of these IDs involves a registration phase, in which an individual provides proof of one or more identifiers to obtain a specific ID. The registration process for various IDs can involve decentralized and time-consuming procedures. Different types of IDs may require different security items / proof of identity. Although common items for security / proof of identity may exist between different systems, these items / proofs are not shared. In many examples, human presence is required to establish an ID, such as for extracting biometric information. Other IDs may not include such requirements. IDs may not be interoperable between systems. This lack of interoperability could be due to security, privacy, compatibility, etc. The aspects presented in this paper enable mobile systems to merge ID information and procedures using mobile user devices. Mobile devices and their security features (e.g., hardware-based root of trust) can provide a central aspect of electronic transaction systems.

[0071] The aspects presented in this paper provide a general framework for enabling users and / or user devices to access services and / or devices based on various types of identities and credentials. Different levels of security can be provided for different levels of access. Levels can be defined based on policies or the sensitivity level of the service being accessed. Services can, for example, determine the access level allowed to a user device based on a certificate associated with the user device. Functional elements and technologies to enhance security, such as enhanced authentication (e.g., liveness testing, continuous authentication), access / admission control, or credential management and protection, can be provided within the user device. Elements and technologies can also be provided at the cloud level.

[0072] The aspects presented in this article enable user devices to act as trusted devices providing more secure gatekeepers for accessing services. User devices can be used to provide information enabling access to services such as healthcare, government, and finance. Different levels of trust can be provided based on specific user device capabilities. User devices can complement traditional systems to provide additional types of secure access to services.

[0073] Trust in a device can be based on hardware security aspects (e.g., authentication at T=0). Such hardware security aspects can include tamper protection, tamper protection, side-channel protection, isolated execution, hardware encryption modules, and authentication (e.g., Common Standard Evaluation Assurance Level (CC EAL)).

[0074] Trust in a device can also be based on device proof (i.e., when T>0), such as measurements and reports of device state (e.g., device software, firmware, operating system, applications, user authentication results, the current location of the user device, one or more hardware states, etc.) using a device key.

[0075] The aspects presented in this article provide secure provisioning and storage of encryption keys / credentials. Keys or credentials may include device keys, user biometric credentials (e.g., fingerprints, Face ID, iris scans, etc.), application keys / access tokens, and / or trust lists (e.g., with trusted certificates).

[0076] An example of eID is a mobile driving license. Driving licenses can be used to provide proof of driving privileges, verify age, prove name, and enter airport security checkpoints. While a simple image of a driver's license may not be trustworthy in itself, mechanisms can be provided at the user's device to obtain credible data from the mobile driving license associated with that device. For example, the data could be obtained under the control of the mobile driving license holder, allowing a verifier to assess the validity of the data (e.g., the user identity or information provided in the mobile driving license) and generate a proof indicating whether the verifier can vouch for the data and the mobile driving license. For instance, the official issuing the mobile driving license could electronically sign the data and ensure it is provided to the appropriate device.

[0077] A system for eID can include various participants. For example, participants can include devices (e.g., user equipment, UE, network endpoints, etc.). In some examples, the device can be UE 104, such as... Figure 1 As shown. Examples of user equipment include, for example, wearable devices, sensors, IoT devices, smartphones, and V2X devices. User equipment can create and store user IDs and credentials locally. User equipment can register user IDs and credentials with an identity management (IDM) system. User equipment can be used by one or more owners / users. User equipment can provide a root of trust for cryptographic operations, credentials, and device proof (e.g., measurement and reporting of device status).

[0078] Another participant in the eID system can be the device owner. The device owner can control the access mode (on or off) of user devices and user groups (for off access mode). In some examples, the device owner may be different from the device user. The device owner can remotely control the user device. For example, it is possible to manage (multiple) user devices and / or execute transactions without the device owner's presence.

[0079] Another participant in the eID system can be the device user (e.g., the eID holder). In some examples, the device user can be different from the device owner.

[0080] Another participant in an eID system can be an IDM system. An IDM system can manage user identities and credentials, authenticate users and authorize users to access associated resources, and / or protect IDs, credentials, and transactions (e.g., immutable records).

[0081] Another participant in the eID system can be a service accessed by the user's device. The service can use the eID system to verify the user's identity. The service can obtain authorized access to user information through the IDM (Internet Management Provider).

[0082] ID types that can be associated with the eID system can include certificate IDs, email addresses, phone numbers, permanent IDs, pseudonyms, and authentication IDs (such as social security numbers, driver's license numbers, etc.).

[0083] Examples of credential types used in an eID system can include public-private key pairs, certificates, tokens, biometric information, passwords, or personal identification numbers (PINs). ID cards can include a digital ID containing user information such as ID number, legal name, date of birth, photograph, issuer, issue / expiration date, and issuer eID. Biometric information can include facial ID, fingerprints, iris biometrics, etc. Biometric templates can include feature extraction. Biometric information can be transformed (e.g., encrypted) to maintain privacy. Credentials can be linked to additional resources for the user, such as device security information (e.g., at the EAL level or tamper-proof), service contracts signed by service providers, etc.

[0084] An eID system can include ID-to-credential relationships. For example, each credential can be associated with a unique ID. Each credential can be associated with or include a set of resources (e.g., Social Security number, legal name, date of birth, age, etc.). New credentials can be created using existing credentials and subsets of resources. Resources exposed to the service can be controlled by the user. Multiple IDs can be associated with a single credential. For example, a user can associate additional IDs with credentials, i.e., multiple roles, without registering multiple credentials. Each ID can be associated with multiple credentials (e.g., for multi-factor authentication (MFA)). The credentials to be used can be determined based on service requirements.

[0085] Table 1 below shows examples of registration types and sample attributes associated with self-generated eIDs and certified eIDs.

[0086]

[0087]

[0088] Figure 2 An example system 200 for identity registration using a self-generated eID is illustrated. As shown, user equipment 202 can generate a self-generated credential 204 and can have a device credential 206. User equipment 202 can send the self-generated credential 204 to IDM system 208 during credential registration. IDM system 208 can perform device authentication using verification system 210, for example, to obtain proof of the current device state to enable feature activation of the user equipment, credential provisioning of the user equipment, etc. Figure 2 Each step shown may include proof. For example, there may be user proof for user equipment 202 (e.g., between the user and user equipment 202), device proof for IDM system 208 (e.g., between user equipment 202 and IDM system 208) and / or device proof for authentication system 210 (e.g., between IDM system 208 and authentication system 210), connection proof for IDM system 208 (e.g., between user equipment 202 and IDM system 208) and / or connection proof for authentication system 210 (e.g., between IDM system 208 and authentication system 210).

[0089] In some examples, user equipment 202 may be a mobile device that exchanges wireless messages with IDM system 208 or other systems as part of registration, authentication, etc.

[0090] Figure 3This is a block diagram illustrating an example of a first wireless device configured to exchange wireless communications with a second wireless device. In the illustrated example, the first wireless device may include a base station 310, the second wireless device may include a UE 350, and the base station 310 may communicate with the UE 350 in an access network. The UE 350 may communicate via the base station 310 with, for example,... Figure 1 The registration system 198 and / or such as Figure 1 The IDM system 199 refers to the devices (e.g., user equipment, network endpoints, etc.) that exchange messages within the IDM system. Figure 3 As shown, base station 310 includes a transmit processor (TX processor 316), a transceiver 318 including transmitter 318a and receiver 318b, an antenna 320, a receive processor (RX processor 370), a channel estimator 374, a controller / processor 375, and a memory 376. Example UE 350 includes an antenna 352, a transceiver 354 including transmitter 354a and receiver 354b, an RX processor 356, a channel estimator 358, a controller / processor 359, a memory 360, and a TX processor 368. In other examples, base station 310 and / or UE 350 may include additional or alternative components.

[0091] In the DL, IP packets from the EPC 160 can be provided to the controller / processor 375. The controller / processor 375 implements Layer 3 and Layer 2 functions. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Service Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. The controller / processor 375 provides RRC layer functions associated with broadcast system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), Radio Access Technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functions associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with upper-layer packet data unit (PDU) transmission, error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs to transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority processing, and logical channel priority.

[0092] The TX processor 316 and RX processor 370 implement Layer 1 functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error correction on the transport channel, forward error correction (FEC) decoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The TX processor 316 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The decoded and modulated symbols can then be split into parallel streams. Each stream can then be mapped to OFDM subcarriers, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domains, and then combined using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a stream of time-domain OFDM symbols. The OFDM streams are spatially precoded to produce multiple spatial streams. The channel estimate from channel estimator 374 can be used to determine the decoding and modulation scheme, as well as for spatial processing. The channel estimate can be derived from the reference signal transmitted by UE 350 and / or channel condition feedback. Each spatial stream can then be provided to a different antenna 320 via a separate transmitter 318a. Each transmitter 318a can modulate a radio frequency (RF) carrier with its respective spatial stream for transmission.

[0093] At UE 350, each receiver 354b receives signals through its respective antenna 352. Each receiver 354b recovers the information modulated onto the RF carrier and provides this information to the RX processor 356. The TX processor 368 and RX processor 356 implement Layer 1 functions associated with various signal processing functions. The RX processor 356 can perform spatial processing on the information to recover any spatial stream destined for UE 350. If multiple spatial streams are destined for UE 350, the RX processor 356 can combine them into a single OFDM symbol stream. The RX processor 356 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal consists of a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols and reference signals on each subcarrier are recovered and demodulated by determining the most probable signal constellation points transmitted by base station 310. These soft decisions can be based on channel estimates calculated by channel estimator 358. The soft decision is then decoded and deinterleaved to recover the data and control signals originally transmitted by base station 310 on the physical channel. The data and control signals are then provided to controller / processor 359.

[0094] The controller / processor 359 may be associated with a memory 360 that stores program code and data. The memory 360 may be referred to as a computer-readable medium. In the UL, the controller / processor 359 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets from the EPC 160. The controller / processor 359 is also responsible for error correction to support HARQ operation using ACK and / or NACK protocols.

[0095] Similar to the functions described in the DL transmission description of the base station 310, the controller / processor 359 provides RRC layer functions associated with system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functions associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions associated with upper-layer PDU transmission, error correction via ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs to TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority processing, and logical channel priority.

[0096] The TX processor 368 can use the channel estimate derived from the reference signal transmitted by the channel estimator 358 or feedback from the base station 310 to select an appropriate decoding and modulation scheme and facilitate spatial processing. The spatial stream generated by the TX processor 368 can be provided to different antennas 352 via separate transmitters 354a. Each transmitter 354a can modulate an RF carrier with its own spatial stream for transmission.

[0097] UL transmissions are processed at base station 310 in a manner similar to that described in conjunction with the receiver function at UE 350. Each receiver 318b receives signals via its respective antenna 320. Each receiver 318b recovers the information modulated onto the RF carrier and provides that information to RX processor 370.

[0098] The controller / processor 375 may be associated with a memory 376 that stores program code and data. The memory 376 may be referred to as a computer-readable medium. In the UL, the controller / processor 375 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets from the UE 350. IP packets from the controller / processor 375 can be provided to the EPC 160. The controller / processor 375 is also responsible for error correction using ACK and / or NACK protocols to support HARQ operation.

[0099] Figure 4 An example communication flow 400 for identity registration of a self-generated eID is shown, based on the teachings disclosed herein. For example, it can be generated by, for example... Figure 2 The eID system shown is used to perform eID registration. Figure 4 The communication flow 400 includes user 402, device 404, IDM system 406, and authentication system 408. A user authentication or verification process 403 can be performed between user 402 and device 404 to verify that user 402 is authorized to use device 404. Authentication or verification can be based on a password, personal identification number (PIN), biometric information, activity test, etc., entered or provided by user 402. Following user authentication (e.g., at authentication process 403), ID registration may be triggered, as shown at 405. For example, user 402 can trigger ID registration. The ID can be selected or generated by user 402 and / or device 404. In some examples, the ID may additionally or alternatively include credentials, such as a public-private key pair (e.g., a public key (pk) and a private key (or a secret key (sk))). Device 404 sends a credential registration request 407 received by IDM system 406. Credential registration request 407 includes a device ID for device 404. IDM system 406 sends a device verification request 409 received by verification system 408. Verification system 408 responds to device verification request 409 by sending a device proof request 411, which includes a nonce, received by IDM system 406. IDM system 406 sends a device proof request 413 with a nonce to device 404. Device 404 responds by sending a device proof 415 received by IDM system 406.

[0100] In some examples, device proof 415 may include a signed statement, which may include one or more device states, hash values ​​of one or more device states, or any combination thereof. The statement includes an assertion and may be in the form of name / value pairs about the device. The statement may be signed by the device (e.g., using a device-specific signing key) and may be provided and stored in a secure or trusted environment of the device. The proof provides attributes about the device. Device state may be measured based on at least one or more of the following: device software, firmware, operating system, applications, user authentication results, current location, hardware state, or any combination thereof. In some examples, the proof may include user proof. User proof may also include one or more of the following: biometric activity score, trusted location, information about the user's finger used for authentication, other metadata associated with preventing spoofing of user authentication, or any combination of such user proof information. As an example of hardware state, the device may determine whether it is connected to a computer via a Universal Serial Bus (USB), whether the device's battery has been removed, or some other evidence of potential hardware tampering. Hardware status can be based on information from sensors to indicate whether something has occurred at the device, such as whether a fuse has blown, whether a fuse has been disabled, whether the device has been turned on, or whether the device is currently connected to another device, such as via USB or other wired connection. The device status, or a hash value of the device status, can be signed at least along with the device ID and a random number. IDM system 406 sends a device verification request 417 to verification system 408. Device verification request 417 may include a signed statement or other information from device proof 415.

[0101] At 419, the verification system 408 determines the device identity and claim verification of device 404. Then, the verification system 408 sends a device verification response 421 to the IDM system 406. The device verification response 421 may contain a device verification result. The device verification result provides proof of the verifier's (e.g., verification system 408) evaluation of the device claim. The device verification result may be signed by the verifier, for example, using its signing key, similar to how a claim from a device is signed by the device using its signing key. The device verification response may also contain a device status. The device verification result may indicate that the device identity has been verified and the claim has been verified by the verification system.

[0102] like Figure 4As shown, after receiving a device authentication response 421 from the authentication system 408, the IDM system 406 sends a credential request 423 to the device 404. The device 404 responds to the credential request 423 by sending a credential response 425 to the IDM system 406. Among other information, the credential response 425 may include one or more of an ID, credential, credential proof, user information, or device proof. Information included in the credential response may include an eID. After receiving the credential response 425, the IDM system 406 responds with a credential registration response 427. Following the credential registration response 427, the eID is registered with the IDM system 406.

[0103] Figure 5 An example eID system 500 is illustrated according to the teachings disclosed herein, wherein an IDM system 508 interacts with an enabler 501 that enables the eID to provide or control access to a consumer or service 503. In the illustrated example, a device 502 (e.g., a user equipment, UE, network endpoint, etc.) can interact with the IDM system 508 to use the eID in conjunction with a consumer or service 503. The IDM system 508 can exchange information with an authentication system 510 to verify the credentials of the device 502. A registration system or eID registration / authentication authority 512 can provide the eID to the IDM system 508 for the device 502. Figure 5 In the example shown, eID registration / certification authority 512 is different. Figure 2 and / or Figure 4 The self-generated eID.

[0104] An eID can be stored or registered in a user device by scanning a physical ID card and verifying its authenticity through interaction with the issuing authority. There are many scenarios where physical ID cards are unnecessary or undesirable due to risks of theft, delays in the issuance and / or registration process, difficulties in revocation, etc. By facilitating the registration process detailed herein, the eID and associated credentials created by the issuing authority can be managed by the IDM, and the user device can be granted a token to access the eID and credentials. The token can be bound to the user device registered by the user during the registration process detailed herein. Device authentication can be performed as part of device registration. The user can then download the eID and credentials from the IDM by presenting the token on the user device.

[0105] Figure 6This is a diagram illustrating an example eID registration environment 600 as presented herein. An eID is an ID that includes ID information and associated credentials (e.g., electronic credentials). Examples of ID information that may be included in an eID include ID number, name, date of birth, date of issue, expiration date, and other information. Associated credentials may include any of the following: keys (e.g., public-private key pairs), certificates, tokens, passwords, PINs, digital IDs containing user information (such as digital ID cards), user biometric information (e.g., face ID, fingerprints, iris biometrics, etc.). User devices can also perform user authentication. User authentication can bind proof to authentication, such as device proof to user. In some examples, user authentication may also include a user activity test, which can increase the binding between device proof and user authentication. Figure 6 As shown, the eID registration environment 600 includes an issuing authority system 602, a device 604 (e.g., user equipment, UE, network endpoint, etc.) controlled by a user 605, an IDM system 606, and an authentication system 608. The issuing authority system 602 may be controlled by the issuing authority of the eID. For example, if the eID is associated with a driver's license, the issuing authority of the eID may be the Department of Motor Vehicles. The authentication system 608 may store information about the user equipment, such as device credentials for device 604. In some aspects, device credentials may include a device public key. In some aspects, device credentials may include credentials bound to the hardware of device 604. For example, device credentials may include one or more permanent identifiers associated with the hardware of device 604 (such as a chipset including a baseband processor and one or more other processors).

[0106] like Figure 6 As shown, user 605 can initiate user registration process 612 using device 604. While performing user registration process 612, device credentials can be sent to issuing authority system 602. Issuing authority system 602 can then send registration approval including a token that can be bound to device 604. Issuing authority system 602 can also perform registration process 616 to IDM system 606 by sending a registration token including ID credentials (such as credentials associated with a driver's license and driver's license information) to IDM system 606. IDM system 606 can store ID credentials sent from issuing authority system 602. In response to receiving registration approval 614, device 604 can utilize IDM system 606 to perform credential provisioning process 618 at device 604. In some aspects, user authentication is also performed based on credentials stored in IDM system 606 during the credential provisioning process. Figure 9Further details of the credential provision process are provided. IDM system 606 can work with verification system 608 to perform device verification process 620 to verify device 604. In some aspects, device verification process 620 may include device provision, feature activation, or device certification. In some aspects, each step in user registration process 612, registration approval 614, registration process 616, credential provision process 618, and device verification process 620 may require device certification.

[0107] Performing remote authentication can include a first entity or first party (e.g., the prover), a second entity or second party (e.g., the dependent party), and a third entity or third party (e.g., the verifier). A prover is an entity whose attributes are evaluated to determine whether the entity is considered trustworthy (e.g., whether the entity has access to and / or authorization to the service) (e.g., a user or device). A dependent party is an entity that relies on the prover's trustworthiness to determine whether the entity has access to and / or authorization to the service (e.g., a service provider). A verifier is an entity that evaluates the validity of the prover's attributes (e.g., a trusted third party, such as a device manufacturer, an IDM system, an authentication system, etc.).

[0108] For example, a network such as an IoT network may include one or more network endpoints and / or devices that access services (e.g., network resources) provided by a service provider (e.g., gateways, routers, access points, base stations, etc.). To protect the integrity of the network, the service provider may utilize a remote authentication process to determine whether one or more network endpoints and / or devices are qualified to access the network.

[0109] Typically, the prover (e.g., a network endpoint, a device) creates evidence (e.g., a set of information or claims) to be passed to the verifier. In some examples, the evidence may include measurements and reports of the state of the network endpoint and / or device (generally referred to herein as the "UE"). For example, the evidence may include firmware information, software information, location information, timestamps (e.g., time and / or date information), etc., associated with the UE. In some examples, the proof may include user credentials. User credentials may also include one or more of the following: biometric activity scores, trusted locations, information about the user's finger used for authentication, other metadata associated with preventing spoofing of user authentication, or any combination of such user credentials information.

[0110] The verifier applies an evidence evaluation strategy to the received evidence to assess the credibility of the prover (e.g., the UE) and generate a proof result. The evidence evaluation strategy may include one or more rules or constraints that guide the verifier on how to evaluate the validity of the evidence provided by the prover. The proof result may indicate whether the verifier guarantees the validity of the prover and the evidence. For example, the verifier may be a trusted third party, such as the manufacturer of a network endpoint and / or device, and the evidence evaluation strategy may include device verification information such as compatible firmware version(s), compatible software version(s), compatible location(s), compatible timestamp(s), etc. The verifier may generate a proof result indicating whether the evidence provided by the prover conforms to the device verification information.

[0111] The dependent party applies a proof evaluation policy to the proof result to determine whether to grant the prover access to the service and / or authorization. For example, the dependent party may be a service provider and may enforce policies on the prover based on the proof result. Policies may include one or more levels or configurations of network access, one or more levels or configurations of service access and / or authorization, one or more levels or configurations of QoS, one or more levels or configurations of resource access, one or more levels or configurations of trust, and / or one or more trust event remedies.

[0112] Different technologies can be used to implement aspects of remote proof. Figure 7A An example communication flow 700, as presented herein, is shown for a first example model 701 that facilitates remote proofs between prover 702, dependent party 704, and verifier 706. Figure 7B An example communication flow 730, as presented herein, is shown for a second example model 731 that facilitates remote proofs between prover 702, dependent party 704, and verifier 706. Figure 7C An example communication flow 750, as presented herein, is shown for a third example model 751 that facilitates remote proofs between prover 702, first dependent party 704a, second dependent party 704b, and verifier 706.

[0113] The aspect of Dependant 704 can be implemented by a service provider offering access to a network (e.g., an IoT network), such as a gateway, router, access point, base station, edge node, etc. The aspect of Proofor 702 can be implemented by a network endpoint and / or device (e.g., [missing information]) that connects to (or attempts to connect to) the network provided by Dependant 704. Figure 1 User equipment 103 and / or Figure 1 The UE104 aspect is implemented. The validator 706 aspect can be implemented by a trusted third party, such as the manufacturer of the validator 702 or an IoT framework configured to manage network devices. Figure 7A , Figure 7B and / or Figure 7C In the example shown, verifier 706 communicates with prover 702 and / or dependent 704 via a remote network.

[0114] In some examples, Figure 7A The first example model 701 can be called a "passport model" because it is similar to how a country issues passports to its citizens. Figure 7A In the example shown, prover 702 sends evidence 710 received by verifier 706. At 712, verifier 706 compares evidence 710 with an evidence evaluation strategy. Verifier 706 then sends the proof result 714 received by prover 702. If prover 702 determines that proof result 714 indicates compliance, prover 702 sends (or forwards) proof result 716 to dependent party 704. At 718, dependent party 704 compares proof result 716 with an evidence evaluation strategy. Dependent party 704 can then enforce a strategy against prover 702 based on the result of the comparison (e.g., at 718).

[0115] In some examples, Figure 7B The second example model 731 can be called a "background investigation model" because it is similar to how employers can conduct background investigations on prospective employees. Figure 7B In the example shown, prover 702 sends evidence 732 received by dependent party 704. Dependent party 704 sends (or forwards) evidence 734 received by verifier 706. At 736, verifier 706 compares evidence 734 with the evidence evaluation strategy. Verifier 706 then sends the proof result 738 received by dependent party 704. At 740, dependent party 704 compares the proof result 738 with the proof evaluation strategy. Dependent party 704 can then enforce the strategy against prover 702 based on the result of the comparison (e.g., at 740).

[0116] In some examples, Figure 7C The third example model 751 can be called a "combined model" because it is similar to the first dependency 704a that adopts the background investigation model, such as Figure 7B As shown, and the second dependency 704b using the passport model, as Figure 7A As shown. In Figure 7CIn the example shown, prover 702 sends evidence 752 received by first dependent party 704a. First dependent party 704a sends (or forwards) evidence 754 received by verifier 706. At 756, verifier 706 compares evidence 754 with the evidence evaluation strategy. Verifier 706 then sends proof result 758 received by first dependent party 704a. At 760, first dependent party 704a compares proof result 758 with the proof evaluation strategy. If first dependent party 704a determines that proof result 758 indicates compliance, then first dependent party 704a sends proof result 762 to prover 702. If prover 702 determines that proof result 762 indicates compliance, then prover 702 sends (or forwards) proof result 764 to second dependent party 704b. At 766, second dependent party 704b compares proof result 764 with the proof evaluation strategy. The second dependent party 704b can then implement a strategy against the prover 702 based on the results of the comparison (e.g., at 766).

[0117] However, in some examples, performing remote authentication can raise privacy, administrative, and / or scalability issues. For example, each time remote authentication is performed, information (e.g., evidence) is sent from a network (e.g., a network provided by a service provider) to the verifier via a remote network. For example, the network may be associated with a home, business, factory, municipality, etc., and network endpoints may include different devices connected to the network. In some such examples, it is understood that the network owner (e.g., homeowner, factory owner, etc.) may want to restrict the information sent to the remote network. For example, a network associated with a home may include one or more smart devices, such as smart meters, smart thermometers, one or more smart light bulbs, etc. In some such examples, the information that one or more smart devices may send during remote authentication could provide homeowner habits or behaviors that the homeowner might want to keep confidential (e.g., when the homeowner is home, etc.). In another example, a network associated with a factory may include dozens or hundreds of network endpoints. In some such examples, the information that network endpoints may send during remote authentication may include trade secrets, such as factory logs. In another example, preventing network endpoints within the network from connecting to trusted third parties (e.g., via a remote network) may be beneficial.

[0118] However, in some examples, maintaining network health may involve communicating with third parties via a remote network. For example, software updates may be provided to network endpoints connected to the network by the network endpoint's manufacturer. In some such examples, the network owner may want to manage health and update devices in a centralized manner (e.g., via a security gateway). Alternatively, the network owner may want to manage their devices based on capabilities, profiles, or roles.

[0119] The example techniques disclosed herein utilize network health managers (e.g., network controllers, network managers, gateways, routers, access points, base stations, edge nodes, etc.) located within the network to facilitate self-managed trust within the network. For example, the disclosed techniques can facilitate the reduction of information sent from the network to third parties via remote networks (e.g., IoT frameworks) by configuring the network health manager to manage the health and trust of network endpoints connected to the network. The network health manager can assume the role of a validator using information provided by one or more trusted third parties. Therefore, the network health manager can act as both a service provider and validator for network endpoints and limit the information sent from the network to third parties via remote networks.

[0120] In some examples, initial verification can be performed, for instance, between a network endpoint, a network health manager, and a trusted third party (e.g., a remote validator). For example, when a network endpoint requests a connection to the network, the network endpoint (e.g., prover 702), the network health manager (e.g., dependent 704), and the trusted third party (e.g., validator 706) can employ the combination described above. Figure 7A , Figure 7B and / or Figure 7C The remote proof process is described.

[0121] Then, when managing the health and trust of network endpoints, a network health manager (e.g., a security gateway) can act as a proxy for the network endpoints. For example, after verifying a network endpoint and determining its trustworthiness, the network health manager can obtain (or receive) trusted reference information for the network endpoint (e.g., from a trusted third party). In some examples, the trusted reference information may include the “last known good state” of the network endpoint. For example, the trusted reference information may include one or more of the following: compatible firmware version information, compatible software version information, compatible location information, compatible timestamp information, etc.

[0122] In some examples, the network health manager can receive trusted reference information for each network endpoint. For instance, the network health manager can receive first trusted reference information for a first smart thermometer, second trusted reference information for a second smart thermometer, third trusted reference information for a smart meter, and so on.

[0123] In some examples, the network health manager can receive trusted reference information for a set of network endpoints (e.g., network endpoints of the same type). For example, the network health manager can receive first trusted reference information for first and second smart thermometers, and second trusted reference information for smart meters, etc.

[0124] In some examples, a network health manager can subscribe to receive up-to-date trusted reference information about network endpoints from a trusted third party. For instance, the network endpoint manufacturer could provide a service to notify the network health manager when a software update becomes available for the network endpoint.

[0125] In some examples, the network health manager can perform verification of network endpoints. For instance, the network health manager can query a certificate from a network endpoint and determine whether a trust event has occurred based on the certificate and trusted reference information associated with the network endpoint. In some examples, the network health manager can perform verification of network endpoints according to a policy. For instance, the network health manager can query a certificate from a network endpoint periodically, on demand, or in response to the occurrence of a triggered event. The network health manager can then determine the trusted status of the network endpoint based on the certificate and the trusted reference information associated with the network endpoint. In some examples, the network health manager can report the verification results and / or the trust status of the network endpoint to a trusted third party. For instance, the network health manager can report the verification results and / or the trust status of the network endpoint according to a service contract with a trusted third party.

[0126] In some examples, the network health manager may obtain or receive policies implemented against network endpoints from a trusted third party. For example, the network health manager may receive policies associated with performing initial authentication, performing subsequent authentication, performing identifier registration, and / or responding to the occurrence of triggering events.

[0127] In some examples, a network endpoint may provide a policy enforced against it to the network health manager. In some examples, a network endpoint may provide a validator to the network health manager for accessing the policy. The network endpoint may be associated with performing initial authentication, with performing identifier registration, and / or providing a validator to the network health manager according to the policy. For example, the validator may include a policy location (e.g., a Uniform Resource Locator (URL)) that the network health manager can use to access (or retrieve) the policy enforced against the network endpoint. In some examples, the policy may include a Manufacturer Use Description (MUD) file. The MUD file may describe the network endpoint and associated device usage information. For example, the MUD file may define what network usage or behavior of the network endpoint is acceptable or permitted.

[0128] In some examples, after the network health manager obtains the policy, it begins enforcing the policy against the network endpoint. For instance, the network health manager may enforce network access or authorization based on the policy. This policy may include network access levels or configurations, service access or authorization levels or configurations, QoS levels or configurations, resource access levels or configurations, and / or trust levels or configurations. In some examples, enforcing the policy may include restricting access to the network endpoint, restricting remote access to the network endpoint, restricting information about the network endpoint provided to third parties, and / or providing software updates to the network endpoint.

[0129] In some examples, the policy may include one or more remedies applied by the network health manager when a trust event is detected. In some examples, a trust event may occur when a network endpoint fails authentication. For example, the network health manager may determine that the credentials provided by the network endpoint may not match the trusted reference information associated with the network endpoint. In some examples, a trust event may occur when it is determined that a network endpoint is operating outside the scope defined in its MUD file. For example, a smart light bulb can be controlled over a network and may be configured to connect to a collection point service accessible through an app executed on a smartphone. If the network health manager detects that the smart light bulb is attempting to access another network element (e.g., a refrigerator, printer, etc.), the network health manager may determine that a trust event has occurred. In another example, the smart meter's MUD file may instruct the smart meter to send data to a cloud service once a day. If the network health manager detects that the smart meter is attempting to send data more frequently, or sending more data than permitted, the network health manager may determine that a trust event has occurred.

[0130] In some examples, when a network health manager determines that a trust event has occurred, it may attempt one or more remedial measures to resolve the event. For example, the network health manager may block user access via the network endpoint, force a software update for the network endpoint, cause the network endpoint to restart, reset the network endpoint (e.g., factory reset), and / or disconnect the network endpoint from the network. In some examples, the network health manager may provide a trust event report to a third-party device manager based on the determination that the network health manager cannot resolve the trust event.

[0131] Figure 8 An example information exchange 800 between network 802, network health manager 804, and remote third party 806, as illustrated herein, is presented. In the illustrated example, information exchange 800 facilitates a self-managed trust system comprising one or more devices of network 802, network health manager 804, and remote third party 806. Aspects of network 802 may consist of one or more network endpoints (e.g., Figure 1 User equipment 103 Figure 2 User equipment 202 Figure 4 Equipment 404 Figure 5 Equipment 502 and / or Figure 6 Device 604), one or more UEs (e.g., Figure 1 UE 104 and / or Figure 3 UE350) and / or one or more certifiers (e.g., Figure 7A , Figure 7B and / or Figure 7C The proof provider 702) can be implemented in an IoT network, enterprise network, and / or consumer network. The network health manager 804 aspect can be implemented by a security gateway, security router, etc. The remote third party 806 aspect can be implemented by a trusted third party associated with a network endpoint (e.g., device 803) of network 802, such as the manufacturer of device 803, a cloud-based device management service (e.g., an IoT framework), an entity hosting policies implemented against device 803 (e.g., a web server), an entity hosting trusted reference information for device 803 (e.g., a web server), an entity configured to perform verifications associated with device 803, etc. It is understood that remote third party 806 can be one of one or more remote third parties.

[0132] exist Figure 8 In the example shown, network health manager 804 manages the health of connected devices (e.g., one or more network endpoints of network 802). In some examples, network health manager 804 may blacklist or otherwise restrict access to suspicious devices within network 802 based on trust policies (e.g., at 810). In some examples, network health manager 804 may act as a firewall for one or more devices on network 802. For example, network health manager 804 may restrict network access for device 803 based on a MUD file (e.g., at 812). Network health manager 804 may also provide software updates to one or more devices on network 802 when the corresponding device software expires (e.g., at 814). Therefore, the network health manager 804 disclosed herein may increase the privacy of network 802, for example, by reducing the amount of information relayed from one or more devices on network 802 to a remote third party 806 (e.g., at 816).

[0133] also, Figure 8A self-managed trust system can facilitate protection against man-in-the-middle (MITM) attacks and prove the connection health of network 802 (e.g., at 818). For example, network health manager 804 can ensure that one or more devices on network 802 are correctly configured and mounted (e.g., at 820). For example, when device 803 initiates a connection request, network health manager 804 can facilitate the performance of initial device authentication (e.g., remote attestation, as combined above). Figure 7A , Figure 7B and / or Figure 7C The network health manager 804 can also perform subsequent queries on the status of device 803 to assess its trust status. When the network health manager 804 detects a trust event, it can perform one or more trust event remediation actions to attempt to resolve the trust event associated with device 803.

[0134] like Figure 8 As shown, one or more devices in network 802 can provide device IDs and / or device health information to network health manager 804. In some examples, the device ID may include a persistent credential for the device (e.g., device 803). Device health information may include status information associated with device 803, such as firmware information, software information, location information, timestamps (e.g., time and / or date information), etc. In some examples, device 803 may collect (or measure) device health information at runtime and / or startup. In some examples, device 803 may provide device health information on demand (e.g., when queried by network health manager 804) and / or on a schedule (e.g., according to a policy).

[0135] Network health manager 804 can protect the privacy of network 802 by, for example, restricting information sent from network 802 to remote third party 806. For instance, by being able to perform authentication, network health manager 804 restricts recorded information associated with one or more devices of network 802 that may have been sent to remote third party 806 as part of device health information (e.g., during remote authentication execution). Furthermore, network health manager 804 provides a centralized way to perform software updates and requests for policies (e.g., MUD files). For example, instead of each device of network 802 coordinating with its respective remote third party to receive software updates, network health manager 804 can subscribe to a service that notifies network health manager 804 when software updates are available to individual devices of network 802.

[0136] The network health manager 804 can receive responses and / or information from a remote third party 806. For example, the network health manager 804 can receive software updates, device verification information, etc. from various devices on the network 802.

[0137] Network health manager 804 can provide provisioning services to various devices in network 802. For example, network health manager 804 can facilitate the provisioning of credentials for device 803.

[0138] As described above, the Network Health Manager 804 can also facilitate software updates for individual devices on the network (e.g., when software updates are available and / or critical for the devices). In some examples, the Network Health Manager 804 can facilitate software updates with increased privacy.

[0139] Figure 9 An example communication flow 900 between network endpoint 902, network health manager 904, and trusted third party 906, as presented herein, is illustrated. In the example shown, communication flow 900 facilitates network endpoint 902 performing a software update while maintaining privacy with trusted third party 906. Aspects of network endpoint 902 can be determined by network endpoints (e.g., Figure 1 User equipment 103 Figure 2 User equipment 202 Figure 4 Equipment 404 Figure 5 Equipment 502 and / or Figure 6 Device 604), UE (e.g., Figure 1 UE 104 and / or Figure 3 UE 350), certifier (e.g., Figure 7A , Figure 7B and / or Figure 7C The certifier 702) and / or Figure 8 The device 803 is used for implementation. The aspects of the network health manager 904 can be implemented by... Figure 8 The network health manager 804 is implemented. The trusted third party 906 aspect can be implemented by a trusted third party associated with network endpoint 902 (e.g., ...). Figure 7A , Figure 7B and / or Figure 7C Validator 706 and / or Figure 8 The remote third party (806) implementation.

[0140] Despite Figure 9 Not shown in the example, but in other examples, network health manager 904 can manage the health and trust of one or more devices connected to the network; therefore, network endpoint 902 could be an example device on the network, such as... Figure 8 Example device 803 of network 802.

[0141] Furthermore, despite Figure 9 The example shown depicts a single entity, but in other examples, Trusted Third Party 906 may include one or more trusted third parties. For example, Trusted Third Party 906 may include the manufacturer of network endpoint 902, a cloud-based device management service (e.g., an IoT framework), an entity hosting policies implemented against network endpoint 902, an entity hosting trusted reference information for network endpoint 902, an entity configured to perform proofs associated with network endpoint 902, etc.

[0142] exist Figure 9 In the example shown, network endpoint 902 and network health manager 904 can perform identity registration at 910. For example, network endpoint 902 and network health manager 904 can use... Figure 4 Example communication flow 400 is used to perform identity registration. In 912, the network health manager 904 can register persistent credentials associated with network endpoint 902.

[0143] At 914, network endpoint 902 generates a temporary credential. The temporary credential may include a public-private key pair. Network endpoint 902 sends a temporary credential 916 received by network health manager 904. The temporary credential 916 may be based on at least one of the public-private key pair, the public key of the public-private key pair, or a certificate. In some examples, the temporary credential 916 may also include a temporary ID associated with the temporary credential. The temporary ID may be a hash of the public key, certificate ID, or identifier associated with the temporary credential 916. Network endpoint 902 may also provide network health manager 904 with proof of ownership (or validity) of the temporary credential 916. For example, proof of ownership may be based on a permanent credential of network endpoint 902 known to network health manager 904 (e.g., a permanent credential registered at 912). If network health manager 904 determines that the temporary credential is valid, at 918, network health manager 904 registers the temporary credential 916 and associates the temporary credential 916 with network endpoint 902.

[0144] In the example shown, network health manager 904 receives software update notification 920 from a trusted third party 906. Software update notification 920 may indicate that a software update is available for network endpoint 902. Network health manager 904 may receive software update notification 920 in response to periodic certification reports and / or as a subscription-based push notification. In some examples, the subscription may be based on device type (e.g., smart meter), while the device ID of network endpoint 902 remains private.

[0145] Network health manager 904 sends a software update request 922 received by trusted third party 906. The software update request 922 may include a temporary credential 916 for network endpoint 902, enabling the software update to be bound to network endpoint 902. For example, trusted third party 906 sends a software update 924 received by network health manager 904. Trusted third party 906 may use the temporary credential 916 to encrypt software update 924. Trusted third party 906 may also sign software update 924 (e.g., via manufacturer ID).

[0146] At 926, network health manager 904 implements the software update policy associated with network endpoint 902. For example, network health manager 904 may attempt to verify the integrity of software update 924 by verifying that software update 924 includes the correct target device (e.g., temporary credentials for network endpoint 902) and that software update 924 is signed by a trusted third party 906 (e.g., via manufacturer ID). If network health manager 904 successfully verifies the software update (e.g., at 926), then network health manager 904 sends software update 928 received by network endpoint 902. If network health manager 904 cannot verify the software update (e.g., software update 924 does not include the correct target device and / or software update 924 is not signed by trusted third party 906), then network health manager 904 prevents the software update from being provided to network endpoint 902.

[0147] At 938, network endpoint 902 updates the software. In some examples, performing a software update may include using a software activation key, for example, to prevent misuse of the software update. For instance, performing a software update may include providing a software activation key.

[0148] In some examples, network endpoint 902 may send a certificate 930 received by network health manager 904. Certificate 930 may include a device identifier of network endpoint 902, persistent credentials of network endpoint 902, and / or device status of network endpoint 902. In some examples, at least one of the device identifier and persistent credentials may be stored in a secure or trusted environment of network endpoint 902, and the information stored in the secure or trusted environment may be immutable.

[0149] Network health manager 904 may send a proof instruction 932 received by trusted third party 906. In some examples, proof instruction 932 may include a proof result generated by network health manager 904 and based on proof 930. Trusted third party 906 may send a software activation code 934 received by network health manager 904. Trusted third party 906 may send the software activation code 934 in response to receiving proof instruction 932. Network health manager 904 sends (or forwards) a software activation code 936 received by network endpoint 902. At 938, network endpoint 902 may use software activation code 936 to facilitate the execution of a software update.

[0150] Figure 10 Example information exchange is illustrated in a self-managed virtual radio access network (vRAN) trusted environment 1000, which includes a UE 1002, a base node 1004, an edge node 1006, and an IoT framework 1008, as presented herein. Figure 10 In the example shown, UE 1002, base node 1004, edge node 1006 and IoT framework 1008 communicate via network 1010.

[0151] Aspects of UE 1002 can be determined by network endpoints (e.g., Figure 1 User equipment 103 Figure 2 User equipment 202 Figure 4 Equipment 404 Figure 5 Equipment 502 Figure 6 Equipment 604 and / or Figure 9 Network endpoint 902), UE (e.g., Figure 1 UE104 and / or Figure 3 UE 350), certifier (e.g., Figure 7A , Figure 7B and / or Figure 7C The certifier 702) and / or Figure 8 The implementation is carried out by device 803. Aspects of the base node 1004 can be implemented by a router or base station, such as... Figure 1 Example base stations 102 / 180 and / or Figure 3 The base station 310. Aspects of the network 1010 can be implemented by a public cloud 1010a, such as a mobile network or a telecommunications network, or by a private cloud 1010b, such as an enterprise network.

[0152] exist Figure 10In the example shown, the IoT framework 1008 may include cloud-based device management services to manage one or more network endpoints (e.g., one or more IoT devices), such as UE 1002. For example, the IoT framework 1008 may perform analytics on one or more network endpoints, perform continuous monitoring of one or more network endpoints, and / or perform device management on one or more network endpoints. In some examples, the IoT framework 1008 may communicate with one or more cloud systems 1009 that provide one or more trusted third-party services. For example, one or more cloud systems 1009 may provide services related to the network endpoint manufacturer, an entity hosting policies enforced against the network endpoint, an entity hosting trusted reference information for the network endpoint, an entity configured to perform device authentication associated with the network endpoint, etc.

[0153] In some examples, the IoT framework 1008 can offload one or more services to the edge node 1006, enabling the edge node 1006 to perform local operations on the data. By offloading one or more services to the edge node 1006, service execution can be completed relatively faster than when executed via the IoT framework 1008, thereby reducing the latency that the UE 1002 may experience when accessing services.

[0154] exist Figure 10 In the example shown, UE 1002 includes a protocol and / or software stack 1050 and hardware component 1052. The example protocol and / or software stack 1050 includes an application programming interface (API), a software development kit (SDK), a NAS layer, an RRC layer, an RLC layer, a MAC layer, a PHY layer, a real-time operating system (RTOS), a hypervisor (HYP) layer, a trusted execution environment (TEE), and a countermeasures layer. However, other example protocol and / or software stacks may include additional or alternative components.

[0155] Example hardware component 1052 includes a Secure Boot (SecBoot) component, an encryption component, and a secure element 1054. The secure element 1054 (sometimes referred to as a "trust management engine") can be hardened to provide hardware guarantees. For example, modifying content stored in the secure element 1054 might require physical access to the secure element 1054. Therefore, storing information in the secure element 1054 adds a guarantee that the stored information will not be modified and provides a "root of trust." In some examples, at least one of the UE 1002's device identifier, the UE 1002's permanent credentials, and / or the UE 1002's device state information may be stored in the secure element 1054. In some examples, during authentication, the secure element 1054 may perform device state measurements and reporting.

[0156] exist Figure 10In the example shown, base node 1004 includes a protocol and / or software stack 1056 and hardware components 1058. The example protocol and / or software stack 1056 includes an RRC layer, RLC layer, MAC layer, PHY layer, RTOS, HYP layer, TEE, and a countermeasures layer. However, other example protocols and / or software stacks may include additional or alternative components.

[0157] Example hardware component 1058 includes a SecBoot component, an encryption component, and a security element 1060. Aspects of security element 1060 may be similar to security element 1054 of UE 1002. In some examples, security element 1060 may additionally or alternatively store registration and / or recorded identifiers associated with other network endpoints (e.g., UE 1002). For example, UE 1002 may register a device identifier with base node 1004 (e.g., using...). Figure 4 Example communication flow 400). In some such examples, base node 1004 may store the registered device identifier of UE 1002 in secure element 1060.

[0158] exist Figure 10 In the example shown, edge node 1006 includes a protocol and / or software stack 1062 and hardware components 1064. The example protocol and / or software stack 1062 includes an application service layer, a HYP layer, a Fog layer (e.g., an open standard for edge computing), a storage layer, a compute layer, an accelerator layer, a network layer, and a countermeasures layer. However, other example protocols and / or software stacks may include additional or alternative components.

[0159] Example hardware component 1064 includes a SecBoot component, an encryption component, and a security element 1066. Aspects of security element 1066 may be similar to security element 1054 of UE 1002 and / or security element 1060 of base node 1004.

[0160] exist Figure 10 In the example shown, when a device such as UE 1002 performs authentication, the secure element 1054 of UE 1002 can measure and report the device status of UE 1002. For example, the secure element 1054 can measure and / or obtain information related to one or more of the following associated with UE 1002: device software, firmware, operating system, applications, user authentication results, current location, hardware status, or any combination thereof. In some examples, authentication may include user authentication. User authentication may also include one or more of the following: biometric activity score, trusted location, information about the user's finger used for authentication, other metadata associated with preventing spoofing of user authentication, or any combination of such user authentication information.

[0161] As mentioned above, in order to promote self-managed trust networks, the network can designate agent devices (or agent devices, as described below) Figure 11 The aforementioned methods facilitate the execution of authentication within the network. In some such examples, the agent device (e.g., a network health manager) can obtain trusted reference information to facilitate the execution of health and trust status checks on one or more connected network endpoints.

[0162] exist Figure 10 In the example shown, base node 1004 can perform aspects of the network health manager, such as... Figure 8 Network Health Manager 804 and / or Figure 9 The network health manager 904. For example, the base node 1004 can facilitate the initial device verification of the UE 1002 and then retrieve trusted reference information associated with the UE 1002 from a trusted third party (e.g., via the IoT framework 1008). The base node 1004 can store the trusted reference information in a secure element of the base node 1004, such as example secure element 1060.

[0163] exist Figure 10 In the example shown, UE 1002 provides proof to the network. For example, UE 1002 may send proof to base node 1004 and / or edge node 1006. In some examples, proof may include device status information measured and reported by the secure element 1054 of UE 1002. UE 1002 may provide proof according to policy, based on a request (e.g., from base node 1004 and / or edge node 1006), and / or in response to a triggering event. UE 1002 may send proof to base node 1004 and / or edge node 1006 for local analysis and management based on trust policies.

[0164] A local management node (e.g., base node 1004 and / or edge node 1006) can determine whether a trust event has occurred based on the proof and trusted reference information associated with UE 1002. In a first example, the local management node can determine that no trust event has occurred. In a second example, the local management node can determine that a trust event has occurred and that the trust event is not a problem. In a third example, the local management node can determine that a trust event has occurred, that the trust event is a problem, and determine to fix the problem. For example, the local management node can apply one or more trust event remedies to fix the problem according to a policy. In a fourth example, the local management node can determine that a trust event has occurred, that the trust event is a problem, and determine to postpone fixing the problem to IoT framework 1008. For example, the local management node can determine that applying one or more trust event remedies has failed to successfully resolve the trust event, that the local management node cannot execute a trust event remedy (e.g., the trust event remedy is outside the policy associated with UE 1002 and / or the policy associated with the local management node), and / or that no trust event remedy (e.g., by policy) has been provided to remedy the trust event.

[0165] In some examples where the local management node determines to postpone fixing the issue to the IoT framework 1008, the local management node may send a trust event report (sometimes called a "proof report") to the IoT framework 1008.

[0166] For example Figure 10 As shown, the device management entity 1070 of the IoT framework 1008 can request proof verification from one or more cloud systems 1009. For example, the device management entity 1070 can use a proof report provided by a local management node to request proof verification for UE 1002. In response to the proof verification request, one or more cloud systems 1009 can provide a proof verification report. The device management entity 1070 can then take one or more actions to remedy trust events associated with UE 1002. For example, the device management entity 1070 can remove UE 1002 from network 1010, force UE 1002 to perform a software update, etc.

[0167] Figure 11 Example network 1100, such as a self-managed high-guarantee IoT network, is depicted, including users 1102, 1104, network endpoints (e.g., nodes 1110, 1112, 1114, 1116, 1118, 1120), router 1122, trusted third party 1124, and edge node 1126, as presented herein. Example network 1100 provides examples of nodes performing user authentication, device authentication, and / or connectivity authentication. Figure 11In the example shown, router 1122 and edge node 1126 each communicate with a trusted third party 1124, and also with one or more nodes 1110, 1112, 1114, 1116, 1118, and 1120. In some such examples, aspects of the network health manager may be implemented by router 1122 and / or edge node 1126. For example, router 1122 may operate as a local authenticator for one or more nodes 1110, 1112, 1114, 1116, and 1118 connected to router 1122, and edge node 1126 may operate as a local authenticator for node 1120 connected to edge node 1126. For example, when any of nodes 1110, 1112, 1114, 1116, and 1118 connects to router 1122, router 1122 can perform initial device verification with each node 1110, 1112, 1114, 1116, and 1118, and then obtain trusted reference information associated with each node 1110, 1112, 1114, 1116, and 1118 from a trusted third party 1124. (As described above...) Figure 10 As described above, router 1122 may store trusted reference information in the router's secure element, such as the secure element of router 1122.

[0168] Similarly, when node 1120 connects to edge node 1126, edge node 1126 can perform initial device verification with node 1120, and then obtain trusted reference information associated with node 1120 from trusted third party 1124. Edge node 1126 can store the trusted reference information in its secure element, such as... Figure 10 The edge node 1006 has a security element 1066.

[0169] like Figure 11 As shown, router 1122 communicates with trusted third party 1124 and relay node 1110. Aspects of relay node 1110 can be implemented by an access point or relay device. In this example, relay node 1110 communicates with a first downstream node 1112, a second downstream node 1114, and a third downstream node 1116. The first downstream node 1112 is accessible by a first user 1102, and the third downstream node 1116 is accessible by a second user 1104. To ensure that users 1102 and 1104 are allowed access to their respective network endpoints (e.g., nodes 1112 and 1116, respectively), the network endpoints can perform user authentication for their respective users. For example, user authentication can be based on one or more of password, biometrics, trusted location, multi-factor authentication, or continuous authentication. Figure 11As shown, the second user 1104 is a "good user," meaning that the second user 1104 successfully provided user authentication and verification. Conversely, the first user 1102 is a "bad user," meaning that the first user 1102 failed to successfully provide user authentication and verification. Figure 11 As shown, based on the premise that the first user 1102 is a "bad user," the first downstream node 1112 can block and / or disallow the first user 1102 from logging in and / or accessing network 1100. The first downstream node 1112 can additionally or alternatively cancel transactions that the first user 1102 may have attempted to execute.

[0170] In some examples, the first downstream node 1112 and / or the third downstream node 1116 may provide the user authentication results to router 1122 (e.g., via relay node 1110). For example, the first downstream node 1112 may provide a proof result to router 1122 indicating that the first user 1102 failed their user authentication (e.g., providing non-compliant authentication and / or non-compliant proof to the first downstream node 1112). Conversely, the third downstream node 1116 may provide a proof result to router 1122 indicating that the second user 1104 passed their user authentication (e.g., providing compliant authentication and proof to the third downstream node 1116). In some examples, the first downstream node 1112 and / or the third downstream node 1116 may provide their proof results according to their respective policies. For example, the policy may instruct downstream nodes 1112, 1116 to provide proof results (multiple) according to a schedule (e.g., daily, etc.), to provide proof results (multiple) on demand (e.g., when requested by router 1122), and / or to provide proof results (multiple) when a triggering event occurs (e.g., each time a downstream node performs user authentication, each time a downstream node performs a successful user authentication, each time a downstream node performs an unsuccessful user authentication, etc.).

[0171] like Figure 11 As shown, router 1122 communicates with bad node 1118. Bad node 1118 can be designated as a "bad node" due to unsuccessful device authentication. For example, performing device authentication can be based on one or more of the following: device ID, boot integrity check, runtime integrity check, behavioral or static antivirus (AV), indication that bad node 1118 is rooted, etc. Figure 11As shown, based on the determination that bad node 1118 is a "bad node," router 1122 can perform policy-driven remedial actions, such as rebooting bad node 1118, resetting bad node 1118 (e.g., performing a factory reset or "wiping" the node), and / or disconnecting bad node 1118 from network 1100. In some examples, after performing one or more remedial actions (successfully or unsuccessfully), router 1122 can query individual nodes 1110, 1112, 1114, 1116, and 1118 to provide proof.

[0172] In some examples, bad node 1118 may provide its proof results according to a policy. For example, the policy may instruct bad node 1118 to provide proof results (multiple) according to a schedule (e.g., daily, etc.), on demand (e.g., when requested by router 1122), and / or when a triggering event occurs (e.g., each time a node performs a proof, each time a node performs a successful proof, each time a node performs an unsuccessful proof, etc.).

[0173] like Figure 11 As shown, router 1122 communicates with relay node 1110 via connection 1140. In the example shown, router 1122 can perform connection proof on connection 1140 to determine the trustworthiness of connection 1140. For example, router 1122 can use connection proof to determine whether connection 1140 might be incompatible due to intrusion (e.g., man-in-the-middle (MITM) attacks, denial-of-service (DoS) attacks, Domain Name System (DNS) poisoning, incompatible Secure Sockets Layer (SSL) connections, etc.), detection of rogue wireless connections, detection of International Mobile Subscriber Identity Detectors (IMSI detectors), detection of rogue Universal Serial Bus (USB) devices, etc. In response to determining that connection 1140 is incompatible (e.g., router 1122 performs an unsuccessful connection proof), router 1122 can disconnect relay node 1110 from network 1100, search for another cell or service set identifier (SSID) through which it is connected, and / or force relay node 1110 and router 1122 to communicate via a Virtual Private Network (VPN).

[0174] As described above, in some examples, different levels of access to a service can be provided to users and / or devices based on the policy or sensitivity level of the service being accessed. For example, based on the occurrence of a trust event associated with the first user 1102, the bad node 1118, and / or connection 1140, router 1122 (and / or downstream nodes 1112, 1114, 1116) can perform remedial measures such as disabling user access, restarting a node, wiping a node, disabling a node, disconnecting a node, searching for another cell or SSID to connect to, and / or forcing a VPN connection.

[0175] However, in some examples, trust incidents may occur, such as detecting a node running outdated software, and remediation for such incidents might involve allowing the node to continue operating while limiting the risk. Figure 11 As shown, edge node 1126 can perform proofs with node 1120 and determine that node 1120 is running outdated software (e.g., an "obsolete" node). In some examples, edge node 1126 can force obsolete node 1120 to perform a software update. In some examples, edge node 1126 can enable obsolete node 1120 to remain functional while limiting the risk to obsolete node 1120 and / or network 1100. For example, a software update for obsolete node 1120 can indicate that the software update does not include critical updates. In some examples, a software update can indicate and / or edge node 1126 can determine that certain functions of obsolete node 1120 are disabled until a software update is applied to obsolete node 1120. For example, obsolete node 1120 can be a smart light bulb, and a software update for a smart light bulb can indicate that the software update corrects a problem when a user attempts to enable the smart light bulb's "party mode" setting. In some such examples, edge node 1126 can instruct obsolete node 1120 to disable the "party mode" setting while still allowing obsolete node 1120 to continue other functions (e.g., being remotely controlled).

[0176] In some examples, a policy implemented against deprecated node 1120 may allow it to operate with deprecated software for a period of time before a mandatory software update is required. For example, when the software update includes a critical update, implementing a policy against deprecated node 1120 may force it to perform the update. In other examples where the software update does not include a critical update, implementing a policy against deprecated node 1120 may allow it to continue operating while using the deprecated software, for example, until a triggering event occurs. In some examples, the software update triggering event may occur based on the passage of a threshold period. For example, the software update triggering event may occur 24 hours after edge node 1126 determines that a software update is available for deprecated node 1120.

[0177] In some examples, the software update trigger event may occur based on the determination that the obsolete node 1120 is connected to a power source, has a threshold battery level, and / or is during the obsolete node 1120's downtime. For example, edge node 1126 may cause the obsolete node 1120 to perform a software update based on historical usage data associated with the obsolete node 1120. For example, the obsolete node 1120 may be a smart light bulb, and the historical usage data associated with the smart light bulb may indicate that the smart light bulb is inactive (e.g., off) during one or more time periods of the day (e.g., during weekday working hours, during nighttime hours, etc.). Edge node 1126 may then cause the smart light bulb to perform a software update during one of the identified time periods.

[0178] Despite Figure 11 Not shown in the examples, but in some examples, router 1122 and / or edge node 1126 may postpone resolving issues (e.g., the occurrence of a trust event). For example, router 1122 and / or edge node 1126 may provide a trust event report to a trusted third party 1124 to determine what techniques to employ to remedy the trust issue. The above combined... Figure 10 The device management entity 1070 describes aspects of delaying problem resolution.

[0179] Figure 12 An example communication flow 1200 between network endpoint 1202, network health manager 1204, and trusted third party 1206, as presented herein, is illustrated. Aspects of network endpoint 1202 can be derived from network endpoints (e.g., Figure 1 User equipment 103 Figure 2 User equipment 202 Figure 4 Equipment 404 Figure 5 Equipment 502 Figure 6 Device 604, network endpoint 902 and / or Figure 11 Nodes 1102, 1103, 1105), UE (e.g., Figure 1 UE 104 Figure 3 UE 350 and / or Figure 10 UE 1002), certifier (e.g., Figure 7A , Figure 7B and / or Figure 7C The certifier 702) and / or Figure 8 The device 803 is used for implementation. The aspects of the network health manager 1204 can be implemented by... Figure 8 Network Health Manager 804 Figure 9 Network Health Manager 904 Figure 10 Basic node 1004 and / or edge node 1006 and / or Figure 11This is implemented by router 1104 and / or edge node 1108. The aspect of trusted third party 1206 can be implemented by a trusted third party associated with network endpoint 1202 (e.g., Figure 7A , Figure 7B and / or Figure 7C Validator 706 Figure 8 Remote third-party 806 Figure 9 Trusted third party 906 Figure 10 IoT framework 1008 and / or Figure 11 Implemented by a trusted third party (1106).

[0180] Despite Figure 12 Not shown in the example, but network health manager 1204 can manage the health and trust of one or more devices connected to the network; therefore, network endpoint 1202 could be an example device on the network, such as... Figure 8 Example device 803 of network 802.

[0181] Furthermore, despite Figure 12 The example shown is a single entity, but trusted third party 1206 may include one or more trusted third parties. For example, trusted third party 1206 may include the maker of network endpoint 1202, an entity hosting policies implemented against network endpoint 1202, an entity hosting trusted reference information for network endpoint 1202, an entity configured to perform proofs associated with network endpoint 1202, etc.

[0182] exist Figure 12 In the example shown, network endpoint 1202 may send a connection request 1210 received by network health manager 1204. Connection request 1210 may be an initial request for network endpoint 1202 to connect to the network managed by network health manager 1204.

[0183] At point 1212, network endpoint 1202, network health manager 1204, and trusted third party 1206 can perform initial verification. The aspects of initial verification can be similar to the combination described above. Figure 7A , Figure 7B and / or Figure 7C The remote proof process is described.

[0184] At point 1214, network endpoint 1202 and network health manager 1204 can perform identity registration. The aspect of performing identity registration (at 1214) can be similar to... Figure 9 910 performs identity registration and / or Figure 4Example communication flow 400. In some examples, the network health manager 1204 can register the device key associated with the network endpoint 1202 after the identity registration is completed. For example, the network health manager 1204 can store the device ID, persistent credentials, etc. associated with the network endpoint 1202 in the secure element of the network health manager 1204.

[0185] In the example shown, network health manager 1204 may send a subscription request 1216 received by a trusted third party 1206. The subscription request 1216 may include a request from network health manager 1204 to subscribe to a service to receive the latest trusted reference information for network endpoint 1202 and / or to receive notifications when software updates for network endpoint 1202 are available.

[0186] In the example shown, trusted third party 1206 sends trusted reference information 1218 received by network health manager 1204. In some examples, trusted third party 1206 may send trusted reference information 1218 in response to subscription request 1216. Trusted reference information 1218 enables network health manager 1204 to perform local management of network endpoint 1202. For example, network health manager 1204 may use trusted reference information 1218 to determine the trust status of network endpoint 1202 and / or enforce policies for network endpoint 1202 without sending information about network endpoint 1202 (e.g., device health information and / or device status information) to trusted third party 1206. In some examples, network health manager 1204 may store trusted reference information 1218 in the secure element of network health manager 1204. In some examples, trusted reference information 1218 may be received for each network endpoint. In some examples, trusted reference information 1218 may be received for a set of network endpoints of the same type.

[0187] In some examples, network health manager 1204 may send a policy request 1220 received by a trusted third party 1206. In some examples, network health manager 1204 may use a proof verifier associated with network endpoint 1202 to send the policy request 1220. For example, network endpoint 1202 may be associated with performing initial verification (e.g., at 1212), with performing identifier registration (e.g., at 1214), and / or providing a proof verifier to network health manager 1204 according to a policy. In some examples, the proof verifier may include a URL that network health manager 1204 can use to access policies enforced against network endpoint 1202.

[0188] A trusted third party 1206 sends policy 1222, which is received by network health manager 1204. For example, trusted third party 1206 may send policy 1222 in response to policy request 1220. In some examples, policy 1222 may include a MUD file. The MUD file may describe network endpoint 1202 and associated device usage information. For example, the MUD file may define what network usage or behavior of network endpoint 1202 is acceptable or permitted. In some examples, policy 1222 may include network access levels or configurations, service access or authorization levels or configurations, QoS levels or configurations, resource access levels or configurations, trust levels or configurations, and / or trust event remedies. In some examples, policy 1222 may be an updatable policy.

[0189] The network health manager 1204 performs authentication of the network endpoint 1202 based at least in part on trusted reference information 1218 received from a trusted third party 1206. In some examples, the network health manager 1204 may perform authentication of the network endpoint 1202 periodically. In some examples, the network health manager 1204 may perform authentication of the network endpoint 1202 on demand. In some examples, the network health manager 1204 may perform authentication of the network endpoint 1202 in response to the occurrence of a triggering event (e.g., installing new software, connecting a USB device, etc.).

[0190] In the example shown, the network health manager 1204 begins to perform verification of the network endpoint 1202 by sending a status query 1224 received by the network endpoint 1202.

[0191] In response to receiving a status query 1224, network endpoint 1202 sends a certificate 1226 received by network health manager 1204. In some examples, the certificate 1226 may be based on one or more of the network endpoint 1202's device identifier, network endpoint 1202's persistent credentials, and / or network endpoint 1202's device status information. In some examples, the security element of network endpoint 1202, such as security element 1054 of UE 1002, may measure and report the certificate 1226. In some examples, at least one of the device identifier and persistent credentials may be stored in the security element of network endpoint 1202.

[0192] At 1228, network health manager 1204 determines the trust status of network endpoint 1202. For example, network health manager 1204 may compare the proof 1226 received from network endpoint 1202 with trusted reference information 1218 to determine the trust status of network endpoint 1202. In some examples, network health manager 1204 may provide notification of trust events (e.g., trust event reports) to the network system or edge components for analysis of trust events, as described above. Figure 10 As stated above.

[0193] In some examples, network health manager 1204 may report the verification results of the performed verification to trusted third party 1206. For example, network health manager 1204 may send message 1236 received by trusted third party 1206. Message 1236 may include the verification result. In some examples, message 1236 may include a verification report.

[0194] At 1230, network health manager 1204 enforces policies on network endpoint 1202. In some examples, network health manager 1204 may enforce policies based on the trust state of network endpoint 1202. In some examples, network health manager 1204 may enforce policies on network endpoint 1202 by restricting access to network endpoint 1202 based on trust policies. In some examples, network health manager 1204 may enforce policies on network endpoint 1202 by restricting remote or network access to network endpoint 1202, by restricting information about network endpoint 1202 provided to third parties, etc.

[0195] In some examples, implementing policies on network endpoint 1202 may include network health manager 1204 resolving the occurrence of a trust event at 1232. For example, network health manager 1204 may apply one or more trust event remediation measures to fix the trust event. In some examples, resolving the occurrence of a trust event may include disabling user access via network endpoint 1202, forcing a software update for network endpoint 1202, restarting network endpoint 1202, resetting network endpoint 1202, and / or disconnecting network access to network endpoint 1202. In some examples, resolving the occurrence of a trust event may include determining that the trust event is not a problem. In some examples, resolving the occurrence of a trust event may include deferring the remediation of the trust event to a cloud-based device manager (e.g., as described above). Figure 10 The above).

[0196] In some examples, at 1234, implementing a policy for network endpoint 1202 could include facilitating software updates. Aspects of facilitating software updates (e.g., at 1234) could be similar to... Figure 9 Example communication flow 900.

[0197] In some examples, when network health manager 1204 begins performing authentication (e.g., by sending status query 1224), network endpoint 1202 can also perform user authentication for the user accessing network endpoint 1202. In some such examples, the proof 1226 sent by network endpoint 1202 to network health manager 1204 may include the user authentication result based on the user authentication performed by network endpoint 1202. (See above in conjunction with...) Figure 11 The network health manager 1204 can control user access to services based on user authentication. For example, the network health manager 1204 can disable or disallow login and / or cancel transactions based on the occurrence of a trust event associated with user authentication.

[0198] Refer again Figure 7A , Figure 7B and Figure 7C In the example shown, the verification of prover 702 is performed by an entity (e.g., verifier 706). However, in some examples, access to the service may be based on verification of various information about the entity accessing the service (e.g., prover or device). In some such examples, performing a single authentication and / or proof may be insufficient to determine the trustworthiness of a device (e.g., user equipment, UE, network endpoint, etc.).

[0199] The example techniques disclosed herein utilize proxy devices to manage access to services provided by a service management entity. For example, the disclosed techniques can configure a device to operate as a proxy for a service management entity and manage access to services based on multiple provable parameters. In some examples, the proxy can facilitate the verification of provable information corresponding to the provable parameters. The example proxy can then assess a trust score for the device based on the corresponding verification results and enforce policies on the device based on the trust score.

[0200] For example, Figure 13 An example information exchange 1300 between device 1302, service management entity 1304, and agent 1306 of service management entity 1304 is depicted as presented herein. While the following description may focus on an automotive / bridge / town example environment, the concepts described herein can be applied to other similar environments where it may be beneficial to manage access permissions based on the policies of a service management entity using an agent device (e.g., an agent). For example, an agent could be implemented by a security gate in a workplace or enterprise. In another example, an agent could be implemented by a peripheral hub (e.g., a Universal Serial Bus (USB) hub, etc.).

[0201] exist Figure 13In the example shown, device 1302 (e.g., the prover) is implemented by a vehicle, service management entity 1304 (e.g., the dependent party) is implemented by a town, and agent 1306 is implemented by a bridge. As shown, service management entity 1304 relies on agent 1306 to verify device 1302. Specifically, the bridge can act as an agent for the town to control traffic based on a number of provable parameters. In some examples, device 1302 may be able to prove device 1302 and / or the user of device 1302. The proof performed by device 1302 can provide at least some of the proof information requested by agent 1306.

[0202] In some examples, device 1302 may provide agent 1306 with proof information corresponding to one or more provable parameters, which agent 1306 can then verify. For example, agent 1306 may be able to use reference information (e.g., a database of license numbers of devices registered with service management entity 1304) to verify whether device 1302 is registered with service management entity 1304 and / or whether the user of device 1302 is a resident of service management entity 1304.

[0203] In some examples, agent 1306 may be able to perform measurements and verify certification information based on those measurements. For example, agent 1306 may be able to measure the weight of device 1302 and determine whether the weight of device 1302 is within general weight limits (e.g., a town may have a maximum weight limit for a vehicle) and / or whether the weight of device 1302 is within weight limits based on device type.

[0204] In some examples, Agent 1306 can communicate with one or more third-party verification entities (e.g., identity issuers, IDM systems, device manufacturers, and / or authentication services) to verify credentials. For example, Agent 1306 can communicate with... Figure 1 The vehicle communicates with the IDM system 199 and / or the Department of Motor Vehicles (DMV) to confirm the vehicle's last smoke test.

[0205] exist Figure 13 In the example shown, device 1302 provides authentication information to agent 1306. In some examples, authentication information may include one or more substates that are independent and associated with or managed by different authentication entities (e.g., device 1302, agent 1306, and / or a third-party authentication entity).

[0206] The proof information may include user-provable information, device-provable information, and / or network (or connectivity)-provable information. In some examples, the proof information may include one or more sub-states of proveable information. For example, the proof information may include one or more of device status information, user authentication status information, and / or connection status information. Device status information may include one or more of the following: Basic Input / Output System (BIOS) information, Unified Extensible Firmware Interface (UEFI) information, Master Boot Loader (PBL) information, Secondary Boot Loader (SBL) information, firmware information, hypervisor information, High-Level Operating System (HLOS) information, Real-Time Operating System (RTOS) information, and / or runtime integrity information. User authentication status information may include one or more of the following: authentication type and result for user access to the device, activity test (e.g., if biometric authentication is used), password strength information, continuous authentication, and / or multi-factor authentication (MFA) information. Connection status information may include one or more of the following: radio frequency (RF) fingerprint information, Virtual Private Network (VPN) information, channel type information, authentication method information, security protocol, and / or algorithm information. In some examples, provable information may include additional provable information such as location information and / or timestamps (e.g., time and / or date). Location information may include different levels of granularity. For example, location information may include coordinate information (e.g., Global Positioning System (GPS) coordinates). In some examples, location information may include general locations such as “home,” “office,” etc.

[0207] Agent 1306 can then facilitate the verification of authentication information. For example, agent 1306 can use the authentication information of device 1302, perform its own verification of authentication information, and / or communicate with one or more third-party verification entities to perform verification.

[0208] To enable agent 1306 to facilitate intelligent policy control and enforcement, agent 1306 can evaluate a trust score based on one or more verification results. In some examples, agent 1306 can apply weights to individual verification results to evaluate the trust score of device 1302. Agent 1306 can use the trust score to manage access to services provided by service management entity 1304. For example, agent 1306 can allow or deny access to services provided by service management entity 1304 based on the trust score of device 1302. In some examples, agent 1306 can determine the accessibility level of services provided by service management entity 1304 based on the trust score of device 1302. For example, agent 1306 can determine whether full or limited access to device 1302 is allowed. In some examples, agent 1306 can determine the priority of service access to device 1302 based on the trust score of device 1302. In some examples, the trust score can allow agent 1306 and / or service management entity 1304 to adaptively configure policies implemented on device 1302. For example, a strategy can be changed based on one or more different factors, such as the increase or decrease of provable parameters (multiple), time of day, traffic volume, bandwidth usage, network conditions, anomaly detection, etc.

[0209] As an illustrative example, agent 1306 acts as an intermediary between device 1302 and service management entity 1304 to manage access permissions (e.g., toll fees, access control, etc.) based on policies of service management entity 1304 and / or agent 1306. For example, policies of service management entity 1304 and / or agent 1306 may include at least one occupant of device 1302 being a resident of service management entity 1304, device 1302 meeting weight restrictions, and the occupant of device 1302 appearing healthy (e.g., no high temperature, etc.). Service management entity 1304 can then use agent 1306 to allow device 1302 to access (or enter) service management entity 1304, prevent device 1302 from accessing (or entering) service management entity 1304, or schedule device 1302 to enter service management entity 1304. For example, policies (or multiple policies) may allow non-residents to enter service management entity 1304 for a maximum period of time. Policies may define one or more actions (e.g., a set of actions) to be implemented based on an evaluation of evidentiary information. Actions (or subsets of actions) may be performed by agent 1306, device 1302, and / or one or more trusted third parties. For example, the set of actions defined by the policy may include one or more actions performed by agent 1306 (e.g., displaying a flag indicating that read access is not approved), one or more actions performed by device 1302 caused by agent 1306 (e.g., by causing device 1302 to redirect), and / or one or more actions performed by one or more trusted third parties caused by agent 1306 (e.g., by moving an access barrier into place to prevent access).

[0210] In some examples, service management entity 1304 (e.g., a town) can use agent 1306 to notify device 1302 of special circumstances within the town. For example, agent 1306 can notify device 1302 of buildings, marching routes, etc. In some examples, agent 1306 can be configured to reroute device 1302 based on special circumstances.

[0211] In some examples, device 1302 may notify agent 1306 and / or service management entity 1304 (e.g., via agent 1306) of specific conditions related to device 1302. For example, device 1302 may indicate to agent 1306 that device 1302 is on a wide road, is part of a funeral procession, etc.

[0212] In some examples, service management entity 1304 and / or agent 1306 may determine the toll to be collected by agent 1306 from device 1302 based, for example, on resident status, vehicle type, time of day, traffic conditions, etc.

[0213] Figure 14An example communication flow 1400 is illustrated between device 1402, service management entity 1404, agent 1406 of the service management entity, and third-party authentication entity 1408 as presented herein. In the illustrated example, communication flow 1400 uses authentication results to facilitate agent-based service access management.

[0214] The aspects of equipment 1402 can be provided by Figure 13 The equipment 1302 is implemented. Aspects of the service management entity 1404 can be implemented by... Figure 13 The service management entity 1304 is implemented. The agent aspect 1406 can be handled by... Figure 13 The agent 1306 is implemented. The aspect of the third-party verification entity 1408 can be handled by... Figure 7A , Figure 7B and / or Figure 7C The authenticator 706, identity issuer, IDM system, device manufacturer and / or authentication service shall implement this.

[0215] Despite Figure 14 Not shown in the example, but it can be understood that in additional or alternative examples, agent 1406 may communicate with one or more other devices, agents or third-party verification entities.

[0216] exist Figure 14 In the example shown, service management entity 1404 sends policy 1410 to agent 1406. However, in other examples, agent 1406 may receive policy 1410 from a trusted third party. For example, service management entity 1404 may instruct or enable a trusted third party to configure agent 1406 with policy 1410. It is understood that in some examples, agent 1406 may request and / or obtain policy 1410 after device 1402 requests access to a service provided by service management entity 1404.

[0217] In some examples, policy 1410 may include one or more provable parameters, one or more trust score thresholds, one or more action sets, and / or one or more trust score evaluation parameters. Provable parameters may define one or more sub-states of the proof information associated with policy 1410. The trust score thresholds of policy 1410 may correspond to different access levels. For example, a first access level may be associated with a trust score greater than or equal to the trust score threshold, and a second access level may be associated with a trust score less than the trust score threshold. The action sets of policy 1410 may include one or more actions performed on the device based on the access level. For example, a first access level may be associated with a first action set, and a second access level may be associated with a second action set.

[0218] The trust score evaluation parameters of policy 1410 may include one or more triggering events that cause agent 1406 to evaluate (or re-evaluate) the device's trust score. For example, triggering events may include an initial service access request from the device, a service access request for one or more services (e.g., a request to access a specific building or building type, a request to access a specific file or file type, etc.). In some examples, the trust score evaluation parameters may indicate the frequency or number of times agent 1406 evaluates (or re-evaluates) the device's trust score (e.g., once per hour, once per day, etc.).

[0219] In the example shown, agent 1406 sends a proof request 1411 received by device 1402. In some examples, proof request 1411 may instruct agent 1406 to use one or more provable parameters to evaluate the proof. For example, agent 1406 may identify one or more provable parameters defined by policy 1410 to device 1402 via proof request 1411.

[0220] In the example shown, device 1402 sends authentication information 1412 received by agent 1406. Authentication information 1412 may include user-provable information, device-provable information, and / or network (or connectivity)-provable information. In some examples, authentication information 1412 may include one or more sub-states of the verifiable information. For example, authentication information 1412 may include one or more of device status information, user authentication status information, and / or connectivity status information. Device status information may include one or more of Basic Input / Output System (BIOS) information, Unified Extensible Firmware Interface (UEFI) information, Master Boot Loader (PBL) information, Secondary Boot Loader (SBL) information, firmware information, hypervisor information, High-Level Operating System (HLOS) information, Real-Time Operating System (RTOS) information, and / or runtime integrity information. User authentication status information may include one or more of the authentication type and result of user access to the device, activity test (e.g., if biometric authentication is used), password strength information, continuous authentication, and / or multi-factor authentication (MFA) information. Connection state information may include one or more of the following: radio frequency (RF) fingerprint information, virtual private network (VPN) information, channel type information, authentication method information, and security protocol and / or algorithm information. In some examples, proof information 1412 may include additional provable information, such as location information and / or timestamps (e.g., time and / or date). Location information may include different levels of granularity. For example, location information may include coordinate information (e.g., Global Positioning System (GPS) coordinates). In some examples, location information may include general locations such as "home," "office," etc.

[0221] At 1414, agent 1406 facilitates the verification of proof information 1412. In some examples, agent 1406 may choose to verify a subset of proof information 1412. For example, agent 1406 may choose a subset of proof information 1412 corresponding to the provable parameters of policy 1410.

[0222] In some examples, different sub-states of proof information 1412 may be associated with and / or managed by different verification entities. For example, and refer to Figure 13 For example, the proof information may include a license plate number associated with device 1302. The license plate number can then be used to determine, for example, whether device 1302 is registered with service management entity 1304, whether an authorized user is driving device 1302, whether device 1302 is within general weight limits, whether device 1302 is within weight limits based on device type, whether device 1302 is smoke compliant, and / or whether device 1302 is safety compliant.

[0223] In some examples, agent 1406 can facilitate the verification of proof information by performing verification. For example, at 1416, agent 1406 can verify the sub-state of proof information 1412. In some examples, agent 1406 can verify the sub-state of proof information 1412 based on reference information. For example, agent 1406 can determine whether device 1402 is registered in a town based on the license plate number of device 1402 and data storage including license plate numbers of devices registered in the town.

[0224] In some examples, agent 1406 can verify the sub-state of proof information 1412 based on measurement. For example, agent 1406 may be able to measure the weight of device 1402 and determine whether the weight of device 1402 is within weight limits (e.g., general weight limits and / or weight limits based on device type).

[0225] In some examples, agent 1406 may facilitate the verification of proof information by requesting a third-party verification entity to perform verification. For example, agent 1406 may send a verification result request 1418 to third-party verification entity 1408, requesting the third-party verification entity 1408 to provide a verification result for a sub-state of proof information 1412. In some examples, verification result request 1418 may include proof information 1412. For example, agent 1406 may provide a license plate number to the DMV and request the DMV to verify whether device 1402 is compliant with smoke regulations. In some examples, verification result request 1418 may include information associated with proof information 1412. For example, agent 1406 may capture an image of a user in device 1402 and send the user's image to an IDM system (e.g., Figure 1 The IDM system (199) requests the IDM system to verify the user's identity.

[0226] At 1420, third-party verification entity 1408 can perform verification of the substate of proof information 1412. Third-party verification entity 1408 can send verification result 1422 received by agent 1406. Verification result 1422 may include the verification result performed by third-party verification entity 1408 (e.g., at 1420).

[0227] At 1424, agent 1406 evaluates the trust score of device 1402 based on the verification results. For example, agent 1406 may evaluate the trust score of device 1402 based on the calculation of applying weight values ​​to each verification result. In some examples, the weight values ​​may be provided by policy 1410 and may be based on corresponding provable parameters defined by policy 1410.

[0228] At 1426, agent 1406 determines the access level of device 1402 based on policy 1410 and the trust score of device 1402. For example, policy 1410 may include one or more trust score thresholds. In some examples, agent 1406 may determine a first access level for device 1402 when the trust score is greater than (or equal to) a trust score threshold, and a second access level for device 1402 when the trust score is less than a trust score threshold. In some examples, the first access level may allow access to a service (e.g., access to a town), and the second access level may deny access to the service (e.g., deny or block access to the town). In some examples, the first access level may allow full access to the service, and the second access level may allow limited access to the service (e.g., deny or block access to a portion of the town). In some examples, the first access level may be associated with a first priority, and the second access level may be associated with a second priority that is less than the first priority. For example, the first priority may allow device 1402 to travel within the town at a faster speed than the second priority.

[0229] At 1428, agent 1406 enforces a policy on device 1402. For example, based on a trust score, agent 1406 can enforce a corresponding access level to device 1402. In some examples, the corresponding access level can be associated with a set of actions. In some examples, agent 1406 can enforce a policy on device 1402 by enforcing a set of actions on device 1402. For example, to deny or prevent device 1402 from accessing a town, agent 1406 can set up a roadblock. In some examples, agent 1406 can enforce a policy on device 1402 by causing device 1402 to enforce a set of actions. For example, to deny or prevent device 1402 from accessing a town, agent 1406 can cause device 1402 to turn around. In some examples, the set of actions can include one or more actions that can be performed by agent 1406, one or more actions that can be performed by device 1402, and / or one or more actions that can be performed by a trusted third party.

[0230] At 1430, agent 1406 can reassess the trust score of device 1402. In some examples, agent 1406 can periodically reassess the trust score of device 1402 (e.g., based on the trust score assessment parameters of policy 1410). In some examples, agent 1406 can reassess the trust score of device 1402 based on the occurrence of a triggering event. For example, a triggering event may include a request to access one or more services (e.g., a request to access a specific building or building type). In some examples, agent 1406 can reassess the trust score of device 1402 by requesting proof information from device 1402, verifying one or more substates of the proof information, and assessing an updated trust score based on the corresponding verification results (e.g., as described above in conjunction with 1414 and 1424).

[0231] At 1432, agent 1406 can update the policy enforcement of device 1402. In some examples, agent 1406 can update the policy enforcement of device 1402 by determining an updated access level based on a new trust score (e.g., as described above in conjunction with 1426). In some examples, policy 1410 can be changed based on one or more of the following: an increase in provable parameters(multiple), a decrease in provable parameters(multiple), time of day, traffic volume, bandwidth usage, network conditions, anomaly detection, etc.

[0232] Therefore, it is understood that the techniques disclosed herein enable service management entity 1404 and agent 1406 to adopt adaptive configurations that include continuous, periodic, and / or on-demand trust score assessments of device 1402. Furthermore, it is understood that by managing access to services provided by service management entity 1404 based on trust score assessments based on one or more verification results, different access levels can be allowed based on the corresponding verification results. For example, instead of denying access to a town based on a verification result indicating that device 1402 has not performed a smoke check (or has not performed a smoke check during a compliant period), the example techniques disclosed herein allow device 1402 to access the town, for example, with restricted access. Furthermore, the set of actions associated with restricted access may include causing device 1402 to perform a smoke check during a threshold period for accessing the town.

[0233] Figure 15 This is flowchart 1500 of the trust management method. This method can be implemented by a network manager (e.g., Figure 8 Network Health Manager 804 Figure 9 Network Health Manager 904 Figure 10 Basic node 1004 and / or edge node 1006 Figure 11 Router 1122 and / or edge node 1126, and / or Figure 12 The network health manager 1204 (device 2102) executes this method. This method can promote self-managed trusted networks, increase privacy, and also manage the network to a trusted and healthy level.

[0234] At point 1502, the network manager registers network endpoints with the networks managed by the network manager, such as in conjunction with... Figure 4 Communication process 400, in Figure 9 910 performs ID registration and / or Figure 12 The 1214 section describes the execution of ID registration. In some examples, the network endpoint can connect to the network manager. In some examples, registering a network endpoint may include exchanging information with the network endpoint. In some examples, the network manager may send a credential request to the network endpoint after performing initial authentication of the network endpoint. In some examples, when exchanging information with the network endpoint, the network manager may authenticate the message using the network manager's credentials before sending the authenticated message to the network endpoint. In some examples, when exchanging information with the network endpoint, the network manager may use the network manager's credentials to decrypt messages received from the network endpoint. At 1502, the registration of the network endpoint can be performed by... Figure 21 The identity registration component 2142 of the device 2102 is used to perform this.

[0235] At 1504, the network manager receives trusted reference information for network endpoints based on registered network endpoints, such as in conjunction with... Figure 12 As stated in trusted reference information 1218. In 1504, it can be obtained from... Figure 21 The trusted reference information component 2140 of the device 2102 performs the reception of trusted reference information. In some examples, the first device may receive trusted reference information for each network endpoint communicating with the network manager. In some examples, the network manager may receive trusted reference information for a set of network endpoints communicating with the network manager. In some examples, the network manager may receive trusted reference information from an authentication information service associated with the network endpoints, such as in conjunction with... Figure 12 The subscription request 1216 describes this. For example, the network manager can subscribe to a service provided by the authentication information service to receive notifications of software updates and / or updated trusted reference information.

[0236] At point 1506, the network endpoint performs verification based on at least one of trusted reference information or proof, such as combining... Figure 12 As stated in proof 1226. In some examples, the network manager can perform network endpoint verification periodically. In some examples, the network manager can perform network endpoint verification on demand. In some examples, the network manager can perform network endpoint verification in response to the occurrence of a triggering event. In some examples, the network manager can initiate verification execution by querying device status information from the network endpoint according to a policy. In 1506, the execution of network endpoint verification can be performed by... Figure 21 The verification component 2146 of the device 2102 is used to perform the verification.

[0237] At point 1508, the network manager enforces policies on network endpoints based on the authentication results, such as combining... Figure 12 As described in 1230, 1232, and / or 1234. At 1508, it can be determined by... Figure 21 The policy enforcement component 2150 of the apparatus 2102 performs policy enforcement on network endpoints. In some examples, the policy may include at least one of network access level or configuration, service access or authorization level or configuration, QoS level or configuration, resource access level or configuration, trust level or configuration, and trust event remediation.

[0238] In some examples, implementing policies on network endpoints may include monitoring the connection health of the network endpoint and / or monitoring the device health of the network endpoint, such as combining... Figure 8 As described in section 818. In some examples, enforcing policies on network endpoints can modify network access control of the network endpoint, restrict the functional capabilities of the network endpoint, adjust the QoS level of the network endpoint, and / or force software updates to the network endpoint, such as in combination with Figure 8 As described in section 812. In some examples, implementing policies on network endpoints may include providing software updates to the network endpoints, such as in conjunction with... Figure 8814 and / or Figure 12 As described in sections 1, 2, 3, and 4. The following is in conjunction with... Figure 14 This describes aspects of providing software updates in accordance with the teachings disclosed herein. In some examples, implementing policies for network endpoints may include restricting the information about network endpoints provided to third parties, such as in conjunction with... Figure 8 As described in section 816. In some examples, enforcing policies on network endpoints may include controlling user access to services or resources based on user authentication, such as in conjunction with... Figure 11 As described by bad user 1101a.

[0239] Figure 16 This is flowchart 1600 of the trust management method. This method can be implemented by a network manager (e.g., Figure 8 Network Health Manager 804 Figure 9 Network Health Manager 904 Figure 10 Basic node 1004 and / or edge node 1006 Figure 11 Router 1122 and / or edge node 1126, and / or Figure 12 The network health manager 1204 (device 2102) executes this method. This method can promote self-managed trusted networks, increase privacy, and also manage the network to a trusted and healthy level.

[0240] At point 1602, the network manager registers network endpoints with the networks managed by the network manager, such as in conjunction with... Figure 4 Communication process 400, in Figure 9 910 performs ID registration and / or Figure 12 The 1214 section describes the execution of ID registration. In some examples, the network endpoint can connect to the network manager. In some examples, registering a network endpoint may include exchanging information with the network endpoint. For example, at 1604, the network manager may send a credential request to the network endpoint, such as in conjunction with... Figure 4 The credential request is described in 423. In some examples, the network manager may send a credential request to the network endpoint after performing initial authentication on the network endpoint. At 1606, the network manager may receive a credential response from the network endpoint, as in conjunction with... Figure 4 The credential response 425 describes this. At 1608, when registering a device identifier with the network manager, the network manager can send a credential registration response to the network endpoint, as described in conjunction with... Figure 4The credential registration response 427 describes this. In some examples, when exchanging information with a network endpoint, the network manager can authenticate the message using the network manager's credentials before sending the authenticated message to the network endpoint. In some examples, when exchanging information with a network endpoint, the network manager can use the network manager's credentials to decrypt a message received from the network endpoint. At 1602, 1604, 1606, and 1608, aspects of network endpoint registration can be provided by... Figure 21 The identity registration component 2142 of the device 2102 is used to perform this.

[0241] At point 1610, the network manager can receive trusted reference information about network endpoints from one or more trusted third parties based on the registered network endpoints, such as in conjunction with... Figure 12 As stated in trusted reference information 1218. In 1610, it can be obtained from... Figure 21 The trusted reference information component 2140 of the device 2102 performs the reception of trusted reference information. In some examples, the first device may receive trusted reference information for each network endpoint communicating with the network manager. In some examples, the network manager may receive trusted reference information for a set of network endpoints communicating with the network manager. In some examples, the network manager may receive trusted reference information from an authentication information service associated with the network endpoints, such as in conjunction with... Figure 12 The subscription request 1216 describes this. For example, the network manager can subscribe to a service provided by the authentication information service to receive notifications of software updates and / or updated trusted reference information.

[0242] At point 1612, the network manager can obtain policies for managing network endpoints, such as combining... Figure 12 As described in strategy 1222. In some examples, a strategy obtained for managing network endpoints may include one or more remedial measures based on the trust level associated with the network endpoint and / or the operational purpose associated with the network endpoint. For example, remedial measures for managing a first network endpoint associated with a first trust level may include disabling the first network endpoint, while remedial measures for a second network endpoint associated with a second trust level may include enabling the second network endpoint to update software. At 1612, it may be provided by Figure 21The policy retrieval component 2144 of device 2102 performs policy retrieval. In some examples, the network manager may use a proof verifier associated with the network endpoint to retrieve policies for managing the network endpoint from one or more trusted third parties. In some examples, managing the network endpoint may include enforcing policies against the network endpoint. In some examples, the proof verifier may include the policy location (e.g., URL) of the entity (e.g., a web server) that hosts the policies for the network endpoint. In some examples, the policy may be a MUD file. In some examples, the network manager may receive policies for enforcing against the network endpoint from the network owner. In some examples, one or more policies may be updatable policies.

[0243] At point 1614, the network endpoint performs verification based on at least one of trusted reference information or proof, such as combining... Figure 12 As stated in proof 1226. In some examples, the network manager may perform network endpoint verification periodically. In some examples, the network manager may perform network endpoint verification on demand. In some examples, the network manager may perform network endpoint verification in response to the occurrence of a triggering event. In some examples, the network manager may initiate verification execution by querying device status information from the network endpoint according to a policy.

[0244] In some examples, performing network endpoint verification may include receiving proof of the network endpoint in 1616, such as in conjunction with Figure 12 As stated in proof 1226. This proof may be based on one or more of the network endpoint's device identifier, the network endpoint's persistent credentials, or the network endpoint's device state. In some examples, at least one of the device identifier and persistent credentials may be stored in a trusted environment of the network endpoint, such as a secure element (e.g., Figure 10 (Security element 1054). It can be understood that a security element can be configured such that the information stored in the security element is immutable.

[0245] In some examples, performing verification may include determining the verification result based on proof and trusted reference information, such as combining... Figure 12 As described in section 1228. In some examples, determining the verification result may include determining that a trust event has occurred. For example, a network manager may determine the occurrence of a trust event based on the device state of a network endpoint.

[0246] In some examples, performing authentication may include performing user authentication on the network endpoint at 1620, such as in combination with Figure 11The bad user 1101a and the first downstream node 1102b are described. In some examples, performing user authentication may include receiving a device certificate including the user authentication result from the network endpoint. In 1614, 1616, 1618, and 1620, the aspect of performing network endpoint authentication may be determined by... Figure 21 The verification component 2146 of the device 2102 is used to perform the verification.

[0247] At point 1622, the network manager can report the verification results to at least one of one or more trusted third parties, such as in conjunction with... Figure 12 As stated in message 1236. In 1622, the report of the verification results can be made by... Figure 21 The reporting component 2148 of the device 2102 performs the operation.

[0248] At point 1624, the network manager enforces policies on network endpoints based on the authentication results, such as combining... Figure 12 As described in 1230, 1232, and / or 1234. In 1624, it can be derived from... Figure 21 The policy enforcement component 2150 of the apparatus 2102 performs policy enforcement on network endpoints. In some examples, the policy may include at least one of network access level or configuration, service access or authorization level or configuration, QoS level or configuration, resource access level or configuration, trust level or configuration, and trust event remediation.

[0249] In some examples, implementing policies on network endpoints may include monitoring the connection health of the network endpoint and / or monitoring the device health of the network endpoint, such as combining... Figure 8 As described in section 818. In some examples, enforcing policies on network endpoints can modify network access control of the network endpoint, restrict the functional capabilities of the network endpoint, adjust the QoS level of the network endpoint, and / or force software updates to the network endpoint, such as in combination with Figure 8 As described in section 812. In some examples, implementing policies on network endpoints may include providing software updates to the network endpoints, such as in conjunction with... Figure 8 814 and / or Figure 12 As described in sections 1, 2, 3, and 4. The following is in conjunction with... Figure 14 This describes aspects of providing software updates in accordance with the teachings disclosed herein. In some examples, implementing policies for network endpoints may include restricting the information about network endpoints provided to third parties, such as in conjunction with... Figure 8 As described in section 816. In some examples, enforcing policies on network endpoints may include controlling user access to services or resources based on user authentication, such as in conjunction with... Figure 11 As described by bad user 1101a.

[0250] In some examples, at 1626, the network manager can resolve trust events based on policies, such as combining... Figure 12 As stated in 1232. In 1626, the resolution of trust incidents can be handled by... Figure 21 The trust event handling component 2152 of the device 2102 performs the following actions. In some examples, the network manager may resolve a trust event by disabling user access via the network endpoint, forcing a software update of the network endpoint, restarting the network endpoint, resetting the network endpoint, and / or disconnecting the network endpoint from network access. In some examples, the network manager may also verify that the trust event was successfully resolved on the network endpoint. In some examples, resolving a trust event may include providing a trust event report to a third-party device manager based on the determination that the network manager cannot resolve the trust event. In some examples, the network manager may provide a trust event report to the network system or edge component for analysis of the trust event. The trust event report may include one or more trust event indications and / or one or more trust event remedies. For example, the trust event report may include indications identifying one or more trust events. The trust event report may additionally or alternatively include one or more trust event remedies attempted by the network manager to resolve the trust event and / or indications of trust event remedies applied by the network manager to resolve the trust event.

[0251] At point 1628, the network manager can provide notifications of trust events to the network system or edge components, such as in conjunction with... Figure 10 As stated above. In 1628, the provision of notification of trust events could be by... Figure 21 The trust event handling component 2152 of the device 2102 performs the operation. In some examples, the notification of a trust event may include a trust event report.

[0252] Figure 17 This is flowchart 1700 of the trust management method. This method can be implemented by a network manager (e.g., Figure 8 Network Health Manager 804 Figure 9 Network Health Manager 904 Figure 10 Basic node 1004 and / or edge node 1006 Figure 11 Router 1104 and / or edge node 1108, and / or Figure 12 The network health manager 1204 (device 2102) performs this operation. This method can facilitate software updates to network endpoints while maintaining the privacy of the network endpoints.

[0253] At 1702, the network manager can receive temporary credentials from the network endpoint, such as in conjunction with... Figure 9 As described in temporary credential 916. In 1702, the receipt of the temporary credential can be by... Figure 21The credential processing component 2154 of the device 2102 performs the operation. In some examples, the temporary credential may be based on at least one of a public-private key pair, a public key, a hash of the public key, or an identifier associated with the temporary credential.

[0254] At 1704, the network manager can determine the validity of temporary credentials, such as by combining... Figure 9 As stated in 918. In 1704, the validity of a temporary certificate can be determined by... Figure 21 The credential processing component 2154 of the device 2102 performs this action. In some examples, the network manager may register temporary credentials in response to a determination that the temporary credentials are valid.

[0255] At point 1706, the network manager can receive software updates for network endpoints from a first trusted third party, such as in conjunction with... Figure 9 As described in software update 924. In 1706, the software update can be received by... Figure 21 The software processing component 2156 of the device 2102 executes. In some examples, the network manager may receive software updates in response to periodic verification reports, notifications based on network endpoint subscriptions, and / or requests from the network manager including temporary credentials for the network endpoint.

[0256] At point 1708, the network manager can provide software updates to network endpoints, such as in conjunction with... Figure 9 As described in software update 928. In 1708, software updates can be provided by... Figure 21 The software processing component 2156 of the device 2102 executes the update. In some examples, the network manager may provide software updates based on verification of the network endpoint. In some examples, the network manager may provide software updates based on verification of the signature of a software update provided by a first trusted third party. In some examples, the network manager may provide software updates to the network endpoint based on a software update policy, such as in conjunction with... Figure 9 As stated in 926.

[0257] At 1710, the network manager can receive proof from the network endpoint, such as in combination. Figure 9 As stated in proof 930. In 1710, the acceptance of the proof may be by… Figure 21 The proof processing component 2158 of the device 2102 is executed.

[0258] At point 1712, the network manager can provide instructions to the first trusted third party regarding proof, such as in conjunction with... Figure 9 The proof instruction 932 is as described. For example, it can be provided by Figure 21 The proof processing component 2158 of the device 2102 performs the provision of proof instructions.

[0259] At point 1714, the network manager can receive software activation codes from a first trusted third party, such as in conjunction with... Figure 9 As described in software activation code 934. In 1714, the software activation code can be received by... Figure 21 The activation code processing component 2160 of the device 2102 performs this function. In some examples, the network manager may receive a software activation code from a first trusted third party in response to an activation instruction.

[0260] At point 1716, the network manager can provide software activation codes to network endpoints, such as in conjunction with... Figure 9 As described in software activation code 936. For example, the software activation code can be provided by... Figure 21 The activation code processing component 2160 of the device 2102 performs the operation.

[0261] At point 1718, the network manager can verify that the software update was successfully completed on the network endpoint, such as in conjunction with... Figure 9 As described in 938. For example, verifying a successful software update can be done by... Figure 21 The software processing component 2156 of the device 2102 executes the process.

[0262] Figure 18 This is flowchart 1800 of a trust management method. This method can be implemented by a network endpoint (e.g., Figure 1 User equipment 103 Figure 2 User equipment 212, Figure 4 Equipment 404 Figure 5 Equipment 502 Figure 6 Equipment 604 Figure 9 Network endpoint 902 and / or Figure 11 Nodes 1102, 1103, 1105), UE (e.g., Figure 1 UE 104 Figure 3 UE 350 and / or Figure 10 UE1002), and the certifier (e.g., Figure 7A , Figure 7B and / or Figure 7C (Proofreader 702) Figure 8 Device 803 and / or Figure 21 The device 2102 is used to perform this. This method can promote self-managed trust networks, increase privacy, and also manage the network to a trusted and healthy level.

[0263] At 1802, the network endpoint provides the network manager with temporary credentials for the network endpoint, such as in conjunction with... Figure 9As described in 916, a temporary credential may be based on a persistent credential of a network endpoint. In some examples, a temporary credential may be based on at least one of a public-private key pair, a public key, a hash of a public key, or an identifier associated with the temporary credential. In 1802, the provision of a temporary credential may be by… Figure 21 The credential processing component 2154 of the device 2102 is executed.

[0264] At 1804, the network endpoint receives access or authorization for a service or resource from the network manager, such as in conjunction with... Figure 8 As described above. In some examples, access or authorization can be based on temporary credentials from a network endpoint. In 1804, receiving access or authorization can be done by... Figure 21 The authorized component 2162 of the device 2102 is executed.

[0265] Figure 19 This is flowchart 1900 of a trust management method. This method can be implemented by a network endpoint (e.g., Figure 1 User equipment 103 Figure 2 User equipment 212, Figure 4 Equipment 404 Figure 5 Equipment 502 Figure 6 Equipment 604 Figure 9 Network endpoint 902 and / or Figure 11 Nodes 1102, 1103, 1105), UE (e.g., Figure 1 UE 104 Figure 3 UE 350 and / or Figure 10 UE1002), and the certifier (e.g., Figure 7A , Figure 7B and / or Figure 7C (Proofreader 702) Figure 8 Device 803 and / or Figure 21 The device 2102 is used to execute this method. This method can promote privacy in self-managed trust networks while also managing the network to a trusted and healthy level.

[0266] At point 1902, the network endpoint provides the network manager with temporary credentials for the network endpoint, such as in conjunction with... Figure 9 As described in 916, a temporary credential may be based on a persistent credential of a network endpoint. In some examples, a temporary credential may be based on at least one of a public-private key pair, a public key, a hash of a public key, or an identifier associated with the temporary credential. In 1902, the provision of a temporary credential may be by… Figure 21 The credential processing component 2154 of the device 2102 performs the operation.

[0267] At point 1904, network endpoints receive access or authorization for services or resources from the network manager, such as in conjunction with... Figure 8 As described above. In some examples, access or authorization can be based on temporary credentials from a network endpoint. In 1904, receiving access or authorization can be... Figure 21 The authorized component 2162 of the device 2102 is executed.

[0268] At point 1906, a network endpoint can perform user authentication for the user of the network endpoint, such as in conjunction with... Figure 11 As described by user 1101a and the first downstream node 1102b. In some examples, user authentication can be performed based on one or more of password, biometrics, trusted location, multi-factor authentication, or continuous authentication. In 1906, user authentication can be performed by... Figure 21 The verification component 2146 of the device 2102 is used to perform the verification.

[0269] At point 1908, network endpoints can provide the network manager with proof including user authentication results, such as in conjunction with... Figure 12 As stated in proof 1226. In 1908, the provision of proof, including user verification results, could be provided by... Figure 21 The device 2102 uses the proof processing component 2158 to perform the operation.

[0270] At point 1910, network endpoints can receive software updates from a first trusted third party via a network manager, such as in conjunction with... Figure 9 As described in software update 928. In 1910, the software update can be received by... Figure 21 The software processing component 2156 of the device 2102 executes.

[0271] At point 1912, network endpoints can provide proof to the network manager, such as in conjunction with... Figure 9 As stated in proof 930. In 1912, the proof could be provided by... Figure 21 The device 2102 uses the proof processing component 2158 to perform the operation.

[0272] At point 1914, the network endpoint can receive a software activation code from a first trusted third party via the network manager, such as in conjunction with... Figure 9 As described in software activation code 936. In 1914, the software activation code could be received by... Figure 21 The activation code processing component 2160 of the device 2102 is executed.

[0273] At point 1916, network endpoints could perform software updates, such as in conjunction with... Figure 9 As stated in 938. In 1916, software updates could be performed by... Figure 21 The software processing component 2156 of the device 2102 executes the process.

[0274] Figure 20This is a flowchart of a trust management method (2000). This method can be implemented by a network manager (e.g., Figure 8 Network Health Manager 804 Figure 9 Network Health Manager 904 Figure 10 Basic node 1004 and / or edge node 1006 Figure 11 Router 1122 and / or edge node 1126, and / or Figure 12 The network health manager 1204 (device 2102) executes this method. This method can promote self-managed trusted networks, increase privacy, and also manage the network to a trusted and healthy level.

[0275] In 2002, the Network Manager registered network endpoints with the networks managed by the Network Manager, such as in conjunction with... Figure 4 Communication process 400, in Figure 9 910 performs ID registration and / or Figure 12 The 1214 execution ID registration is described above. In some examples, the network endpoint can connect to the network manager. In some examples, registering a network endpoint may include exchanging information with the network endpoint. In some examples, the network manager may send a credential request to the network endpoint after performing initial authentication of the network endpoint. In some examples, when exchanging information with the network endpoint, the network manager may authenticate the message using the network manager's credentials before sending the authenticated message to the network endpoint. In some examples, when exchanging information with the network endpoint, the network manager may use the network manager's credentials to decrypt messages received from the network endpoint. In 2002, network endpoint registration can be performed by... Figure 21 The identity registration component 2142 of the device 2102 is used to perform this.

[0276] In 2004, the network manager received trusted reference information for network endpoints based on registered network endpoints, such as in conjunction with... Figure 12 As stated in trusted reference information 1218. At 2004, it can be obtained from... Figure 21 The trusted reference information component 2140 of the device 2102 performs the reception of trusted reference information. In some examples, the first device may receive trusted reference information for each network endpoint communicating with the network manager. In some examples, the network manager may receive trusted reference information for a set of network endpoints communicating with the network manager. In some examples, the network manager may receive trusted reference information from an authentication information service associated with the network endpoints, such as in conjunction with... Figure 12 The subscription request 1216 describes this. For example, the network manager can subscribe to a service provided by the authentication information service to receive notifications of software updates and / or updated trusted reference information.

[0277] In 2006, network endpoints query device information from network endpoints according to network manager policies implemented by the network manager, such as combining... Figure 12 As described in status query 1224. At 2006, queries for network endpoints could be made by... Figure 21 The verification component 2146 of the device 2102 is used to perform the verification.

[0278] In 2008, when a trust event occurs, the Network Manager executes one or more trust event remediation actions according to the Network Manager policy, such as combining... Figure 12 As described in section 1232. In some examples, the occurrence of a trust event may be based on a comparison of device information and trusted reference information of a network endpoint. At 2008, the execution of one or more trust event remediation measures may be carried out by... Figure 21 The policy enforcement component 2150 of the apparatus 2102 is used to execute the policy. In some examples, the policy may include at least one of network access level or configuration, service access or authorization level or configuration, QoS level or configuration, resource access level or configuration, trust level or configuration, and trust event remediation.

[0279] Figure 21Figure 2100 illustrates an example of a hardware implementation of device 2102. Device 2102 may be a UE, a component of a UE, or may implement UE functionality. In some aspects, device 2102 may include a cellular baseband processor 2104 (also referred to as a modem) coupled to a cellular RF transceiver 2122. In some aspects, device 2102 may also include one or more Subscriber Identity Module (SIM) cards 2120, an application processor 2106 coupled to a Secure Digital Card (SD) card 2108 and a screen 2110, a Bluetooth module 2112, a Wireless Local Area Network (WLAN) module 2114, a Global Positioning System (GPS) module 2116, or a power supply 2118. Cellular baseband processor 2104 communicates with UE 104 and / or base station 102 / 180 via cellular RF transceiver 2122. Cellular baseband processor 2104 may include computer-readable media / memory. The computer-readable media / memory may be non-transitory. Cellular baseband processor 2104 is responsible for general processing, including executing software stored on a computer-readable medium / memory. When executed by cellular baseband processor 2104, the software causes cellular baseband processor 2104 to perform the various functions described above. The computer-readable medium / memory can also be used to store data manipulated by cellular baseband processor 2104 during software execution. Cellular baseband processor 2104 also includes receiving component 2130, communication manager 2132, and transmission component 2134. Communication manager 2132 includes one or more of the components shown. Components within communication manager 2132 may be stored in computer-readable medium / memory and / or configured as hardware within cellular baseband processor 2104. Cellular baseband processor 2104 may be a component of UE 350 and may include memory 360 and / or at least one of TX processor 368, RX processor 356, and controller / processor 359. In one configuration, device 2102 may be a modem chip and include only the cellular baseband processor 2104; in another configuration, device 2102 may be the entire UE (e.g., see...). Figure 3 The UE 350 includes an additional module for device 2102.

[0280] Communication manager 2132 includes trusted reference information component 2140, which is configured to receive trusted reference information from network endpoints based on registered network endpoints, for example, as in combination with Figure 15 1504 and / or Figure 16 As described in 1610. Example trusted reference information component 2140 can also be configured to receive trusted reference information from a network endpoint based on a registered network endpoint, for example, as in conjunction with... Figure 20 As stated in 2004.

[0281] Communication manager 2132 also includes identity registration component 2142, which is configured to register network endpoints with the network managed by network manager, for example, as in combination with Figure 15 1502 and / or Figure 16 As described in 1602. Example identity registration component 2142 can also be configured to send a credential request to the network endpoint after performing authentication on the network endpoint, for example, as in conjunction with... Figure 16 As described in 1604. Example identity registration component 2142 can also be configured to receive credential responses from network endpoints, for example, as in conjunction with... Figure 16 As described in 1606. Example identity registration component 2142 can also be configured to send a credential registration response to a network endpoint when registering a device identifier with a network manager, for example, as in conjunction with... Figure 16 As described in 1608. Example identity registration component 2142 can also be configured to register network endpoints with networks managed by a network manager, for example, as in conjunction with... Figure 20 As stated in 2002.

[0282] Communication manager 2132 also includes policy acquisition component 2144, which is configured to acquire policies for managing network endpoints, for example, as in combination with Figure 16 As stated in 1612.

[0283] Communication manager 2132 also includes verification component 2146, which is configured to perform network endpoint verification based on at least one of trusted reference information received from one or more trusted third parties or proof received from the network endpoint, for example, as in combination with Figure 15 1506 and / or Figure 16 As described in 1614. Example verification component 2146 can also be configured to receive proof from a network endpoint, for example, as in conjunction with... Figure 16 As described in 1616. Example verification component 2146 can also be configured to determine verification results based on proof and trusted reference information, for example, as in combination with... Figure 16 As described in 1618. Example verification component 2146 can also be configured to perform user verification for users of network endpoints, for example, as in conjunction with... Figure 16 As described in 1620. Example verification component 2146 can also be configured to perform user verification for users of network endpoints, for example, as in conjunction with... Figure 19 As described in 1906. Example verification component 2146 can also be configured to query device information from network endpoints based on network manager policies implemented by the network manager, for example, as in conjunction with... Figure 20 As stated in 2006.

[0284] Communication manager 2132 also includes a reporting component 2148, which is configured to report verification results to at least one trusted third party, for example, as in combination with Figure 16 As stated in 1622.

[0285] Communication manager 2132 also includes policy enforcement component 2150, which is configured to enforce policies on network endpoints based on the results of authentication, for example, as in combination with Figure 15 1508 and / or Figure 16 As described in 1624. Example policy implementation component 2150 can also be configured to perform one or more trust event remediation actions according to the network manager policy when a trust event occurs, for example, as in conjunction with... Figure 20 As stated in 2008.

[0286] The communication manager 2132 also includes a trust event handling component 2152, which is configured to resolve the occurrence of trust events, for example, as in conjunction with Figure 16 As described in 1626. Example trust event handling component 2152 can also be configured to provide notification of trust events to network systems or edge components, for example, as in conjunction with... Figure 16 As stated in 1628.

[0287] Communication manager 2132 also includes credential processing component 2154, which is configured to receive temporary credentials from network endpoints, for example, as in combination with Figure 17 As described in 1702. Example credential processing component 2154 can also be configured to determine the validity of temporary credentials, for example, as in conjunction with... Figure 17 As described in 1704. Example credential processing component 2154 can also be configured to provide temporary credentials for network endpoints to the network manager, for example, as in conjunction with... Figure 18 1802 and / or Figure 19 As stated in 1902.

[0288] Communication manager 2132 also includes software processing component 2156, which is configured to receive software updates for network endpoints from a first trusted third party, for example, as in conjunction with Figure 17 As described in 1706. Example software processing component 2156 can also be configured to provide software updates to network endpoints, for example, as in conjunction with... Figure 17 As described in 1708. Example software processing component 2156 can also be configured to verify successful completion of the software update, for example, as in conjunction with... Figure 17 As described in 1718. Example software processing component 2156 can also be configured to receive software updates from a first trusted third party via a network manager, for example, as in conjunction with... Figure 19 As described in 1910. Example software processing component 2156 can also be configured to perform software updates, for example, as in conjunction with... Figure 19 As stated in 1916.

[0289] Communication manager 2132 also includes proof processing component 2158, which is configured to receive proofs from network endpoints, for example, as in combination with Figure 17 As described in 1710. Example proof processing component 2158 can also be configured to provide an instruction to a first trusted third party, for example, as in conjunction with... Figure 17 As described in 1712. Example proof processing component 2158 can also be configured to provide the network manager with proof including the user verification result, for example, as in conjunction with... Figure 19 As described in 1908. Example proof processing component 2158 can also be configured to provide proofs to the network manager, for example, as in conjunction with... Figure 19 As stated in 1912.

[0290] Communication manager 2132 also includes activation code processing component 2160, which is configured to receive software activation codes from a first trusted third party, for example, as in combination with Figure 17 As described in 1714. The example activation code processing component 2160 can also be configured to provide software activation codes to endpoints, for example, as in conjunction with... Figure 17 As described in 1716. The example activation code processing component 2160 can also be configured to receive software activation codes, for example, as in conjunction with... Figure 19 As stated in 1914.

[0291] The communication manager 2132 also includes an authorization component 2162, which is configured to receive access to or authorization for services or resources from the network manager, for example, as in conjunction with Figure 18 1804 and / or Figure 19 As stated in 1904.

[0292] The device may include execution Figures 15 to 20 The flowchart shows additional components for each block of the algorithm. Therefore, Figures 15 to 20 Each block in the flowchart can be executed by a component, and the apparatus can include one or more of these components. These components can be one or more hardware components specifically configured to execute the process / algorithm, implemented by a processor configured to execute the process / algorithm, stored in a computer-readable medium for processor implementation, or some combination thereof.

[0293] As shown in the figure, apparatus 2102 may include various components configured for various functions. In one configuration, apparatus 2102, particularly cellular baseband processor 2104, includes components for registering network endpoints with a network managed by a network manager. Example apparatus 2102 also includes components for receiving trusted reference information about the network endpoints based on the registered network endpoints. Example apparatus 2102 also includes components for performing authentication of the network endpoints based on at least one of trusted reference information or proof received from the network endpoints. Example apparatus 2102 also includes components for enforcing policies on the network endpoints based on the authentication results.

[0294] In another configuration, example device 2102 also includes components for receiving proof from a network endpoint. Example device 2102 also includes components for determining a verification result based on the proof and trusted reference information.

[0295] In another configuration, example device 2102 also includes components for receiving trusted reference information for each network endpoint communicating with the network manager.

[0296] In another configuration, example device 2102 also includes components for receiving trusted reference information about a set of network endpoints in communication with a network manager.

[0297] In another configuration, example device 2102 also includes components for performing network endpoint authentication periodically, on demand, or in response to the occurrence of a triggering event.

[0298] In another configuration, example device 2102 also includes a component for reporting verification results to at least one trusted third party.

[0299] In another configuration, example device 2102 also includes components for monitoring the connection health of network endpoints. Example device 2102 also includes components for monitoring the device health of network endpoints.

[0300] In another configuration, example device 2102 also includes components for modifying network access control of the network endpoint. Example device 2102 also includes components for limiting the functional capabilities of the network endpoint. Example device 2102 also includes components for adjusting the QoS level of the network endpoint. Example device 2102 also includes components for forcing software updates to the network endpoint.

[0301] In another configuration, example device 2102 also includes components for receiving software updates from a trusted third party at the network endpoint. Example device 2102 also includes components for providing software updates to the network endpoint based on authentication of the network endpoint. Example device 2102 also includes components for verifying that the software update was successfully completed on the network endpoint based on a second proof from the network endpoint.

[0302] In another configuration, example device 2102 also includes components for performing user authentication for users of network endpoints. Example device 2102 also includes components for controlling user access to services or resources based on user authentication.

[0303] In another configuration, example device 2102 also includes a component for receiving a device certificate, including a user authentication result, from a network endpoint.

[0304] In another configuration, example device 2102 also includes components for sending a credential request to the network endpoint after performing authentication of the network endpoint. Example device 2102 also includes components for receiving a credential response from the network endpoint. Example device 2102 further includes components for sending a credential registration response to the network endpoint when registering a device identifier with a network manager, wherein the network manager receives trusted reference information of the network endpoint from one or more trusted third parties after registering the device identifier of the network endpoint.

[0305] In another configuration, example device 2102 also includes a component for retrieving, using a proof verifier associated with the network endpoint, a policy to be implemented against the network endpoint from one or more trusted third parties.

[0306] The component may be one or more components of device 2102, configured to perform the functions described herein. As described above, device 2102 may include TX processor 368, RX processor 356, and controller / processor 359. Therefore, in one configuration, the component may be TX processor 368, RX processor 356, and controller / processor 359 configured to perform the functions described herein.

[0307] Figure 22 This is a flowchart 2200 of an access management method. This method can be performed by a trusted agent (e.g., UE 104, agent 1306, and / or agent 1406; device 2602). This method can help improve access management of services or resources based on the results of the verification.

[0308] At 2202, the trust agent receives authentication information from the device requesting access to a service or resource provided by the service management entity, such as in conjunction with... Figure 14 The proof information is as described in 1412. At 2202, the proof information can be received by... Figure 26 The proof receiving component 2640 of the device 2602 performs the proof receiving. In some examples, the proof information may include at least one of user-provable information, device-provable information, or network-provable information.

[0309] In some examples, the proof information may include first provable information associated with or managed by a first verification entity and second provable information associated with or managed by a second verification entity. In some examples, the first verification entity and the second verification entity may be the same verification entity. In some examples, the first verification entity may be different from the second verification entity.

[0310] In some examples, the first verification entity may include a trust proxy. In some examples, the trust proxy may determine the verification result associated with the first provable information based on reference information. In some examples, the trust proxy may determine the verification result associated with the first provable information based on measurement.

[0311] In some examples, the first verification entity may include a trusted third party that is different from the trusted proxy. In some examples, the trusted proxy may receive verification results associated with the first provable information from the trusted third party. In some examples, the trusted proxy may provide the first provable information to the trusted third party, and the trusted proxy may receive verification results associated with the first provable information from the trusted third party.

[0312] At point 2204, the trust agent evaluates the device's authentication information based on an updateable policy, such as combining... Figure 14 As stated in 1424. In 2204, the evaluation of the proof information can be performed by... Figure 26 The evaluation component 2642 of the device 2602 is used to perform the evaluation.

[0313] In some examples, the trust agent may evaluate a device's proof information based on one or more verification results associated with various proof information and updatable policies. In some examples, the trust agent may evaluate a device's proof information based on one or more verification results associated with a subset of the proof information and updatable policies. In some examples, the subset of proof information may include situation-related information such as one or more of the following: the operational purpose associated with the device, the trust level associated with the device, and / or the lifecycle state associated with the device. For example, after registration, the network manager may use device manufacturer information to verify that the device has not been cloned and may disregard the use of live proof information (e.g., whether the device has a root of trust, how long since the last startup, etc.) until some later time. In some examples, the evaluation of verification results may be based on proof parameters provided by the service management entity via the updatable policy.

[0314] In some examples, the trust agent can periodically evaluate the device's authentication information. In other examples, the trust agent can evaluate the device's authentication information in response to the occurrence of a triggering event.

[0315] At point 2206, the trust agent, based on the evaluation of proof information, implements an updateable policy on the device for the services or resources provided by the service management entity, such as combining... Figure 14 As stated in 1428. At 2206, it can be obtained from... Figure 26 The policy implementation component 2644 of the device 2602 performs policy implementation on the device. In some examples, policy implementation on the device may include implementing a set of actions. In some examples, the set of actions may include one or more actions of an updatable policy selected based on a device trust score and a trust score threshold. In some examples, the device trust score may be based on an evaluation of verification results associated with proof information. In some examples, the device trust score may be based on an evaluation of an updatable policy based on verification results.

[0316] In some examples, the trust proxy can perform a set of actions on the device, or the trust proxy can enable the device to perform a set of actions on itself. In some examples, the trust proxy can perform a first subset of the action set on the device, and the trust proxy can enable the device to perform a second subset of the action set on itself. In some examples, the trust proxy can enable one or more trusted third parties to perform at least one action from the action set on the device.

[0317] In some examples, when a device's trust score is greater than or equal to a trust score threshold, the action set can be associated with a first access level to the service, and when the device's trust score is less than the trust score threshold, the action set can be associated with a second access level to the service. In some such examples, the second access level can be different from the first access level.

[0318] In some examples, when a device's trust score is greater than or equal to a trust score threshold, the action set can be associated with the service's first priority, and when the device's trust score is less than the trust score threshold, the action set can be associated with the service's second priority. In some such examples, the second priority may be lower than the first priority.

[0319] Figure 23 This is a flowchart 2300 of an access management method. This method can be performed by a trusted agent (e.g., UE 104, agent 1306, and / or agent 1406; device 2602). This method can help improve access management of services or resources based on the results of the authentication process.

[0320] At point 2302, the trust broker can receive a trust score threshold from the service management entity via an updatable policy, such as in conjunction with... Figure 14 As described in strategy 1410. At 2302, the reception of the trust score threshold can be achieved by... Figure 26 The strategy receiving component 2646 of the device 2602 executes.

[0321] At 2304, the trusted agent receives authentication information from the device requesting access to a service or resource provided by the service management entity, such as in conjunction with... Figure 14 The proof information is as described in 1412. At 2304, the proof information can be received by... Figure 26 The proof receiving component 2640 of the device 2602 performs the proof receiving. In some examples, the proof information may include at least one of user-provable information, device-provable information, or network-provable information.

[0322] In some examples, the proof information may include first provable information associated with or managed by a first verification entity and second provable information associated with or managed by a second verification entity. In some examples, the first verification entity and the second verification entity may be the same verification entity. In some examples, the first verification entity may be different from the second verification entity.

[0323] In some examples, the first verification entity may include a trust proxy. In some examples, the trust proxy may determine the verification result associated with the first provable information based on reference information. In some examples, the trust proxy may determine the verification result associated with the first provable information based on measurement.

[0324] In some examples, the first verification entity may include a trusted third party that is different from the trusted proxy. In some examples, the trusted proxy may receive verification results associated with the first provable information from the trusted third party. In some examples, the trusted proxy may provide the first provable information to the trusted third party, and the trusted proxy may receive verification results associated with the first provable information from the trusted third party.

[0325] At point 2306, the trust agent evaluates the device's authentication information based on an updateable policy, such as combining... Figure 14 As stated in 1424. At 2306, the evaluation of the proof information can be performed by... Figure 26 The evaluation component 2642 of the device 2602 is used to perform the evaluation.

[0326] In some examples, the trust agent may evaluate the device's proof information based on one or more verification results associated with various provable information of the proof information and the update policy. In some examples, the trust agent may evaluate the device's proof information based on one or more verification results associated with a subset of the proof information and the update policy. In some examples, the evaluation of verification results may be based on provable parameters provided by the service management entity via the update policy.

[0327] In some examples, the trust agent can periodically evaluate the device's authentication information. In other examples, the trust agent can evaluate the device's authentication information in response to the occurrence of a triggering event.

[0328] At point 2308, the trust agent, based on the evaluation of proof information, implements an updatable policy on the device for the services or resources provided by the service management entity, such as combining... Figure 14 As stated in 1428. At 2308, it can be obtained from... Figure 26 The policy implementation component 2644 of the device 2602 performs policy implementation on the device. In some examples, policy implementation on the device may include implementing a set of actions. In some examples, the set of actions may include one or more actions of an updatable policy selected based on a device trust score and a trust score threshold. In some examples, the device trust score may be based on an evaluation of verification results associated with proof information. In some examples, the device trust score may be based on an evaluation of an updatable policy based on verification results.

[0329] In some examples, the trust proxy can perform a set of actions on the device, or the trust proxy can enable the device to perform a set of actions on itself. In some examples, the trust proxy can perform a first subset of the action set on the device, and the trust proxy can enable the device to perform a second subset of the action set on itself. In some examples, the trust proxy can enable one or more trusted third parties to perform at least one action from the action set on the device.

[0330] In some examples, when a device's trust score is greater than or equal to a trust score threshold, the action set can be associated with a first access level to the service, and when the device's trust score is less than the trust score threshold, the action set can be associated with a second access level to the service. In some such examples, the second access level can be different from the first access level.

[0331] In some examples, when a device's trust score is greater than or equal to a trust score threshold, the action set can be associated with the service's first priority, and when the device's trust score is less than the trust score threshold, the action set can be associated with the service's second priority. In some such examples, the second priority may be lower than the first priority.

[0332] Figure 24 This is a flowchart 2400 of an access management method. This method can be performed by a device (e.g., user equipment 103, UE 104, device 1302 and / or device 1402; apparatus 2602). This method can help improve access management of services or resources based on the results of verification.

[0333] At point 2402, when requesting access to a service or resource provided by a service management entity, the device provides the trusted agent with authentication information associated with the device, such as... Figure 14 The proof information is as described in 1412. In 2402, the proof information can be provided by... Figure 26The device 2602 provides component 2648 to perform the test.

[0334] In some examples, the proof information may include at least one of user-provable information, device-provable information, or network-provable information. In some examples, the proof information may include first proveable information associated with or managed by a first verification entity and second proveable information associated with or managed by a second verification entity.

[0335] At 2404, the device, based on an evaluation of the proof information of the updatable policy, receives access from the trust agent for services or resources provided by the service management entity, such as in conjunction with... Figure 14 As described in 1428. In 2404, the receipt of access to a service or resource can be by... Figure 26 The access processing component 2650 of the device 2602 performs the operation.

[0336] Figure 25 This is a flowchart 2500 of an access management method. This method can be performed by a device (e.g., user equipment 103, UE 104, device 1302 and / or device 1402; apparatus 2602). This method can help improve access management of services or resources based on the results of verification.

[0337] At point 2504, when requesting access to a service or resource provided by a service management entity, the device provides the trusted agent with authentication information associated with the device, such as... Figure 14 The proof information is as described in 1412. In 2504, the proof information can be provided by... Figure 26 The device 2602 provides component 2648 to perform the test.

[0338] In some examples, the proof information may include at least one of user-provable information, device-provable information, or network-provable information. In some examples, the proof information may include first proveable information associated with or managed by a first verification entity and second proveable information associated with or managed by a second verification entity.

[0339] In some examples, the device can receive a request for proof information at 2502, such as in combination with Figure 14 As described in 1430. In some examples, the device may periodically receive requests for authentication information from the trust broker. In some examples, the device may receive requests for authentication information from the trust broker in response to the occurrence of a triggering event. In 2502, the receipt of requests for authentication information may be... Figure 26 The device 2602 provides proof of the execution of component 2648.

[0340] At point 2506, the device receives access from the trust broker to services or resources provided by the service management entity based on an evaluation of the proof information of the updatable policy, such as in conjunction with... Figure 14 As described in 1428. In 2506, the receipt of access to a service or resource can be by... Figure 26 The access processing component 2650 of the device 2602 performs the operation.

[0341] At point 2508, the device can perform a set of actions on the device, such as combining... Figure 14 As described in 1428. In some such examples, the action set can be based on the evaluation of proof information of an updatable policy. In some examples, a trust agent can enable a device to enforce the action set against another device. In 2508, it can be... Figure 26 The strategy implementation component 2644 of the device 2602 performs a set of actions on the device.

[0342] Figure 26Figure 2600 illustrates an example of a hardware implementation of device 2602. Device 2602 may be a UE, a component of a UE, or may implement UE functionality. In some aspects, device 2602 may include a cellular baseband processor 2604 (also referred to as a modem) coupled to a cellular RF transceiver 2622. In some aspects, device 2602 may also include one or more Subscriber Identity Module (SIM) cards 2620, an application processor 2606 coupled to a Secure Digital Card (SD) card 2608 and a screen 2610, a Bluetooth module 2612, a Wireless Local Area Network (WLAN) module 2614, a Global Positioning System (GPS) module 2616, or a power supply 2618. Cellular baseband processor 2604 communicates with UE 104 and / or base station 102 / 180 via cellular RF transceiver 2622. Cellular baseband processor 2604 may include computer-readable media / memory. The computer-readable media / memory may be non-transitory. Cellular baseband processor 2604 is responsible for general processing, including executing software stored on a computer-readable medium / memory. When executed by cellular baseband processor 2604, the software causes cellular baseband processor 2604 to perform the various functions described above. The computer-readable medium / memory can also be used to store data manipulated by cellular baseband processor 2604 during software execution. Cellular baseband processor 2604 also includes receiving component 2630, communication manager 2632, and transmission component 2634. Communication manager 2632 includes one or more of the components shown. Components within communication manager 2632 may be stored in computer-readable medium / memory and / or configured as hardware within cellular baseband processor 2604. Cellular baseband processor 2604 may be a component of UE 350 and may include memory 360 and / or at least one of TX processor 368, RX processor 356, and controller / processor 359. In one configuration, device 2602 may be a modem chip and include only cellular baseband processor 2604; in another configuration, device 2602 may be the entire UE (e.g., see...). Figure 3 The UE 350 includes an additional module for device 2602.

[0343] Communication manager 2632 includes a certificate receiving component 2640, which is configured to receive certificate information from the device, for example, as in combination with Figure 22 2202 and / or Figure 23 As stated in 2304.

[0344] Communication manager 2632 also includes evaluation component 2642, which is configured to evaluate the device's certification information based on an updatable policy, such as in conjunction with Figure 22 2204 and / or Figure 23 As stated in 2306.

[0345] Communication manager 2632 also includes policy enforcement component 2644, which is configured to enforce updatable policies on the device based on an evaluation of the proof information, for example, as in combination with Figure 22 2206 and / or Figure 23 As described in 2308. Example policy enforcement component 2644 can also be configured to enforce a set of actions on the device, for example, as in conjunction with... Figure 25 As stated in 2508.

[0346] Communication manager 2632 also includes policy receiving component 2646, which is configured to receive trust score thresholds from service management entities, for example, as in combination with Figure 23 As stated in 2302.

[0347] The communication manager 2632 also includes a certificate providing component 2648, which is configured to provide the trusted agent with certificate information associated with the device, for example, as in combination with Figure 24 2402 and / or Figure 25 As described in section 2504. Example proof providing component 2648 can also be configured to receive requests for proof information from a trust broker, for example, as in conjunction with... Figure 25 As stated in 2502.

[0348] The communication manager 2632 also includes an access processing component 2650, which is configured to receive access to a service or resource from a trust broker based on an evaluation of proof information of an updatable policy, for example, as in conjunction with Figure 24 2404 and / or Figure 25 As stated in 2506.

[0349] The device may include execution Figures 22 to 25 The flowchart shows additional components for each block of the algorithm. Therefore, Figures 22 to 25 Each block in the flowchart can be executed by a component, and the apparatus can include one or more of these components. These components can be one or more hardware components specifically configured to execute the process / algorithm, implemented by a processor configured to execute the process / algorithm, stored in a computer-readable medium for processor implementation, or some combination thereof.

[0350] As shown in the figure, apparatus 2602 may include various components configured for various functions. In one configuration, apparatus 2602, particularly cellular baseband processor 2604, includes components for receiving authentication information from a device requesting access to a service or resource provided by a service management entity. Example apparatus 2602 also includes components for evaluating the authentication information of the device based on an updatable policy. Example apparatus 2602 further includes components for implementing an updatable policy on the device for the service or resource provided by the service management entity based on the evaluation of the authentication information.

[0351] In another configuration, example device 2602 also includes components for evaluating the device’s proof information based on one or more verification results associated with each piece of proof information and updatable strategy.

[0352] In another configuration, example device 2602 also includes components for evaluating the device’s proof information based on one or more verification results associated with a subset of proof information and updatable policies.

[0353] In another configuration, example device 2602 also includes a component for evaluating one or more verification results based on provable parameters provided by a service management entity via an updatable policy.

[0354] In another configuration, example device 2602 also includes components for implementing a set of actions, wherein the set of actions includes one or more actions of an updatable policy selected based on a device trust score and a trust score threshold.

[0355] In another configuration, example device 2602 also includes a component for receiving a trust score threshold from a service management entity via an updatable policy.

[0356] In another configuration, example device 2602 also includes components for performing a set of actions on the device.

[0357] In another configuration, example device 2602 further includes components for performing a first subset of a set of actions on the device. Example device 2602 also includes components for causing the device to perform a second subset of a set of actions on the device.

[0358] In another configuration, example device 2602 also includes a component for causing one or more trusted third parties to perform at least one action from a set of actions on the device.

[0359] The component may be one or more components of device 2602, configured to perform the functions described herein. As described above, device 2602 may include TX processor 368, RX processor 356, and controller / processor 359. Therefore, in one configuration, the component may be TX processor 368, RX processor 356, and controller / processor 359 configured to perform the functions described herein.

[0360] It should be understood that the specific order or hierarchy of boxes in the disclosed process / flowchart is an illustration of the example method. Based on design preferences, it is understood that the specific order or hierarchy of boxes in the process / flowchart may be rearranged. Furthermore, some boxes may be combined or omitted. The appended method claims present the elements of various boxes in a sample order and are not intended to limit one to the specific order or hierarchy presented.

[0361] The foregoing description is provided to enable those skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but are given the full scope consistent with the language of the claims, wherein references to elements in the singular are not intended to mean “one and only one,” but rather “one or more” unless specifically stated otherwise. Terms such as “if,” “when,” and “simultaneously” should be interpreted as meaning “in this case,” rather than meaning a direct temporal relationship or reaction. That is, these phrases, such as “when,” do not imply a response to an action or an immediate action during the occurrence of the action, but simply mean that an action will occur if the condition is met, without requiring a specific or immediate time limit for the action to occur. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or superior to other aspects. Unless otherwise specifically stated, the term “some” means one or more. Combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" may be only A, only B, only C, A and B, A and C, B and C, or A and B and C, wherein any such combination may include one or more members of A, B, or C. All structural and functional equivalents of elements throughout the various aspects described in this disclosure that are known or subsequently known to those skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended specifically for the public, regardless of whether the disclosure is expressly recited in the claims. The terms “module,” “mechanism,” “element,” and “device” cannot replace the term “component.” Therefore, no claim element should be interpreted as a component plus a function unless the element is explicitly stated using the phrase “component is used for.”

[0362] The following aspects are illustrative only and may be combined with other aspects or teachings described herein without limitation.

[0363] Aspect 1 is an apparatus for trust management at a network manager, comprising at least one processor coupled to a memory and configured to register network endpoints to a network managed by the network manager; receive trusted reference information of the network endpoints based on the registered network endpoints; perform verification of the network endpoints based on at least one of the trusted reference information or proof received from the network endpoints; and implement policies on the network endpoints based on the verification results.

[0364] Aspect 2 is an apparatus of aspect 1, further comprising performing verification of a network endpoint, a memory, and at least one processor, wherein the at least one processor is configured to: receive a certificate from the network endpoint; and determine a verification result based on the certificate and trusted reference information.

[0365] Aspect 3 is an apparatus of either aspect 1 or 2, further comprising a memory and at least one processor configured to receive trusted reference information for each network endpoint communicating with the network manager.

[0366] Aspect 4 is an apparatus of any of aspects 1 to 3, further comprising a memory and at least one processor configured to receive trusted reference information of a set of network endpoints in communication with a network manager.

[0367] Aspect 5 is an apparatus of any of aspects 1 to 4, further comprising a memory and at least one processor configured to perform network endpoint authentication periodically, on demand, or in response to the occurrence of a triggering event.

[0368] Aspect 6 is an apparatus of any of aspects 1 to 5, further comprising a memory and at least one processor and is also configured to: report the verification results to at least one trusted third party.

[0369] Aspect 7 is an apparatus of any of aspects 1 to 6, and further includes, for implementing policies on network endpoints, a memory and at least one processor configured to: monitor the connection health status of the network endpoints; and monitor the device health status of the network endpoints.

[0370] Aspect 8 is an apparatus of any of aspects 1 to 7, and further includes a strategy including trust event remediation measures, and in order to implement the trust event remediation measures, the memory and at least one processor are configured to: modify network access control of the network endpoint, restrict the functional capabilities of the network endpoint, adjust the QoS level of the network endpoint, or force a software update of the network endpoint.

[0371] Aspect 9 is an apparatus of any of aspects 1 to 8, further comprising a memory and at least one processor, and is further configured to: receive a software update for a network endpoint from a trusted third party; provide the software update to the network endpoint based on verification of the network endpoint; and verify that the software update has been successfully completed on the network endpoint based on a second proof from the network endpoint.

[0372] Aspect 10 is an apparatus of any of aspects 1 to 9, further comprising a memory and at least one processor configured to: perform user authentication of a user at a network endpoint; and control user access to services or resources based on user authentication.

[0373] Aspect 11 is an apparatus of any of aspects 1 to 10, and further includes, for performing user authentication, a memory and at least one processor configured to receive a device certificate including the user authentication result from a network endpoint.

[0374] Aspect 12 is an apparatus of any of aspects 1 to 11, further comprising a memory and at least one processor, and is further configured to: send a credential request to the network endpoint after performing authentication of the network endpoint; receive a credential response from the network endpoint; and send a credential registration response to the network endpoint when registering a device identifier with a network manager, wherein the network manager receives trusted reference information of the network endpoint from one or more trusted third parties after registering the device identifier of the network endpoint.

[0375] Aspect 13 is an apparatus of any of aspects 1 to 12, further comprising a memory and at least one processor configured to: retrieve, using a proof verifier associated with the network endpoint, a policy for managing the network endpoint from one or more trusted third parties, wherein the management of the network endpoint is based in part on the policy, the trust level associated with the network endpoint, and the operational purpose associated with the network endpoint.

[0376] Aspect 14 is an apparatus of any of aspects 1 to 13, and further includes a transceiver coupled to at least one processor.

[0377] Aspect 15 is a wireless communication method for implementing any of aspects 1 to 14.

[0378] Aspect 16 is an apparatus for wireless communication, including components for implementing any of aspects 1 to 14.

[0379] Aspect 17 is a non-transitory computer-readable storage medium storing computer-executable code, wherein when the code is executed, it causes a processor to implement any one of aspects 1 to 14.

[0380] Aspect 18 is an apparatus for access management at a trusted broker, comprising at least one processor coupled to a memory and configured to receive authentication information from a device requesting access to a service or resource provided by a service management entity; evaluate the authentication information of the device based on an updatable policy; and, based on the evaluation of the authentication information, implement an updatable policy on the device for the service or resource provided by the service management entity.

[0381] Aspect 19 is an apparatus of aspect 18, and further includes proof information including first provable information associated with or managed by the first verification entity and second provable information associated with or managed by the second verification entity.

[0382] Aspect 20 is an apparatus of either aspect 18 or 19, and further includes a first verification entity including a trust agent.

[0383] Aspect 21 is an apparatus of any of aspects 18 to 19, and further includes a first verification entity comprising a trusted third party different from the trusted agent.

[0384] Aspect 22 is an apparatus of any of aspects 18 to 21, further comprising a memory and at least one processor configured to evaluate the apparatus’s proof information based on one or more verification results associated with the proof information and the corresponding proof information of the updatable strategy.

[0385] Aspect 23 is an apparatus of any of aspects 18 to 22, further comprising a memory and at least one processor configured to evaluate the apparatus’s proof information based on one or more verification results associated with a subset of proof information and provable information of an updatable strategy.

[0386] Aspect 24 is an apparatus of any of aspects 18 to 23, further comprising a memory and at least one processor configured to evaluate one or more verification results based on provable parameters provided by a service management entity via an updatable policy.

[0387] Aspect 25 is an apparatus of any of aspects 18 to 24, and further includes, in order to implement an updateable policy on the device, a memory and at least one processor configured to: implement a set of actions, wherein the set of actions includes one or more actions of an updateable policy selected based on a device trust score and a trust score threshold.

[0388] Aspect 26 is an apparatus of any of aspects 18 to 25, and further includes a memory and at least one processor, which is also configured to receive a trust score threshold from a service management entity via an updatable policy.

[0389] Aspect 27 is an apparatus of any of aspects 18 to 26, and also includes an assessment of the device trust score based on verification results associated with the proof information.

[0390] Aspect 28 is an apparatus of any of aspects 18 to 27, and further includes a memory and at least one processor configured to perform a set of actions on the apparatus.

[0391] Aspect 29 is an apparatus of any of aspects 18 to 28, further comprising a memory and at least one processor configured to: perform a first subset of a set of actions on the device; and cause the device to perform a second subset of a set of actions on the device.

[0392] Aspect 30 is an apparatus of any of aspects 18 to 29, further comprising a memory and at least one processor configured to cause one or more trusted third parties to perform at least one action in a set of actions on the apparatus.

[0393] Aspect 31 is an apparatus of any of aspects 18 to 30, and further includes a transceiver coupled to at least one processor.

[0394] Aspect 32 is a wireless communication method for implementing any of aspects 18 to 31.

[0395] Aspect 33 is a device for wireless communication, including components for implementing any of aspects 18 to 31.

[0396] Aspect 34 is a non-transitory computer-readable storage medium that stores computer-executable code, wherein when the code is executed, it causes a processor to implement any one of aspects 18 to 31.

[0397] Aspect 35 is an apparatus for trust management at a network manager, comprising at least one processor coupled to a memory and configured to register a network endpoint to a network managed by the network manager; receive trusted reference information of the network endpoint from one or more trusted third parties based on the registered network endpoint; perform verification of the network endpoint based on at least one of the trusted reference information received from one or more trusted third parties or a certificate received from the network endpoint; and implement policies on the network endpoint based on the verification results.

[0398] Aspect 36 is an apparatus of aspect 35, and further includes policies including at least one of network access level or configuration, service access or authorization level or configuration, QoS level or configuration, resource access level or configuration, trust level or configuration, and trust event remediation measures.

[0399] Aspect 37 is an apparatus of any of aspects 35 and 36, further comprising performing verification of a network endpoint, a memory, and at least one processor, wherein the at least one processor is configured to: receive a certificate from the network endpoint; and determine a verification result based on the certificate and trusted reference information.

[0400] Aspect 38 is an apparatus of any of aspects 35 to 37, and further includes proof of one or more of a device identifier based on a network endpoint, a persistent credential of a network endpoint, or device status information of a network endpoint.

[0401] Aspect 39 is an apparatus of any of aspects 35 to 38, further comprising a memory and at least one processor, and is further configured to: store at least one of a device identifier and a permanent credential in a trusted environment of a network endpoint, wherein the information stored in the trusted environment is immutable.

[0402] Aspect 40 is an apparatus of any of aspects 35 to 39, further including a memory and at least one processor, which is also configured to receive trusted reference information for each network endpoint in communication with the network manager.

[0403] Aspect 41 is an apparatus of any of aspects 35 to 40, further including a memory and at least one processor, which is also configured to receive trusted reference information of a set of network endpoints in communication with a network manager.

[0404] Aspect 42 is an apparatus of any of aspects 35 to 41, further comprising a memory and at least one processor, and is also configured to receive trusted reference information from an authentication information service associated with a network endpoint.

[0405] Aspect 43 is an apparatus of any of aspects 35 to 42, further comprising a memory and at least one processor configured to perform network endpoint authentication periodically, on demand, or in response to the occurrence of a triggering event.

[0406] Aspect 44 is an apparatus of any of aspects 35 to 43, further comprising a memory and at least one processor and is also configured to: report the verification results to at least one of one or more trusted third parties.

[0407] Aspect 45 is an apparatus of any of aspects 35 to 44, and further includes, for implementing policies on network endpoints, a memory and at least one processor configured to: monitor the connection health status of the network endpoints; and monitor the device health status of the network endpoints.

[0408] Aspect 46 is an apparatus of any of aspects 35 to 45, and further includes a strategy including trust event remediation measures, which include one or more of the following: modifying network access control of the network endpoint, restricting the functional capabilities of the network endpoint, adjusting the QoS level of the network endpoint, or forcing a software update of the network endpoint.

[0409] Aspect 47 is an apparatus of any of aspects 35 to 46, further comprising a memory and at least one processor, and is further configured to: receive a software update for a network endpoint from a first trusted third party among one or more trusted third parties; provide the software update to the network endpoint based on verification of the network endpoint; and verify that the software update is successfully completed on the network endpoint based on proof from the network endpoint.

[0410] Aspect 48 is an apparatus of any of aspects 35 to 47, further including a memory and at least one processor, and is also configured to: receive a temporary credential from a network endpoint; and determine the validity of the temporary credential based on a permanent credential of the network endpoint known to the network manager.

[0411] Aspect 49 is an apparatus of any of aspects 35 to 48, further comprising a temporary credential based on at least one of: a public-private key pair, a public key, a hash of a public key, or an identifier associated with the temporary credential.

[0412] Aspect 50 is an apparatus of any of aspects 35 to 49, further comprising a memory and at least one processor, and is further configured to receive a software update in response to at least one of the following: a periodic certification report, a notification of a subscription based on a network endpoint, or a request from a network manager including temporary credentials for a network endpoint.

[0413] Aspect 51 is an apparatus of any of aspects 35 to 50, further including a memory and at least one processor, and is further configured to: provide a software update to a network endpoint based on verification of a signature of a software update provided by a first trusted third party.

[0414] Aspect 52 is an apparatus of any of aspects 35 to 51, further comprising a memory and at least one processor, and is further configured to: receive a certificate from a network endpoint; provide an instruction to a first trusted third party to provide the certificate; receive a software activation code from the first trusted third party in response to the instruction to provide the certificate; and provide the software activation code to the network endpoint.

[0415] Aspect 53 is an apparatus of any of aspects 35 to 52, further comprising a memory and at least one processor, and is further configured to: perform user authentication of a user at a network endpoint; and control user access to services or resources based on user authentication.

[0416] Aspect 54 is an apparatus of any of aspects 35 to 53, and further includes, for performing user authentication, a memory and at least one processor configured to receive a device certificate including the user authentication result from a network endpoint.

[0417] Aspect 55 is an apparatus of any of aspects 35 to 54, further comprising a memory and at least one processor, and is further configured to: send a credential request to the network endpoint after performing authentication of the network endpoint; receive a credential response from the network endpoint; send a credential registration response to the network endpoint when registering a device identifier with a network manager, and wherein the network manager receives trusted reference information of the network endpoint from one or more trusted third parties after registering the device identifier of the network endpoint.

[0418] Aspect 56 is an apparatus of any of aspects 35 to 55, and further includes a memory and at least one processor, and is also configured to: retrieve, using a proof verifier associated with the network endpoint, a policy for implementation against the network endpoint from one or more trusted third parties.

[0419] Aspect 57 is an apparatus of any of aspects 35 to 56, and further includes a memory and at least one processor, which is also configured to retrieve a policy from one or more trusted third parties via a policy locator.

[0420] Aspect 58 is an apparatus of any of aspects 35 to 57, and further includes a memory and at least one processor, which is also configured to query a network endpoint for device status according to a policy.

[0421] Aspect 59 is an apparatus of any of aspects 35 to 58, further comprising a memory and at least one processor, and is further configured to: determine the occurrence of a trust event based on the device state of a network endpoint; resolve the trust event according to a policy by applying one or more trust event remedies; and verify that the trust event was successfully resolved at the network endpoint based on proof from the network endpoint.

[0422] Aspect 60 is an apparatus of any of aspects 35 to 59, and further includes, for resolving trust events, the memory and at least one processor being configured to: disable user access via the network endpoint, force a software update of the network endpoint, restart the network endpoint, reset the network endpoint, or disconnect network access of the network endpoint.

[0423] Aspect 61 is an apparatus of any of aspects 35 to 60, further comprising a memory and at least one processor, and is further configured to: provide a trust event report to a network system or edge component for analysis of trust events, wherein the trust event report includes at least one of one or more trust event indications or one or more trust event remedies.

[0424] Aspect 62 is an apparatus of any of aspects 35 to 61, further comprising, for resolving a trust event, a memory and at least one processor configured to: provide a trust event report to a third-party device manager based on a determination that the network manager cannot resolve the trust event, wherein the trust event report includes at least one of one or more trust event indications or one or more trust event remedies.

[0425] Aspect 63 is a device of any of aspects 35 to 62, and also includes a network endpoint connected to a network manager.

[0426] Aspect 64 is an apparatus of any of aspects 35 to 63, and also includes a network manager including a router, network controller, gateway, base station, or edge node.

[0427] Aspect 65 is an apparatus of any of aspects 35 to 64, and further includes a memory and at least one processor, which is also configured to receive from the network owner a policy for implementation on network endpoints.

[0428] Aspect 66 is a device of any of aspects 35 to 65, and also includes a strategy that is updatable.

[0429] Aspect 67 is an apparatus of any of aspects 35 to 66, further comprising, for communicating with a network endpoint, a memory and at least one processor configured to: authenticate a message using credentials before sending an authenticated message to the network endpoint, and to decrypt a message received from the network endpoint using credentials.

[0430] Aspect 68 is a wireless communication method for implementing any of aspects 35 to 67.

[0431] Aspect 69 is a device for wireless communication, including components for implementing any of aspects 35 to 67.

[0432] Aspect 70 is a non-transitory computer-readable storage medium storing computer-executable code, wherein when the code is executed, it causes a processor to implement any one of aspects 35 to 67.

[0433] Aspect 71 is an apparatus for performing trust management at a network manager, comprising at least one processor coupled to memory and configured to register network endpoints to a network managed by the network manager; receive trusted reference information of the network endpoints from one or more trusted third parties based on the registration of the network endpoints to the network; query device information of the network endpoints according to a network manager policy implemented by the network manager; and, when a trust event occurs, perform one or more trust event remediation measures according to the network manager policy, the occurrence of which is based on a comparison of the device information and the trusted reference information of the network endpoints.

[0434] Aspect 72 is a wireless communication method for implementing aspect 71.

[0435] Aspect 73 is a device for wireless communication, including components for implementing aspect 71.

[0436] Aspect 74 is a non-transitory computer-readable storage medium that stores computer-executable code, wherein when the code is executed, it causes a processor to implement aspect 71.

[0437] Aspect 75 is an apparatus for trust management at a network endpoint, comprising at least one processor coupled to memory and configured to provide a temporary credential for the network endpoint to a network manager, wherein the temporary credential is based on a permanent credential for the network endpoint; and to receive access to or authorization for a service or resource from the network manager, the access or authorization being based on device verification based on the temporary credential for the network endpoint.

[0438] Aspect 76 is an apparatus of aspect 75, further comprising a temporary credential based on at least one of: a public-private key pair, a public key, a hash of a public key, or an identifier associated with the temporary credential.

[0439] Aspect 77 is an apparatus of any of aspects 75 and 76, and also includes memory and at least one processor, and is further configured to: receive software updates from a trusted third party via a network manager based on device authentication using temporary credentials based on a network endpoint.

[0440] Aspect 78 is an apparatus of any of aspects 75 to 77, further including a memory and at least one processor, and is also configured to: provide proof to a network manager; and in response to the proof, receive a software activation code from a trusted third party via the network manager.

[0441] Aspect 79 is an apparatus of any of aspects 75 to 78, further comprising a memory and at least one processor, and is further configured to: perform user authentication of a user at a network endpoint; and provide a certificate to a network manager, the certificate including the result of the user authentication.

[0442] Aspect 80 is an apparatus of any of aspects 75 to 79, further comprising a memory and at least one processor configured to perform user authentication based on one or more of the following: password, biometrics, trusted location, multi-factor authentication, or continuous authentication.

[0443] Aspect 81 is a wireless communication method for implementing any of aspects 75 to 80.

[0444] Aspect 82 is a device for wireless communication, including components for implementing any of aspects 75 to 80.

[0445] Aspect 83 is a non-transitory computer-readable storage medium storing computer-executable code, wherein when the code is executed, it causes a processor to implement any one of aspects 75 to 80.

[0446] Aspect 84 is an apparatus for access management at a trusted broker, comprising at least one processor coupled to a memory and configured to receive authentication information from a user equipment requesting access to a service or resource provided by a service management entity; evaluate the authentication information of the user equipment based on an updatable policy; and, based on the evaluation of the authentication information, implement an updatable policy on the user equipment for the service or resource provided by the service management entity.

[0447] Aspect 85 is an apparatus of aspect 84, and further includes proof information including at least one of user-provable information, device-provable information, or network-provable information.

[0448] Aspect 86 is an apparatus of any of aspects 84 and 85, and further includes proof information including first provable information associated with or managed by the first verification entity and second provable information associated with or managed by the second verification entity.

[0449] Aspect 87 is an apparatus of any of aspects 84 to 86, and further includes a first verification entity and a second verification entity being the same verification entity.

[0450] Aspect 88 is an apparatus of any of aspects 84 to 86, and further includes a first verification entity different from the second verification entity.

[0451] Aspect 89 is an apparatus of any of aspects 84 to 88, and further includes a first verification entity including a trust agent.

[0452] Aspect 90 is an apparatus of any of aspects 84 to 89, further comprising a memory and at least one processor configured to: determine a verification result associated with the first provable information based on reference information.

[0453] Aspect 91 is an apparatus of any of aspects 84 to 90, and further includes a memory and at least one processor configured to: determine a verification result associated with the first provable information based on a measurement.

[0454] Aspect 92 is an apparatus of any of aspects 84 to 91, and further includes a first verification entity comprising a trusted third party different from the trusted agent.

[0455] Aspect 93 is an apparatus of any of aspects 84 to 92, further comprising a memory and at least one processor configured to receive a verification result associated with the first provable information from a trusted third party.

[0456] Aspect 94 is an apparatus of any of aspects 84 to 93, further comprising a memory and at least one processor configured to: provide first provable information to a trusted third party and receive verification results associated with the first provable information from the trusted third party.

[0457] Aspect 95 is an apparatus of any of aspects 84 to 94, further comprising a memory and at least one processor configured to evaluate the proof information of the user equipment based on one or more verification results associated with the proof information and the corresponding proof information of the updatable strategy.

[0458] Aspect 96 is an apparatus of any of aspects 84 to 95, further comprising a memory and at least one processor configured to evaluate the proof information of the user equipment based on one or more verification results associated with a subset of the proof information and the proof information of the updatable strategy.

[0459] Aspect 97 is an apparatus of any of aspects 84 to 96, and further includes a memory and at least one processor configured to evaluate the verification results based on provable parameters provided by the service management entity via an updatable policy.

[0460] Aspect 98 is an apparatus of any of aspects 84 to 97, and further includes a memory and at least one processor configured to periodically evaluate the certification information of the user equipment.

[0461] Aspect 99 is an apparatus of any of aspects 84 to 98, further comprising a memory and at least one processor configured to evaluate the authentication information of the user equipment in response to the occurrence of a triggering event.

[0462] Aspect 100 is an apparatus of any of aspects 84 to 99, further comprising a memory and at least one processor configured to: implement a set of actions to implement an updatable policy on a user equipment, wherein the set of actions includes one or more actions of the updatable policy selected based on a device trust score and a trust score threshold.

[0463] Aspect 101 is an apparatus of any of aspects 84 to 100, and further includes a memory and at least one processor, which is also configured to receive a trust score threshold from a service management entity via an updatable policy.

[0464] Aspect 102 is a means of any of aspects 84 to 101, and also includes an evaluation of the device trust score based on the verification results associated with the proof information.

[0465] Aspect 103 is a device of any of aspects 84 to 102, and also includes a device trust score based on an evaluation of an updatable strategy for verification results.

[0466] Aspect 104 is an apparatus of any of aspects 84 to 103, further comprising a memory and at least one processor, and is further configured to: implement the set of actions on a user equipment or a trusted agent by using the user equipment to implement the set of actions on the user equipment.

[0467] Aspect 105 is an apparatus of any of aspects 84 to 104, further including a memory and at least one processor, which is also configured to: perform a first subset of an action set on the user equipment and to cause the user equipment to perform a second subset of an action set on the user equipment.

[0468] Aspect 106 is an apparatus of any of aspects 84 to 105, further comprising a memory and at least one processor, and is further configured to cause one or more trusted third parties to perform at least one action in a set of actions on the user equipment.

[0469] Aspect 107 is a wireless communication method for implementing any of aspects 84 to 8406.

[0470] Aspect 108 is a device for wireless communication, including components for implementing any of aspects 84 to 106.

[0471] Aspect 109 is a non-transitory computer-readable storage medium storing computer-executable code, wherein when the code is executed, it causes a processor to implement any one of aspects 84 to 106.

[0472] Aspect 110 is an apparatus for access management at a user equipment, comprising at least one processor coupled to a memory and configured to provide authentication information associated with the user equipment to a trust agent when requesting access to a service or resource provided by a service management entity; and to receive access to the service or resource provided by the service management entity from the trust agent based on an evaluation of the authentication information on an updatable policy.

[0473] Aspect 111 is the apparatus of aspect 110, and further includes proof information including at least one of user-provable information, device-provable information, or network-provable information.

[0474] Aspect 112 is an apparatus of any of aspects 110 and 111, and further includes proof information including first provable information associated with or managed by the first verification entity and second provable information associated with or managed by the second verification entity.

[0475] Aspect 113 is an apparatus of any of aspects 110 to 112, further comprising a memory and at least one processor configured to periodically receive requests for proof information from a trust agent.

[0476] Aspect 114 is an apparatus of any of aspects 110 to 113, further comprising a memory and at least one processor configured to receive a request for authentication information from a trust agent in response to the occurrence of a triggering event.

[0477] Aspect 115 is an apparatus of any of aspects 110 to 114, further comprising a memory and at least one processor configured to: implement a set of actions on a user equipment based on an evaluation of proof information of an updatable policy.

[0478] Aspect 116 is a wireless communication method for implementing any of aspects 110 to 115.

[0479] Aspect 117 is an apparatus for wireless communication, including components for implementing any of aspects 110 to 115.

[0480] Aspect 118 is a non-transitory computer-readable storage medium storing computer-executable code, wherein when the code is executed, it causes a processor to implement any one of aspects 110 to 115.

Claims

1. An apparatus for trust management at a network manager, comprising: At least one memory including instructions; as well as At least one processor, the at least one processor being configured to execute the instructions to cause the device to: Register a network endpoint with the network managed by the network manager by following these steps: After performing the initial authentication of the network endpoint, a credential request is sent to the network endpoint; Receive a credential response from the network endpoint; as well as When registering a device identifier with the network manager, a credential registration response is sent to the network endpoint; After registering the device identifier of the network endpoint, receive trusted reference information for the network endpoint; The verification of the network endpoint is performed based on at least one of the trusted reference information or proof received from the network endpoint; as well as Based on the results of the verification, a policy is implemented for the network endpoint.

2. The apparatus according to claim 1, wherein, In order to perform the initial authentication of the network endpoint, the at least one processor is configured to cause the device to: Receive the proof for the network endpoint; and The verification result is determined based on the proof and the trusted reference information. The device further includes a transceiver coupled to the at least one processor.

3. The apparatus according to claim 1, wherein, The at least one processor is configured to enable the device to receive the trusted reference information from each network endpoint communicating with the network manager.

4. The apparatus according to claim 1, wherein, The at least one processor is configured to enable the device to receive the trusted reference information for a set of network endpoints used to communicate with the network manager.

5. The apparatus according to claim 1, wherein, The at least one processor is configured to cause the device to perform the authentication of the network endpoint periodically, on demand, or in response to the occurrence of a triggering event.

6. The apparatus according to claim 1, wherein, The at least one processor is further configured to cause the device to: Report the verification results to at least one trusted third party.

7. The apparatus according to claim 1, wherein, In order to implement the policy on the network endpoint, the at least one processor is configured to cause the device to: Monitor the connection health status of the network endpoints; as well as Monitor the device health status of the network endpoints.

8. The apparatus according to claim 1, wherein, The strategy includes trust event remediation measures, and in order to implement the trust event remediation measures, the at least one processor is configured to cause the device to: Modify the network access control of the network endpoint. Limit the functionality of the network endpoints. Adjust the Quality of Service (QoS) level of the network endpoint, or Force a software update for the network endpoint.

9. The apparatus according to claim 1, wherein, The at least one processor is further configured to cause the device to: Receive software updates for the network endpoints from a trusted third party; Based on the verification performed on the network endpoint, the software update is provided to the network endpoint; as well as Based on a second proof from the network endpoint, the software update is verified to have been successfully completed on the network endpoint.

10. The apparatus according to claim 1, wherein, The at least one processor is configured to cause the device to: Perform user authentication for the user at the network endpoint; and The user authentication is used to control user access to services or resources.

11. The apparatus according to claim 10, wherein, In order to perform the user authentication, the at least one processor is configured to cause the device to: Receive device proof, including user verification results, from the network endpoint.

12. The apparatus according to claim 1, wherein, The at least one processor is configured to cause the device to: The network endpoint is managed by a proof verifier associated with the network endpoint, which retrieves the policy for managing the network endpoint from one or more trusted third parties. The management of the network endpoint is based in part on the policy, the trust level associated with the network endpoint, and the operational purpose associated with the network endpoint.

13. The apparatus according to claim 1, wherein, The at least one processor is further configured to cause the device to: Provide trust event reports to network systems or edge components for the purpose of analyzing trust events, wherein the trust event reports include at least one of one or more trust event indications or one or more trust event remediation measures.

14. The apparatus according to claim 1, wherein, The at least one processor is further configured to cause the device to: Since the network manager cannot resolve the determination of the trust event, a trust event report is provided to a third-party device manager, wherein the trust event report includes at least one of one or more trust event indications or one or more trust event remediation measures.

15. A method for trust management at a network manager, comprising: Register a network endpoint with the network managed by the network manager by following these steps: After performing the initial authentication of the network endpoint, a credential request is sent to the network endpoint; Receive a credential response from the network endpoint; as well as When registering a device identifier with the network manager, a credential registration response is sent to the network endpoint; After registering the device identifier of the network endpoint, receive trusted reference information for the network endpoint; The verification of the network endpoint is performed based on at least one of the proof received from the network endpoint or the trusted reference information; as well as Based on the results of the verification, a policy is implemented for the network endpoint.

16. A computer-readable medium comprising executable instructions that, when executed by one or more processors of a device, cause the device to perform the method of claim 15.

17. An apparatus comprising components for performing the method according to claim 15.

Images