PaperlayerView exact revision on arXiv

Source-linked AI summary

RAMP: Toward Ubiquitous Quantum-Safe Key Distribution as a Service

Jiafan Wang, Sebastian Kish, Dongxi Liu

arXiv:2610.22879v1cs.CR

TL;DR

QKD’s specialized hardware limits ordinary users, and service providers may know material that determines delivered keys. RAMP separates provider-side QKD generation from user-side masking and processing; its prototype reports 2.1Kb/s key-distillation throughput on an M4 Pro CPU.

  • Problem

    QKD’s specialized hardware limits ordinary users, while a service provider may learn or reconstruct the delivered key, exposing end-to-end confidentiality to infrastructure compromise.

    Source: §1 · p. 1, §1.1 · p. 2

  • Method

    RAMP separates QKD material generation at service providers from user-side masking and QKD post-processing.

    Source: §7 · p. 14

  • Results

    2.1Kb/s key-distillation throughput was measured on an M4 Pro CPU, with feasibility shown on experimentally acquired QKD data.

    Source: §6.5 · p. 14

  • Takeaways & Limitations

    RAMP moves QKD post-processing to commodity user devices while providing final-key confidentiality under complementary compromise modes.

    Source: §7 · p. 14

    The evaluation covers one low-SNR CV-QKD operating point, one LDPC configuration, and a local acquisition path, so performance depends on QKD parameters, decoders, networks, and hardware.

    Source: §6.5 · p. 14

Abstract

from arXiv · show

Quantum key distribution (QKD) offers a security foundation independent of computational hardness assumptions. However, its reliance on specialized hardware limits access by ordinary users. Turning QKD into a service poses a fundamental trust challenge, as the providers that supply QKD-derived material themselves could retain knowledge of the keying inputs of users. This makes end-to-end confidentiality solely depend on the trustworthiness of the service infrastructure. We present RAMP, a service-oriented framework that decouples QKD material generation from key consumption. Providers operate QKD infrastructure and supply raw-key materials, while users securely acquire, mask, and locally process them into final keys without operating QKD devices. RAMP employs reconciliation-preserving masking compatible with both DV- and CV-QKD. It mitigates the trust dependence by separating the QKD-service and user-side masking domains. We formalize complementary confidentiality guarantees: RAMP protects the final key even if colluding providers expose their complete raw-key views, provided the masking domain remains secure; conversely, exposing the complete masking state does not break final-key secrecy as long as the QKD source and acquisition paths remain protected. The results establish the dual-domain security boundary of RAMP. We implement RAMP using experimentally acquired QKD data and standardized quantum-safe cryptography. After acquiring service-provisioned keying material, commodity endpoints complete user-side QKD post-processing with an average key-distillation throughput of 2.1Kb/s on an M4 Pro CPU. To our knowledge, we demonstrate the first experimental realization of such service-provisioned, user-side QKD processing, presenting a viable path toward QKD as a service.

1 Introduction

QKD’s specialized hardware limits access, while service models can leave providers trusted with material that determines users’ final keys. RAMP shifts processing to users and separates provider-side QKD material from user-side masking to address this trust problem.

1.1 Challenges in More Accessible QKD

  • Existing QKD networks remain device-centric, and service infrastructures may learn or reconstruct delivered keys, leaving end-to-end confidentiality exposed to provider compromise or collusion.Specialized hardware, calibrated links, and protocol-specific processing make QKD difficult to scale to ordinary endpoints.Source: §1 · p. 1, §1.1 · p. 2

1.2 From QKD to Quantum-Safe Service

  • RAMP moves parameter estimation, reconciliation, and privacy amplification to users, using reconciliation-preserving masking so providers’ knowledge of supplied material cannot determine the final key.The framework separates quantum-state transmission and raw-key generation at providers from user-side cryptographic protection and post-processing.Source: §1.2 · pp. 2–3

1 Introduction

  • RAMP lets ordinary users acquire and locally process QKD-derived material without operating specialized QKD devices.Providers operate the quantum infrastructure and generate raw-key material, decoupling its generation from on-demand key consumption.Source: §1.2 · p. 2, §1.3 · p. 3

