Serverversleuteling vs. clientversleuteling: het doorslaggevende verschil

Vrijwel elke transcriptiedienst adverteert met „versleuteling“. Maar niet elke versleuteling beschermt even goed. Het doorslaggevende verschil zit niet in het algoritme – maar in wie de sleutel heeft.

Dit artikel legt het verschil uit tussen versleuteling aan de serverzijde en aan de clientzijde en waarom dat voor je audiobestanden een fundamenteel verschil maakt.

Wat „encryption at rest“ werkelijk betekent

„Encryption at rest“ betekent: gegevens worden versleuteld opgeslagen. Het addertje: de aanbieder bezit de sleutel. Elke medewerker met databasetoegang, elke cloudbeheerder en elke hacker die de server compromitteert, kan de gegevens ontsleutelen.

De meeste clouddiensten versleutelen gegevens zodra ze op de harde schijf staan. Dat beschermt tegen diefstal van fysieke harde schijven – een scenario dat bij professionele datacenters zelden voorkomt. Het beschermt niet tegen:

• Aanvallen op de applicatie: Wie in de applicatie binnendringt, heeft toegang tot de ontsleutelfunctie.
• Insidertoegang: Beheerders van de aanbieder kunnen de gegevens op elk moment lezen.
• Verzoeken van autoriteiten: De aanbieder kan de gegevens ontsleutelen en afgeven.
• AI-training: De aanbieder zou je gegevens kunnen gebruiken om zijn modellen te verbeteren.

Kortom: versleuteling aan de serverzijde beschermt de harde schijf, niet je gegevens.

Wat versleuteling aan de clientzijde anders doet

Bij versleuteling aan de clientzijde wordt je audiobestand in de browser versleuteld voordat het de server bereikt. De server slaat alleen versleutelde blobs op – hij bezit de sleutel niet. Zelfs de aanbieder kan de opgeslagen gegevens niet lezen.

Het verloop in detail:

• 1. Sleutel genereren: Voor elk bestand wordt in de browser een eigen 256-bits sleutel gegenereerd (File Encryption Key).
• 2. Lokaal versleutelen: Het audiobestand wordt met AES-256-GCM direct in de browser versleuteld. De server ontvangt alleen versleutelde bytes.
• 3. Sleutel beveiligen: De bestandssleutel wordt met je persoonlijke masterkey versleuteld en zo op de server opgeslagen. Zonder je wachtwoord kan niemand erbij.

Het resultaat: op de server staan uitsluitend versleutelde gegevens. Geen medewerker van de aanbieder, geen hacker en geen autoriteit kan ze zonder je sleutel ontsleutelen.

De directe vergelijking

De volgende tabel toont het verschil in één oogopslag:

• Wie versleutelt? Serverversleuteling: de aanbieder. Clientversleuteling: je browser.
• Wie heeft de sleutel? Serverversleuteling: de aanbieder. Clientversleuteling: alleen jij.
• Kan de aanbieder meelezen? Serverversleuteling: ja. Clientversleuteling: nee.
• Bescherming bij een datalek? Serverversleuteling: beperkt (sleutel vaak mee gecompromitteerd). Clientversleuteling: volledig (sleutel staat niet op de server).
• Afgifte aan autoriteiten? Serverversleuteling: aanbieder kan ontsleutelen. Clientversleuteling: aanbieder kan alleen versleutelde blobs leveren.
• AVG art. 34(3)(a)? Serverversleuteling: meldplicht bij een datalek. Clientversleuteling: geen meldplicht, omdat de gegevens onleesbaar zijn.

Wat op de server is opgeslagen

Bij versleuteling aan de clientzijde staan op de server permanent alleen versleutelde gegevens. Het transcript wordt versleuteld opgeslagen en kan alleen door de gebruiker zelf worden ontsleuteld. Originele audiobestanden worden na de verwerking automatisch verwijderd – op de server blijft alleen een versleutelde afspeelversie achter.

Het resultaat: zelfs wij als aanbieder kunnen de opgeslagen transcripten en audiobestanden niet lezen.

Waaraan je herkent welke versleuteling een dienst gebruikt

Wanneer een transcriptiedienst zegt „Je gegevens zijn versleuteld“, vraag dan gericht door:

• „Wie heeft de ontsleutelsleutel?“– Als de aanbieder hem heeft, is het versleuteling aan de serverzijde.
• „Kunnen jullie medewerkers mijn transcripten lezen?“ – Bij eerlijke aanbieders met versleuteling aan de serverzijde luidt het antwoord: in theorie ja.
• „Wat gebeurt er bij een datalek?“– Als de aanbieder meldplichten conform art. 34 AVG noemt, wijst dat op ontsleutelbare gegevens.
• „Kan ik de versleuteling zelf verifiëren?“ – Bij versleuteling aan de clientzijde kun je in het netwerktabblad van de browser controleren dat alleen versleutelde bytes worden geüpload.

Wanneer volstaat versleuteling aan de serverzijde?

Versleuteling aan de serverzijde is niet per se slecht. Voor niet-kritische inhoud – bijvoorbeeld de transcriptie van een openbare podcast – kan ze volstaan. Maar voor:

• Medische dictaten en patiëntgesprekken
• Cliëntgesprekken bij advocatenkantoren
• Bestuursvergaderingen en strategiegesprekken
• Journalistieke interviews met vertrouwelijke bronnen
• HR-gesprekken en beoordelingen van medewerkers
• Rechtszittingen en getuigenverklaringen

… is versleuteling aan de clientzijde de enige architectuur die echte bescherming biedt. Want hier gaat het niet om de vraag of een aanbieder je gegevens misbruikt – maar erom dat hij het technisch niet kan.

Conclusie

„Versleuteld“ is niet hetzelfde als „beschermd“. Het doorslaggevende verschil zit in wie de sleutel beheert. Versleuteling aan de serverzijde beschermt harde schijven. Versleuteling aan de clientzijde beschermt je gegevens – ook tegen de aanbieder zelf. Wie met vertrouwelijke audio-opnames werkt, zou dit verschil moeten kennen.