De zoektocht naar doorzoekbare encryptie

Dat klopt: geen Flutter of Xamarin, maar een onderwerp dat net zo interessant kan zijn. Voordat ik bij Baseflow aan de slag ging, ben ik afgestudeerd in Cyber Security. Mijn onderzoek richtte zich op het onderwerp van doorzoekbare encryptie. Laat me je meenemen op een reis door de wondere wereld van privacy, informatielekken en hashing algoritmes.

Het probleem

Tegenwoordig slaan we heel veel gegevens op; vergadernotities, foto's van huisdieren en alle seizoenen van Mr. Robot. We slaan deze gegevens meestal op in de cloud, zodat ze altijd voor ons toegankelijk zijn. Door de gegevens online te bewaren, hoeven we ook niet de nieuwste harde schijf te kopen om al onze gegevens persoonlijk op te slaan. Het zit de meeste mensen niet lekker om grote bedrijven als Microsoft, Google en Apple te vertrouwen met hun persoonlijke gegevens. En hoewel ik niet geloof dat grote techbedrijven inherent slecht zijn, denk ik ook niet dat zij de privacy van hun gebruikers als hun eerste zorg zien.

‍

Wat kunnen we doen om te voorkomen dat deze bedrijven toegang krijgen tot onze gegevens terwijl we toch gebruik maken van hun diensten? Of om de vraag om te draaien, wat kan een dienstverlener doen om de privacy van een klant te respecteren en te garanderen? Encryptie! Gebruikers versleutelen de gegevens die ze met de dienstverlener delen. Als ze dan de gegevens opvragen, kunnen ze ze zelf ontsleutelen, en is alles in orde. Toch? Nou, niet echt. Het probleem is dat deze aanpak weliswaar werkt vanuit het oogpunt van gegevensbeveiliging, maar door alle gegevens te versleutelen, is er geen manier om erachter te komen welke gegevens u in eerste instantie uit de cloud wilt halen. Als ik bijvoorbeeld een belangrijke e-mail wil vinden die Harry me heeft gestuurd, ga ik naar mijn Gmail en typ ik 'Harry' in. Aangezien Google mijn e-mails kan lezen, kan het mij alle relevante mail tonen. Maar als ik al mijn e-mails zou versleutelen, zou Google geen idee hebben wat hij me moet laten zien! Google zou alle e-mails naar mij kunnen sturen, en ik zou ze allemaal kunnen ontsleutelen om erachter te komen welke e-mails relevant zijn, maar dat doet het doel van het opslaan van gegevens in de cloud een beetje teniet.

De oplossing

Wat is dan de oplossing? Doorzoekbare encryptie! Doorzoekbare versleutelingsschema's zijn ontworpen om zowel privacy van gegevens te bieden als zoekopdrachten mogelijk te maken. Deze regelingen bestaan in allerlei vormen en worden meestal bereikt door gebruik te maken van slimme wiskundige eigenschappen.

Sommige regelingen zijn snel en bieden een basis zoekoperatie, waarbij men kan zoeken naar een enkel woord. Andere methoden staan meer gedetailleerde zoekopdrachten toe, zoals "wildcard queries". De wildcard-query "l*g" zou bijvoorbeeld overeenkomen met documenten die de woorden "lag", "leg" en "log" bevatten. Een ander aspect dat per schema verschilt, is de beveiliging ervan. Zoekbare versleutelingsschema's lekken bijna altijd een bepaalde hoeveelheid gegevens. Dit kan de zoekopdracht van de gebruiker zijn of het aantal woorden in een document. Het beperken van het lekken gaat meestal ten koste van de efficiëntie. Meestal moeten ontwerpers van doorzoekbare versleutelingsregelingen de drie eigenschappen zorgvuldig tegen elkaar afwegen, rekening houdend met de omgeving waarin de regeling zal worden gebruikt.

‍

Een eenvoudig schema construeren

Als u op dit punt nog steeds aan het lezen bent, mijn complimenten dat u het volhoudt! Laten we wat dieper duiken en kijken hoe een basisschema werkt. We zullen een eenvoudig schema construeren dat tonnen informatie lekt voor een buitenstaander. Niettemin toont het de basisstructuur van de meeste moderne systemen.

