]> Arm Ltd

yogesh.deshpande@arm.com

Huawei Technologies France S.A.S.U.

junzhang1@huawei.com

Huawei Technologies France S.A.S.U.

houda.labiod@huawei.com

Fraunhofer SIT

henk.birkholz@sit.fraunhofer.de

Security RATS IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verifiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction A Verifier plays a central role in any Remote Attestation System. A Verifier appraises the Attester and produces Attestation Results, which are essentially a verdict of attestation. The results are consumed by the Relying Party to decide the trustworthiness of the Attester, before making any critical decisions about the Attester, such as admitting it to the network or releasing confidential resources to it. Attesters can come in a wide variety of shapes and forms. For example, Attesters can be endpoints (edge or IoT devices) or complex machines in the cloud. Composite Attester () generates Evidence that consists of multiple parts. For example, in data center servers, it is not uncommon for separate Attesting Environments (AE) to serve a subsection of the entire machine. One AE might measure and attest to what was started on the main CPU, while another AE might measure and attest to what was started on the machine's GPU. Throughout this document we use the term Component Attester () to address the single entity which produces its own Evidence in a Composite Attester system. In a Composite Attester system, it may not be possible for a single Verifier to possess all the capabilities or information required to conduct a complete appraisal of the Attester. Refer to () for motivation of this document. Multiple Verifiers need to collaborate to reach a conclusion on the appraisal and produce the Attestation Results. This document describes three topological patterns of multiple Verifiers that work in a coordinated manner to conduct appraisal of a Composite Attester to produce Attestation Results.

Need for Multiple Verifiers To conduct the task of Evidence appraisal, a Verifier requires:

1. Reference Values from trusted supply chain actors, known as Reference Value Providers (), producing, aggregating, or administering Attesters
2. Endorsements from trusted supply chain actors, known as Endorsers (), producing, certifying, or compliance checking Attesters
3. Appraisal Policy for Evidence, which is under the control of the Verifier Owner

The Verifier inputs listed above largely vary dependent on the make and the model of the Attesters. Typically, Composite Attesters are complex systems comprising different types of components, potentially originating from multiple suppliers and integrated into a single system. Consequently, the Attestation Evidence produced by such a system may comprise a heterogeneous combination of Evidence, reflecting the different types of Attesting Environments associated with each Component Attester, such as CPU, GPU, or FPGA variants. When conducting Evidence appraisal for a Composite Attester, the following challenges remain:

1. An Attester's composition can change over time based on market requirements and availability (e.g., a set of racks in a data center gets thousands of new FPGAs). It is highly unlikely that there is always one appropriate Verifier that satisfies all the requirements that a complex and changing Composite Attester imposes. It may not be economically viable to build and maintain such a degree of complexity in a single Verifier.
2. A Verifier Owner may have an Appraisal Policy for Evidence of a Component Attester that is internal to them and which they may choose not to reveal to a “monolithic" Verifier.
3. A Reference Value Provider may not wish to reveal its Reference Values or their lifecycle to a monolithic Verifier.

As a consequence, there may not be a single actor in the ecosystem that can stand up and take ownership of verifying every Component Attester due to a lack of knowledge, complexity, regulations or associated cost. The mix today is a combination of Verifier services provided by component manufacturers, Verifiers provided by integrators, and Verifiers under local authority (i.e., close to the attester). Rarely is it just one of these.

Reference Use Cases This section covers generic use cases that demonstrate the applicability of Multi Verifier, regardless of specific solutions. Its purpose is to motivate various aspects of the architecture presented in this document. There are many other use cases; this document does not contain a complete list.

Verification of Devices containing heterogenous components A device may contain a Central Processing Unit (CPU), as well as heterogeneous acceleration components such as Graphical Processing Units (GPUs), Neural Processing Units (NPUs) and Tensor Processing Units (TPUs) from different suppliers. These components can be used to speed up processing or assist with AI inference. Trustworthiness assessment of the device requires trust in all of these components. However, due to business concerns such as scalability, complexity and cost of infrastructure, the Verifier for each type of component may be deployed separately by each vendor. When these Verifiers operate together, they must interact with each other, understand the topology and interoperate using standardised protocols. For instance, they may need to exchange Partial Evidence relating to the relevant component or Partial Attestation Results for it. Attester: A Device having multiple components Relying Party: An entity which is making trust decisions for such an Attester

