Beveiligingswhitepaper

Technische uitdieping van hoe RocketShare uw bestanden beschermt met zero-knowledge encryptie

Dit document biedt een uitgebreid technisch overzicht van hoe RocketShare uw gegevens beschermt. Het is bedoeld voor beveiligingsprofessionals, compliance officers en iedereen die precies wil begrijpen hoe onze encryptie werkt.

1. Managementsamenvatting

RocketShare is een zero-knowledge versleuteld platform voor het delen van bestanden. Bestanden worden client-side versleuteld met AES-256-GCM vóór upload, en de encryptiesleutel wordt uitsluitend opgenomen in het URL-fragment—een deel van de URL dat browsers nooit naar servers verzenden. Deze architectuur betekent dat RocketShare-operators onder geen enkele omstandigheid gebruikersbestanden kunnen openen, lezen of ontcijferen, inclusief bij verzoeken tot rechtmatige onderschepping.

Belangrijkste eigenschappen:

  • Zero-knowledge architectuur — de server heeft nooit de beschikking over ontsleutelingssleutels
  • End-to-end encryptie — bestanden worden versleuteld voordat ze het apparaat van de verzender verlaten en worden alleen op het apparaat van de ontvanger ontsleuteld
  • Geen server-side sleutelopslag — sleutels bestaan alleen in het URL-fragment van de deellink
  • Automatische vervaldatum en verwijdering — bestanden worden permanent verwijderd na vervaldatum

2. Bedreigingsmodel

Waartegen we beschermen

  • Servercompromittering — zelfs als een aanvaller volledige toegang krijgt tot onze servers, blijven opgeslagen bestanden versleuteld en onleesbaar zonder de per-transfer sleutel
  • Netwerkonderschepping — TLS 1.3 beschermt data in transit; encryptiesleutels in URL-fragmenten worden nooit over het netwerk verzonden
  • Insider threats — RocketShare-operators hebben bij ontwerp, niet bij beleid, geen toegang tot bestandsinhoud
  • Rechtmatige onderschepping — we kunnen niet voldoen aan ontcijferingsverzoeken omdat we de sleutels niet bezitten; we kunnen alleen versleutelde blobs en metadata verstrekken

Wat buiten ons bedreigingsmodel valt

  • Gecompromitteerd apparaat van verzender of ontvanger — als malware toegang heeft tot de browser van de gebruiker, kan het sleutels of plaintext-bestanden onderscheppen
  • Onderschepping van deellink — iedereen die de volledige deellink (inclusief het URL-fragment) verkrijgt, kan de bestanden ontcijferen; gebruikers moeten links veilig delen
  • Browserkwetsbaarheden — we vertrouwen op de Web Crypto API van de browser; exploits op browserniveau vallen buiten onze controle

3. Encryptie-implementatie

Algoritme

Alle bestandsencryptie maakt gebruik van AES-256-GCM (Galois/Counter Mode), een symmetrisch authenticated encryption-algoritme. GCM biedt zowel vertrouwelijkheid als integriteit, wat betekent dat elke manipulatie van de ciphertext tijdens ontsleuteling wordt gedetecteerd.

Sleutelgeneratie

Encryptiesleutels worden client-side gegenereerd met behulp van de Web Crypto API van de browser (crypto.subtle.generateKey), die wordt ondersteund door de cryptografisch veilige pseudorandom number generator (CSPRNG) van het besturingssysteem.

  • Sleutelgrootte: 256 bits
  • Bron: Web Crypto API (crypto.subtle.generateKey), ondersteund door CSPRNG op OS-niveau
  • Scope: één unieke sleutel per transfer (bestand of bundel)

