MongoDB laat databasegebruikers query's uitvoeren op versleutelde data

MongoDB heeft een preview uitgebracht van een functie waarmee gebruikers zoekopdrachten kunnen uitvoeren op versleutelde data. Queryable Encryption werkt op data die versleuteld op servers staat en kan voorlopig alleen equalityquery's doen.

MongoDB heeft Queryable Encryption als preview uitgebracht. Gebruikers kunnen daarmee zoekopdrachten uitvoeren op een versleutelde database. Voorlopig gaat het alleen nog om equalityquery's, waarmee een gebruiker kan zien of een zoekopdracht wel of niet voorkomt in de tekst. In de toekomst komen daar ook query's bij voor range, pre- en suffixes, substrings en meer, zegt het bedrijf.

Gebruikers kunnen velden en databases versleutelen met encryptiesleutels van derde partijen die de Key Management Interoperability Protocol-standaard ondersteunen zoals AWS, Google Cloud of Azure. Als gebruikers een query draaien, kijkt MongoDB eerst of die wordt gedaan op een normaal of een versleuteld veld. In dat laatste geval wordt de sleutel opgehaald bij de externe provider. Die query wordt dan als een ciphertekst naar de MongoDB-server gestuurd. Die kan er vervolgens een berekening op loslaten, zoals een equality-zoekopdracht. Het resultaat wordt eveneens versleuteld naar de eindgebruiker gestuurd, die de decryptiesleutel bezit.

De ver- en ontsleuteling gebeurt op die manier volgens MongoDB alleen client-side, maar databasebeheerders hebben zo wel een versleutelde database waar ze zelf de informatie niet uit kunnen lezen. Dat kan handig zijn in sectoren waar strenge compliance-eisen gelden voor hoe er met data wordt omgegaan. Data kunnen volgens MongoDB in Atlas en Enterprise Advanced zowel automatisch als handmatig versleuteld worden. Bij het handmatig versleutelen hebben gebruikers de mogelijkheid om opties toe te voegen, zoals welke encryptiestandaard er wordt gebruikt. Dat laatste is in de Community Edition niet mogelijk.

MongoDB zegt dat het de eerste databaseaanbieder is die zoeken in versleutelde data mogelijk maakt. Het is niet het enige bedrijf dat daarmee bezig is. Tweakers schreef eerder een achtergrondverhaal over dergelijke homomorfe encryptie. Ook bedrijven zoals IBM en onderzoeksinstituten zoals TNO onderzoeken de mogelijkheden om op een dergelijke manier informatie uit versleutelde data af te lezen.

Reacties (33)

[MarbHarmsen]

Kan iemand met meer verstand van het onderwerp mij helpen dit te begrijpen. Allereerst vraag ik me af waarom dit 'bijzonder' is, en of dit daadwerkelijk een "homomorfe" operatie is.

Laten we voor het gemak het plaatje volgen, de daadwerkelijke info is "901-10-4312" wat de gebruiker versleuteld heeft als "er493grtee4erw". Hij weet de sleutel en kan dus altijd converteren tussen "901-10-4312" <-> "er493grtee4erw" (versleuteling is toch altijd een one-to-one mapping). Als hij dan wilt zoeken, dan moet hij me niet "901-10-4312" sturen, want ik ken alleen de versleutelde data. Dus moet hij de zoekterm versleutelen, en me dus naar "er493grtee4erw" vragen, dat kan ik wel voor hem vinden, ondanks dat ik niet weet wat dit betekend. Maar ik snap niet wat hier nieuw aan is, kon dit niet altijd al.
Ik snap trouwens het nut van homomorfe operaties wel, maar dit lijkt me daar niet één van.

Wat dit wel betekend is dat in de database:
1) alle 'veldnamen' publiek zichtbaar moeten zijn.
2) je alle velden van "Jones Glee" los moet versleutelen
3) je moet alle velden via de zelfde key versleutelen, je moet namelijk bij je zoekopdracht weten via welke key "901-10-4312" is versleuteld, terwijl je nog niet weet wie dat is.

