Skip to content

ex3ndr-bot/secure-perimeter

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

24 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Secure Perimeter

Minimal infrastructure for running attested workloads with verifiable supply chain, designed for web and mobile clients that need to verify they're talking to genuine, unmodified code.

Design Goals

  1. Minimal β€” fewest possible moving parts, all off-the-shelf
  2. Verifiable β€” every build is signed, logged, and reproducible
  3. Attested β€” clients verify they're talking to real TEE hardware running expected code
  4. Stateful β€” encrypted persistent storage, keys released only after attestation
  5. Updatable β€” ship new code without exposing or losing data

Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                        BUILD (CI)                            β”‚
β”‚                                                              β”‚
β”‚  Source β†’ Nix Build β†’ Container Image β†’ Cosign Sign          β”‚
β”‚                            β”‚                                 β”‚
β”‚                            β–Ό                                 β”‚
β”‚                   Rekor Transparency Log                     β”‚
β”‚                   (digest + signature + measurements)        β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                            β”‚
                            β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                      DEPLOY (k3s)                            β”‚
β”‚                                                              β”‚
β”‚  Kyverno admission β†’ verify Cosign signature against Rekor   β”‚
β”‚         β”‚                                                    β”‚
β”‚         β–Ό                                                    β”‚
β”‚  Kata Containers β†’ Confidential VM (AMD SEV-SNP)            β”‚
β”‚         β”‚                                                    β”‚
β”‚         β–Ό                                                    β”‚
β”‚  dm-verity root FS β†’ hardware attestation quote generated    β”‚
β”‚         β”‚                                                    β”‚
β”‚         β–Ό                                                    β”‚
β”‚  KBS releases LUKS key β†’ encrypted volume mounted            β”‚
β”‚         β”‚                                                    β”‚
β”‚         β–Ό                                                    β”‚
β”‚  Workload running with attested identity                     β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                            β”‚
                            β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    VERIFY (Client)                            β”‚
β”‚                                                              β”‚
β”‚  Client β†’ Noise handshake β†’ server embeds attestation quote  β”‚
β”‚         β†’ verify quote signature (AMD/Intel root CA)         β”‚
β”‚         β†’ compare measurements to transparency log           β”‚
β”‚         β†’ encrypted session with forward secrecy             β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Components

Component Tool Purpose
Build system Nix Reproducible, deterministic builds
Container signing Cosign (keyless via Fulcio) Sign container images with OIDC identity
Transparency log Rekor Append-only log of signatures + measurements
Orchestrator k3s Lightweight Kubernetes
Admission Kyverno Enforce signature policy before pod admission
Runtime isolation Kata Containers VM-per-pod with TEE support
TEE AMD SEV-SNP Hardware-level memory encryption + attestation
Filesystem integrity dm-verity Immutable root filesystem with hash tree
Key management KBS (Trustee) Release secrets only to attested workloads
Storage encryption LUKS CSI Encrypted persistent volumes
Client protocol Noise Protocol (Pipes) Encrypted channels with embedded attestation

Project Structure

secure-perimeter/
β”œβ”€β”€ README.md                      # This file
β”œβ”€β”€ ARCHITECTURE.md                # Detailed architecture doc
β”œβ”€β”€ nix/                           # Nix build system
β”‚   β”œβ”€β”€ flake.nix                  # Nix flake for reproducible builds
β”‚   β”œβ”€β”€ flake.lock
β”‚   └── default.nix
β”œβ”€β”€ images/                        # Container image definitions
β”‚   └── workload/
β”‚       β”œβ”€β”€ Dockerfile
β”‚       └── dm-verity.conf
β”œβ”€β”€ deploy/                        # k3s deployment manifests
β”‚   β”œβ”€β”€ kustomization.yaml
β”‚   β”œβ”€β”€ namespace.yaml
β”‚   β”œβ”€β”€ kyverno-policy.yaml        # Signature verification policy
β”‚   β”œβ”€β”€ kata-runtime-class.yaml    # RuntimeClass for confidential VMs
β”‚   β”œβ”€β”€ workload.yaml              # Pod/Deployment spec
β”‚   └── pvc-encrypted.yaml         # LUKS-encrypted PVC
β”œβ”€β”€ attestation/                   # Attestation infrastructure
β”‚   β”œβ”€β”€ kbs/                       # Key Broker Service config
β”‚   β”‚   β”œβ”€β”€ kbs-config.yaml
β”‚   β”‚   └── reference-values.yaml  # Expected measurements
β”‚   └── transparency/
β”‚       └── publish.sh             # Script to publish measurements to Rekor
β”œβ”€β”€ server/                        # Server-side workload code
β”‚   β”œβ”€β”€ src/
β”‚   β”‚   β”œβ”€β”€ main.ts                # Entry point
β”‚   β”‚   β”œβ”€β”€ noise.ts               # Noise Protocol server with attestation
β”‚   β”‚   β”œβ”€β”€ attestation.ts         # Read TEE quote, embed in handshake
β”‚   β”‚   └── storage.ts             # Encrypted state management
β”‚   β”œβ”€β”€ package.json
β”‚   └── tsconfig.json
β”œβ”€β”€ client/                        # Client verification libraries
β”‚   β”œβ”€β”€ web/
β”‚   β”‚   β”œβ”€β”€ src/
β”‚   β”‚   β”‚   β”œβ”€β”€ index.ts           # Web client entry
β”‚   β”‚   β”‚   β”œβ”€β”€ noise-client.ts    # Noise Protocol client
β”‚   β”‚   β”‚   β”œβ”€β”€ verify.ts          # Attestation quote verification
β”‚   β”‚   β”‚   └── transparency.ts    # Query Rekor for measurements
β”‚   β”‚   β”œβ”€β”€ package.json
β”‚   β”‚   └── tsconfig.json
β”‚   └── mobile/
β”‚       β”œβ”€β”€ ios/
β”‚       β”‚   └── SecurePerimeter/
β”‚       β”‚       β”œβ”€β”€ NoiseClient.swift
β”‚       β”‚       └── AttestationVerifier.swift
β”‚       └── android/
β”‚           └── src/
β”‚               └── SecurePerimeter.kt
β”œβ”€β”€ ci/                            # CI/CD pipelines
β”‚   └── .github/
β”‚       └── workflows/
β”‚           β”œβ”€β”€ build-sign.yml     # Build + Cosign + Rekor
β”‚           └── deploy.yml         # Deploy to k3s
└── scripts/                       # Helper scripts
    β”œβ”€β”€ setup-k3s.sh               # k3s + kata + kyverno setup
    β”œβ”€β”€ setup-kbs.sh               # KBS deployment
    └── verify-local.sh            # Local attestation verification test