1.3 Contributions

  • RAMP combines independently separated QKD-service and user-side masking domains with no-error-propagation masking that supports standard post-processing and detection of inconsistent provider material.Its security analysis formalizes confidentiality under complementary compromise modes, and its evaluation uses experimentally acquired QKD data and standardized quantum-safe primitives.Source: §1.3 · p. 3

2 Preliminaries

The preliminaries describe QKD’s quantum and classical stages, including how noisy raw keys are filtered, assessed, reconciled, and distilled. They also define the cryptographic building blocks used by RAMP, from signatures and key exchange to provisioned secure channels and stream ciphers.

2.1 Quantum Key Distribution (QKD)

  • QKD exchanges and measures quantum states, producing noisy correlated raw keys that parties filter, assess, reconcile, and compress into a shared secret.Parameter estimation may trigger abort, reconciliation aligns noisy data, and privacy amplification removes potential adversarial information.Source: §2.1 · p. 4
  • Composable QKD secrecy bounds the distinguishability of an accepted real key from an ideal uniform key independent of adversarial side information.That side information may include retained quantum information and the public post-processing transcript.Source: §2.1 · p. 4

2.2.1 Digital Signature Scheme (SIG)

  • A digital signature authenticates a message’s origin and integrity through signing with a secret key and verification with its corresponding public key.The scheme defines key generation, signing, and verification algorithms.Source: §2.2.1 · pp. 4–5

2.2.2 Authenticated Key Exchange (AKE)

  • Authenticated key exchange lets two parties establish a shared session key while authenticating their intended peer over an adversarially controlled network.Matching initiator and responder sessions output the key; otherwise, the protocol outputs ⊥.Source: §2.2.2 · p. 5

2.2.3 Secure Channel from Provisioned Credential

  • A secure channel from a provisioned credential uses a previously established symmetric trust root to authenticate peers and derive session-specific traffic keys.TLS 1.3 supports this channel model using symmetric pre-shared keys.Source: §2.2.3 · p. 5

2.2.4 Synchronous stream ciphers (SSC)

  • An XOR-based synchronous stream cipher generates a keystream from a secret key and encrypts or decrypts by XOR, without error propagation.Ciphertext or plaintext transmission errors affect only corresponding symbols.Source: §2.2.4 · p. 5

3 System Design

RAMP is designed as a service in which providers maintain QKD devices and users acquire, mask, and process raw keys locally. Its interfaces specify those interactions, while its threat model defines complementary conditions for final-key confidentiality.

3 System Design

  • Users register, acquire provider-generated raw keys, mask them, and run post-processing without operating local QKD hardware.The design assumes providers manage paired DV- or CV-QKD devices with regular point-to-point functionality.Source: §3 · p. 5

3.1 Interfaces

  • The interfaces cover provider initialization and raw-key generation, credentialed user registration and acquisition, user-side masking, and final-key post-processing.Providers index corresponding raw-key materials and metadata; users mask acquired keys obtained under the same identifier before processing.Source: §3.1 · p. 6

3.2 Threat Model

  • Final-key confidentiality holds if masking remains secure despite provider compromise, or if QKD-service secrecy and acquisition security hold despite masking-state exposure.The goals also preserve the QKD bound on accepting inconsistent provider material; the described deployment focuses on two users, while multiple-provider and subscriber deployments are not evaluated.Source: §3 · p. 5, §3.2 · p. 7

4 Construction

RAMP separates provider-side QKD generation and service operations from users’ acquisition, masking, and local post-processing. Its workflow uses reconciliation-preserving masking so users can process masked material with standard QKD operations under the same correlation conditions as conventional QKD.

4 Construction

  • RAMP’s Register–Acquire–Mask–Process workflow uses signatures, secure acquisition channels, authenticated key exchange, and a stream cipher for masking.The acquisition credential and AKE secret are generated independently; primitive sizes follow NIST guidance for quantum-adversary security.Source: §4 · p. 7

4.1 System Setup and Raw-Key Generation

  • Providers initialize QKD links, generate correlated raw-key blocks with shared identifiers, and store them with metadata and lifecycle states.Consumed or expired blocks are never made available to another user session.Source: §4.1 · p. 7

4.2 Registration and Raw-Key Acquisition

  • A user requests an available raw-key block from its provider, then forwards its signed identifier so the peer’s provider can verify and return the matching material.Users validate returned metadata against the agreed QKD profile before masking; invalid or unsupported metadata causes an abort.Source: §4.2 · p. 8

4.3 Raw-Key Masking

  • After acquisition, users perform protocol-specific sifting and parameter estimation, establish a session-specific masking key, and mask the remaining reconciliation inputs.Parameter estimation occurs after both raw-key blocks are acquired; the process aborts if channel estimates exceed protocol thresholds.Source: §4.3 · pp. 8–9
  • Users mask reconciliation inputs with a shared keystream that hides them from providers while preserving the discrepancy structure needed by DV- and CV-QKD post-processing.For CV-QKD, flipping a bit label also reverses its LLR sign without changing its magnitude or reliability.Source: §4.3 · p. 9

4.4 Post-Processing and Key Distillation

  • RAMP preserves correctness and robustness under the same conditions as conventional QKD: raw-key discrepancies remain localized and correctable when the observed error rate is below the protocol threshold.The masking operation adds no error propagation, so standard QKD post-processing applies to the masked inputs.Source: §4.4 · p. 9
  • Provider signatures and state tracking protect allocation identifiers against forgery or reuse, but do not authenticate raw-key contents or physical provenance.Content integrity during acquisition is provided by the secure channel when the provider endpoint is honest.Source: §4.4 · p. 9

5 Security Formalization

The security formalization analyzes complementary compromises of the QKD-service and user-side masking domains. It also characterizes when inconsistent provider-supplied material is rejected and how unilateral deviation can be checked.

5 Security Formalization

  • RAMP’s dual-domain guarantee covers provider compromise while masking remains secure, and masking-state exposure while QKD secrecy and acquisition remain protected.The security analysis targets sessions between honest users while allowing an adversary to control the classical network and use QKD-permitted quantum-channel capabilities.Source: §5 · p. 10

5.1 Provider-Compromise Key Confidentiality

  • Theorem 1 guarantees final-key confidentiality even when both providers expose their complete session views, provided AKE security, secure masking, and leakage-aware privacy amplification hold.The result does not assume QKD secrecy or acquisition security.Source: §5.1 · p. 10
  • RAMP places security-critical QKD processing with users, so provider-visible QKD inputs do not determine the final key when the masking domain remains secure.The paper distinguishes this service boundary from hybrid key combiners that combine independently protected secrets at final-key derivation.Source: §5.1 · p. 10

5.2 Masking-Compromise Key Confidentiality

  • Theorem 2 guarantees final-key confidentiality despite exposure of the complete masking state, assuming QKD secrecy, secure acquisition channels, and public-mask invariance of reconciliation.The masking state may include the AKE key and resulting keystream; the proof does not assume AKE or stream-cipher secrecy.Source: §5.2 · pp. 10–11

5.3 Detectability of Inconsistent Key Material

  • Theorem 3 bounds acceptance of inadmissible provider material by εdet when the underlying QKD post-processing accepts such input with probability at most εdet.RAMP preserves the underlying acceptance and rejection behavior through parameter estimation, masking, reconciliation, and correctness verification.Source: §5.3 · p. 11
  • When at most one independently administered provider deviates, user-side parameter estimation checks the correlation of paired material without letting that provider tune its block to the other user’s undisclosed samples.Those samples are unknown to the provider when the raw-key blocks are acquired.Source: §5.3 · p. 11

6 Experimental Evaluation

The evaluation tests RAMP’s user-side QKD processing and service path on experimentally acquired CV-QKD data and two commodity laptops. Processing is feasible at the evaluated finite-size operating point, with reconciliation dominating runtime and RAMP-specific costs remaining comparatively small.

6.1 Experimental Setup and Scope

  • The experiment uses qOptica 100 CV-QKD data and evaluates the user-side pipeline on an M4 Pro and an i7-1265U without GPU acceleration.The MATLAB pipeline takes provider-supplied raw-key material and a user-established masking key through parameter estimation, masking, reconciliation, and privacy amplification.Source: §6.1 · p. 11

6.2 User-Side QKD Processing

  • The complete finite-size processing run takes approximately 18.7 minutes on M4 Pro and 89.8 minutes on i7-1265U, with LDPC decoding the dominant stage.RAMP-specific masking takes about 4.19% and 4.62% of wall-clock runtime on the respective platforms.Source: §6.2 · pp. 11–12

