EQUIPMENT, PROCEDURE AND COMPUTER-READABLE MEDIUM FOR A LOCAL CERTIFICATION SERVICE

Abstract

A computer program comprising instructions which, when executed by a computer, cause the computer to perform operations that include: enabling local attestation of a network within a trust cluster, wherein enabling local attestation includes attesting nodes associated with the network within the trust cluster; communicating with a selected node outside the trust cluster; and attesting the selected node, wherein the selected and attested node is added to the trust cluster.

Description

background Attestation services are crucial for verifying the integrity and trustworthiness of computing environments, ensuring that systems are secure and functioning as intended. However, centralized, single-point attestation services present scalability challenges for customers whose infrastructure and resources are distributed across multiple locations. In edge computing scenarios, where computing resources are often limited, there are situations where it is impossible to meet the computing demands or implement the necessary features required to secure a system with a centralized attestation service.Furthermore, customers who operate entirely on-premises, such as certain healthcare providers or research institutions, may avoid using centralized or public cloud services solely for AaaS (Attestation-as-a-Service) due to concerns about data privacy, regulatory compliance, and reliance on external infrastructure. Therefore, an improved setup, process, and / or machine-readable medium for a local attestation service may be desirable. Brief description of the characters Some examples of facilities and / or procedures are described below by way of example and with reference to the accompanying figures, in which Fig. 1 shows a block diagram of an example facility for a local attestation service of a network within a trust cluster; Fig. 2 shows an example system that uses a tiered AaaS; Fig. 3 shows an example system with attestation boundaries and the addition of a new node; Fig. 4 shows a flowchart of a procedure for a local attestation service; and Fig. 5 illustrates a computing device for a local attestation service. Detailed description Some examples are now described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these extensively described embodiments. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used here to describe certain examples should not exclude other possible examples. Throughout the description of the figures, identical or similar reference symbols refer to identical or similar elements and / or features, which may be implemented identically or in a modified form, while providing the same or a similar function. The thickness of lines, layers, and / or areas in the figures may also be exaggerated for clarity. Although further examples of various modifications and alternative forms are appropriate, some specific examples are presented in the figures and described in detail below. This detailed description, however, does not limit further examples to the specific forms described. Further examples may encompass all modifications, equivalents, and alternatives that fall within the scope of the disclosure. Throughout the description of the figures, the same reference marks refer to identical or similar elements that, when compared, may be implemented identically or in a modified form while simultaneously providing the same or similar functionality. When two elements A and B are combined using "or," this is to be understood as revealing all possible combinations, i.e., only A, only B, and A and B, unless explicitly defined otherwise in a specific case. As an alternative formulation for the same combinations, "at least one of A and B" or "A and / or B" can be used. This applies equally to combinations of more than two elements. When a singular form, such as "a," "an," and "the," "a," or "the," is used, and the use of only a single element is neither explicitly nor implicitly defined as mandatory, subsequent examples may also use multiple elements to implement the same function. If a function is subsequently described as being implemented using multiple elements, subsequent examples may implement the same function using a single element or a single processing entity.It is further understood that the terms “include”, “containing”, “encompass” and / or “comprehensive”, when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof. Unless otherwise defined, all terms (including technical and scientific terms) are used herein in their normal meaning within the field to which the examples belong. The following description presents specific details; however, examples of the technologies described herein can be implemented without these specific details. Well-known circuits, structures, and techniques have not been shown in detail to avoid complicating the understanding of the present description. "An example," "various examples," "some examples," and the like may include features, structures, or characteristics, but not every example necessarily exhibits those particular features, structures, or characteristics. Some examples may exhibit some, all, or none of the features described for other examples. “First,” “second,” “third,” and the like describe a common element and indicate different instances of similar elements being referred to. Such adjectives do not imply that the element(s) so described must be present in any given order, whether temporal, spatial, hierarchical, or otherwise. “Connected” may indicate that elements are in direct physical or electrical contact with one another, and “coupled” may indicate that elements work together or interact, although they may or need not be in direct physical or electrical contact. As used herein, the terms “working”, “executing” or “running” relating to software or firmware in respect of a system, device, platform or resource are used interchangeably and can refer to software or firmware stored on one or more computer-readable storage media which the system, device, platform or resource can access, even if software or firmware instructions are not actively executed by the system, device, platform or resource. The description may use the expressions “in one example,” “in examples,” “in some examples,” and / or “in several examples,” each of which may refer to one or more of the same or to different examples. Furthermore, the terms “comprehensive,” “including,” “with,” and the like, as used in relation to examples in this disclosure, are synonymous. It should be noted that the exemplary schemes disclosed herein are applicable to / with any operating system and any reference to a specific operating system in this disclosure is merely an example, not a limitation. Fig. 1 shows a block diagram 100 of an example of a facility 10 (or device 10) for a local attestation service of a network within a trust cluster. The facility 10 may include a storage circuit arrangement 20, machine-readable instructions 20a, and a processor circuit arrangement 30 for executing the machine-readable instructions. The facility 10 may be part of a system 100. For example, the processor circuit arrangement 30 may be configured to provide the functionality of the facility 10 in conjunction with the interface circuit arrangement 40. For example, the interface circuit arrangement 40 is configured to exchange information, e.g., with other components inside or outside the facility 10 and the storage circuit arrangement 20. Likewise, the device 10 may include means configured to provide the functionality of the device 10. The components of the device 10 are defined as component means that correspond to, or can be implemented by, the respective structural components of the setup 10. For example, the device 10 of Fig. 1 comprises processing means 30, which correspond to, or can be implemented by, the processing circuit arrangement 30; communication means 40, which correspond to, or can be implemented by, the interface circuit arrangement 40; and (optionally) information storage means 20, which correspond to, or can be implemented by, the storage circuit arrangement 20. The functionality of the device 10 is illustrated below with reference to the setup 10. Features described in connection with the setup 100 can thus be applied equally to the corresponding device 10. In general, the functionality of the processing circuit arrangement 30 or the means of processing 30 can be implemented by the processing circuit arrangement 30 or means of processing 30 executing machine-readable instructions 20a. Accordingly, any feature attributed to the processing circuit arrangement 30 or means of processing 30 can be defined by one or more instructions from a plurality of machine-readable instructions 20a. The device 10 or apparatus 10 can include the machine-readable instructions, for example, within the storage circuit arrangement 20 or means of storing information 20. For example, the processing circuit arrangement 30 or the means of processing 30 can perform a method shown in the present disclosure, such as the method discussed in connection with Fig. 4. The interface circuit arrangement 40 or means of communication 40 can correspond to one or more inputs and / or outputs for receiving and / or transmitting information, which may be in digital (bit) values ​​according to a specified code, within a module, between modules, or between modules of different entities. For example, the interface circuit arrangement 40 or means of communication 40 can comprise a circuit arrangement configured to receive and / or transmit information. For example, the processing circuit arrangement 30 or the means of processing 30 can be implemented using one or more processing units, one or more processing devices, or any means of processing, such as a processor, a computer, or a programmable hardware component that can be operated with appropriately adapted software. In other words, the described function of the processing circuit arrangement 30 or the means of processing 30 can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components can include a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc. For example, the storage circuit arrangement 20 or the means of storing information 20 may include at least one element of the group of a computer-readable storage medium, such as a magnetic or optical storage medium, e.g. a hard disk drive, flash memory, floppy disk, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), EPROM (EEPROM) or network memory. Facility 10 can be configured to communicate with a selected node outside the trust cluster, attest to the selected node, and register the selected node within the trust cluster if the attestation of the selected node is successful. The facility can be the local trust authority or an Attestation-as-a-Service (AaaS) system responsible for managing trust and attestation within the network. Centralized attestation services may not scale well for customers whose infrastructure and resources are spread across multiple locations, including a local private enterprise edge, a remote public cloud, an on-premises version of a public cloud stack, and various other combinations. Edge computing strategically positions compute processes and data storage close to data generation sources, minimizing the latency and bandwidth consumption typically associated with centralized, cloud-based systems. This architectural framework comprises a network of distributed nodes, which may include IoT devices, sensors, gateways, and local servers, each equipped with processing capabilities to perform data analytics, real-time decision-making, and application-specific tasks at or near the point of data generation.Therefore, edge resources can be limited, leading to situations where it is impossible to meet the computational requirements (or features) needed to secure a system. Customers with fully on-premises (e.g., 100%) systems, such as certain hospital systems or research institutions, may not want to connect to a centralized or public cloud solely for attestation services (AaaS). The revealed local trust authority can be a platform that scales to meet the demands of modern enterprise computing environments. The primary function of this local trust authority is to attest to the integrity of trusted execution environments (TEEs) by validating that workloads running within these environments have not been compromised. This can enable confidential computing in multi-party scenarios. Confidential computing allows the processing of sensitive data within confidential computing environments (CCES), ensuring that data remains secure during computation. This can be true even when data is shared by multiple parties.During the COVID-19 pandemic, AaaS enabled collaborative efforts between organizations, such as drug developers and healthcare providers, to securely share and process sensitive intellectual property and health data without exposing the underlying information to potential breaches. Attestation by a local trust authority can be achieved through TEE instance setup, a verification process, attestation policy compliance, attestation token generation, and token verification. Users or their infrastructure providers can configure a trusted computing environment, such as a TEE, which may contain application-layer or virtual machine (VM) workloads. The TEE generates cryptographically signed attestations that include identity and integrity metrics of the environment. These attestations are submitted to the local trust authority for attestation. The trust authority compares the cryptographically signed attestations against predefined security policies configured by the user. These policies define the expected identity and integrity metrics of the computing environment.If the environment passes the attestation checks, the trusted authority issues an attestation token. This token is cryptographically signed and serves as proof that the environment is trustworthy and secure. Any trusting party can verify the attestation token's signature and ensure that the environment meets the necessary security policies. Once verified, workloads and data can be securely decrypted and executed within the TEE. The setup for a local trust authority can be implemented through multiple small attestation infrastructures that, when detected, can work together to form a more powerful cluster. Local attestation can be ideal for edge computing where resources are limited. The attestation service can be implemented as a hierarchy of functionality and / or communities. Ad-hoc, local, or peer-to-peer trust authority infrastructures can consider how they are formed, how they communicate with each other, and what happens if one of them fails or becomes damaged. All of these considerations can lead to different security gradients and approaches to handling sensitive computing tasks.Monitoring of local trust authorities of centralized attestation services or of peers at the edge can, in certain scenarios, serve as a complement to or oversight of local attestation. Edge solutions provide the ability to extend cloud infrastructure to the network edge, bringing computing resources closer to data generation sources. Customers, including those with on-premises private enterprise edge setups or remote public cloud infrastructures, can leverage edge outposts to improve operational efficiency. For example, healthcare providers managing HIPAA-regulated data could integrate edge computing solutions to maintain data privacy and compliance without relying on centralized public clouds, thus addressing their concerns about public cloud exposure. Introducing a trusted authority into an edge network enables a wide range of secure computing use cases. Competitors in highly regulated industries, such as financial services or healthcare, can securely share data or workloads, knowing that the computing environment is verified and has not been tampered with. Meanwhile, organizations can deploy sensitive workloads across multi-cloud and edge environments, ensuring that all environments maintain the same high level of security. For example, in the oil and gas industry, attestation for wellhead controls during oil extraction can be critical for remote sites where connecting to centralized attestation services is not cost-effective or feasible. Local Trust Authorities (LTAs) can be designed to scale seamlessly across a wide range of deployment models, from on-premises infrastructures to hybrid cloud environments. Organizations can maintain consistent security policies across different cloud providers without investing in complex and expensive custom attestation services. Additionally, the LTA design can simplify deployment, configuration, and management. Organizations can dynamically configure security policies and maintain consistency across their entire infrastructure with minimal effort. Furthermore, by implementing zero-trust principles, the LTA helps organizations protect sensitive data and workloads by ensuring that every computing environment is verified before being trusted.For example, a financial institution could deploy sensitive workloads across multiple cloud environments, with each edge node independently attested and integrated into the overall trust cluster. A CCE (Computer Computing Environment) can refer to a secure area within a computing system that isolates sensitive data and computation from other processes, including the operating system and hypervisors. This is typically achieved through hardware-based security features, such as TEEs (Trusted Execution Systems). A TEE can be provided within or by the processing circuitry and creates isolated and secure areas for performing sensitive computations and storing confidential data. A TEE can be hosted within a CCE, enabling confidential computation of a workload. Confidential computing can refer to computing (i.e., data processing) performed in such a secure environment, as a CCE can provide hardware-based security features both within the processing circuit arrangement and across the wider computing system that includes the processing circuit arrangement to protect data in use from unauthorized access and manipulation. For example, memory encryption can be used to ensure that the contents of system memory (e.g., RAM) are encrypted to protect data, even if physical access to the memory is gained. Furthermore, features such as I / O isolation can be used to secure input / output operations and prevent data loss during transit between the processing circuitry and peripheral devices. Together, these system-level processing circuit arrangements and features can provide a robust foundation for one or more TEEs, ensuring that sensitive information and computations (or more generally, workloads) are protected throughout their lifetime. Operating on top of the system software, the TEEs rely on the underlying system software for their initialization, execution, and management. The system software provides the necessary services and interfaces for the TEE to operate securely and efficiently. A CCE can comprise one or more hierarchically layered environments. Each of these layered environments can be specifically designed to perform different computational functions within the CCE. These layers are hierarchically structured so that a lower layer can support and attest to the integrity of a layer above it, ensuring a continuous chain of trust across the entire CCE. For example, a lower-layered environment can receive a measurement from a higher-layered environment and sign it with its private key. One or more layered environments can be categorized into layers based on their functions within the CCE.The layers can be logically and / or hardware-separated based on their specific functions, roles, and responsibilities within the CCE, thus ensuring a structured and secure computing framework. For example, one or more layers may be designed to perform fundamental security functions, such as the Root of Trust (RoT). This fundamental security provides the essential security mechanisms and trust anchors upon which the entire framework is built. For example, the fundamental security framework may include layers responsible for secure booting, cryptographic key management, and integrity verification. Attestation can refer to a mechanism that reports on the protection and integrity properties of the workload-host TEE and also on target environments (TEs), such as the RoT and intermediate layers (e.g., firmware layer, integrity register layer, and the like). Attestation reports can be collected when events are imported during the workload's lifetime, such as whenever an image is updated, when the workload is migrated, or similar events. In some examples, the selected node is discovered when it becomes visible to a node within the trust cluster. Here, a selected node can refer to any device or system component intended for integration into the trust cluster, such as IoT devices, sensors, or edge servers. Discovered can imply that another trusted node (e.g., within the trust cluster) identifies and recognizes the node through mechanisms such as network scanning, broadcasting, or peer discovery protocols. The trust cluster can refer to a group of nodes that have been authenticated and trusted to communicate and share resources securely. For example, a new IoT sensor becomes a selected node when it becomes discoverable by an existing trusted gateway within the cluster, enabling seamless integration and secure communication. In some examples, the facility establishes a secure channel between itself and the selected node. A secure channel can be a communication path that ensures data transmitted between the facility and the selected node is encrypted and protected from unauthorized access or manipulation. This can involve protocols such as TLS (Transport Layer Security) or IPsec to provide confidentiality and integrity. For example, when a new edge device joins the network, the facility can initiate a TLS-encrypted connection to securely exchange authentication credentials and attestation data with the selected node, ensuring that all subsequent communications are protected from potential threats. In some examples, the selected node may contain a CCE, and attesting the selected node involves attesting the confidential computing environment. Attesting the CCE may involve verifying that the CCE is operating correctly and securely to ensure that its data is protected from unauthorized access or manipulation. For example, a hospital's data processing unit may operate within a CCE to protect patient information, and the institution may perform attestation to confirm the integrity and security of this environment before allowing any data processing. Attestation of the selected node's CCE (Centre for Trusted Environments) can be achieved, for example, via an Enhanced Privacy ID (EPID) or a Gossip Group Protocol. EPID is a cryptographic protocol that provides identity verification while preserving user privacy by allowing devices to prove their identity without revealing their exact identity to third parties. The Gossip Group Protocol is a decentralized communication method where nodes share information with randomly selected peers, enabling efficient and scalable data distribution across the network. Using EPID can ensure that the selected node's identity is securely authenticated. The Gossip Group Protocol can facilitate the distribution and verification of attestation information across the trust cluster.For example, when a new edge device is introduced, EPID verifies its identity, and the Gossip protocol ensures that this attestation is communicated to all relevant nodes within the trust cluster, thereby maintaining consistent security across the network. In some examples, after successful attestation, the selected node is registered to communicate with other nodes in the trust cluster, provide security services, or discover additional selected nodes outside the trust cluster. Registration for communication allows the node to securely exchange data and messages with other trusted nodes within the cluster. Providing security services might involve the node offering functionalities such as encryption, authentication, or intrusion detection to improve the overall security posture of the network. Discovering additional selected nodes might involve identifying and integrating additional devices or systems that wish to join the trust cluster.For example, once a new edge device passes attestation, it can securely communicate with existing IoT devices, offer encryption services for data transmission, and detect and integrate new devices as they become available, thereby expanding the capabilities and coverage of the trusted cluster. In some examples, the selected node is in an evaluation phase prior to successful attestation. The evaluation or onboarding phase can refer to a preliminary period during which the node undergoes assessments to determine its compliance with the security and operational requirements of the trusted cluster. This phase may include testing the node's hardware integrity, software configurations, and performance metrics to ensure it meets predefined standards. For example, a new edge device might enter the evaluation phase, where its firmware is verified, its processing capabilities are tested, and its network performance is measured before it is granted full access and trust within the cluster. The evaluation or onboarding process allows new nodes to join the trust cluster by undergoing a series of verification steps managed by local trust authorities. This could include query mechanisms, trust entities that monitor the health and status of clients, and dynamic provisioning based on resource availability and attestation scores. For example, if a new edge device is deployed to a new remote location, a trust authority can review its attestation score and resource availability before deploying it to a more suitable location within the trust cluster. In some examples, data generated by the selected node during the evaluation phase is tagged. Tagging data can involve labeling or annotating the information generated by the node to indicate its status or origin. This can be achieved through metadata tagging, digital signatures, or watermarking techniques, which help track, verify, and manage data during the evaluation process. For example, data streams from a node undergoing evaluation can be tagged with a unique identifier and a status indicator to distinguish them from data generated by fully attested and registered nodes. This ensures that any analysis or processing of the data during the evaluation phase can take its preliminary status into account and apply appropriate handling protocols. In some examples, the trust cluster may encompass multiple networks. During the evaluation phase, the selected node can be assessed for performance and / or cost efficiencies and, upon successful attestation, registered with one of the trust cluster's multiple networks if a threshold is met. Multiple networks can refer to several interconnected networks within the trust cluster, such as on-premises corporate networks, public cloud networks, or hybrid cloud environments. When a node is evaluated for performance or cost efficiencies, its energy consumption and operating costs can be assessed to ensure optimal resource utilization and economic viability. A threshold can be a predefined benchmark or criteria that the node must meet to qualify for registration within a specific network.For example, an edge device can be tested for its energy consumption and processing costs during the evaluation, and if it operates below the set thresholds, it will be registered to join the most cost-effective and energy-efficient network within the trusted cluster, thereby optimizing overall resource management. In some examples, after registering the selected node within the trust cluster, the system periodically reassesses the node's performance and / or cost efficiency and migrates it to another network within the trust cluster if a threshold is met. Reassessment may involve conducting regular evaluations of the node's operational performance and resource consumption over time. Migration may refer to moving the node's operational tasks, data processing, or connectivity from one network to another to maintain optimal performance and cost-effectiveness. If a node's power consumption or cost metrics exceed or fall below defined thresholds, indicating inefficiency or underutilization, the system may autonomously move the node to a more suitable network within the trust cluster.For example, an edge device initially assigned to a high-performance network can be migrated to a more cost-effective network if ongoing evaluations show that its processing requirements have decreased, thereby reducing operating costs and saving energy resources. In some examples, facility 10 is an edge facility of the network. An edge facility can refer to a device or system component located at the periphery of the network, close to data sources and end users, responsible for local data processing rather than relying solely on centralized cloud servers. This proximity can enable faster data processing, reduced latency, and more efficient bandwidth utilization. When operating as an edge facility, it can perform critical tasks such as data analytics, real-time decision-making, and secure communication right at the network edge.For example, the device in a factory can be located in an edge gateway that monitors and processes data from various sensors in the production hall in real time, enabling immediate responses to operational changes and improving overall system efficiency. In some examples, the institution can deregister the selected node from the trust cluster. Deregistration, or offboarding, can involve removing the node's authentication and trust status, thereby revoking its permissions to communicate and interact with other nodes within the cluster. This action ensures that untrusted or compromised nodes no longer have access to sensitive resources or data within the network. Deregistration can be triggered by several factors, such as security breaches, performance degradation, or policy violations. For example, if a node exhibits suspicious behavior or fails to comply with security protocols, the institution can initiate the deregistration process to isolate and remove the node from the trust cluster, thus preserving the integrity and security of the overall system.The deregistration or offboarding process ensures that nodes can be removed or migrated based on changing conditions, such as resource limitations or security threats. In some examples, the registration of the selected node is revoked if the selected node fails, if the selected node is re-attested and the re-attestation fails, or if the selected node is designated as untrusted by another attestation service. A failure can refer to the node experiencing operational problems, such as hardware malfunctions, software bugs, or performance inefficiencies, that impair its functionality. Re-attesting can mean that the node undergoes a subsequent attestation process to verify its continued compliance and security status within the trust cluster. If this re-attestation fails for the node, indicating potential compromises or deviations from security policies, it may be de-registered.Furthermore, if another attestation service within the network identifies the node as untrusted, perhaps due to conflicting attestation reports or detected anomalies, the institution may deregister the node to prevent security breaches. For example, if an edge device begins to exhibit erratic behavior or fails a second round of security checks, it will be deregistered to protect the trust cluster from potential threats. In some examples, the selected node is listed in an untrusted node blockchain and removed from the trust cluster. An untrusted node blockchain is a distributed and immutable ledger that records the identities and states of nodes identified as untrusted or compromised. Using blockchain technology ensures that information regarding untrusted nodes is securely stored, transparent, and resistant to manipulation or unauthorized changes. Once a node is flagged and recorded in this blockchain, the institution can automatically remove the node from the trust cluster to prevent future interactions or access to sensitive resources.For example, if it is determined that a node has been compromised by malware or a virus, its details can be added to the blockchain of untrusted nodes, ensuring that all trusted authorities within the network recognize it and exclude it from the trusted cluster operations. In some examples, the selected node resides within a second network, which includes a second local attestation service. Attesting the selected node involves communicating with this second local attestation service, and registering the selected node with the trust cluster further registers the second network within the trust cluster. A second local attestation service can refer to an additional trust authority operating within a different, distinct network that independently verifies and attests to the integrity and security of nodes within its domain. The second network could represent a different geographic location, organizational unit, or specialized operational segment requiring its own attestation mechanisms.When the institution attests to the selected node through the second local attestation service in this peer-to-peer manner, it can not only validate the node's trustworthiness but also extend the scope of the trust cluster by integrating the second network into the overarching trust cluster. For example, a multinational company might have separate attestation services for its regional offices; once a device has been successfully attested by a regional branch, the second network (the regional branch's network) can be automatically integrated into the main trust cluster. Fig. 1 further shows a system 100 comprising a processor circuit arrangement 30 and a non-volatile machine-readable medium 20 storing program code 20a. The processor circuit arrangement 30 can be coupled to the machine-readable medium 20 via a memory channel. When executed by the processor circuit arrangement 30, the program code 20a enables the system 100 to function as a local attestation service for a network within a trust cluster. The system can be configured to communicate with a selected node outside the trust cluster, attest to the selected node, and, if the attestation of the selected node is successful, register the selected node within the trust cluster. The Computer System 100 can be a client computer system, a server computer system, a rack server, a desktop computer system, a mobile computer system, a security gateway, and a router. The System 100 can also be a smartphone, a tablet, a wearable device, or a mobile computer. Further details and optional aspects of the local attestation service of Fig. 1 can be described in conjunction with the examples described below (e.g. Fig. 2, Fig. 3, Fig. 4 to Fig. 5). Figure 2 shows an example System 200 with tiered Attestation-as-a-Service (TAaaS). Figure A shows a tiered System 200 with both a centralized AaaS and a local attestation service, in which there is an edge-to-edge (e2e) system 220, 230 with trust between its nodes 222, 232 at the edge. In other words, the nodes 220, 230 know each other and trust a centralized cloud component 210. The right side of Figure 2 highlights the local TAaaS, where one to many participating end customers and their associated workloads are orchestrated in the respective local edge environment or on-premises. Here, nodes can be attested along with any AI models / data that are maintained within the closed-loop envelope, instead of going to an untrusted public cloud service.Additionally, the tiered mechanism can enable peer-to-peer AaaS capabilities for confidential multi-party computing within an edge infrastructure (shown in double arrow 240). The revealed local trust authority is a platform that scales to meet the demands of modern enterprise computing environments. Its primary function is to attest to the integrity of TEEs by validating that workloads running within these environments have not been compromised. This can be achieved through TEE instance setup, a verification process, attestation policy compliance, attestation token generation, and token verification. In Fig. 2, users 211, 221, 231 of each network 220, 220 can configure a confidential computing environment, such as a TEE 213, 223, 233, which can contain application-level or virtual machine (VM) workloads. The TEE generates cryptographically signed evidence that includes identity and integrity measurements of the environment. This evidence is transmitted to the local TAaaS 222, 232 for attestation. The local TAaaS 222, 232 compares the cryptographically signed evidence against predefined security policies configured by the user. These policies define the expected identity and integrity metrics of the computing environment. If the environment passes the attestation checks, the TAaaS 222, 232 then issues an attestation token. This token is cryptographically signed and serves as proof that the environment is trustworthy and secure.Any trusting party can verify the signature of the attestation token and ensure that the environment meets the necessary security guidelines. Once verified, workloads and data can be securely decrypted and executed within the TEE. Centralized AaaS systems may not support the decentralized operations required for diverse multi-cloud environments. For example, if a healthcare provider collaborates with a drug developer, both operating within separate edge clouds, centralized attestation could hinder seamless and secure integration, necessitating a more flexible, decentralized approach. The proposed solution introduces a decentralized model in which multiple trust authorities operate within different edge networks. Each organization operating an edge node could establish its own sub-trust authority, enabling independent verification and management of computing resources. For example, a primary trust authority could oversee the entire trust framework, while individual sub-trust authorities handle attestation and monitoring within their respective edge networks. This hierarchical or tiered trust capability enables real-time collaboration across multiple edge environments, thereby improving scalability and resilience. To enhance flexibility, the revealed TAaaS architecture can support hierarchical trust capabilities. This allows the system to support security beyond central CPUs to include XPUs, GPUs, or other AI accelerators. By extending the trust boundary from CPUs to various accelerators, the system can secure a wider range of compute resources, addressing the evolving needs of AI-centric and high-performance computing applications. In a data center, for example, GPUs used for AI tasks could be independently attested and trusted, ensuring that sensitive AI models run securely. Remote attestation can be performed over private and on-premises networks rather than a public cloud.Attestation based on additive homomorphic encryption can be performed when data or AI models move from client to network to cloud. Attestation can take place in a confidential, multi-party computing environment. Further details and aspects of the concept for the local attestation service can be described in connection with the examples discussed above (e.g. Fig. 1) or below (e.g. Fig. 3, Fig. 4 to Fig. 5). Figure 3 shows an example system 300 with attestation boundaries and the addition of a new node. In this figure, a new or selected node 321 is added, which may, for example, be offline from the cloud component 330 or untrusted. However, the new node 321 can be visible to a node 311 of the peers 312 in the trusted edge cluster 310. The trusted cluster 310 can, for example, be an EPID group. The new node 321 can be one of several nodes in its own trusted cluster 320. Discovery can be performed using a regular gossip protocol. A secure handshake can then be conducted to understand the security capabilities of the selected node 321. Once a secure channel is established, the new node 321 can be in an evaluation phase. This might involve having a marker or tag on all generated data.After the evaluation period, when node 321 becomes trusted for the trusted edge boundary, it can provide security services, communicate freely with the other nodes, and be open to speaking with new nodes about joining. The architecture supports hierarchical and distributed trust management, enabling multiple trust authorities to collaborate while maintaining consistent security policies. Sub-trust authorities could continuously participate in gossip logs to monitor node health, support levels, and capacity, allowing the network to dynamically adjust trust relationships and resource allocations. For example, in a scenario where a primary trust authority detects resource exhaustion in an edge network, sub-trust authorities could work together to redistribute workloads to other edge nodes with available capacity, maintaining overall system performance and security. The proposed architecture can also extend trust boundaries from CPUs to XPUs, enabling secure operations across a wider range of compute accelerators, such as GPUs and AI accelerators. This extension can facilitate the securing of more diverse workloads, including AI-driven applications that utilize specialized hardware. For example, an AI accelerator within an edge node could undergo separate attestation processes to ensure its operations are secure and trustworthy, thereby enhancing the overall security framework of the trust cluster. Implementing local trust authorities could leverage various technologies, including blockchain for distributed revocation management and gossip protocols for decentralized trust monitoring. By maintaining security gradients through hierarchical trust authorities, the system ensures consistent security policies while enabling flexibility and scalability. Additionally, by supporting AI accelerators and extending trust boundaries beyond traditional CPUs, AaaS adapts to evolving computing demands and enhances security across diverse processing environments. Further details and aspects of the concept for the local attestation service can be described in connection with the examples discussed above (e.g. Fig. 1 to Fig. 2) or below (e.g. Fig. 4 to Fig. 5). Fig. 4 illustrates a flowchart of an example of a procedure 400 for a local attestation service. The procedure 400 may be performed, for example, by a facility such as facility 10, as described herein. The procedure 400 may include: communicating 410 with a selected node outside the trust cluster; attesting 420 of the selected node; and, if the attestation of the selected node is successful, registering 430 of the selected node within the trust cluster. In some embodiments, the procedure may include establishing 411 a secure channel between the facility and the selected node. In some embodiments, prior to successful attestation, the selected node may be in an evaluation phase, and data generated by the selected node during the evaluation phase may be tagged 413. In some embodiments, after registering the selected node within the trust cluster, the method 400 may include periodically re-evaluating 440 the selected node for performance and / or cost efficiencies and migrating the selected node to another network within the trust cluster when a threshold is met. In some embodiments, the method 400 may further include de-registering 450 the selected node from the trust cluster. Further details and aspects of the concept for the local attestation service can be described in connection with the examples discussed above (e.g. Fig. 1, Fig. 2 to Fig. 3) or below (e.g. Fig. 5). Fig. 5 illustrates a computing device 700 according to one implementation of the invention. A circuit board 702 is housed in the computing device 700. The circuit board 702 can comprise a number of components, including, among others, a processor 704 and at least one communication chip 706. The processor 704 is physically and electrically coupled to the circuit board 702. In some implementations, the at least one communication chip 706 is also physically and electrically coupled to the circuit board 702. In other implementations, the communication chip 706 forms part of the processor 704. Depending on its applications, the computer device 700 may include other components, which may or may not be physically and electrically coupled to the circuit board 702. These other components include, but are not limited to, volatile memory (e.g., DRAM), non-volatile memory (such as ROM), flash memory, a graphics processor, a digital signal processor, a cryptoprocessor, a chipset, an antenna, a display, a touchscreen display, a touchscreen controller, a battery, an audio codec, a video codec, a power amplifier, a global positioning system device (GPS device), a compass, an accelerometer, a gyroscope, a loudspeaker, a camera, and a mass storage device (such as a hard disk drive, a compact disc (CD), a digital versatile disc (DVD), and the like). The 706 communication chip enables wireless communication for the transmission of data to and from the 700 computing device. The term "wireless" and its derivatives can be used to describe circuits, devices, systems, methods, techniques, communication channels, etc., that can transmit data over a non-solid medium by using modulated electromagnetic radiation. The term does not imply that the associated devices contain no wires whatsoever, although they may be absent in some embodiments. The 706 communication chip can implement any number of wireless standards or protocols, including, but not limited to, Wi-Fi (IEEE 802.11 family), WiMAX (IEEE 802.16 family), and IEEE 802.20, Long Term Evolution (LTE), Ev-DO, HSPA+, HSDPA+, HSUPA+, EDGE, GSM, GPRS, CDMA, TDMA, DECT, Bluetooth, derivatives thereof, and any other wireless protocols designated as 3G, 4G, 5G, and beyond. The computing device 700 can include a plurality of communication chips 706. For example, a first communication chip 706 can be designated for shorter-range wireless communication, such as Wi-Fi and Bluetooth, and a second communication chip 706 can be designated for longer-range wireless communication, such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, etc. The processor 704 of the computing device 700 includes an integrated circuit die that is housed within the processor 704. In some implementations of the invention, the integrated circuit die of the processor includes one or more devices mounted in an ePLB- or eWLB-based PoP package that includes a potting layer which directly contacts a substrate, according to implementations of the invention. The term "processor" can refer to any device or any section of a device that processes electronic data from registers and / or a memory to convert such electronic data into other electronic data that can be stored in registers and / or a memory. The communication chip 706 also includes an integrated circuit die that is housed within the communication chip 706. According to another implementation of the invention, the integrated circuit die of the communication chip includes one or more devices mounted in an ePLB- or eWLB-based P0P package that includes a potting layer which directly contacts a substrate, according to implementations of the invention. Further details and aspects of the concept for the local attestation service are mentioned in connection with the proposed concept or one or more of the examples described above (e.g., Fig. 1, Fig. 2, Fig. 3, Fig. 4 to Fig. 5). The concept for the local attestation service may include one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more of the examples described above. The aspects and features described in relation to a particular of the previous examples can also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example. It is further understood that the disclosure of multiple steps, processes, operations, or functions in the description or claims is not to be interpreted as implying that these operations necessarily depend on the described sequence, unless explicitly stated in a specific case or required for technical reasons. Therefore, the preceding description does not restrict the execution of multiple steps or functions to a specific sequence. Furthermore, in other examples, a single step, function, process, or operation may include and / or be subdivided into multiple sub-steps, functions, processes, or operations. If certain aspects relating to a device or system have been described, these aspects should also be understood as a description of the corresponding procedure. For example, a block, device, or functional aspect of the device or system may correspond to a feature, such as a process step, of the corresponding procedure. Accordingly, aspects described in relation to a procedure should also be understood as a description of a corresponding block, element, property, or functional feature of a corresponding device or system. An example (e.g., Example 1) concerns a setup for a local attestation service of a network within a trust cluster, wherein the setup includes: an interface circuitry, a memory circuitry, machine-readable instructions, and a processor circuitry for executing the machine-readable instructions to: communicate with a selected node outside the trust cluster; attest to the selected node; and, if the attestation of the selected node is successful, register the selected node within the trust cluster. Another example (e.g., Example 2) refers to a previously described example (e.g., Example 1) where the selected node is discovered if it is visible to a node within the trust cluster. Another example (e.g., Example 3) refers to a previously described example (e.g., any one of Examples 1 or 2), which further includes the machine-readable instructions for establishing a secure channel between the facility and the selected node. Another example (e.g., Example 4) refers to a previously described example (e.g., one of Examples 1 to 3), where the selected node includes a confidential computing environment and attesting the selected node includes attesting a confidential computing environment. Another example (e.g., Example 5) refers to a previously described example (e.g., one of Examples 1 to 4), where, after successful attestation, the selected node is registered to perform one of the following: communicate with other nodes in the trust cluster, provide security services, and discover other selected nodes outside the trust cluster. Another example (e.g., Example 6) refers to a previously described example (e.g., any one of Examples 1 to 5), where, prior to successful attestation, the selected node is in an evaluation phase. Another example (e.g., Example 7) refers to a previously described example (e.g., Example 6), where data produced by the selected node during the evaluation phase is marked. Another example (e.g., Example 8) refers to a previously described example (e.g., one of Examples 6 or 7), where the trust cluster includes several networks and where, during the evaluation phase, the selected node is evaluated for performance and / or cost efficiency and, after successful attestation, is registered with one of the several networks if a threshold is met. Another example (e.g., Example 9) refers to a previously described example (e.g., one of Examples 1 to 8), which further includes machine-readable instructions to periodically re-evaluate the selected node for performance and / or cost efficiencies after registering it within the trust cluster, and to migrate the selected node to another network within the trust cluster when a threshold is met. Another different example (e.g., Example 10) refers to a previously described example (e.g., any one of Examples 1 to 9), where the setup is an edge setup of the network. Another example (e.g., Example 11) refers to a previous example (e.g., one of Examples 1 to 10), and furthermore includes comprehensive machine-readable instructions for deregistering the selected node from the trust cluster. Another example (e.g., Example 12) relates to a previously described example (e.g., Example 11), where the registration of the selected node is revoked if at least one of the following is true: the selected node has an error; the selected node is re-attested, and the re-attesting fails; and the selected node is flagged as untrusted by another attestation service. Another example (e.g., Example 13) refers to a previously described example (e.g., any one of Examples 11 or 12), where the selected node is listed in a blockchain of untrusted nodes and the registration of the selected node is revoked by the trusted cluster. Another example (e.g., Example 14) refers to a previously described example (e.g., one of Examples 1 to 13), wherein the selected node is located within a second network that includes a second local attestation service, wherein attestation of the selected node includes communicating with the second local attestation service, and registering the selected node with the trust cluster further registers the second network within the trust cluster. An example (e.g., Example 15) refers to a procedure for a local attestation service of a network within a trust cluster, wherein the procedure includes: communicating with a selected node outside the trust cluster; attesting the selected node; and if the attestation of the selected node is successful, registering the selected node within the trust cluster. Another example (e.g., Example 16) refers to a previously described example (e.g., Example 15) where the selected node is discovered if it is visible to a node within the trust cluster. Another example (e.g., Example 17) refers to a previously described example (e.g., any one of Examples 15 or 16), which further includes establishing a secure channel between the facility and the selected node. Another example (e.g., Example 18) refers to a previously described example (e.g., one of Examples 15 to 17), where the selected node includes a confidential computing environment and attesting the selected node includes attesting a confidential computing environment. Another example (e.g., Example 19) refers to a previously described example (e.g., one of Examples 1 to 18), where, after successful attestation, the selected node is registered to perform one of the following: communicate with other nodes in the trust cluster, provide security services, and discover other selected nodes outside the trust cluster. Another example (e.g., Example 20) refers to a previously described example (e.g., any one of Examples 15 to 19), where, prior to successful attestation, the selected node is in an evaluation phase. Another example (e.g., Example 21) refers to a previously described example (e.g., Example 20), where data produced by the selected node during the evaluation phase are marked. Another example (e.g., Example 22) refers to a previously described example (e.g., one of Examples 20 or 21), where the trust cluster includes several networks and where, during the evaluation phase, the selected node is evaluated for performance and / or cost efficiency and, after successful attestation, is registered with one of the several networks if a threshold is met. Another example (e.g., Example 23) refers to a previously described example (e.g., one of Examples 15 to 22), which further includes, after registering the selected node within the trust cluster, periodic re-evaluation of the selected node for performance and / or cost efficiencies and migration of the selected node to another network within the trust cluster when a threshold is met. Another different example (e.g., Example 24) refers to a previously described example (e.g., any of Examples 15 to 23), where the setup is an edge setup of the network. Another example (e.g., example 25) refers to a previous example (e.g., one of examples 15 to 24), further encompassing the unregistration of the selected node from the trust cluster. Another example (e.g., Example 26) relates to a previously described example (e.g., Example 25), where the registration of the selected node is revoked if at least one of the following is true: the selected node has an error; the selected node is re-attested, and the re-attesting fails; and the selected node is flagged as untrusted by another attestation service. Another example (e.g., Example 27) refers to a previously described example (e.g., any one of Examples 25 or 26), where the selected node is listed in a blockchain of untrusted nodes and the registration of the selected node is revoked by the trusted cluster. Another example (e.g., Example 28) refers to a previously described example (e.g., one of Examples 15 to 27), wherein the selected node is located within a second network that includes a second local attestation service, wherein attestation of the selected node includes communicating with the second local attestation service, and registering the selected node with the trust cluster further registers the second network within the trust cluster. An example (e.g., Example 29) refers to a non-volatile, computer-readable medium comprising program code which, when executed on a processor, computer, or programmable hardware component, causes the processor, computer, or programmable hardware component to perform one of the procedures from a previously described example (e.g., one of Examples 15 to 28). The aspects and features described in relation to a particular of the previous examples can also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example. Examples may also include a (computer) program with program code to execute one or more of the above procedures, when the program is executed on a computer, processor, or other programmable hardware component. Thus, steps, operations, or processes of different procedures described above may also be executed by programmed computers, processors, or other programmable hardware components. Examples may also include program storage devices, such as digital data storage media, that are machine-, processor-, or computer-readable and can encode and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. Program storage devices may include, for example, digital storage devices, magnetic storage media such as magnetic disks and tapes, hard disks, or optically readable digital data storage media.Other examples may include computers, processors, control units, (field-)programmable logic arrays ((F)PLAs), (field-)programmable gate arrays ((F)PGAs), graphics processing units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoC) systems programmed to perform the steps of the procedures described above. It is further understood that the disclosure of multiple steps, processes, operations, or functions in the description or claims is not to be interpreted as implying that these operations necessarily depend on the described sequence, unless explicitly stated in a specific case or required for technical reasons. Therefore, the preceding description does not restrict the execution of multiple steps or functions to a specific sequence. Furthermore, in other examples, a single step, function, process, or operation may include and / or be subdivided into multiple sub-steps, functions, processes, or operations. If certain aspects relating to a device or system have been described, these aspects should also be understood as a description of the corresponding procedure. For example, a block, device, or functional aspect of the device or system may correspond to a feature, such as a process step, of the corresponding procedure. Accordingly, aspects described in relation to a procedure should also be understood as a description of a corresponding block, element, property, or functional feature of a corresponding device or system. As used herein, the term "module" refers to logic that may be implemented in a hardware component or device, software or firmware running on a processing unit, or a combination thereof, to perform one or more operations consistent with the present disclosure. Software and firmware may be implemented as instructions and / or data stored on non-volatile, computer-readable storage media. As used herein, the term "circuit arrangement" alone or in any combination may include: a non-programmable (hard-wired) circuit arrangement, a programmable circuit arrangement such as processing units, a state machine circuit arrangement, and / or firmware that stores instructions executable by a programmable circuit arrangement.The modules described herein can be embodied collectively or individually as a circuit arrangement that forms part of a computing system. Thus, any of the modules can be implemented as a circuit arrangement. A computing system described as being programmed to perform a procedure can be programmed to perform the procedure using software, hardware, firmware, or combinations thereof. Any of the disclosed methods (or a part thereof) may be implemented as computer-executable instructions or a computer program product (e.g., machine-readable instructions, program code, etc.). Such instructions may cause a computing system or one or more processing units capable of executing computer-executable instructions to perform any of the disclosed methods. As used herein, the term "computer" refers to any computing system or device described or mentioned herein. Thus, the term "computer-executable instructions" refers to instructions that can be executed by any computing system or device described or mentioned herein. The computer-executable instructions can be, for example, part of the operating system of the computing system, an application stored locally on the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the procedures described herein can be performed by computer-executable instructions carried out by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to computer-executable instructions can be downloaded to a computing system from a remote server. Furthermore, it is understood that an implementation of the disclosed technologies is not limited to any specific computer language or computer program. For example, the disclosed technologies can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, assembly language, or any other programming language. Likewise, the disclosed technologies are not limited to any particular computer system or type of hardware. Furthermore, any of the software-based examples (which include, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed by suitable means of communication. Such suitable means of communication include, for example, the Internet, the World Wide Web, an intranet, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, ultrasonic, and infrared communication), electronic communication, or other such means of communication. The disclosed methods, devices, and systems are not to be understood as being restrictive in any way. Instead, the present disclosure applies to all novel and non-obvious features and aspects of the various disclosed examples, both individually and in various combinations and sub-combinations. The disclosed methods, devices, and systems are not limited to any specific aspect or feature, nor do the disclosed examples require that any specific advantages or problems be solved. Operating theories, scientific principles, or other theoretical descriptions presented herein with reference to the devices or methods of this disclosure are provided for convenience only and are not intended to limit the scope. The devices and methods in the appended claims are not limited to those devices and methods that operate in the manner described by such operating theories. The following claims are hereby incorporated into the detailed description, each claim standing independently as a separate example. It should also be noted that, although in the claims a dependent claim refers to a specific combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby expressly suggested unless it is stated in a particular case that a specific combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

A computer program comprising instructions which, when executed by a computer, cause the computer to perform operations that include: enabling local attestation of a network within a trust cluster, wherein enabling local attestation includes attesting nodes associated with the network within the trust cluster; communicating with a selected node outside the trust cluster; and attesting the selected node, wherein the selected and attested node is added to the trust cluster. Computer program according to claim 1, wherein the node is evaluated before being added to the trust cluster. Computer program according to claim 1 or 2, wherein the node is evaluated based on one or more security protocols or operational protocols associated with the trust cluster. Computer program according to claim 1, 2 or 3, wherein enabling local attestation further includes reporting and logging events. A computer-implemented method comprising: enabling local attestation of a network within a trust cluster, wherein enabling local attestation includes attesting nodes associated with the network within the trust cluster; communicating with a selected node outside the trust cluster; and attesting the selected node, wherein the selected and attested node is added to the trust cluster. Setup, comprising: Processing circuitry configured to: Enable local attestation of a network within a trust cluster, wherein enabling local attestation includes managing and attesting nodes associated with the network within the trust cluster; Communicate with a selected node outside the trust cluster; and Attest to the selected node, wherein the selected and attested node is added to the trust cluster.

Images