xBoot: Server Code Integrity via Threshold Shares

The Problem

Server source code sits in plaintext on disk. A single disk compromise, insider threat, or supply chain breach exposes the entire codebase. Encryption-at-rest protects against offline attacks, but the decryption key must live on the same machine — defeating the purpose.

Traditional deployment pipelines copy source code or compiled binaries directly to production servers. The code exists as readable files on persistent storage. Anyone with disk access — a compromised VPS, a stolen backup, a malicious datacenter employee — can read the entire codebase.

Full-disk encryption (LUKS, BitLocker) requires the key to be available at boot. The key either lives on the same disk (circular security) or is fetched from a network service (single point of failure). Neither approach provides information-theoretic guarantees.

The fundamental flaw: every conventional approach requires the complete plaintext code to exist somewhere — on disk, in a build artifact, in a container image. xBoot ensures the complete plaintext exists only in memory, only during execution.

The Old Way

Competitive Analysis

Existing code integrity approaches protect specific layers but leave plaintext code accessible at some point. None provides information-theoretic protection for the complete software stack.

Why Hardware Approaches Fall Short for Software

UEFI Secure Boot verifies firmware signatures at the hardware level but does not protect application code deployed after boot. TPM attestation proves the boot chain is unmodified but cannot protect against runtime code extraction. SGX enclaves provide strong isolation but require Intel-specific hardware and have suffered multiple side-channel attacks (Spectre, Foreshadow, PLATYPUS).

xBoot takes a fundamentally different approach: instead of relying on hardware to protect software, it uses mathematics. The code is split into shares that are information-theoretically secure. No hardware vulnerability, no side-channel attack, no physical access can extract information from K-1 shares because the information literally does not exist in fewer than K shares.

The PRIVATE.ME Solution

xBoot splits server source code into K-of-N threshold shares at deploy time using XorIDA. Each share is stored on a separate disk or location. On boot, K shares are collected, HMAC-verified, reconstructed in memory, and loaded via tmpfs. The plaintext code never touches persistent storage.

Information-theoretic guarantee: Any K-1 shares reveal exactly zero bits about the original code. This is not computational security — it is mathematically proven. No quantum computer, no future algorithm, no amount of compute can extract information from fewer than K shares.

Triple integrity verification: (1) HMAC-SHA256 on the reconstructed bundle before any data is returned. (2) Ed25519 manifest signature from a trusted admin DID. (3) Per-file SHA-256 against the signed manifest. All three must pass before code executes.

The New Way

How It Works

Two operations: deploy() splits code into signed shares, boot() reconstructs and runs from shares. A 10-step pipeline with three layers of integrity verification.

Implementation Architecture

xBoot ships as two components: a TypeScript library (@private.me/xboot) for programmatic integration and an enterprise CLI server (xboot-cli) for production deployments. Both provide the same cryptographic guarantees while targeting different operational contexts.

The Enterprise CLI provides additional operational controls not available in library mode:

• Bundle revocation: Mark deployed bundles as revoked. Future boot attempts return BUNDLE_REVOKED error.
• RBAC enforcement: Three roles (admin, operator, auditor) with SHA-256 hashed API keys. Operators can boot bundles but cannot revoke. Auditors have read-only access to logs.
• Audit trail: Every upload, boot, and revocation logged with timestamp, bundle ID, and actor. Append-only JSONL format for compliance workflows.
• Air-gapped deployment: CLI commands can run entirely offline. Upload bundles via USB, distribute shares to disconnected systems, boot without network access.

Deploy Pipeline

Boot Pipeline

Bundle Format Detail

// Custom deterministic binary format (no tar dependency)

[fileCount: uint32 BE]
[entry] x fileCount, where each entry is:
  [pathLen: uint32 BE]
  [path: utf8 bytes]
  [dataLen: uint32 BE]
  [data: raw bytes]

// Files sorted alphabetically for deterministic output.
// Returns: blob (Uint8Array) + BundleFileEntry[] (path, sha256, size)

