untrust

A TEE deployment auditor for the trust boundaries that attestation forgets.

Cloud TEEs (AWS Nitro Enclaves, AMD SEV-SNP, Intel TDX) promise that a fully compromised host cannot reach into a hardware-isolated enclave. The cryptographic attestation story is sound. The deployment story is not.

Every TEE workload has to receive something from outside: bootstrap state from cloud object storage, environment variables from the host, KMS keys whose policies should but often don't enforce attestation. None of these inputs are protected by the attestation guarantee. All of them have been used in real exploitation.

untrust audits the trust boundaries TEE attestation does not cover, and produces a pass/fail report with concrete remediation guidance. It ships 62 checks for three platforms today — AWS Nitro Enclaves (33), AMD SEV-SNP on GCP Confidential Space (11), and NVIDIA GPU Confidential Computing (18) — behind a single --platform switch, and one pip install untrust includes all three.

Why this exists

untrust was built after a real adversarial simulation in which a single cloud storage write permission was sufficient for full Remote Code Execution as root inside a hardware-isolated enclave. The bug was a path traversal in the bootstrap state download — a class of vulnerability from 1998 that defeated a trillion-dollar trust boundary.

The talk presenting this research was delivered at DEF CON 34 (August 2026): "The Enclave Is Lying to You: Breaking TEE Trust Boundaries Through Boot-Time State."

Installation

pip install untrust

Requires Python 3.10+. A single install includes both the AWS and GCP scanners — no extras. Live scans use your existing AWS credentials (Nitro) or Google Application Default Credentials (Confidential Space); demo mode needs neither.

Quickstart

Live scan against a real deployment

untrust scan \
  --target-bucket my-enclave-state \
  --kms-key-id arn:aws:kms:us-west-2:111111111111:key/abc... \
  --instance-id i-0abc123 \
  --region us-west-2 \
  --output report.json

Demo mode (no AWS credentials needed)

untrust scan --demo

GCP Confidential Space (SEV-SNP)

# Demo — no GCP credentials needed
untrust scan --platform sev-snp --demo

# List the SEV-SNP / Confidential Space checks
untrust list-checks --platform sev-snp

# Live scan against a Confidential Space deployment (uses Application Default Credentials)
untrust scan --platform sev-snp \
  --wip-provider projects/PROJECT/locations/global/workloadIdentityPools/POOL/providers/PROVIDER \
  --gcp-kms-key projects/PROJECT/locations/global/keyRings/RING/cryptoKeys/KEY \
  --gcs-bucket my-bootstrap-state \
  --gcp-instance my-cs-vm --gcp-zone us-central1-a \
  --output report.json

Any single target flag is enough; checks whose inputs are absent report SKIP.

NVIDIA GPU Confidential Computing (gpu-cc)

# Demo — no GPU, driver, or attestation evidence needed
untrust scan --platform gpu-cc --demo

# List the GPU CC checks with their trust boundary and assurance tier
untrust list-checks --platform gpu-cc

# Analyze captured evidence and policy files
untrust scan --platform gpu-cc \
  --gpu-attestation-report evidence/report.json \
  --gpu-verifier-policy policy.json \
  --gpu-kbs-policy kbs.json \
  --gpu-launch-config launch.json \
  --gpu-model-bucket my-model-weights \
  --output report-out.json

GPU CC is file-based: it reads a captured attestation report plus the verifier, key-release, and launch policies you supply. The retained nvattest outputs sit beside the report (see the platform README). Any single target flag is enough; checks whose inputs are absent report SKIP.

Sample output

Running untrust scan --demo against the built-in simulated deployment:

List every check and its severity with untrust list-checks:

What it audits

AWS Nitro Enclaves — 33 checks

33 checks across eight categories, each mapped to a real-world exploitation path.

Bootstrap & Supply Chain

Object Storage (state bucket)

Alternative state backends

