Beveiliging en architectuur
Hoe het systeem werkt, wat het garandeert, en wat niet.
Cryptografische integriteit
by Design.
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
Live integriteitsdemo // SHA-256-hashketen
Manipulatie wordt zichtbaar, door het ontwerp.
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.
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 “|”
4295189a5d881953e3b91cba44fc6826a334b537fb39ef947f0d9ee4ca7ea840
Samen gehasht, in deze volgorde
SHA-256 of the ten values above, joined by “|”
e94ab3df58d6fa49612a7ee5d02240502475020b8a52fce4adc2704087b168c4
Samen gehasht, in deze volgorde
SHA-256 of the ten values above, joined by “|”
ae44cffce3407272d7263a39c2a1c5a5fcff1fa58cdcf82cd05e1338baa5a553
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?”
De payload niet. Het logboek wel.
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 aan de clientkant. De URL wordt omgezet 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. Zelfs wie het rechtstreeks zou opvragen, vindt hier niets leesbaars.
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 is een mechanisme dat enkel aan de clientkant werkt, vastgelegd in de HTTP-specificatie.
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 volledig aan de clientkant. De bestemmings-URL wordt op geen enkel moment naar onze servers gestuurd — of door hen prijsgegeven.
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 voor ons leesbaar, bij ontwerp, 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.
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 valt daar niet onder: 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.
Vertrouw je de architectuur?
Probeer het zelf.
De versleuteling die hier beschreven staat, draait in je eigen browser. Deel gratis een link en bekijk het zelf.
Geen kaartgegevens nodig. Het Scout-plan is gratis.