Beveiliging en architectuur
Hoe het systeem werkt, wat het garandeert, en wat niet.
Een toegangslogboek waarin manipulatie zichtbaar wordt.
Elke toegangsgebeurtenis wordt gehasht en gekoppeld aan de vorige, in een register dat per gate wordt bijgehouden. Een eerdere registratie aanpassen breekt de keten — en dat is precies wat het logboek controleerbaar maakt.
Zero-knowledge payload
De browser versleutelt de bestemmings-URL, of het bestand zelf, voordat het het apparaat verlaat, en onze servers bewaren alleen de versleutelde data. De sleutel reist mee in het linkfragment, dat browsers nooit naar een server sturen. Wie de volledige link heeft, heeft de sleutel.
- Algoritme
- AES-256-GCM
- Waar de sleutel staat
- Alleen het linkfragment
- Wat de server ziet
- Alleen versleutelde data
- Reikwijdte
- De payload, niet het toegangslogboek
Toegangslogboek
Wanneer een ontvanger een link opent, worden tien waarden samen vastgelegd en opgenomen in de hashketen van die gate: wie, wanneer, vanwaar, welk bestand en de exacte voorwaarden of mededeling die hij te zien kreeg. Heeft de link voorwaarden, dan is het aanvaarden ervan de handtekening. Wordt er later één van aangepast, dan mislukt de verificatie.
- E-mail en IP van de ondertekenaar
- Als versleutelde data gehasht
- Tijdstempel
- UTC, microseconde
- Getoonde voorwaarden of mededeling
- SHA-256 van de exacte tekst
Één register per gate
Elke link houdt zijn eigen hashketen bij in plaats van één gedeeld register, zodat elke registratie alleen gekoppeld is aan eerdere registraties op datzelfde document. Een link archiveren of verwijderen laat de integriteit van de andere intact.
- Hashfunctie
- SHA-256
- Architectuur
- Gescheiden ketens per gate
- Resultaat
- Verifieerbaar auditlogboek
Integriteitsdemo: een SHA-256-hashketen
Een toegangslogboek waarin manipulatie zichtbaar wordt.
Het toegangslogboek kan alleen worden aangevuld, en elke registratie wordt samen met de vorige gehasht. Pas je een historische registratie aan, dan klopt elke hash daarna niet meer, zoals hieronder. Op zichzelf vangt dat een aanpassing op, geen herschrijving: wie de hele tabel kan herschrijven, kan ook de latere hashes opnieuw berekenen. Daarom wordt elke keten ook gekopieerd naar aparte opslag die maar één keer beschreven kan worden, en controleert een geplande taak de live registraties tegen die kopieën. Een herschrijving moet dan afwijken van een kopie die ze niet kan bereiken. Elke dagelijkse kopie krijgt nu ook een gekwalificeerd elektronisch tijdstempel (eIDAS art. 41) over de exacte inhoud, dat dezelfde taak controleert: een kopie die achteraf wordt gewijzigd, komt er niet meer mee overeen.
Architectuur
Genesis seed — sha256(gate id)
2af6f231702098d477213328551d3599b9b8316dc05874b6407446c69ceff48a
Afgeleid van de id van deze gate, zodat geen enkele andere gate hier een keten kan beginnen.
Samen gehasht, in deze volgorde
SHA-256 of the ten values above, joined by “|”
ebb5dacbcf46d719bfe12ed3e6fa82ed33fcfd6a886612d0495730e322e6959e
Samen gehasht, in deze volgorde
SHA-256 of the ten values above, joined by “|”
e0d546c992930e064ed277e2f81203a58f43ad30f50d44861b7df4c099e406b3
Samen gehasht, in deze volgorde
SHA-256 of the ten values above, joined by “|”
c7232444441723c67ceb37b4dbea9415e9ef63fd4a4c426e07dd3a18de54458d
De registraties zijn verzonnen, de hashes niet. Elke digest hierboven is de echte SHA-256 van de tien waarden in dat blok, in die volgorde, samengevoegd met “|”. Kopieer ze en reken het zelf na.
“Kan SignToSee zien wat ik deel?”
Nee. Wij kunnen het toegangslogboek lezen, niet wat je deelt.
De bestemmings-URL en elk bestand dat je uploadt worden versleuteld in je browser voordat ze ons bereiken, dus wij kunnen ze niet lezen. Het toegangslogboek is een ander verhaal: wij kunnen lezen wie wat opende en wanneer, want die registratie ís het bewijs. Hier ligt de grens precies.
1. Jij plakt je bestemmings-URL
Je Figma-, Notion- of Drive-link, of een pdf. Je browser maakt een willekeurige versleutelingssleutel aan, die op dit moment je apparaat niet verlaat.
2. De versleuteling gebeurt in je browser, voordat er iets vertrekt
AES-256-GCM draait in je browser en zet de URL of het bestand om in onleesbare versleutelde data. Alleen die versleutelde data reist naar onze server; de sleutel niet.
3. Onze server bewaart alleen de versleutelde data, nooit de leesbare tekst
Dit is wat er in onze database staat. Zonder de sleutel is het niet te lezen.
4. De sleutel staat in het URL-fragment, het deel dat de server nooit ziet
De link die je naar je klant stuurt bestaat uit twee delen. De browser kent ze allebei. De server ontvangt alleen wat vóór de # staat: het fragment bestaat alleen in de browser, zo vastgelegd in de URL-standaard.
5. Nadat de ontvanger zijn e-mailadres bevestigt (en eventuele voorwaarden aanvaardt), wordt de sleutel gebruikt — in zijn browser
De browser van de ontvanger leest de sleutel uit het fragment, ontsleutelt de inhoud en opent het bestand in de viewer of stuurt door naar je link. Het ontsleutelen gebeurt in zijn browser, dus onze servers zien de bestemming nooit.
Resultaat: wij hebben geen sleutel tot de payload
Dit geldt zowel voor links als voor geüploade bestanden: wij bewaren de versleutelde data, nooit de sleutel. Een vordering tot openbaarmaking reikt alleen tot wat wij werkelijk hebben, namelijk die versleutelde data en het toegangslogboek. Het toegangslogboek is bewust leesbaar voor ons, en bevat het e-mailadres van de ontvanger, zijn IP-adres en de voorwaarden of mededeling die hij te zien kreeg.
De termen uitgelegd
De begrippen die op deze site gebruikt worden, in gewone taal.
Zero-knowledge (alleen de payload)
Geldt voor de payload: de bestemmings-URL en elk bestand dat je uploadt worden versleuteld in je browser, en de sleutel blijft in het linkfragment staan, dat browsers nooit naar een server sturen. Wij bewaren en tonen alleen versleutelde data. Het geldt niet voor het toegangslogboek — dat kunnen wij wel lezen.
AES-256-GCM
Advanced Encryption Standard met een 256-bits sleutel in Galois/Counter Mode. Een geauthenticeerde versleuteling: ze houdt de payload vertrouwelijk én merkt wijzigingen op, zodat aangepaste versleutelde data niet ontsleutelt in plaats van iets verkeerds op te leveren.
Envelope-encryptie en crypto-shredding
Het e-mailadres en IP-adres van elke ondertekenaar worden versleuteld onder een sleutel die uniek is voor die ondertekenaar én die klant. Die sleutels zijn op hun beurt versleuteld onder een hoofdsleutel die alleen in de omgeving van de draaiende server bestaat. Één sleutel vernietigen maakt de gegevens van die ene ondertekenaar blijvend onleesbaar, zonder die van iemand anders te raken. De hashketen blijft intact, want die dekt de versleutelde data, en die blijft staan waar ze staat.
SHA-256-hashketens
Elke nieuwe registratie wordt met het SHA-256-algoritme aan de vorige gekoppeld, zodat elke link die je deelt een eigen, ononderbroken geschiedenis heeft waarin manipulatie zichtbaar wordt.
Passkeys en aanmelden in twee stappen
Een afzender kan na het wachtwoord een tweede stap toevoegen: een passkey, ontgrendeld met de vingerafdruk, het gezicht of de pincode van het toestel, of een code van zes cijfers uit een authenticator-app. Een passkey kan ook op zichzelf aanmelden. Het is optioneel en staat uit tot de eigenaar van het account het aanzet. Elke wijziging vraagt het wachtwoord en wordt naar de eigenaar gemaild.
Normen en kaders
De Europese regels waaronder dit product werkt, en wat het met elk daarvan doet.
eIDAS-verordening nr. 910/2014
Art. 25, rechtsgevolg
Heeft een link een overeenkomst, dan voldoet het aanvaarden ervan aan de definitie van een gewone elektronische handtekening. Art. 25(1) belet een rechter om er een terzijde te schuiven enkel omdat ze elektronisch is; het bepaalt niet welke bewijswaarde ze heeft.
Het toegangslogboek
Wat wij kunnen lezen
Het e-mailadres en IP-adres van de ondertekenaar en de identiteitsgegevens die hij invult, worden versleuteld opgeslagen onder een sleutel die wij beheren — wij kunnen ze dus ontsleutelen. De browserinformatie, tijdstempels, de voorwaardentekst van de klant zelf en de hashketen staan onversleuteld. Dat is een bewuste keuze: een registratie die niemand kan lezen, is geen bewijs.
Wissen
Wat we bewaren, wat we vernietigen
De toegangsregistratie kan alleen worden aangevuld, nooit gewijzigd, en wordt bewaard voor de instelling, uitoefening of onderbouwing van een rechtsvordering — wat art. 17(3)(e) toestaat. De identiteit van de ondertekenaar daarbinnen bewaren we 10 jaar na zijn laatste registratie bij die klant, of tot een geldig verzoek tot wissen of tot de klant zijn account verwijdert, als dat eerder is, tenzij een juridische blokkering voor een concreet geschil erop rust. Ze staat er niet leesbaar in: zijn e-mailadres, IP-adres en alle bedrijfs-, vertegenwoordigings-, adres- en registratiegegevens die hij invulde, zijn versleuteld onder een sleutel die uniek is voor die ondertekenaar én die klant, en bij een geldig verzoek tot wissen vernietigen wij die sleutel. De registratie blijft verifieerbaar en de aanvaarde voorwaarden blijven leesbaar; de identiteit wordt onleesbaar, ook in de ondertekende overeenkomst, die op aanvraag wordt samengesteld in plaats van opgeslagen. Kopieën die bij de ondertekening al gemaild zijn, kunnen niet worden teruggehaald.
Hosting op EU-bodem
Gegevensopslag in de EU
Alle servers staan fysiek in de EU en worden beheerd door aanbieders die in de EU gevestigd zijn. We gebruiken geen Amerikaanse hyperscalers voor de kernhosting.
Controleer het op
je eigen link.
De versleuteling die hier beschreven staat, draait in je eigen browser. Deel gratis een link en bekijk het zelf.
Begin op het Free-plan. Geen kaartgegevens nodig.