Attestation Flow

Build Time

  1. Nix builds container image (deterministic hash)
  2. GitHub Actions signs with Cosign (keyless via Fulcio OIDC)
  3. Signature + image digest + expected measurements published to Rekor
  4. SLSA provenance attached to the build

Deploy Time

  1. Image pushed to registry with Cosign signature
  2. k3s admission (Kyverno) verifies signature against Rekor before allowing pod
  3. Kata creates confidential VM (AMD SEV-SNP)
  4. dm-verity locks root filesystem
  5. Hardware generates attestation quote (CPU-signed)
  6. Workload sends quote to KBS β†’ KBS validates β†’ releases LUKS key
  7. Encrypted volume mounted, workload starts

Runtime (Client Connection)

  1. Client initiates Noise Pipes handshake
  2. Server embeds attestation quote in handshake response
  3. Client verifies:
    • Quote signature against AMD/Intel root certificate
    • Measurements match known-good values from Rekor
    • Public key is bound to the quote
  4. Forward-secret encrypted session established

Update Flow

  1. New code merged β†’ CI builds new image
  2. Cosign signs β†’ Rekor logs new measurements
  3. Deploy new version to k3s
  4. KBS reference values updated for new measurements
  5. New pods attest with new measurements β†’ get LUKS keys
  6. Old pods drain β†’ encrypted state accessible to new code (same LUKS key)
  7. Clients verify new measurements from transparency log

Stateful Storage

Encrypted persistent volumes using LUKS:

  • Keys managed by KBS (Trustee)
  • Keys released ONLY after TEE attestation succeeds
  • Key rotation supported (re-encrypt with new key)
  • Data survives code updates (KBS releases key to new valid measurements)
  • Host/orchestrator never sees plaintext keys

Client Libraries

Web (TypeScript)

  • @stablelib/noise or noise-protocol for Noise handshake
  • Custom attestation quote parser (AMD SEV-SNP report format)
  • Rekor client for fetching expected measurements
  • AMD/Intel root CA certificates bundled in app

iOS (Swift)

  • NoiseSockets for Noise Protocol
  • Custom AttestationVerifier for TEE quote validation
  • Keychain for storing verified session keys

Android (Kotlin)

  • noise-java for Noise Protocol
  • Custom attestation verification
  • Android Keystore for session keys

Per-Pod Encryption (Key Isolation)

Critical invariant: no shared encryption keys between users.

Each pod gets its own encryption key hierarchy. Users' data is cryptographically isolated even if pods share the same physical volume or the same TEE.

Key Derivation Hierarchy

KBS Master Secret (released after attestation)
    |
    +-> HKDF(master, "pod:" + pod_id) -> Pod Root Key
    |       |
    |       +-> HKDF(pod_root, "user:" + user_id) -> User Data Key
    |       |       +-> Encrypts user's state (AES-256-GCM)
    |       |
    |       +-> HKDF(pod_root, "session:" + session_id) -> Session Key
    |               +-> Ephemeral, forward-secret per-connection
    |
    +-> Each pod attestation gets a UNIQUE master secret from KBS
        (KBS tracks which pod_id received which key)

How It Works

  1. Pod boots -> TEE generates attestation quote with unique pod identity
  2. Pod attests to KBS -> KBS validates, generates unique master secret for this pod
  3. User connects -> after Noise handshake, user provides user_id
  4. Key derivation -> HKDF derives user-specific data key from pod master + user_id
  5. Storage -> each user's data encrypted with their own derived key
  6. Key never shared -> different pods get different masters; different users get different derived keys

Implementation

// Key derivation (HKDF-SHA256)
const podRootKey = hkdf(masterSecret, "pod:" + podId);
const userDataKey = hkdf(podRootKey, "user:" + userId);
const encrypted = aes256gcm.encrypt(userDataKey, plaintext);

Properties

  • Pod isolation: Each pod gets a unique master from KBS
  • User isolation: HKDF ensures user keys are cryptographically independent
  • Forward secrecy: Session keys are ephemeral
  • Key rotation: KBS can issue new masters; pods re-derive user keys
  • No shared state: Even if two pods serve the same user, they derive independently

Quick Start

# 1. Setup k3s with Kata + Kyverno
./scripts/setup-k3s.sh

# 2. Setup KBS
./scripts/setup-kbs.sh

# 3. Build and sign
nix build .#workload
cosign sign --yes ghcr.io/yourorg/workload@sha256:...

# 4. Deploy
kubectl apply -k deploy/

# 5. Verify from client
cd client/web && npm run verify

About

Minimal attested workloads on k3s with sigstore transparency and client verification

Resources

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors