Discussion :

[hugo123]

Bonjour,

Pour situer un peu le sujet, récemment sur l'appli sur laquelle je travaille nous avons eu des demandes pour crypter certaines données qui sont présentes en base de données.
Nous avions jusqu'ici du cryptage Md5 non symétrique, par exemple pour les passwords des utilisateurs.

Je ne connais pas bien les standards et les bonnes pratiques dans ce domaine. Je cherche une bonne méthode, sans parler d'implémentation pour l'instant.


Bref, grosso modo j'ai besoin d'un algorithme symétrique, car j'ai besoin des données cryptées dans mon application. A ce que j'ai pu lire, pour cela il faut donc passer par un couplé clé publique, clé privé et utiliser un algorithme de cryptage symétrique, par exemple AES.
Une chose qui me parait peu claire, c'est qu'en théorie ce couple clé privé/clé publique est généré par une entité puis fournie a l'application. Ce qui implique que l'application doit stocker quelque part cette clé privée pour décrypter les infos.

1) Dans mon cas, tout se passe en interne de l'application, donc la clé publique ne m'est pas trop utile non ?

2) C'est bien beau de crypter, mais si je stocke la clé privée en clair, cela ne me semble pas très sécurisé. Quel est le standard à ce sujet ?

3) Si un beau jour la clé publique est changé, la clé privé doit l'être aussi. Cela veut donc dire qu'il décrypter puis recrypter toutes les données ?

Quel est le standard pour une appli qui gère des données en interne et qui souhaite les crypter sur un support quelconque (base, fichiers etc....) ?

Merci d'avance pour vos éclaircissements

[tchize_]

le couple clé publique / clé privée sert quand ce sont deux entité distincte qui écrivent et lisent. Celle(s) qui écrit(vent) a(ont) la clé publique. Seule l'application effectuant la lecture à accès à la clé privée. Dans ton cas, c'est donc inutile.

Ensuite, il faut bien scinder cryptage et hashage. Le cryptage, c'est quand il y a un secret à connaitre, le hashage c'est quand il y a une vérification à faire. Le hashage (ex md5) est très bien pour les mot de passe, ce sont des données à vérifier (le mot de passe est-il le bon?) mais qu'on a pas besoin de lire (on a pas besoin de connaitre le mot de passe). L'avantage du hashage, c'est que c'est difficilement réversible.

