Bezpečnostní whitepaper

1. Shrnutí

GrataQ je platforma pro bezpečný příjem citlivých dokumentů od externích odesílatelů. Kdokoli si nainstaluje aplikaci GrataQ, stává se příjemcem šifrovaných souborů — bez registrace na straně odesílatele, bez sdílení hesel, bez závislosti na třetí straně. Obsah je šifrován post-kvantovou kryptografií už na straně odesílatele (v prohlížeči nebo v nativní aplikaci), takže náš server vidí jen nečitelná data a obsah souborů nikdy nezná. Každý soubor má vlastní jednorázový klíč, takže prozrazení jednoho souboru neohrozí ostatní.

2. Řešený problém

Instituce denně přijímají citlivé dokumenty od externích osob: doklady totožnosti, smlouvy, lékařské zprávy, fotodokumentaci pojistných událostí. Běžné kanály mají strukturální slabiny:

• E-mail — typicky nešifrovaný přenos, kopie zůstávají na poštovních serverech, v zálohách a na sdílených discích. Odesílatel ani příjemce nemá kontrolu nad tím, kde data skončí.
• Cloudová úložiště — vyžadují registraci odesílatele a důvěru v provozovatele. Obsah je obvykle šifrován klíčem provozovatele, ne klíčem příjemce, takže provozovatel k datům technicky přístup má.
• Messengery — vyžadují, aby obě strany používaly stejnou platformu, a většina spoléhá na klasickou kryptografii zranitelnou kvantovými počítači.

Nad tím stojí riziko „harvest now, decrypt later": provoz zachycený dnes může být dešifrován kvantovým počítačem v horizontu let. U dokumentů s dlouhou životností (smlouvy, identifikační doklady, zdravotnická dokumentace) je to reálná hrozba už v okamžiku přenosu. GrataQ proto šifruje obsah způsobem, který je navržen jako odolný i vůči kvantovým počítačům.

3. Kryptografický protokol

GrataQ nepoužívá žádnou vlastní kryptografii. Protokol stojí výhradně na NIST standardizovaných algoritmech na bezpečnostní úrovni NIST Level 3 (ekvivalent AES-192). Tyto algoritmy jsou dnes v provozu. Nasazeno

Volba Level 3 odpovídá průmyslovému konsensu (Signal, hybridní TLS v prohlížečích, primární doporučení NIST). Protokol je navržen tak, aby umožnil budoucí přechod na Level 5 bez změny celkové architektury.

3.1 ML-KEM — zapouzdření klíče

ML-KEM-768 je mechanismus zapouzdření klíče založený na problému učení s chybami nad mřížkami (Module-LWE). Pracuje ve třech operacích: generování páru klíčů (veřejný klíč 1 184 B, privátní klíč 2 400 B), zapouzdření nad veřejným klíčem příjemce (ciphertext 1 088 B + 256bitové sdílené tajemství) a rozbalení privátním klíčem (totéž sdílené tajemství). Sdílené tajemství slouží jako klíč pro AES-256-GCM. Tajemství dokáže z ciphertextu odvodit pouze držitel privátního klíče — tedy příjemce na svém zařízení.

3.2 ML-DSA — identita a autentizace

ML-DSA-65 je schéma digitálních podpisů nad mřížkami. Pár klíčů ML-DSA je identita účtu v GrataQ — žádné heslo, žádný OAuth, žádná závislost na třetí straně. Autentizace vůči serveru probíhá protokolem challenge-response: server pošle náhodný nonce, klient ho podepíše svým ML-DSA klíčem a server podpis ověří proti uloženému veřejnému klíči. Server tak nikdy nedrží žádné sdílené tajemství, kterým by se klient prokazoval.

3.3 Per-file forward secrecy