Encryptieproces

  1. De gebruiker selecteert bestanden om te uploaden
  2. Een 256-bit AES-sleutel wordt gegenereerd met crypto.subtle.generateKey()
  3. Een unieke 96-bit initialization vector (IV) wordt per encryptieoperatie gegenereerd
  4. Bestanden worden in de browser versleuteld met AES-256-GCM via de Web Crypto API
  5. De versleutelde ciphertext wordt naar de server geüpload
  6. Het ruwe sleutelmateriaal wordt Base64url-gecodeerd en in het URL-fragment geplaatst (#<base64url-key>)

Streaming encryptie

Voor grote bestanden gebruikt RocketShare een streaming encryptiebenadering. Bestanden worden in chunks verwerkt om geheugengebruik te minimaliseren, waardoor encryptie en upload van bestanden die het beschikbare RAM-geheugen overschrijden mogelijk is.

Elke chunk wordt versleuteld met een eigen willekeurig gegenereerde 96-bit IV (crypto.getRandomValues), wat unieke ciphertext voor elke chunk garandeert, zelfs als bestandsinhoud zich herhaalt.

4. Sleutelbeheer

URL-fragmentbenadering

De ontsleutelingssleutel wordt opgenomen in het URL-fragment (het deel na #). Dit is de kritieke beveiligingseigenschap van het systeem:

  • Browsers verzenden URL-fragmenten nooit naar servers in HTTP-verzoeken (RFC 3986, Sectie 3.5)
  • Het fragment blijft volledig client-side — in de adresbalk van de browser, geschiedenis en wanneer gedeeld door de gebruiker
  • De server ontvangt alleen het pad en query-parameters, nooit het #... sleutelgedeelte

Sleutellevenscyclus

  1. Generatie — gecreëerd in de browser van de verzender met CSPRNG
  2. Gebruik — direct gebruikt voor client-side encryptie
  3. Inbedding — geplaatst in het URL-fragment van de deellink
  4. Verzending — de gebruiker deelt de link via het door hem/haar gekozen veilige kanaal (e-mail, messenger, etc.)
  5. Ontsleuteling — de browser van de ontvanger leest het fragment en ontsleutelt het bestand
  6. Geen opslag — sleutels worden nooit op de server opgeslagen; ze bestaan alleen in de deellink

Wat de server opslaat

De server slaat alleen op:

  • Versleutelde bestandsblobs (ciphertext)
  • Transfer-metadata: bestandsnaam, bestandsgrootte, MIME-type, vervaldatum
  • Transfer-instellingen: downloadlimiet, wachtwoordbeveiligingshash (indien ingeschakeld)
  • Accountniveau-gegevens: e-mail, auth-tokens (niet gerelateerd aan bestandsencryptie)

De server slaat nooit op: encryptiesleutels, plaintext-bestandsinhoud, of enige gegevens die gebruikt kunnen worden om de sleutel af te leiden.

5. Bestandslevenscyclus

Upload

  1. Gebruiker selecteert bestanden → encryptiesleutel wordt client-side gegenereerd
  2. Bestanden worden versleuteld met AES-256-GCM in de browser
  3. Versleutelde blobs worden via TLS 1.3 naar de server geüpload
  4. Server slaat ciphertext + metadata op, retourneert transfer-ID
  5. Deellink wordt samengesteld: https://rocketshare.app/d/{id}#{base64url-key}

Opslag

  • Versleutelde bestanden worden opgeslagen op S3-compatibele objectopslag gehost in de EU (Amsterdam)
  • Bestanden worden opgeslagen als ondoorzichtige versleutelde blobs — de opslagprovider kan ze niet lezen
  • Metadata wordt opgeslagen in PostgreSQL met encryption-at-rest op het databasevolume

Download

  1. Ontvanger opent de deellink
  2. Browser extraheert de sleutel uit het URL-fragment (nooit naar server verzonden)
  3. Versleutelde blob wordt van de server gedownload
  4. Ontsleuteling gebeurt volledig in de browser van de ontvanger
  5. Plaintext-bestand wordt aan de gebruiker gepresenteerd voor download

Vervaldatum en verwijdering

  • Transfers hebben een configureerbare vervaldatum (3 dagen tot 90 dagen, afhankelijk van het abonnement)
  • Na vervaldatum verwijdert een geplande opschoontaak permanent de versleutelde blobs uit objectopslag en de bestandsrecords uit de database
  • Het transfer-metadata-record (bestandsnamen, groottes, timestamps) wordt bewaard in een vervallen status voor administratieve en auditdoeleinden, maar alle versleutelde bestandsgegevens worden onomkeerbaar verwijderd
  • Er worden geen back-ups bewaard van vervallen bestandsgegevens

6. Infrastructuur

Hosting

  • Applicatie: gedeployed op Cloudflare Workers (edge compute)
  • Database: PostgreSQL, gehost in de EU
  • Objectopslag: S3-compatibel, EU (Amsterdam) region
  • Cache: Cloudflare KV (key-value store), voor sessie- en rate-limiting-data alleen — nooit gebruikt voor bestandsinhoud
  • CDN: Cloudflare wereldwijd netwerk voor statische assets en edge routing

Gegevenslocatie

Alle bestandsopslag en databaseservers bevinden zich binnen de Europese Unie. We repliceren bestandsgegevens niet buiten de EU.

Netwerkbeveiliging

  • TLS 1.3 afgedwongen op alle verbindingen (HTTP en database)
  • HSTS met preloading — browsers krijgen de instructie altijd HTTPS te gebruiken
  • HTTP beveiligingsheaders — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Geen mixed content — alle resources worden over HTTPS geladen

7. Authenticatie en toegangscontrole

Gebruikersauthenticatie

  • E-mail/wachtwoord — wachtwoorden gehasht met scrypt (N=16384, r=16, p=1), minimum 8-tekens lengte afgedwongen
  • OAuth — Google en Microsoft SSO via industriestandaard OAuth 2.0 / OpenID Connect
  • Sessiebeheer — veilige HTTP-only cookies met juiste SameSite-attributen

Transfer-toegangscontroles

  • Link-gebaseerde toegang — iedereen met de volledige deellink kan ontcijferen (de sleutel zit in de URL)
  • Optionele wachtwoordbeveiliging — transfers kunnen een aanvullend wachtwoord vereisen; de wachtwoordhash wordt server-side geverifieerd voordat de versleutelde blob wordt geleverd
  • Downloadlimieten — configureerbaar maximumaantal downloads voordat de link wordt uitgeschakeld
  • Vervaldatum — automatische tijdsgebaseerde vervaldatum waarna versleutelde bestandsgegevens permanent worden verwijderd

8. Gegevensminimalisatie en bewaring

Principe van minimale data

We verzamelen alleen wat nodig is om de dienst te laten werken:

  • Accountgegevens: e-mailadres, naam (indien verstrekt via OAuth), gehasht wachtwoord
  • Transfer-metadata: bestandsnamen, groottes, MIME-types, timestamps, vervaldatums
  • Gebruiksgegevens: transfer-aantallen en gebruikte opslag (voor abonnementafdwinging)
  • Analytics: geanonimiseerde gebruikspatronen via PostHog (EU-gehost, privacy-gerichte configuratie)

Wat we niet verzamelen

  • Bestandsinhoud (we hebben geen toegang tot versleutelde blobs)
  • Encryptiesleutels
  • IP-adressen in langetermijnopslag (toegangslogboeken zijn tijdelijk)
  • Browsegeschiedenis of cross-site trackinggegevens

Retentie

  • Transfers: versleutelde bestandsgegevens automatisch verwijderd bij vervaldatum; transfer-metadata bewaard in vervallen status
  • Accountgegevens: bewaard zolang account actief is; verwijderd op verzoek tot accountverwijdering
  • Toegangslogboeken: tijdelijk, niet bewaard na de request-levenscyclus

9. Incident response

In het geval van een beveiligingsincident:

  1. Containment — getroffen systemen onmiddellijk isoleren
  2. Beoordeling — omvang en impact bepalen; dankzij zero-knowledge architectuur legt een server-inbreuk bestandsinhoud niet bloot
  3. Notificatie — getroffen gebruikers worden binnen 72 uur geïnformeerd zoals vereist door de AVG
  4. Remediatie — oorzaak oplossen, verdediging verbeteren
  5. Openbaarmaking — publieke bekendmaking van het incident en onze reactie

Beveiligingsproblemen kunnen bij ons worden gemeld via ons Responsible Disclosure-beleid.

10. Beperkingen en transparantie

We geloven in transparantie over wat onze beveiligingsarchitectuur wel en niet beschermt:

  • We kunnen verloren links niet herstellen — als een gebruiker de deellink (inclusief het URL-fragment) verliest, kunnen de versleutelde bestanden niet worden ontcijferd. We hebben de sleutel niet.
  • Linkbeveiliging is de verantwoordelijkheid van de gebruiker — de deellink is de enige toegangsreferentie. Als deze wordt onderschept (bijv. verzonden via een onveilig kanaal), kan de onderschepper de bestanden ontcijferen.
  • CSP met nonce-gebaseerd scriptbeleid — we gebruiken Content Security Policy met strict-dynamic en nonce-gebaseerde scriptbronnen, wat de aanbevolen aanpak is voor SSR-applicaties. Inline styles vereisen nog steeds unsafe-inline vanwege Tailwind CSS.
  • Browser trust — onze encryptie is afhankelijk van de Web Crypto API. Als de browser gecompromitteerd is, valt alles in het water.
  • Metadata-zichtbaarheid — hoewel bestandsinhoud versleuteld is, zijn bestandsnamen, groottes en timestamps zichtbaar voor de server voor operationele doeleinden.

Deze whitepaper is actueel per februari 2026. We updaten dit document wanneer onze beveiligingsarchitectuur verandert. Voor vragen kunt u contact met ons opnemen.