Het resultaat is dat je in je database heel veel (kleine) entries hebt die allemaal met de zelfde sleutel versleuteld zijn, ik vraag me af of dat de veiligheid verzwakt. En bij een groot gedeelte van die fields snap je het "data-format". Stel je voor dat er een rekeningnummer veld is. We weten precies hoe de ontsleutelde informatie er uit ziet NLcc AAAA xxxx xxxx xx (waarbij cc een controle getal is dat je kunt uitrekenen aan de hand van de rest van de IBAN getallen). Ik heb dus van een miljoen gebruikers het versleutelde IBAN, en ze zijn allemaal via de zelfde sleutel versleuteld, terwijl ik ongeveer weet wat er uit komt. Kan ik dan daarmee ontsleutelen, waarom (niet), en wat nu als ik van één gebruiker het echte IBAN weet. Kan ik dan meer?

(btw Ik vind versleutelingen een boeiend onderwerp, maar weet er veel te weinig van)

[Reactie gewijzigd door MarbHarmsen op 23 juli 2024 08:20]

[JakkeMan]

De belangrijkste reden hiervoor is performance en scalability.
Ja, dat kon al lang, maar tot hiervoor was het custom work, development om op dit punt uit te komen. En laat nu net die kennis bij niet veel mensen aanwezig zijn om dit soort van projecten tot een goed einde te brengen.

Sinds de invoering van GDPR zijn dit soort van projecten alleen maar belangrijker geworden, en komen ze hoger op de prioriteitenlijstjes. Waardoor de DB vendors nu beginnen te beseffen dat encryptie van data heel waardevol is, en dat ze het als een service willen aanbieden.

Hierdoor kan het kennisniveau naar beneden, en zullen die diensten alleen maar sneller in allerhande projecten kunnen gebruikt worden. Waardoor het security-niveau snel(ler) omhoog kan. Natuurlijk zijn dat niet de enige factoren.

Maar om op jouw technische vraag terug te komen, de vraag bij commerciele encryptie projecten, is altijd waar loopt de crypto-performance. Voor belangrijke projecten is sleutelbeheer enorm belangrijk wegens de accountability op het gebruik van de sleutels. In het verleden werden en dikwijls hardware toestellen in eigen beheer gebruikt, maar wegens availability en scalability zijn er moderne oplossingen nodig.

Central key management, waarop dit soort van toepassingen ontsloten worden, worden meer en meer de standaard. Er zijn meestal normen of standaarden die moeten gehaald worden voor overheid/defensie/wetgeving/payment/...-organisaties. De exacte crypto die hier dan minimaal moet op toegepast worden, kan je in de meeste van die technische documenten terugvinden.

Maar dit is inderdaad zoals je aanhaalt, enkel te bereiken met homomorfe encryptie. Dit is een container begrip voor verschillende one-way transacties om search functies te enabled op crypto data. Hier zullen de komende jaren nog enrome stappen kunnen genomen worden qua performance.

Indien je naast search queries, ook de effectieve data nodig hebt voor extra operaties, dan zal er tot vandaag nog steeds decryptie moeten plaatsvinden. Hiervoor is de wetenschapscommunity nog steeds naarstig op zoek naar nieuwe crypto-methodes. En zie je hier ook meer en meer funding naartoe gaan vanuit de business kant.

[Rafe]

https://ciphersweet.paragonie.com/ bestaat al een paar jaar. Ik moet er goed voor gaan zitten om ze te vergelijken maar afgaande op het plaatje werkt het hetzelfde.

[GeroldM]

De belangrijkste reden hiervoor is performance en scalability.

MongoDB is een NoSQL database, welke in principe goed schaalbaar zijn en data snel kunnen verwerken. Maar in het artikel staat dat er bij elke query contact gezocht word met de 3e partij die gebruikte sleutels verstrekt.

