Technische Samenvatting: QSecureMail

Probleemstelling

De komst van quantumcomputing vormt een fundamentele bedreiging voor klassieke publieke-sleutelcryptografie, waardoor huidige e-mailsystemen kwetsbaar worden voor "harvest-now-decrypt-later" (HNDL)-aanvallen. Terwijl Quantum Key Distribution (QKD) informatie-theoretische veiligheid biedt en Post-Quantum Cryptography (PQC) algoritmische veerkracht biedt, staat de praktische implementatie voor een kritieke flessenhals: resourcebeheer. QKD-systemen genereren sleutels tegen beperkte, variabele snelheden, terwijl het volume en de omvang van e-mailverkeer onvoorspelbaar zijn. Bestaande oplossingen falen vaak in het overbruggen van de kloof tussen de fysieke beperkingen van quantumhardware en de dynamische vereisten van e-mailsystemen, wat leidt tot potentiële onderbrekingen van de dienstverlening of inefficiënt sleutelverbruik.

Methodologie

De auteur stelt QSecureMail voor, een e-mailclient-systeem dat ontworpen is om te opereren over bestaande infrastructuur door middel van integratie van QKD en PQC. Het systeem is gebouwd op een drielaagse architectuur: een React/Vite frontend, een Node.js/Express backend, en een ETSI GS QKD 014-conforme Key Management (KM) infrastructuur.

Kerncomponenten

1. Adaptive Security Policy Engine (ASPE):
   De ASPE fungeert als de centrale besluitvormingslaag, die dynamisch encryptieniveaus selecteert op basis van de real-time "poolgezondheid" (de ratio van beschikbare sleutels ten opzichte van de totale poolgrootte). Het maakt gebruik van een hysteresis-mechanisme om snelle oscillatie tussen beveiligingsniveaus onder fluctuerende belastingsomstandigheden te voorkomen. De engine monitort de e-mailverzendsnelheid ($\lambda_{email}$) en de sleutelvernieuwingssnelheden om drempelwaarden te kalibreren, waardoor wordt gewaarborgd dat de sleutelpool niet uitgeput raakt tijdens verkeer met een hoog volume. Indien het KM-systeem onbereikbaar wordt, degradeert het systeem gracieus naar een klassieke AES-256-GCM modus (Niveau 4).

2. Drielagen Encryptie-engine:
   Het systeem definieert drie verschillende encryptieniveaus, waarbij een balans wordt gezocht tussen beveiligingsgaranties en sleutelverbruik:

   • Niveau 1 (Geauthenticeerde QKD-OTP): Maakt gebruik van een echte One-Time Pad (OTP) afgeleid van QKD-sleutels voor perfecte geheimhouding, aangevuld met een HMAC-SHA256 tag voor integriteit. Dit niveau verbruikt $\lceil|m|/32\rceil + 1$ sleutels per bericht, wat het zeer veilig maar ook zeer resource-intensief maakt.
   • Niveau 2 (Quantum-ondersteunde AES-256-GCM): Gebruikt een enkele 256-bits QKD-sleutel om een AES-sessiesleutel af te leiden via HKDF-SHA256. Dit biedt computationele veiligheid gevoed door quantumrandomiteit en verbruikt exact één sleutel per e-mail, ongeacht de payload-grootte.
   • Niveau 3 (Hybride QKD⊕PQC): De nieuwe bijdrage van het artikel. Dit schema combineert een QKD-afgeleide sleutel ($k_{QKD}$) met een gedeeld geheim van een ML-KEM-1024 (FIPS 203) encapsulatie ($k_{PQC}$) middels een bitwise XOR-operatie ($k_{fused} = k_{QKD} \oplus k_{PQC}$). De gefuseerde sleutel stuurt de AES-256-GCM encryptie aan. Deze constructie garandeert veiligheid zolang ofwel het QKD-kanaal veilig blijft, ofwel het PQC-algoritme onbreekt blijft.

3. Beveiligingsattestatie:
   Het systeem voegt een gestructureerde X-QSecureMail-Security-Profile MIME-header toe aan elk bericht. Deze header codeert het encryptieniveau, een fragment van de sleutelidentificatie, de tijdstempel en het algoritme, wat transparante auditing van de beveiligingsstatus mogelijk maakt zonder dat decryptie vereist is.

Belangrijkste Bijdragen

Het artikel identificeert vier primaire bijdragen:

