Stručně
SealTask šifruje čitelný obsah pracovního prostoru na zařízení pomocí ChaCha20-Poly1305 ještě před synchronizací. Služba nemá klíče k jeho dešifrování, ale zpracovává účtová, fakturační, bezpečnostní, auditní, servisní a pracovní metadata. Uložený záložní klíč může jednou obnovit přístup po ztrátě hesla. Pro regulované použití jsou stále nutné příslušné smlouvy a kontroly.
Bezpečnostní pojmy mají popisovat hranici, ne zdobit tvrzení.
Pojmy používané na bezpečnostních, poradenských, srovnávacích a incidentních stránkách SealTask. Pojmy s úplným vysvětlením odkazují na svou kanonickou stránku.
Procházet celé centrum znalostíNáš základní princip.
Čitelný obsah pracovního prostoru se šifruje na zařízení před odesláním na naše servery. SealTask neumí dešifrovat otevřený text úkolů, poznámek, komentářů, checklistů, názvů seznamů ani příloh. Metadata uvedená níže služba nadále zpracovává. Této hranici obsahu říkáme zero-knowledge architekturou.
V čem je SealTask 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“
- • Únik nebo oprávněný přístup může odhalit čitelný obsah i metadata
SealTask (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 databáze může odhalit ciphertext a metadata, ne však čitelný obsah bez klientských klíčů
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.
Čitelný obsah se šifruje na zařízení; provozní metadata zůstávají viditelná serveru:
- Názvy a popisy pracovních seznamů
- Názvy úkolů, jejich obsah, checklisty a komentáře
- Obsah šablony opakovaného úkolu je šifrovaný; cron plán, časové pásmo, aktivní stav, iterace a časy materializace zůstávají viditelné serveru
- 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
Server ukládá šifrované payloady a zveřejněná provozní metadata; bez klientských klíčů neumí přečíst šifrovaný otevřený text.
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 pozvánek se zapisují do Merkleova logu. Dříve důvěryhodný checkpoint může při ověření odhalit nesoulad, ale současný klient nezůstává fail-closed ani toto zjištění neuchová: checkpoint může zahodit a ověření zopakovat od geneze
- Odebrání spolupracovníka zruší jeho serverem autorizovaný přístup k seznamu. Server, který změnu potvrdí, signalizuje aktivní streamy po commitu; změny z jiného serveru a hromadné či jinak nesignalizované změny se znovu ověří nejpozději do 30 sekund. Již doručená nebo transportem bufferovaná data nelze vzít zpět. Současná verze automaticky nerotuje klíč seznamu ani seznam znovu nešifruje a nesmaže obsah či klíče získané během oprávněného přístupu. Pro novou kryptografickou hranici vytvořte nový seznam jen pro aktuální členy.
Server kontroluje shodu HMAC bez dešifrování payloadu.
Přístup autorizuje stav relace a aktivního členství v databázi. Prohlížeč odděleně odvodí z klíče seznamu pomocí HKDF a pevné protokolové konstanty vazební klíč pro daný seznam; stejný klíč se zkopíruje ke každému členství a uloží na serveru.
Server tímto klíčem ověří HMAC nad ciphertextem. Důkaz pouze potvrzuje shodu HMAC s bajty ciphertextu, aniž by je server dešifroval.
- Prohlížeč odvodí vazební klíč pro daný seznam z klíče seznamu pomocí HKDF; nejde o dešifrovací klíč obsahu pracovního prostoru
- Server před autorizací požadavku ověří přihlášenou relaci a aktivní členství
- Server uloženým zkopírovaným klíčem ověří nebo sám vypočítá odpovídající HMAC nad ciphertextem
- HMAC nedokládá čerstvost, nebrání opakování, neváže payload na entitu ani člena a nedokládá jeho autenticitu vůči serveru
Co naše servery (ne)vidí.
NEVIDÍME
- × Čitelné názvy úkolů
- × Čitelné texty úkolů a poznámek
- × Čitelný obsah šablon opakovaných úkolů
- × Čitelné texty komentářů
- × Čitelný obsah checklistů
- × Čitelné názvy a popisy seznamů
- × Otevřený obsah příloh
- × Hesla k účtům v otevřené podobě
- × Dešifrovací klíče obsahu pracovního prostoru
Příklady viditelných metadat workspace (neúplný výčet)
- ✓ 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)
- ✓ Soli a důkazy jednotlivých členství a serverem uložený vazební klíč pro daný seznam, kterým server ověřuje nebo počítá odpovídající HMAC; nejde o dešifrovací klíč obsahu pracovního prostoru
- ✓ Plán opakování, časové pásmo, aktivní stav, iterace a časové údaje materializace
- ✓ Vztahy příloh, identifikátory úložiště, velikost ciphertextu, stav a časové údaje
- ✓ Typy událostí v reálném čase, identifikátory aktérů a entit, názvy změněných polí, časové údaje a počty zmeškaných událostí
Rozsah a citlivost: Zobrazený seznam uvádí neúplné příklady serverem viditelných metadat pracovního prostoru; nejde o úplný výčet aktuálních modelů persistence, odpovědí API ani událostí SSE. Nejde ani o úplný inventář osobních údajů: autentizace účtu, fakturace, bezpečnost a audit, prevence zneužití a telemetrie služby jsou samostatné oblasti popsané neúplně v zásadách ochrany osobních údajů. Metadata mohou být sama o sobě citlivá. Velikost ciphertextu přílohy obvykle přibližně prozrazuje velikost původního souboru.
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 šifrované payloady pracovního prostoru.
Backend nedešifruje šifrované payloady pracovního prostoru. Požadavky autorizují kontroly relace a členství v databázi. Uloženým vazebním klíčem pro daný seznam může server ověřit nebo vypočítat HMAC odpovídající ciphertextu; tím se dokládá shoda ciphertextu, nikoli čerstvost, ochrana proti opakování, vazba na entitu či člena ani autenticita vůči serveru.
Odebrání přístupu má omezený dosah a nepůsobí zpětně.
Odebrání spolupracovníka zruší jeho serverem autorizovaný přístup k seznamu. Server, který změnu potvrdí, signalizuje aktivní streamy po commitu; změny z jiného serveru a hromadné či jinak nesignalizované změny se znovu ověří nejpozději do 30 sekund. Již doručená nebo transportem bufferovaná data nelze vzít zpět. Současná verze automaticky nerotuje klíč seznamu ani seznam znovu nešifruje a nesmaže obsah či klíče získané během oprávněného přístupu. Pro novou kryptografickou hranici vytvořte nový seznam jen pro aktuální členy.
Transparentnost pozvánkových klíčů.
Veřejné klíče pozvánek jsou v append-only Merkleově stromu. Dříve důvěryhodný checkpoint může při ověření odhalit nesoulad, současný klient jej však může zahodit a zkusit vše znovu od geneze; tento pokus i první použití zůstávají hranicemi důvěry, nikoli bezpodmínečnou zárukou kontinuity.
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 9807) a HPKE
- Serverem uložený vazební klíč pro daný seznam umožňuje ověřit nebo vypočítat HMAC odpovídající ciphertextu; přístup autorizují kontroly relace a členství v databázi, zatímco HMAC nedokládá čerstvost, ochranu proti opakování, vazbu na entitu či člena ani autenticitu vůči serveru
- Merkleovy důkazy mohou ukázat nesoulad vůči důvěryhodnému checkpointu, současný klient jej však může zahodit a ověření zopakovat od geneze
- 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 SealTask
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 SealTask 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) |
| Dvoufaktorové ověření | TOTP z autentizační aplikace (RFC 6238) s jednorázovými záložními kódy; volitelné pro každý účet |
| 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 |
| Kontroly shody payloadu | 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. SealTask musí před jakýmkoli použitím PHI výslovně písemně souhlasit. Pokud se použije HIPAA, musí strany před použitím uzavřít BAA v souladu s HIPAA. Šifrování je jen jednou z ochran; potřebné provozní kontroly a posouzení dodavatele musí zajistit váš compliance program.
Časté otázky.
Co se stane, když vás někdo hackne?
Útočník databáze může získat ciphertext a účtová, směrovací, auditní a pracovní metadata. Uložený obsah bez klientských dešifrovacích klíčů nepřečte; ochrana závisí také na kryptografii, klientech a správě klíčů.
Mohou vás úřady donutit dešifrovat moje data?
Právní žádost může vyžadovat ciphertext a viditelná účtová, fakturační, bezpečnostní, auditní, servisní a pracovní metadata. Klíče potřebné k dešifrování čitelného obsahu nedržíme.
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, SealTask 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 SealTasku vidět moje data?
Zaměstnanci ani správci databáze nemají klientské klíče k dešifrování pracovních payloadů. Oprávněné systémy a osoby mohou přistupovat k metadatům uvedeným na této stránce.
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.
Podporuje SealTask dvoufaktorové ověření?
Ano. V nastavení zabezpečení můžete zapnout dvoufaktorové ověření pomocí autentizační aplikace (RFC 6238 TOTP) a uložit si jednorázové záložní kódy. Přihlášení pak vyžaduje heslo a aktuální kód. Chrání přihlášení k účtu a je oddělené od klientského šifrování, které chrání obsah pracovního prostoru.
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 9807: The OPAQUE Augmented 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ů
- 07 RFC 6238 — TOTP — Dvoufaktorové ověření
Připraveni na skutečné soukromí?
Připojte se k týmům, které důvěřují SealTasku, že jejich práce zůstane opravdu soukromá. Začněte na Free — bez platební karty.
Začít zdarmaMáte otázky k bezpečnosti? Napište nám na security@sealtask.com