# How RuView Configures QUIC Mesh Security for Tamper Detection and Replay Protection

> Discover how RuView configures QUIC mesh security using TLS 1.3 and HMAC-SHA256 with nonce windows for tamper detection and replay protection. Secure your Wi-Fi mesh network effectively.

- Repository: [rUv/RuView](https://github.com/ruvnet/RuView)
- Tags: how-to-guide
- Published: 2026-03-08

---

**RuView secures its multistatic Wi-Fi mesh through a dual-mode architecture that combines TLS 1.3-encrypted QUIC transport for high-security environments with manual HMAC-SHA256 authentication for resource-constrained devices, implementing explicit replay protection via a 16-slot nonce window in manual mode.**

RuView is an open-source multistatic Wi-Fi sensing framework that implements robust **QUIC mesh security** to protect beacon transmissions across heterogeneous ESP32 hardware. The system provides developers with configurable cryptographic modes that ensure both tamper detection and replay protection while adapting to varying computational constraints.

## QUIC Mesh Security Architecture Overview

RuView's security layer operates through two distinct modes defined in the `SecurityMode` enum located in [`quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/quic_transport.rs) (lines 44-52). The **QuicTransport** mode leverages native TLS 1.3 encryption provided by the QUIC protocol, while **ManualCrypto** mode implements custom HMAC-SHA256 verification with explicit nonce management for devices where QUIC overhead is prohibitive. Both modes integrate with the `SecureTdmCoordinator` in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 53-57) to enforce consistent security policies across the mesh.

## Tamper Detection in QUIC Mesh Networks

### TLS 1.3 Mode (QUIC Transport)

When operating in QUIC mode, RuView wraps every `MessageType::Beacon` payload within a TLS 1.3-protected stream. The QUIC transport implementation in [`quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/quic_transport.rs) (lines 49-51) automatically provides confidentiality, integrity, and authentication through the TLS layer's built-in AEAD encryption. Any modification to the encrypted beacon payload is detected immediately upon receipt, triggering standard TLS error handling without requiring application-layer intervention.

### Manual Crypto Mode (HMAC-SHA256)

For resource-constrained environments, RuView extends the standard 16-byte beacon to a 28-byte **AuthenticatedBeacon** format defined in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 56-64). This format includes:

- A unique nonce (8 bytes)
- An HMAC-SHA256 tag truncated to 8 bytes

The HMAC is computed using a pre-shared 16-byte mesh key configured in `SecureTdmConfig`. The `verify_beacon` function (lines 28-44) validates the tag against the received payload, rejecting any beacon exhibiting bit-level alterations. Verification failures increment a dedicated counter accessible via `verification_failures()` (lines 43-45).

## Replay Protection Mechanisms

### Implicit Protection via QUIC Streams

In QUIC transport mode, replay protection is handled implicitly by the underlying TLS 1.3 implementation. As noted in [`quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/quic_transport.rs) (line 49), QUIC automatically discards out-of-order or duplicated packets during the handshake and stream processing phases. This eliminates replay attacks without requiring explicit nonce tracking at the application layer, leveraging the protocol's built-in sequence number verification and anti-replay window.

### Explicit Nonce Tracking with ReplayWindow

When operating in manual crypto mode, RuView implements explicit replay protection through the `ReplayWindow` struct defined in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 27-35). This sliding window mechanism maintains:

- The highest accepted nonce value
- A configurable history window of 16 recent nonces (`REPLAY_WINDOW = 16`)

The verification process follows a strict sequence: `ReplayWindow::check` validates nonce freshness against the window, and `ReplayWindow::accept` updates the window state only for valid, non-replayed beacons. Any duplicate or stale nonce triggers immediate rejection and increments the `verification_failures` counter, preventing adversaries from retransmitting captured beacon frames.

## Configuring QUIC Mesh Security in RuView

Developers configure security modes through the `SecureTdmConfig` structure located in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 84-95). The configuration requires specifying a `SecurityMode` variant and providing corresponding transport parameters.

### Enabling QUIC Transport Mode

To activate TLS 1.3-secured mesh communications, instantiate the coordinator with `SecurityMode::QuicTransport`:

```rust
use wifi_densepose_hardware::esp32::{
    quic_transport::{QuicTransportConfig, SecurityMode},
    secure_tdm::{SecureTdmConfig, SecureTdmCoordinator},
};

// Default config already selects QUIC + TLS 1.3
let cfg = SecureTdmConfig::default(); // security_mode = QuicTransport

// Optionally tweak QUIC parameters
let mut quic_cfg = QuicTransportConfig::default();
quic_cfg.bind_addr = "0.0.0.0:4433".to_string();
quic_cfg.handshake_timeout_ms = 200;

// Apply the custom QUIC config
let cfg = SecureTdmConfig {
    security_mode: SecurityMode::QuicTransport,
    quic_config: quic_cfg,
    ..SecureTdmConfig::default()
};

let coordinator = SecureTdmCoordinator::new(schedule, cfg)
    .expect("Failed to initialize QUIC mesh security");

```

This configuration creates a `QuicTransportHandle` within `SecureTdmCoordinator::new` (lines 53-57), establishing TLS 1.3 encryption for all beacon transmissions.

### Switching to Manual Crypto Mode

For environments where QUIC overhead is prohibitive, configure manual HMAC verification with explicit replay protection:

```rust
use wifi_densepose_hardware::esp32::{
    quic_transport::SecurityMode,
    secure_tdm::{SecureTdmConfig, SecLevel, SecureTdmCoordinator},
};

// Pre-shared 16-byte mesh key
let mesh_key: [u8; 16] = [
    0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
    0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10
];

let security_cfg = SecureTdmConfig {
    security_mode: SecurityMode::ManualCrypto,
    mesh_key: Some(mesh_key),
    sec_level: SecLevel::Enforcing, // Reject unauthenticated beacons
    ..SecureTdmConfig::default()
};

let coordinator = SecureTdmCoordinator::new(schedule, security_cfg).unwrap();

```