6.3 Reconciliation Efficiency and Key Yield

  • 2.1×10^3 bits/s on M4 Pro and 4.2×10^2 bits/s on i7-1265U are the effective key-distillation throughputs at the evaluated finite-size operating point.The 200-block run produces a final key of approximately 2.28×10^6 bits; privacy amplification is subdominant to decoding.Source: §6.3 · pp. 12–13

6.4 RAMP Service-Path Evaluation

  • The service-path evaluation separates one-time provisioning costs from per-session operations and measures online operations over 30 executions after warm-up.The measurements follow RAMP’s execution order.Source: §6.4 · p. 13

6.4.1 Setup and Raw-Key Provisioning

  • Importing and indexing the prepared 3.65GB paired raw-key workload takes 1.32 seconds on M4 Pro and 2.68 seconds on i7-1265U.The operation includes integrity hashing, identifier derivation, and provider-side storage updates.Source: §6.4.1 · p. 13

6.4.2 Registration and Raw-Key Acquisition

  • Acquiring the 3.65GB paired workload takes a median 13.99 seconds on M4 Pro and 22.95 seconds on i7-1265U.The measured path includes protected transfer and local persistence; provider signing and verification account for only about 0.10% and 0.04% of acquisition time.Source: §6.4.2 · p. 13

6.4.3 Session Binding and Masking-Key Establishment

  • Session binding takes a median 19.1µs on M4 Pro and 24.3µs on i7-1265U; masking-key establishment succeeds across 60 measured sessions.The establishment wrapper takes a median 2.33 seconds and 2.28 seconds, respectively, including OpenSSL process-management overhead.Source: §6.4.3 · p. 13

6.3 Reconciliation Efficiency and Key Yield

  • At the evaluated operating point, RAMP achieves reconciliation efficiency βeff ≈0.929 with zero observed frame errors and zero residual post-reconciliation bit errors.For 4×10^8 accepted bits, the finite-size secret fraction is approximately 0.0057 bits/use.Source: §6.3 · p. 12, §6.5 · p. 13

7 Conclusion

RAMP moves QKD from a device-centric model to a service-oriented architecture, separating quantum-state generation from user-side processing. The paper positions this design against existing QKD services and hybrid constructions, emphasizing user-side local processing and a distinct pre-reconciliation service boundary.

7 Conclusion

  • RAMP lets ordinary users obtain quantum-derived keys without QKD hardware by decoupling key provision from consumption, while providing final-key confidentiality under complementary compromise modes.Only service providers require QKD hardware.Source: §7 · p. 14, §B.1 · p. 17

A Ethics Considerations

  • The experiments are intended to assess feasibility and performance under stated assumptions, not to certify a production deployment.The work reports no vulnerability in an existing system.Source: A Ethics Considerations · p. 16

B.1 QKD Networks

  • Existing QKD networks remain device-centric and typically have limited elasticity under multi-user demand, whereas RAMP requires QKD hardware only at service providers.The networks also require trusted intermediate relays or repeaters.Source: §B.1 · p. 17

B.2 Offloading and QKD-as-a-Service

  • Prior QKD-as-a-service work addresses resource management and provisioning, while RAMP lets users locally mask and process raw-key materials into final keys.The paper states that prior approaches do not address provider abuse of keys assigned to users.Source: §B.2 · p. 17

B.3 Hybrid PQC–QKD Key Establishment and Key Combination

  • Prior hybrid and QKD-service constructions do not address the pre-reconciliation boundary of protecting provider-known noisy inputs while preserving user-side reconciliation.RAMP exposes pre-reconciliation QKD-derived material to providers and has users execute the classical QKD security pipeline locally.Source: §B.3 · p. 17

D.1 Proof of Provider-Compromise Final-Key Confidentiality (Theorem 1)

The proof reduces provider-compromise confidentiality to the security of the user-side AKE and stream cipher, then analyzes an ideal uniform mask. In both DV- and CV-QKD, the masked reference string is uniform despite providers knowing the original inputs; privacy amplification accounts for subsequent public leakage.