Pro každý soubor se použije unikátní jednorázový pár klíčů ML-KEM (pre-key). Příjemce vygeneruje 100 pre-keys, jejich veřejné části podepíše svým identitním klíčem ML-DSA a nahraje na server. Odesílatel si vyžádá jeden pre-key, provede zapouzdření a zašifruje soubor; po použití se pre-key smaže. Když zbývá méně než 20 nepoužitých pre-keys, aplikace automaticky dogeneruje další dávku. Řetězec pro jeden soubor je: 1 pre-key → 1 zapouzdření → 1 unikátní sdílené tajemství → 1 unikátní klíč AES-256. Kompromitace klíče jednoho souboru proto neohrozí žádný jiný soubor. Nasazeno

3.4 Formát šifrovaného payloadu

Payload je vždy ZIP archiv — ať se posílá jeden soubor, nebo dvacet. ZIP se vytvoří na straně odesílatele a teprve potom se zašifruje:

šifrovaný blob = AES-256-GCM( [1 B verze] + [ZIP data] )

Originální názvy souborů jsou součástí ZIP, tedy uvnitř šifrované obálky — server je nikdy nevidí. Jednotný formát zároveň umožňuje, aby web i nativní aplikace produkovaly stejný typ payloadu. Nasazeno

4. Architektura

Server je navržen jako „hloupý prostředník". Pouze přijímá a přeposílá podepsané pre-keys a šifrované bloby. Nedrží žádný privátní klíč, neukládá žádný plaintext a neukládá žádné identifikační údaje odesílatele (žádný e-mail, žádné telefonní číslo). Nasazeno

4.1 Datový model

Serverový datový model tvoří čtyři entity:

• Account — identifikátor účtu (ID), veřejný klíč ML-DSA a branding (název, logo, ověřená doména). Identifikátor účtu je odvozen z veřejného klíče, není to uživatelem volené jméno.
• PreKey — veřejný klíč ML-KEM spolu s podpisem ML-DSA, jednorázový.
• Blob — šifrovaný soubor čekající na vyzvednutí, uložený dočasně.
• Session — krátkodobý autentizační token.

4.2 Transportní bezpečnost

Komunikace mezi klientem a serverem je chráněna standardním TLS 1.3. Nasazeno Obsah souborů je ale chráněn post-kvantovou kryptografií nezávisle na TLS: i kdyby útočník s kvantovým počítačem prolomil zachycený TLS provoz, získal by metadata (kdo, komu, kdy), ne obsah souborů. Přechod na PQ-hybridní TLS (kombinace klasické a post-kvantové výměny klíče) je plánován po stabilizaci standardu. Roadmapa

5. Modely důvěry

GrataQ podporuje dva modely důvěry podle toho, zda komunikují jednotlivci, nebo instituce.

5.1 Model A — Fingerprint

Pro komunikaci mezi jednotlivci. Fingerprint je otisk SHA-256 veřejného klíče ML-DSA a zároveň slouží jako identifikátor účtu. Ověření probíhá out-of-band: telefonátem, při osobním setkání (QR kód) nebo jiným nezávislým kanálem. Bezpečnost nestojí na utajení fingerprintu, ale na tom, že příjemce porovná otisk získaný jinou cestou s otiskem klíče dodaného serverem. Nasazeno

5.2 Model B — Ověřená doména

Pro instituce. Instituce naváže svou identitu na vlastní doménu prostřednictvím kontroly DNS. Po úspěšném ověření se na upload stránce zobrazí příznak „Ověřená doména", takže odesílatel vidí, že stránka patří dané instituci. Tento postup byl reálně otestován v produkci. Nasazeno

5.3 Trust anchory po úrovních

Každý další nezávislý zdroj ověření zvyšuje náročnost útoku, protože útočník by musel kompromitovat několik nezávislých infrastruktur současně.

