Authenticate messages on the QKD classical channel.

Raise the authentication of the classical channel to the security level of its quantum channel, so it is no longer the QKD link's weak point, built on information-theoretically secure cryptography.

Contact us →
// The Threat

Every computational cryptographic algorithm has a limited lifetime, including the one authenticating your QKD classical channel.

QKD distributes keys with a security proven from physics, under its own stated device and channel assumptions. But every QKD link runs a public classical channel alongside the quantum one, and that channel has to be authenticated. Today it is authenticated with standards-based cryptography such as HMAC, AES-GMAC, RSA, and ECDSA, all based on computational hardness: a computational assumption, not a proof. A quantum computer breaks RSA and ECDSA, while AI and new cryptanalysis may break the rest, the computational MACs and post-quantum signatures included, so the algorithm authenticating your classical channel has a limited lifetime.

Why the classical channel is the link's weak point:

  • The classical channel must be authenticated. QKD key agreement relies on an authenticated classical channel. Without authentication, a man-in-the-middle defeats the QKD protocol, and the derived keys end up shared with the attacker.
  • Today it rests on computational security. QKD products authenticate the classical channel with HMAC, AES-GMAC, or post-quantum signatures. Each rests on computational hardness, an assumption and not a proof, so each is secure only while its underlying problem stays too hard to solve.
  • A broken MAC puts every derived key at risk. Once classical-channel authentication is broken, every QKD key derived through that link is at risk, and QKD's information-theoretic security no longer holds for that link.
// QUAUTS for QKD

The classical channel, raised to the quantum channel's security level.

QuBalt secures the classical channel of QKD links through QUAUTS for QKD, its Quantum- and Cryptanalysis-Secure Authentication System, built on QuBalt's authentication core.

QUAUTS for QKD authenticates every classical-channel message, key post-processing and ciphertext alike, with an information-theoretically secure tag keyed from the QKD output itself. The classical channel is raised to the quantum channel's security level, with no dependence on a computational hardness assumption.

QUAUTS for QKD is delivered as a building block that integrates symmetrically into both QKD endpoints. At each endpoint it runs as an FPGA core, with its bootstrap key and tag-key pool, plus a software stack on the host controller; the same building block sits at each end. It draws its authentication keys from the QKD channel itself: the QKD key store feeds two streams, authentication keys for the QUAUTS for QKD tags and, where you use it, AES keys for user-data encryption. QUAUTS is validated to TRL 4 under the ESA GSTP programme and is adapted to each customer's specific requirements and hardware environment.

// Capabilities
  • Raise the classical channel to the quantum level. Authenticate every classical-channel message, key post-processing and ciphertext alike, so the classical channel matches the quantum channel's security level.
  • Keyed from the QKD output. Draw tag keys from the QKD channel itself, consuming only a small fraction of QKD output to authenticate the rest.
  • FPGA or software. Run the authentication in an FPGA core or in host software.
  • Across every QKD architecture. Apply the same building block to DV-QKD, CV-QKD, satellite-ground QKD, and QKD-as-a-service links.
// In operation
  • FPGA core or software library. QUAUTS for QKD is available as an FPGA core, or as a pure C library on the host processor where no secure FPGA is available.
  • Beside your existing channel. QUAUTS for QKD sits beside your existing classical-channel transport and authenticates its traffic; it complements QKD and does not replace it.
  • Self-replenishing keys. One-time tag keys are consumed on use and immediately replenished from the same QKD channel. Keys are consumed on use and never reused.
  • Encryption is optional. Where classical-channel content must also be kept confidential, add the bundled AES or reuse your own; authenticity stays information-theoretic either way.
// Application Areas

One building block across every QKD deployment.

The same QUAUTS for QKD integration authenticates the classical channel wherever your QKD links run, so one building block covers your whole product line:

In space

Satellite-to-ground and inter-satellite QKD links.

In fibre networks

Metropolitan and long-haul terrestrial QKD networks.

In secure hardware

QKD nodes, trusted-node relays, and QKD-as-a-service platforms.

// What You Get

The classical channel is no longer the link's weak point.

For the QKD link and the manufacturer who fields it, that means the classical channel matched to the quantum channel and a key supply that sustains itself:

  • Classical channel matched to the quantum channel. The classical channel's authentication is raised to the quantum channel's security level, so QKD's information-theoretic key distribution is not undercut by the channel beside it.
  • Secure for the whole mission and beyond. The authentication stays secure against quantum computers, AI, and future cryptanalysis, and holds for the deployed device's full operational life, so recording traffic today gains an adversary no advantage in forging it later.
  • No MAC-break replacement cycle. Systems still relying on HMAC, AES-GMAC, or PQC signatures must be re-keyed or replaced when those are broken; QUAUTS for QKD systems are not affected.
  • Self-sustaining key supply. Authentication draws only a small fraction of QKD output and replenishes its own one-time tag keys from the same channel.
  • Compliance-ready. Meets emerging information-theoretic and sovereign-cryptography procurement criteria that computational MACs cannot.
  • One integration, every QKD architecture. A single building block covers DV-QKD, CV-QKD, satellite-ground QKD, and QKD-as-a-service.