Manifest Structure

const manifest = {
  deployId:    'uuid-here',            // unique deployment ID
  gitSha:      'bf5dadd',              // git commit being deployed
  deployedAt:  '2026-04-05T...',        // ISO 8601 timestamp
  totalSize:   48230,                  // bundle size in bytes
  fileCount:   12,                     // number of files
  files: [
    { path: 'start.ts',       sha256: 'a1b2c3...', size: 1024 },
    { path: 'routes/auth.ts', sha256: 'd4e5f6...', size: 2048 },
    // ... per-file SHA-256 for every file in the bundle
  ],
  split: { n: 3, k: 2 },              // threshold parameters
  productType: 0x0035,                // xFormat product type
};

HMAC-Before-Reconstruction Invariant

The critical security invariant in the boot pipeline: HMAC is verified before any reconstructed data is returned to the caller. This ensures that tampered shares are rejected at the earliest possible point. The verification sequence is:

1. XorIDA reconstruct from K shares (output is raw bytes).
2. Unpad outer PKCS7 layer.
3. Extract HMAC key (bytes 0-31) and HMAC signature (bytes 32-63) from the prefix.
4. Compute HMAC-SHA256 over the remaining padded data using the extracted key.
5. Compare computed HMAC with the extracted signature. If mismatch: error, reject, return nothing.
6. Only if HMAC passes: unpad inner PKCS7, return the original bundle blob.

Hardware Root-of-Trust Integration

While xBoot's information-theoretic security does not depend on hardware, production deployments can layer xBoot with hardware roots-of-trust for defense-in-depth. Three integration patterns address different infrastructure contexts:

// Extend PCR registers with xBoot attestation data
import { attestBoot } from '@private.me/xboot';
import { extendPCR } from 'tpm2-tools';

// 1. Reconstruct bundle from shares (HMAC verified)
const bootResult = await boot(config);

// 2. Compute attestation (per-file SHA-256 vs. manifest)
const attestation = attestBoot(manifest, reconstructedBundle);

// 3. Extend TPM PCR 10 (application-specific measurements)
await extendPCR(10, attestation.overallHash);

// PCR 10 now contains cryptographic proof of code integrity.
// Remote attestation can verify this measurement before granting access.

TPM PCR Extension Flow: Platform Configuration Registers (PCRs) store hash chains of boot-time measurements. xBoot integrates at the application layer (PCR 10-15 are reserved for OS and application use). After HMAC verification and per-file SHA-256 checks pass, xBoot extends a PCR with the overall attestation hash. This creates a cryptographic record that the code running on the system matches the signed deployment manifest. Remote attestation protocols (TPM2_Quote) can then prove to external systems that the platform booted trusted code.

UEFI Secure Boot Compatibility: xBoot operates above the UEFI layer and does not conflict with Secure Boot certificate chains. The bootloader verifies kernel signatures via UEFI Secure Boot. The kernel boots userspace. xBoot then reconstructs application code in userspace RAM. The two mechanisms provide complementary protection: UEFI protects the boot chain up to the kernel, xBoot protects application code loaded after kernel initialization. Organizations can deploy both simultaneously without modification to UEFI configurations.

Boot Measurement Chain: The complete measurement chain for a TrustZone-integrated xBoot deployment on ARM looks like:

1. ARM TrustZone Boot ROM measures first-stage bootloader (immutable).
2. First-stage bootloader measures second-stage (U-Boot or equivalent).
3. U-Boot measures kernel, extends ARM TrustZone measurement registers.
4. Kernel boots, OP-TEE Secure World initialized.
5. xBoot retrieves Share 1 from Normal World, Share 2 from OP-TEE secure storage.
6. Reconstruction and HMAC verification in OP-TEE Trusted Application.
7. Attestation hash extended to TrustZone measurement register.
8. Code loaded into Normal World for execution, Secure World holds attestation proof.

This layered approach addresses IEC 62443-4-2 requirements for embedded device security in operational technology environments. The measurement chain provides cryptographic evidence from hardware root-of-trust through application code integrity.