Verification of Workloads operating in Confidential Computing environments As organisations move more workloads into untrusted or shared environments, Confidential Computing is becoming increasingly important. In such a system, an application or workload (which could be an AI model, database process or financial service, for example) is executed inside a Trusted Execution Environment, such as a Confidential Virtual Machine (CVM). When the workload starts, the TEE can generate a cryptographic attestation report providing:

1. The workload is running on a platform with a known state.
2. The workload is running the correct application.

The platform is often built by an independent TEE vendor, while the workloads are deployed by workload owners from different parts of the supply chain. Verification of Attestation for such a system requires independent, yet mutually coordinated, verification of: Platform claims appraised by a Platform Verifier and Workload claims appraised by a Workload Verifier. Attester: A layered Attester containing a platform and a workload running in a CC environment Relying Party: An entity which is making trust decisions, such as a key release to a workload

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses terms and concepts defined by the RATS architecture. For a complete glossary, see . Specifically this document heavily uses the terms Attesting Environment , Layered Attester and Composite Device

Glossary This document uses the following terms:

Composite Attester:

A Composite Attester is either a Composite Device () or a Layered Attester () or any combination of these.

Component Attester:

A Component Attester is a single Attester of a Composite Attester. For example, it can be a sub-entity or a layer within a composition. For this document, a Component Attester is an entity which produces a single Evidence which can be appraised by a Component Verifier.

Composite Evidence (CE):

Evidence produced by a Composite Attester.

Partial Evidence (PE):

Extract from a Composite Evidence. It consists of at least one or more Component Evidence.

Lead Verifier (LV):

A Verifier which acts as a main Verifier to receive Composite Evidence from a Composite Attester in a Hierarchical pattern .

Component Verifier (CV):

A Verifier which is responsible for the Verification of one single component or a layer.

Partial Attestation Results (PAR):

Partial Attestation Results are produced by a Component Verifier, and contain partial results from at least one or more Component Attesters.

Aggregated Attestation Results (AAR):

Aggregated Attestation Results refer to a collection of Attestation Results produced upon completion of appraisal of a Composite Attester.

Multi Verifier topological patterns A Composite Attester has multiple Component Attesters. Each Attester requires a different set of Verifiers. Hence multiple Verifiers collaborate to appraise a Composite Attester.

Hierarchical Pattern The figure below shows the block diagram of a Hierarchical Pattern.

Hierarchical Pattern | | | | Verifier 1 | | .-------------+ | | | PAR_1 '------------' | v ... .---------------. CE .----+----------. PE_i .------------. | +-------->| +-------->| | | Attester / RP | | Lead Verifier | | Verifier i | | |<--------+ |<--------+ | '---------------' AAR '----+----------' PAR_i '------------' | ^ ... | | PAR_n .------------. | '-------------+ | | | Verifier n | '------------------->| | PE_n '------------' Legend: - CE: Composite Evidence - AAR: Aggregated Attestation Results - PE_i: Partial Evidence of i-th Component Attester - PAR_i: Partial Attestation Results of i-th Component Attester - Verifier i : This represents Component Verifier-i (CV-i). ]]>

The following sub-sections describe the various roles that exist in this pattern.

Lead Verifier In this topological pattern, there is an Entity known as Lead Verifier (LV). Lead Verifier is the central entity in communication with the Attester (directly in passport model or indirectly via the Relying Party in background-check model, ()). It receives Attestation Evidence from a Composite Attester.

Integrity Verification of Composite Evidence The Lead Verifier must verify the integrity of the Composite Evidence. There are many ways to integrity protect the Composite Evidence, as given below.

1. If the Composite Attestation Evidence is signed, LV must verify the integrity of the Evidence by validating the signature. If signature verification fails, the Verification is terminated.
2. If the Composite Attestation Evidence is not signed but each Component Evidence, is signed and there is a cryptographic binding to link the individual components, then the LV must verify the binding. If the cryptographic binding fails, the Verification is terminated.

Otherwise LV performs the following steps.

