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 ^^

[divxdede]

Tu es obligé d'avoir un dépot de confiance.
Si ce n'est pas la base de données, ce doit être autre chose.

Tu ne peu pas sans cesse proteger la protection qui protége une autre protection elle meme protégeant ...

Typiquement, tu dois à un moment donné, trouver un lieu (filesystem, serveur ldap) dit fiable.
J'entends par fiable que seul les entités autorisées sont amenées à y avoir accés.

[Invité]

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

Ca apporte un chiffrement hybride : procédé asymétrique lent pour crypter une courte données -> la clef
Procédé symétrique rapide pour les grosses données (potentiellement)
Ca c'est l'intérêt en terme de vitesse. Ensuite la sécurité d'un système hybride est aussi intéressante et c'est ce qui se fait dans certaines boites...

[tchize_]

en fait, si on omet les risque que ta clé privée traine là ou il faut pas, le chiffrement hybride apporte une sécurité supplémentaire. Les données chiffrée avec la clé privée son totalement imprévisibles. Ca rend des attaques cryptographiques dessus très difficiles car on a aucun présupposé quand aux données sur lesquelles se baser pour tester la validité d'une hypothétique clé privée. De plus, rien ne t'oblige à rendre la clé publique "publique"

Quand aux clés symétriques, même si elles sont cassées un jour par attaque cryptographique, ben il faudra lancer une attaque pour chaque donnée ou groupe de données, puisque chacun aura une clé symétrique suivante.

[Invité]

en fait, si on omet les risque que ta clé privée traine là ou il faut pas, le chiffrement hybride apporte une sécurité supplémentaire. Les données chiffrée avec la clé privée son totalement imprévisibles. Ca rend des attaques cryptographiques dessus très difficiles car on a aucun présupposé quand aux données sur lesquelles se baser pour tester la validité d'une hypothétique clé privée. De plus, rien ne t'oblige à rendre la clé publique "publique"

Quand aux clés symétriques, même si elles sont cassées un jour par attaque cryptographique, ben il faudra lancer une attaque pour chaque donnée ou groupe de données, puisque chacun aura une clé symétrique suivante.

Voilá. Si tu crées un objet PKCS#7 avec l'algo Rijndael 256 bits tu as pour le moment une bonne protection.
Ensuite pour la clef privée ben elle est dans un objet PKCS#12 donc protégée plutôt bien normalement, mais on est jamais à l'abris de rien c'est sûr...
Par contre le certificat avec la clef à une durée de validitée finie, il faut faire attention à ca aussi

[tchize_]

Qaudn c'est juste pour travailler en local, t'as pas besoin de certificat. Tu génère ta paire ce clés et tu la protège bien. Eventuellement, si tu veux un jour 'lupgrader, il faudra faire un get sur chaque entrée de la db, décrypter avec l'ancienne clé et recrypter avec la nouvelle.

Attention aussi aux backups Si tu perd une partie de ta clé symmétrique..... bardaf

[tchize_]

par contre, tant qu'on y est, un certificat peut srevir à signer ton code, Un ou plusieurs développeurs signent les jars de produciton avec des certificats persos, çà permettrait de s'assurer que le code source n'embarque pas un troyen :p

[Invité]

Un objet PKCS#7 permet de signer et/ou protéger des données grâce à un certificat (si je ne dis pas de bêtise, il FAUT un certificat pour générer un tel objet). Ca ne coute pas cher à faire un certificat maison et pis on peut vérifier le CA dans son appli en disant que ca vient de chez soi, ca peut être pas mal...

[tchize_]

je dit juste que t'as pas besoin d'un certificat, un certificat c'est un gros enrobage autour d'une paire de clés qui permet d'identifier leur propriétaire et d'attester de l'identité vérifié de celui-ci, via le systame de CA. T'as pas besoin de çà pour utiliser l'api crypto de java Tu peux juste te contenter de tes keyfactory, et de faire des appels aux méthodes de cryptage. Les PKCS en eux même ne sont pas des algorithme de crpytage, c'est un format dans lequel tu tappe une série de hash et de clé et des informations sur les algoithmes utilisé et leur propriétaire. Ca ne fait pas de cryptage en lui même.

[Invité]

Je n'ai jamais dit le contraire mais ce sont des pseudo standards qui permettent des échanges et d'être sûr de trouver un format conforme. Ce qui est toujours intéressant de savoir qu'avec un autre outil en cas de problème on pourra retrouver ses données codées en utilisant un des standards (et pourquoi pas un objet PKCS#7)

[hugo123]

Merci en tout cas pour vos réponses, j'avoue que je ne connaissais pas bien ce domaine et avec des docs et vos réponses j'y vois plus clair.

Pour info, comme il a été dit plus haut, a partir du moment ou je n'ai aucun lieu de stockage considéré comme sûr, je ne peux malheureusement pas mettre en oeuvre ces solutions. J'en cherchais une car je ne souhaitais pas passer par un outils du client mais je me rends compte que c'est impossible avec leurs prérequis ^^ En l'occurence ce sera cet outil mon dépositaire de confiance.

Pour la petite anecdote qui fait sourire, leur outils donne un mot de passe a partir du moment ou on lui file un userId et un serverId, données qui sont évidemment stocké en clair dans un fichier de mon coté....

"Va savoir Charles..."

[tchize_]

reste l'option du mot de passe à la main pour débloquer la clé Attends toi à etre appelé au milieu de la nuit pour un reboot du serveur