Benchmarks

Performance measured on Node.js 22, Apple M2. xBoot protects firmware and code bundles with sub-100ms overhead for typical deployment sizes.

Memory Overhead

During reconstruction, memory usage equals approximately 2x the bundle size: one copy for the share data being reconstructed, one for the output bundle. After reconstruction completes, share data is zeroed and released. Peak memory for a 1 MB bundle is approximately 2.5 MB (bundle + overhead + tmpfs write buffer).

Comparison: Boot Overhead vs. Alternatives

Throughput at Scale

For fleet deployments, xBoot's deploy pipeline processes approximately 20 MB/s of source code (split + HMAC + envelope + encode). A 10 MB application bundle deploys in approximately 500ms. Share distribution is parallelized: all N shares are sent simultaneously to their respective storage backends.

Boot reconstruction throughput is similar: approximately 20 MB/s. The bottleneck for large bundles is the XorIDA reconstruction, which is linear in bundle size. For bundles under 1 MB (which covers most server applications), total boot overhead is under 50ms.

ACI Surface

Six core operations covering the complete deploy-boot lifecycle. Every function returns Result<T, XbootError> and never throws.

Use Cases

xBoot protects any software that needs to run without ever existing as plaintext on persistent storage.

Regulatory Alignment

xBoot addresses code integrity, firmware resilience, and data-at-rest requirements across multiple compliance frameworks.

Compliance Workflow

For organizations subject to NIST SP 800-193 or IEC 62443, xBoot provides a structured compliance workflow. The Ed25519-signed deployment manifest serves as cryptographic evidence of what code was deployed, when, and by whom (identified by DID). Auditors can verify the manifest signature to confirm deployment authenticity without accessing the source code.

The per-file SHA-256 hashes in the manifest enable fine-grained audit: auditors can verify that specific files (e.g., authentication modules, encryption libraries) are exactly the approved versions. Combined with git SHA references, this creates a complete chain of custody from source repository to production execution.

Industry-Specific Requirements

Cross-ACI Patterns

xBoot integrates with the PRIVATE.ME platform to provide code integrity within the broader security infrastructure.

xBoot + xLink: Agent-Verified Boot

xLink provides DID-authenticated agent-to-agent communication. xBoot shares can be distributed via xLink channels, ensuring that only DID-authenticated agents receive shares. The boot server authenticates the share source via xLink envelope verification before accepting shares for reconstruction.

import { Agent } from '@private.me/xlink';
import { deploy } from '@private.me/xboot';

// Deploy: split code into shares
const result = await deploy(bundleConfig, { n: 3, k: 2 });

// Distribute shares via xLink authenticated channels
const admin = await Agent.fromSeed(adminSeed);
for (let i = 0; i < result.value.shares.length; i++) {
  await admin.send(
    shareHolderDids[i],
    new TextEncoder().encode(result.value.shares[i])
  );
}

xBoot + xProve: Verifiable Boot Proofs

xProve chains boot events into a tamper-evident audit trail. Every deploy, boot, reconstruction, and integrity check generates HMAC-SHA256 integrity tags. xProve links these into a verifiable chain that proves exactly what code ran on which server at what time. Auditors can verify the entire boot history without accessing the code itself.

xBoot + xStore: Split-Stored Binaries

xStore provides a universal split-storage layer with pluggable backends (S3, GCS, Azure Blob, local filesystem). xBoot shares can be stored via xStore, distributing shares across multiple cloud providers automatically. On boot, xStore collects K shares from the configured backends and passes them to xBoot for reconstruction.

xBoot + xGhost: Ephemeral Execution

xGhost provides ephemeral execution with automatic memory purging. Combined with xBoot, the code is reconstructed in memory by xBoot, executed within an xGhost ephemeral context, and then both the code and the execution state are purged. The code exists in memory only for the duration of the specific operation, not the entire server lifetime.

xBoot + xID: DID-Authenticated Deployments