Dus is het meteen zo dat als er een probleem is met deze 3e partij, de data in de database ook niet beschikbaar is voor de eigenaar van de database. Of dat de database retetraag word als er een capaciteitsprobleem bij die 3e partij plaatsvind.

Het concept van versleutelde data staat mij wel erg aan, maar of op deze manier de goede kwaliteiten van een NoSQL database nog overeind blijven staan, daar heb ik twijfels over. Misschien speelt het bij MongoDB minder, maar over het algemeen worden NoSQL databases gebruikt voor time-series data, welke op zich al vrij neutraal is, want dat is waar dit soort databases in uitblinken.

Misschien is het dan slimmer om zelf de versleuteling te regelen (self-signed), want blijft de eigenaar van de database ook baas van de versleutelde data. Zolang onverlaten de versleuteling niet in handen hebben, is dat net zo veilig als een 3e partij de versleuteling laten beheren. En je kan de validiteits verzoeken nu ook binnenshuis houden, wat de performance alleen maar ten goede komt.

Ook is er een minder groot probleem met backups van de versleutelde data. Heb je zelf de sleutel, dan is het niet zo moeilijk om oudere data weer terug te halen, mocht dat nodig zijn. Maar als een 3e partij de versleuteling in beheer heeft, dan zijn na verloop van tijd de backups compleet ontoegankelijk geworden.

Conceptueel is dit een nuttige ontwikkeling, maar ik zie behoorlijk grote beren op de weg.

[Sublimity]

Het voorbeeld dat hier geschetst wordt is misschien niet helemaal het juiste. In principe stelt "searchable encryption" (zoals het in de literatuur genoemd wordt) je in staat om allerlei soorten zoekoperaties uit te voeren op versleutelde data. Zo kan je bijv. alle gebruikers uit een databasetabel met een leeftijd hoger dan 50 opvragen, zonder dat alle individuele "leeftijd" velden ontsleuteld moeten worden.

De daadwerkelijke manier van versleuteling hangt af van het gebruikte scheme, maar er bestaan al verscheidene technieken om dit op een veilige en efficiënte manier te doen. Doorgaans heeft elke gebruiker een eigen geheime sleutel, dus in jouw voorbeeld zouden alle IBAN nummers met een andere sleutel versleuteld zijn. Verder zijn veel encryption schemes non-deterministisch, wat betekent dat als je dezelfde informatie met dezelfde sleutel versleutelt, je twee verschillende ciphers krijgt.

[MarbHarmsen]

Bedankt voor de info, operaties als zoek iedereen met een geboorte datum van voor 1982 lijkt me inderdaad een indrukwekkende toevoeging die me ook lastig lijkt om te ontwikkelen. Dan is het een stuk beter dan het voorbeeld dat ze hebben gegeven.

Origineel ging ik ervan uit dat iedereen onafhankelijk versleuteld was. Maar ik zie niet hoe dat kan werken, je moet namelijk de correct versleutelde query sturen naar MangoDB. Als je iedereen apart versleuteld dan weet je toch niet hoe je zoekopdracht eruit ziet, want je weet nog niet wie die persoon is, of personen zijn. Dus hoe weet je welke sleutel je moet gebruiken om de versleutelde zoekopdracht te genereren.

@RefriedNoodle & @Sublimity ik heb er naar gegoogled en er zijn inderdaad verscheidene manieren om ervoor te zorgen dat herhaalde encrypties niet steeds tot het zelfde antwoord leiden. Deze zijn dus niet one-to-one maar one-to-many waarbij inversie zodanig dat inversie nog wel mogelijk is, een voorbeeld daarvan is Probabilistic Encryption. En dat kende ik nog niet. Het lijkt precies bedoeld om te voorkomen dat je de key kan herleiden uit herhaaldelijk gebruik van dezelfde encryptie key. En het voorkomt de door mij voorgestelde IBAN aanval.

