Discussion :

[trabelsi]

Bonjour / Bonsoir,

J'aimerai connaitre vos avis sur les possibilités de cryptage de données entre le client et le server.
Soit je m'explique :

Les clients sur Windows XP encodent des infos via une appli faite avec visual studio (asp.net), une fois validées ces datas doivent rejoindre mon server (Linux RedHat), dans une DB Intersystems Caché. Je voudrai que sur le chemin de transfert ces datas soient cryptées. Une fois arrivées à la DB elles peuvent être stockées cryptées (ou pas). Idem pour le chemin inverse, elles doivent sortir cryptées et être décryptées une fois arrivées au client. A savoir que je dois aussi pouvoir récupérer ces datas via un soft de reporting style crystal report.

J'ai lu pas mal de trucs sur des composants pour asp.net qui disent faire ce boulot (SecureBlackbox ou aspencrypt).
Quelqu'un a t'il un avis la dessus, les a testé, les utilise pour ses applis.

Bref tous vos avis sont les bienvenues

Yas

[Bluedeep]

Tu as tout ce qui faut en standard avec les classes du NS Cryptography :

- Cryptage symétrique (clef secrète utilisée pour cryptage/décryptage).
- Cryptage asymétrique (clef publique + clef privée).
- Hash

Comme tu ne précise pas quel type de gestion de clef tu souhaites mettre en place, il est un peu difficile de t'en dire plus.

[trabelsi]

Merci pour ta réponse.

Conernant justement le type de gestion de clé. La méthode est elle différente en fonction du type de clé choisit ?
Même avec les outils standards.

[Arnard]

Ca peut varier en effet. Si les deux parties du logiciel sont sûres, une clé Symétriquefera l'affaire (sur un lan dédié par exemple).

Par contre si ça circule sur un espace public, communiquer une clé privée de manière ouverte peut être dangereux, dans ces cas là chaque parti génère une clé asymétrique, et une fois le dialogue entamé, le serveur génère une clé symétrique qu'il communique au client via la clé asymétrique, l'intérêt étant de garder la sécurité grâce à la clé asymétrique et la vitesse de traitement de la symétrique.

[Bluedeep]

Ca peut varier en effet. Si les deux parties du logiciel sont sûres, une clé Symétriquefera l'affaire (sur un lan dédié par exemple).

Ben, au début il faut quand même qu'une des parties livre la clef à l'autre sous une forme ou une autre. C'est là où le bât blesse. (remise en main propre d'un CD éventuellement).

La difficulté étant aussi de sécuriser le stockage de la clef.

[trabelsi]

Merci pour vos réponses.

Pour détailler un peu mon cas, la sensibilité viendra du fait que mes clients distants auront accès à mon reseau via un RAS.
Mes clients sont tous membres de ma société et pourront donc obtenir la clé.
Le problème est qu'il faut que je sécurise le stockage de la clé au cas ou leurs pc portables soient volés.
Donc la réponse de Arnard (ci=dessous) me parrait plus applicable dans mon cas

"Par contre si ça circule sur un espace public, communiquer une clé privée de manière ouverte peut être dangereux, dans ces cas là chaque parti génère une clé asymétrique, et une fois le dialogue entamé, le serveur génère une clé symétrique qu'il communique au client via la clé asymétrique, l'intérêt étant de garder la sécurité grâce à la clé asymétrique et la vitesse de traitement de la symétrique. "

Et si tout cela existe en standard comme dit Bluedeep, ça devrait ne pas trop poser de problèmes.

Mes données étant très confidentielles il faut que la solution soit le plus possible sécurisée mais ne doit générer trop de lenteur lors de l'encodage et de la récupération de données.

Autre point, si cette solution est applicable aves Visual Studio, les datas sont envoyées cryptées vers la DB et sont décryptées à leurs retour dans le programme d'encodage/lecture mais qu'en ait il pour un autre programme d'accès aux datas tel que Crystal Report ?