xID provides per-verifier ephemeral DIDs. The deployment admin's DID is embedded in the manifest signature. On boot, the manifest verifier checks the signer DID against a trusted admin registry. Ephemeral DIDs from xID can be used for one-time deployments where the deployment identity should not be linkable across different servers.

xBoot + xPass: Billing-Gated Code Distribution

xPass can enforce billing on code distribution channels. Each xBoot share distribution requires an active xPass billing connection between the deployer and the share-holding node. If billing lapses, share rotation is suspended — the node cannot receive new deployment shares. This creates a billing enforcement layer for code distribution, complementing xPass's M2M communication billing.

Integration Architecture

// Full secure boot with PRIVATE.ME platform integration

// 1. xStore: collect shares from distributed backends
const shares = await xstore.collectShares(deployId, k);

// 2. xLink: verify share source authentication
for (const share of shares) {
  const verified = await xlink.verifyEnvelope(share.envelope);
  if (!verified.ok) throw new Error('Share source unverified');
}

// 3. xBoot: reconstruct and execute
const result = await xboot.boot({
  shares: shares.map(s => s.data),
  manifest: signedManifest,
  trustedAdminDid: adminDid,
  entrypoint: 'start.ts',
});

// 4. xProve: log boot event to audit trail
await xprove.logEvent({
  type: 'BOOT_COMPLETE',
  deployId: manifest.deployId,
  gitSha: manifest.gitSha,
});

Boot Measurement and Remote Attestation

xBoot integrates with platform attestation mechanisms to provide cryptographic proof of code integrity to remote verifiers. Three attestation patterns address different infrastructure requirements.

TPM 2.0 PCR-Based Attestation

Trusted Platform Modules provide hardware-backed measurement storage via Platform Configuration Registers (PCRs). xBoot extends application-layer PCRs (10-15) with attestation hashes after successful boot verification. The measurement flow:

// After xBoot completes HMAC + manifest + per-file verification
const bootResult = await boot(config);
const attestation = attestBoot(manifest, reconstructedBundle);

// Extend PCR 10 with overall attestation hash
const pcrValue = attestation.overallHash;
await tpm2.pcrExtend(10, pcrValue);

// PCR 10 now contains: SHA-256(previous_value || attestation_hash)
// This creates an ordered hash chain of all boot events.

// Remote attestation: prove platform state to external verifier
const quote = await tpm2.createQuote([10], nonce);
const signature = await tpm2.signQuote(quote, aikHandle);

// Verifier checks: quote signature, nonce freshness, PCR values.
// If PCR 10 matches expected hash chain, code integrity is proven.

PCR Selection Strategy: PCRs 0-7 are reserved for BIOS/UEFI measurements. PCRs 8-9 for bootloader and kernel. PCRs 10-15 available for OS and application use. xBoot uses PCR 10 by default to avoid conflicts with other application-layer measurements. Organizations running multiple attestation systems can assign different PCRs per application (e.g., PCR 10 for xBoot, PCR 11 for container runtime, PCR 12 for database encryption keys).

TPM Quote Protocol: Remote attestation works via TPM2_Quote operation. The verifier sends a fresh nonce. The TPM signs a structure containing current PCR values and the nonce using the Attestation Identity Key (AIK). The verifier checks the signature against the AIK public key and confirms the nonce matches. If PCR 10 contains the expected xBoot attestation hash, the verifier has cryptographic proof that the platform booted the correct code. No secrets are revealed — only the fact that integrity checks passed.

ARM TrustZone Attestation (OT/ICS Devices)

ARM-based operational technology devices (PLCs, RTUs, edge controllers) increasingly support TrustZone. xBoot integrates with OP-TEE (Open Portable Trusted Execution Environment) for secure boot attestation on ARM Cortex-A processors:

// OP-TEE Trusted Application (Secure World)
struct xboot_attestation {
  uint8_t manifest_hash[32];     // SHA-256 of signed manifest
  uint8_t bundle_hash[32];       // SHA-256 of reconstructed bundle
  uint8_t overall_hash[32];      // Combined attestation hash
  uint64_t timestamp;             // Boot time (monotonic counter)
};