Proof strategy

  • The hybrid proof first replaces the target AKE key, then the stream-cipher keystream, with independent uniform values, using AKE session-key security and SSC IND-CPA security.These replacements are computationally indistinguishable under the stated security assumptions.Source: §D.1 · p. 19

Uniform masking across QKD modes

  • For both DV-QKD and CV-QKD, the masked binary reference string is uniform even when corrupted providers know the original reference material.In CV-QKD, the transformed LLR vector preserves reconciliation consistency without adding entropy.Source: §D.1 · pp. 19–20

Entropy and public leakage

  • The proof models the adversary’s state before key-dependent public communication and attributes the n-bit min-entropy to the independent mask, not the QKD source.Reconciliation and correctness-verification leakage is accounted for before privacy amplification.Source: §D.1 · p. 20

Final-key confidentiality

  • After successful reconciliation, privacy amplification yields a final key εPA-close to an independent uniform key, and the combined provider-compromise advantage is negligible.The argument does not rely on QKD-secrecy or acquisition-security assumptions in this compromise branch.Source: §D.1 · p. 20

D.2 Proof of Masking-Compromise Final-Key Confidentiality (Theorem 2)

The proof shows that exposing the masking state leaves final-key secrecy intact when the QKD execution and acquisition paths remain secure. Its argument reduces the disclosed mask to a public, reversible relabeling that preserves reconciliation and privacy amplification.

D.2 Proof of Masking-Compromise Final-Key Confidentiality (Theorem 2)

  • Revealing the masking state turns the mask into a public relabeling; the proof therefore needs no secrecy or pseudorandomness of that state.The reconciliation inputs are fixed before users derive the masking state.Source: §D.2 · pp. 20–21
  • DV masking preserves every disagreement position, while CV masking preserves soft-decision reliability and, under reconciliation equivariance, acceptance behavior and leakage bounds.For CV-QKD, the syndrome changes only by public offset Hz; the reconciled binary strings differ by the public XOR offset z.Source: §D.2 · pp. 20–21
  • Condition Q preserves the underlying QKD secrecy guarantee for the users’ pre-masking state, including adversarial quantum information and the QKD public transcript.The provider-side state containing target raw-key materials is not exposed under Q.Source: §D.2 · p. 21
  • The two acquisition-channel hybrids protect QKD-derived contents and ensure users accept provider-supplied payloads except with accounted-for channel failure probabilities.Unauthorized modification, injection, or replay is treated as a secure-channel integrity failure.Source: §D.2 · p. 21
  • For fixed z, XOR relabeling preserves universality of the privacy-amplification hash family, leaving the masked execution with the underlying execution’s secrecy guarantee.The implementation applies privacy amplification to the reconciled binary reference string.Source: §D.2 · p. 22
  • The final key remains εqkd-close to uniform and independent of the adversary’s complete side information when Q and A hold.The proof combines secure acquisition channels with the underlying QKD secrecy bound.Source: §D.2 · p. 22

D.3 Dual-Domain Compromise Resilience

RAMP retains final-key confidentiality if the masking domain is secure, or if both QKD-service secrecy and acquisition security hold. These complementary guarantees do not extend to compromise of both branches.

D.3 Dual-Domain Compromise Resilience

  • RAMP provides final-key confidentiality when M∨(Q∧A) holds.If M fails, the guarantee requires both Q and A; RAMP makes no claim when ¬M∧(¬Q∨¬A).Source: §D.3 · p. 22
  • With M secure, provider-side QKD and acquisition state may be exposed; with Q and A secure, the complete masking state may be exposed.The two cases rest on different security foundations: computational confidentiality in the provider-compromise case and the underlying QKD secrecy guarantee in the masking-compromise case.Source: §D.3 · p. 22
  • The guarantee is limited to either a secure masking domain or jointly secure QKD-service and acquisition conditions.No final-key confidentiality claim is made when the masking condition fails and either Q or A also fails.Source: §D.3 · p. 22

E More on QKD Experiment

The experiment uses field-acquired CV-QKD material and locally performed user-side post-processing. The implementation specifies the metadata and decoding, verification, and privacy-amplification steps needed to process that material.

