Les clients sont identifiés sur le réseau par une valeur unique appelée hachage utilisateur (user hash). Cette valeur est sauvegardée dans le fichier preferences.dat et est utilisée pour accorder les crédits gagnés auprès des autres clients.
eMule comporte une fonction de cryptage asymétrique afin d'éviter l'exploitation ou la manipulation des valeurs de hachages utilisateurs des autres clients. La méthode emploie une clé privée et une clé publique de manière à sécuriser le hachage utilisateur, tout en autorisant une identification correcte par les clients distants.
L'identification sécurisée des utilisateurs peut être activée dans les Préférences -> Sécurité. Il est recommandé d'en faire usage.
Fonctionnement de l'identification sécurisée :
Le client A veut s'assurer que ses crédits sont sécurisés et que lui seul peut les utiliser.
Il crée une clé RSA privée de 384 bits et la sauvegarde dans le fichier cryptkey.dat.
Cette clé privée est générée lors de la première utilisation du cryptage. La perte de cette clé signifie que le client A perd tous ses crédits car il n'est plus en mesure de prouver qu'il en est le propriétaire valide.
Lorsque deux clients, comprenant la fonction de cryptage, échangent des données pour la première fois, il s'envoient l'un à l'autre une clé publique, associée à une valeur aléatoire. Chacun sauvegarde la clé de l'autre dans son fichier clients.met. Seule la clé est sauvegardée, la valeur aléatoire est générée à nouveau lors de chaque connexion suivante.
Si le client A désire s'identifier auprès du client B lors d'une prochaine rencontre, il crée une signature numérique et l'envoie à B. Cette signature est composée de sa clé privée, de la clée publique de B et d'une valeur aléatoire. Elle demeure valide tant que le client A conserve la même IP ou que le client B ne ferme pas eMule.
Lors de la réception de la signature de A, le client B vérifie si elle est créée à partir de sa clé publique et de la valeur aléatoire correcte. Si elle est aussi en accord avec la clé publique du client A, alors le client A est correctement identifié.
Notes:
Si le fichier cryptkey.dat est perdu ou supprimé, le fichier preferences.dat doit aussi être supprimé. Sinon aucun nouveau crédit ne pourra être collecté à partir des clients déjà connus.
Lors du passage à l'identification sécurisée des utilisateurs, tous les anciens crédits "non-sécurisés" sont perdus. Pour des raisons de sécurité, il n'y a aucun moyen de transférer ces crédits vers le système sécurisé.
S'applique à la version: .29b +
Dernière mise à jour le : 20/06/03 par Monk
