Security Model

Overview

Bunker-Centric Architecture follows a zero-trust model by construction. The architecture recognizes that all components outside the Bunker Trusted Computing Base (Bunker OS, Bunker TEE, Hypervisor, firmware) are inherently non-trusted. Open World is untrusted from the start, not due to configuration or policy, but by design.

The security model rests on three pillars:

1. Trust by Verification, Not by Default

Components within the Trusted Computing Base (hypervisor, Bunker OS, Bunker TEE, firmware) are trusted because they are verified through a cryptographic chain starting from an immutable hardware root-of-trust. Open World is not trusted; it is isolated and monitored. Any data crossing from Open World into Bunker OS is treated as potentially hostile: it must be cryptographically verified before being acted upon, and encrypted when confidentiality is required. There is no implicit trust on the Open World | Bunker boundary; every crossing should be subject to explicit validation.

2. Customer-Controlled Secrets

Accelerat does not manage customer keys or certificates. Instead, all cryptographic material is managed by the customer through the Bunker Development Framework (BDF). This means you control the full lifecycle of your security material: generation, provisioning, rotation, and revocation. We provide open-source tools and infrastructure to assist, but the keys remain yours. You can audit these tools (available in the SBOM), check for CVEs, and patch them independently.

3. Defense in Depth with Transparency

All security-critical components are open-source, allowing full transparency. You have access to SBOMs and can monitor CVEs through our tools. When vulnerabilities are discovered, you can patch them independently or rely on reference design patches.

Trusted Computing Base

The Trusted Computing Base (TCB) consists of components verified at boot and isolated from Open World:

  • Firmware (SPL, TF-A): Verified by immutable ROM code; Controls boot chain

  • Bunker TEE (OP-TEE): Verified by immutable ROM code; Provides trusted execution environment for cryptographic operations and secrets management

  • Hypervisor: Verified by immutable ROM code; Enforces VM isolation and controls all I/O access

  • Bunker OS: Manages system policy, authentication, authorization, and security monitoring

Everything else such as Open World, containerized applications, and network services, is untrusted by construction.

Bunker OS itself runs with kernel lockdown enforced and all kernel modules must be signed; unsigned modules are rejected at load time. The Open World kernel and bootloader are signed and verified at boot as part of the trust chain, preventing unauthorized kernels from being launched.

For the rootfs, the reference design distinguishes between the two domains:

  • Bunker OS rootfs: Subject to integrity and/or confidentiality protection depending on deployment requirements. Because Bunker OS is part of the TCB, protecting its rootfs with dm-verity (integrity) and/or dm-crypt (confidentiality) is strongly recommended for production.

  • Open World rootfs: You are free to choose. Integrity and/or confidentiality can be applied if required. Secrets for dm-verity or dm-crypt must be managed through OP-TEE or Bunker OS; see Security Hardening for how to configure this.

Note

By default, reference design images ship without signature enforcement or dm-verity active, because these features require key generation, provisioning, and hardware fuse programming that are specific to your deployment. How to generate keys, enable secure boot, provision keys, write eFuses, and enable dm-verity or other device-mapper targets is documented in Security Hardening and Meta Layers Reference.

See Boot Flow for boot image signing and kernel integrity enforcement details.

Threat Model

Open World Threats

Because Open World is inherently untrusted, it is isolated at the hypervisor level. Even if Open World is completely compromised, it cannot:

  • Access Bunker OS memory (hypervisor enforces address space isolation)

  • Access Bunker OS storage (single-storage mode: virtio backend controlled by Bunker OS; dual-storage mode: separate physical device inaccessible to Open World VM)

  • Tamper with boot artifacts or signed images (Bunker OS and secure boot prevent modification)

  • Compromise cryptographic keys (stored in OP-TEE secure world, never exposed to normal world)

  • Bypass authorization for system-critical operations (RPC schema validation, ACLs)

  • Directly access security-sensitive hardware devices (all security-critical devices are assigned to Bunker OS; Open World receives only non-sensitive devices, which are virtualized or passed through per hypervisor configuration)

The impact of an attack depends on how deep the compromise reaches within Open World:

  • User or root-level exploit: The attacker is fully contained within Open World. They can disrupt applications and services, but cannot access Bunker OS memory, storage, or cryptographic keys. Monitoring data already captured by Bunker OS is in Bunker OS secure storage and cannot be tampered with retroactively.

  • Open World kernel exploit: The attacker gains control of the Open World kernel. This can disrupt Open World completely, including potentially degrading the monitoring pipeline, since monitoring relies on Open World kernel interfaces. However, even a fully compromised Open World kernel cannot escape the hypervisor boundary, access Bunker OS memory, modify boot artifacts, or reach OP-TEE secrets. The Bunker domain remains secure; only Open World availability and monitoring capabilities are affected.