Maar ik snap niet hoe zo'n soort encryptie algoritme gebruikt kan worden in het voorbeeld van MangoDB. Het probleem is dat je voor een zoekopdracht de correct encrypted query moet geven. Als je dus '901-10-4312' zoek moet je daar altijd 'er493grtee4erw' van kunnen maken, toen je de data origineel invoerde, nu en als je in de toekomst opnieuw zoek ook. Terwijl een one-to-many encryptie steeds andere encrypted queries verstuurd als je op '901-10-4312'.

Ofwel zijn ze bij MangoDB veel intelligenter dan ik (ongetwijfeld), ofwel de methode die ze gebruiken is veel complexer dan wat de tekst van Tweakers doet vermoeden, ofwel het verminderd de veiligheid, omdat ze deterministic encryption gebruiken, en bij iedereen dezelfde key.

[Sublimity]

Het is een tijdje geleden dat ik me hiermee heb bezig gehouden, maar voor zover ik me herinner is de query niet letterlijk de tekst die je zoekt. Er zit iets meer complexiteit achter het opstellen van een query. Anders zou het alsnog niet mogelijk zijn om ">" zoekopdrachten te doen op versleutelde data.

Daarnaast vindt er voordat een gebruiker data op kan slaan en kan doorzoeken een soort handshake plaats, waarin de beide partijen de nodige informatie uitwisselen. Denk hierbij een bijvoorbeeld de publieke sleutel van de gebruiker (hoewel dit totaal afhankelijk is van hoe de Searchable Encryption geïmplementeerd is).

[Krystalize]

Bij het verzenden van een query naar de server kan er middels bijvoorbeeld Diffie-Hellman een sessie key afspreken en die gebruiken voor de versleuteling van de query. Dit betekend dat de server de query in plain tekst heeft. Daarna kan MongoDB doen wat ze willen kwa vergelijken met versleutelde data.

Het is dus niet zo dat je de versleutelde versie zoals deze in de db staat hoeft te verzenden, je vraagt naar de plain text, versleuteld met een sessie sleutel.

[RefriedNoodle]

versleuteling is toch altijd een one-to-one mapping

Ik ben geen encryptie-expert, maar volgens mij is dit niet altijd waar, en zijn er encryptie-algoritmes die bij dezelfde input verschillende outputs leveren (die bij decryptie natuurlijk weer wel naar dezelfde data leiden).

Ik hoor graag van iemand of dit wel of niet waar is, maar als dit zo is haalt dit wel een stuk van je theorie onderuit.

[Verwijderd]

@MarbHarmsen schreef:

versleuteling is toch altijd een one-to-one mapping

RefriedNoodle reageerde daarop met:

[...] zijn er encryptie-algoritmes die bij dezelfde input verschillende outputs leveren (die bij decryptie natuurlijk weer wel naar dezelfde data leiden).

Dat is essentieel om aanvallen te bemoelijken.

Waarom dat nodig is, zie je in de met AES versleutelde "ECB penguin"; in het tweede (versleutelde) plaatje zijn de contouren van de pinguin zichtbaar.

Dit probleem kun je oplossen door in elk te versleutelen blok een uniek getal (dat niet geheim is) op te nemen.

[Geckow]

Niet helemaal. Dezelfde input geeft dezelfde output. Als je met dezelfde key (en IV, Initialisation Vector) dezelfde data op dezelfde manier encrypt moet de output hetzelfde zijn. Juist door de IV random te laten zijn kun je ervoor zorgen dat de output steeds verschild, en daarmee belangrijk om semantic security te bereiken.

Dat plaatje van de pinguin komt doordat elk blok los encrypted, en steeds met dezelfde of geen IV. Een witte pixel komt dan altijd tot dezelfde encrypted string, waardoor je inderdaad patronen gaat zien. Daarom zijn er verschillende modes, waarbij steeds voorgaande output gebruikt wordt als input voor het volgende blok. Maar nogmaals: met dezelfde key, IV, methode en input is de output ook hetzelfde.

