BLA
BLA는 오픈소스 Blue Defense MCP와 CLI로, 소프트웨어 자산을 자동 AI 리버스 엔지니어링으로부터 보호합니다
enclavia Enclavia 엔클레이브 런타임용 오픈소스 크레이트
Open-source crates for the Enclavia enclave runtime: in-enclave services, shared protocol types, client SDK, CLI. Dual-licensed Apache-2.0/MIT.
보안Rust · DartGitHub @EnclaviaIO직접 설치운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
설치형 프로젝트는 배포 도메인 없이도 확인할 수 있습니다. 개인 저장소는 GitHub 로그인으로, 조직 저장소는 위의 저장소 확인 파일로 직접 확인해 주세요.
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Open-source crates that make up the Enclavia enclave runtime: the in-enclave services that run inside the EIF (Enclave Image File), the shared protocol types that describe the wire format between client and enclave, the client SDK (native and wasm), and the CLI.README 전문 보기 ↗Open-source crates that make up the Enclavia enclave runtime: the in-enclave services that run inside the EIF (Enclave Image File), the shared protocol types that describe the wire format between client and enclave, the client SDK (native and wasm), and the CLI.
Enclavia lets you run arbitrary Docker images inside an AWS Nitro Enclave (or a local QEMU debug enclave) and reach them through an end-to-end-encrypted channel that is anchored to a Nitro attestation. The hosted control plane (website, builder, router) lives in a separate, closed-source repository. The code that runs inside the enclave (which is PCR-measured and therefore part of the attestation contract) and the code that talks to it must be auditable, so it lives here.
See https://beta.enclavia.io for the hosted service.
Agents:
skills/enclavia/SKILL.mdis a machine-oriented guide to driving theenclaviaCLI with--json. If you are an AI agent operating enclaves, start there.
The client-facing pieces are published to the public registries:
cargo install enclavia-cli installs the enclavia binary (enclavia-cli on crates.io), or nix run github:EnclaviaIO/enclavia#enclavia.enclavia on crates.io (cargo add enclavia).@enclavia/client-wasm on npm (Node 22+, Deno, bundlers).enclavia-protocol on crates.io, pulled in transitively by the SDK and CLI.Everything else in this workspace (the in-enclave binaries, dev tools) is consumed from git/Nix and is not on crates.io.
In-enclave binaries (run inside the EIF, reach the host over tokio-vsock):
enclavia-server: Noise responder that terminates the encrypted channel from the router, forwards plaintext bytes to the inner container over loopback TCP, and dispatches signed control commands (upgrades).enclavia-egress: Outbound TCP daemon. Owns tun0, runs a smoltcp userspace TCP/IP stack, and dials egress-host over vsock for every accepted outbound flow. Enforces a deny-by-default allowlist of IP literals, CIDRs, and hostnames (resolved through an in-enclave unbound).enclavia-crypto: Key management. Talks to KMS over vsock and unseals the LUKS volume that backs persistent storage.nbd-client: NBD client that backs the encrypted filesystem on top of storage-host, and the anti-rollback enforcement point (pins volume freshness against the synchronizer).synchronizer: The storage anti-rollback oracle. A mutually-attested, Raft-replicated cluster of identical enclaves that tracks each volume's latest transaction id, so a malicious host cannot serve a stale (rolled-back) copy of the encrypted volume unnoticed.enclavia-chain-init: Boot-time hook that submits each boot/upgrade link of the enclave's attested history chain.enclavia-secrets-init: Boot-time hook that pulls the per-enclave secrets payload from the host and injects it into the workload's environment.synchronizer-names-init: Boot-time identity side-channel for synchronizer nodes (routing labels only; identity comes from attestation).Shared / client-side crates (build for any target):
enclavia-protocol: Wire types and Noise+CBOR responder helpers. Shared between the in-enclave server, the host-side router, and the SDK. Includes attestation verification, the upgrade-chain and custody helpers, and the mesh/egress hand-off frames.enclavia: Client SDK. Opens a Noise tunnel through the router's WebSocket, verifies the enclave's attestation against your pinned PCRs, and exposes the channel as an http-compatible client. Compiles for native targets and wasm32-unknown-unknown.enclavia-wasm: wasm-bindgen bindings over the SDK for browsers and JS runtimes (Node >= 22, Deno): connect(url, pcrs, opts), fetch(...), and raw openStream(...) byte pipes. Same attestation verification as native.enclavia-cli: The enclavia binary: auth, enclave lifecycle, image push, secrets, signed upgrades (managed or self-hosted YubiKey custody), reproduce, and a global --json mode. Also exposes a library face (enclavia_cli::{api, commands, config}); see enclavia-cli/README.md.enclavia-vsock: Small shared vsock plumbing used by the in-enclave crates.Dev tools:
mock-kms: A KMS Trent endpoint for QEMU dev wrappers and the local dev stack.The host-side relays (egress-host, storage-host, mesh-host, ...), the WebSocket-to-vsock router, the control-plane API, the frontend, and the EIF builder live in separate repositories.
This workspace is driven by Nix flakes and Cargo.
# One-shot Cargo build:
cargo build --workspace
# Or via the Nix dev shell (pins the Rust toolchain):
nix develop
cargo build --workspace
Individual flake packages:
nix build .#enclavia-server
nix build .#enclavia-egress
nix build .#enclavia-crypto
nix build .#nbd-client
nix build .#synchronizer
nix build .#enclavia-secrets-init
nix build .#enclavia-chain-init
nix build .#mock-kms
nix build .#enclavia # the CLI binary
nix build .#enclavia-wasm
The in-enclave binaries only really run inside an enclave or QEMU. To exercise them end-to-end you also need the builder (which constructs the EIF). See https://github.com/EnclaviaIO/builder.
The synchronizer is the one enclave whose image is built in this repo. There are two images. They are separate builds with separate PCRs:
| Output | Architecture | Runs on | Synchronizer build |
|---|---|---|---|
synchronizer-eif-nitro | aarch64 | Graviton Nitro Enclaves (production) | enclave: full AWS Nitro CA chain checks |
synchronizer-eif | x86_64 | the local QEMU cluster (dev and CI only) | qemu: skips the CA chain; never for production |
Both are defined only for x86_64-linux. The production image is cross-built on x86_64, kernel and init included, so anyone can reproduce its PCRs on an ordinary x86_64 machine:
nix build .#synchronizer-eif-nitro
cat result/pcr.json
Both images use the builder's minimal kernel (non-storage profile, no modules, NSM driver built in) and the builder's patched init. The kernels and the aarch64 init are built here from the builder's source (the pinned builder-src input) with the builder's own nixpkgs pin (nixpkgs-builder), by the builder's recipe, so they are the same derivations the builder exports. The builder is not a flake input here: its flake has an enclavia input of its own. Everything else in the image is static: the synchronizer, synchronizer-names-init, nitro-timesync and busybox. The init script runs under busybox sh. The build fails if any binary in the image is not a static ELF for the image's architecture. See nix/synchronizer-eif.nix.
The whole point of this repo being open source is that anything PCR-measured inside the EIF must be buildable from sources you can audit. Every crate here is part of that perimeter (or is consumed by code that is, via enclavia-protocol).
The CLI's enclavia reproduce command pins to the same flake.lock the backend used when building an enclave, so you can verify that a given attestation came from the sources you expect.
Dual-licensed under either:
LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)LICENSE-MIT or http://opensource.org/licenses/MIT)at your option.
See CONTRIBUTING.md. Security reports go to [email protected].