When a beacon arrives, the coordinator runs:

```rust
match coordinator.verify_beacon(&incoming) {
    Ok(beacon) => { /* accepted, nonce recorded in ReplayWindow */ }
    Err(e) => { /* HMAC failure or replay detected */ }
}

```

The `ReplayWindow` (size = `REPLAY_WINDOW = 16`) guarantees that any nonce older than the window or a duplicate is rejected.

## Monitoring Security Events

RuView exposes security metrics through transport statistics and verification counters. Access these via the coordinator's API:

```rust
// Access QUIC transport statistics
if let Some(transport) = coordinator.transport() {
    let stats = transport.stats();
    println!("Beacons sent: {}", stats.beacons_sent);
    println!("Beacons received: {}", stats.beacons_received);
    println!("Bytes encrypted: {}", stats.tx_bytes);
}

// Check manual crypto verification failures
let failures = coordinator.verification_failures();
println!("Tamper/replay rejections: {}", failures);

```

The `TransportStats` struct in [`quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/quic_transport.rs) (lines 2-19) tracks beacon transmission metrics, while `verification_failures()` (lines 43-45 in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs)) counts HMAC validation errors and replay rejections in manual mode.

## Key Source Files

| File | Purpose | Critical Components |
|------|---------|---------------------|
| [`rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/quic_transport.rs) | Implements the QUIC transport layer, TLS 1.3 configuration, and transport statistics | `SecurityMode` enum (L44-52) • `QuicTransportConfig` • `TransportStats` (L2-19) • TLS replay protection (L49) |
| [`rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/secure_tdm.rs) | Wraps the TDM coordinator with security; selects QUIC or manual crypto, performs HMAC verification and replay checks | `SecureTdmConfig` (L84-95) • `ReplayWindow` (L27-35) • `verify_beacon` (L28-44) • `verification_failures` (L43-45) • `AuthenticatedBeacon` format (L56-64) |
| [`rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/tdm.rs`](https://github.com/ruvnet/RuView/blob/main/rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/tdm.rs) | Defines core TDM scheduling and beacon serialization | `SyncBeacon` structure • `to_bytes` / `from_bytes` serialization (consumed by security layer) |

## Summary

- RuView implements **QUIC mesh security** through dual-mode architecture supporting both TLS 1.3-encrypted QUIC transport and manual HMAC-SHA256 authentication.
- **Tamper detection** relies on TLS 1.3 AEAD encryption in QUIC mode, or truncated 8-byte HMAC-SHA256 tags in manual mode, with verification implemented in `verify_beacon` ([`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) lines 28-44).
- **Replay protection** is implicit in QUIC mode through TLS sequence numbers, while manual mode uses a 16-slot `ReplayWindow` ([`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) lines 27-35) to track nonces and reject duplicates.
- Configuration occurs through `SecureTdmConfig` ([`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) lines 84-95) via the `SecurityMode` enum ([`quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/quic_transport.rs) lines 44-52), selecting between `QuicTransport` and `ManualCrypto` modes.
- Security metrics are accessible through `TransportStats` for QUIC mode and `verification_failures()` for manual mode, enabling runtime monitoring of tampering and replay attempts.

## Frequently Asked Questions

### What is the difference between QUIC mode and Manual Crypto mode in RuView?

**QUIC mode** leverages native TLS 1.3 encryption provided by the QUIC protocol, offering built-in confidentiality, integrity, and replay protection through the transport layer's AEAD ciphers and sequence number tracking. **Manual Crypto mode** implements custom HMAC-SHA256 authentication with an 8-byte truncated tag and explicit nonce tracking via the `ReplayWindow` struct for ESP32 devices where QUIC overhead is prohibitive, requiring application-layer verification in `verify_beacon`.

### How does RuView prevent replay attacks in manual crypto mode?

In manual crypto mode, RuView prevents replay attacks through the `ReplayWindow` struct defined in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 27-35), which maintains a sliding window of 16 recently accepted nonces. When a beacon arrives, the `check` method validates that the nonce is greater than the highest accepted value or falls within the valid window range, while `accept` updates the window state; duplicate or stale nonces trigger immediate rejection and increment the `verification_failures` counter.

### Where is the mesh security mode configured in the RuView codebase?

The mesh security mode is configured through the `SecureTdmConfig` structure in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 84-95), which contains a `security_mode` field accepting variants from the `SecurityMode` enum defined in [`quic_transport.rs`](https://github.com/ruvnet/RuView/blob/main/quic_transport.rs) (lines 44-52). Developers instantiate `SecureTdmCoordinator::new(schedule, config)` to activate either `SecurityMode::QuicTransport` for TLS 1.3 encryption or `SecurityMode::ManualCrypto` for HMAC-based authentication, with the coordinator internally creating the appropriate transport handle or crypto verifier based on the selected variant.

### What cryptographic primitives does RuView use for tamper detection?

RuView employs **AES-GCM** via TLS 1.3 in QUIC mode, providing authenticated encryption with associated data (AEAD) that detects any bit-level modification of beacon payloads through the TLS layer's built-in MAC. In manual crypto mode, the system uses **HMAC-SHA256** truncated to 8 bytes, computed over the beacon payload using a pre-shared 16-byte mesh key and verified in [`secure_tdm.rs`](https://github.com/ruvnet/RuView/blob/main/secure_tdm.rs) (lines 28-44), with verification failures indicating tampering attempts.