QuantovaQstampby Quantova
ES
EnglishEN日本語JAFilipinoFIL한국어KO简体中文ZHFrançaisFREspañolESУкраїнськаUK
GitHub Empezar a desarrollar →
Qstamp / Robotics
QEdge · Robotic and uncrewed systems

Command, software and mission records of robotic systems that a quantum computer cannot forge.

QEdge is the robotic and uncrewed systems part of QDefence. It places post quantum signatures exactly where a robotic system decides what to trust, which commands it accepts, which software it runs and what it records, so that no adversary can inject a command, load forged firmware or rewrite a mission record. QEdge is being built for release as open source under the same licences as the rest of the Quantova stack. Every tool of the defence branch concerns the integrity, provenance, authority and accountability of records. None of them selects, targets or engages, none of them carries weapons functions, and none of them makes the use of force faster or more effective. They are built for defence, for the protection of command, equipment and evidence against forgery by an adversary who may hold a quantum computer.

Showcase

How QEdge integrates into a robotic system.

Each numbered point marks where QEdge places a post quantum control on the platform, the link or the ground, and what it does there for the defence of the system.

1Ground control stationQMission

The authorising officer signs the mission mandate with a key held in hardware. After the mission the whole record is verified here.

2Data linkML KEM session

Each session is keyed with ML KEM and every command is authenticated, so an injected or replayed command is refused.

3Companion computerQMission check

Verifies the mandate once, then checks every command against its area, time window and permitted actions before it runs.

4Flight controllerQBoot

Boots only firmware signed under CNSA 2.0 and accepts only commands passed by the companion computer.

5Secure elementQKeyring

Holds the platform keys, signs recorder checkpoints and destroys its keys when the platform reports capture.

6Mission recorderQRecorder

Chains every command, refusal and event by SHA3 hash, so no entry can be removed or rewritten after an incident.

7SensorsQTelemetry

Signs telemetry and sensor output in chained batches, so analysis can prove the data came from this platform unaltered.

8Quantova networkAnchor

Recorder checkpoints are anchored on a sovereign or public network when a link is available, fixing them in time.

An uncrewed aircraft is shown. The same eight points of trust apply to ground and maritime robotic systems.

Showcase

QEdge on an uncrewed ground vehicle.

The same design protects ground robots used for logistics and explosive ordnance disposal, from the command post to the manipulator arm.

1Command postQMission

The authorising officer signs a mandate naming the route corridor, the time window and the permitted tasks, with a key held in hardware.

2Radio linkML KEM session

Each session is keyed with ML KEM and every drive and arm command is authenticated, so a spoofed or replayed command is refused.

3Mission computerQMission check

Checks every drive and manipulator command against the corridor, time window and permitted tasks before it reaches the motors.

4Drive and arm controllersQBoot

Boot only firmware signed under CNSA 2.0 and accept only commands passed by the mission computer.

5Secure elementQKeyring

Holds the platform keys, signs recorder checkpoints and destroys its keys when the vehicle is reported lost or captured.

6Mission recorderQRecorder

Chains every command, refusal, arm action and handover by SHA3 hash, so the record of the task cannot be rewritten.

7Sensor mastQTelemetry

Signs camera, lidar and position data in chained batches, so the record of what the vehicle observed is provably unaltered.

8Quantova networkAnchor

Checkpoints and signed handovers of the vehicle between units are anchored when a link is available.

An uncrewed ground vehicle for logistics and explosive ordnance disposal is shown. QEdge secures its command, software and records and carries no weapons function.

Live flow

A ground robot task from command post to investigator, in motion.

Live flowQEdge on a ground robot, from command post to investigator
  1. Your systemsCommand postA mandate names the route corridor, the time window and the permitted tasks
  2. Your systemsMission computerEvery drive and manipulator command is checked against the mandate before execution
  3. Your systemsRefusals recordedA command outside the corridor or the permitted tasks is refused and recorded
  4. Your systemsSigned handoverHandover of the vehicle between units is signed by both parties
  5. Quantova networkAnchorCheckpoints and handovers are anchored when a link is available
  6. PublicInvestigatorThe full task record is verified against the mandate and its anchors
Inside your systemsQuantova networkPublic and verifiable
El problema

Where robotic systems are exposed to quantum forgery.

ExposureWhat an adversary could doWhere QEdge acts
Command linkInject or replay commands that the platform accepts as genuineQMission mandates checked on board and ML KEM sessions on the link
Firmware and updatesLoad forged firmware signed with a recovered RSA or elliptic curve keyQBoot secure boot with CNSA 2.0 firmware signatures
Mission recordsRewrite a flight or mission log after an incidentQRecorder hash chained recorder with signed and anchored checkpoints
Sensor dataAlter telemetry or sensor output before analysisQTelemetry chained and signed batches
Captured platformsExtract keys from a lost platform and impersonate itQKeyring revocation on capture and key destruction
Platform design

Exactly where the cryptography sits on a robotic system.

QEdge uses NIST standardised algorithms, ML DSA for signatures, ML KEM for key establishment and SHA3 for fingerprints. What is Quantova's own is the design that places them across the ground station, the link and the platform, and binds every mission to a signed human authority and an anchored record. The numbers follow the order of a mission.