// The Key Difference

Security proven by information theory, not assumed to be hard.

For a QKD link, the classical channel's security basis decides the whole link: authenticate it computationally and it stays the weak point beside a quantum channel proven from physics.

State-of-the-art QKD products authenticate the classical channel with digital signatures such as RSA and ECDSA, with the post-quantum standards, or with computational MACs such as HMAC and AES-GMAC, all standards-based and all forms of computational security: their security rests on a problem staying too hard to solve, an assumption that has never been proven. A quantum computer breaks RSA and ECDSA, while AI and new cryptanalysis may break the rest, the MACs and post-quantum standards included. QUAUTS for QKD instead uses information-theoretic authentication: provably secure under its stated assumptions of truly random, single-use keys and a correct implementation, and independent of any attacker's computing power, now or in the future. That proof covers the authentication algorithm; full system security also rests on key management and implementation assurance.

QUAUTS for QKD therefore rests on a different security basis, one that stays secure against quantum computers, AI, and future cryptanalysis, so the classical channel matches the quantum channel it runs beside for the QKD link's entire operational life.

// Frequently asked questions

Questions a technical evaluator asks.

What exactly is information-theoretically secure, and under what assumptions?
The guarantee belongs to the authentication algorithm: at any computing power, the best attack is a blind guess with negligible, fixed odds. It holds under four assumptions, all required: keys are truly random, used exactly once (reuse breaks it), the implementation is correct and free of side-channel or fault leakage, and keys are kept secret and securely provisioned. The authentication core is our validated implementation of that algorithm plus its key management, so the core is not itself called information-theoretically secure; full system security also rests on that key management and on implementation assurance.
How is this different from post-quantum cryptography?
PQC is still computational security: it rests on problems only assumed too hard to solve, and holds only while that assumption holds. QUAUTS for QKD authentication does not rest on a hardness assumption, so it stays secure against quantum computers, AI, and future cryptanalysis, matching the quantum channel it runs beside.
Does this replace my QKD system?
No. QUAUTS for QKD sits beside your existing classical-channel transport and authenticates its traffic. QUAUTS for QKD complements QKD and does not replace it.
Where do the authentication keys come from?
From the QKD channel itself. QUAUTS for QKD consumes only a small fraction of the QKD output to authenticate the rest, and replenishes its one-time tag keys from the same channel. Keys are consumed on use and never reused.
Does a recorded message stay protected if it is attacked later?
QUAUTS for QKD authentication does not rest on a hardness assumption that can fall later, so recording a message to forge it later gains nothing: at any computing power, and whenever the attempt is made, the best a forger can do is a blind guess with negligible, fixed odds. Its authenticity holds for the link's whole life and beyond it. Where AES is added for confidentiality, that content rests on AES strength.
Is confidentiality included?
Authentication is always on. Confidentiality is optional and separate: add the bundled AES, or reuse your own AES implementation, where classical-channel content must also be kept confidential. AES is not itself information-theoretically secure, and authenticity stays information-theoretic either way.
Which QKD architectures does it support?
DV-QKD, CV-QKD, satellite-ground QKD, and QKD-as-a-service, all with the same building block and the same key supply drawn from the QKD output.
What primitive and standards does QUAUTS for QKD use?
Authentication is an information-theoretic one-time MAC, with keys consumed on use and never reused. Optional encryption is AES-128/256 with PKCS#7 padding. Validated to TRL 4 under the ESA GSTP programme.
What is QUAUTS for QKD's maturity and flight heritage?
The authentication core is validated to TRL 4 under the ESA GSTP programme and is selected for in-orbit demonstration aboard ESA's CyberCUBE, 2026.
What if there is no secure FPGA at the endpoint?
The authentication core is delivered as a pure C library on the host processor instead of an FPGA core.
What footprint, throughput, and overhead does QUAUTS for QKD need?
The fraction of QKD output consumed for authentication, per-message overhead, throughput, footprint, and key-budget sizing are supplied for your target platform. We do not quote figures we have not measured for your case.
Is the implementation hardened against side-channel and fault attacks?
The core is developed within the ESA GSTP programme. Side-channel and fault-injection resistance and radiation tolerance are being implemented in an ongoing project to advance the technology to TRL 5.
// Get in Touch

Discuss your QKD-authentication requirements

Whether you build DV-QKD, CV-QKD, satellite-ground, or QKD-as-a-service links, our engineers will show you how to raise your classical channel to the quantum channel's security level within your existing architecture. Contact us about your link.

Contact us →