Discussion :

[Michael Guilloux]

ZeroDB : une base de données open source chiffrée de bout en bout
Elle permet aux applications d’interroger des données chiffrées

ZeroDB est une base de données open source « zero knowlegde » ou chiffrée de bout en bout. Écrite en Python, elle est basée sur ZODB (Zope Object DataBase), la base de données du serveur d’applications Zope. D’après sa description sur GitHub, « ZeroDB rend plus facile de développer des applications avec des garanties de sécurité et de confidentialité fortes, en permettant aux applications d’interroger des données chiffrées ».

Le serveur de base de données ne sait rien sur les données qu’il stocke, ce qui réduit considérablement le risque de violation des données. En effet, toutes les opérations se font du côté client, qu’il s’agisse du chiffrement, du déchiffrement ou de la compression des données. La logique de base de données est également gérée côté client. En ce qui concerne les requêtes, elles sont chiffrées de bout en bout. Cela signifie que les clients peuvent exécuter des requêtes sur les bases de données chiffrées et récupérer des enregistrements sans jamais exposer les données déchiffrées au serveur de base de données. Les données sur le serveur sont toujours chiffrées, qu’elles soient au repos, en transit, ou en cours d’utilisation. Le serveur n’a jamais aucune connaissance sur les données, leur structure ou leur ordre. Cela implique que même si des attaquants arrivent à infiltrer le serveur, ils ne pourront pas avoir accès aux données en clair.

En ce qui concerne les fonctionnalités offertes par ZeroDB, il lui est attribué d’offrir la plupart des fonctionnalités attendues dans une base de données moderne. La base de données offre également des performances adéquates. En exécutant la logique de requête côté client, ZeroDB ne ralentit pas les requêtes parallèles. Les clients peuvent encore exécuter des requêtes à distance sur les données chiffrées sans avoir à les télécharger totalement et sans rencontrer une baisse de performance excessive. Ils disposent également d’un cache qui stocke les parties les plus utilisées des structures de données et qui accélère considérablement les requêtes, quelles que soient leurs tailles.

ZeroDB pourra donc permettre aux développeurs de décharger des applications sensibles dans le cloud. Ces derniers pourront ainsi bénéficier des avantages de coût et de performance du cloud, sans compromettre la sécurité ou la facilité d’utilisation de leurs données.

Une implémentation en Python de la base de données chiffrée de bout en bout est disponible depuis hier. Un client JavaScript de ZeroDB est également prévu dans un avenir proche.

Sources : Blog ZeroDB, ZeroDB sur GitHub, ZeroDB Server sur GitHub

Et vous ?

Que pensez-vous de ZeroDB ?
Utilisez-vous d’autres bases de données chiffrées ? Lesquelles ?

Voir aussi

Forums Bases de données

[StringBuilder]

Je suis peut-être pas bien réveillé mais...

1/ Comment assurer l'intégrité des données si les requêtes se font côté client, et que le serveur ne peut pas analyser les données ? (pas de FK, de contrainte d'unicité, etc.), ou alors au prix d'une gestion des locks au niveau table de très longue durée
2/ J'ai toujours cru que le point d'entrée vulnérable d'un SI, c'est pas le serveur, mais les clients qui s'y connectent (Régis qui ramène la clé USB verrolée de chez lui pour jouer à Tetrinet avec son pote Robert), ou bien Ginette qui lance la macro contenue dans le PPTX bourré de chatons qu'elle vient de recevoir par mail

Du coup je vois mal l'intérêt de cette base, qui ne joue finalement pas d'autre rôle qu'une gestion d'artiches protégées par mot de passe (genre un dossier partagé avec des ZIP protégés dedans...)

[TiranusKBX]

Je suis peut-être pas bien réveillé mais...

1/ Comment assurer l'intégrité des données si les requêtes se font côté client, et que le serveur ne peut pas analyser les données ? (pas de FK, de contrainte d'unicité, etc.), ou alors au prix d'une gestion des locks au niveau table de très longue durée
2/ J'ai toujours cru que le point d'entrée vulnérable d'un SI, c'est pas le serveur, mais les clients qui s'y connectent (Régis qui ramène la clé USB verrolée de chez lui pour jouer à Tetrinet avec son pote Robert), ou bien Ginette qui lance la macro contenue dans le PPTX bourré de chatons qu'elle vient de recevoir par mail