[Verwijderd]

Als je met dezelfde key (en IV, Initialisation Vector) dezelfde data op dezelfde manier encrypt moet de output hetzelfde zijn.

Dat weet ik, maar mijn ervaring is dat leken afhaken zodra je over begrippen als IV begint - en ik wou het kort houden.

Juist door de IV random te laten zijn kun je ervoor zorgen dat de output steeds verschild, en daarmee belangrijk om semantic security te bereiken.

De luxe van een random IV voor elk blok heb je vaak niet, want dat kost extra opslagruimte (iets dat je bijv. niet hebt als bij Full Disk Encryption een versleutelde sector niet méér ruimte mag kosten dan een onversleutelde sector, en waarbij je ook geen CBC o.i.d. kunt gebruiken. Vandaar dat het sectornummer er meestal op de een of andere manier als "nonce" bij betrokken wordt).

Dat plaatje van de pinguin komt doordat elk blok los encrypted, en steeds met dezelfde of geen IV. Een witte pixel komt dan altijd tot dezelfde encrypted string, waardoor je inderdaad patronen gaat zien.

Ik gebruikte de penguin precies om te laten zien wat er gebeurt als versleuteling altijd dezelfde output zou opleveren, zoals MarbHarmsen schreef:

Hij weet de sleutel en kan dus altijd converteren tussen "901-10-4312" <-> "er493grtee4erw" (versleuteling is toch altijd een one-to-one mapping).

[CAPSLOCK2000]

Kan iemand met meer verstand van het onderwerp mij helpen dit te begrijpen. Allereerst vraag ik me af waarom dit 'bijzonder' is, en of dit daadwerkelijk een "homomorfe" operatie is.
<knip>
Maar ik snap niet wat hier nieuw aan is, kon dit niet altijd al.

Volgens mij is nieuw dat MongoDB zelf iets ingebouwd heeft om deze werkwijze makkelijk te maken. Volgens mij heb je gelijk dat er niks echt fundamenteel nieuws is dat niet eerder al mogelijk was als je het zelf bouwde. Het nieuwe is dus dat je het zelf niet meer hoeft te bouwen.

Het belangrijkste punt is geloof ik vooral dat de sleutel niet in het bezit van MongoDB is. MongoDB kan wel aan een ander systeem vragen om crypto-operaties te doen maar kan het niet zelf. Als je MongoDB gestolen wordt kan de dief niks met de data zonder ook de keyserver te sttelen en open te breken.l

[Sublimity]

Met searchable encryption kan je als gebruiker je eigen data versleutelen. Hierdoor hoeft je geheime sleutel in theorie nooit je lokale machine te verlaten.

[bush]

Lijkt me niet dat ze de eerste zijn, SQL Server Always Encrypted bestaat al jaren
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver16

uit de documentatie

Always Encrypted provides confidential computing capabilities by enabling the Database Engine to process some queries on encrypted data

[XIU]

En sinds SQL 2019 nog verder uitgebreid met complexere zoekopdrachten: https://docs.microsoft.co...ves?view=sql-server-ver16

[HappyReader]

In het geval van SQL Server wordt er deterministic encryptie gebruikt. MongoDB geeft aan dat dit voor random encryptie werkt.

In SQL Server 2016 (13.x), SQL Server 2017 (14.x) and in Azure SQL Database, Always Encrypted supports equality comparison via deterministic encryption.

[Reactie gewijzigd door HappyReader op 23 juli 2024 08:20]

[Yarisken]

Dus eigenlijk database beheerders de data niet meer laten zien ...
Kan er me wel in vinden. Bij echt gevoelige data wil je echt beperken wie deze kan inzien. Beheerders vallen hier niet altijd onder.

[klakkie.57th]

