Schéma fondé sur l'identité
Le schéma fondé sur l'identité (ou identity-based) est une notion de cryptologie introduite par Adi Shamir en 1984[1].
La cryptographie par identité permet de résoudre le problème de certification des clefs publiques. En effet si la cryptographie asymétrique a résolu le problème d’échange de clefs[2], la question de savoir si une clef publique, trouvée sur une page personnelle par exemple, correspond bien à une clef privée que possède l’interlocuteur présumé reste une question importante. GnuPG propose par exemple l’idée de la toile de confiance construite sur le principe de la transitivité de la confiance, et si beaucoup de membres de confiance ont certifié une clef, alors il y a de bonnes chances pour que la clef soit aussi de confiance.
Ainsi, dans le cadre du chiffrement par identité, un utilisateur peut publiquement dériver une clef de chiffrement pour une identité donnée par exemple par une adresse de courrier électronique. L’utilisateur possédant l’adresse e-mail obtient de la part d’une autorité la clef secrète permettant de déchiffrer pour son identité.
Principe
modifierL'idée est de prendre comme clef publique l'identité de l'utilisateur, par exemple ses nom, prénom, date de naissance, ou numéro de sécurité sociale. Si l'on arrive à créer des clefs de chiffrement secrètes relatives à ces identités de telle sorte que deux individus différents ne puissent avoir la même clef secrète, alors il n'est plus utile de certifier les clefs publiques.
Schémas généraux
modifierLes schémas basés sur l'identité permettent à n'importe quelle personne de régénérer la clef publique d'un individu à partir d'une valeur d'identité telle qu'une chaîne ASCII[3].
Un tiers de confiance, le générateur de clefs privées, est chargé de la fabrication des clefs secrètes qui correspondent à ces clefs publiques. Pour cela, le générateur de clefs privées publie une clef publique « maître » et conserve pour lui la clef privée maître qui correspond.
On combine la clef publique « maître » à la valeur d'identité afin de régénérer la clef publique qui correspond à cette identité. Afin d'obtenir la clef privée associée, la personne à qui correspond cette identité doit contacter le générateur de clefs privées, qui utilise sa clef privée « maître » pour générer la clef privée de l'utilisateur qui correspond à son identité.
En conséquence, il est possible de chiffrer des messages (ou de vérifier des signatures) sans opération préalable d'échange de clef entre les individus. Ceci est extrêmement utile au cas où la pré-distribution des clefs est difficile, ou impossible à cause de contraintes techniques.
Inconvénients
modifierLa contrainte de cette approche est que le niveau de confiance qui doit être accordé au générateur de clefs privées est très élevé, car il est intrinsèquement capable de régénérer la clef privée de tout utilisateur, et donc de pouvoir réaliser sans autorisation des signatures ou des déchiffrements. En fait une fonctionnalité de recouvrement de clef est présente de manière inhérente au système.
Un certain nombre de variantes ont été proposées afin d'éviter ce problème tel que le chiffrement basé sur certificat, la génération de clé sécurisée, et la cryptographie sans certificat. Quelques schémas ont été proposés entre 1984 et 2000, mais aucun n'a réuni deux qualités majeures : sécurité et applicabilité.
Il faut attendre 2001, et les publications de quasi simultanées Cocks et de Franklin et Boneh pour voir des cryptosystèmes vraiment prometteurs.
Cette page décrit dans le détail uniquement le schéma de Cocks, qui a l'avantage de l'originalité sur son rival. Il est néanmoins important de remarquer que le système de Boneh et Franklin est pleinement opérationnel, et dispose d'une implémentation pour le chiffrement de courriel.
Classification de Shamir des protocoles de reconnaissance
modifierEn , Fiat et Shamir ont classifié les différentes catégories de protocoles de reconnaissance. Ils distinguèrent alors trois niveaux de protections. Supposons qu'Alice veuille prouver son identité à Bob, les différents niveaux sont alors :
- protocole d'authentification: Alice peut prouver à Bob qu'elle est véritablement Alice, mais personne d'autre ne peut prouver à Bob qu'elle est Alice.
- protocole d'identification : Alice peut prouver à Bob qu'elle est véritablement Alice, et Bob ne peut extraire aucune information de cette preuve pour tenter de faire croire à quelqu'un d'autre qu'il est Alice.
- protocole de signature (ou non-répudiation): ce protocole a les mêmes propriétés que le précédent mais, en plus, Alice ne peut pas dire qu'elle n'a pas prouvé son identité à Bob, ou que le message qu'elle a signé était différent de celui que Bob prétend avoir reçu (elle ne peut pas répudier sa signature). En d'autres termes, Bob ne peut pas faire croire qu'Alice lui a prouvé son identité alors qu'elle ne l'a pas fait.
En fait, le protocole d'authentification au sens de Fiat et Shamir ne sera utilisé que lorsqu’Alice et Bob ont leurs intérêts en commun, pour prévenir une attaque venue de l'extérieur. Par contre, lorsqu’Alice et Bob ont des intérêts divergents, l'un des deux autres types de schéma doit être employé. Avec un protocole d'authentification, Bob pourrait a posteriori se faire passer pour Alice auprès d'un troisième intervenant. Ceci n'est plus possible lorsque l'on a affaire à un schéma d'identification. En revanche, dans ce cas, comme dans le cas de l'authentification, Bob peut faire croire qu'il a reçu un message venant d'Alice (en quelque sorte en imitant sa signature), tandis qu'un protocole de signature l'en interdit.
Nous n'utiliserons cependant pas le vocabulaire de Shamir, en ne faisant pas de distinction entre authentification et identification. En effet l'authentification au sens de Shamir présuppose qu'Alice et Bob ne sont pas rivaux, ce qui arrive assez souvent dans la pratique, mais aussi, que personne ne peut écouter une preuve d'authentification entre Alice et Bob, car sinon l'indélicat personnage serait dans les mêmes conditions que Bob pour restituer la clef secrète d'Alice, et pourrait donc se faire passer pour Alice lors des conversations ultérieures. Or, la confidentialité physique est généralement loin d'être parfaitement assurée.
Protocole de Shamir
modifierCe schéma est sous-jacent au protocole de signature publié par Shamir en 1984. Comme pour le schéma précédent, l'autorité crée une paire de clefs RSA (les mêmes notations seront utilisées et à partir de maintenant, tous les calculs doivent être effectués modulo , dans ce protocole et dans les suivants). L'autorité confie à Alice , où est l'identité d'Alice. Pour prouver qui elle est, Alice devra montrer qu'elle connaît , sans dévoiler .
Pour cela, lorsqu'elle envoie un message à Bob, elle choisit un aléa et lui envoie . Bob prend au hasard un nombre appartenant à l'intervalle , et le communique à Alice qui lui retourne alors . Il ne reste plus à Bob qu'à vérifier que l'on a bien .
Cependant, on ne possède pas de preuve de la sécurité de ce schéma.
Protocole de Cocks
modifierSoit l'ensemble d'informations représentant l'identité d'Alice (par exemple une chaîne de caractères donnant son adresse de courrier électronique). On suppose l'existence d'un procédé public à base de fonctions de hachage tel que On considérera dans la suite l'expression comme étant l'identité de Alice.
Supposons que Bob veuille transmettre un courrier à Alice, d'identité La valeur est publique, mais les facteurs et sont des valeurs secrètes gardées par l’autorité. On supposera de plus sans perte de généralité que est un carré modulo Bob va traiter son message bit à bit :
Chiffrement
modifierSoit la représentation d'un bit à envoyer, ou Bob choisit un entier aléatoirement tel que Il peut alors envoyer le cryptogramme correspondant à
Dérivation de clef
modifierConformément au principe des cryptosystèmes basés sur l'identité, Alice interagit avec l'autorité de manière à obtenir vérifiant . On a vu que seule la connaissance de et permet de calculer
La valeur devient alors le clef secrète d'Alice, fournie par l'autorité.
Déchiffrement
modifierComme . Alice peut retrouver par le calcul suivant.
Dans le cas où est un carré modulo on utilise .
Protocole de Boneh-Franklin
modifierC'est historiquement le premier schéma de chiffrement basé sur l'identité proposé en 2001 par Dan Boneh et Matthew Franklin[5]. Celui-ci est prouvé sémantiquement sûr dans le modèle de l'oracle aléatoire. Cette construction repose sur l'utilisation de couplages cryptographiques.
Initialisation
modifierLors de la phase d'initialisation, un couplage est choisi, ainsi qu'un générateur de , une fonction de hachage Un aléa est ensuite sélectionné et les paramètres publiques PP consistent en , et la clef secrète maître MSK est l'exposant secret .
Dérivation de clef
modifierLorsqu'un utilisateur demande une clef pour son identité , le possesseur de la clef maître privée l'utilise pour calculer .
Chiffrer
modifierPour chiffrer un message pour le possesseur de l'identité , un utilisateur va commencer par générer un aléa , puis calculer le chiffré . On peut reconnaître des similitudes avec le chiffrement El Gamal.
Déchiffrer
modifierEn possédant sa clef secrète , à la réception d'un chiffré , le receveur du message peut annuler le masque jetable sur la seconde composante du chiffré,
avec ces informations. Ce qui donne : .
Chiffrement fondé sur l'identité et signatures
modifierIl existe une construction générique de schémas de signature à partir de schémas de chiffrement fondé sur l'identité (CFI)i décrite dans les travaux initiaux de Boneh et Franklin sur les CFI de 2001[5]. Dans cet article, ils proposent la construction suivante: étant donné un CFI , on construit le schéma de signature :
- GenClefs(1λ): Cet algorithme commence en lançant l'algorithme d'initialisation du CFI pour obtenir . La clef de signature sera la clef secrète maîtresse du CFI: et la clef de vérification sont les paramètres publiques du CFI: .
- Signer(sk, M): Pour signer un message M, cet algorithme génère une clef dérivée pour l'identité correspondant au message pour en faire la signature: .
- Vérifier(vk, M, σ): Pour vérifier une signature, cet algorithme commence par tirer un challenge uniformément au hasard dans l'espace des messages, puis accepte la signature si et seulement si .
La correction du schéma de signature provient de la correction du CFI, et la sécurité de la signature (résistance aux falsifications) est issue de la sécurité du CFI (impossibilité de générer une clef dérivée sans la clef secrète maîtresse). Cette méthode permet, par exemple, de construire le schéma de signature de Boneh, Lynn et Shacham[6] à partir du CFI de Boneh et Franklin.
Notes et références
modifierAnnexes
modifierBibliographie
modifier- [Boneh et Franklin 2001] (en) Dan Boneh et Matthew Franklin, « Identity based encryption from the Weil pairing », Crypto, (lire en ligne)
- [Boneh, Lynn et Shacham 2001] (en) Dan Boneh, Ben Lynn et Hovav Shacham, « Short Signatures from the Weil Pairing », Asiacrypt, (lire en ligne)
- [Cocks 2001] (en) Clifford Cocks, « An identity based encryption scheme based on quadratic residues », Cryptography and Coding, (lire en ligne, consulté le ).
- [Diffie et Hellman 1976] (en) Whitfield Diffie et Martin Hellman, « Multiuser cryptographic techniques », AFIPS, (DOI 10.1145/1499799.1499815)
- [Neven et Joye 2008] (en) Gregory Neven et Marc Joye, Identity-Based Cryptography, Amsterdam, IOS Press, , 263 p. (ISBN 978-1-58603-947-9, lire en ligne)
- [Shamir 1984] (en) Adi Shamir, « Identity-based cryptosystems and signature schemes », Crypto, (lire en ligne, consulté le ).
Articles connexes
modifierLiens externes
modifier- (en) Benoît Libert et Damien Stehlé, « Cours de Cryptographie Avancée : IBE and Bilinear maps »,