Metadata-Version: 2.4
Name: tibet-edge
Version: 0.1.1
Summary: IoT Firmware Sealer — full provenance chain verification for firmware updates on edge devices
Project-URL: Homepage, https://humotica.com
Project-URL: Repository, https://github.com/jaspertvdm/tibet-edge
Project-URL: Documentation, https://humotica.com/docs/tibet-edge
Project-URL: Bug Tracker, https://github.com/jaspertvdm/tibet-edge/issues
Project-URL: TIBET Protocol, https://pypi.org/project/tibet-core/
Project-URL: IETF TIBET Draft, https://datatracker.ietf.org/doc/draft-vandemeent-tibet-provenance/
Author-email: "J. van de Meent" <jasper@humotica.com>, "R. AI" <root_idd@humotica.nl>
Maintainer-email: Humotica AI Lab <ai@humotica.nl>
License: MIT
License-File: LICENSE
Keywords: automotive,edge,firmware,iot,ota,provenance,supply-chain,tibet
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Manufacturing
Classifier: License :: OSI Approved :: MIT License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Topic :: Security
Classifier: Topic :: System :: Hardware
Requires-Python: >=3.10
Requires-Dist: jis-core>=0.4.0b1
Requires-Dist: tibet-core>=0.2.0
Provides-Extra: dev
Requires-Dist: pytest>=7.0; extra == 'dev'
Requires-Dist: ruff>=0.1.0; extra == 'dev'
Provides-Extra: full
Requires-Dist: rich>=13.0.0; extra == 'full'
Description-Content-Type: text/markdown

# tibet-edge — IoT Firmware Sealer

> Not just hash verification. **Full provenance chain** for firmware updates.
>
> Who built it, from what source, on what build server, why this version.