Ground
1Ground control station

Operators prepare missions. QMission mandates are signed here by the authorising officer, never on the platform.

2Mission authority

The person who approves a mandate signs with a key held in a hardware security module.

6Verificación

After the mission the recorder chain and its checkpoints are verified against the mandate.

Link
3Data link

Each session is established with ML KEM, and each message is authenticated with a symmetric key, because a 3,309 byte signature does not fit a narrow band frame.

5Checkpoint export

When a link is available, the signed head of the recorder chain is sent for anchoring on a sovereign or public Quantova network.

Plataforma
4aCompanion computer

Verifies the mandate signature once, checks every command against the mandate and writes the recorder chain.

4bFlight controller

Accepts only commands passed by the companion computer and boots only firmware that verifies under QBoot.

4cSecure element

Holds platform keys, signs recorder checkpoints and destroys its keys when the platform reports capture.

Platform profiles

Five profiles, one for each point of trust.

QMission · Signed mission mandates

A signed mandate states the area, the time window and the permitted actions of a platform and the human who authorised them. The platform checks every command against it before execution, and a mandate can only narrow what the platform may do.

QBoot · Firmware signing and secure boot

Firmware and updates are signed with hash based or lattice signatures under CNSA 2.0, and the platform refuses any image that does not verify.

QRecorder · Flight and mission recorder

Every command, decision and event is written to a hash chained record whose head is signed at intervals and anchored when a link is available.

QTelemetry · Telemetry and sensor provenance

Telemetry and sensor output are chained and signed in batches, so later analysis can prove the data came from the platform unaltered.

QKeyring · Platform key lifecycle

Keys are provisioned in a secure element, rotated, revoked when a platform is lost or captured and destroyed on command.

Live flow

A mission from mandate to verification, in motion.

Live flowQEdge, from mission authority to the verifier
  1. Your systemsMission authorityA person signs a mandate naming the area, the time window and the permitted actions
  2. Your systemsPlatform checkThe platform verifies the mandate and checks every command against it before execution
  3. Your systemsRejected commandsA command outside the mandate is refused and the refusal itself is recorded
  4. Your systemsMission recorderEvery accepted command and event is chained by hash and checkpointed under the secure element
  5. Quantova networkAnchorWhen a link is available the checkpoint is anchored on a sovereign or public Quantova network
  6. PublicInvestigatorThe whole mission record is verified against the mandate and the anchors
Inside your systemsQuantova networkPublic and verifiable
Demonstration

Try the decision rules yourself.

Simulation in your browserSigned mission mandate and mission recorder

This simulation runs the decision rules of a signed mission mandate and a hash chained mission recorder in your browser. Each recorder entry is hashed with SHA3 256, computed in this page. It does not sign, transmit or anchor anything, and it describes no real platform or operation.

Mandato
  • AreaInspection zone A, grid 10 to 40 by 10 to 40
  • Time windowSteps 1 to 30 of the simulation
  • Permitted actionsSurvey, hold, return
  • Authorised byMission authority key
Commands checked on the platform
    Recorder chain

    Chain head none

    Checkpoints 0

    Engineering

    Built for the constraints of real platforms.

    ConstraintApproach
    Narrow band linksSignatures of 3,309 bytes are used only for mandates, checkpoints and updates, while each message is authenticated with keys established by ML KEM
    Constrained processorsAn embedded Rust core without the standard library, built on the Quantova cryptography library, for companion computers first and flight controllers after
    Denied environmentsThe platform records and checkpoints without any link and anchors the checkpoints later through a ground station
    Claves en hardwareKeys held in secure elements, trusted platform modules or ARM TrustZone, never in ordinary memory
    LatencyMandate checks run against a mandate verified once at the start of a mission, so each command check takes microseconds
    Normas

    Standards the design is aligned with.

    Alignment describes design intent against published requirements. It is not a certification or an approval by any body.

    NormaPertinencia
    CNSA 2.0Published by the National Security Agency of the United States, it sets the algorithms and dates for software and firmware signing in national security systems
    NIST SP 800 208Stateful hash based signatures, LMS and XMSS, for firmware
    NIST SP 800 193Platform firmware resiliency, protection, detection and recovery
    STANAG 4586Interoperability of uncrewed aircraft control, to which QEdge adds signed authority
    MAVLink 2Its message signing uses classical keys, which QEdge replaces with ML KEM sessions
    RTCA DO 326A and EUROCAE ED 202AAirworthiness security process
    DoD Directive 3000.09Autonomy in weapon systems, which QMission and QRecorder support with records of human authority and judgement
    Release path

    From ground station to flight controller.

    1. 01Ground station

      Mandate signing and recorder verification on the ground, using the released QMandate and QLog SDKs.

    2. 02Embedded core

      Port of the Quantova cryptography library to embedded Rust without the standard library.

    3. 03Companion computer

      On board mandate checks and the mission recorder on the companion computer.

    4. 04Secure element

      Platform keys and checkpoint signatures in a secure element.

    5. 05Flight controller

      Secure boot and command acceptance on the flight controller.

    6. 06Review and release

      Security review, open source release and evaluation with integrators.