Gegevensformaat

Allereerst beschouwen de meeste schema's gegevens in een document id-keyword paar formaat. Dit betekent dat elk document, e-mail of ander gegevenstype dat wij willen opslaan, wordt voorgesteld als meerdere paren bestaande uit het id en elk één trefwoord.

‍

Stel dat we een boodschappenlijstje hebben dat we willen opslaan. We geven de lijst een nummer en beschouwen elk item op de lijst als een trefwoord. We sturen dan de paren 1-Hagelslag, 1-Kikkererwten enz. afzonderlijk naar de server.

De server slaat deze paren op in wat wij een index noemen. Een index kan veel verschillende vormen aannemen, afhankelijk van het schema, maar in zijn eenvoudigste vorm is het gewoon een lijst van alle id-keyword paren.

Algoritmen

De meeste moderne regelingen bestaan uit drie paar algoritmen.

‍

AddToken wordt door de client gebruikt om een token te genereren uit een id-keyword paar en dit naar de server te sturen. Add wordt dan door de server gebruikt om dit token te gebruiken om zijn index bij te werken.

DeleteToken en Delete werken op dezelfde manier om paren uit de index te verwijderen.

SearchToken wordt door de client gebruikt om een token te instantiëren op basis van een zoekopdracht. Het zoekalgoritme wordt door de server gebruikt om te controleren welke id's overeenkomen op basis van het zoektoken. Deze id's worden dan gebruikt om te bepalen welke bestanden aan de cliënt moeten worden teruggegeven. De implementaties van deze algoritmen verschillen per schema en zijn vaak behoorlijk ingewikkeld. Om u een basisidee te geven, laten we een eenvoudig schema maken op basis van een hashing-functie.

De regeling

Het AddToken-algoritme neemt gewoon het id-keyword-paar en hasht het keyword alvorens het paar naar de server te sturen. Het Add-algoritme voegt het paar rechtstreeks toe aan de index, die in dit schema een lijst is.

‍

Het SearchToken-algoritme hasht een single-keyword-query alvorens deze naar de server te sturen.

Het zoekalgoritme controleert gewoon de index op overeenstemmende hashes. Elke overeenkomende hash komt overeen met een id van een overeenkomend document.

‍

Laten we eens kijken wat deze regeling bereikt, en wat niet.

Ten eerste, het schema werkt. Joepie! We kunnen gegevens bijwerken en doorzoeken (verwijderen laat ik als oefening voor jullie!). Helaas kunnen we, zoals je misschien al hebt gemerkt, slechts naar één trefwoord tegelijk zoeken. Met dit schema kunnen we niet zoeken naar documenten met meerdere trefwoorden of mooie zoekopdrachten doen, zoals zoeken met een jokerteken.

Laten we nu onze aandacht richten op de beveiliging, want daar is deze hele zoektocht mee begonnen. Het goede nieuws: aangenomen dat we een veilige hashing-functie gebruiken, zijn zowel de inhoud van de gegevens als de inhoud van de zoekopdracht van de cliënt verborgen. De server krijgt nooit de eigenlijke trefwoorden te zien. We zien echter wel wanneer we meerdere keren hetzelfde trefwoord toevoegen of zoeken, omdat de hashes dan identiek zijn. Een waarnemer zou kunnen zien wanneer we documenten met dezelfde trefwoorden uploaden en met slimme analysetechnieken privé-informatie kunnen afleiden. Bovendien lekt het schema extra informatie zoals het aantal trefwoorden in een document en metadata zoals wanneer we een specifiek document verwijderen.

Slotwoord

Samen doken we in de wereld van doorzoekbare encryptie en ontwierpen we een eenvoudig schema. In mijn onderzoek heb ik een systeem ontworpen om wildcard-ondersteunende schema's te maken met extra veiligheidsgaranties. Helaas is er geen blogpost die lang genoeg is om alle intrinsieke kenmerken uit te leggen. Ik hoop dat ik uw interesse heb gewekt in de fascinerende wereld van de doorzoekbare encryptie. Neem gerust contact met me op als u meer wilt weten over dit onderwerp!