C.A.P. System Architecture
The C.A.P. (Catch A Predator) platform is a hardware-based child safety appliance operating at the network infrastructure layer. Unlike device-level parental controls, C.A.P. inspects all traffic traversing the home network regardless of endpoint, making it resistant to child-initiated bypass and invisible to the devices being monitored.
Dual gigabit Ethernet interfaces operate in transparent bridge mode. Traffic is mirrored to the detection pipeline in parallel with forwarding, minimizing added latency (<1ms target).
A dedicated secure element (TPM 2.0) holds cryptographic keys used for evidence signing and secure boot attestation. The SoC's crypto accelerator handles TLS metadata inspection (SNI extraction, ClientHello fingerprinting) and signature matching at line rate. C.A.P. does not perform TLS interception or payload decryption.
Classifies flows by protocol — HTTPS (via SNI and ClientHello fingerprinting), DNS, HTTP, and protocol identification for messaging and game/voice services where possible.
Maintains per-flow state via connection tracking. Encrypted payloads are not decrypted under any circumstances; banking, health, and financial domains are categorically excluded from any inspection at the protocol level. For inspectable traffic (cleartext only) and for metadata across all flows, the relevant signals are passed to L3.
The heart of the C.A.P. patent claim. Four parallel detectors — signature, behavioral, flow-correlation, and content-classification — feed a unified risk score.
Signatures target known predator-communication patterns (grooming phrases, credential- exfiltration patterns, indicator domains). Behavioral analysis flags timing, contact asymmetry, and platform-hopping indicative of grooming.
Converts detection events into actionable outputs. The risk scorer aggregates signals across time windows; the policy engine applies household-specific rules (age of child, quiet hours, allowed platforms).
When thresholds are crossed, the evidence sealer cryptographically signs the relevant packet captures and metadata, and the alert generator dispatches a parent notification via the secure management channel.
IBR-Tech operates a managed signature-distribution feed (updated continuously from curated threat intelligence, public threat feeds where licensing permits, and the C.A.P. deployed-fleet telemetry).
A tamper-evident evidence vault provides redundant offsite storage of sealed evidence packages. The parent app backend handles push notifications, review, parental acknowledgment, and parent-initiated NCMEC CyberTipline reporting.
PACKET L1→L2 DECODE L2→L3 SCORE L3→L4 SEAL L4→L5 ALERT
Typical detection-to-parent-alert latency: 2–6 seconds under normal load. All pipeline stages are instrumented for observability and auditability.
- Bypass resistance — By operating below the OS layer on every device, C.A.P. cannot be disabled by children through device settings, VPN apps, or browser incognito modes. The only way around it is to take the device off the home network entirely.
- Zero user configuration — Plug between modem and router; device auto-configures bridge mode, auto-discovers devices, and begins monitoring. No router reconfiguration required.
- Privacy-preserving whitelist — Banking, medical, tax, and government domains are categorically excluded from deep inspection at the protocol level, not just the policy level.
- Fail-open by design — C.A.P. is engineered to never become a single point of failure for the household's internet connectivity. A hardware fail-open relay and an independent watchdog ensure that if the device loses power, hangs, or experiences a firmware fault, traffic continues to flow between the modem and router unimpeded. See the Failsafe Subsystem section below.
- Offline-capable — Core detection and alerting continue functioning during cloud connectivity loss. Evidence queues locally on encrypted storage until the secure channel is restored.
- Chain-of-custody integrity — Every alert is tied to a cryptographically signed evidence package with timestamped hash chain, TPM-attested device provenance, and tamper-evident sealing suitable for introduction as evidence (see Section 03).
- Firmware integrity — Secure boot is verified by the TPM on every power-on. OTA updates require Ed25519 signature verification from the IBR-Tech signing authority.
An inline network appliance carries an inherent risk: if the appliance fails, every downstream device loses internet connectivity. A child-safety product that takes a household offline is a worse outcome than one that briefly stops monitoring. C.A.P.'s failsafe subsystem ensures the device cannot become a single point of failure for household connectivity.
A normally-closed bypass relay is wired in parallel with C.A.P.'s inline data path. During healthy operation, the relay is held open by an active control signal from the SoC — traffic flows through C.A.P.'s inspection pipeline as designed.
If the SoC's control signal drops for any reason (loss of DC power, firmware panic, watchdog reset, deliberate user-initiated bypass), the relay closes within milliseconds and creates a direct copper bypass between the WAN and LAN ports. The household's internet connection continues to function, with C.A.P. transparently out of the path.
The relay is electromechanical, requires no firmware to operate in its bypass state, and defaults to bypass-closed at power-up until the SoC explicitly takes inspection control.
A discrete watchdog timer runs on its own clock domain, independent of the SoC. The firmware must service the watchdog at fixed intervals; if it fails to do so (kernel hang, driver fault, firmware loop), the watchdog asserts a reset signal that both reboots the SoC and drops the relay control signal — engaging the fail-open bypass.
The watchdog is socketed into the BOM as a hardware element, not a firmware feature, so a firmware compromise cannot disable it.
A dedicated front-panel LED reflects the failsafe state: steady cyan = healthy and inspecting; amber = degraded but inspecting; red = bypass engaged, traffic uninspected. The parent mobile application also receives a push notification within seconds of any fail-open event so the household is aware inspection is not currently active.
Bypass events are logged locally and reported to the IBR-Tech management cloud for fleet-level reliability monitoring.
A physical pair button on the device, held for five seconds, triggers a deliberate fail-open bypass. This is for households who want to temporarily take C.A.P. out of the path (e.g., for diagnosing an unrelated network issue) without unplugging cables. The parent app surfaces the event in the same way as a fault-driven bypass.
Detection Engine Design
The Detection Engine (L3) is the patent-core innovation of C.A.P. It is a parallel multi-detector system that evaluates every inspectable flow against four independent signals, then fuses those signals into a unified risk score via a weighted ensemble with household-tunable thresholds.
High-throughput multi-pattern string matcher built on the Aho-Corasick algorithm, with SIMD acceleration on supported targets (Vectorscan on ARM, equivalents elsewhere). Matches cleartext-inspectable traffic (HTTP headers, DNS names, unencrypted chat, SNI values) against curated signature sets.
| Attribute | Specification |
|---|---|
| Signature Categories | Grooming language patterns · Credential-phishing patterns targeting minors · Known bad domains · SNI fingerprints of platforms commonly used for predatory contact |
| Signature Source | Curated IBR-Tech threat-intelligence feed · Community-vetted submissions · Public threat feeds where licensing permits |
| Update Cadence | Incremental feed every 15 min · Full roll every 24 h |
| Match Throughput | Up to 1 Gbps aggregate with tuned rule sets on target SoC; benchmarking ongoing |
| Signature Count (target) | ~250,000 rules at GA on current 4 GB hardware; ~750K growth envelope on current platform; 2M+ on next-generation appliance |
| Reporting Pathway | Parent-initiated NCMEC CyberTipline reporting; no vendor-claimed law-enforcement integrations |
| False-Positive Mitigation | Context-scoped rules; no rule fires standalone — always feeds the fusion layer with a confidence weight |
Operates on flow metadata (who talks to whom, when, how often, how much). Grooming has well-documented behavioral fingerprints — rapid escalation of contact frequency from a new contact, off-hours messaging bursts, and platform-hopping from public to private. These signals are heuristic by nature and feed the fusion layer with confidence weights rather than firing alerts independently. Several indicators (off-hours clustering in particular) can be defeated by VPN or cellular use; the fusion model is designed not to depend on any single behavioral signal.
| Indicator | Description |
|---|---|
| Contact Velocity | Sudden rise in message frequency with a new external party relative to baseline |
| Reciprocity Asymmetry | One-sided initiation pattern — adult-initiation dominance |
| Off-Hours Clustering | Disproportionate activity between 22:00–06:00 local; weak signal in isolation, useful in fusion |
| Platform Hopping | Contact initiated on public platform then migrates to private/encrypted channel within 72 h; behavioral heuristic, not deterministic identity correlation |
| Session Duration Spikes | Extended late-night sessions with a single endpoint |
| Model | Gradient-boosted ensemble + rule overlay; runs entirely on-device |
Links flows across platforms that appear, on a behavioral-heuristic basis, to represent the same external adult contact. This addresses the common grooming pattern of moving a child from an initial platform (game chat, public social) to a more private channel.
Correlation is performed on metadata only — temporal proximity, traffic volume correlation, and platform-transition patterns learned from known grooming case studies. No content cross-platform correlation is performed. Cross-platform identity correlation under encryption is an inherent heuristic, not a deterministic identification, and is scored accordingly in the fusion layer.
For inspectable (cleartext) traffic only. Primary workloads are (a) URL and domain reputation matching against publicly available threat-intelligence feeds, and (b) image perceptual-hash comparison against IBR-Tech's curated indicator set of known-bad content fingerprints, where licensing permits.
Each detector outputs a per-event tuple: (category, raw_score ∈ [0,1], confidence ∈ [0,1]). The fusion layer combines them into a single risk score R ∈ [0, 100] with an attached confidence band.
| Detector | Default Weight | Rationale |
|---|---|---|
| Signature Matcher | 0.35 | High precision for known-bad patterns; directly actionable |
| Behavioral Analyzer | 0.30 | Strong grooming-pattern indicator; detects novel cases |
| Flow Correlator | 0.15 | Corroborating signal; low standalone precision |
| Content Classifier | 0.20 | Corroborating signal on URL/domain reputation and image-hash matches against IBR-Tech indicator sets |
Thresholds (default, household-adjustable):
- R < 25 Log only; no parent notification
- 25 ≤ R < 60 Daily digest notification to parent app
- 60 ≤ R < 85 Immediate push alert
- R ≥ 85 Immediate push + evidence seal + optional law-enforcement export flow
Evidence Preservation & Chain-of-Custody
For C.A.P. to meaningfully support law-enforcement action, evidence it preserves must be forensically sound — authenticated at origin, unaltered in transit, time-verifiable, and tamper-evident. This section defines the cryptographic and procedural design for the evidence chain.
Each sealed evidence package is a self-contained archive containing everything required to verify authenticity and integrity independently of the C.A.P. device or IBR-Tech cloud.
| Artifact | Contents |
|---|---|
| pcap.bin | Packet capture of the triggering flow(s), filtered to the event window |
| manifest.json | Detector outputs, risk score, fusion weights, policy state, ruleset version |
| device_attest.json | TPM quote: firmware hash, secure-boot state, device serial, public key fingerprint |
| merkle_root.bin | SHA-256 Merkle root over all artifacts; binds the package |
| device_sig.bin | Ed25519 signature over merkle_root by device's TPM-resident key |
| tsa_token.tsr | RFC 3161 timestamp from an external Trusted Timestamp Authority |
| chain.pem | Full certificate chain from device key → IBR-Tech intermediate CA → root |
- Origin authentication — The device-resident Ed25519 signing key is generated inside the TPM at provisioning and never exits the secure element. Signatures therefore bind each package to the specific C.A.P. unit that produced it.
- Integrity — Merkle-root binding means altering any artifact invalidates the device signature. Downstream systems (parent app, cloud vault, LE portal) verify before accepting.
- Independent time verification — An external RFC 3161 Trusted Timestamp Authority countersigns the merkle root. This establishes "package existed at or before time T" without requiring trust in the device's own clock.
- Tamper evidence — Local storage uses an encrypted write-once partition; the cloud replica uses object-lock (immutable for the retention period). Any attempt to modify or delete is logged and detectable.
- Provenance attestation — Every package includes a TPM quote proving the device was running signed, unmodified IBR-Tech firmware at the moment of capture. This defeats "rogue firmware" defenses in court.
- Privacy-preserving export — Law-enforcement export is strictly parent-initiated. No automatic LE forwarding occurs. NCMEC CyberTipline pathways are available but opt-in per event.
- Verifiable chain — IBR-Tech publishes the intermediate CA public key and revocation list. Independent verifiers (defense counsel, courts, NCMEC) can validate any package without contacting IBR-Tech.
Hardware Block Diagram & BOM
Preliminary hardware architecture for the IBR-CAP reference design. Target form factor is a desktop appliance approximately the size of a paperback book, passive-cooled, plug-and-play. Final component selection is subject to supply-chain, certification, and cost-target review.
| Ref | Component | Role | Example Part |
|---|---|---|---|
| U1 | Application SoC | Main processor, DPI, detection | NXP LS1028A / Rockchip RK3568 class |
| U2, U3 | GbE PHY ×2 | WAN and LAN physical layer | Realtek RTL8211F or Marvell 88E151x |
| U4 | DDR4 SDRAM | Runtime memory | Micron MT40A512M16 · 4 GB |
| U5 | eMMC Flash | OS, ruleset, encrypted log partition | Kingston EMMC32G · 32 GB |
| U6 | TPM 2.0 Secure Element | Evidence-signing keys, boot attest | Infineon SLB 9670 · SPI |
| U7 | PMIC | System power rails | TI TPS65219 or equivalent |
| U8 | RTC + Watchdog | Time, recovery boot | NXP PCF85063 + discrete WDT |
| U9 | Hardware Watchdog (independent) | Detects firmware hang; triggers fail-open + reset | TI TPS3850 or equivalent |
| K1 | Fail-Open Bypass Relay | Bypasses C.A.P. data path on power loss or fault | Bel Fuse 0826 / Pickering 109-1 class signal relay |
| U10 | Relay Driver | Holds bypass relay open during healthy operation | TI ULN2003-class transistor array |
| D1, D2, D3 | Status LEDs | Healthy / degraded / bypass indication | Tri-color front-panel LED stack |
| SW1 | Pair / Bypass Button | Pairing & user-initiated fail-open bypass (5s hold) | C&K KMR2 momentary |
| J1, J2 | RJ45 GbE Jacks | WAN, LAN | Pulse JXD6-0001NL |
| J3 | USB-C | Service port | GCT USB4105 |
| Enclosure | Aluminum / ABS Hybrid | EMI shielding, passive cooling | Custom, Hammond 1455-class |
| PSU | External Wall-Wart | 12V / 2A DC | MeanWell GS24A12 |
Target enclosure 140 × 95 × 30 mm. Passive cooling via aluminum heat-spreader and enclosure venting. Weight target < 400g. Wall-mount and desk-mount variants.
Sealed-case construction with security-screw fasteners; the device is designed for fixed deployment between modem and router and is not intended for end-user disassembly.
Target certifications: FCC Part 15 Class B, UL 62368-1 (safety), CE / UKCA for future export, RoHS 3, California Prop 65 labeling review.
Wireless variant (if populated): FCC / ISED / CE radio certification required. Baseline SKU is wired-only to minimize certification complexity for V1 launch.
Target TDP < 5W under sustained 1 Gbps DPI load. Silent operation (no fan). Thermal validation required at 35°C ambient, enclosed environment.
V1 target: contract manufacturing via US-based CM for Buy-American alignment on government contracts. 4-layer PCB; no exotic processes. Initial production run: 500 units.