// Secure World stores attestation in protected memory
TEE_Result store_boot_attestation(struct xboot_attestation *att) {
  // Write to Secure Storage (encrypted by TrustZone)
  return TEE_WriteObjectData(secure_handle, att, sizeof(*att));
}

// Normal World requests attestation proof
TEE_Result get_attestation_proof(uint8_t *signature_out) {
  // Sign attestation with device-unique key (fused in TrustZone)
  return TEE_AsymmetricSignDigest(att_key, &att, signature_out);
}

TrustZone Boot Flow for Industrial Controllers: At power-on, the ARM Boot ROM (immutable, fused in silicon) measures and boots the first-stage bootloader. The bootloader measures U-Boot, U-Boot measures the kernel, and the kernel initializes OP-TEE. xBoot runs as a Trusted Application in OP-TEE Secure World. Share 1 comes from Normal World filesystem, Share 2 from Secure Storage. Reconstruction and HMAC verification happen in Secure World, isolated from the Normal World OS. The attestation hash is signed with a device-unique key (derived from TrustZone UID) and can be verified remotely by the SCADA master or operations center.

Why This Matters for OT/ICS: Industrial control systems face unique threats: long service life (20+ years), harsh physical environments, difficulty patching firmware, and high consequence of failure. TrustZone provides hardware-based isolation without requiring discrete TPM chips (which add cost and complexity to ruggedized enclosures). A water treatment plant deploying 50 field controllers can verify code integrity on all units via remote attestation without physical site visits. IEC 62443-4-2 SR 3.4 (software integrity) and SR 1.2 (software update authentication) are both satisfied.

UEFI Secure Boot Layering

xBoot does not replace UEFI Secure Boot — it complements it. UEFI Secure Boot verifies the bootloader and kernel signatures against certificates in the UEFI key database. xBoot operates at the application layer, protecting code loaded after the kernel is running. The combined defense:

Certificate Expiry Context (2026): Microsoft's UEFI CA 2023 and KEK CA 2011 certificates expire in June 2026. Affected systems must update UEFI firmware to receive refreshed certificates. xBoot's Ed25519-based manifest signatures are independent of the UEFI certificate chain and unaffected by UEFI certificate rotation. Organizations can update UEFI certificates on their own schedule without coordinating with xBoot deployment cycles.

Defense-in-Depth Rationale: A bootkit that bypasses UEFI Secure Boot can still not reconstruct xBoot-protected application code without obtaining K shares. Conversely, an attacker with K shares but no kernel access cannot modify the boot chain to inject malicious code because UEFI Secure Boot blocks unsigned kernels. The layered approach raises the bar significantly: an attacker must compromise both the UEFI certificate chain AND the xBoot share distribution infrastructure simultaneously.

Measured Boot vs. Secure Boot

xBoot supports both paradigms, which serve different purposes:

Remote Attestation Use Case: Cloud Confidential Computing

Cloud confidential VMs (Azure Confidential VMs, AWS Nitro Enclaves, GCP Confidential VMs) provide hardware attestation via AMD SEV-SNP or Intel TDX. xBoot integrates by extending the attestation report with application-layer code measurements:

1. Confidential VM boots with SEV-SNP attestation enabled.
2. xBoot reconstructs server code from shares, computes attestation hash.
3. Attestation hash is hashed with the SEV-SNP measurement.
4. Combined measurement sent to remote verifier (e.g., Azure Attestation Service).
5. Verifier checks: SEV-SNP report signature, firmware measurements, xBoot attestation hash.
6. If all checks pass, verifier releases secrets (database encryption keys, API tokens).

This pattern ensures that secrets are only released to VMs running the correct code, verified both at the hypervisor level (SEV-SNP) and the application level (xBoot). An attacker who gains VM access cannot decrypt databases or access APIs without also compromising the attestation chain.

Why XorIDA

