Chiffrement côté client et proxy interceptant et posttraitant les requêtes

Bonjour à tous,

Je travailles sur une application d'accès sécurisé à une base de données dans le cas où l'administrateur SGBD n'est pas considéré comme sûr (aucun déchiffrement autorisé côté serveur). Je me tourne donc vers un chiffrement/déchiffrement côté client.(http://www.postgresql.org/docs/8.4/i...n-options.html -> Client-side encryption)

L'idée est de réaliser un proxy côté client qui recevrait les requêtes SQL en clair et qui ferait la translation de ces requêtes pour accéder aux données chiffrées. Le SGBD traiterait donc une requête qu'il ne "comprend pas" sur des données chiffrées et renverrait un résultat chiffré. Ainsi même si le canal de transmission et tout le côté serveur est compromis, cela ne pose pas de problèmes.

Cette fonctionnalité est plutôt côté "driver" et j'ai donc cherché sans succès des traces d'implémentations de telles fonctionnalités dans libpq. Le message de la mailing list [HACKERS] PostgreSQL traite de la question sans donner de réponses ni de pistes. http://www.mail-archive.com/pgsql-ha...msg131276.html

L'architecture serait la suivante :

Application
cliente <->JDBC <-> Le proxy à développer <-> SGBD (PostgreSQL)

Le but est de rendre ce proxy "invisible" pour l'application cliente utilisant des drivers standards (JDBC, libpq,....)

J'ai donc plusieurs questions :

- Auriez vous connaissance de drivers présentant ce genre de fonctionnalités ?
- Je vais avoir à "intercepter" les requêtes SQL sortant des drivers pour les post-traiter, puis les rediriger et enfin renvoyer les résultats du SGBD vers le client initial. Je manque de documentation claire sur les protocoles de communication entre le driver JDBC et la base de données. Suffit-il d'indiquer au client le port du proxy à la place du port du SGBD et de mettre une socket en écoute sur ce port pour récupérer le "flux" SQL ?

Merci à tous ceux qui auront pris le temps de lire ce long post :)
Je le mettrai à jour au fur et à mesure de mon avancement.

PS : langage de programmation pour le proxy, probablement Python ou Java

Du point de vue de l'architecture, un tel proxy serait au même niveau que des programmes comme pgpool ou pgbouncer.
Du point de vue de la programmation réseau ce n'est pas très difficile de se positionner comme intermédiaire entre le client et le serveur.
En revanche pour transformer les flux SQL pour crypter et décrypter, il faut décoder le protocole client-serveur postgresql et là c'est certainement un gros travail.