# Hardware Root of Trust & Silicon Lock

Bauxite is designed to move security from the software layer down to the physical silicon. By binding node identities to hardware security modules, Bauxite ensures that node cloning is mathematically impossible and that the "blast radius" of a compromised OS is strictly limited.

## Silicon Lock: Current Implementation

The Silicon Lock feature is controlled by the `silicon-lock` feature flag in `bauxite`. The current implementation uses environment-variable-based attestation:

- **`BAUXITE_MOCK_HARDWARE_ATTESTATION`**: When set, the `SoftwareSigner` returns mock attestation data via `get_attestation()`, simulating a hardware-backed identity.
- **`BAUXITE_TAMPERED_BOOT`**: When set, `verify_pcr_measurements()` (called during Hub connection via `HubConnector`) returns a `TPM_PCR_TAMPER_DETECTED` error, simulating a tampered boot state.

### Planned Hardware Integrations

The following integrations are defined in the protocol specifications (`bauxite-proto`) but require platform-specific implementation:

- **TPM 2.0 (Linux/x86)**: Generate and store the node's private signing key in the Trusted Platform Module. The key never leaves the TPM's protected memory.
- **Strongbox / TEE (Android)**: Bind keys to the hardware-backed Strongbox Keymaster on mobile edge devices.
- **Secure Enclave (iOS)**: Hardware-bound key storage for Apple devices.

### Advantages of Silicon Lock:
- **Anti-Spoofing**: Even if an attacker gains root access to the device's filesystem, they cannot extract the private keys to clone the node onto another machine.
- **Hardware Attestation**: During the join process, the node provides an attestation report to the Hub. The Hub verifies this report to ensure the device has booted a **trusted** kernel and hasn't been tampered with.

## Software-Backed Fallback

For devices without a functional hardware root of trust, Bauxite provides software-backed Ed25519/X25519 key generation via `SoftwareSigner` (`identity.rs`).

### How it works:
1. **Key Generation**: The `SoftwareSigner` generates Ed25519 (signing) and X25519 (key exchange) keypairs using `ed25519-dalek` and `x25519-dalek` crates.
2. **Passphrase Protection** (optional): When compiled with the `software-passphrase` feature, keys can be encrypted at rest using a passphrase hashed via **blake3** (`BAUXITE_KEY_PASSPHRASE` env var).
3. **CSR Generation**: The node generates a Certificate Signing Request (CSR) and sends it to the Hub for mTLS certificate issuance, keeping the private key local.

### RBAC Sandbox (Implemented)

The `DataPlaneScheduler::check_rbac_sandbox()` actively enforces tier restrictions on software-identity nodes:

- **Software nodes** (`is_hardware == false`) are **blocked** from sending:
  - Critical-tier traffic (ICMP, small packets < 100 bytes)
  - Traffic to ports 5004 and 7412 (designated high-value ports)
- **Hardware-bound nodes** (`is_hardware == true`) have full access to all tiers and ports.

This check is enforced in `dispatch_loop()` (`scheduler.rs:279`) and wired via `BauxiteNode` (`mod.rs:452`) using `identity.signer.is_hardware()`.