Stručně
Worklist používá šifrování ChaCha20-Poly1305 a zero-knowledge architekturu. Data se šifrují na vašem zařízení pomocí dokumentovaných kryptografických primitiv dřív, než dorazí na naše servery. I s plným přístupem do databáze fyzicky neumíme vaše úkoly přečíst. Uložený záložní klíč může jednorázově obnovit přístup při ztrátě hesla, aniž by Worklist získal dešifrovací klíč. Podporuje minimalizaci dat podle GDPR a může pomoci s technickými zárukami pro HIPAA/SOC 2, pokud je doplněný o potřebné smlouvy a provozní kontroly.
Náš základní princip.
Vaše data se šifrují na vašem zařízení dříve, než dorazí na naše servery. Worklist je navržený tak, abychom my — firma — nemohli dešifrovat, číst ani přistupovat k vašim pracovním seznamům, úkolům a komentářům. Tomu se říká zero-knowledge architektura.
V čem je Worklist jiný.
Tradiční správa úkolů.
Co dělají konkurenti
- • Ukládají vaše data na serverech v čitelné podobě
- • Mohou číst každý úkol, komentář i soubor
- • Mohou obsah procházet kvůli reklamě, AI tréninku nebo „funkcím“
- • Při úniku dat odhalí všechno
Worklist (zero-knowledge).
Co děláme my
- • Šifruje na vašem zařízení ještě před odesláním na servery
- • Vaše úkoly neumíme dešifrovat, ani kdybychom chtěli
- • Žádné prohledávání, žádný trénink AI na vaší soukromé práci
- • Únik dat neodhalí nic smysluplného — jen šifrované bloky
Jak zero-knowledge šifrování funguje.
Vytvoříte si účet.
Při registraci heslo nikdy neopustí prohlížeč v čitelné podobě. Místo toho:
- Používáme protokol OPAQUE PAKE, takže servery nikdy nevidí vaše heslo v čitelné podobě
- Po úspěšné registraci nebo přihlášení OPAQUE předá prohlížeči tajný exportní klíč, který nikdy nedostaneme
- Na zařízení se vygeneruje náhodný 32bajtový „datový klíč“
- Tento datový klíč je lokálně zašifrovaný obalovacím klíčem odvozeným z exportního klíče OPAQUE
- Zašifrovaný datový klíč se uloží na našich serverech — ale bez odemykacího materiálu na klientovi ho nedešifrujeme
- Můžete si stáhnout jednorázový záložní klíč. V prohlížeči obalí stejný datový klíč a my uložíme jen šifrovanou obnovovací obálku
Klíčový bod: odemykací klíč i datový klíč zpracovává prohlížeč. Ukládáme jen šifrované obálky, nikdy čitelná hesla ani klíče workspace.
Proč šifrovaný datový klíč vůbec ukládáme?
Abyste se mohli přihlásit z jakéhokoli zařízení. Když přejdete na jiný počítač nebo telefon, pošleme zašifrovaný blok, prohlížeč ho po bezpečném přihlášení lokálně odemkne a jste zpět. Bez tohoto úložiště byste museli ručně přenášet 32bajtový klíč mezi zařízeními — strašný UX při stejné bezpečnosti.
Vytvoříte pracovní seznam nebo úkol.
Každý kus citlivých dat se zašifruje na vašem zařízení:
- Názvy seznamů, popisy a nastavení
- Názvy úkolů, jejich obsah, checklisty a komentáře
- Šablony opakovaných úkolů a rozvrhy
- Vše se šifruje pomocí ChaCha20-Poly1305 AEAD (moderní auditovaná šifra)
- Každý pracovní seznam má vlastní šifrovací klíč odvozený z vašeho datového klíče
Naše servery uchovávají jen zašifrovaný ciphertext — čitelný text z něj nepřečtou.
Pozvete členy týmu.
Při sdílení pracovních seznamů s kolegy:
- Každý člen dostane vlastní šifrovanou kopii klíče k seznamu
- Klíče se vyměňují přes HPKE (Hybrid Public Key Encryption)
- Veřejné klíče se publikují do logu transparentnosti (Merkle tree), což brání útokům typu man-in-the-middle
- Když člena odeberete, klíč seznamu se rotuje a všichni zbývající dostanou nové šifrované kopie
Naše servery ověřují, aniž by dešifrovaly.
Možná vás napadne: „Jak může server vynucovat oprávnění, když nedešifruje?“
Používáme HMAC důkazy — kryptografické podpisy, které dokáží, že máte právo k datům, aniž by odhalily čitelný obsah.
- Prohlížeč spočítá HMAC (klíčovaný hash) ze šifrovaných dat pomocí klíče specifického pro členství
- Server ověří HMAC, aby potvrdil, že jste aktivní člen
- Pokus o úpravu nebo přehrání cizích dat HMAC kontrolu neprojde
- Obsah nikdy nedešifrujeme — jen ověřujeme integritu a oprávnění
Co naše servery (ne)vidí.
NEVIDÍME
- × Názvy a popisy pracovních seznamů
- × Názvy úkolů, jejich obsah a checklisty
- × Komentáře a diskuze
- × Šablony opakovaných úkolů
- × Jakýkoli obsah v šifrovaných paketech
- × Vaše heslo (ani v podobě hashe)
VIDÍME
- ✓ E-mail účtu (pro přihlášení)
- ✓ Vztahy členství (kdo je v jakém seznamu)
- ✓ Stav úkolu (otevřený/uzavřený) a priorita
- ✓ Termíny a časové údaje
- ✓ Přiřazení delegací (jen ID uživatelů)
- ✓ Metadata potřebná pro dotazy (ID, data vzniku)
Proč jsou některá metadata viditelná: Některá pole (jako stav úkolu nebo termíny) musí být uložená v čitelné podobě, aby servery mohly efektivně filtrovat dotazy, posílat upomínky a udržovat indexy. Tato pole neobsahují žádný citlivý obsah — jen provozní metadata, díky kterým aplikace funguje.
Bezpečnostní záruky.
Odemykání ověřené heslem (jen na klientu).
Vaše heslo nikdy neopustí zařízení v čitelné podobě. Úspěšná autentizace OPAQUE dá prohlížeči exportní klíč, který lokálně rozbalí datový klíč. Z něj pak HKDF odvodí samostatné klíče pro každý pracovní seznam.
Server nedokáže dešifrovat data.
Backend nikdy nevolá operace dešifrování nad uživatelskými daty. Pouze ověřuje HMAC důkazy k potvrzení oprávnění.
Rotace klíčů při změně členů.
Když člena odeberete nebo odejde, klíč pracovního seznamu se rotuje. Všichni zbývající členové dostanou nové šifrované kopie, takže odešlý člen nemůže dešifrovat budoucí obsah.
Transparentnost pozvánkových klíčů.
Veřejné klíče pro pozvánky se zapisují do append-only Merkle tree. Klienti ověřují důkazy zařazení a konzistence, takže server nemůže potichu vyměnit klíče a odposlouchávat data.
Záložní klíče zůstávají zero-knowledge.
Záložní klíč vzniká v prohlížeči a musíte si ho uložit vy. Vytváří samostatnou šifrovanou obálku pro stejný datový klíč; ukládáme jen obnovovací credential file a šifrovanou obálku, takže bez uloženého klíče nemůžeme resetovat heslo ani číst data.
Open source kryptografie.
Používáme prověřené knihovny: strong-box (ChaCha20-Poly1305), OPAQUE (autentizace heslem), HKDF (odvozování klíčů), Argon2id (heslové zpevnění OPAQUE a legacy migrace) a HPKE (výměna klíčů). Veškerý kryptografický kód je open source a auditovatelný.
Jak ověřujeme naše zabezpečení.
Naše bezpečnostní tvrzení jsou ověřitelná, ne jen marketing. Takto zajišťujeme, že zero-knowledge architektura skutečně funguje, jak slibujeme:
- Open-source kryptografický kód na GitHubu k veřejnému auditu bezpečnostními experty
- Prověřené knihovny včetně ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) a HPKE
- Kryptografické důkazy (HMAC), které matematicky brání dešifrování na serveru
- Logy transparentnosti (Merkle trees) k odhalení útoků s podvržením klíčů
- Klientské odemykání z OPAQUE exportních klíčů zajišťuje, že nikdy nevidíme vaše heslo ani šifrovací klíče
- Jednorázové záložní klíče generuje a uchovává uživatel, nikdy Worklist
Kompromisy zero-knowledge.
Záložní klíč může obnovit přístup po ztrátě hesla.
Záložní klíč si jednou uložte a držte ho v soukromí. Pokud heslo ztratíte, tento klíč umožní heslo resetovat a zachovat přístup k šifrovaným datům. Protože Worklist neuchovává kopii, účty bez uloženého záložního klíče zůstávají neobnovitelné.
Žádné serverové vyhledávání.
Protože je obsah úkolů šifrovaný, neumíme nabídnout fulltextové vyhledávání na serveru napříč všemi úkoly. Vyhledávání probíhá v prohlížeči po dešifrování.
Zmírnění: Vyhledávání v prohlížeči optimalizujeme indexovanými dotazy a rychlým dešifrováním, aby zůstalo svižné.
Technické specifikace.
| Symetrické šifrování | ChaCha20-Poly1305 AEAD (přes knihovnu strong-box) |
| Odemčení datového klíče | OPAQUE export key + HKDF-SHA256 — odvozuje lokální obalovací klíče pro šifrovaný datový klíč |
| Hierarchie klíčů | HKDF-SHA256 — z datového klíče odvozuje klíče pro seznamy a členství |
| Autentizace heslem | OPAQUE PAKE (křivka Ristretto255) |
| Záložní klíče | Jeden aktivní jednorázový záložní klíč na uživatele; generuje se na klientovi a ukládá ho uživatel |
| Výměna klíčů (pozvánky) | HPKE (Hybrid Public Key Encryption) s X25519 |
| Integritní důkazy | HMAC-SHA256 |
| Serializace | CBOR (Concise Binary Object Representation) |
| Velikost klíče | 256 bitů (32 bajtů) pro všechny symetrické klíče |
Všechny kryptografické operace probíhají v prohlížeči pomocí WebCrypto API a auditovaných WASM modulů zkompilovaných z Rustu.
Audity a transparentnost.
Open source kryptografický stack.
Celá naše kryptografická implementace je open source a dostupná na GitHubu. Bezpečnostní výzkumníky vítáme, ať náš kód auditují.
Otevřít na GitHubuCompliance.
Zero-knowledge architektura podporuje minimalizaci dat podle GDPR a může pomoci s technickými zárukami pro HIPAA nebo SOC 2. Regulovaná PHI stále vyžadují písemnou smlouvu nebo BAA, provozní kontroly a potvrzení dodavatele podle vašeho compliance programu.
Časté otázky.
Co se stane, když vás někdo hackne?
Pokud se útočník dostane k naší databázi, uvidí jen šifrované bloky — v podstatě náhodné bajty. Bez odemčení ověřeného vaším heslem nebo uloženého záložního klíče je dnešní technologií matematicky nemožné je dešifrovat.
Mohou vás úřady donutit dešifrovat moje data?
Ne, protože to skutečně neumíme. Nemáme klíče. I se soudním příkazem můžeme poskytnout pouze šifrovaný ciphertext — bez odemčení ověřeného vaším heslem nebo záložního klíče, který jste si uložili, je k ničemu.
Co když zapomenu heslo?
Pokud jste si uložili záložní klíč, můžete ho jednou použít k resetu hesla a zachovat přístup k šifrovaným datům. Pokud jste si záložní klíč neuložili, Worklist za vás data obnovit nemůže.
Čím se to liší od „šifrování v klidu“?
„Šifrování v klidu“ znamená, že data jsou šifrovaná na discích serveru, ale server stále má klíče k dešifrování. End-to-end šifrování znamená, že klíče máte jen vy (koncové body) — server nikdy nemá přístup k čitelným datům.
Mohou zaměstnanci Worklistu vidět moje data?
Ne. Náš backend je navržen tak, aby uživatelská data nikdy nedešifroval. Ani správci databáze s plným přístupem k serverům nepřečtou vaše pracovní seznamy ani úkoly.
Co když chci data exportovat?
Dešifrovaná data můžete kdykoli z aplikace exportovat. Dešifrování probíhá v prohlížeči, takže dostanete čitelné soubory JSON/CSV — žádné šifrované bloky.
Odkazy a standardy.
Naše kryptografické volby odpovídají průmyslovým standardům a recenzovaným specifikacím.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Náš standard symetrického šifrování
- 02 RFC 9497: OPAQUE Asymmetric PAKE Protocol — Zero-knowledge autentizace heslem
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Výměna klíčů pro týmové pozvánky
- 04 RFC 9106: Argon2 Memory-Hard Function — Odvození klíče z hesla
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Federální kryptografické pokyny
- 06 GDPR Article 32: Security of Processing — Požadavky EU na ochranu osobních údajů
Připraveni na skutečné soukromí?
Připojte se k týmům, které důvěřují Worklistu, že jejich práce zůstane opravdu soukromá. Spusťte zkušební verzi — bez platební karty.
Spustit zkušební verziMáte otázky k bezpečnosti? Napište nám na security@worklist.app