Protected Threats

The BCA architecture protects against a range of threats:

Threat

Protection Mechanism

Supply Chain & Firmware Attacks

Malicious boot artifact replacement is detected at boot via signature verification. Invalid signatures halt boot in fail-secure mode. Recovery only possible through legitimate update channels.

Unauthorized Updates

Update packages are cryptographically signed and verified by OP-TEE before activation. Only packages signed by authorized parties are accepted; all others are rejected and logged as security events.

Rollback Attacks

Version monotonic counters prevent downgrading to older versions. RAUC enforces forward-only versioning (customizable per policy).

Configuration Tampering

Boot configuration, device tree, and policy files are signed. Modified configurations are detected at boot and rejected before execution.

Data Exfiltration

Open World cannot access Bunker OS storage directly. Secrets and cryptographic keys remain in OP-TEE secure world (never exposed to normal world). All inter-domain communication (RPC/vsock) can be monitored and validated.

Physical Attacks (platform-dependent)

Some SoCs provide tamper-proof monitors, PUF (Physically Unclonable Function), secure storage (fuses, HSM). Bunker OS can leverage these to detect tampering. Availability varies by platform; refer to SoC-specific documentation.

Limitations

The architecture does not protect against the following limitations:

Limitation

Description & Mitigation

Hypervisor Vulnerabilities

A critical bug in the hypervisor could potentially allow VM escape. Mitigation: Hypervisor code is minimized and open-source for auditability; apply security patches promptly.

Open World Kernel Vulnerabilities

A kernel exploit in Open World can disrupt Open World availability and degrade monitoring fidelity, but cannot escape the hypervisor or affect Bunker OS security. Mitigation: Keep Open World kernel updated; hardware and software watchdogs detect hangs and trigger recovery.

Bunker OS or Hypervisor Vulnerabilities

A critical vulnerability in Bunker OS or the hypervisor is more serious and could affect Bunker security functions or, in an extreme case, allow VM escape. Mitigation: Apply security updates promptly; both code surfaces are minimized to reduce risk; report vulnerabilities to Accelerat for expedited response.

Cryptographic Algorithm Breaks

A fundamental break in RSA-2048 or SHA-256 is cryptographically unlikely within decades. Mitigation: Bunker Development Framework supports algorithm agility; newer algorithms can be substituted.

Malicious Hardware

If the SoC itself is compromised at manufacturing, isolation and cryptography cannot help. Mitigation: Use SoCs with security certifications; verify supply chain integrity, verify SoC errata document(s).

Key Management

Your Keys, Your Control

Unlike traditional platforms, you own and manage all cryptographic material. BCA provides tools and infrastructure but does not hold your keys. All key management happens through the Bunker Development Framework:

  • Device keys (public/private): Generated per-device; used for authentication and attestation

  • Signing keys (for updates): You control who can sign updates to your devices

  • Encryption keys (for data at rest): Encrypted with hardware-unique keys when supported; you control the key policy

  • Audit and compliance keys: Generated and rotated per your policy

All tools for key generation, provisioning, and lifecycle management are open-source, available in the SBOM, and auditable.

OP-TEE for Cryptography

OP-TEE (Open Portable Trusted Execution Environment) manages all cryptographic operations in a trusted execution environment that runs in ARM TrustZone secure world (EL1S/EL3).

OP-TEE takes full advantage of hardware cryptographic backends where the SoC supports them:

  • Hardware crypto engines: AES, SHA, RSA, and ECC accelerators are used as backends, offloading operations from software and reducing side-channel exposure

  • Hardware Unique Keys (HUK): Where available, OP-TEE derives a device-unique key that is physically bound to the SoC (from fuses, PUF, or equivalent). This key cannot be extracted even with physical access and full memory dumps. All other keys can be wrapped (encrypted) under the HUK, making them device-bound

  • PUF (Physically Unclonable Function): Provides hardware-rooted entropy for key derivation on supported SoCs

  • HSM integration: On platforms with a dedicated Hardware Security Module, OP-TEE can delegate key storage and operations to the HSM

  • RPMB (Replay Protected Memory Block): Provides tamper-resistant secure storage for OP-TEE persistent data on eMMC devices

Keys generated and managed by OP-TEE never leave secure world during cryptographic operations. Bunker OS and its services can request cryptographic services through the OP-TEE client API (GlobalPlatform TEE Client API), but cannot access raw key material.

See Security Hardening for OP-TEE configuration, Trusted Application development, and platform-specific hardware crypto integration.

Black-Red Separation