Du coup je vois mal l'intérêt de cette base, qui ne joue finalement pas d'autre rôle qu'une gestion d'artiches protégées par mot de passe (genre un dossier partagé avec des ZIP protégés dedans...)

c'est sans doute une base document
quand à sont intérêt cela peut se présenter si la base est sur un serveur à part et pas forcément dans la même architecture réseau que le client

[heid]

Pour les index j'imagine que la valeur chiffrée est indexable mais comment fonctionnent les requête de range dans ce cas si le déchiffrage se fait coté client : where name > "B" ?

[SQLpro]

Il faut bien stocker les clefs quelque part... Si c'est sur le poste client c'est évidemment mien bien sécurisé en général que sur un serveur.
Le seul moyen efficace de stocker les clefs de chiffrement sans qu'elles soient volable est d'utiliser un HSM (Hardware Security Module) qui se branche sur le réseau, contient les clefs et s'autodétruit en cas de tentative d'accès malintentionné. Exemple Thales nShield

En outre pour éviter les attaques de décryptage par analyse fréquentielle il convient de saler le chiffrement ce que ne fais aucun SGBD open source (ni MySQL ni PostGreSQL...).

Enfin, le chiffrement du stockage des bases existe à travers TDE (Transparent Data Encryption) depuis de nombreuses années dans les SGBDR modernes (2008 par exemple pour SQL Server...).

Pour couronner le tout, effectivement les performances risque d'être lamentable car :
1) on n'a pas encore trouvé d'algorithme permettant de rendre cherchable par range (>, <, BETWEEN...) des données chiffrées sans salage
2) avec salage du chiffrement aucun prédicat de recherche, même l'égalité, n'est cherchable ! Il faut décrypter toutes les données pour comparer ce qui conduit à des "scans" systématique de table pour toute recherches avec en sus l'extraoverhead du déchiffrement ligne à ligne... !

Et ne parlons pas d'un sujet déjà évoqué... L'impossible gestion de l'intégrité des données !

Donc, une vrai foutaise !

A +

[amine.hirri]

Le serveur n’a jamais aucune connaissance sur les données, leur structure ou leur ordre

Cela remet en cause les performances du serveur. Comment peut-il récupérer les données en se basant sur les PK, FK ou INDEX?
De plus, toutes les données stockées ne sont pas toutes critiques, il n'est donc pas util de les crypter/décrypter à chaque fois!

[Traroth2]

Il y a aussi un site officiel : http://www.zerodb.io/

Je dois reconnaitre que pour l'instant, je ne comprends pas vraiment ce que ça fait ni comment ça marche...

Edit : j'ai lu la page de documentation, et je ne comprends toujours pas en quoi on peut même considérer que c'est une base de données (puisque tout le travail de résolution des requêtes est fait au niveau du client), et contre quels risques elle est supposée nous prémunir. Bof...

[TiranusKBX]

Dans la doc j'ai pus voir que ça s'utilise comme le 'Cloud Storage Azure' de Microsoft, des requêtes simples, pas de JOIN et une simple condition de recharche
Les tables stockquent des 'Entité' dont le format est variable dans les tables donc le client doit gérer la logique

[StringBuilder]

On en revient donc au fameux serveur de fichier ZIP protégés par mot de passe que j'évoquais...

[Traroth2]

On en revient donc au fameux serveur de fichier ZIP protégés par mot de passe que j'évoquais...

Ben ça ressemble assez à ça, en fait. Avec une API...

[Iradrille]

Donc... ya une DB chiffrée sur un serveur, un client fait une requête...
La requête est chiffrée donc le serveur ne peut pas la traiter.
Il envoie la base complète au client qui la déchiffre, effectue sa requête, chiffre la base et la renvoie au serveur ?

[TiranusKBX]

Donc... ya une DB chiffrée sur un serveur, un client fait une requête...
La requête est chiffrée donc le serveur ne peut pas la traiter.
Il envoie la base complète au client qui la déchiffre, effectue sa requête, chiffre la base et la renvoie au serveur ?

non sur ce genre de base tu fait une requête sur une table, il te renvois des données que sur la table et la recherche est possible car ton client vas donnez les valeurs de recherche cryptées au serveur, sinon tu l'aurait bien mal