Sharing is caring: Attestable and Trusted Workflows out of Distrustful Components

This paper presents Mica, a confidential computing architecture built on Arm CCA that decouples confidentiality from trust by enabling tenants to explicitly define, restrict, and attest communication paths between distrustful TEE components, thereby preventing sensitive data leakage without significantly expanding the trusted computing base.

The Gist

The Big Problem: The "Trust Me" Trap

Imagine you are building a high-security factory to process your most valuable secrets (like your bank details or private medical records). You hire three different companies to do the work:

1. Company A sorts the data.
2. Company B analyzes it.
3. Company C stores the results.

In the current world of "Confidential Computing" (using special secure hardware called TEEs), each company gets its own super-secure, locked room. The hardware guarantees that no one outside can peek inside their room.

However, there is a catch: To do their job, these companies need to pass data to each other. They have to hand a package from Room A to Room B, and then to Room C.

Currently, the hardware says: "I will lock the rooms, but once you hand the package to the next room, I don't know what happens. You have to trust that Company B won't peek at the package, and that Company C won't steal it."

This is a fragile assumption. In the real cloud, these companies often don't trust each other, they might be rivals, or they might be owned by different people. Asking them to trust each other is like asking a spy to trust the person they are trying to catch. If one company is sloppy or malicious, your secrets leak.

The Solution: Mica (The "Strict Bouncer")

The researchers built a new system called Mica. Instead of relying on the companies to be honest, Mica acts like a super-strict, rule-following bouncer who controls every single door and window between the rooms.

Mica changes the rules of the game in three clever ways:

1. From "Implicit" to "Explicit" (The Guest List)

• Old Way: "You can talk to whoever you want, as long as you don't get caught." (This relies on the software inside the room being perfect).
• Mica Way: "You must submit a Guest List before you start."
  • You tell Mica: "I am only allowed to pass a package to Company B. I am NOT allowed to talk to the internet, and I am NOT allowed to talk to Company C."
  • Mica checks this list. If you try to pass a package to anyone not on the list, Mica slams the door shut immediately.

2. The "Chain of Custody" (The Inductive Step)

This is the coolest part. Mica doesn't just check your rules; it checks your neighbor's rules too.

• If Company A says, "I only talk to B," Mica looks at Company B's rules.
• If Company B says, "I only talk to C," Mica connects the dots.
• Mica ensures that the data can flow from A → B → C, but cannot flow from A → B → The Internet.
• Even if Company B is a "bad actor" who wants to leak data, Mica's rules prevent B from opening a door to the outside world. The data is trapped in the pipeline.

3. The "Group Passport" (Attestation)

Usually, to prove a room is secure, you check the lock on that specific door. But with Mica, you get a Group Passport.

• Instead of checking 100 individual rooms, a remote verifier (like a bank or a government) can check one single document that proves: "Yes, these 100 rooms are connected exactly as we planned, and no secret data can escape this specific chain."
• This proves the entire workflow is secure, not just the individual parts.

How It Works (The Analogy of the "Secure Pipeline")

Think of Mica as a specialized water pipe system for your data.

• The Pipes (Memory): In the old days, pipes were open to the air. If a pipe leaked, the water (data) spilled out. Mica creates sealed, transparent pipes between the rooms. You can see the water flowing, but no one can touch it or steal it.
• The Valves (Policies): Mica installs smart valves.
  • If the pipe goes from the "Encoder" to the "Moderator," the valve only allows water to flow forward.
  • If the "Encoder" tries to open a valve to the "Internet," the valve is welded shut.
• The Inspector (Attestation): Before the water starts flowing, an inspector walks the whole line. They check every valve and every pipe connection. Once they sign off, you get a certificate saying, "This entire pipeline is leak-proof."

Why Is This a Big Deal?

1. No More "Trust Me": You don't need to trust the software companies. You just need to trust the Mica system (which is small and simple). Even if the companies are rivals or have buggy code, they physically cannot leak your data because the pipes are sealed by Mica.
2. Smaller "Trusted" List: In the old world, you had to trust every single company's entire software stack (their OS, their apps, etc.). With Mica, you only trust the Mica system itself. The companies can be messy; Mica keeps them in line.
3. Real-World Use: The paper shows this works for things like:
   • Video Moderation: A video goes from a user → an encoder → a nudity detector → storage. The encoder can't steal the video, and the detector can't leak it.
   • AI Chatbots: A user sends a prompt to a filter, then to an AI, then back to a filter. The AI can't talk to the internet to steal the user's prompt, and the filter ensures the AI doesn't say anything dangerous.

Summary

Mica is like building a secure train line between different cities (computing components).

• Before: You had to trust that every train station manager wouldn't let passengers jump off the train or steal the luggage.
• With Mica: The tracks are enclosed in a glass tunnel. The train can only stop at the stations on the schedule. If a station manager tries to open a door to the outside world, the tunnel seals itself. You get a ticket (attestation) that proves the train stayed on the tracks the whole time.

It allows us to build complex, secure systems out of parts that don't trust each other, simply by enforcing strict, verifiable rules on how they can share information.

Technical Summary

1. Problem Statement

Current Confidential Computing technologies, specifically Trusted Execution Environments (TEEs), protect data in use but suffer from a critical limitation: they assume that all components within a pipeline must be mutually trusted.