Quand il faut "inverser", il faut alors un clé de cryptage (qu'elle soit symétrique ou pas). Dans ce cas, la sécurité des données n'est assurée que dans la mesure ou la clé est bien protégée (nombre d'opérateurs ayant accès à la clé limité, volatilité éventuelle de la clé*). Le cryptage de la db est d'un intérêt pour des cas limités. Il faudrait que tu nous explique le but de ce cyptage et pourquoi une simple restriction des droits d'accès à la DB n'est pas suffisant pour qu'on te conseille.


* On met parfois en place des système ou la clé n'est stockée que dans la tête de certains opérateurs/administrateur. En cas de (re)démarrage de l'application, celui-ci doit entrer manuellement la clé, elle est alors préservée dans une zone mémoire garantie de ne pas être swappée sur le disque. Elle n'est donc pas récupérable facilement.

[Tommy31]

Bref, grosso modo j'ai besoin d'un algorithme symétrique, car j'ai besoin des données cryptées dans mon application. A ce que j'ai pu lire, pour cela il faut donc passer par un couplé clé publique, clé privé et utiliser un algorithme de cryptage symétrique, par exemple AES.

Non, dans un cryptage symétrique il n'y a qu'une seule clé, la clé de cryptage. D'ailleurs, toute la sécurité de ce procédé repose sur la clé.

Ce qui implique que l'application doit stocker quelque part cette clé privée pour décrypter les infos.

L'application se sert de la clé pour crypter et décrypter. Cette information contenu dans l'application doit être elle-même cachée, sinon, le cryptage vole en éclat.

En général, lorsque l'application est adressée par des utilisateurs authentifiés, on se sert de leur mot de passe pour crypter les données de telle façon que la clé n'est pas directement contenu dans l'application.

[hugo123]

ok, merci pour vos précisions.

Il faudrait que tu nous explique le but de ce cyptage et pourquoi une simple restriction des droits d'accès à la DB n'est pas suffisant pour qu'on te conseille.

Nous stockons en base des paramètrages de connexion à d'autres applicatifs et donc des mots de passe. Certains clients ont des demandes assez fortes en ce qui concerne la sécurité (avec des pavés de 200 pages...) et une donnée sensible comme un mdp ne doit pas être en clair, que ce soit sur le disque ou en base.
J'ai donc besoin de les crypter et j'ai besoin que ce soit réversible car j'utilise ces paramétrage pour effectuer ces connexions dans l'application elle-même.

D'où mon souci concernant cette clé, qui ne peut être stocké en base pour la même raison.

* On met parfois en place des système ou la clé n'est stockée que dans la tête de certains opérateurs/administrateur. En cas de (re)démarrage de l'application, celui-ci doit entrer manuellement la clé, elle est alors préservée dans une zone mémoire garantie de ne pas être swappée sur le disque. Elle n'est donc pas récupérable facilement.

Ici cela me semble adapté dans le cas ou j'utilise cette clé pour crypter et décrypter sans stockage, c'est a dire que j'ai besoin de cette clé uniquement le temps que mon application tourne. Mais dans mon cas, je stocke les valeurs cryptées en bases de données, donc j'ai besoin qu'après redémarrage la clé soit toujours identique.

L'application se sert de la clé pour crypter et décrypter. Cette information contenu dans l'application doit être elle-même cachée, sinon, le cryptage vole en éclat.

C'est effectivement la conclusion a laquelle je suis arrivé mais je ne vois pas comment. Le stockage de cette clé est tout autant problématique que le stockage d'un mot de passe et mettre un système de cryptage de clé c'est se se mordre la queue ^^

[tchize_]

quand je parlais de la clé dans la tête, j'entendais qu'il fallait que l'opérateur entre la clé au redémarrage de l'application. Cette technique est utilisé sur les filesystem crypté contenant les clés de signature de certaine root CA, où cette information est extrèmement sensible. Dans ton cas, si les applicatifs tiers ne sont utilisés que pendant la présence de l'utilisateur, utiliser le mot de passe du user comme base semble un bon compromis. Attention cependant, si l'utilisateur perd son mot de passe, il est parti pour une reconfiguration totale de ses accès aux applications tierces

[Invité]

Salut,

Ce que je ferais pour enregistrer des données chiffrées dans une BDD : un objet PKCS#7 contenant les informations:
* Cet objet contient l'information cryptée par un algorithme symétrique (triple DES, AES, ...)
* la clef symétrique dudit algorithme cryptée par un procédé asymétrique (RSA, ...). Pour faire cet object PKCS#7 tu as besoin d'un objet PKCS#12 qui contient un certificat avec la clef publique et la clef privée. C'est ici que l'humain doit intervenir: l'objet PKCS#12 est protegé par un mot de passe étant donné qu'il contient une clef privée.

Si je n'ai pas été assez clair et que tu es intéressé par cette solution demande moi.

[divxdede]

Il faut savoir qu'utiliser un protocole de chiffrement asymetrique est trés couteux et peut nuire aux performances.

Généralement, voici comme un protocole de sécurité procéde:

1. [dialogue en clair] Echange des protocoles de chiffrement supportés
Les deux hotes doivent se mettre d'accords sur
. Un protocole asymetrique
. Un protocole symétrique

2. [pas de dialogue] Création d'une clé asymétrique avec le protocole commun par l'hote "client"

3. [dialogue en clair] Envoi de la clé publique de l'hote "client" à l'hote "serveur"

4. [pas de dialogue] Génération par l'hote "serveur" de la clé symétrique

5. [dialogue chiffré asymetrique] envoie de la clé symétrique à l'hote "client" avec un message chiffré asymétrique

6. [dialogue chiffré symétrique] dialogue standard protégé en utilisant la clé symétrique.

C'est approximativement ce que fait un protocol comme SSL (ce qui corresponds à ce que l'on appelle l'handshaking)

Exemple de protocole asymétrique : RSA
Exemple de protocole symétrique : AES

SSL négocie également un protocole de hashage (ex MD5) pour gérer l'intégrité des messages.

Crypter ton flux en AES est beaucoup plus efficaces et rapide que de tout crypter en RSA.

Avec ce mécanisme, tu réalises correctement un protocol dit "confidentiel" mais il ne gére pas d'authorisation (fait par exemple avec des certificats).

SSL gére pour toi les 3 domaines: Confidentialité, Authentification et Intégrité. pour un système sur, il te faut les 3.

Si tu en as la possibilité, oriente toi vers SSL (SSLEngine est assez souple).

PS: En général le programme résident possédant la clé symétrique est considéré comme de confiance et n'a pas a mettre en place de système complexe pour stocker en mémoire cette clé.

[divxdede]

Salut,

Ce que je ferais pour enregistrer des données chiffrées dans une BDD : un objet PKCS#7 contenant les informations:
* Cet objet contient l'information cryptée par un algorithme symétrique (triple DES, AES, ...)
* la clef symétrique dudit algorithme cryptée par un procédé asymétrique (RSA, ...). Pour faire cet object PKCS#7 tu as besoin d'un objet PKCS#12 qui contient un certificat avec la clef publique et la clef privée. C'est ici que l'humain doit intervenir: l'objet PKCS#12 est protegé par un mot de passe étant donné qu'il contient une clef privée.

Si je n'ai pas été assez clair et que tu es intéressé par cette solution demande moi.

Je suis assez d'accord avec cette proposition (passer par un PKCS#12) mais pourquoi utiliser un PKCS#7 ? ques-ce que ca apporte ?

[hugo123]

Salut,

Ce que je ferais pour enregistrer des données chiffrées dans une BDD : un objet PKCS#7 contenant les informations:
* Cet objet contient l'information cryptée par un algorithme symétrique (triple DES, AES, ...)
* la clef symétrique dudit algorithme cryptée par un procédé asymétrique (RSA, ...). Pour faire cet object PKCS#7 tu as besoin d'un objet PKCS#12 qui contient un certificat avec la clef publique et la clef privée. C'est ici que l'humain doit intervenir: l'objet PKCS#12 est protegé par un mot de passe étant donné qu'il contient une clef privée.

Si je n'ai pas été assez clair et que tu es intéressé par cette solution demande moi.

Si je comprends bien l'idée, je stocke ma valeur et la clé me permettant de la décrypter au même endroit et crypté eux mêmes a l'aide d'un couple clé publique/clé privé qui serait stocké dans un keystore.

Pour avoir accès au keystore, il me faudrait un mdp afin de pouvoir récupérer mon couple de clé.

Pour confirmer cependant :
- si je change mon couple de clé, j'imagine bien qu'il faut rechanger toutes les valeurs qui ont été crypté avec ces clés, c'est bien cela ? Il faut donc prévoir un mécanisme pour changer la clé et toutes les valeurs cryptées dans la même opération.
- il faut bien saisir un mdp au démarrage qui me servira lors de ma session pour récupérer ce couple de clé

Ce qui me perturbe dans le second point, c'est que pour une application serveur, il n'y a pas forcément d'opérateur en face pour saisir des mots de passe au démarrage et pour une webapp par exemple, il n'y a pas de mode interactif au démarrage de tomcat.
Evidemment je pourrais les passer en option de lancement (le -D en java) mais du coup si je fais la liste des processus sur la machine (un ps -aef) je retrouve mon mot de passe dans la ligne de commande ^^
Le stocker en base c'est tout autant interdit comme nous l'avons vu plus haut. Je me mords un peu la queue ^^