XorIDA provides the mathematical foundation that makes xBoot's guarantees possible. No encryption algorithm — no matter how strong — can match the security properties of information-theoretic splitting.

Security Properties

Three integrity layers, information-theoretic confidentiality, and defense-in-depth against every realistic threat vector.

Threat Model

Error Code Reference

Ship Proofs, Not Source

xBoot generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.

Use Cases

Honest Limitations

Six known limitations documented transparently. xBoot's security model requires trade-offs in deployment flexibility.

Limitation Details

On K-share availability: The most common deployment is 2-of-3, which tolerates one node failure. For mission-critical systems, 3-of-5 tolerates two simultaneous failures. The choice of K and N is a trade-off between fault tolerance (higher N-K) and security (higher K). A 2-of-2 deployment has zero fault tolerance but maximum security — both shares must be present, and a single share reveals nothing.

On memory requirements: The 2x memory overhead during reconstruction is a fundamental constraint of the XorIDA algorithm. For very large bundles (>100 MB), chunked reconstruction is recommended: split the application into independently-bootable segments, each reconstructed and loaded separately. This reduces peak memory to the size of the largest segment.

On environment attestation: xBoot verifies code integrity but not environment integrity. A compromised operating system could intercept the reconstructed code in memory. For maximum protection, pair xBoot with hardware attestation (SGX, TrustZone, SEV-SNP) or xGhost ephemeral execution. xBoot provides the code integrity layer; the environment integrity layer is a separate concern.

Enterprise CLI

xboot-cli provides a standalone HTTP server for enterprise deployments. Port 3700. Docker-ready. Air-gapped capable.

Endpoints

// Deploy operations
POST   /deploy                  // Split source into shares
POST   /deploy/bundle           // Bundle source directory
POST   /deploy/split            // Split an existing bundle
POST   /deploy/manifest         // Sign deployment manifest

// Boot operations
POST   /boot                    // Full boot pipeline
POST   /boot/verify-manifest    // Verify manifest signature
POST   /boot/reconstruct        // Reconstruct from shares
POST   /boot/attest             // Verify per-file SHA-256

// Management
GET    /deployments              // List deployment history
GET    /deployments/:id          // Get deployment details

// Health
GET    /health                   // Server status

Docker Deployment

services:
  xboot:
    image: private.me/xboot-cli:latest
    ports:
      - "3700:3700"
    environment:
      - XBOOT_PORT=3700
      - XBOOT_TMPFS_BASE=/dev/shm
      - XBOOT_ADMIN_DID=did:key:z6Mk...
    volumes:
      - xboot-data:/data
      - type: tmpfs
        target: /dev/shm
    restart: always

Configuration

xboot-cli is configured via environment variables. All settings have sensible defaults for development. Production deployments should explicitly set the admin DID and tmpfs base path.

Air-Gapped Operation

xboot-cli is designed for air-gapped environments. All cryptographic operations (XorIDA splitting, HMAC-SHA256, Ed25519 signing, SHA-256 hashing) use the built-in Web Crypto API with no external dependencies. Shares can be transported via USB drives, optical media, or any offline channel. The CLI validates shares entirely locally without network access.

For air-gapped deployments, the workflow is: (1) deploy() on the build machine, producing Base45-encoded shares on separate media; (2) physically transport K media to the target machine; (3) boot() reads shares from the media, reconstructs in memory, and executes. The target machine never needs network connectivity.

Viral Onboarding: < 2 Minute M2M Setup

One-Line Connection (SDK)

import { connect } from '@private.me/agent-sdk';

// Zero-config discovery
const bootService = await connect('secure-boot-attestation');

// Use immediately for firmware verification
const result = await bootService.send({
  type: 'attest',
  data: {
    deployId: '...',
    measurements: [...],
    manifest: signedManifest
  }
});

Network effects: When your supplier already uses Xlink, connection is instant. When they don't, you send an invite (< 10 sec), they accept (< 60 sec), and all future connections are instant.

CLI Alternative