The black-red model is a security paradigm that separates cryptographic keys and sensitive data based on their exposure:

  • Red refers to unencrypted, plaintext cryptographic keys and sensitive data. Red keys must never exist outside a secure boundary - they must never reside on untrusted storage or be exposed in normal world.

  • Black refers to data encrypted under red keys, or red keys themselves encrypted and stored in secure storage. Black data can safely cross insecure boundaries, be stored on untrusted media, or be transmitted over a network, because without the corresponding red key it is opaque to an attacker.

This approach of keeping red keys encrypted (as black) in storage is a foundational principle applied throughout BCA to ensure keys are never exposed in plaintext. It is introduced conceptually here; specific implementations and usage patterns are documented in the relevant technical documentation (boot security, key management, storage encryption, etc.).

In BCA, red keys are used to encrypt sensitive data (rootfs images, configuration archives, secrets bundles, audit logs, etc.). The red keys themselves are protected by storing them as “black” (encrypted) in OP-TEE secure storage. This ensures that even if an attacker extracts the contents of OP-TEE secure storage, the keys remain encrypted and unusable without the master key.

Key Storage in OP-TEE

When a red key is generated, it is stored in OP-TEE secure storage as encrypted (black) material. OP-TEE secure storage itself is encrypted using a master key that is hardware-bound and never stored in plaintext. Depending on the SoC, the master key is derived from:

  • Hardware Unique Key (HUK): A device-unique key derived from immutable hardware features (fuses, PUF) that cannot be extracted or cloned

  • Key-Encryption-Key (KEK): On some SoCs, a KEK is stored in BBRAM or delegated to an HSM (Hardware Security Module)

For details on OP-TEE secure storage and key wrapping mechanisms, see the OP-TEE secure storage documentation.

Practical Examples

  • Encrypted Bunker OS rootfs: Rootfs is encrypted with a red key and stored on the storage device (untrusted from physical access perspective). At boot, the Bunker OS kernel (signed, verified, and trusted) requests the red key from OP-TEE. OP-TEE retrieves the key from secure storage and provides it to the kernel. The kernel loads the key into the Linux keychain and uses it with dm-crypt to transparently decrypt and mount the rootfs. The red key never exists outside the kernel context; once the rootfs is mounted, the key remains in the keychain for decryption operations but is never exposed to user space nor saved as plaintext in the physical device.

  • Encrypted audit logs: Bunker OS encrypts security logs with a red key managed by OP-TEE. Later, the customer retrieves these logs and decrypts them on a remote server using the same red key (provisioned separately to that server), gaining access to the plaintext logs without exposing the key on the device.

  • Encrypted configuration or secret data: Any asset (credentials, certificates, policy files) can be encrypted with a red key and provisioned onto the device without exposing it to Open World.

Key Provisioning Policy

Key provisioning is configured through the Bunker Development Framework. You choose between:

  • Device-unique keys (default, strongest binding): Each device receives a unique red key, binding encrypted data to that specific device.

  • Shared keys: The same red key is used across multiple devices, allowing the same encrypted image to boot on multiple devices (useful for fleets with identical configurations).

Regardless of the provisioning model, the red keys remain encrypted and secure in OP-TEE secure storage, never exposed in plaintext on untrusted media.

Monitoring and Anomaly Detection

Open World Monitoring

Because Open World is untrusted, Bunker OS monitors its behavior for anomalies and malicious activity. Monitoring occurs at multiple levels:

Kernel-Level Monitoring

Bunker OS uses Falco as the kernel-level security monitoring engine for Open World. Falco instruments the Open World kernel via a signed kernel module and collects system call traces, process lifecycle events, network activity, and file access patterns in real time. Collected data is written to Bunker OS secure storage, making it inaccessible to Open World.

The resilience of monitoring against an attack depends on the depth of the compromise:

  • User or root-level attack: Falco continues operating normally. Monitoring data is in Bunker OS secure storage and cannot be suppressed, tampered with, or forged by Open World, even from a root shell.

  • Open World kernel exploit: A kernel-level attacker could potentially interfere with the Falco kernel module or its data collection path, degrading the fidelity or continuity of monitoring going forward. This affects monitoring availability only while all previously captured records remain protected in Bunker OS secure storage, and the Bunker domain itself is not affected in any way.

The monitoring documentation covers:

  • Which event categories can be monitored (syscalls, network, file I/O, process events)

  • How the Falco kernel module is signed and how signature enforcement prevents substitution

  • How collected data is transferred to Bunker OS secure storage

See Falco Runtime Security Monitoring for full configuration and integration details.

Hardware-Level Performance Monitoring Analysis

Hardware-Level Performance Monitoring Unit (PMU) analysis is available as an optional additional component. This component analyzes PMU events from Open World without contextual information from applications. A semantic-free statistical analysis engine reads PMU events (with multiplexing support) and raises alarms when anomalies are detected. For example, an excess of speculative execution in a short time window might indicate a side-channel or Spectre-like attack. PMU analysis documentation is forthcoming. Contact Accelerat for availability and configuration details.

