9. Pilotinio projekto planas
Siūlomas Pilotas sudarytas iš trijų etapų. Pirmasis etapas įrodo, kad PQC envelope gali patikimai veikti virš Reticulum. Antrasis etapas įveda vartų modelį ir politiką. Trečiasis etapas prideda QKD/KME simuliatorių arba realų KME, jeigu jis prieinamas laboratorijoje.
9.2. Trijų etapų planas
Aplikacinis MVP
Tikslas: sukurti paprastą PQC envelope virš Reticulum Link tarp dviejų mazgų.
Rezultatas: veikiantis demo — ML-KEM raktų sudarymas, AEAD pranešimas, audit log, payload fragmentacijos matavimas.
Vartų modelis
Tikslas: įdiegti PQC Bridge A/B kaip saugumo domenų vartus ir pridėti politiką.
Rezultatas: gateway scenarijus su suite_id, fail-closed/fallback politika, session registry, rnstatus/rnpath metrikomis.
QKD/KME adapteris
Tikslas: pridėti KME simuliatorių arba realų QKD KME ir sujungti QKD raktą su ML-KEM paslaptimi.
Rezultatas: hibridinis PQC ir QKD demo su key_id, raktų fondo metrika, klaidų režimu ir galutine testų ataskaita.
9.3. KPI ir priėmimo kriterijai
| KPI | Tikslinė reikšmė MVP | Kodėl svarbu |
|---|---|---|
| PQC handshake sėkmės dalis | ≥ 95% kontroliuojamame TCP/Wi-Fi bandyme | Rodo bazinį protokolo stabilumą. |
| LoRa/RNode handshake sėkmės dalis | Matavimo KPI, ne iš anksto nustatytas tikslas | Rodo realų postkvantinio overhead tinkamumą žemo pralaidumo terpei. |
| Papildomas baitų kiekis vienai sesijai | Išmatuotas ir dokumentuotas pagal suite_id | Reikalinga optimizacijai ir atitikties argumentavimui. |
| Vidutinė handshake trukmė | Atskirai TCP / Wi-Fi / LoRa scenarijams | Leidžia spręsti dėl sesijos galiojimo laiko ir rotacijos intervalo. |
| "Downgrade" bandymo blokavimas | 100% blokuojama pagal politiką | Būtinas saugumo kontrolės kriterijus. |
| Audit log pilnumas | 100% sesijų turi suite_id, rns_destination, timestamp, key_id, statusą | Būtina kriptoinventoriui ir saugumo peržiūrai. |
| QKD key_id panaudojimo kontrolė | 0 pakartotinio nekontroliuojamo naudojimo atvejų | Būtina QKD raktų gyvavimo ciklui. |
| Tilto (Bridge) proceso stabilumas | Nėra kritinių rnsd/bridge crash per 72 val. testą | Reikalinga vartų modelio brandai. |
9.4. Minimalus darbų sąrašas
| Komponentas | Darbas | Prioritetas |
|---|---|---|
| PQC envelope biblioteka | Apibrężti pranešimo formatą: version, suite_id, sender_bridge_id, rns_destination_hash, nonce, ciphertext, tag, optional key_id. | P1 |
| ML-KEM integracija | Naudoti ML-KEM-768 MVP, parengti testus ir pasirinkimo politiką ML-KEM-1024 scenarijui. | P1 |
| AEAD ir KDF | Įgyvendinti context-bound KDF, AEAD šifravimą, anti-replay sekos numerius. | P1 |
| RNS adapteris | RNS Link/Resource siuntimas, fragmentacijos matavimas, pakartotinių bandymų politika. | P1 |
| Audit log | JSONL arba SQLite logai: suite_id, algoritmai, hash, key_id, status, timings. | P1 |
| Gateway daemon | PQC Bridge A/B kaip systemd arba konteinerizuotas procesas su konfigūracija. | P2 |
| KME simuliatorius | REST/HTTPS testinis KME su key_id ir key pool būsenomis. | P2 |
| ResilQ/RQmod integracija | Generuoti CBOM ir QARS/PQC rizikos artefaktą iš sesijos duomenų. | P2 |
| Saugumo testai | Downgrade, replay, key reuse, malformed packet, path loss ir KME outage scenarijai. | P1 |
10. Išvados ir rekomendacijos
Keturios pagrindinės išvados
1. Reticulum NET yra stiprus kandidatas atsparaus ryšio sluoksniui —
jis palaiko heterogeniškas terpes, savikonfigūruojamą multi-hop transportą ir veikia
mažo pralaidumo bei didelės delsos aplinkose.
2. Reticulum neturi būti pristatomas kaip savaime postkvantiškai
saugus — jo baziniai asimetriniai primityvai yra ECC pagrindo. Postkvantinis saugumas
įvedamas per PQC Bridge.
3. Geriausias pirmas kelias yra aplikacinis PQC envelope virš RNS
Link/Resource, po to vartų lygmens PQC Bridge tarp saugumo domenų. QKD/KME integracija
— antras ar trečias etapas.
4. Reticulum core forkas su PQC primityvais turėtų būti atidėtas,
kol bus atlikti MVP matavimai ir saugumo peržiūra.
10.1. Rekomendacijos
- Patvirtinti „Reticulum kaip transportas, PQC Bridge kaip saugumo sluoksnis“ architektūrinį principą.
- Eksperimentiškai įgyvendinti MVP su ML-KEM-768, AEAD, audit log ir RNS Link/Resource perdavimu.
- Pirmajame etape nekurti Reticulum core forko ir nekeisti RNS wire-format.
- Įtraukti CBOM/kriptoinventoriaus generavimą, kad pilotas būtų naudingas ResilQ/RQmod demonstracijoms.
- Antrajame etape sukurti gateway/bridge paslaugą, skirtą saugumo domenų sujungimui.
- Trečiajame etape įtraukti QKD/KME adapterį pagal ETSI GS QKD 014 arba KME simuliatorių.
- Visuose etapuose matuoti ne tik kriptografinį sėkmingumą, bet ir realius tinklo parametrus: fragmentaciją, delsą, path discovery, throughput, raktų rotaciją ir raktų fondo būseną.
- Parengti atskirą saugumo testavimo planą: downgrade, replay, key reuse, malformed payload, KME outage, Reticulum path loss, gateway compromise prielaidos.
10.2. Sprendimo pozicionavimas
Reticulum NET ir PQC Bridge gali būti pozicionuojamas kaip „resilient quantum-safe overlay bridge“: atsparus, decentralizuotas, heterogeniškas ryšio sluoksnis, papildytas postkvantiniu raktų sudarymu, QKD raktų šaltinio galimybe, kriptoinventoriumi ir auditavimo įrodymais. Tai gerai dera su:
- KTU Kibernetinio saugumo kompetencijų centro infrastruktūra — kiber.ktu.edu
- RQmod krypti — rqmod.com
- SpinQ edukaciniu eksperimentavimu — spinq.lt
- EuroQCI/QCI praktinio pasirengimo logika — qci.lt
Priedas B. Sprendimo brandos lygiai
| Lygis | Aprašymas | Įrodymas |
|---|---|---|
| TRL 3 — koncepcinis demo | Veikia du mazgai, PQC envelope, rankinis testavimas. | Demo scenarijus, logai, pranešimo pavyzdžiai. |
| TRL 4 — laboratorinis prototipas | Automatizuoti testai per kelias RNS sąsajas, klaidų scenarijai. | Testų ataskaita, KPI, kriptoinventorius. |
| TRL 5 — relevant environment | Gateway modelis, KME simuliatorius arba realus KME, ilgesnis stabilumo testas. | 72 val. stabilumo testas, key_id kontrolė, security review. |
| TRL 6 — pilotas tarp domenų | Du saugumo domenai, politika, incidentų valdymas, dokumentuota eksploatacija. | Valdymo procedūros, audit logs, rizikos priėmimo sprendimas. |
11. Šaltiniai
- [R1] Reticulum Network Stack Manual 1.2.5, „What is Reticulum?“. markqvist.github.io/Reticulum/manual/whatis.html
- [R2] Reticulum Network Stack API Reference 1.2.5 — Packet, Link, Reticulum parameters. reticulum.network/manual/reference.html
- [R3] NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. csrc.nist.gov/pubs/fips/203/final
- [R4] NIST FIPS 204, Module-Lattice-Based Digital Signature Standard. csrc.nist.gov/pubs/fips/204/final
- [R5] NIST FIPS 205, Stateless Hash-Based Digital Signature Standard. csrc.nist.gov/pubs/fips/205/final
- [R6] NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms. csrc.nist.gov/pubs/sp/800/227/final
- [R7] IETF RFC 9794, Terminology for Post-Quantum Traditional Hybrid Schemes. datatracker.ietf.org/doc/html/rfc9794
- [R8] ETSI GS QKD 014 V1.1.1, Quantum Key Distribution; REST-based key delivery API. etsi.org/…/gs_qkd014v010101p.pdf
- [R9] ETSI Work Programme, QKD work items including GS QKD 014 update. portal.etsi.org/webapp/WorkProgram
- [R10] Open Quantum Safe liboqs algorithms and standardization status. openquantumsafe.org/liboqs/algorithms
Kontaktai
Klausimai apie pilotą, bendradarbiavimas ar domėjimasis Reticulum bendruomene?
info@reticulum.lt