1. Adaptive Security Policy Engine (ASPE): Een operationele laag die de afweging tussen beveiliging en beschikbaarheid beheert. Het gebruikt hysteresis en online kalibratie om uitputting van de sleutelpool te voorkomen en behoudt Niveau 1 (OTP) voor kritieke berichten wanneer de middelen dit toestaan.
2. Hybride QKD⊕PQC Encryptie (Niveau 3): Een geformaliseerde constructie die ML-KEM-1024 combineert met ETSI GS QDK 014 sleutels. De auteur biedt Stelling 1, die bewijst dat de gefuseerde sleutel computationeel ononderscheidbaar is van een uniforme verdeling indien ten minste één van de component-sleutels uniform is, wat defensie-in-diepte biedt tegen zowel wiskundige doorbraken als fysieke kanaalaanvallen.
3. Geauthenticeerde QKD-OTP (Niveau 1): Een constructie die de malleability-zwakte van klassieke OTP's oplost door cipherteksten te authenticeren met een aparte QKD-afgeleide HMAC-sleutel.
4. Transparante Beveiligingsattestatie: Een mechanisme voor het loggen en auditen van de quantum-beveiligingsstatus van individuele e-mails via standaard headers.

Resultaten en Evaluatie

De auteur heeft een referentiemateriaal geïmplementeerd en prestatie-evaluaties uitgevoerd met behulp van een in-process KM-simulator (die QKD-hardware simuleert via ETSI 014 API's).

• Latentie:
  • Niveau 1 (OTP): De latentie schaalt lineair met de payload-grootte vanwege sequentiële sleutelretrievals. Voor een bericht van 100 KB bedraagt de gemiddelde latentie 1,373 ms.
  • Niveau 2 (QKD-AES): De latentie is laag en schaalt minimaal met de grootte (0,170 ms voor 10 KB), omdat het slechts één sleutel vereist.
  • Niveau 3 (Hybride): Introduceert een vaste computationele overhead door de ML-KEM-1024 encapsulatie. De gemiddelde latentie bedraagt ongeveer 2,2–2,7 ms over alle payload-groottes (1 KB tot 100 KB). Dit bevestigt dat het hybride schema een vaste kostenpost toevoegt in plaats van een proportionele.
• Sleutelverbruik & Pool Duurzaamheid:
  • Niveau 1 verbruikt ongeveer 321 sleutels voor een 10 KB e-mail ($\kappa_1 \approx 321$), terwijl Niveau 2 en 3 slechts 1 sleutel verbruiken ($\kappa_{2,3} = 1$).
  • Simulaties tonen aan dat bij een snelheid van 100 e-mails/uur een pool van 1.000 sleutels in ~1,87 minuten uitgeput raakt bij Niveau 1, maar ~10 uur meegaat bij Niveau 2 en 3. Dit 321-voudige verschil valideert de noodzaak van de adaptieve drempels van de ASPE.
• Correctheid: Unit-tests bevestigden de round-trip correctheid, de integriteit van de ciphertekst (detectie van manipulatie), sleutelisolatie (ontvanger-binding) en de onafhankelijkheid van de QKD- en PQC-componenten.

Betekenis en Claims

Het artikel claimt dat QSecureMail een haalbare aanpak biedt voor het implementeren van quantum-veilige e-mail over bestaande infrastructuur, zonder dat wijzigingen in de onderliggende e-mailtransportprotocollen (SMTP/IMAP) vereist zijn.

• Praktiseerbaarheid: Door de grens van de quantumhardware (ETSI 014 API) te ontkoppelen van de applicatielogica, kan het systeem integreren met fysieke QKD-hardware zodra deze beschikbaar komt.
• HNDL-resistentie: Het gebruik van verse QKD-afgeleide sleutels voor elke e-mail pakt de HNDL-dreiging direct aan, waardoor wordt gegarandeerd dat gearchiveerde cipherteksten zelfs niet gedecodeerd kunnen worden als een tegenstander uiteindelijk een quantumcomputer bezit.
• Defensie-in-Diepte: Het Niveau 3 hybride schema biedt een robuuste fallback; als het PQC-algoritme wordt doorbroken, behoudt de QKD-component (in hardwareconfiguraties) de veiligheid, en vice versa.
• Operationele Continuïteit: De ASPE zorgt ervoor dat de e-maildienst beschikbaar blijft, zelfs onder hoge belasting of sleuteltekort, door dynamisch te degraderen naar minder resource-intensieve encryptieniveaus zonder de beveiliging van kritieke berichten in gevaar te brengen.

De auteur neemt een bescheiden standpunt in door te erkennen dat de huidige implementatie steunt op een softwarematige KM-simulator en dat toekomstig werk gericht moet zijn op de integratie met fysieke QKD-hardware, cross-instance sleuteldistributie en de formele verificatie van de policy engine. Desalniettemin demonstreert de architectuur dat een transitie naar quantum-veilige e-mail haalbaar is met de huidige commodity client-hardware en gestandaardiseerde interfaces.