Als je database beheerder de data niet mag zien, hoe gaat die dat een query/view schrijven en de data output kunnen verifiëren?

Dat is net één van de taken van het merendeel van de DBA’s

Dit is toch echt meer een oplossing om diefstal van data te voorkomen wanneer een hele server/database gestolen wordt

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 08:20]

[DUX]

Door het (laten) maken van data-testsets met geanonimiseerde data of dummydata waarmee je je view kunt gaan ontwerpen Wanneer de view de juiste/verwachte testdata laat zien kan het viewontwerp doorgezet worden naar de volgende fase in je OTAP-straat. Zo heb je een technisch werkende oplossing zonder ooit productiedata te hebben gezien.

[Reactie gewijzigd door DUX op 23 juli 2024 08:20]

[klakkie.57th]

The perfect world … maar hoe vaak kom je dat tegen. Een HR departement die voldoende kennis in huis heeft om na de initiële setup alles zelf te doen .. en is dat dan eigenlijk ook geen HR-DBA dan ??

[DUX]

Ik mag toch hopen dat de HR-afdeling weet hoe de software werkt waar ze hun werk mee moeten doen?

Nee, dan zit je testprocedure niet goed in elkaar. De (key) users moeten een functionele test doen om te checken of alles binnen de applicatie naar wens en vooral naar verwachting werkt. De technische test heb je reeds afgerond met testdata zoals hierboven beschreven. De users hebben onder begeleiding van een test engineer testscripts gemaakt (ga hierheen, klik daar, verschijnt dit) zodat de werking van een applicatie op een gestandaardiseerde manier nagekeken wordt en ook onafhankelijk van de geselecteerde tester dezelfde resultaten oplevert. Het liefst nog in een acceptatieomgeving (dus nog steeds geen productiedata). De users zijn over het algemeen de kennishouders van (werking van) de applicatie, niet de DBA'er, en tekenen ook af voor een correcte werking van de applicatie. Geen vaag gezeik richting IT dat dingen niet werken: wát werkt er niet, hoe heb je dat getest dan als key user? Verantwoordelijkheden beleggen waar ze horen.

Dat je deze gang van zaken (te) weinig tegenkomt is niet relevant voor de initiële vraag hoe zo'n ontwikkeling doorlopen zou moet worden. Als de workflow niet op een dergelijke wijze is ingericht maar het is wél nodig, dán ga je het dus wel zo inrichten óf je accepteert de gevolgen dat een DBA'er bij gevoelige data kan/de DBA'er zich bezighoudt met taken die niet standaard bij een DBA'er horen, etc.

[mphilipp]

Klopt. Maar dat kan in Oracle ook al. Daar kun je de data versleutelen, terwijl de DBA's wel de mogelijkheid hebben om data te exporteren (naar een versleuteld bestand uiteraard) en backups te maken. Zelfs de audit logs kunnen indien gewenst op een externe server worden geplaatst waar de DBA's geen toegang toe hebben. Zonder die optie is het nl wel erg makkelijk om je eigen sporen te wissen.
Ik meende ook dat ik in Oracle ook queries kan uitvoeren op encrypted data, en afhankelijk of ik de juiste key heb, die ik garbage óf de decrypted data. Het verschil is denk ik dat ik niet de encrypted velden zelf kan queryen. Nooit echt mee gewerkt eigenlijk, alleen in presentaties zien langskomen.

[klakkie.57th]

Maar dan is eerder het punt , wat is een DBA.

Dit soort features gebruik ik eerder bv in een query en dan zijn bepaalde velden leesbaar voor iedereen en andere bv niet.
Dus lijst van alle werknemers inclusief loon. Dat laatste is dan encrypted en enkel iemand met de juiste key kan ook dat veld inkijken.

[mphilipp]

