Discussion :

[Akryos-K]

Bonjour,

Je suis en train de concevoir une application en Java nécessitant de se connecter à un service distant. Cette application est démarré automatique à l'ouverture d'une session sur un Os. Ce service a pour vocation d'être confidentiel.

Je souhaite donc mettre en place une auto-connexion sachant que la connexion se fait par Webservice sur https à ce jour.

Que pouvez-vous me conseiller? Certificats SSL, sauvegarde de mot de passe crypté? Comment rendre ces fichiers confidentiels? Bref, je ne sais pas par où commencer. Je reste ouvert à toute proposition si vous avez été confronté à cette problématique.

Amicalement,
Damien.

[Logan Mauzaize]

Le principe générale :

• Un algorithme de cryptage à deux clés (souvent symétrique pas obligatoire)
• Une paire de clé pour le client
• Optionnellement une paire de clé pour le serveur
• Pour assurer son identité, le client envoie un message (non sensible) crypté avec sa clé privée auprès du serveur.
• Le serveur le décrypte avec la clé publique du client et vérifie que c'est bien le message qu'il attendait.

En général :

• On génère des certificats pour le serveur et on signe les certificats des clients avec ceux-ci.
• Le client utilise sa clé privée pour "signer" ces messages. Et le serveur utilise la clé publique pour vérifier la signature.
• Le serveur utilise la clé publique pour "crypter" des messages. Et le client utilise sa clé privée pour les décoder.
• Il existe un algorithme pour échanger publiquement des clés.
• La première étape du protocole consiste à échanger publiquement des clés, ensuite à échanger des messages cryptés avec la paire de clés PUIS les clés échangées.
• Selon la sensibilité de la communication, une fois l'authentification étable, le serveur peut générer des clés temporaires qui serviront uniquement à cette session/transaction.

[tchize_]

Il faudrait un peux préciser ce que tu entends par confidentiel, ou plutot qu'est-ce qui doit être confidentiel:

-> Les données sur le réseau ne doivent pas être lues par les tiers intermédiaires?
-> Le propriétaire (admin) de l'OS ne dois pas connaitre le mot de passe / ne doit pas être capable de le reproduire sur une autre machine?
-> autre?

[Akryos-K]

Tout d'abord, merci pour vos réponses.

Il faudrait un peux préciser ce que tu entends par confidentiel, ou plutot qu'est-ce qui doit être confidentiel:

-> Les données sur le réseau ne doivent pas être lues par les tiers intermédiaires?
-> Le propriétaire (admin) de l'OS ne dois pas connaitre le mot de passe / ne doit pas être capable de le reproduire sur une autre machine?
-> autre?

L'objectif est de faire un client pour un espace de sauvegarde confidentiel. Pour ce qui est de la sauvegarde, j'utilise du ftps avec le cryptage des logins, mot de passe & data.

Le soft permettant de définir le contenu de la sauvegarde doit se connecter afin de récupérer les identifiants de connexion ftps & pouvoir faire la sauvegard

Ce soft est destiné à la fois aux grands public, au TPE & PME. Dans le cadre des clients grand public, le soft est multi-user. Les TPE sont considérés comme grand public. Pour les PME, je pars de l'hypothèse que l'administrateur des postes sont ceux ayant mis en place la solution. Il n'y a donc pas d'obligation que l'administrateur d'un poste n'est pas accès aux fichiers d'identification.

Y-a-t-il une API ou mode opératoire standard pour la connexion automatique?

L'objectif est surtout de se prémunir d'une usurpation d'identité par un pirate qui arriverait à dérober les clés sur le poste.

Ai-je répondu à vos interrogations pour préciser mon besoin?

[tchize_]

tu pourra limiter mais pas empecher le vol. Ton application a besoin de ces clés, donc, à un moment donné, elles seront dans la mémoire du système. Ce que je ferais:

1) installation de l'application sur le poste client par l'admin ou l'utilisateur
2) configuration, l'application génère une paire de clés et envoie sa clé publique au serveur
3) l'admin, coté serveur, accepte la clé et la reconnais pour le poste donné (moyennant les vérification d'usage, si il accepte automatiquement, ca sert à rien)

avec les domaines windows et active directory on pourrait envisager d'autres moyen de propager la clé.


Opération de connexion:
1) l'applicaiton utilise sa clé privée pour signer un message à destination du serveur, le tout au dessus d'une connexion https par exemple, en y incluant un challenge du serveur
2) le serveur reconnais la source (via son ip) et, associé à la signature du message, permet de "faire confiance", il répond en envoyant un user/passe temporaire pour le serveur sftp, valable seulement maintenant et uniquement à partir de la même IP.


conséquence:
vol de la clé privée -> elle est associée à l'ip, impossible à utliser sur une autre machine sans aussi dérober l'IP
vol du mot de passe (à partir de la machine, par exemple) -> il est temporaire et utilisable uniquement depuis ladite machine, impossible de l'utiliser d'ailleurs.


Ce n'est qu'une proposition parmi plein de scénarios envisageables.

[Akryos-K]

J'avais pensé à l'ip. Mais, tout le monde n'a pas d'ip fixe (chez Numéricable, par exemple). Il y a également les personnes mobiles et c'est peut-être eux les plus intéressés car les déplacements augmentent le risque de vol et donc l'intérêt pour la sauvegarde. J'ai divergé pour préciser le contexte.

Maintenant, avoir quelqu'un qui valide l'utilisateur manuellement, n'est pour moi pas une solution très intéressante. Je peux néanmoins fournir une solution clé publique/privée en traçant les adresses Ip et le retranscrire au client pour qu'il puisse vérifier par lui même si les adresses sont cohérentes (retranscription en fonction du whois ip).

Autre point, je peux vérifier si deux utilisateurs sont connectés simultanément avec le même compte à deux adresses Ip différentes et dans ce cas remonter des alertes en préconisant de changer le mot de passe ou de se relogger pour un nouvel échange de clé. En fonction de la criticité des informations sauvegardées ou du type de client, je peux également réalisé une déconnexion si je rentre dans ce cas.

Que pensez-vous de ce retour? Sachant que j'aurais certainement des soucis avec les gens exploitant la 3G pour travailler en voiture, train, etc... Mais, bon, ce sont des cas au limite.

Pour la création & l'échange de clés, avez-vous des conseils à me fournir sur des API sur le client et/ou sur le serveur?

(Le serveur est basique et je tourne uniquement avec de l'apache/php5 sur ubuntu server.)

Merci encore pour vos retours.

[tchize_]

Vous voulez éviter quoi en fait, qu'est-ce que vous voulez comme gain par rapport à un user/pass, parce que je ne suis pas sur de comprendre.

[Akryos-K]

Je peux placer les logins et mot de passe (salt & crypt).

Mais, j'aimerais surtout savoir si vous connaissez des méthodologies ou API déjà existante pour faire cette sauvegarde d'identification afin qu'au lancement de ce soft, ce dernier vienne s'identifier sur mon serveur.

En Java, si quelque chose est déjà fait, pourquoi le ré-implémenter?

Et désolé, de ne pas être clair dans ma demande. Je dois vouloir trop en dire, et j'en perds l'objectif.

[tchize_]

Pour la cryptographie, il y a la java crypto api qui permet de chiffrer, hasher, etc.

Pour l'authentification, les seuls "standard" que je connaisse sont l'authentification BASIC sur une connexion https, qu'on peux aisément réaliser avec commons httpclient par exemple. Pour els protocole particuliers (ftp, sftp, etc) il existe déjà des implémentation complètes avec authentification par exemple dans commons-net de apache.

[Akryos-K]

Je te remercie pour ces informations. Je vais regarder ça. Pour le ftps, il existe en effet quelque chose de standard que j'ai déjà mis en place.

Merci encore. Je ferais un retour d'expérience en expliquant mes choix si ça peut aider d'autres utilisateurs du forum.