Threat model

1. Účel a rozsah

GrataQ řeší jeden konkrétní úkol: bezpečný příjem souborů od třetích stran. Příjemce (instituce nebo profesionál) zveřejní přijímací odkaz; odesílatel přes něj nahraje soubor — buď ve webovém prohlížeči, nebo z desktopové aplikace. Tento threat model pokrývá právě tuto cestu: od okamžiku, kdy odesílatel vybere soubor, až po jeho dešifrování v aplikaci příjemce.

Perspektiva dokumentu je útočníkova: co může útočník v dané pozici získat a jak tomu architektura brání. Nepopisujeme zde marketingové vlastnosti ani interní procesy provozovatele — jen bezpečnostní vlastnosti samotného produktu a jejich hranice.

Mimo rozsah tohoto modelu jsou organizační opatření na straně instituce (vnitřní směrnice, školení, fyzická bezpečnost) a chování koncových zařízení mimo aplikaci GrataQ. Tam, kde se hranice dotýká endpointu, ji explicitně pojmenujeme v kapitole 6.

2. Chráněná aktiva

Aktiva seřazená podle priority ochrany:

• Důvěrnost obsahu souborů — vlastní data, která odesílatel nahrává (smlouvy, doklady, zdravotnická dokumentace). Nejcennější aktivum.
• Integrita obsahu — jistota, že přijatý soubor je přesně ten, který odesílatel odeslal, beze změny po cestě.
• Soukromí odesílatele — odesílatel se neregistruje, neposkytuje e-mail ani telefon. Server o něm záměrně neeviduje identifikační údaje.
• Soukromí příjemce — kdo přijímá soubory a jaké, nemá být zjistitelné nad rámec toho, co je technicky nezbytné pro doručení.
• Identita a klíče příjemce — privátní ML-DSA identita a ML-KEM klíče příjemce; jejich kompromitace by umožnila čtení doručených souborů a vydávání se za příjemce.
• Dostupnost — schopnost přijímat soubory; cíl útoku typu odepření služby (DoS).

3. Aktéři a útočníci

Uvažujeme následující útočníky a jejich schopnosti:

• Pasivní odposlech sítě — útočník zachytává provoz mezi odesílatelem/příjemcem a serverem. Zahrnuje scénář „harvest now, decrypt later": data uložená dnes mohou být dešifrována kvantovým počítačem za 5–15 let, což je u dokumentů s dlouhou životností (smlouvy, doklady totožnosti, zdravotní záznamy) reálná hrozba.
• Útočník s přístupem na server / kompromitovaný server — má plný přístup k datům uloženým na serveru, včetně databáze a blob úložiště. Může číst vše, co server skutečně drží.
• Útočník v síti (MITM) — aktivně zasahuje do komunikace, pokouší se podstrčit pozměněná data nebo falešné klíče.
• Útočník napodobující instituci — phishing a impersonace: nastaví falešnou přijímací stránku, aby odesílatel nahrál soubor jemu místo skutečné instituci.
• Zlomyslný odesílatel — nahrává malware nebo zneužívá službu (abuse, zahlcení).
• Ztráta nebo krádež zařízení příjemce — útočník získá fyzický přístup k zařízení, na kterém běží aplikace příjemce a jsou na něm privátní klíče.

4. Hranice důvěry

Data při příjmu procházejí čtyřmi zónami. Klíčové je, kde data přecházejí z důvěryhodné zóny do nedůvěryhodné:

1. Prohlížeč (nebo aplikace) odesílatele — důvěryhodná zóna pro tento přenos. Zde a jen zde se obsah šifruje, ještě než opustí zařízení.
2. Síť — nedůvěryhodná. Chráněna TLS 1.3; obsah je navíc zašifrovaný nezávisle na TLS.
3. Server — nedůvěryhodný prostředník. Vidí pouze zašifrovaný blob a technicky nutná metadata. Nemá žádný privátní klíč a obsah nedokáže přečíst.
4. Zařízení příjemce — důvěryhodná zóna. Jediné místo s privátním klíčem, jediné místo, kde se obsah dešifruje.

5. Co produkt chrání

Záruky, které architektura poskytuje proti útočníkům z kapitoly 3:

• Obsah je nečitelný pro server i odposlech — šifrování probíhá u odesílatele pomocí standardů ML-KEM-768 + AES-256-GCM (NIST Level 3). Odolnost platí i proti budoucímu kvantovému počítači, tedy i proti scénáři „harvest now, decrypt later".
• Integrita obsahu — každý balíček je chráněn autentizačním tagem AES-256-GCM; jakákoli změna šifrovaných dat po cestě je při dešifrování detekována a odmítnuta.
• Forward secrecy pro každý soubor zvlášť — každý soubor používá jednorázový ML-KEM pre-key (příjemce jich má nahráno 100, aplikace automaticky doplní, klesne-li jejich počet pod 20). Po použití se pre-key smaže. Kompromitace klíče jednoho souboru neohrozí žádný jiný.
• Ověření identity příjemce — odesílatel se ujistí, že šifruje pro správného příjemce: identita je vázána na otisk veřejného ML-DSA klíče (SHA-256, slouží zároveň jako identifikátor účtu) a volitelně na ověřenou doménu instituce (kontrola DNS).
• Autentizace bez hesla — přístup k účtu příjemce stojí na challenge-response podpisu ML-DSA-65, nikoli na sdíleném tajemství uloženém na serveru.
• Šifrovaný transport — veškerá komunikace s serverem běží přes TLS 1.3; ochrana obsahu je na TLS nezávislá vrstva navíc.

6. Co produkt výslovně NEchrání (non-goals)

Threat model má smysl jen tehdy, je-li upřímný o svých hranicích. Následující věci GrataQ nezaručuje:

• Metadata viditelná serveru — server pro doručení potřebuje a technicky vidí: kdo (který účet) je příjemcem, přibližně kdy přenos proběhl, IP adresu odesílatele v provozních záznamech a velikost zašifrovaného balíčku. Obsah ne, ale tato metadata ano.
• Bezpečnost koncového zařízení odesílatele — pokud je zařízení odesílatele infikované (keylogger, malware čtoucí obsah před zašifrováním), GrataQ to neřeší. Šifrujeme to, co dostaneme; co se děje před tím na napadeném endpointu, je mimo náš dosah.
• Bezpečnost koncového zařízení příjemce — po dešifrování je soubor v čitelné podobě na zařízení příjemce. Malware na tomto zařízení ho může přečíst. Ochrana endpointu je odpovědnost instituce.
• Co příjemce udělá s daty po dešifrování — další uložení, přeposlání, tisk či sdílení dešifrovaného obsahu jsou mimo kontrolu produktu.
• Obsah, který odesílatel prozradí mimo systém — pokud odesílatel pošle totéž navíc nezabezpečeným kanálem (běžný e-mail, chat), GrataQ to neovlivní.
• Antivirová kontrola obsahu — protože server obsah nevidí, nedokáže ho ani skenovat na malware. Případná kontrola obsahu probíhá až na zařízení příjemce po dešifrování, mimo službu. Je to přímý důsledek end-to-end šifrování, ne opomenutí.

7. Hrozby a mitigace

Shrnutí hlavních hrozeb, jejich závažnosti, mitigace a jejího aktuálního stavu. Stav rozlišuje, co je dnes nasazeno a co je na roadmapě.

8. Předpoklady a závislosti

Bezpečnostní záruky modelu platí za následujících předpokladů:

• Korektnost NIST-standardizovaných algoritmů — důvěřujeme bezpečnosti ML-KEM-768, ML-DSA-65 a AES-256-GCM tak, jak byly standardizovány.
• Korektnost klientského kódu na zařízení — předpokládáme, že aplikace (nebo upload skript) na zařízení odesílatele/příjemce skutečně provádí to, co deklaruje, a běží na nekompromitovaném endpointu.
• Integrita TLS — transportní vrstva (TLS 1.3) chrání metadata a zabraňuje běžnému MITM; ochrana obsahu je na ní nezávislá vrstva navíc.
• Důvěra v DNS u ověření domény — Model B (ověřená doména) se opírá o DNS; bez DNSSEC je DNS slabší článek (proto je DNSSEC na roadmapě).
• Uživatel chrání svůj klíč a zálohu — záruky padají, pokud uživatel vyzradí privátní klíč nebo zpřístupní zálohu identity.

9. Reziduální rizika

I po aplikaci výše uvedených mitigací zůstávají tato rizika; jsou vědomě přijata a plynou z povahy služby:

• Metadata — server nutně vidí, kdo je příjemce, přibližný čas přenosu, IP odesílatele a velikost balíčku. Obsah chráněn je, vzor komunikace zcela skrýt nelze.
• Koncová zařízení (endpoint) — kompromitace zařízení odesílatele před zašifrováním nebo příjemce po dešifrování leží mimo dosah produktu.
• Lidský faktor — phishing může uspět, pokud uživatel ignoruje ověření domény; vyzrazení klíče, zálohy nebo dešifrovaného obsahu mimo systém produkt neovlivní.

---

Související dokumenty pro bezpečnostní tým: Technický whitepaper · Životní cyklus klíčů · Co server ukládá a loguje.