Skip to main content
ROCSI
ROEN
Menu

Current Work / 03 / Experimental

Experimental
Domain
Trustworthy infrastructure / Privacy-preserving verification
Started
2026 research cycle
Development
Simulation-first research & prototyping
Environment
Vehicle / drone telemetry experiments

Telemetry Attestation Gateway

An experiment in proving selected properties of telemetry without exposing the underlying telemetry itself.

Telemetry Attestation Gateway is simulation-first research into narrowly scoped zero-knowledge proofs for vehicle and drone telemetry. The work explores whether a verifier can receive evidence about a specific property while the underlying sensitive telemetry remains undisclosed. It is not presented as a production security product, control system, or command-authorization layer.

Explore ROCSI on GitHub ↗All Current Work →

01 / Why

Verification does not always require disclosure of the underlying data.

The research question

Telemetry can contain sensitive operational detail, yet another system may need evidence about a narrowly defined property of that telemetry. Sending the complete dataset can disclose more information than the verifier actually needs.

The experiment asks whether an attestation layer can prove a limited statement about telemetry while keeping the original measurements private, and what trust, freshness, identity, and failure assumptions would still remain outside the proof itself.

Why ROCSI is investigating it

The project gives ROCSI a bounded environment for studying selective disclosure, verifiable claims, telemetry provenance, and the limits of cryptographic evidence in systems that cross organizational or infrastructure boundaries.

The value of the experiment is as much in identifying what a proof cannot establish as in demonstrating what it can. A valid proof does not automatically establish sensor correctness, trustworthy key custody, current system safety, or authorization to control a vehicle.

02 / Experiment system

Telemetry in. Narrow claim out. Verification remains a separate boundary.

The current model is conceptual and simulation-first. Vehicle or drone telemetry is evaluated against a narrowly scoped predicate, a zero-knowledge proof represents that claim, and a verifier checks the proof without receiving the raw telemetry. The diagram communicates the experiment boundary rather than a production deployment architecture.

  1. 01

    Telemetry source

    A simulated vehicle or drone context produces telemetry. MAVLink 2 is represented in the current experiment as one telemetry framing, not as a claim of universal protocol coverage.

  2. 02

    Attestation predicate

    The experiment defines a narrowly scoped property to be evaluated instead of exposing a complete telemetry record to the verifier.

  3. 03

    Zero-knowledge proof

    A proof is generated for the selected statement. Its scope is limited to what the circuit or proof statement actually encodes.

  4. 04

    Verifier boundary

    The verifier checks the proof and must still rely on separate assumptions about identity, key custody, freshness, sensor provenance, and surrounding system policy.

03 / Current experiment

The experiment separates what is being tested from what is still unknown.

This is experimental work. Architecture, scope, implementation, and proof statements may change as assumptions are tested. The current record deliberately avoids presenting research hypotheses as operational guarantees.

Current experiment

  • A simulation-first vehicle/drone telemetry model with a conceptual path from telemetry to a narrowly scoped attestation and verification step.
  • A privacy-preserving proof model intended to disclose a selected property rather than the underlying telemetry dataset.
  • Explicit exclusion of flight control, command authorization, and autonomous decision execution from the experiment's claimed scope.

Under evaluation

  • Defining proof statements that are narrow enough to be meaningful without implying broader system trust than the proof can establish.
  • Testing how provenance, freshness, replay resistance, identity, and key-management assumptions should sit around the proof boundary.
  • Evaluating whether the computational and operational cost of proof generation and verification is appropriate for plausible telemetry workflows.

Open questions

  • Which telemetry predicates provide useful assurance while preserving meaningful privacy?
  • How should a verifier communicate the difference between a valid proof and trust in the source that supplied the underlying measurements?
  • Which threat models and deployment contexts justify a cryptographic attestation layer instead of simpler signed or policy-based mechanisms?

04 / Experiment principles

A proof should establish only the claim it was designed to establish.

01

Minimize disclosure

Share the property needed by the verifier rather than exposing complete telemetry by default.

02

Scope claims narrowly

A valid zero-knowledge proof is evidence for a defined statement, not a blanket guarantee about the vehicle, sensors, operator, or environment.

03

Keep trust boundaries visible

Identity, key custody, freshness, sensor provenance, and verifier policy remain distinct system concerns even when the cryptographic proof is valid.

04

No control authority by implication

The experiment does not authorize commands, control flight or driving, or execute autonomous decisions.

05

Simulate before claiming deployment

Experimental evidence should precede production-oriented claims about performance, safety, security, or operational suitability.

05 / Research relationships

The experiment sits where trust, infrastructure, resilience, and emerging cryptography meet.

Telemetry Attestation Gateway is useful to ROCSI because it forces several durable research questions into one bounded technical experiment.

Trust & Information Integrity

Examines how a verifier can assess a narrowly scoped claim, its provenance assumptions, and the limits of the evidence being presented.

Open Digital Infrastructure

Explores whether attestation interfaces can be designed as inspectable infrastructure boundaries rather than opaque proprietary trust mechanisms.

Cyber & Digital Resilience

Tests how verification, failure handling, freshness, and explicit trust assumptions might contribute to systems that remain understandable under adverse conditions.

Emerging Technologies

Uses zero-knowledge proofs as an emerging technical mechanism and evaluates their practical value, limitations, and operational cost instead of assuming suitability.

Explore ROCSI research →

06 / Project state

Experimental

Experimental

This work is under technical evaluation. Its architecture, scope, proof statements, and implementation may change while the underlying assumptions are tested. It should not be interpreted as a production-ready telemetry security or vehicle-control system.

Question under investigation

  • Determine which telemetry claims can be both useful to a verifier and meaningfully privacy-preserving.
  • Make the non-cryptographic trust assumptions around provenance, freshness, identity, and keys explicit.
  • Measure whether the added cryptographic complexity is justified by the privacy or verification benefit in realistic scenarios.

07 / Possible direction

Advance only the parts that survive the experiment.

The next steps are research directions rather than roadmap commitments. A result that shows a simpler approach is more appropriate would also be a useful outcome.

  1. 01Refine the smallest useful proof statements and test their privacy and verification properties in controlled simulations.
  2. 02Document threat assumptions and failure cases alongside successful proof verification so the system boundary remains inspectable.
  3. 03Compare zero-knowledge attestations with simpler signed, disclosed, or policy-based alternatives before considering any broader implementation path.

08 / Explore / collaborate

Treat the experiment as a question, not a product claim.

This ROCSI page is the project record for the current experiment. No dedicated public production deployment or project repository is implied here; broader open ROCSI work remains visible through the organization and Workbench surfaces.

Explore ROCSI on GitHub ↗View all Current Work →Open the Workbench →Discuss collaboration →