QS09: add pulse-level circuit attack class (Xu & Szefer, IEEE S&P 2025)

[Treyrob3]

QS09 currently covers two documented attack classes, both of which assume a compromised toolchain component: circuit theft via a malicious compiler (Suresh et al., HASP 2021) and QTrojan via altered hardware configuration files (Chu et al., ICASSP 2023).

This PR adds a third class that requires no compromised component. Xu and Szefer (IEEE S&P 2025) show that the interface between a custom gate's gate-level description and its pulse-level implementation is unvalidated across most current SDKs, enabling qubit plunder, qubit block, qubit reorder, and timing, frequency, phase and waveform mismatch attacks. The attacks are demonstrated on real hardware. The malicious input is the gate definition itself, which makes an imported or shared custom gate a supply-chain vector even when every component of the toolchain is authentic.

This seemed to fit QS09 rather than warrant a new entry, since the existing description already names pulse-level schedulers as part of the stack in scope and Prevention step 4 already treats pulse configuration as a sensitive surface. Happy to move it if you see the boundary differently — it could arguably sit with QS10, though the delivery path is the software stack rather than the control plane.

Changes: one description paragraph, two common examples, two prevention steps, one attack scenario, one reference. No existing content removed or reworded. The reference is inserted at position 3 rather than appended, to keep research citations grouped ahead of frameworks and regulation as the list currently does.

[Ar3sDoom]

Hi, thanks for opening this PR. This view is very interesting, and the prevention is really similar to the common binary.
Validation before execution and code signing?

I think we can start now to analyze and read rules to detect malicious patterns or gates in code with the same tools of static analysis: YARA and static code analysis with graphic representation. I'm trying to write an add-on for Binary Ninja or write my own tools to explore this view. I think we need for the future the same technology as SonarQube for quantum code.

What do you think of this type of approach in relation to your PR?

[Treyrob3]

Thanks, this is a great direction and the analogy makes sense to me. Gate-level vs pulse-level really is a bit like source code vs the compiled binary: what you look at isn't what actually runs, and that gap is the whole problem.

One thing I keep getting stuck on with the YARA idea: YARA is good at spotting known-bad patterns, but these pulses aren't malformed. A qubit plunder pulse is a perfectly normal pulse — it's only an attack because it does more than the gate said it would. So I'm not sure there's a fixed pattern to match on, but I am also not an expert on YARA really.

What might work better is a conformance check: does this pulse only touch the qubits the gate declares, stay in its timing window, stay in its frequency range? The nice thing is that the gate-level description is basically a spec, so unlike normal binary analysis you already have something to check against instead of having to guess intent. That feels buildable/actionable today.

Your signature idea probably still matters for the cases a scope check would miss — like phase or waveform mismatch, where the pulse hits the right qubit at the right time but does the wrong thing. I don't have a clean answer for those either.

One thing I am unsure about: pulse behaviour depends on how the device is calibrated at the time. Curious whether you've run into that.

On code signing — I think it's worth having but doing a different job. It tells you who wrote a gate, not whether the gate is safe. Useful for the "imported from a shared library" case, which is why I'd keep both.

For the PR itself, I would lean toward keeping the prevention steps to things people can do today, since the project is trying to separate demonstrated risk from speculation. The tooling you're describing feels like a strong fit for Track 2 (platform threat modelling / secure design). There's a Work Areas form linked in the README if you want to propose it. I would back that, I just do not the proper way to propose it

In case it's useful: Xu and Szefer propose a defence framework at the end of the same paper (arXiv:2406.05941). Might be a head start on this.

[Vishnu2707]

One question on the conformance check idea, if calibration drifts over time, does a static conformance spec even hold up, or does the check need to run against live calibration state at execution time? Feels like that changes what "in scope" means from a fixed boundary to a moving one.

What do u think @Treyrob3 @Ar3sDoom ?

[Ar3sDoom]

Thanks for this exchange and the very constructive feedback on these different
points. This is where we see the limitations of applying classical static
analysis methodology to quantum computing.

You're right that YARA only detects patterns, and I didn't have all the
elements to go further on that aspect. Thanks to your message, I see things
differently now I see it a bit like dynamic analysis with real-time reading
of the state and impacted targets.

To stay within the analogy: which register or which memory address is altered
by function X?

Code signing indeed doesn't allow you to control its state, but rather to
legitimize code that has passed through a trust verification chain before
being signed.

And @Treyrob3 I submitted my idea, along with all the explanations, via a Google Form :)

[Vishnu2707]

That's a good reframe, dynamic state monitoring fits this better than anything static @Ar3sDoom : )

[Treyrob3]

@Vishnu2707 Good question, and I think the answer is "both," because some parts of the check drift and some don't.

The real problem your question surfaces is timing. If you check the gate against today's calibration and the device recalibrates before the job actually runs, you validated against something that no longer applies. So this probably needs to happen at dispatch, tied to a specific calibration version, not as a check in CI. It also can't run on the client side, since whoever supplies the gate definition would be the one running the validator. That's close to what #16 is working on.