The bootstrap-state trust boundary is backend-agnostic — attestation covers none of these. If the enclave loads state from something other than S3, target it with the matching flag (--dynamodb-table, --secret-arn, --parameter-path, --efs-id, --db-instance). Each check skips unless its backend is named.

KMS & Attestation

IAM & Access Control

Network & Host

Host Memory & Persistence Hygiene

Enclave Runtime

Configuration

Detection & Forensics

GCP Confidential Space (SEV-SNP) — 11 checks

The same thesis on GCP: attestation proves the code, not what you hand it at boot, nor who you let ask for the keys. On Confidential Space a workload proves itself with an attestation token and exchanges it — through Workload Identity Federation (WIF) — for Cloud KMS access. Run untrust list-checks --platform sev-snp; full detail lives in untrust/platforms/sevsnp/README.md.

NVIDIA GPU Confidential Computing — 18 checks

Confidential AI on H100/H200 and Blackwell: the GPU's signed attestation is sound, but the deployment around it decides whether anyone actually verifies it, and whether model weights, keys, and the launch config stay inside the boundary. A confidential-GPU deployment is two TEEs (the GPU and the CPU-side TDX/SEV-SNP/CCA VM), so untrust checks both and their binding. Run untrust list-checks --platform gpu-cc; full detail lives in untrust/platforms/gpucc/README.md.

Each check carries an assurance tier: report-derived (trusted only once GPUCC-SIGVERIFY-01 passes, otherwise flagged), probed (actively tested), or operator-declared (a policy says so). The console summary counts passes by tier so a green report is not read as stronger than its evidence.

What untrust deliberately does not check (and why)

An honest scanner names its own blind spots. These threats are real, but a deployment-config scanner cannot meaningfully test them — they require code review, runtime introspection inside the enclave, or are the hardware vendor's responsibility. Cross-referenced against the Confidential Computing Consortium threat model, MITRE/COIN enclave-interface research, Trail of Bits' Nitro attack-surface notes, and recent academic work (SGX.Fail, TEE.Fail).

CLI Reference

# Run all checks
untrust scan --target-bucket BUCKET --kms-key-id KEY --instance-id INSTANCE

# Audit a non-S3 state backend (any combination)
untrust scan --dynamodb-table TABLE --kms-key-id KEY
untrust scan --secret-arn ARN
untrust scan --parameter-path /enclave/
untrust scan --efs-id fs-0123 --db-instance prod-db

# Passive scan only — skip intrusive checks (the bucket canary-write probes on
# every platform and the Nitro host/nitro-cli SSM commands) to avoid tripping
# SOC/EDR detections
untrust scan --target-bucket BUCKET --kms-key-id KEY --instance-id INSTANCE --read-only

# Run in demo mode (simulated vulnerable deployment)
untrust scan --demo

# Output JSON report
untrust scan --demo --output report.json
untrust scan --demo --json

# List available checks
untrust list-checks

# --- GCP Confidential Space (SEV-SNP) ---
untrust scan --platform sev-snp --demo
untrust scan --platform sev-snp --wip-provider PROVIDER --gcs-bucket BUCKET \
  --gcp-instance VM --gcp-zone ZONE --gcp-kms-key KEY
untrust list-checks --platform sev-snp

# --- NVIDIA GPU Confidential Computing ---
untrust scan --platform gpu-cc --demo
untrust scan --platform gpu-cc --gpu-attestation-report report.json \
  --gpu-verifier-policy policy.json --gpu-kbs-policy kbs.json --gpu-launch-config launch.json
untrust list-checks --platform gpu-cc

# Version
untrust --version

JSON Output

The --output and --json flags produce structured output suitable for integration with CI/CD pipelines, SIEM systems, or security dashboards:

{
  "version": "1.2.0",
  "timestamp": "2026-08-24T14:30:22.000000+00:00",
  "target": {
    "bucket": "enclave-state-XXXXXXXXXXXX",
    "kms_key_id": "arn:aws:kms:us-west-2:XXXXXXXXXXXX:key/demo-key-id",
    "instance_id": "i-0abc123def456789a",
    "region": "us-west-2"
  },
  "summary": {
    "total": 28,
    "pass": 0,
    "fail": 28,
    "skip": 0,
    "error": 0
  },
  "findings": [...]
}

