We are developing an
experimental version of ClassicSys for Email and
installing a TA simulation.
ClassicSys for Email is not an Email application but only
the encryption part of it.
ClassicSys for Email will give you the following possibilities :
ClassicSys can be downloaded here. The identification code is 0E5, and the trust
authority address is classicsys.ulb.ac.be
Diffie-Hellman reduced key is
97493583B561E8D87FA9262CCD42A9F8 for the version 4.00 (December 23,
2007)
Addenda
Version draft réduite (juillet 2006)
Faisabilité du dépôt des clefs
(Key escrow)
Introduction et état de l'art
actuel
La
cryptographie peut se révéler comme étant la meilleure ou la pire des nouvelles
technologies, tout dépend de l'esprit de l'utilisateur. L'honnête citoyen peut
dissimuler sa messagerie électronique lors de son acheminement sur internet, aux personnes non autorisées, et encore signer un
document mieux que par une signature manuscrite. Par contre, une personne mal
intentionnée pourrait occasionner des préjudices graves à autrui. Si les
terroristes du 11 septembre sont parvenus à exécuter à l'improviste leurs
sinistres attentats à l'insu des services de sécurité, c'est certainement parce
qu'ils ont pu se concerter entre eux en faisant usage de la cryptographie. Les
terroristes, le recyclage de l'argent sale de la corruption, la drogue et bien
d'autres choses encore engendrent la
criminalité.
La méthode
conventionnelle (PGP) pour correspondre en mode chiffré consiste à générer une
paire conjuguée de clefs, l'une publique et l'autre privée. Le destinataire fait
parvenir sa clef publique à l'expéditeur. Si ce dernier a l'assurance qu'il
détient réellement cette clef publique, il peut faire parvenir au destinataire
un message chiffré à l'aide d'un algorithme symétrique en utilisant une clef
aléatoire, cette dernière étant adjointe au message mais chiffrée à l'aide d'un
algorithme asymétrique à clef publique. Il est nécessaire de recourir à des
algorithmes symétriques et asymétriques, ces derniers ayant des vitesses de
chiffrement mille fois inférieures. Cette méthode est très sûre pour le partage
d'une clef de session entre correspondants mais les services de sécurité sont
incapables de déchiffrer les messages s'ils ne disposent pas des clefs
secrètes.
La surveillance des messages
suspects nécessite leur interception et déchiffrage tout en respectant la
confidentialité du reste des courriers. Pour éviter toute dérive, des procédures
très strictes devront être mises en oeuvre, par exemple l'obligation de la
délivrance d'un mandat judiciaire par un juge d'instruction pour permettre
l'ouverture d'un message chiffré suspect ou encore la tenue d'archives non
destructibles, mises à disposition d'un responsable, à un échelon hiérarchique
supérieur, pour vérification éventuelle.
Dans son
anthologie “Applied Cryptography”, Bruce Schneier cite
en 1996 le texte prémonitoire “Imagine a major terrorist attack in New York;
what sorts of lirnits on
the police would be thrown aside in the aftermath ” (Key escrow
$4.14) L’auteur a
certainement pris conscience de l’importance de la cryptographie dans le combat
contre le terrorisme, mais n’a pu imaginer le drame qui allait se produire à
New-York. Dans le même chapitre, il expose la
procédure du dépôt de clef comme une méthode possible pour faire échec à une
utilisation fallacieuse de la cryptographie mais en arrive finalement à la
conclusion que sa mise en oeuvre n’est pratiquement pas
possible.
Par une
vue de l'esprit, on peut imaginer la réalisation d'un organisme détenant toutes
les clefs privées conjuguées aux clefs publiques appartenant aux internautes,
mais cette façon de voir les choses est loin d'être réaliste. Peut-on imposer à
999.999 honnêtes internautes l'obligation de communiquer leurs clefs privées
(sans savoir si elles seront utilisées ou non, ni à quelles fins) pour atteindre
un internaute mal intentionné, lequel craignant de voir sa messagerie
déchiffrée, utilisera une autre clef. En effet, il n'est pas possible de
vérifier en permanence que toutes les clefs mises en dépôt sont bien celles
utilisées en réalité. Pour les internautes honnêtes, la démarche du dépôt de
leurs clefs secrètes créera un sentiment de frustration, si non même de
violation, car ils se sentiront suspectés d’être
malintentionnés.
Une autre
façon d'aborder le problème
La
difficulté à réaliser l'objectif du dépôt des clefs provient du fait que c'est
l'internaute lui-même qui crée la paire de clefs, secrète et publique, et qui
assume sa gestion et son gardiennage. De plus, il est contraint de diffuser sa
clef publique et de donner la preuve de l'identité du détenteur de la
clef.
Une autre
méthode consiste à charger un organisme de confiance (TAS: Trust Authority Server) de distribuer les clefs secrètes privées
en donnant l'assurance que la protection de la vie privée des internautes est
assurée et qu'aucune dérive ne peut se produire. Le système ClassicSys veut répondre à cet objectif. Au cours de la
procédure d'affiliation, l'internaute reçoit un numéro d'affiliation, en
réalité, son numéro d'arrivée lors de la procédure d'affiliation, et une clef
privée qui est le résultat du chiffrement par le TAS de ce numéro d'affiliation.
Pour pouvoir correspondre avec un autre affilié, il demandera au TAS une clef de
session, laquelle est obtenue par le chiffrement par le TAS du bloc contenant
les numéros d'affiliations de l'expéditeur et du destinataire. Le message
chiffré d'un expéditeur vers un destinataire comprend plusieurs blocs d'en-tête.
Le déchiffrement de ces blocs, à l'aide de la clef privée du destinataire, donne
la clef de session pour le déchiffrement du message, des blocs de contrôle, et
l'identité de l'expéditeur.
La banque
de données du serveur TAS ne comprend que les données relatives à l'identité des
affiliés et leurs numéros d'affiliation. Pour toute demande d'une clef de
session, le TAS recalcule les clefs privées des deux correspondants en fonction
de leurs numéros d'affiliation, et, à partir de ce résultat, il calcule la clef
de session.
Tous les
algorithmes symétriques à clefs privées seraient susceptibles de remplir cette
fonction mais ne peuvent convenir pour des raisons de sécurité qui sont exposées
plus loin.
Pour
atteindre notre objectif, nous proposons l'utilisation de l'algorithme SED
(inventeur E. Musyck), un algorithme de chiffrement
qui utilise des clefs différentes de chiffrement et de déchiffrement. Cet
algorithme est à classer comme algorithme à clef privée, car si l'on connaît une
clef, on peut en déduire l'autre clef. (www.ulb.ac.be/di/scsi/classicsys)
Les
algorithmes RSA et SED présentent certaines analogies mais aussi des différences
essentielles. Ces deux algorithmes opèrent dans des groupes
multiplicatifs.
Pour le RSA, le facteur multiplicatif est
un nombre entier et la multiplication de type arithmétique modulaire, dans
l'espace commun des données et des clefs qui correspond au produit de deux
nombres premiers très grands.
Pour le
SED, le facteur multiplicatif est une matrice carrée 127*127 qui opère modulo-2
dans l'espace commun des clefs et des données, lequel correspond au nombre
premier 2^127-1. La matrice susmentionnée définit la base logarithmique discrète
d'un corps fini. A tout nombre appartenant à cet espace, correspond un
logarithme discret dans une certaine base. Bien que ce logarithme discret ne
doive pas être connu, l'algorithme SED calcule le nombre qui a comme logarithme
discret celui égal au nombre d'entrée multiplié mod
(2^127-1) par la clef de chiffrement. Cette opération est appelée DLM1 (Discrete Logarithm Multiplier). Ce
premier résultat est ensuite multiplié arithmétiquement par la même clef (mod 2^127-1). Cette application est appelée MAM (Modular Arithmetic Multiplier). Ce
dernier résultat fait l'objet d'une seconde multiplication DLM2 mais avec une
autre base logarithmique discrète. Le déchiffrement s'effectue par les
applications DLM2, MAM, DLM1 en utilisant la clef conjuguée définie par la
relation K1*K2 = 1 (mod 2^127-1). L'application MAM a
été introduite en 1999 suite à l'étude Mieczislaw Kula
( A cryptosystem
based on double discret logarithm) et sa robustesse en toute logique se situe au
niveau de la force brute.
Performance
et robustesse du système cryptographique ClassicSys
On peut
considérer que celui qui veut attaquer le système ClassicSys sera confronté à l'existence de deux niveaux de
difficultés à vaincre. Cet opposant sera externe s'il n'a accès qu'aux documents
chiffrés circulant sur internet, mais il pourrait
aussi être interne, c-à-d potentiellement l'un des
deux correspondants. Nous abordons ici le domaine de la correspondance
recommandée. L’expéditeur doit pouvoir créer une signature générée par lui
exclusivement, cette signature doit être authentifiable par qui que se soit et
non révocable.
Le niveau
"1" se situe à la difficulté à décompiler du logiciel
ClassicSys afin de reconstituer le code source du
logiciel. Cette décompilation est indispensable pour pouvoir recréer,
frauduleusement, les clefs conjuguées aux clefs normalement utilisées. Le
système ClassicSys est conçu de telle manière que, à
l'envoi ou à la réception de messages chiffrés entre deux correspondants, chacun
utilise la clef conjuguée de l'autre et de ce fait, ne peut créer un message qui
serait attribué à l'autre. Le niveau "1" est à la portée d'un nombre très
restreint d'internautes et son attaque demande un immense effort, mais il ne
peut pas être considéré comme suffisant dans le domaine de la correspondance
recommandée. Le niveau "1" est parfait si l'on veut se protéger contre un
opposant externe. Dans ce cas, il est indispensable que la clef privée ait fait
l'objet d'un chiffrement à l'aide d’un algorithme à clef publique par le TAS
lors de la procédure d’affiliation. Nous préconisons pour cet objectif
l’algorithme Diffie-Helmann. Il n’y a pas lieu de
craindre l’attaque de l’intrus du milieu si une vérification de la clef publique
du TAS est faite par l’affilié.
Sans l'usage de l'algorithme à clef publique Diffie-Helmann, un opposant externe, qui aurait pu prendre
connaissance des informations échangées lors d'une l'affiliation et disposerait
également du programme source de ClassicSys, serait en
mesure de reconstituer la clef privée d'un affilié.
Le niveau
"2" correspond à la difficulté d'attaque des chiffrements par la clef privée
d'un affilié. Ce niveau est pratiquement inviolable à tout opposant, interne ou
externe, qui n'a pas matériellement accès à l'ordinateur de l'internaute qu'il
veut tromper. Tout message peut faire l'objet d'une opération de hachage et
créer ainsi un bloc d'abrégé de texte. Le chiffrement de l'abrégé à l'aide de la
clef privée donne une signature propre au détenteur de la clef privée en
question. Cette signature ne peut être authentifiée que par le TAS qui seul peut
reconstituer la clef privée de tous les affiliés. Le recours à l'utilisation de
la protection de niveau "2" nécessite un volume double de calcul pour les
chiffrements, ce qui constitue une petite contrainte. Il sera néanmoins
nécessaire de recourir à ce niveau pour la création de messages recommandés. En
effet, pour tout litige relatif à un message recommandé porté devant une
instance judiciaire, le juge ne peut accepter d'instruire la plainte que si les
signatures électroniques, présentées comme pièces à conviction, appartiennent au
niveau "2".
Pour
mémoire, il y a lieu de citer le niveau "0" qui ne concerne pas ClassicSys et correspond au cas d'un hypothétique système
cryptographique présentant la même structure que ClassicSys mais qui utiliserait un algorithme de chiffrement
symétrique. La violation du niveau "0" est pratiquement à la portée de tout le
monde pour la création d'un faux message car il y a utilisation de la même clef,
que se soit en chiffrement ou en déchiffrement. C'est pour cette raison que
l'utilisation d'un algorithme symétrique pour le système ClassicSys n'est pas acceptable. L'algorithme SED est unique
dans son genre et tout permet de croire qu'il le restera.
Etat
d'avancement du système ClassicSys (juillet
2006)
Le
système ClassicSys (version ultérieure bêta) est conçu
afin d'assurer toutes les fonctions desservies par les systèmes PGP ou
équivalents. En ce moment, la version expérimentale, entièrement gratuite et
bilingue Français-Anglais, permet l'affiliation et
l'échange de messages chiffrés ainsi que les mises à jour. Le serveur TAS, situé
à l'Université Libre de Bruxelles, travaille d'une manière autonome 24/24h dans
une zone protégée physiquement et d’accès strictement limité. La gestion
administrative du serveur s'effectue à distance et permet l'enregistrement et la
radiation des affiliés. L’enregistrement consiste en la vérification de
l’identité annoncée par l’affilié et celle pouvant se déduire par un document
officiel ou même par un versement financier. Le gestionnaire n'a pas accès à la
clef secrète du serveur et il lui est impossible de reconstituer les clefs
privées ou de session des affiliés. Il est aussi possible de mettre en service
plusieurs serveurs TAS. Dans ce dernier cas, la demande d'une clef de session
pour un affilié relevant d'un autre serveur est possible, mais nécessite un
dialogue entre serveurs TAS.
La version
actuelle permet l'envoi et la réception de messages chiffrés ainsi que
l'authentification des signatures par le TAS.
En ce
moment, il n'existe pas de logiciel permettant le déchiffrement des messages
suspects, mais des tests très positifs ont déjà été réalisés dans cette optique.
Ces logiciels seraient immédiatement mis en chantier et réalisés si un intérêt
se manifestait chez les autorités compétentes. Si un tel logiciel était réalisé,
chaque ouverture d’un message suspect nécessiterait une demande particulière au
serveur TAS valable pour ce seul message. Cette dernière demande serait chiffrée
et enregistrée dans la mémoire du serveur TAS. Les demandes d’ouverture ne sont
pas déchiffrables par le gestionnaire du TAS, mais seulement par le responsable
hiérarchique du demandeur de l’ouverture.
Autre
son de cloche
Les
opinions divergent quant à la nécessité et à l’efficacité d’effectuer le dépôt
de clefs. Les opposants au dépôt déclarent :
-1) que les diverses
solutions avancées vont à l’encontre des libertés individuelles.
Réponse : La vie privée est
sacrée et nul ne le conteste mais la société a aussi l’obligation de protéger
l’individu contre la criminalité. Le recouvrement d’un message suspect avec le
système ClassicSys n’est possible que par le détenteur
de l’affiliation dédiée aux Services de Sécurité Nationale et ce recouvrement
est obtenu dans un laps de temps très court, de l’ordre de la
seconde ;
- 2) que les clefs secrètes entre les mains d’un tiers,
même confiant, risquent fort de tomber entre les mains de personnes mal
intentionnées.
Réponse : Comme, dans le système ClassicSys, les messages de l’expéditeur au destinataire,
sont chiffrés chaque fois avec une nouvelle clef aléatoire, la demande d’un
recouvrement n’est valable que pour un seul message
- 3) que
l’utilisation d’un système cryptographique permettant le recouvrement des
messages constitue une charge financière pour les utilisateurs des messageries
chiffrées.
Réponse : L’utilisation du système ClassicSys est, et restera, entièrement gratuite. De plus,
si le fournisseur d’accès à Internet est en même temps le gestionnaire du TAS,
les frais relatifs à l’hébergement de la clef auprès d’un certificateur
d’identité peuvent être évités.
Test de
fonctionnement
La version
expérimentale de ClassicSys peut être téléchargée sur
le site www.ulb.ac.be/di/scsi/classicsys/experim.htm.
Vous pouvez prendre deux ou trois affiliations en tant que personne privée,
employée ou indépendante et correspondre de l’une à l’autre à titre de test.
Pour chaque affiliation, le logiciel titulaire sera placé dans un dossier
entièrement vierge.
Conclusion
Bien que le
logiciel ClassicSys soit toujours dans sa phase
expérimentale, il apparaît déjà que le système, très convivial, pourra répondre
à toutes les exigences en matière de sécurité.
Doit-on
craindre de voir nos messages chiffrés être déchiffrés par les Services de
Sécurité Nationale? NON, si
les correspondants sont d’honnêtes internautes et certainement pas dans nos pays
jouissant d’une parfaite démocratie. Je pose la question : y a-t-il
contrainte ou humiliation, de devoir passer sous un portique de détection de
métaux avant de s’embarquer en avion ? Certains pourraient voir dans cette
obligation une espèce de « Fourches Caudines », pourtant, aujourd’hui,
nul ne conteste l’utilité de ces portiques, et des portiques bien plus
sensibles, auraient peut-être pu éviter le drame du 11 septembre 2001. Perdre un
peu de sa liberté, toute subjective, pour gagner un meilleur mode de vie avec
moins de criminalité ou de terrorisme, pourquoi pas ?
Emile
Musyck (www.ulb.ac.be/di/scsi/emusyck)