VerifiableFL: Verifiable Claims for Federated Learning using Exclaves

1. Problem Statement

Federated Learning (FL) allows multiple data providers to jointly train a machine learning model without sharing raw data. However, this distributed nature creates a significant challenge: verifying claims about how the model was trained.

• The Trust Gap: Current FL systems rely on "reputational trust." Data providers claim to use specific datasets, apply sanitization (e.g., removing PII), or follow specific algorithms. Without proof, a malicious provider could skip steps (e.g., skipping data cleaning to save costs) or inject poisoned data, and the final model would still be accepted.
• Limitations of Existing Solutions (TEEs): Prior approaches used Trusted Execution Environments (TEEs) like Intel SGX or AMD SEV-SNP to secure FL training. However, the authors identify two critical flaws in relying on TEEs for verifiable claims:
  1. Static vs. Runtime: TEEs typically provide static attestation (verifying the code at deployment time). They cannot easily prove that specific runtime data transformations (like sanitizing a specific dataset) occurred correctly during training.
  2. Confidentiality Dependency: TEE attestation relies on the confidentiality of the TEE memory (to protect attestation keys). If an attacker compromises confidentiality via side-channel attacks, they can forge attestation proofs, breaking the integrity guarantees.

2. Methodology: Exclaves and VerifiableFL

The authors propose VerifiableFL, a system that decouples integrity from confidentiality to provide runtime verifiable claims.

A. The Core Abstraction: Exclaves

The system introduces a new hardware abstraction called an Exclave.

• Definition: An Exclave is an integrity-only execution environment. Unlike TEEs, it does not guarantee data confidentiality.
• Key Property: The security of an Exclave relies solely on the integrity of the code and data. Even if an adversary can read all data inside the Exclave (via side-channels or direct access), they cannot alter the code or the attestation process.
• Mechanism:
  • The Exclave uses a secure hardware coprocessor (e.g., AMD PSP) to maintain a signing key that is never accessible to software.
  • It generates Exclave Data Records (EDRs) at runtime. An EDR is a signed statement binding:
    1. The code measurement (hash of the code).
    2. The input data hash.
    3. The output data hash.
  • This proves that a specific transformation was performed by specific code on specific data.

B. System Architecture (VerifiableFL)

VerifiableFL extends the NVIDIA NVFlare framework to execute FL tasks inside Exclaves.

• Workflow:
  1. Task Execution: FL tasks (Local Training, Differential Privacy, Aggregation, Model Update) run inside Exclaves.
  2. EDR Generation: Upon task completion, the Exclave generates an EDR containing hashes of inputs, outputs, and code.
  3. Dataflow Graph Construction: All EDRs are collected to build an Exclave Dataflow Graph (EDG). This is a directed acyclic graph where nodes are EDRs and edges represent data flow (matching output hashes of one task to input hashes of the next).
  4. Auditing: A third-party auditor (or regulator) inspects the EDG to verify claims.
     • Example Claim Verification: To verify "Data Sanitization," the auditor checks if the input hash of the training task matches the output hash of a sanitization task. If the graph is broken or missing nodes, the claim is invalid.

C. Implementation Details

• Hardware: Implemented on AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging).
• Emulation: Since modifying proprietary firmware to create "secret-free" communication with the Platform Security Processor (PSP) is difficult, the authors implemented a variant using a Virtual TPM (vTPM) to emulate the signing functionality. This offers similar performance with slightly weaker security guarantees (relying on the vTPM's isolation rather than a dedicated hardware signer).
• Storage: Uses dm-verity with Merkle trees to ensure the integrity of datasets stored on disk before they are loaded into the Exclave.

3. Key Contributions

1. Exclave Abstraction: A novel hardware-based integrity-only execution environment that is immune to data leakage attacks because it does not rely on keeping data secret, only on the integrity of the attestation key.
2. Runtime Attestation: A mechanism to generate Exclave Data Records (EDRs) that bind code, inputs, and outputs, enabling verification of specific data transformations (e.g., sanitization, noise addition) rather than just static code presence.
3. Exclave Dataflow Graph (EDG): A method to aggregate EDRs into a global graph that allows auditors to verify end-to-end properties of the FL training process (e.g., "Was the model trained on the claimed dataset?" or "Was differential privacy applied?").
4. System Implementation: A working prototype extending NVFlare that integrates Exclaves without requiring changes to the FL job logic or the framework's core orchestration.

4. Results and Evaluation

The authors evaluated VerifiableFL using various models (GPT-2, BERT, VGG9, LeNet) and datasets (Wikitext, NCBI-disease, CIFAR-10) on Azure cloud infrastructure.

• Performance Overhead:
  • VerifiableFL introduces less than 12% overhead compared to unprotected FL training.
  • For moderate-to-large models (GPT-2, BERT, VGG9), overhead is <10%.
  • The overhead is primarily driven by the distributed nature of Exclaves (network serialization) and runtime attestation generation, not the cryptographic signing itself (which takes ~4ms).
• Scalability: The system scales linearly with the number of clients. Adding more clients increases throughput proportionally, similar to baseline FL systems.
• Auditing Overhead: Verifying claims is computationally cheap. For 100 clients training for 1,000 rounds, the auditor takes only ~19 seconds to verify signatures and construct the graph. Storage overhead is minimal (~162 MB).
• Secure Storage: Using integrity-protected storage (dm-verity) reduces read throughput by ~62% due to Merkle tree checks, but this is a one-time cost per dataset load and is manageable for most FL workloads.

5. Significance

• Regulatory Compliance: VerifiableFL directly addresses emerging regulations like the EU AI Act, which mandates transparency regarding training data provenance, sanitization, and bias detection. It provides the cryptographic proof required to satisfy these legal requirements.
• Security Model Shift: By moving from "Confidentiality + Integrity" (TEEs) to "Integrity-Only" (Exclaves), the system eliminates the vulnerability to side-channel attacks that plague current TEE-based FL solutions. It proves that for verification purposes, data secrecy is not strictly necessary; integrity is sufficient.
• Trust in Closed-Source Models: It enables model providers to make verifiable claims about their training processes even when the training code and data are proprietary, shifting trust from "reputation" to "cryptographic proof."

In summary, VerifiableFL solves the "black box" problem in Federated Learning by providing a lightweight, hardware-backed mechanism to cryptographically prove that a model was trained exactly as claimed, without requiring the data to be kept secret from the hardware operator.