The Setup
OQTOPUS is an open-source cloud quantum computer operating system built by a Japanese research team. It manages real quantum hardware — job submission, qubit mapping, circuit execution, result return. Apache 2.0. Actively maintained. 20 repos. Real hardware.
We were evaluating it as infrastructure for QSL's quantum security stack — specifically whether it could provide verifiable execution provenance for quantum workloads. Standard move: before you build on something, you audit it.
What We Found
The gRPC interface for job execution looks like this:
string job_id = 1;
uint32 shots = 2;
string program = 3; // raw OpenQASM3 — no signing, no auth
}
message CallJobResponse {
JobStatus status = 1;
Result result = 2; // counts returned — no integrity proof
}
Four problems identified during review:
- No authentication on who submitted the job
- No verification that the result came from actual hardware
- No proof the program that ran matches what was submitted
- The server starts with:
server.add_insecure_port(address)— no TLS on the transport
The risk: In a deployment where this gRPC interface is network-accessible without additional transport controls, an actor could tamper with the OpenQASM3 program in transit or modify the counts returned from hardware. The interface provides no mechanism to detect either.
Why This Matters
Quantum computers are increasingly targeted for cryptographic key generation, drug discovery, financial modeling, and national security research. Tampered results aren't just wrong — they're dangerous. A poisoned quantum random number generator produces predictable keys. Predictable keys break encryption.
"Harvest Now, Decrypt Later" already assumes adversaries are collecting encrypted data today to decrypt later with quantum computers. The integrity gap we identified is orthogonal to HNDL but compounds it — if the computation itself is untrustworthy, post-quantum defenses built on those results inherit that weakness.
Observed in the device-gateway gRPC interface at time of review:
What We Proposed
A lightweight attestation module, implemented in a fork and submitted as PR #79 (pending review). Zero new dependencies. Pure Python stdlib.
hash_program()— SHA-256 of the OpenQASM3 circuithash_counts()— SHA-256 of canonical result countshash_device_info()— SHA-256 of device identity + calibration timestampcreate_job_attestation()— full attestation record per jobverify_attestation()— tamper detection
9 tests. All passing. Including tamper detection — modified counts and modified programs both correctly rejected.
Non-breaking: logs only, response object unchanged.
The PR
Issue #78 opened. PR #79 submitted to oqtopus-team/device-gateway.
Awaiting review from maintainer orangekame3.
Responsible disclosure means building the fix, not just reporting the gap.
Proposed Roadmap
- TLS on the gRPC server —
add_insecure_port→add_secure_port - Calibration data signing — poisoned calibration = wrong qubit mapping
- Job submission authentication layer
- PQC-secured API endpoints for the cloud layer
Security Engineering for Quantum Infrastructure
We perform security assessments of quantum computing infrastructure, build attestation layers, and submit patches upstream. If you're building on quantum infrastructure, we can help you secure it.