Note

PMU analysis is subject to customer agreement and is available as an optional service.

Tamper-Proof Logs and Telemetry

Bunker OS collects telemetry and security logs and stores them in secure storage, preventing Open World from tampering with audit trails. Features include:

  • Event logging with cryptographic integrity protection

  • Secure backups stored on Bunker OS partition

  • Secure log rotation and retention policies

  • Integration with external logging systems (via RPC)

See Fluent Bit Log Forwarding for detailed configuration and integration patterns.

Compliance and Customization

BCA provides multiple features beyond standard compliance to meet demanding security requirements:

Defense-in-Depth Features

Feature

Description

Independent reboot capability

Bunker OS can reboot independently, isolating Open World

Minimal VM with constrained functionality

For running only critical security services

Hardware watchdogs

Detect system hangs; can be configured for automatic recovery

Software watchdogs

Bunker OS monitors key system processes; can trigger recovery or isolation

Standards Compliance

Standard

Coverage

IEC 62443 Security Levels

SL1, SL2, SL3 supported in reference design; SL4 with custom hardening (independent reboot, mini VM, watchdogs)

CRA (Cyber Resilience Act)

Secure boot chain, signed updates (RAUC), vulnerability management, incident reporting (logging), documentation

Hardware Security (where available)

Some SoCs provide hardware-based security features:

Feature

Description & Availability

Tamper-proof monitors

Detect physical tampering (available on custom projects; check SoC-specific documentation)

PUF (Physically Unclonable Function)

Hardware-unique key derivation (no extraction of keys from hardware)

HSM (Hardware Security Module)

Dedicated cryptographic processor (available on select platforms)

Secure storage (RPMB, fuses)

Tamper-resistant memory

Support

For compliance documentation, threat analysis, and risk assessment, Accelerat provides consulting and support:

  • Help developing compliance documentation aligned with CRA and IEC 62443

  • Threat modeling and risk assessment for your deployment

  • Custom hardening recommendations

  • Support for platform-specific security features

Vulnerability Management

Open-Source Transparency

All components managing cryptographic material and secrets are open-source:

  • You have access to full source code and can audit it independently

  • The SBOM (Software Bill of Materials) is generated as part of every build and CVE tracking and analysis is supported through integrated tooling; see SBOM Generation and CVE Analysis for how to generate and use it

  • VEX (Vulnerability Exploitability eXchange) reports allow you to communicate and assess whether a CVE is exploitable in your specific configuration; see VEX Decisions and Compliance Export

Update Strategy

Accelerat Reference Designs: We patch the reference design as soon as vulnerabilities are discovered and verified. Patches are provided as updates on BCA, which you deploy on your schedule. If you have devices in production, you should package and send an update to maintain security posture.

Custom Components: You can patch your own customizations independently. The Bunker Development Framework supports custom meta-layer recipes, allowing you to build and deploy patches without waiting for Accelerat releases.

CVE Monitoring: Use the SBOM and CVE tracking tools to identify vulnerabilities in your deployment. Prioritize based on exploitability and impact.

BCA uses RAUC (Robust Auto Update Client) for update delivery and verification. RAUC uses a manifest file and asymmetric cryptographic signatures to sign updates, ensuring only authorized packages are installed. See Update Management for RAUC workflows, packaging, and patching strategies. For more on RAUC architecture and configuration options, refer to the RAUC documentation.

Security Boundaries

Boundary 1: ARM TrustZone (Normal World ↔ Secure World)

The ARM TrustZone boundary separates normal world (Bunker OS, Open World) from secure world (OP-TEE). Only OP-TEE code runs in secure world; no userspace or Open World code can execute there. Transitions between worlds are controlled through Secure Monitor Calls (SMCs), which are validated by firmware and mediated by CLARE-Hypervisor.

Boundary 2: Hypervisor (Bunker OS ↔ Open World)

The hypervisor enforces strict isolation between VMs through multiple mechanisms including spatial isolation (address space separation via hardware MMU) and temporal isolation (scheduling and resource allocation). Open World cannot read, write, or execute Bunker OS memory. All device access is controlled by hypervisor configuration: security-critical devices (cryptographic engines, tamper monitors, secure storage) are assigned to Bunker OS; non-sensitive devices are assigned to Open World and may be accessed via passthrough or virtualization (e.g., virtio-blk for storage, virtio-net for network) depending on configuration.

Boundary 3: RPC Schema (Bunker OS ↔ Open World)

All inter-domain communication flows through RPC. In the reference design, Bunker OS services validate caller identity, operation, and parameters before executing; invalid requests are rejected and logged as security events. Custom services implemented in Bunker OS should follow the same validation patterns, though the specific implementation depends on how each service is built.

Where to Go Next