Roadmap

• v1.0 (DEF CON 34, August 2026): AWS Nitro Enclaves, 33 checks (S3 + DynamoDB/Secrets Manager/SSM/EFS/RDS state backends), JSON output
• v1.1 — shipped: AMD SEV-SNP on GCP Confidential Space, 11 checks including five Tier-1 attestation-bypass paths, behind a --platform switch
• v1.2 — shipped: NVIDIA GPU Confidential Computing, 18 checks across both TEEs of a confidential-GPU deployment, with per-check assurance tiers
• Next: SARIF output for GitHub code scanning; Intel TDX bootstrap integrity; Azure Confidential Containers
• Future: Plugin API for vendor-specific TEE platforms

Contributions welcome. See CONTRIBUTING.md.

How it works

For AWS Nitro, untrust uses the AWS SDK (boto3) and SSM to inspect the target deployment; for GCP Confidential Space (--platform sev-snp) it uses the Google API client libraries (Compute, IAM, Cloud KMS, Storage) with your Application Default Credentials; for NVIDIA GPU CC (--platform gpu-cc) it reads captured attestation evidence and policy files, plus the model-weights bucket on Cloud Storage. Each check separates a pure analyze_*() function from a thin live-fetch wrapper. The AWS Nitro platform combines several families of checks (run untrust list-checks for the full set of 33):

• Cloud-API checks read S3, KMS, EC2, IAM, and CloudTrail configuration directly — e.g. KMS-01 performs semantic key-policy evaluation (rejecting all-zeros and identity-only PCR conditions), ROLLBACK-01 reads S3 Object Lock, S3-02 reads bucket encryption and the TLS-only policy, and CLOUDTRAIL-01 confirms KMS/S3 activity is actually logged.
• Alternative-backend checks apply the same storage-plane controls to non-S3 state stores when targeted: DynamoDB (DDB-01), Secrets Manager (SECRETS-01), SSM Parameter Store (SSM-01), EFS/EBS (EFS-01), and RDS/Aurora (RDS-01). Each checks for a customer-managed CMK (so KMS-01 attestation can gate it), least-privilege/non-public access, anti-rollback, and audit coverage. CMK status is resolved authoritatively via kms:DescribeKey (KeyMetadata.KeyManager) — a string check cannot distinguish an AWS-managed service key from a customer CMK, since both surface as a resolved key ARN.
• Host checks (via SSM AWS-RunShellScript) run read-only commands on the parent instance — SSH/port/service posture, file and exec permissions, IMDS filtering, DNS DNAT, core-dump/swap/journal hygiene, and restart persistence.
• Enclave-runtime checks (via SSM + nitro-cli) confirm the enclave is out of debug mode, has non-zero PCRs, is not co-tenant, and was booted from a signed EIF (describe-eif → PCR8 + signature check).
• BOOTSTRAP-01 additionally uploads canary objects with path-traversal key names and deletes any that succeed. A write that is rejected — with a 403 AccessDenied or any other client-side (4xx) response such as a 400 from a bucket policy/encryption condition — is treated as blocked (PASS), since the object never lands. Only transient/server-side failures (throttling, 5xx) are reported as ERROR.

Read-only mode

untrust scan --read-only runs the passive checks only and skips the intrusive ones — the canary-write bucket probes (BOOTSTRAP-01 on Nitro, GCS-BOOT-02 on Confidential Space, GPUCC-MODEL-01 on GPU CC) and every Nitro host/enclave check that shells into the instance via SSM AWS-RunShellScript. Use it when you need a posture snapshot without generating write events or on-host command execution that a SOC/EDR pipeline might flag.

Required IAM permissions

