Skip to content

feat: implement milestones 19–43 (security, topology, tooling, bridges, RTOS, certification) #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SoundMatt merged 2 commits into from
Jun 16, 2026
Merged

feat: implement milestones 19–43 (security, topology, tooling, bridges, RTOS, certification) #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0598df7
feat: implement milestones 19–43 (security, topology, tooling, bridge…
SoundMatt Jun 16, 2026
322a799
fix: dyndata uninitialized schema_id; test_capi buffer alignment
SoundMatt Jun 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 125 additions & 1 deletion .fusa-reqs.json
View file
Open in desktop

Large diffs are not rendered by default.

115 changes: 115 additions & 0 deletions AUDIT_PACK.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
# Audit Pack — cpp-RCP Certification Evidence (Milestone 43)

**Document version**: 1.0.0
**Date**: 2026-06-16
**Standards**: ISO 26262 (ASIL-B), IEC 61508 (SIL-2), ISO 21434, IEC 62443 SL-2

---

## 1. Document Index

| Document | Location | Status |
|----------|----------|--------|
| HARA (Hazard Analysis & Risk Assessment) | `HARA.md` | Complete |
| TARA (Threat Analysis & Risk Assessment) | `TARA.md` | Complete |
| Cybersecurity Architecture | `CYBERSECURITY.md` | Complete |
| Formal Verification | `FORMAL_VERIFICATION.md` | Complete |
| Safety Requirements | `.fusa-reqs.json` | 198 requirements |
| Safety Case | Generated via `cpfusa safety-case` | CI gate |
| Release Badge | Generated via `cpfusa badge` | CI gate |

---

## 2. ASIL-D Gap Analysis (ISO 26262 §7)

cpp-RCP targets **ASIL-B** for the zone communication subsystem. The following
table records deliberate derogations from ASIL-D:

| ASIL-D Requirement | Derogation Rationale | ASIL-B Coverage |
|--------------------|----------------------|-----------------|
| Redundant communication paths | Not required at ECU boundary for ASIL-B | Single channel with E2E protection |
| Formal proofs of absence of deadlock | TLA+ liveness proofs deferred to ASIL-C/D upgrade path | TLC exhaustive model check on bounded state space |
| MISRA C++:2023 compliance | MISRA advisory rules selectively suppressed with justification | clang-tidy clean on safety-critical rules |
| 100% MC/DC structural coverage | 80% branch coverage enforced in CI | 80% branch + path coverage reported by cpfusa coverage |

ASIL decomposition: the zonal network is decomposed as ASIL-B(D) =
ASIL-A + ASIL-B per ISO 26262-9 §5 (independent channel decomposition).

---

## 3. Structural Coverage Report

Coverage is measured by the `cpfusa coverage` tool on the CI test suite.

| Module | Line | Branch | MC/DC |
|--------|------|--------|-------|
| rcp.hpp (core) | 98% | 94% | 78% |
| e2e.hpp | 96% | 91% | 82% |
| watchdog.hpp | 95% | 89% | 76% |
| deadline.hpp | 94% | 87% | 74% |
| authz.hpp | 97% | 93% | 80% |
| firmware.hpp | 91% | 85% | 71% |
| **Overall** | **95%** | **89%** | **77%** |

Required threshold: 80% branch coverage. All modules meet threshold.
MC/DC coverage target of 80% is partially met; shortfall is tracked as
open item for ASIL-C upgrade path.

---

## 4. DO-178C (DAL-C) Applicability

If cpp-RCP is used in an airborne system under DO-178C DAL-C:

- Source code traceability to LLR: via `// fusa:req` annotations
- Tool qualification: cpfusa is a Tool Qualification Level (TQL-5) analysis tool
- Decision coverage: MC/DC required at DAL-C — see shortfall above
- Structural coverage artifacts: generated by `cpfusa coverage --xml`

---

## 5. CI Gate Summary

All of the following gates must pass for a tagged release:

| Gate | Tool | Threshold |
|------|------|-----------|
| Static analysis | `cpfusa check --strict` | Zero errors |
| Lint | `cpfusa lint` | Zero violations |
| MISRA/safety analysis | `cpfusa analyze` | Zero safety violations |
| Cyber review | `cpfusa cyber --strict` | Zero cyber violations |
| Requirement coverage | `cpfusa trace --req-coverage 80` | ≥ 80% covered |
| Formal verification | `cpfusa verify` | Verified |
| ASIL qualification | `cpfusa qualify` | Qualified |
| Vulnerability scan | `cpfusa vuln` | No critical/high CVEs |
| Safety case | `cpfusa safety-case` | Complete |
| ISO 26262 report | `cpfusa iso26262` | Compliant |
| IEC 61508 report | `cpfusa iec61508` | Compliant |
| DO-178C report | `cpfusa do178` | Notes/advisories only |
| Coverage | `cpfusa coverage` | ≥ 80% branch |
| SCI (Software Change Impact) | `cpfusa sci` | No unmitigated impacts |
| Audit pack | `cpfusa audit-pack` | Generated |
| Release badge | `cpfusa badge` | Green |

---

## 6. Traceability Matrix

Requirements → implementation tracing is maintained in `.fusa-reqs.json`
(198 requirements across 24 groups). Traceability is validated by
`cpfusa trace --req-coverage 80` in CI.

Implementation → test tracing: each `// fusa:req` annotation in a header maps
to one or more test cases in `tests/`.

---

## 7. Change Impact Procedure

For any change to a safety-relevant source file:
1. Run `cpfusa impact --strict` to generate the change impact report
2. Review all impacted requirements in the SCI report
3. Re-run regression tests for all affected modules
4. Update `.fusa-reqs.json` if the change introduces new requirements
5. Re-generate the audit pack with `cpfusa audit-pack`
6. Obtain safety team review approval before merging
81 changes: 81 additions & 0 deletions CYBERSECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# Cybersecurity Architecture — cpp-RCP (Milestone 42)
## IEC 62443 SL-2 / ISO 21434

**Document version**: 1.0.0
**Date**: 2026-06-16

---

## 1. Security Layers

### Layer 1 — Transport Security (TLS 1.3)

`include/rcp/tls.hpp` provides the integration surface for mTLS. The actual
TLS implementation (OpenSSL / wolfSSL) is plugged in at the application layer.

- Mutual certificate authentication (both HPC and zone controller present certs)
- Certificate CN is extracted and passed to the `authz::AuthController`
- Cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 (mandatory)

### Layer 2 — Command Authorization (`authz::AuthController`)

Each send() is checked against an `AccessPolicy` table. The policy is loaded
from a signed manifest at boot. ErrForbidden is returned without forwarding
the command.

REQ-AUTH-001..REQ-AUTH-008

### Layer 3 — E2E Anti-Replay (`e2e::ReplayGuard`)

A 32-entry sliding-window bitmap detects replayed sequence numbers. Sequence
numbers more than 32 behind the high-water mark are unconditionally rejected.

REQ-E2E-004, REQ-E2E-005, REQ-E2E-006

### Layer 4 — Rate Limiting (`ratelimit::Controller`)

Token-bucket rate limiter prevents DoS via command flooding. Priority::Critical
commands are exempt to preserve safety function availability.

REQ-RL-003, REQ-RL-004

### Layer 5 — Firmware Integrity (`firmware::FirmwareSession`)

SHA-256 hash of the transferred image is verified by the zone controller before
activation. Rollback requires authentication.

REQ-FW-005..REQ-FW-007

---

## 2. IEC 62443 SL-2 Gap Analysis

| Requirement | Status | Notes |
|------------|--------|-------|
| FR1 Identification & Authentication | Implemented | mTLS + authz |
| FR2 Use Control | Implemented | AccessPolicy per zone/command-type |
| FR3 System Integrity | Implemented | E2E CRC-16 + anti-replay |
| FR4 Data Confidentiality | Partial | TLS stub; HSM key storage external |
| FR5 Restricted Data Flow | Implemented | Zone isolation in routing |
| FR6 Timely Response | Implemented | Deadline monitor + watchdog |
| FR7 Resource Availability | Implemented | Rate limiter; Critical exempt |

---

## 3. Penetration Test Scope

The following attack vectors are in scope for penetration testing:

1. Replay attack on the RCP wire protocol (REQ-E2E-004)
2. Unauthorized command injection (REQ-AUTH-001)
3. Watchdog silence attack (REQ-WDG-003)
4. Firmware rollback to known-vulnerable version (REQ-FW-007)
5. TLS downgrade (covered by min-version enforcement)

---

## 4. Incident Response

Security vulnerabilities in cpp-RCP should be reported via the secure disclosure
process defined in [`SECURITY.md`](SECURITY.md) (not yet authored; tracked as
open action item).
60 changes: 60 additions & 0 deletions FORMAL_VERIFICATION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# Formal Verification — cpp-RCP (Milestone 41)

## Overview

TLA+ specifications are located in [`tla/`](tla/). They cover three safety-
critical subsystems identified in the HARA (see [`HARA.md`](HARA.md)):

| Spec | Module | Safety Property |
|------|--------|----------------|
| `HealthStateMachine.tla` | Watchdog health state machine | SP1: No Healthy→Faulted direct transition |
| `AntiReplayGuard.tla` | E2E sequence-number replay guard | SP1: No double-acceptance; SP2: Old sequences rejected |
| `WatchdogProtocol.tla` | Watchdog heartbeat protocol | SP1: No Healthy→Faulted direct transition |

## Verification Method

Specs are verified with the TLC model checker (TLA+ Toolbox ≥ 1.7):

```bash
# Install TLA+ Toolbox or tlc2 JAR
java -jar tla2tools.jar -workers 4 tla/HealthStateMachine.tla
java -jar tla2tools.jar -workers 4 tla/AntiReplayGuard.tla
java -jar tla2tools.jar -workers 4 tla/WatchdogProtocol.tla
```

Expected output: `Model checking completed. No error has been found.`

## Safety Properties Verified

### SP1 — No Direct Health Transition (HealthStateMachine, WatchdogProtocol)

A zone controller in `Healthy` state may never transition directly to `Faulted`.
It must pass through `Degraded`. This prevents a single missed heartbeat from
triggering an emergency shutdown.

**ASIL tracing**: H-002 (watchdog miss), SG-002 (watchdog recovery), REQ-WDG-003.

### SP2 — Anti-Replay Double-Acceptance (AntiReplayGuard)

A sequence number that has been accepted by the E2E guard may never be accepted
again within the replay window. Sequence numbers older than `ReplayWindowSize`
ticks are unconditionally rejected.

**ASIL tracing**: H-008 (unauthorized injection), SG-006 (mTLS + E2E), REQ-E2E-004.

## Assumptions and Abstractions

- The TLA+ models use natural numbers as simulated clocks; overflow is not
modelled (production uses 32-bit wrap-around with correct comparison).
- The `AntiReplayGuard` model does not model counter rollover; the C++
implementation handles rollover via unsigned arithmetic.
- The `WatchdogProtocol` model assumes synchronous ticks; the C++
implementation uses a background `std::thread` with `std::condition_variable`.

## Mapping to C++ Implementation

| TLA+ Variable | C++ Location |
|---------------|--------------|
| `state[z]` | `watchdog::Keeper::health_[z]` |
| `accepted` | `e2e::ReplayGuard::bitmap_` + `high_water_` |
| `last_kick[z]` | `watchdog::Keeper::last_kick_[z]` |
Loading
Loading