Confidential Computing Use Cases

Federated Learning, Multi-party Computing and Trusted Pipelines with CoCo

CoCo Use Cases Work Group

Working document - https://docs.google.com/document/d/1LnGNeyUyPM61Iv4kBKFbfgmBr3RmxHYZ7Ev88obN0_E/edit?usp=sharing

Confidential Computing Use Cases:

CC use cases across industries

Federated Learning Use Cases

Concerns when using federated learning

• Trustworthy of the participants
• execution code tempering
• Model tampering
• model inversion attack
• Model theft during training
• Private data leak

​

​

FL Use Cases that requires CC

​

• Build Explicit Trust
• Prevent code, model, data tampering
• Secure aggregation node
• Aggregation code protection
• Training node protection with TEE
• Secure Training at client node
• Model IP protection with TEE
• Prevent data leak
• Federated Inference Protection
• Input data protection
• Model protection

CC will not protect

• code is already flawed at rest
• data is already poisoned at rest
• model is already poisoned at rest

​

Confidential Federated Learning: Process

Attestations

• Federated Learning requests multi-SDK attestation
• FL Servers needs to verify all client’s trustworthiness
• Attestation at different points, self and cross verifications via attestation service

CC Policies:

• Bootup policy – provided by hardware vendor
• Self-verification CC policy – user defined
• Cross-verification CC policy -- user defined

Protected Assets

• Code: Training code (client), aggregation code (server)
• Data: input data
• Model: initial model, intermediate model, output model
• Workspace: check points, logs, temp data, output directory

Key Broker Service

• Key management depends on user case, global model ownership, key release management process

Bootstrap:

• Need a process to generate the keys, policies and input them into key-vault to avoid tempering

​

Multi-party Computing (data clean room, confidential spaces etc)

Source: https://uploads-ssl.webflow.com/63c54a346e01f30e726f97cf/6418fb932b58e284018fdac0_OC3%20-%20Keith%20Moyer%20-%20MPC%20with%20CC.pdf

Multi-Party Computing Requirements for CoCo

Requirements

• Attestation-cross-verification
• In MPC or FL cases, we need to explicitly verify all participants to be trustworthy according to the cross verification CC policy.
• Periodic self-check test and cross-verification
• a long running workload can ensure that the TEE is still valid
• Ad hoc attestation verification for given participation node
• From CLI or API, application wants to know what’s the current status (trustworthiness) of the specified node
• Attestation audit report
• each party would like to get details on when attestation was performed by the TEE and relevant details
• Connecting to multiple KBSes
• the workload needs to connect to different KBS each belonging to a specific party for getting access to the keys
• Support multiple devices
• One participant may has only one type of device (CPU), but need to verify other participant’s devices including different CPU and GPU

CI/CD Pipeline (Supply Chain)

• Compliance Frameworks require Software Bill Of Materials (SBOM)
• What was the OCI Image was built from?
• Confidential Computing requires a way to verify the OCI Images being used.
• Signatures, Encrypted Layers etc.
• Is this the OCI Image I am looking for?

​

• Do signatures or encrypted layers with TEE and CoCo provide Confidential Computing?

What environment did we use to :

• Build the OCI Images?
• Define/Generate the SBOM we later use to inform our choice of Image?
• Sign or encrypt the Image?
• If the pipeline/build environment is not secure, what value does running the OCI Images in CoCo give?

Trusted Pipeline (Supply Chain)

A trusted CI/CD pipeline prevents malicious code from infiltrating the software and ensures that the software can be traced and verified.

​

We need to use CoCo as part of our CI/CD to establish a trusted pipeline

• To ensure the SBOM accurately reflects how the OCI Image was built
• No ability to tamper with the build
• To protect the keys used to establish signatures or encrypt the Images.
• To make the signatures, keys, SBOMs available for use/audit purposes later.

But considering OCI Images is not enough

Our Supply chain also includes:

• CoCo VM (with SBOM)
• Attestation Measurements to verify the CoCo VM
• Generation and protection of Keys/Secrets/Policies/Configuration
• Trustee (KBS/Attestation) and Remote Verification Services
• Potentially updates to Firmware for the TEE in use.

Bootstrap Problem?

• How can we use a CoCo VM to securely build a CoCo VM?

Confidential RAG LLMs – Threat Model

LLM01 - Prompt Injection

LLM02 - Insecure Output Handling

LLM03 - Training Data Poisoning

LLM05 - Supply Chain Vulnerabilities

LLM07 - Insecure Plugin Design

LLM08 - Excessive Agency

LLM06 - Sensitive Info. Disclosure

LLM04 - Model Denial of Service

LLM09 - Overreliance

LLM10 - Model Theft

Potential Threats: OWASP Top 10 for LLMs

Potential Mitigations Strategies with CC

Limit Attack Surface, Secure Execution of Plugins, Traceability

Limit Attack Surface, Secure Execution of Plugins, Traceability

Secure Data in Use (Model, Data) , Prevent Data Injection, Supply Chain Verification (Attestation)

Virtualization, 2nd Line of Defense, Resource Overuse, Input Flood

Supply Chain Verification, Attestation, Signing and Encryption

Encrypted Data Processing, Data Integrity and Confidentiality

Untrusted Code Execution in Enclave, Privilege Escalation limited

Excessive Functionality/Permissions/Autonomy limited to the Enclave

Confidential Computing (CC) doesn't directly address the issue of overreliance

Securing Execution Patterns, Encrypted Data Processing, Secure Execution Environments

Confidential RAG LLMs – Confidential Containers

Virtualization as 2nd line of defense, resource misuse, misconfiguration, see previous slide for more points 

In a confidential environment confidential models should only be released upon positive attestation of the platform,  signed and encrypted for supply chain verification.

Web Frontend

API Server

Model Server

Vector DB

Data Sources

LLMs trained on confidential data, would mean that the vectors represent this sensitive information. Vectors are a abstract representation, there’s still a risk to deduce confidential information

In a confidential environment confidential data sources should only be released upon positive attestation of the platform,  signed and encrypted for supply chain verification.

Secure Key Release, decrypt confidential data only in a Trusted Execution Environment (TEE)

Models trained on confidential data needs protection when in use. Protection against model theft, API misuse, … Attestation can confirm a valid and genuine configuration. (Model watermarking, … ) 

General considerations for CC are compliance and regulations like GDPR, HiPAA, secure multi-party computation, protection against insider threats, … - Zero Trust 

Model 

Store

Secure Key Release, decrypt confidential model only in a TEE

CC

CC

Confidential Container, complete pipeline protection, theft, misuse, resource exploitation: Zero Trust

https://github.com/NVIDIA/GenerativeAIExamples