Du fait des probl`emes figur´es dans l’utilisation d’un certificat (introduction, partie 1.1.5, nous renvoyons aussi `a [72] pour une culture plus approfondie), Adi Shamir cherchait un syst`eme pour les crypto syst`emes (sch´ema en g´en´eral) `a cl´e publique o `u les certificats sont simple et mˆeme non utilis´es. La premi`ere id´ee pos´ee `a Shamir est de chercher un syst`eme o `u l’utilisateur pourrait fixer lui-mˆeme sa cl´e publique comme une chaˆıne de caract`eres et pour- quoi pas ˆetre li´ee `a l’identit´e. Shamir pr´esente son id´ee [161] pendant la conf´erence CRYPTO qui s’est d´eroul´ee en 1984, mais sous forme de concept et il a restreint `a traduire son id´ee uniquement sur les sch´emas de signatures. Ici, nous pr´esentons sa proposition.
Description de la signature de Shamir
Cl´e Secr`ete : g (secret) sachant que : i = ge(mod n), i est l’identit´e.
S : s=g.rf (t,m), r est choisi arbitrairement par l’utilisateur tandis que f est choisi par la
PKG.
t : t=re
On envoi (s,t) et on v´erifie si :
s
e= i.t
f (t,m)mod n.
(1.6)
Apr`es l’id´ee de Shamir, la cl´e publique peut ˆetre une chaine de caract`eres li´es `a l’identit´e de l’utilisateur, c¸a peut ˆetre son adresse email, son num´ero de t´el´ephone, son num´ero de CNSS, en g´en´eral tous ce qui caract´erise l’identit´e. Cette derni`ere doit ˆetre d´efinie de mani`ere unique et que chaque individu ait son identit´e num´erique propre.
Cas d’un ID sous forme d’une adresse email
Si Alice veut envoyer un e-mail `a Bob elle cherche uniquement son identit´e, par exemple elle utilise son adresse email [email protected]. Alice peut chiffrer son message en utilisant comme cl´e publique [email protected]. Elle n’a pas besoin donc d’obtenir cette cl´e publique via un syst`eme de certificats. Quand Bob rec¸oit le message chiffr´e, il s’identifie aupr`es d’une au- torit´e de confiance appel´ee G´en´erateur de cl´es Priv´ees (PKG) et obtient sa cl´e priv´ee construite `a partir d’une cl´e maˆıtresse. Avec cette affaire, Alice peut envoyer son message chiffr´e `a Bob avant mˆeme qu’il n’a ni cl´e priv´ee, ni moyen de le d´echiffrer. Bob peut demander cela lorsqu’il rec¸oit la requˆete repr´esent´ee sous forme de message chiffr´e. Mais ce syst`eme de fonctionne- ment donne `a l’autorit´e PKG une immense validit´e de suivre ses clients puisqu’elle g´en`ere leurs cl´es priv´ees.
Restriction d’utilisation d’une identit´e et solution d’attributs
Dans l’IBE, chaque utilisateur est identifi´e par une seule identit´e. `A priori l’utilisateur ne peut pas ˆetre identifi´e d’une seule mani`ere. Donc les r´egisseurs d’IBE ont ´elus l’utilisation des attributs. De cette mani`ere l’utilisateur est caract´eris´e par un ensemble d’affirmations qui peuvent ˆetre son rˆole (fonction), son classement ou hi´erarchie (expert ou personnage moyen), son autorisation (tˆaches auxquelles il a acc`es), son ˆage plus son identit´e. Shai et Waters sont les premiers [153] qui ont d´ecrit un sch´ema avec lequel l’utilisateur peut envoyer un message en sp´ecifiant un ensemble d’attributs et un nombre d. Alors le r´ecepteur qui v´erifie au moins d attributs peut d´echiffrer le message.
L’IBE et l’Hi´erarchie
Comme dans la PKI (partie 1.1.2), nous avons besoin d’une hi´erarchie pour ´eviter la concentration sur une autorit´e. Les articles [104][90] ont pris l’initiative de relier l’IBE `a cette technique, en cr´eant ce qu’on appelle dans la litt´erature HIBE.
Dans le HIBE on suit une m´ethode successive o `u une autorit´e cerveau, nomm´ee root plac´ee `a la tˆete de la hi´erarchie et prenant le rˆole du directeur d’une soci´et´e g´en`ere la cl´e maˆıtresse `a ses subordonn´ees (sous autorit´es) class´ees selon des niveaux. Ainsi, l’autorit´e du niveau 1 procr´ee des cl´es `a son sous autorit´e c. `a.d. de niveau 2 et ainsi de suite. De ce fait, l’utilisateur n’est pas oblig´e de contacter l’autorit´e root (racine), mais suivant sa r´esidence il peut joindre l’autorit´e la plus proche de lui. De cette mani`ere, on simplifie la tˆache pour l’utilisateur et aussi pour l’autorit´e puisqu’il y a des autorit´es coop´eratives.
Afin de bien s’adapter avec le fonctionnement de HIBE, nous renvoyons le lecteur `a l’article [90] o `u le sch´ema de Boneh et Franklin a ´et´e impl´ement´e comme exemple.
1.2.1
Les probl`emes majeurs de s´ecurit´e rencontr´es dans l’IBE et les
solutions propos´ees
Stockage de la cl´e maˆıtresse (master)
La premi`ere difficult´e affront´ee par les cr´eateurs de l’IBE est de garantir un endroit s´ecuris´e pour stocker la cl´e maˆıtresse. Si un attaquant r´eussi `a attaquer ou plutˆot connaˆıtre la cl´e maˆıtresse, il pourra signer n’importe quel message comme ´etant la PKG, ou encore d´echiffrer les messages des utilisateurs en g´en`erant ses propres cl´es priv´ees. Pour d´efendre ceci, des solutions sugg`erent de distribuer la cl´e maˆıtresse entre plusieurs PKGs.
Key Eskrow
L’IBE connait un deuxi`eme inconv´enient souvent d´ecrit comme fondamental, le fait qu’une PKG peut g´en´erer les cl´es priv´ees, permet de lire les messages de ses utilisateurs et donc suivre les communications en court. La solution est beaucoup plus critique lorsqu’il s’agit des secrets sensibles. Nous allons bien traiter ce probl`eme et les solutions offertes dans le chapitre 4.
S´equestre des cl´es
Dans l’IBE, la PKG g´en`ere les cl´es priv´ees en assurant automatiquement un s´equestre de ces cl´es puisqu’elle peut g´en´erer `a tout moment une cl´e priv´ee. Ce qui peut pr´esenter l’avan- tage de r´ecup´erer les cl´es perdues et constituer des nouvelles, par contre la PKG peut contre- faire une signature et donc d´es´equilibrer le principe de non r´epudiation qui est le but fonda- mentale dans la cryptographie. Parmi les solutions propos´ees pour rem´edier `a ce probl`eme est de distribuer les cl´es priv´ees sur plusieurs PKGs poss´edant chacune sa propre cl´e maˆıtresse et r´ecup´erer ces cl´es en cas de besoin.
R´evocation des cl´es
Concernant la PKI, la r´evocation des cl´es est garantie par une publication de CRL (Certi- ficate Revocation List). Ce qui n’est pas le cas dans l’IBE, puisqu’on n’utilise ni un certificat ni un annuaire o `u on peut stocker les cl´es r´evoqu´ees. Donc, lorsqu’une cl´e priv´ee est com- promise ou qu’un utilisateur a chang´e sa place, il faut le confirmer. Boneh et Franklin [22] proposent d’utiliser l’identit´e concat´en´ee avec une chaˆıne de caract`eres d’horodatage. Par
exemple, au lieu d’utiliser l’adresse email de Bob : [email protected], il vaut mieux le remplacer par [email protected]||05||2014. Malheureusement cette m´ethode demande de renouveler les cl´es priv´ees `a chaque fois, une m´ethode plus ad´equate a ´et´e sugg´er´ee par Alexandra Boldyreva et al [18].
Transmission de la cl´e priv´ee
Pour ce qui est de la PKI, la cl´e priv´ee est g´en´er´ee par l’utilisateur lui mˆeme apr`es sa pu- blication par l’autorit´e comp´etente. Ce qui lui permettra de se d´efendre suite `a une ´eventuelle attaque du Man in the Middle. Dans le cadre de l’IBE, c’est la PKG qui g´en`ere la cl´e priv´ee et pour la transmettre aux utilisateurs, c¸a demande un canal s ˆur ou de se pr´esenter physi- quement pour l’obtenir. Pour d´ecroitre ce besoin une solution a ´et´e propos´ee par Kumar en 2006 [124], nous rappelons ici sa m´ethode dans le cas de la cl´e priv´e utilis´ee par le sch´ema de Boneh et Franklin :
Tout d’abord, l’utilisateur qui a l’identit´e ID, pour s’authentifier aupr`es de l’autorit´e PKG, doit choisir un rID (dans un corps fini convenable) et il l’envoie `a cette derni`ere sous la forme :
<ID,(rID−1 mod q)P >. La PKG stocke quelques part le (r −1
ID mod q)P comme param`etre r´eserv´e
`a ID et il issu apr`es sQID||(r−1IDmod q)P comme preuve d’enregistrement `a l’utilisateur.
Pour renvoyer la cl´e priv´ee, la PKG choisit x dans le corps g´en´er´e, il calcule ensuite U=sQID+xP,
V=x(rID−1mod q)P. Une fois rec¸u <U,V>, l’utilisateur concern´e c. `a.d. celui qui a g´en´er´e rIDpeut
extraire facilement la cl´e cherch´ee en calculant U − rIDV = sQID.
La mˆeme m´ethode peut ˆetre appliqu´ee dans le cas des autres sch´emas.
1.2.2
Points en communs et diff´erences entre l’IBE et la PKI
Le tableau 1.1 pr´esente les points permettant de comparer entre l’IBE et la PKI, selon non seulement notre point de vue ; mais aussi d’apr`es les regards de certains chercheurs, en se basant sur [93][149][73].
√
: Veut dire que cela existe
√
2 : Veut dire moyenne existence
× : Veut dire n’existe pas.
On exprime par genre (inconv´enient/ avantage) important lorsqu’il pr´esente une difficult´e (sa solution est ardue) ou une flexibilit´e d’utilisation. Par contre, l’utilisation et la solution d’un peu important est `a peu pr`es simple (c¸a d´epend du probl`eme qu’il pr´esente).
Points cit´es/ genre inconv´enient avantage important peu important Points cit´es/ technologie PKI IBE PKI IBE
Demande de certificat √ × oui
Besoin la confiance de l’autorit´e
√ 2
√
oui
Key escrow × √ oui
Authentifier le r´ecepteur et √ × oui
l’´emetteur
Chercher une forme sp´eciale √ × oui
des cl´es v´erifiant certaines crit`eres
Taille plus grande de la cl´e √ × oui
publique
Demande CRL ou OCSP √ × oui
Authentification de haut niveau √ × oui
Le r´ecepteur laisse sa cl´e √ × oui
publique chez l’autorit´e avant d’ˆetre contacter
Besoin d’un stockage s´ecuris´e × √ oui
d’une cl´e fondatrice du syst`eme (cl´e master)
Permet un off line de chiffrement × √ oui
Permet aux utilisateurs de √ × oui
g´en´erer leurs cl´es personnelles
Produire la cl´e publique × √ oui
`a partir de l’identit´e
TABLE1.1 – Comparaison entre l’IBE et la PKI suivant divers points