TL;DR
SealTask cifra i contenuti leggibili dello spazio di lavoro sul tuo dispositivo con ChaCha20-Poly1305 prima della sincronizzazione. Il servizio non conserva le chiavi necessarie per decifrarli, ma continua a elaborare metadati di account, fatturazione, sicurezza, audit, servizio e spazio di lavoro. Una chiave di backup conservata da te può ripristinare l’accesso una volta dopo la perdita della password. Questo design favorisce la minimizzazione dei dati; l’uso regolamentato richiede comunque accordi e controlli appropriati.
Un termine di sicurezza deve descrivere un confine, non decorare un’affermazione.
Il vocabolario usato nelle pagine di sicurezza, guide, confronti e incidenti di SealTask. I termini con una spiegazione completa rimandano alla pagina canonica.
Esplora tutto il centro di apprendimentoIl nostro principio fondamentale.
I contenuti leggibili dello spazio di lavoro vengono cifrati sul tuo dispositivo prima di raggiungere i nostri server. SealTask è progettato affinché l’azienda non possa decifrare il testo leggibile di attività, note, commenti, checklist, titoli di liste o allegati. Il servizio continua a elaborare i metadati indicati di seguito. Questo confine applicato ai contenuti si chiama zero-knowledgearchitettura.
Cosa rende SealTask diverso.
Task manager tradizionali.
Cosa fanno i concorrenti
- • Memorizza i tuoi dati in chiaro sui loro server
- • Può leggere ogni attività, commento e file che crei
- • Può eseguire la scansione dei tuoi contenuti alla ricerca di annunci, addestramento AI o "funzionalità"
- • Una violazione o un percorso di accesso autorizzato può esporre contenuti leggibili e metadati
SealTask (zero-knowledge).
Cosa facciamo
- • Crittografa sul tuo dispositivo prima di inviarlo ai nostri server
- • Non possiamo decrittografare le tue attività, anche se lo volessimo
- • Nessuna scansione, nessuna addestramento AI sul tuo lavoro privato
- • Una violazione del database può esporre ciphertext e metadati, ma non contenuti leggibili senza le chiavi conservate dal client
Come la crittografia zero-knowledge funziona.
Crei il tuo account.
Quando ti registri, la tua password non lascia mai il tuo browser in chiaro. Invece:
- Usiamo il protocollo OPAQUE PAKE in modo che i nostri server non vedano mai la tua password in chiaro
- Dopo una registrazione o un accesso riuscito, OPAQUE consegna al browser una export key segreta che noi non riceviamo mai
- Sul tuo dispositivo viene generata una "chiave dati" casuale da 32 byte
- Questa chiave dati viene crittografata localmente con una chiave di wrapping derivata da quella export key OPAQUE
- La chiave dati crittografata è archiviata sui nostri server, manon possiamo decrittografarlasenza il materiale di sblocco lato client
- Puoi scaricare una chiave di riserva monouso. Avvolge la stessa chiave dati nel browser, e noi salviamo solo un wrapper di recupero crittografato
Punto chiave: la chiave di sblocco e la chiave dati vengono gestite nel tuo browser. Conserviamo solo wrapper crittografati, mai password in chiaro o chiavi del workspace.
Perché archiviare la chiave dati crittografata?
Così puoi accedere da qualsiasi dispositivo. Quando cambi computer o usi il telefono, inviamo il blob crittografato, il browser lo sblocca localmente dopo l'accesso sicuro e sei di nuovo dentro. Senza memorizzarlo, dovresti copiare manualmente una chiave da 32 byte tra i dispositivi: una pessima UX per la stessa sicurezza.
Crei un elenco di lavoro o un'attività.
I contenuti leggibili dello spazio di lavoro vengono cifrati sul tuo dispositivo; i metadati operativi restano visibili al server:
- Titoli e descrizioni delle liste di lavoro
- Titoli delle attività, descrizioni, liste di controllo e commenti
- Il contenuto del modello di attività ricorrente è cifrato; pianificazione cron, fuso orario, stato attivo, iterazione e timestamp di materializzazione restano visibili al server
- Tutto è crittografato utilizzandoChaCha20-Poly1305 AEAD(un codice moderno e controllato)
- Ogni lista di lavoro ha la propria chiave di crittografia univoca derivata dalla chiave dati
Il server memorizza payload cifrati dello spazio e i metadati operativi dichiarati; senza le chiavi conservate dal client non può leggere il testo leggibile cifrato.
Inviti i membri del team.
Quando condividi elenchi di lavoro con i membri del team:
- Ogni membro riceve la propria copia crittografata della chiave della lista di lavoro
- Le chiavi vengono scambiate utilizzandoHPKE(Crittografia ibrida a chiave pubblica)
- Le chiavi pubbliche degli inviti vengono registrate in un log di trasparenza Merkle. Un client che conserva un checkpoint precedentemente attendibile può rilevare una discrepanza durante la verifica, ma il client attuale non resta in modalità fail-closed né conserva il rilevamento: può eliminare il checkpoint e riprovare dalla genesi
- La rimozione di un collaboratore revoca il suo accesso alla lista autorizzato dal server. Il server che esegue il commit segnala poi i propri stream attivi; le modifiche provenienti da un altro server, in blocco o non segnalate vengono ricontrollate entro un massimo di 30 secondi. I dati già consegnati o memorizzati nel buffer di trasporto non possono essere richiamati. La versione attuale non ruota automaticamente la chiave della lista, non ricifra la lista e non cancella contenuti o chiavi ottenuti durante l’accesso autorizzato. Per un nuovo confine crittografico, crea una nuova lista riservata ai membri attuali.
Il server controlla la coerenza HMAC senza decifrare il payload.
Lo stato di sessione e appartenenza attiva nel database autorizza l’accesso. Separatamente, il browser deriva dalla chiave della lista, tramite HKDF e una costante fissa di protocollo, una chiave di associazione del payload specifica della lista; la stessa chiave viene copiata per ogni appartenenza e memorizzata dal server.
Il server usa quella chiave per verificare un HMAC sul ciphertext. La prova dimostra soltanto che l’HMAC corrisponde ai byte del ciphertext, senza decifrarli.
- Il browser deriva la chiave di associazione specifica della lista dalla chiave della lista tramite HKDF; non è una chiave di decifratura dei contenuti
- Il server controlla la sessione autenticata e l’appartenenza attiva prima di autorizzare la richiesta
- Il server memorizza la chiave di associazione copiata e può verificare o calcolare HMAC corrispondenti sul ciphertext
- L’HMAC non dimostra attualità, non impedisce la riproduzione, non associa un’entità o un membro e non autentica il payload nei confronti del server
Cosa possono fare i nostri server (e non può) vedere.
NON POSSIAMO vedere
- × Titoli leggibili delle attività
- × Testi leggibili di attività e note
- × Contenuti leggibili dei modelli di attività ricorrenti
- × Testi leggibili dei commenti
- × Contenuti leggibili delle checklist
- × Titoli e descrizioni leggibili delle liste
- × Testo in chiaro degli allegati
- × Password degli account in chiaro
- × Chiavi di decifratura dei contenuti dello spazio di lavoro
Esempi non esaustivi di metadati visibili dello spazio di lavoro
- ✓ E-mail dell'account utente (per l'accesso)
- ✓ Rapporti di appartenenza (chi è in quale lista di lavoro)
- ✓ Stato dell'attività (aperta/chiusa) e priorità
- ✓ Date di scadenza e timestamp
- ✓ Assegnazioni di delega (solo ID utente)
- ✓ Metadati necessari per le query (ID, date di creazione)
- ✓ Salt e prove per appartenenza, oltre alla chiave di associazione del payload specifica della lista memorizzata dal server per verificare o calcolare HMAC corrispondenti; non è una chiave di decifratura dei contenuti
- ✓ Pianificazione delle ricorrenze, fuso orario, stato attivo, iterazione e tempi di materializzazione
- ✓ Relazioni degli allegati, identificatori di archiviazione, dimensione del ciphertext, stato e timestamp
- ✓ Tipi di eventi in tempo reale, identificatori di attori ed entità, nomi dei campi modificati, timestamp e conteggi degli eventi persi
Ambito e sensibilità: L’elenco mostrato fornisce esempi non esaustivi dei metadati dello spazio di lavoro visibili al server; non è un inventario completo degli attuali modelli di persistenza, delle risposte API o degli eventi SSE. Non è neppure un inventario completo dei dati personali: autenticazione dell’account, fatturazione, sicurezza e audit, prevenzione degli abusi e telemetria del servizio sono ambiti distinti descritti in modo non esaustivo nell’informativa sulla privacy. I metadati possono essere sensibili. La dimensione del ciphertext di un allegato di solito approssima quella del file originale.
Sicurezza garanzie.
Sblocco autenticato dalla password (solo client).
La tua password non lascia mai il dispositivo in chiaro. Un'autenticazione OPAQUE riuscita consegna al browser una export key che sblocca localmente la chiave dati. La chiave dati viene quindi espansa con HKDF per derivare chiavi separate per ogni lista di lavoro.
Il server non può decrittografare i payload.
Il backend non decifra i payload cifrati dello spazio di lavoro. I controlli di sessione e appartenenza nel database autorizzano le richieste. Con la chiave di associazione specifica della lista che memorizza, il server può verificare o calcolare un HMAC corrispondente al ciphertext; ciò dimostra coerenza del ciphertext, non attualità, protezione dalla riproduzione, associazione a un’entità o membro né autenticità nei confronti del server.
La rimozione dell’accesso è limitata e non retroattiva.
La rimozione di un collaboratore revoca il suo accesso alla lista autorizzato dal server. Il server che esegue il commit segnala poi i propri stream attivi; le modifiche provenienti da un altro server, in blocco o non segnalate vengono ricontrollate entro un massimo di 30 secondi. I dati già consegnati o memorizzati nel buffer di trasporto non possono essere richiamati. La versione attuale non ruota automaticamente la chiave della lista, non ricifra la lista e non cancella contenuti o chiavi ottenuti durante l’accesso autorizzato. Per un nuovo confine crittografico, crea una nuova lista riservata ai membri attuali.
Invita la trasparenza chiave.
Le chiavi pubbliche degli inviti vengono registrate in un albero Merkle append-only. Un checkpoint precedentemente attendibile può far emergere una discrepanza durante la verifica, ma il client attuale può cancellarlo e riprovare dalla genesi; quel tentativo e il primo utilizzo restano confini di fiducia, non una prevenzione incondizionata.
Le chiavi di riserva restano zero-knowledge.
Una chiave di riserva viene generata nel browser e deve essere salvata da te. Crea un wrapper crittografato separato per la stessa chiave dati; noi memorizziamo solo il file credenziale di recupero e il wrapper crittografato, quindi non possiamo reimpostare la password o leggere i dati senza quella chiave salvata.
Crittografia open source.
Utilizziamo librerie testate sul campo: strong-box (ChaCha20-Poly1305), OPAQUE (autenticazione con password), HKDF (derivazione chiave), Argon2id (rafforzamento della password OPAQUE e migrazione legacy) e HPKE (scambio di chiavi). Tutto il nostro codice crittografico è open source e verificabile.
Come verifichiamo la nostra sicurezza.
Le nostre affermazioni sulla sicurezza sono verificabili, non solo marketing. Ecco come garantiamo che la nostra architettura zero-knowledge funzioni come promesso:
- Codice crittografico open source disponibile su GitHub per il controllo pubblico da parte dei ricercatori di sicurezza
- Librerie verificate in produzione tra cui ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9807) e HPKE
- La chiave di associazione specifica della lista memorizzata dal server gli consente di verificare o calcolare un HMAC corrispondente al ciphertext; sessione e appartenenza nel database autorizzano l’accesso, mentre l’HMAC non dimostra attualità, protezione dalla riproduzione, associazione a un’entità o membro né autenticità nei confronti del server
- Le prove Merkle possono mostrare una discrepanza rispetto a un checkpoint attendibile, ma il client attuale può eliminarlo e riprovare dalla genesi
- Lo sblocco lato client dalle export key OPAQUE garantisce che non vedremo mai la tua password o le chiavi di crittografia
- Le chiavi di riserva monouso sono generate e conservate dall'utente, mai da SealTask
Compromessi di zero-knowledge.
Una chiave di riserva può ripristinare l'accesso se perdi la password.
Salva una chiave di riserva una volta e tienila privata. Se perdi la password, quella chiave ti consente di reimpostarla e mantenere l'accesso ai dati crittografati. Poiché SealTask non ne conserva una copia, gli account senza una chiave di riserva salvata non possono essere recuperati.
Nessuna ricerca lato server.
Poiché il contenuto della tua attività è crittografato, non possiamo fornire la ricerca full-text lato server in tutte le tue attività. La ricerca avviene nel tuo browser dopo la decrittazione.
Mitigazione: ottimizziamo la ricerca lato client con ricerche indicizzate e decrittografia rapida per mantenerla performante.
Specifiche tecniche.
| Crittografia simmetrica | ChaCha20-Poly1305 AEAD (tramite la libreria strong-box) |
| Sblocco della chiave dati | Export key OPAQUE + HKDF-SHA256 — deriva chiavi di wrapping locali per la chiave dati crittografata |
| Gerarchia delle chiavi | HKDF-SHA256 — deriva le chiavi delle liste di lavoro e delle appartenenze dalla chiave dati |
| Autenticazione con password | OPAQUE PAKE (curva Ristretto255) |
| Autenticazione a due fattori | TOTP da app di autenticazione (RFC 6238) con codici di riserva monouso; facoltativa per account |
| Chiavi di riserva | Una chiave di riserva attiva e monouso per utente; generata lato client e conservata dall'utente |
| Scambio di chiavi (inviti) | HPKE (Hybrid Public Key Encryption) con X25519 |
| Controlli di coerenza del payload | HMAC-SHA256 |
| Serializzazione | CBOR (Concise Binary Object Representation, rappresentazione binaria compatta degli oggetti) |
| Dimensione chiave | 256 bit (32 byte) per tutte le chiavi simmetriche |
Tutte le operazioni crittografiche avvengono nel tuo browser utilizzando le API WebCrypto e moduli WASM controllati compilati da Rust.
Audit e trasparenza.
Stack crittografico open source.
La nostra intera implementazione crittografica è open source e disponibile su GitHub. Diamo il benvenuto ai ricercatori di sicurezza per verificare il nostro codice.
Visualizza su GitHubConformità.
La nostra architettura zero-knowledge supporta la minimizzazione dei dati GDPR e può aiutare con le protezioni tecniche. SealTask deve accettare espressamente per iscritto prima di qualsiasi uso di PHI. Quando si applica HIPAA, le parti devono stipulare un BAA conforme a HIPAA prima dell'uso. La crittografia è solo una protezione; il programma di conformità deve assicurare i controlli operativi e la valutazione del fornitore necessari.
Domande comuni.
Cosa succede se vieni hackerato?
Un aggressore con accesso al database potrebbe ottenere ciphertext e metadati di account, instradamento, audit e spazio di lavoro. I contenuti memorizzati non sono leggibili senza le chiavi di decifratura conservate dal client, nei limiti della sicurezza di crittografia, client e gestione delle chiavi.
Le agenzie governative possono obbligarti a decrittografare i miei dati?
Una richiesta legale può imporci di fornire ciphertext e metadati visibili di account, fatturazione, sicurezza, audit, servizio e spazio di lavoro. Non conserviamo le chiavi necessarie per decifrare i contenuti leggibili dello spazio.
Cosa succede se dimentico la password?
Se hai salvato una chiave di riserva, puoi usarla una sola volta per reimpostare la password e mantenere l'accesso ai dati crittografati. Se non hai salvato una chiave di riserva, SealTask non può ripristinare i dati per te.
In cosa differisce da "crittografato a riposo"?
"Crittografato a riposo" significa che i dati sono crittografati sui dischi rigidi del server, ma il server ha ancora le chiavi per decrittografarli. La crittografia End-to-end significa che solo tu (gli endpoint) hai le chiavi: il server non ha mai accesso in testo normale.
I dipendenti SealTask possono vedere i miei dati?
Il personale di SealTask e gli amministratori del database non possiedono le chiavi del client necessarie per decifrare i payload dello spazio. I sistemi e le persone autorizzati possono comunque accedere ai metadati visibili descritti in questa pagina.
Cosa succede se voglio esportare i miei dati?
Puoi esportare i tuoi dati decrittografati in qualsiasi momento dall'app. Poiché la decrittografia avviene nel tuo browser, otterrai file JSON/CSV leggibili, non BLOB crittografati.
SealTask supporta l'autenticazione a due fattori?
Sì. Nelle impostazioni di sicurezza puoi attivare l'autenticazione a due fattori con un'app di autenticazione (RFC 6238 TOTP) e salvare codici di riserva monouso. L'accesso richiede poi la password e un codice corrente. Questo protegge l'accesso all'account ed è separato dalla crittografia lato client che protegge i contenuti dello spazio di lavoro.
Riferimenti e standard.
Le nostre scelte crittografiche seguono gli standard di settore e le specifiche sottoposte a revisione paritaria.
- 01 RFC 8439: ChaCha20 e Poly1305 per protocolli IETF — Il nostro standard di crittografia simmetrica
- 02 RFC 9807: protocollo OPAQUE PAKE aumentato — Zero-knowledge autenticazione tramite password
- 03 RFC 9180: crittografia ibrida a chiave pubblica (HPKE) — Scambio di chiavi per gli inviti del team
- 04 RFC 9106: funzione di memoria dura Argon2 — Derivazione della chiave basata su password
- 05 NIST SP 800-175B: Linee guida per l'utilizzo di standard crittografici — Guida crittografica federale
- 06 GDPR Articolo 32: Sicurezza del trattamento — Requisiti di protezione dei dati dell'UE
- 07 RFC 6238 — TOTP — Autenticazione a due fattori
Pronto per vera privacy?
Unisciti ai team che si affidano a SealTask per mantenere il proprio lavoro veramente privato. Inizia con Free: non è richiesta la carta di credito.
Inizia gratisHai domande di sicurezza? Inviaci un'e-mail a security@sealtask.com