E.1 QKD Testbed

  • The qOptica 100 testbed uses heterodyne, reverse-reconciled CV-QKD over a deployed 13.7 km metropolitan fibre loop.The acquired material reflects installed field fibre rather than a laboratory spool, back-to-back, or simulated channel.Source: §E.1 · p. 22
  • CV-QKD post-processing uses metadata for shot-noise calibration, detector parameters, channel estimates, LDPC configuration, and protocol partitioning.Providers supply calibration and protocol metadata, while users locally estimate security-critical transmittance and excess noise; metadata authentication does not establish correctness under provider corruption.Source: §E.1 · p. 22

E.2 Post-Processing Details

  • The pipeline performs parameter estimation, multidimensional reconciliation, LDPC decoding, verification, and privacy amplification, with masking before reconciliation.It uses octonion-based 8-dimensional mappings, soft-input belief-propagation decoding, and LDPC codes of length 2 × 10^6 bits at rate 1/10.Source: §E.2 · p. 23
  • Implementation choices include vectorized belief propagation, joint two-quadrature parameter estimation, and FFT-based Toeplitz hashing.The FFT extractor scales to aggregated inputs of order 10^9 bits; practical near-capacity reconciliation still requires careful LLR scaling, numerical stability, and decoder convergence.Source: §E.2 · p. 23

F Findings in Experiment:

The findings emphasize the asymmetric user-side workload and the separation between raw-key acquisition and final-key distillation. They identify user capability and optimized computation as relevant to practical deployment.

Asymmetry, Optimization, and Autonomy

  • Because LDPC reconciliation dominates processing time, user-side capability can guide deployment choices, and optimized implementations or commodity GPUs are expected to speed processing without changing RAMP’s workflow.The processing-time breakdown supports strategic adjustment to the asymmetric user-side workload.Source: Asymmetry, Optimization, and Autonomy · p. 23
  • Users can decide when and how much acquired raw key to process, provided they follow the post-processing procedure.The evaluation highlights decoupling between raw-key acquisition and final-key distillation.Source: Asymmetry, Optimization, and Autonomy · p. 23

F.1 Asymmetry in User-Side Processing Time

In the CV-QKD prototype, user-side processing is asymmetric: syndrome generation is lightweight, while LDPC decoding dominates; commodity GPUs are identified as an optimization path.

F.1 Asymmetry in User-Side Processing Time

  • The CV-QKD workload is asymmetric: U′ computes a syndrome with a lightweight sparse matrix-vector multiplication, while U performs iterative soft-input LDPC decoding and verification.This concentration of work allows a resource-constrained device to take the syndrome-generation role while the more capable endpoint handles reconciliation.Source: §F.1 · pp. 23–24
  • The prototype’s processing cost asymmetry comes from syndrome-based reconciliation, and its reported CPU performance is a conservative baseline without hardware acceleration.Source: §F.1 · p. 23, §F.2 · p. 24

F.2 Optimization with Commodity Hardware

  • Prior CV-QKD work reports GPU-parallel LDPC decoding and rate-adaptive GPU reconciliation, supporting commodity-GPU acceleration as a practical optimization direction,.Source: §F.2 · p. 24
  • The observed bottleneck is an optimizable LDPC-reconciliation implementation cost, not protocol-level overhead; commodity GPUs can handle the decoding-heavy role without specialized QKD hardware.The CPU result is described as a conservative baseline because the implementation uses no hardware acceleration.Source: §F.2 · p. 24

F.3 On-Demand Key Consumption and User Autonomy

RAMP separates provider-side raw-key generation from user-side key distillation, giving users flexibility over when and how much material to process. The authors also report limited supporting use of generative AI.

F.3 On-Demand Key Consumption and User Autonomy

  • Users can acquire provider-generated raw-key material and choose when and how much to process, adjusting batch size to available resources and desired key length within QKD post-processing conditions.Source: §F.3 · p. 24
  • Deferred processing requires locally protected raw-key blocks and lifecycle consistency so each block is used only once and eventually consumed or expired.Source: §F.3 · p. 24
  • Providers manage QKD devices and raw-key inventories, while users perform reconciliation and privacy amplification on demand, decoupling generation, acquisition, and final-key distillation.Source: §F.3 · p. 24

G Use of Generative AI

  • The authors report using ChatGPT for language polishing and prototype debugging, with suggested fixes manually reviewed, tested, and validated.Source: G Use of Generative AI · p. 24

Related papers

Loading 2610.22879v1…