• Úroveň 1 — Ověřená doména: navázání veřejného klíče na doménu instituce přes kontrolu DNS. Základní vrstva. Nasazeno
• Úroveň 2 — DNSSEC + DNS TXT: otisk veřejného klíče zapsaný do DNS TXT záznamu pod DNSSEC. DNS je jiná infrastruktura než web, takže útočník by musel kompromitovat web i DNS i GrataQ současně. Roadmapa
• Úroveň 3 — Transparency log: každá registrace a změna klíče by se zapisovala do veřejného append-only Merkle logu (Sigstore Rekor), který lze nezávisle auditovat a jehož záznamy nelze zpětně měnit. Roadmapa

6. Co server nemůže

Architektura je navržena tak, aby kompromitace serveru měla minimální dopad. Server konkrétně:

• nedokáže dešifrovat obsah — nemá žádný privátní klíč; ten existuje jen na zařízení příjemce;
• nemůže podstrčit falešný klíč — pre-keys jsou podepsané identitním klíčem příjemce a u instituce navázané na ověřenou doménu;
• nedokáže identifikovat odesílatele — neukládá žádné registrační ani kontaktní údaje odesílatele;
• nemůže nepozorovaně změnit data — autentizační tag AES-256-GCM jakoukoli změnu šifrovaného blobu odhalí při dešifrování.

7. Ověření autenticity obsahu (C2PA) Roadmapa

C2PA (Coalition for Content Provenance and Authenticity) je otevřený standard pro ověřitelnou provenienci digitálního obsahu. C2PA manifest je kryptograficky podepsaná struktura vložená přímo v souboru, která zaznamenává, kdo obsah vytvořil, kdy, jakým zařízením a jaké úpravy proběhly. Některá moderní zařízení tento manifest generují už při pořízení snímku.

Plán integrace: GrataQ by zachoval C2PA manifest beze změny po celou cestu (ZIP → šifrování → přenos → dešifrování) a aplikace příjemce by manifest po dešifrování automaticky ověřila a zobrazila informace o provenienci. Tím by vznikl doložitelný řetězec od pořízení obsahu až po jeho bezpečné doručení. Tato funkce je součástí roadmapy a zatím není nasazena. Roadmapa

8. Technologický stack

• Server — C# / .NET 10 s nativní podporou ML-KEM a ML-DSA. Nasazeno
• Klientská aplikace — desktopová aplikace pro Windows. Nasazeno Multiplatformní verze (macOS, iOS, Android) postavená na .NET MAUI je plánovaná. Roadmapa
• Webová upload stránka — statická stránka, šifrování probíhá kompletně v prohlížeči odesílatele pomocí @noble/post-quantum, JSZip a Web Crypto API, bez registrace a bez instalace. Nasazeno

9. Roadmapa

Následující funkce jsou plánované a zatím nejsou nasazené.

Fáze 3 — Nativní odesílatel a řetězec důvěry Roadmapa

• Nativní odesílací aplikace s přímou integrací fotoaparátu.
• Zachování a ověřování C2PA provenience.
• App Attest (iOS) a Play Integrity (Android) pro důkaz integrity odesílací aplikace.
• Transparency log Sigstore Rekor jako další trust anchor.

Fáze 4 — Enterprise Roadmapa

• API a webhooky pro napojení na interní systémy.
• On-premise verze.
• Podpora HSM.
• Auditní logy a compliance reporty.
• Napojení na státní PKI.

10. Transparentnost

Protokol i použité algoritmy jsou popsány otevřeně — v souladu s Kerckhoffsovým principem nestojí bezpečnost na jejich utajení. Veřejné jsou protokol, algoritmy a architektura (tento dokument); soukromé zůstávají privátní klíče uživatelů, detaily nasazení serverové infrastruktury a obchodní logika.

Součástí budování důvěry je plánovaný nezávislý bezpečnostní audit a bug bounty program. Roadmapa

---

Související dokumenty pro bezpečnostní tým:

Threat model — přehled hrozeb a jejich mitigací.

Životní cyklus klíčů — generování, podepisování, doplňování a mazání klíčů.

Co server ukládá a loguje — přesný výčet dat na straně serveru.