The scanning identity needs the following permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UntrustS3Checks",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:GetBucketVersioning",
        "s3:GetBucketLogging",
        "s3:GetBucketPolicy",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetEncryptionConfiguration",
        "s3:GetBucketObjectLockConfiguration"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR-STATE-BUCKET",
        "arn:aws:s3:::YOUR-STATE-BUCKET/*"
      ]
    },
    {
      "Sid": "UntrustKms",
      "Effect": "Allow",
      "Action": "kms:GetKeyPolicy",
      "Resource": "arn:aws:kms:REGION:ACCOUNT:key/KEY-ID"
    },
    {
      "Sid": "UntrustEc2",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeVpcPeeringConnections",
        "ec2:DescribeTransitGatewayVpcAttachments"
      ],
      "Resource": "*"
    },
    {
      "Sid": "UntrustCloudTrail",
      "Effect": "Allow",
      "Action": [
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "cloudtrail:GetEventSelectors"
      ],
      "Resource": "*"
    },
    {
      "Sid": "UntrustIam",
      "Effect": "Allow",
      "Action": [
        "iam:GetInstanceProfile",
        "iam:ListRolePolicies",
        "iam:GetRolePolicy",
        "iam:ListAttachedRolePolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "UntrustStateBackends",
      "Effect": "Allow",
      "Action": [
        "kms:DescribeKey",
        "dynamodb:DescribeTable",
        "dynamodb:DescribeContinuousBackups",
        "dynamodb:GetResourcePolicy",
        "secretsmanager:DescribeSecret",
        "secretsmanager:GetResourcePolicy",
        "ssm:DescribeParameters",
        "elasticfilesystem:DescribeFileSystems",
        "elasticfilesystem:DescribeFileSystemPolicy",
        "elasticfilesystem:DescribeBackupPolicy",
        "rds:DescribeDBInstances",
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBSnapshotAttributes",
        "ec2:DescribeSecurityGroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "UntrustSsm",
      "Effect": "Allow",
      "Action": [
        "ssm:SendCommand",
        "ssm:GetCommandInvocation"
      ],
      "Resource": [
        "arn:aws:ssm:REGION:ACCOUNT:document/AWS-RunShellScript",
        "arn:aws:ec2:REGION:ACCOUNT:instance/INSTANCE-ID"
      ]
    }
  ]
}

BOOTSTRAP-01 writes canary objects to the target bucket and deletes them after — scope the s3:PutObject/s3:DeleteObject actions to a dedicated audit role. The host and enclave-runtime checks (SSH-01, PORT-01, NAT-01, HOST-01, HOST-02, EXEC-01, ENV-01, VSOCK-01, DNS-01, CORE-01, SWAP-01, LOG-01, RESTART-01, ENCLAVE-01/02/03/04) execute read-only shell/nitro-cli commands on the host via SSM — ensure the SSM agent is running and the instance profile allows SSM sessions. The remaining checks use S3, KMS, EC2, IAM, and CloudTrail read APIs.

On GCP, GCS-BOOT-02 (Confidential Space) and GPUCC-MODEL-01 (GPU CC) write and then delete canary objects in the target bucket the same way, so the identity needs storage.objects.create and storage.objects.delete there; use --read-only to skip them.

Background reading

• AWS Nitro Enclaves User Guide
• Cryptographic Attestation with AWS KMS for Nitro Enclaves
• NCC Group, "Public Report — AWS Nitro System Security Review" (2023)
• Trail of Bits, "Security Assessment of AWS Nitro Enclaves" (2022)
• OWASP, "Path Traversal"

Disclosure

The vulnerabilities that motivated this tool were discovered during an authorized adversarial simulation against a production TEE deployment. They were reported to the affected vendor, and fixes shipped in a subsequent build. Coordinated disclosure is complete. untrust does not include any vendor-specific exploit code or proprietary information — it implements the audit checks generically against published cloud APIs.

License

MIT. See LICENSE.

Author

Sandeep Jayashankar (pyro) — offensive cloud security researcher.

DEF CON 34 speaker. Focus: adversarial simulation against confidential computing deployments.