TL;DR
SealTask versleutelt leesbare werkruimte-inhoud vóór synchronisatie op uw apparaat met ChaCha20-Poly1305. De dienst bezit niet de sleutels om die inhoud te ontsleutelen, maar verwerkt nog steeds account-, facturerings-, beveiligings-, audit-, service- en werkruimtemetadata. Een door u bewaarde back-upsleutel kan na wachtwoordverlies eenmaal toegang herstellen. Dit ontwerp ondersteunt dataminimalisatie; gereguleerd gebruik vereist nog steeds passende overeenkomsten en beheersmaatregelen.
Een beveiligingsterm moet een grens beschrijven, niet alleen een claim versieren.
De begrippen uit de beveiligings-, gids-, vergelijkings- en incidentpagina’s van SealTask. Begrippen met volledige uitleg verwijzen naar hun canonieke pagina.
Bekijk het volledige kenniscentrumOns kernprincipe.
Leesbare werkruimte-inhoud wordt op uw apparaat versleuteld voordat die onze servers bereikt. SealTask is zo ontworpen dat het bedrijf de leesbare tekst van taken, notities, opmerkingen, checklists, lijsttitels en bijlagen niet kan ontsleutelen. De dienst verwerkt de hieronder vermelde metadata nog steeds. Deze inhoudsgrens noemen we zero-knowledge architectuur.
Wat maakt SealTask anders.
Traditionele taakmanagers.
Wat concurrenten doen
- • Slaan uw gegevens in leesbare tekst op hun servers op
- • Kan elke taak, opmerking en bestand lezen dat u maakt
- • Kan uw inhoud scannen op advertenties, AI-training of ‘functies’
- • Een inbreuk of geautoriseerd toegangspad kan leesbare inhoud en metadata blootleggen
SealTask (zero-knowledge).
Wat wij doen
- • Versleutelt op uw apparaat voordat het naar onze servers wordt verzonden
- • We kunnen uw taken niet ontsleutelen, zelfs als we dat zouden willen
- • Geen scannen, geen AI-training op uw privéwerk
- • Een database-inbreuk kan ciphertext en metadata blootleggen, maar zonder client-side sleutels geen leesbare werkruimte-inhoud
Hoe zero-knowledge-versleuteling werkt.
U maakt uw account aan.
Wanneer u zich registreert, verlaat uw wachtwoord uw browser nooit in platte tekst. In plaats daarvan:
- Wij gebruiken het OPAQUE PAKE-protocol zodat onze servers uw wachtwoord in platte tekst nooit zien
- Na succesvolle registratie of aanmelding geeft OPAQUE uw browser een geheime exportkey die wij nooit ontvangen
- Er wordt een willekeurige ‘datasleutel’ van 32 bytes op uw apparaat gegenereerd
- Deze gegevenssleutel wordt lokaal versleuteld met een verpakkingssleutel die van die OPAQUE-exportkey is afgeleid
- De versleutelde gegevenssleutel wordt opgeslagen op onze servers, maar we kunnen hem niet ontsleutelen zonder het client-side ontgrendelingsmateriaal
- U kunt een eenmalige reservesleutel downloaden. Die verpakt dezelfde gegevenssleutel in uw browser; wij bewaren alleen een versleutelde herstelverpakking
Belangrijk punt: de ontgrendelingssleutel en gegevenssleutel worden in uw browser verwerkt. Wij bewaren alleen versleutelde verpakkingen, nooit platte wachtwoorden of workspace-sleutels.
Waarom de versleutelde gegevenssleutel opslaan?
Zo kunt u vanaf elk apparaat inloggen. Wanneer u van computer wisselt of uw telefoon gebruikt, sturen we de versleutelde blob, uw browser ontgrendelt die lokaal na veilige aanmelding en u bent weer binnen. Zonder dit op te slaan zou u handmatig een sleutel van 32 bytes tussen apparaten moeten kopiëren - een slechte gebruikerservaring voor dezelfde beveiliging.
U maakt een werklijst of taak.
Leesbare werkruimte-inhoud wordt op uw apparaat versleuteld; operationele metadata blijven zichtbaar voor de server:
- Titels en beschrijvingen van werklijsten
- Taaktitels, hoofdteksten, checklists en opmerkingen
- De inhoud van een terugkerende taaksjabloon is versleuteld; cronplanning, tijdzone, actieve status, iteratie en materialisatietijdstippen blijven zichtbaar voor de server
- Alles is versleuteld met behulp van ChaCha20-Poly1305 AEAD (een modern, gecontroleerd cijfer)
- Elke werklijst heeft zijn eigen unieke versleutelingssleutel, afgeleid van uw gegevenssleutel
De server bewaart versleutelde werkruimtepayloads en de bekendgemaakte operationele metadata; zonder client-side sleutels kan hij de versleutelde leesbare tekst niet lezen.
U nodigt teamleden uit.
Bij het delen van werklijsten met teamgenoten:
- Elk lid krijgt zijn eigen versleutelde kopie van de werklijstsleutel
- Sleutels worden uitgewisseld via HPKE (Hybride openbare sleutelversleuteling)
- Openbare uitnodigingssleutels worden vastgelegd in een Merkle-transparantielogboek. Een client met een eerder vertrouwd controlepunt kan tijdens verificatie een afwijking signaleren, maar de huidige client faalt niet gesloten en bewaart die detectie niet: hij kan het controlepunt wissen en opnieuw vanaf het begin proberen
- Het verwijderen van een medewerker trekt diens door de server geautoriseerde toegang tot de lijst in. De server die de wijziging committeert, signaleert daarna zijn actieve streams; wijzigingen van een andere server, bulkgewijze of niet-gesignaleerde wijzigingen worden uiterlijk binnen 30 seconden opnieuw gecontroleerd. Reeds afgeleverde of door het transport gebufferde gegevens kunnen niet worden teruggeroepen. De huidige versie roteert de lijstsleutel niet automatisch, versleutelt de lijst niet opnieuw en wist geen inhoud of sleutels die tijdens geautoriseerde toegang zijn verkregen. Maak voor een nieuwe cryptografische grens een nieuwe lijst voor alleen de huidige leden.
De server controleert HMAC-consistentie zonder de payload te ontsleutelen.
Databasestatus van sessie en actief lidmaatschap autoriseert toegang. Los daarvan leidt uw browser met HKDF en een vaste protocolconstante uit de lijstsleutel een lijstspecifieke payloadbindingssleutel af; dezelfde sleutel wordt voor elk lidmaatschap gekopieerd en door de server opgeslagen.
De server gebruikt die sleutel om een HMAC over ciphertext te verifiëren. Het bewijs toont alleen dat de HMAC met de ciphertextbytes overeenkomt, zonder ze te ontsleutelen.
- Uw browser leidt met HKDF de lijstspecifieke bindingssleutel af uit de lijstsleutel; dit is geen decryptiesleutel voor werkruimte-inhoud
- De server controleert de geauthenticeerde sessie en het actieve lidmaatschap voordat hij het verzoek autoriseert
- De server bewaart de gekopieerde bindingssleutel en kan overeenkomstige HMAC’s over ciphertext verifiëren of zelf berekenen
- De HMAC bewijst geen actualiteit of bescherming tegen replay, bindt geen entiteit of lid en bewijst geen authenticiteit tegenover de server
Wat onze servers wel en niet kunnen zien.
Wij KUNNEN NIET zien
- × Leesbare taaknamen
- × Leesbare taakteksten en notities
- × Leesbare inhoud van terugkerende taaksjablonen
- × Leesbare opmerkingen
- × Leesbare checklistinhoud
- × Leesbare lijsttitels en -beschrijvingen
- × Platte tekst van bijlagen
- × Accountwachtwoorden in platte tekst
- × Decryptiesleutels voor werkruimte-inhoud
Niet-uitputtende voorbeelden van zichtbare werkruimtemetadata
- ✓ E-mailadres van gebruikersaccount (voor inloggen)
- ✓ Lidmaatschapsrelaties (wie staat in welke werklijst)
- ✓ Taakstatus (open/gesloten) en prioriteit
- ✓ Vervaldata en tijdstempels
- ✓ Delegatietoewijzingen (alleen gebruikers-ID's)
- ✓ Metagegevens die nodig zijn voor zoekopdrachten (ID's, aanmaakdatums)
- ✓ Salts en bewijzen per lidmaatschap, plus de door de server opgeslagen lijstspecifieke payloadbindingssleutel waarmee de server overeenkomstige HMAC’s verifieert of berekent; dit is geen decryptiesleutel voor werkruimte-inhoud
- ✓ Herhalingsschema, tijdzone, actieve status, iteratie en materialisatietijdstippen
- ✓ Bijlagerelaties, opslag-ID’s, ciphertextgrootte, status en tijdstippen
- ✓ Realtime gebeurtenistypen, actor- en entiteits-ID’s, namen van gewijzigde velden, tijdstippen en aantallen gemiste gebeurtenissen
Reikwijdte en gevoeligheid: De getoonde lijst bevat niet-uitputtende voorbeelden van werkruimtemetadata die voor de server zichtbaar zijn; het is geen volledige inventaris van de huidige persistentiemodellen, API-antwoorden of SSE-gebeurtenissen. Het is ook geen volledige privacy-inventaris: accountauthenticatie, facturering, beveiliging en audit, misbruikpreventie en servicetelemetrie zijn afzonderlijke domeinen die niet-uitputtend in het privacybeleid worden beschreven. Metadata kunnen zelf gevoelig zijn. De grootte van ciphertext van een bijlage benadert doorgaans de oorspronkelijke bestandsgrootte.
Beveiliging garanties.
Met wachtwoord geverifieerde ontgrendeling (alleen client-side).
Uw wachtwoord verlaat uw apparaat nooit in leesbare tekst. Succesvolle OPAQUE-verificatie geeft uw browser een exportkey die uw gegevenssleutel lokaal uitpakt. Die gegevenssleutel wordt vervolgens uitgebreid met behulp van HKDF om voor elke werklijst afzonderlijke sleutels af te leiden.
De server kan de payloads niet ontsleutelen.
De backend ontsleutelt geen versleutelde werkruimtepayloads. Databasecontroles van sessie en lidmaatschap autoriseren verzoeken. Met de opgeslagen lijstspecifieke bindingssleutel kan de server een HMAC verifiëren of berekenen die overeenkomt met ciphertext; dat bewijst ciphertextconsistentie, niet actualiteit, replaybescherming, binding aan een entiteit of lid of authenticiteit tegenover de server.
Toegangsverwijdering is begrensd en niet met terugwerkende kracht.
Het verwijderen van een medewerker trekt diens door de server geautoriseerde toegang tot de lijst in. De server die de wijziging committeert, signaleert daarna zijn actieve streams; wijzigingen van een andere server, bulkgewijze of niet-gesignaleerde wijzigingen worden uiterlijk binnen 30 seconden opnieuw gecontroleerd. Reeds afgeleverde of door het transport gebufferde gegevens kunnen niet worden teruggeroepen. De huidige versie roteert de lijstsleutel niet automatisch, versleutelt de lijst niet opnieuw en wist geen inhoud of sleutels die tijdens geautoriseerde toegang zijn verkregen. Maak voor een nieuwe cryptografische grens een nieuwe lijst voor alleen de huidige leden.
Transparantie van uitnodigingssleutels.
Openbare uitnodigingssleutels worden in een append-only Merkle-boom vastgelegd. Een eerder vertrouwd controlepunt kan tijdens verificatie een afwijking zichtbaar maken, maar de huidige client kan het wissen en opnieuw vanaf het begin proberen; die poging en het eerste gebruik blijven vertrouwensgrenzen, geen onvoorwaardelijke preventie.
Reservesleutels blijven zero-knowledge.
Een reservesleutel wordt in uw browser gegenereerd en moet door u worden bewaard. Hij maakt een aparte versleutelde verpakking voor dezelfde gegevenssleutel; wij bewaren alleen het herstelcredentialbestand en de versleutelde verpakking, zodat we zonder die bewaarde sleutel uw wachtwoord niet kunnen resetten en uw gegevens niet kunnen lezen.
Open source-cryptografie.
We gebruiken beproefde bibliotheken: strong-box (ChaCha20-Poly1305), OPAQUE (wachtwoordauthenticatie), HKDF (sleutelafleiding), Argon2id (OPAQUE-wachtwoordverharding en legacy-migratie) en HPKE (sleuteluitwisseling). Al onze cryptocode is open source en controleerbaar.
Hoe we verifiëren onze veiligheid.
Onze beveiligingsclaims zijn verifieerbaar, niet alleen marketing. Zo zorgen we ervoor dat onze zero-knowledge-architectuur werkt zoals beloofd:
- Open-source cryptografische code beschikbaar op GitHub voor openbare audits door beveiligingsonderzoekers
- In de praktijk geteste bibliotheken, waaronder ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9807) en HPKE
- De door de server opgeslagen lijstspecifieke bindingssleutel laat de server een HMAC verifiëren of berekenen die overeenkomt met ciphertext; databasecontroles van sessie en lidmaatschap autoriseren toegang, terwijl de HMAC geen actualiteit, replaybescherming, binding aan een entiteit of lid of authenticiteit tegenover de server bewijst
- Merkle-bewijzen kunnen een afwijking ten opzichte van een vertrouwd controlepunt tonen, maar de huidige client kan dat punt wissen en opnieuw vanaf het begin proberen
- Client-side ontgrendeling vanuit OPAQUE-exportkeys zorgt ervoor dat we uw wachtwoord of versleutelingssleutels nooit zien
- Eenmalige reservesleutels worden door de gebruiker gegenereerd en bewaard, nooit door SealTask
Afwegingen van zero-knowledge.
Een reservesleutel kan toegang herstellen als u uw wachtwoord kwijtraakt.
Bewaar een reservesleutel eenmaal en houd hem privé. Als u uw wachtwoord kwijtraakt, kunt u met die sleutel het wachtwoord opnieuw instellen en toegang houden tot versleutelde gegevens. Omdat SealTask geen kopie bewaart, blijven accounts zonder bewaarde reservesleutel onherstelbaar.
Geen zoekopdracht op de server.
Omdat uw taakinhoud versleuteld is, kunnen we niet voor al uw taken op de server full-text zoeken. Zoeken gebeurt in uw browser na ontsleuteling.
Beperking: we optimaliseren zoeken aan de clientzijde met geïndexeerde zoekopdrachten en snelle ontsleuteling om de prestaties te behouden.
Technisch specificaties.
| Symmetrische versleuteling | ChaCha20-Poly1305 AEAD (via de strong-box-bibliotheek) |
| Gegevenssleutel ontgrendelen | OPAQUE-exportkey + HKDF-SHA256 — leidt lokale verpakkingssleutels af voor de versleutelde gegevenssleutel |
| Sleutelhiërarchie | HKDF-SHA256 — leidt werklijst- en lidmaatschapssleutels af van de gegevenssleutel |
| Wachtwoordverificatie | OPAQUE PAKE (Ristretto255 curve) |
| Tweefactorauthenticatie | TOTP via authenticator-app (RFC 6238) met eenmalige back-upcodes; optioneel per account |
| Reservesleutels | Een actieve eenmalige reservesleutel per gebruiker; client-side gegenereerd en door de gebruiker bewaard |
| Sleuteluitwisseling (uitnodigingen) | HPKE (Hybrid Public Key Encryption) met X25519 |
| Consistentiecontroles van payloads | HMAC-SHA256 |
| Serialisatie | CBOR (Concise Binary Object Representation) |
| Sleutelgrootte | 256-bit (32 bytes) voor alle symmetrische sleutels |
Alle cryptografische bewerkingen gebeuren in uw browser met behulp van WebCrypto API's en gecontroleerde WASM-modules samengesteld uit Rust.
Audits & transparantie.
Open source crypto-stack.
Onze gehele cryptografische implementatie is open source en beschikbaar op GitHub. We verwelkomen beveiligingsonderzoekers om onze code te controleren.
Bekijk op GitHubNaleving.
Onze zero-knowledge-architectuur ondersteunt AVG-dataminimalisatie en kan helpen met technische beveiligingen. SealTask moet vóór elk gebruik van PHI uitdrukkelijk schriftelijk instemmen. Wanneer HIPAA van toepassing is, moeten de partijen vóór gebruik een HIPAA-conforme BAA sluiten. Encryptie is slechts één beveiliging; uw nalevingsprogramma moet de vereiste operationele controles en leveranciersbeoordeling verzorgen.
Algemeen vragen.
Wat gebeurt er als u wordt gehackt?
Een databaseaanvaller kan ciphertext en account-, routerings-, audit- en werkruimtemetadata verkrijgen. Opgeslagen inhoud is niet leesbaar zonder de client-side decryptiesleutels, afhankelijk van de beveiliging van cryptografie, clients en sleutelbeheer.
Kunnen overheidsinstanties u dwingen mijn gegevens te ontsleutelen?
Een rechtsgeldig verzoek kan ons verplichten ciphertext en zichtbare account-, facturerings-, beveiligings-, audit-, service- en werkruimtemetadata te verstrekken. Wij bezitten niet de sleutels die nodig zijn om leesbare werkruimte-inhoud te ontsleutelen.
Wat als ik mijn wachtwoord vergeet?
Als u een reservesleutel hebt bewaard, kunt u die eenmaal gebruiken om uw wachtwoord opnieuw in te stellen en toegang tot uw versleutelde gegevens te behouden. Zonder bewaarde reservesleutel kan SealTask de gegevens niet voor u herstellen.
Hoe verschilt dit van “versleuteling voor opgeslagen gegevens”?
‘Versleuteld voor opgeslagen gegevens’ betekent dat gegevens op de harde schijven van de server worden versleuteld, maar dat de server nog steeds over sleutels kan beschikken om ze te ontsleutelen. End-to-end-versleuteling betekent dat alleen u (de eindpunten) de sleutels heeft; de server heeft nooit toegang tot platte tekst.
Kunnen medewerkers van SealTask mijn gegevens inzien?
Medewerkers en databasebeheerders van SealTask bezitten niet de client-side sleutels die nodig zijn om werkruimtepayloads te ontsleutelen. Geautoriseerde systemen en personen kunnen wel toegang hebben tot de zichtbare metadata die op deze pagina staan.
Wat moet ik doen als ik mijn gegevens wil exporteren?
U kunt uw ontsleutelde gegevens op elk gewenst moment vanuit de app exporteren. Omdat de ontsleuteling in uw browser plaatsvindt, krijgt u leesbare JSON/CSV-bestanden en geen versleutelde blobs.
Ondersteunt SealTask tweefactorauthenticatie?
Ja. U kunt in de beveiligingsinstellingen tweefactorauthenticatie met een authenticator-app (RFC 6238 TOTP) inschakelen en eenmalige back-upcodes opslaan. Inloggen vereist daarna uw wachtwoord en een actuele code. Dit beschermt de accountaanmelding en staat los van de client-side versleuteling die werkruimte-inhoud beschermt.
Referenties & normen.
Onze cryptografische keuzes volgen industriestandaarden en peer-reviewed specificaties.
- 01 RFC 8439: ChaCha20 en Poly1305 voor IETF-protocollen — Onze symmetrische encryptiestandaard
- 02 RFC 9807: het uitgebreide OPAQUE-PAKE-protocol — Zero-knowledge-wachtwoordverificatie
- 03 RFC 9180: Hybride publieke sleutelversleuteling (HPKE) — Sleuteluitwisseling voor teamuitnodigingen
- 04 RFC 9106: Argon2 Memory-Hard-functie — Op wachtwoord gebaseerde sleutelafleiding
- 05 NIST SP 800-175B: Richtlijn voor het gebruik van cryptografische standaarden — Federale cryptografische begeleiding
- 06 AVG Artikel 32: Beveiliging van de verwerking — EU-vereisten voor gegevensbescherming
- 07 RFC 6238 — TOTP — Tweefactorauthenticatie
Klaar voor echte privacy?
Sluit u aan bij teams die erop vertrouwen dat SealTask hun werk echt privé houdt. Start met Free – geen creditcard vereist.
Gratis startenHeeft u beveiligingsvragen? E-mail ons op security@sealtask.com