De DBA is de beheerder van de database (database administrator) en die heeft (in principe) geen wachtwoord nodig om data te zien van alle gebruikers. Inmiddels heeft (oa) Oracle mechanismen om ook voor een DBA data af te schermen, zonder zijn werk onmogelijk te maken. Hij moet immers data kunnen backuppen en/of exporteren. Daarvoor heb je toegang nodig. Het is best een complex probleem, want zo is de DBA, net als de systeembeheerder altijd een zwakke schakel vwb security/privacy/spionage.

[AlphaRomeo]

Volgens mij gaat het niet zozeer om beheerders maar eerder om gelekte databases en hardware diefstal. Als de data versleuteld is opgeslagen in de database is een gelekte database dus min of meer onbruikbaar. Afgezien van brute-force aanvallen zoals @Skit3000 terecht aangeeft.

[The Zep Man]

Volgens mij gaat het niet zozeer om beheerders maar eerder om gelekte databases en hardware diefstal. Als de data versleuteld is opgeslagen in de database is een gelekte database dus min of meer onbruikbaar.

Veel databases worden 'gep0wned' via de systemen als die de database gebruiken. Ergo, sleutel + versleutelde data = ontsleutelde data.

Verder is het goed als die functies er zijn, maar moeten ze wel geïmplementeerd worden. De meeste lekken komen uit organisaties die (onder andere) niet voldoende investeren in hardening.

[DUX]

Het afscheiden van beheerdersinzage was al mogelijk via andere manieren, meen ik. Ik ben niet geheel op de hoogte maar MSSQL kan dit al. Wellicht dat een MSSQL-adept hier verder de verschillen t.a.v. het nieuwsartikel kan beschrijven?

[Skit3000]

Met een equality-query kun je de complete inhoud van een database leegtrekken door te brute-forcen. Voor lange teksten is dit natuurlijk niet te doen, maar als iemand een versleuteld veld gebruikt om bijvoorbeeld beschermde persoonsgegevens zoals ras of godsdienst op te slaan dan is deze versleutelingsoptie niet echt heel sterk.

[CAPSLOCK2000]

Met een equality-query kun je de complete inhoud van een database leegtrekken door te brute-forcen. Voor lange teksten is dit natuurlijk niet te doen, maar als iemand een versleuteld veld gebruikt om bijvoorbeeld beschermde persoonsgegevens zoals ras of godsdienst op te slaan dan is deze versleutelingsoptie niet echt heel sterk.

Dat klopt, daar is deze beveiliging niet op gericht.
Het is inderdaad mogelijk om die hele database leeg te trekken maar dat kon je toch al, ook zonder deze vorm van encryptie. Het gaat er om dat je vervolgens niks met die data kan als je geen toegang hebt tot de private key.

Deze bewaking is nuttig in het geval de hele database gestolen wordt, bijvoorbeeld omdat iemand de HD van de server steelt. In dat geval is de database nutteloos als de bijhorende sleutel niet ook gestolen wordt en die wordt hopelijk ergens apart opgeslagen op een goed beveiligde plek.

[pietje63]

Bij stap 1 staat "query from authenticated client", ik neem aan dat er bij stap 4 niet enkel een equality check plaatsvindt, maar ook een recht op toegang check.

Overigens lijkt me dit vooral een aanpassing in hoe de driver werkt, niet hoe de database werkt, of zie ik dat verkeerd?

[Cartman!]

Gezien je alleen exacte matches kunt doen maak ik eruit op dat ze "gewoon" een hash/hmac van de data maken en als soort kopie bij de encrypted waarde opslaan. Als er dan een query komt voeren ze dezelfde hash/hmac operatie uit en voeren ze die vergelijking uit op de hash kopie. Zo doe ik t zelf namelijk ook altijd (met andere DBs, ik gebruik geen MongoDB) en werkt heel goed. Handig als je dit nu kunt doen zonder custom logica

[Atlantis1995]

Volgens mij kan Orcacle prima werken met encrypted data. Het enige verschil t.o.v. Oracle is dat MongoDB non-rationeel is.