|
A lire :
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é 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é.
Revue et corrigé ( Version supérieur à la 0.47A ) Swan.