**tibet-edge** seals firmware images with a complete [TIBET](https://pypi.org/project/tibet-core/) provenance chain covering every step from developer to device. A missing step means a rejected update. No exceptions.

## The Problem: Hashes Are Not Enough

Everyone verifies firmware hashes. But a hash only proves "the binary hasn't changed." It doesn't prove:

- **Who** compiled it (intern or senior engineer?)
- **What** source code it came from (which git commit?)
- **Where** it was built (CI server or compromised laptop?)
- **Why** this version exists (security patch or backdoor?)

A supply chain attacker who compromises the build server produces a binary with a **perfectly valid hash** — of the wrong firmware.

## The Firmware Envelope

```
┌─────────────────────────────────────────────────────────────────────┐
│                     FIRMWARE ENVELOPE                               │
│                                                                     │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ FIRMWARE BINARY                                                │ │
│  │ SHA-256: a1b2c3...  Size: 2.4MB  Version: 3.1.7              │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                     │
│  ┌─ BUILD CHAIN (every step = TIBET token) ─────────────────────┐  │
│  │                                                               │  │
│  │  [1] commit    dev@company    git:abc123    → src_hash       │  │
│  │       │                                                       │  │
│  │  [2] compile   ci-server-04   GCC 13.2      → obj_hash      │  │
│  │       │                                                       │  │
│  │  [3] test      ci-server-04   pytest 8.1    → test_hash     │  │
│  │       │                                                       │  │
│  │  [4] sign      hsm-prod-01   ECDSA P-256    → sig_hash      │  │
│  │       │                                                       │  │
│  │  [5] package   ci-server-04   fwtools 2.0   → pkg_hash      │  │
│  │       │                                                       │  │
│  │  [6] release   release-mgr    approved       → rel_hash      │  │
│  │                                                               │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  Missing step? → REJECT UPDATE                                      │
│  Broken chain? → REJECT UPDATE                                      │
│  Unknown actor? → REJECT UPDATE                                     │
│                                                                     │
│  TIBET Token: jis:fw:envelope:a1b2c3d4                              │
│  Sealed by:  jis:ci:build-pipeline-prod                             │
│  Sealed at:  2026-02-27T14:00:00Z                                   │
└─────────────────────────────────────────────────────────────────────┘
```

## Install

```bash
pip install tibet-edge
```

## Quick Start

```python
from tibet_edge import FirmwareSealer, BuildStep

sealer = FirmwareSealer(actor="ci-pipeline-prod")

# Record each build step
sealer.add_build_step(BuildStep(
    name="compile",
    actor="ci-server-04",
    input_hash="abc123...",
    output_hash="def456...",
    tool="GCC 13.2",
    environment="Ubuntu 24.04",
))

# Seal the firmware
envelope = sealer.seal(
    firmware_path="firmware-v3.1.7.bin",
    version="3.1.7",
    metadata={"reason": "Security patch CVE-2026-1234"},
)

# Verify: every step present, hashes match, chain unbroken
result = sealer.verify(envelope)
print(result.valid)           # True
print(result.steps_verified)  # 6
print(result.missing_steps)   # []
```

### CLI

```bash
tibet-edge info           # Concept overview
tibet-edge demo           # Full demo: seal, verify, tamper detection
tibet-edge profiles       # Sector profiles (automotive, medical, etc.)
tibet-edge seal fw.bin    # Seal a firmware file (demo mode if no file)
tibet-edge verify env.json  # Verify a firmware envelope
```

## Use Cases

| Sector | Threat | tibet-edge Response |
|--------|--------|-------------------|
| **Automotive OTA** (Tesla, VW) | Tampered ECU firmware via OTA | Full build chain from git to ECU, dual-sign required |
| **Medical Devices** (insulin pumps) | Unauthorized firmware modification | FDA-compliant provenance, clinical trial reference |
| **Consumer IoT** (cameras, routers) | Mirai-style botnet injection | Minimum viable provenance, rejects unsigned builds |
| **Industrial SCADA** | Stuxnet-style PLC manipulation | OT-specific fields, air-gap compatible verification |

## Sector Profiles

```bash
tibet-edge profiles
```

| Profile | Required Steps | Min Trust | Dual Sign | Max Age |
|---------|---------------|-----------|-----------|---------|
| `automotive` | commit, compile, test, sign, package, release | 0.95 | Yes | 90 days |
| `medical` | commit, compile, test, clinical_review, sign, fda_submit, release | 0.99 | Yes | 365 days |
| `industrial` | commit, compile, test, sign, release | 0.90 | No | 180 days |
| `consumer_iot` | compile, sign, release | 0.70 | No | 30 days |

## EU Cyber Resilience Act (CRA) Compliance

tibet-edge's firmware envelope provides the technical evidence required by the [EU CRA](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act):

- **Article 10(6)**: Identify and document vulnerabilities — ERACHTER layer records CVE references and patch intent
- **Article 10(9)**: Security updates with provenance — the envelope IS the provenance
- **Article 10(10)**: SBOM compatibility — build chain maps to SBOM components

## TIBET Provenance Layers

| Layer | Firmware Content |
|-------|-----------------|
| **ERIN** | Firmware version, hash, size |
| **ERAAN** | Build chain steps, git commit, parent envelope |
| **EROMHEEN** | Build server, compiler, OS, hardware |
| **ERACHTER** | "Security patch CVE-xxxx", release intent |

## Target Implementations

- **Python** — Reference implementation (this package)
- **C** — Embedded library for constrained devices (planned)
- **Rust** — Safety-critical embedded systems (planned)

## Part of the TIBET Ecosystem

| Package | Purpose |
|---------|---------|
| [`tibet-core`](https://pypi.org/project/tibet-core/) | Protocol core |
| [`tibet-y2k38`](https://pypi.org/project/tibet-y2k38/) | Y2K38 Time Bridge |
| [`tibet-pol`](https://pypi.org/project/tibet-pol/) | Process Integrity Checker |
| [`tibet-pqc`](https://pypi.org/project/tibet-pqc/) | Post-Quantum Crypto Router |
| [`tibet-overlay`](https://pypi.org/project/tibet-overlay/) | Identity Overlay |
| [`tibet-twin`](https://pypi.org/project/tibet-twin/) | Digital Twin Guard |
| **tibet-edge** | IoT Firmware Sealer |

## License

MIT — Humotica / J. van de Meent 2025

## Authors

- **J. van de Meent** — jasper@humotica.com
- **R. AI (Root AI)** — root_idd@humotica.nl


## Credits

Designed by [Jasper van de Meent](https://github.com/jaspertvdm). Built by Jasper and [Root AI](https://humotica.com) as part of [HumoticaOS](https://humotica.com).

---

**Stack-positie:** Groep `agentic` · Bootstrap = OSAPI-handshake naar [`tibet`](https://pypi.org/project/tibet-core/) + [`jis`](https://pypi.org/project/jis-core/) (fail → snaft-rule + tibet-pol-rapport) · ← [`tibet-iot`](https://pypi.org/project/tibet-iot/) · [`tibet-mesh`](https://pypi.org/project/tibet-mesh/) → · See `STACK.md` · See `demo/golden-path/` for the spine end-to-end.
---

## Enterprise

For private hub hosting, SLA support, custom integrations, or compliance guidance:

| | |
|---|---|
| **Enterprise** | enterprise@humotica.com |
| **Support** | support@humotica.com |
| **Security** | security@humotica.com |

See [ENTERPRISE.md](ENTERPRISE.md) for details.