• The Trust Bottleneck: In modern cloud workloads, applications are often pipelines of independently developed components (e.g., different vendors' OS, libraries, or AI models). To ensure confidentiality, current TEEs require the tenant to trust the functional correctness of every component in the chain. If any component leaks data via shared memory or host interfaces, the entire pipeline is compromised.
• Implicit vs. Explicit: Existing TEEs rely on implicit trust in the software mediating communication (e.g., the OS or hypervisor). They protect exclusive resources but leave shared interfaces (shared memory, RPCs, host interactions) largely unmeasured.
• The Consequence: Tenants are forced to audit massive third-party stacks (including proprietary OSs) to guarantee mutual trust, which is unrealistic. Furthermore, existing solutions that try to solve this (like intra-TEE sandboxes) often require a common trusted software stack, limiting flexibility and increasing the Trusted Computing Base (TCB).

2. Methodology: The Mica Architecture

The authors propose Mica, a confidential computing architecture that decouples confidentiality from trust. Instead of relying on the correctness of the code inside a TEE, Mica enforces confidentiality through explicit, attestable, and restricted communication paths.

Core Design Principles

1. Explicit Sharing: Communication endpoints and paths are explicitly identified, measured, and attested, rather than inferred from software behavior.
2. Configurable Policies: Mica separates tenant-defined sharing policies from the trusted mechanisms that enforce them.
3. Structural Guarantees: Confidentiality is derived from the attestable structure of memory access and inter-component communication, not from trusted software mediating interactions.

Key Mechanisms

• Policy Language: Mica introduces a policy language that allows tenants to define:
  • Memory Channels: Explicitly mapping shared memory regions (protected or unprotected) between specific TEEs (Realms) and the host.
  • Control-Flow Channels: Restricting transitions to the untrusted host (e.g., exceptions, calls) to prevent covert channels (timing attacks, data exfiltration via interrupt frequency).
  • Transitive Constraints: A component's policy can constrain the behavior of its peers (e.g., "Peer A can only talk to Peer B, and Peer B cannot talk to the host").
• Group Attestation: Mica extends standard TEE attestation to cover an entire group of communicating TEEs. It generates a single report verifying that the entire pipeline adheres to the declared policies, allowing remote verifiers to trust the workflow without trusting individual components.
• Implementation on Arm CCA:
  • Mica is implemented on Arm Confidential Compute Architecture (CCA).
  • It extends the Realm Management Monitor (RMM) with a small policy language.
  • It utilizes existing primitives (Realm Management Interface - RMI, Realm Services Interface - RSI) without requiring hardware changes.
  • It introduces a Protected Granule Table (SGT) to manage confidential shared memory between Realms that is inaccessible to the host.

3. Key Contributions

1. Mica Architecture: A novel extension to confidential computing that enables building secure pipelines from mutually untrusted components.
2. Policy Language: A formal language allowing TEEs to explicitly define resource sharing policies, including memory mappings and control-flow restrictions, with transitive constraints.
3. Implementation & Prototype: A full implementation on Arm CCA (using QEMU emulation) involving:
   • Extensions to the TF-RMM (Realm Management Monitor).
   • Modifications to the QEMU VMM and KVM host kernel.
   • A guest kernel driver for policy upload and attestation.
4. Group Attestation: A mechanism to attest the collective state of a pipeline, verifying that communication paths match the declared policies.

4. Results and Evaluation

The authors evaluated Mica through three realistic cloud use cases:

1. Networking Service: A trusted gateway Realm mediating traffic for multiple untrusted client Realms.
2. Multi-Stage Video Moderation: A linear pipeline of proprietary components (Encoder $\to$ Nudity Detector) where data flows strictly forward.
3. Guard-Railed LLM Inference: A graph-based workflow where a filtering Realm mediates inputs/outputs for an LLM Realm.

Key Findings:

• TCB Reduction: Mica significantly reduces the Trusted Computing Base. In a vanilla CCA deployment, all communicating components must be trusted. In Mica, only the Gateways (components interacting with the host) need to be trusted; application logic components are untrusted but confined by policy. This reduces the TCB by roughly 2–3$\times$.
• Performance Overhead:
  • The overhead is localized to policy upload/validation (one-time) and control-flow checks in the RMM.
  • Mica enables unencrypted communication between TEEs over protected shared memory. In contrast, vanilla CCA requires encryption/decryption for cross-TEE communication, which prior work suggests can consume up to 50% of CPU cycles. Thus, Mica likely offers a net performance gain for secure pipelines.
• Attestation Size: The group attestation report size grows linearly with the number of Realms (approx. 450 bytes per policy blob), which is manageable compared to the complexity of attesting each component individually and verifying their interconnections manually.
• Security: Mica prevents data exfiltration even if a component is compromised, provided the component cannot bypass the policy-defined channels (e.g., an encoder cannot send data to the network if the policy only allows reading from the input channel).

5. Significance

• Paradigm Shift: Mica shifts the security model from "Trust the Code" to "Trust the Structure." It allows cloud tenants to compose complex, multi-vendor pipelines without needing to audit or trust the proprietary code of every vendor.
• Solving the "Distrustful Components" Problem: It directly addresses the reality of modern cloud computing where components are developed by different entities with no mutual trust.
• Hardware-Software Co-design: It demonstrates how extending the RMM (firmware) with policy enforcement can solve leakage problems that pure software solutions (like sandboxes) cannot, without requiring new hardware instructions.
• Practicality: The implementation requires only modest changes to the TCB (12% increase in RMM code) and integrates seamlessly with existing guest software stacks (Linux, QEMU), making it a viable path forward for confidential cloud computing.

In summary, Mica provides a robust framework for building attestable, end-to-end confidential workflows in environments where components are inherently untrusted, effectively solving the "confidentiality vs. trust" trade-off that has limited the adoption of confidential computing in complex, multi-tenant cloud scenarios.