• Lead Verifier has the required knowledge to break down the Composite Evidence into Partial Evidence. It decodes the Composite Evidence to extract the Component Attesters' Evidence. This may lead to "N" Partial Evidence, one for each Component Attester.
• The Lead Verfier relays each Partial Evidence (PE) to its own Component Verifier (CV). In certain topologies, it is possible that the PE is not protected. In such cases, the Lead verifier must wrap the Partial Evidence (example PE_1) in a signed Conceptual Message Wrapper (CMW), and then send it to its Component Verifier (example CV 1). Upon successful appraisal of Evidence by the CV, it receives signed Component Attester Attestation Results also known as Partial Attestation Results. There are many protocols to determine how a Lead Verifier can select the Component Verifiers (e.g., static configuration or a discovery protocol). Verifier discovery is out of scope for this specification.
• Once the Lead Verifier receives Partial Attestation Results from all the Verifiers, it combines the results from each Verifier to construct Aggregated Attestation Results (AAR). The Lead verifier may apply its own policies and also add extra claims as part of its appraisal.
• Lead Verifier signs the final AAR and conveys it to the Attester (in Passport model) or to the Relying Party (in background check model).

The overall verdict may be dependent on the Appraisal Policy of the Lead Verifier.

Component Verifier The role of a Component Verifier is to receive Partial Evidence from the Lead Verifier and produce signed Partial Attestation Results to the Lead Verifier.

Trust Relationships In this topology the Lead Verifier is trusted by Component Verifiers (example CV 1). Component Verifiers are provisioned with the Trust Anchors (see ) for the Lead Verifier. Also, each of the Component Verifier is trusted by the Lead Verifier. Lead Verifier is provisioned with the Trust Anchors (see ) for CV 1..N.

Cascaded Pattern The figure below shows the block diagram of a Cascaded Pattern.

Cascaded Pattern | i +----------->| i +----- ... ---->| i | | Attester / RP | | f | | f | | f | | |<------+ i |<-----------+ i |<---- ... -----+ i | '---------------' AAR | e | AAR | e | AAR=PAR_1..n | e | | r | | r | | r | | | | | | | | 1 | | 2 | | n | '-----' '-----' '-----' Legend: - CE: Composite Evidence - AAR: Aggregated Attestation Results - PAR: Partial Attestation Results - Verifier i : This represents Component Verifier-i (CV-i). ]]>