# Initialize once
xlink init

# Connect to attestation service
xlink connect secure-boot-attestation

# Invite a supplier to join
xlink invite partner-factory-boot

Zero-Downtime Migration

import { DualModeAdapter } from '@private.me/agent-sdk';

// Both Xlink AND your existing API key work
const adapter = new DualModeAdapter({
  xlink: bootAgent,
  fallback: { apiKey: process.env.FACTORY_API_KEY }
});

const result = await adapter.call('attest', {
  deployId: '...',
  measurements: [...]
});

// Track adoption progress
console.log(adapter.getMetrics());
// { xlinkPercentage: 73, xlinkCalls: 146, fallbackCalls: 54 }

As your supplier partners adopt Xlink, your xlinkPercentage automatically increases. No code changes required.

Why Supply Chains Need Viral M2M

• Instant verification: Firmware attestation flows must complete in real-time during boot. API key setup delays create deployment bottlenecks.
• Multi-party trust: Secure boot involves OEMs, component suppliers, foundries, and auditors. Manual key exchange across 5+ parties is untenable.
• Network effects: Each manufacturer's adoption reduces friction for their entire supply chain—suppliers connect instantly to multiple customers.

Each manufacturer connects to ~3 suppliers → exponential growth. Growth projection: Month 1 (100 manufacturers) → Month 12 (74,185 manufacturers) with VC = 1.2

Verifiable Code Protection

Every operation in this ACI produces a verifiable audit trail via xProve. HMAC-chained integrity proofs let auditors confirm that data was split, stored, and reconstructed correctly — without accessing the data itself.

Enhanced Identity with Xid

xBoot can optionally integrate with Xid to enable unlinkable device attestation — verifiable within each boot context, but uncorrelatable across reboots, locations, or time.

Three Identity Modes

// Initialize xBoot with Xid integration
import { createBootClient } from '@private.me/xboot-cli';
import { XidClient } from '@private.me/xid';

const xid = new XidClient({ mode: 'ephemeral' });
const boot = createBootClient({ identityProvider: xid });

// Each boot derives unlinkable device DID automatically
const attestation = await boot.attest();
  → [xBoot] Deriving ephemeral device DID from master seed...
  → [xBoot] DID: did:key:z6MkG... (unique to this boot + device + epoch)
  → [xBoot] Generated TPM attestation with ephemeral identity (~50µs)
  → [xBoot] Key purged (<1ms exposure)

// Boot is verified with unlinkable DID
// Attestation works within context, but cross-boot correlation fails

Integration Example

Full lifecycle: deploy with manifest signing, distribute shares, boot with triple verification.

import { deploy } from '@private.me/xboot';
import { generateIdentity } from '@private.me/xlink';

// Generate admin identity for manifest signing
const admin = await generateIdentity();
if (!admin.ok) throw new Error('Keygen failed');

// Deploy: bundle + split + sign manifest
const result = await deploy(
  {
    sourceDir: '/path/to/server/src',
    gitSha: 'abc1234',
    adminDid: admin.value.did,
    adminPrivateKey: admin.value.privateKey,
  },
  { n: 3, k: 2 }  // 2-of-3 threshold
);

if (result.ok) {
  console.log(`Deploy ID: ${result.value.deployId}`);
  console.log(`Shares: ${result.value.shares.length}`);
  // Distribute shares to separate storage locations
}

import { boot } from '@private.me/xboot';

// Collect K shares from separate storage backends
const result = await boot({
  shares: [shareFromDisk1, shareFromDisk2],
  manifest: signedManifestFromSecureStorage,
  trustedAdminDid: 'did:key:z6Mk...',
  entrypoint: 'start.ts',
  tmpfsBase: '/dev/shm',
});

if (!result.ok) {
  console.error(`Boot failed: ${result.error}`);
  process.exit(1);
}
// Server is running from RAM
// tmpfs cleaned up in finally block

Ready to deploy xBoot?

Talk to Sol, our AI platform engineer, or book a live demo with our team.