In this topological pattern, the Attestation Verification happens in sequence. Verifiers are cascaded to perform the Attestation Appraisal. Each Verifier in the chain has the knowledge to derive or extract the Partial Evidence, which it can appraise, from the Composite Evidence. Attester may send the Composite Evidence (CE) to any of the Verifiers (directly in the passport model, or indirectly via the Relying Party in the background-check model). The Verifier which processes the Composite Evidence, acts as the first Verifier CV1 and verifies the signature on the Evidence, if present. It extracts the Partial Evidence from the Composite Evidence, performs Appraisal of the Component Attester whose Reference Values and Endorsements are in its database. Once the appraisal is complete, it forwards the Composite Evidence and signed Partial Attestation Results to the subsequent Verifier. The process is repeated, until the entire appraisal is complete. The last Verifier, i.e. CV-N, completes its Appraisal of the Partial Evidence, that it can appraise. It has now all the signed Partial Attestation Results and creates the Aggregated Attestation Results (AAR), which is a collection of all signed PARs. To ensure the integrity of the collection, CV-N signs the AAR. It returns the AAR to the N-1 Verifier (from where it received the Composite Evidence and Partial AR). The process is repeated, i.e. AAR is returned in the chain until the Verifier, which recieved the initial Composite Evidence is reached. At this point in time the Aggregated Attestation Results are signed and the AAR is sent to the Attester (in Passport Model) or Relying Party (in background check model). As shown in the picture, the Partial Attestation Results and Composite Evidence are transmitted to a chain of Verifiers, till the Appraisal is complete. Upon completion, the last Verifier in the chain combines the incoming Partial Attestation Results with the results from its own Evidence Appraisal, and passes the Aggregated Attestation Results to the Verifier from which it receives Composite Evidence. The visibility of evidence within this pattern is subject to the privacy policies described in . There are many protocols to determine how a Verifier can select the next Verifier to route the CE and PAR (e.g., (e.g., static configuration or a discovery protocol). Verifier discovery is out of scope for this specification.

Trust Relationships

Verifiers In the cascaded pattern, the communicating Verifiers must trust each other. Each Verifier should have the trust anchor for the Verifier it is communicating to (i.e. either sending information or receiving information). This prevents man in the middle attack for the Partial Attestation Results received by a Verifier or an Aggregated Attestation Results (AAR) which it receives in the return path.

Relying Party and Verifiers In the cascaded pattern, the RP may communicate with any Verifier and thus receive its Attestation Results. Hence RP must trust all the Verifiers (in a Distributed Trust Model) or only trust the first Verifier (in a Delegated Trust Model).

Hybrid Pattern In a particular deployment, there is a possibility that the two models presented above can be combined to produce a hybrid pattern. Note that there are many ways to combine the two models. The figure below illustrates an example where Verifier 2 in the Cascaded Pattern becomes the Lead Verifier for the remaining Verifers from 3, to N.

Hybrid Pattern | Verifier 1 |<--->| Verifier 2 / LV | '---------------' '-----------------' '-----------------' ^ ^ | | .---------------' | | | v v .-----------------. .-----------------. | Verifier 3 | ... | Verifier N | '-----------------' '-----------------' Legend: - LV: Lead Verifier - Verifier 1..N : Component Verifiers ]]>

Freshness The Verifier needs to ensure that the claims included in the Evidence reflect the latest state of the Attester. As per RATS Architecture, the recommended freshness is ascertained using either Synchronised Clocks, Epoch IDs, or nonce, generated by the Verifier. When Verifiers generates freshness, in a Multi Verifier System, the generation and subsequent verification of freshness during appraisal, depends on the specific mechanism utilized. For example, when nonce is employed, in a Heirarchical pattern, one possible approach is for the Lead Verifier to autonomously generate a unique nonce, or autonomously by the first Verifier (in Cascaded pattern) communicating with the Attester. This approach simplifies the freshness appraisal procedure by centralizing the processing of the challenge. The other alternative may be for a LV to generate a nonce by aggregating the nonces generated by each participating Component Verifier. In this case, the freshness appraisal procedure requires obtaining the individual component nonces received as a claim from PAR and recomputing the aggregated nonce. Conversely, when Synchronized Clocks or Epoch IDs are employed, the verification of freshness can be performed independently by each individual Component Verifier.

Security Considerations The Verifier is not part of the Attester’s Trusted Computing Base (TCB), but acts as a critical component in the Relying Party’s trust decision chain. Therefore, its security directly affects the trustworthiness of the entire remote attestation process. When multiple Verifiers coordinate to conduct an appraisal, this may increase the attack surface, depending on the system architecture and trust assumptions. Any mistake in the appraisal procedure conducted by one or more Verifiers could lead to severe security implications, such as incorrect Attestation Results of a component or a composition to the Relying party. This section details the security threats and mitigation strategies specific to the multi-verifier topologies described in this document. In addition to the considerations herein, Verifiers MUST follow the guidance detailed in the Security and Privacy considerations of a RATS Verifier as detailed in () and the RATS Architecture (Section and Section of ).

Adversarial Model The security analysis in this section assumes that attackers may:

1. Eavesdrop on any communication channel between Verifiers.
2. Inject, modify, replay, or delay messages traversing the network.
3. Compromise one or more Verifiers in the ecosystem, attempting to leak sensitive information (e.g., Evidence, Reference Values) or manipulate Attestation Results.
4. Perform Man-in-the-Middle (MitM) attacks between any two communicating entities.

The system is designed to be resilient under the assumption that the cryptographic keys used for signing Evidence and Attestation Results (by authentic entities) are not compromised.

General Considerations All communications between entities (Attester-Verifier, Verifier-Verifier, Verifier-RP) MUST be secured using mutually authenticated, confidential, and integrity-protected channels (e.g., TLS). It is recommended that any two verifiers establishing a communication channel perform mutual attestation before exchanging any attestation messages.

Security for Topological Patterns

Hierarchical Pattern The hierarchical pattern introduces a central trust entity, the Lead Verifier (LV). The security of the entire system relies on the integrity and correct operation of the LV.

Threats and Mitigations

LV Compromise Threat: A compromised LV can orchestrate attacks, such as approving malicious attestations, wrongly aggregating attestation results or leaking sensitive evidence. This is a single point of failure from the trust perspective. Mitigation: The LV MUST be hardened and operate and store its Keys in a secure environment. Its operation SHOULD be auditable. Component Verifiers are provisioned with the Trust Anchors (see ) for the Lead Verifier so that they can establish required trust in the authority of the LV.

Communication Security (LV <-> CV) Threat: Eavesdropping or manipulation of evidence/results in transit. Mitigation: All communications between the LV and CVs MUST be mutually authenticated and confidential (e.g., using TLS with mutual authentication). This ensures integrity, confidentiality, and authenticity of the messages exchanged between the Verifiers.

Evidence Integrity and Origin Authentication (LV -> CV) Threat: The LV could forward manipulated evidence to a CV, or an attacker could inject fake evidence. Mitigation: The conceptual message containing the Partial Evidence MUST be integrity-protected and authenticated. If the Partial Evidence is natively signed by the Component Attester at origin, the CV can verify it directly. If the Partial Evidence lacks inherent signatures (e.g., in UCCS), the LV MUST sign the Partial Evidence using a key that the CV trusts. This prevents any on-path attacker from altering the Partial Evidence.

Results Integrity and Origin Authentication (CV -> LV) Threat: Partial Attestation Results could be manipulated in transit or forged by a malicious CV. Mitigation: Each Partial Attestation Result MUST be digitally signed by the CV. LV should maintain a list of trust anchors for the CV's it communicates with. The LV MUST validate the signature using the required trust anchor for the CV, before adding the Partial Attestation Results to the Aggregated Attestation Results.

Replay Attacks Threat: An adversary Component Verifier replays old Evidence or Attestation Results. Mitigation: Freshness is enforced based on the selected mechanism described in .

Cascaded Pattern The cascaded pattern distributes trust but requires each Verifier in the chain to be trusted to correctly handle and forward Attestation messages. The chain's security is only as strong as its weakest link.

Threats and Mitigations

Verifier Compromise Threat: Any compromised Verifier in the chain can block, delay, or manipulate the attestation process. It can inject false partial results, drop evidence, or leak sensitive information. Mitigation: Relying Parties and Verifiers MUST be configured with strict trust policies defining the allowed paths and trusted Verifiers. Operations SHOULD be logged for auditability.

Communication Security Threat: Eavesdropping or manipulation of evidence and results between Verifiers. Mitigation: Each hop between Verifiers MUST be secured with mutually authenticated and confidential channels (e.g., TLS with mutual authentication).

Evidence and Results Protection Threat: Lack of end-to-end security allows intermediate Verifiers to manipulate evidence or results that are not intended for them to appraise. Mitigation: End-to-end integrity protection is RECOMMENDED. The Composite Evidence SHOULD be signed by the Attester. Partial and Aggregated Attestation Results SHOULD be signed by the Verifier that generated them. This allows subsequent Verifiers and the Relying Party to verify that results have not been tampered with by intermediate nodes.

Replay Attacks Threat: An adversary replays old Evidence or Attestation Results. Mitigation: Freshness is enforced in accordance with the mechanisms described in .

Security of the Hybrid Pattern As the hybrid pattern is the composition of hierarchical pattern and cascade pattern, all the threats and mitigations that are applicable for these two patterns are also applicable for the general hybrid pattern.

Privacy Considerations The appraisal of a Composite Attester requires exchange of attestation-related messages, for example, Partial Evidence and Partial Attestation Results, among multiple Verifiers. This can potentially leak sensitive information about the Attester's configuration, identities and the nature of composition. However, when carefully designed, a multi-verifier architecture can actually mitigate these privacy concerns. By distributing appraisal responsibilities and ensuring that no single Verifier has access to the full set of Evidence, the risk of comprehensive device profiling or tracking is reduced. Nonetheless, such benefits depend on strong implementation practices.

• Minimization: Attesters SHOULD only generate Evidence that is strictly necessary for the appraisal policy. Verifiers SHOULD only request necessary claims. Refer to () and () for further guidance on procedures for minimization of Evidence.
• Confidentiality: Evidence containing sensitive information SHOULD be encrypted so that it can only be accessed by the intended Verifier and not by any unauthorised parties (including other Verifiers in the hierarchy, cascade or hybrid pattern). This is crucial in multi-tenant environments.
• Policy Handling: Verifiers SHOULD be careful not to leak their internal appraisal policies (e.g., through error messages or timing side channels) when communicating with other Verifiers or Attesters, as this information could be exploited by an attacker to manipulate appraisal.

IANA Considerations

Acknowledgments The authors would like to thank Simon Frost, Usama Sardar, Paul Howard, Mark Novak, Michael Richardson, & Yaron Sheffer for their reviews and suggestions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Crypto4A Inc. Cryptic Forest Software University of the Bundeswehr Munich Fraunhofer SIT This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce Evidence tailored for expected use.

Contributors Linaro

Thomas.Fossati@linaro.org

UBITECH Ltd.

agiannetsos@ubitech.eu

NVIDIA

sbellock@nvidia.com

ORANGE

ghada.arfaoui@orange.com