PROCEDE D'AUTHENTIFICATION ENTRE ENTITES COMMUNIQUANT ENTRE ELLES AU TRAVERS D'UN RESEAU DE TELECOMMUNICATIONS
Domaine technique
L'invention se rapporte au domaine de l'authentification entre entités communiquant entre elles au travers d'un réseau de télécommunications.
L'invention s'applique notamment au contrôle d'accès, depuis une première entité, à des ressources physiques ou logiques distantes situées sur une deuxième entité, l'accès à la ressource nécessitant une authentification de la première entité de la part de la deuxième entité.
Etat de la technique
Dans Ie domaine de la cryptographie, II existe deux grandes familles d'algorithmes cryptographiques, à savoir, les algorithmes à clef secrète et les algorithmes à clef publique plus communément appelés algorithmes symétriques et algorithmes asymétriques par l'homme du métier, respectivement.
Lorsqu'une première entité A (l'entité s'authentifiant) requiert un accès à une ressource distante située sur une deuxième entité B (l'entité authentifiant), une authentification de la première entité A est réalisée par la deuxième entité B au moyen d'un protocole d'authentification. Ce protocole a pour fonction de certifier que la première entité est authentique.
Ce type de mécanisme d'authentification est souvent sujet à des attaques, notamment des attaques par rejeu (replay attack en anglais) consistant à espionner une communication entre entités et à en extraire des informations d'authentification pour les rejouer et se faire passer pour un utilisateur légitime. Il existe des mécanismes propres à éviter ces attaques par rejeu. Ces mécanismes sont appelés mécanismes à authentification forte. A la différence des mécanismes à authentification faible où seul le nom et le mot de passe de l'utilisateur sont nécessaires pour s'authentifier, les mécanismes
dits à authentification forte ou aussi appelés "défi-réponse" utilisent un algorithme cryptographique. Ces mécanismes consistent en les étapes suivantes: lorsque l'entité d'authentification B reçoit une demande d'authentification émise par une première entité se présentant à elle comme détentrice de l'identité A, l'entité d'authentification génère d'abord un défi qui est généralement un nombre aléatoire aussi appelé aléa, ou encore challenge, et envoie ce défi à l'entité s'authentifiant A. En retour, l'entité A signe le défi reçu selon un algorithme cryptographique de signature prédéfini. L'entité A renvoie alors à l'entité d'authentification B la signature du défi. L'entité B vérifie cette signature. En cas de vérification positive, l'entité d'authentification B valide l'authentification, signifiant que l'entité A s'est correctement authentifiée. La validation de l'authentification se traduit par exemple par l'attribution à l'entité cliente A, de la part de l'entité d'authentification B, de droits d'accès à des ressources gérées par l'entité d'authentification B.
Cette technique d'authentification forte présente un gros problème. En effet, deux cas de fraude se présentent selon que l'authentification choisie est asymétrique ou symétrique.
Considérons que, dans le cas d'utilisation d'un algorithme asymétrique, l'entité A dispose d'une clé secrète SA, et l'entité B connaît la clé publique PA de l'entité A. Dans ce cas, la clé publique PA de A est à priori largement diffusée car A peut la communiquer à toutes les entités avec lesquels ils doit avoir une relation de confiance (authentification, signature, chiffrement). Cette clé n'étant pas secrète, il n'y a aucun inconvénient à la publier ou à la diffuser largement. Ainsi le calcul de vérification de l'authentification effectuée dans l'entité A, qui ne nécessite que la connaissance de la clé publique PA, peut être effectué par tout ceux qui ont connaissance de cette clé, y compris les fraudeurs. Ceci est intrinsèque aux mécanismes à clé publique qui par définition sont dits « ouverts ». Il y a là un réel danger de détournement. De la même façon, considérons que dans le cas d'un algorithme symétrique, l'entité A, qui s'authentifie auprès de l'entité B, partage avec l'entité B une clé secrète KA- Dans ce cas, la vérification nécessite la connaissance de KA. Contrairement à la clé publique PA, la clé KA est une
donnée secrète qui ne peut être communiquée à des tiers car toute personne en possession de KA pourrait se faire passer pour A. Seules les entités A et B disposent donc de la clé secrète KA et donc seul l'entité B peut vérifier les authentifications. Le risque de détournement semble faible. Cependant un tiers malveillant pourrait détourner la principe d'authentification dit à authentification forte de la façon suivante: le fraudeur F peut demander à l'entité A (avec son consentement où à son insu) de calculer pour "N" valeurs de défi DEF1 , DEF2, ..., DEFN et obtenir des résultats respectifs R1 , R2, ... ,RN où : Ri est par exemple une fonction connue MAC fonction de la clé secrète KA et du défi DEFi (Ri= MAC(KA, di)) (MAC (Message Authentication Code) est une fonction d'authentification de message classique construite à partir d'un algorithme symétrique tel que le DES (acronyme anglo-saxon pour « Data Encryption Standard ») ou l'AES (Advanced Encryption Standard)). En stockant les couples (DEFi1Ri), le fraudeur F est capable de vérifier N authentifications. Certes le fraudeur F ne pourra réaliser qu'un petit nombre d'authentifications car calculer par avance un nombre N de fonction MAC représente un coût en temps considérable. L'entité B, dispose quant à lui de deux puissance I possibilités (2') où I est la longueur en bits de du défi. Concrètement, pour une valeur de I = 64 qui est une valeur courante, 2 puissance 64 (2 ) est un nombre très grand. Cependant, une fois les N authentifications obtenues, le fraudeur F pourra demander d'autre valeurs (DEFi, Ri) à l'entité A, ou rejouer les anciennes valeurs obtenues DEFi en affaiblissant bien sûr, dans ce dernier cas, la fiabilité de l'authentification.
Un tiers malveillant peut ainsi détourner à son profit (pour réaliser un service nécessitant une authentification) le matériel et/ou le logiciel et les données qui ont été déployées par un fournisseur légitime du service. Or ce déploiement peut être coûteux. Le tiers malveillant bénéficie alors gratuitement du service, ce qui est néfaste pour le fournisseur légitime du service. L'invention
Un but de l'invention est de diminuer considérablement ce type de fraude tout en assurant une compatibilité avec les standards actuels
minimisant ainsi les modifications à réaliser pour la mise en œuvre de l'invention.
A cet effet, le procédé de l'invention comprend les étapes suivantes:
- une étape de calcul, par la deuxième entité, d'un défi et de la signature de ce défi, ladite signature étant réalisée par l'intermédiaire d'une donnée secrète détenue par la deuxième entité,
- une étape de transmission de la signature dans laquelle la deuxième entité transmet à la première entité au moins la signature,
- une étape de vérification dans laquelle la première entité (A) vérifie la signature du défi,
- une étape décisionnelle dans laquelle la signature du défi par la première entité ainsi que sa transmission vers l'entité d'authentification est subordonné au résultat positif de la vérification de la signature du défi.
L'invention concerne aussi une entité d'authentification comprenant un microcontrôleur stockant un programme apte à réaliser les étapes suivantes:
- une étape de calcul, d'un défi et de la signature de ce défi, ladite signature étant réalisée par l'intermédiaire d'une donnée secrète (SB1KB) détenue par (B);
- une étape de transmission de la signature (SGN) dans laquelle l'entité d'authentification (B) transmet à l'entité (A) au moins la signature (SGN), ladite signature (SGN) étant apte à être vérifiée par la première entité (A) afin d'authentifier l'entité d'authentification (B);
- une étape de réception de la signature du défi par la première entité (A), cette étape étant subordonnée au résultat positif de la vérification, par la première entité (A), de la signature (SGN) du défi.
L'invention concerne aussi une entité apte à être authentifiée auprès d'une entité d'authentification, l'entité s'authentifiant comprenant un microcontrôleur stockant un programme apte à réaliser les étapes suivantes:
- une étape de réception d'au moins une signature d'un défi issue de l'entité d'authentification, ladite signature étant réalisée par l'intermédiaire d'une donnée secrète détenue pas l'entité d'authentification,
- une étape de vérification dans laquelle la signature (SGN) du défi est vérifiée,
- une étape décisionnelle dans laquelle la signature du défi ainsi que sa transmission vers l'entité d'authentification est subordonnée au résultat positif de la vérification de la signature du défi;
L'invention se rapporte aussi au programme d'ordinateur apte à être mis en œuvre sur une entité d'authentification apte à authentifier une première entité, lesdites entités communiquant entre elles au travers d'un réseau de télécommunication, caractérisé en ce que ledit programme comprend des instructions de code qui, lorsque le programme est exécuté sur ladite entité d'authentification, réalise les étapes suivantes: - une étape de calcul d'un défi et de la signature de ce défi, ladite signature étant réalisée par l'intermédiaire d'une donnée secrète détenue par l'entité d'authentification;
- une étape de transmission de la signature (SGN) dans laquelle l'entité d'authentification transmet à la première entité au moins la signature, ladite signature étant apte à être vérifiée dans la première entité afin d'authentifier l'entité d'authentification;
- une étape de réception par l'entité d'authentification de la signature du défi réalisée par la première entité, cette étape étant subordonnée au résultat positif de la vérification, par la première entité (A), de la signature (SGN) du défi.
L'invention se rapporte aussi à un programme d'ordinateur apte à être mis en œuvre sur une entité s'authentifiant auprès d'une entité d'authentification, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté sur ladite entité s'authentifiant, réalise les étapes suivantes:
- une étape de réception d'au moins une signature d'un défi issue de l'entité d'authentification, ladite signature étant réalisée par l'intermédiaire d'une donnée secrète détenue par l'entité d'authentification,
- une étape de vérification dans laquelle la signature du défi est vérifiée par l'entité s'authentifiant,
- une étape décisionnelle dans laquelle la signature du défi par l'entité s'authentifiant ainsi que sa transmission vers l'entité d'authentification (B) est subordonné au résultat positif de la vérification de la signature du défi.
De cette façon, l'entité s'authentifiant vérifie la signature du défi reçue, et s'assure que l'entité d'authentification requérant une authentification est bien l'entité légitime et non un fraudeur. Ainsi, l'entité s'authentifiant ne répond au défi issu de l'entité d'authentification que si la signature du défi est valide.
Dans le cas contraire, l'entité s'authentifiant ne répond pas au défi ou répond une valeur sans signification. On assure ainsi que seul l'entité d'authentification légitime ne peut interroger l'entité s'authentifiant car la signature du défi ne peut être calculée que par l'entité d'authentification. Ainsi, grâce à l'invention, il n'y a pratiquement plus de risque de détournement.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence à la figure 1 représentant un système informatique dans lequel l'invention peut être mise en œuvre.
Description détaillée d'exemples de réalisation illustrant l'invention
La figure 1 représente un système informatique SYS. Dans l'exemple de réalisation, ce système comprend deux entités. Une première entité A communiquant avec une deuxième entité B au travers d'un réseau de télécommunications RES.
Dans notre exemple de réalisation, nous désignerons par A l'entité s'authentifiant et B l'entité d'authentification.
Dans notre exemple de réalisation, la première entité A souhaite accéder à des ressources physiques ou logiques présentes sur l'entité B. Dans notre exemple, l'entité B engage une procédure d'authentification propre à authentifier l'entité A.
Le partage de clés entre les entités A et B est fonction de l'algorithme d'authentification utilisé. Avec un algorithme symétrique, l'entité A, qui s'authentifie auprès de l'entité B, partage avec l'entité B une clé secrète KA.
Avec un algorithme asymétrique, l'entité A dispose d'une clé secrète SA, et l'entité B connaît la clé publique PA de A.
Dans les deux cas, le protocole se déroule de la manière suivante :
- L'entité A envoie son identité idA à l'entité B;
- Après réception de l'identité idA, l'entité B envoie un défi DEF à l'entité A; - L'entité A réalise ensuite un calcul à l'aide d'un algorithme d'authentification, et transmet une réponse R. Dans notre exemple de réalisation, la réponse R est: o dans le cas symétrique : R = MAC(KA, DEF), o dans le cas asymétrique: R = SGN(SA, DEF) OÙ SGN est un algorithme de signature asymétrique.
Indifféremment, à réception de l'identifiant IdA ou à réception de la réponse R, l'entité B retrouve grâce à l'identité idA de A, selon le cas, la clé KA OU la clé PA, et réalise le calcul suivant : o Dans le cas symétrique R' = MAC(KA, DEF) si R = R' l'authentification est réussie; dans la négative, elle échoue. o Dans le cas asymétrique, l'entité B met en œuvre l'algorithme de vérification de signature VERIF(PA, DEF). Si cette vérification est positive l'authentification est réussie; dans la négative, elle échoue.
Selon l'invention, la deuxième entité B calcule non seulement un défi DEF mais aussi la signature SGN de ce défi. Ensuite, au moins la signature est transmise par l'entité B à l'entité A. En réponse à ce défi, A ne signera le défit proposé et le transmettra à l'entité B que si la vérification de la signature
SGN est positive.
Avantageusement, la signature SGN peut être réalisée par l'entité B en utilisant un algorithme symétrique ou asymétrique, ceci indépendamment du
procédé d'authentification proprement dit, qui peut, de manière indépendante, lui aussi être symétrique ou asymétrique.
Les différents exemples décrits ci-dessous illustreront des variantes mettant en œuyre l'invention: Cas symétrique:
Un premier exemple est celui où la signature du défi DEF est réalisée par l'intermédiaire d'un mécanisme d'authentification symétrique. Deux variantes décrites ci-dessous illustreront ce premier exemple.
Dans cet exemple, l'entité A et l'entité B partagent une clé secrète KB. Cas symétrique - Variante 1 :
Selon une première variante, l'entité B calcule la signature du défi de la façon suivante:
SGN = MAC(KB, DEF)
Dans notre exemple, l'entité B transmet à l'entité A le couple (DEF, SGN) incluant le défi ainsi que sa signature SGN.
Ensuite, l'entité A réalise le même calcul et obtient comme résultat une signature SGN':
SGN1 = MAC(KB, DEF)
L'entité A vérifie que la signature reçue SGN est la même que celle calculée SGN'.
Si la signature est la même, l'entité A répond à l'entité B. Dans la négative, l'entité A ne répond pas ou répond une valeur sans signification de manière à ce qu'un éventuel fraudeur obtienne de faux résultats.
Cas symétrique - Variante 2:
Selon une deuxième variante, l'entité B calcule une fonction de redondance sur le défi DEF :
Cl1 = Red(DEF)
La fonction de redondance "Red" peut être dérivée d'un code correcteur d'erreur ou simplement en concaténant au défi DEF un motif de bit fixe.
Le résultat de la fonction de redondance donne une valeur d1. L'entité A chiffre ensuite la valeur obtenue d-\ avec un algorithme symétrique E et obtient une valeur d2 = E(KB, d-i).
L'entité A transmet ensuite la valeur d2 à l'entité B.
L'entité B déchiffre ensuite la valeur d2 reçue et obtient d'i = D(KB, d2) et vérifie la redondance de d'i (en vérifiant par exemple le code correcteur d'erreur ou en vérifiant la présence du motif de bits).
L'entité B ne répond à l'entité A que si cette vérification est positive.
Cas asymétrique: Un deuxième exemple est celui où la signature du défi DEF est réalisée par l'intermédiaire d'un mécanisme d'authentification asymétrique. L'utilisation d'algorithmes asymétriques évite d'avoir le même secret dans tous les dispositifs.
Dans ce cas, l'entité B dispose d'une clé secrète SB et l'entité A dispose de la clé publique correspondante PB de l'entité B. Deux variantes vont illustrer ce deuxième exemple (cf. Cas asymétrique - variante 1 et Cas asymétrique variante 2, ci-dessous).
Cas asymétrique - variante 1 :
L'entité B calcule la signature du défi en utilisant la clé secrète SB et le défi: SGN (SB, DEF) où SGN est un algorithme de signature asymétrique.
L'entité B transmet ensuite le couple (DEF, SGN) comprenant le défi et la signature à l'entité A pour vérification.
L'entité A met en œuvre l'algorithme de vérification de signature VERIF(PB, DEF) pour vérifier si la signature reçue est correcte; dans l'affirmative, l'entité A répond à l'entité B.
Cas asymétrique variante 2: Cette variante s'applique dans le cas particulier où l'algorithme de signature est l'algorithme RSA.
L'entité B calcule une fonction de redondance sur DEF et obtient la valeur d1 = Red(DEF) (où Red est la fonction de redondance définie ci-dessus), puis signe d1 avec l'algorithme RSA et obtient la valeur d2 =RSA(SB, d1 ).
Ensuite, dans notre exemple, l'entité B transmet d2 à l'entité A. On s'aperçoit que dans cette variante, le défi n'est pas transmis en clair sur le réseau.
Après réception du défi d2, l'entité A fait le calcul inverse et obtient une valeur d'1 = RSA(PB, d2) et vérifie que la redondance de d'1 est correcte . L'entité A ne répondra à l'entité B que si cette vérification est positive.
Selon une caractéristique préférée de l'invention, dans la cas de la signature symétrique, la clé secrète que l'on notera KBA nécessaire au calcul de l'algorithme d'authentification MAC ou du chiffrement/déchiffrement à l'aide des algorithmes E et F définis ci-dessus (cas symétrique - variantes 1 et 2) et nécessaires à la mise en œuvre des deux variantes ci-dessus, est dérivée d'une secret mère MB et, par exemple, de l'identifiant idA de l'entité s'authentifiant. Dans cet exemple, l'identifiant Ida est choisi comme paramètre car celui-ci est unique, deux entités A ne pouvant avoir un même identifiant idA. Tout autre paramètre assurant cette unicité peut être choisi pour le calcul de la clé mère MB; Dans notre exemple de réalisation, le calcul de la clé KBA est réalisé à l'aide de l'algorithme d'authentification MAC de la manière suivante : KBA = MAC(MB, idA) où idA est l'identité de A et MB la clé mère.
Généralement, cette clé mère MB est délivrée par un organisme habilité à délivrer des clés.
Ainsi chaque entité contient cette fois un secret individuel KBA- B est capable de reconstituer toutes les clés KBA de chaque entité puisqu'il connaît la clé mère MB et l'identifiant idA de chaque entité A. Ceci évite que la même clé secrète ne se trouve sur plusieurs entités à la fois. Chaque entité A nécessitant une authentification dispose donc de sa propre clé secrète KBA-
Selon une autre caractéristique avantageuse de l'invention, les entités A et B sont dotées de compteur CA et CB, respectivement. Dans notre exemple illustré, l'entité B dispose d'un compteur C6 initialisé au départ à 1.
Chaque dispositif A dispose d'un compteur CA stocké dans le dispositif initialisé au départ à 0.
Selon cette variante, l'entité B transmet la valeur courante de son compteur CB en tant que défi DEF, et l'incrémente après transmission, par exemple d'une unité. L'entité B met en œuvre la transmission du défi selon l'une des variantes décrites ci-dessus.
L'entité A récupère ensuite le défi DEF de l'une des façons décrites ci- dessus. Si le défi reçu, à savoir la valeur courante du compteur CB, est supérieur à la valeur du compteur courant CA de l'entité (si DEF > CA) il met à jour CA et poursuit le processus d'authentification. Dans notre exemple, le compteur CA prend la valeur du défi reçu; en d'autres mots la valeur de CA prend la valeur du compteur CB reçu. A l'inverse, si le défi reçu, à savoir la valeur courante du compteur CBi est inférieur à la valeur du compteur courant CA de l'entité A (si DEF < CA) alors l'entité A ne répond pas (ou répond une valeur sans signification); dans ce cas, l'authentification n'aura pas lieu.
Cette utilisation de compteurs peut aussi être mis en œuvre en combinaison avec toutes les variantes/améliorations décrites ci-dessus. Ainsi, la sécurité du mécanisme d'authentification est augmentée, l'entité A devant
procéder à une double vérification à savoir la vérification de la signature du défi et la vérification de la valeur du compteur.
On voit bien que la présente invention, outre l'avantage principal cité ci- dessus, comporte d'autres avantages améliorant la sécurité du processus d'authentification.
Par exemple, on a vu que la signature SGN du défi DEF effectuée dans l'entité d'authentification B est réalisée par tout type d'algorithme cryptographique indépendamment du type d'algorithme cryptographique choisi servant à authentifier l'entité A. Ainsi, par exemple si l'algorithme cryptographique utilisé pour authentifier est de type symétrique, un fraudeur peut être tenté d'utiliser le même algorithme pour décrypter la signature du défi reçu par l'entité A. Cette fonctionnalité apporte un avantage en terme de sécurité.
On a vu aussi que la signature peut être transmise avec ou sans le défi DEF sur le réseau RES. De cette façon, l'information transmise par l'entité d'authentification B vers l'entité ne donne aucune indication sur la valeur du défi.
On a vu aussi que chaque entité s'authentifiant ou d'authentification dispose d'un compteur (CA, CB). Un programme stocker sur l'entité B est apte à transmettre le compteur CB de l'entité d'authentification B à la première entité A pour comparaison, et à décider, en fonction de la comparaison, de la poursuite ou non du processus d'authentification de l'entité A. De préférence, ce compteur est signé de la même manière qu'un défi. La signature ainsi obtenue du compteur CB est vérifiée dans la première entité A à la fois pour authentifier l'entité d'authentification B et pour s'assurer que le compteur est valide.
Dans notre exemple de réalisation, le compteur de l'entité d'authentification B a initialement une valeur supérieure au compteur de la première entité A. Chaque transmission ou réception d'un compteur est suivi d'une incrémentation de la valeur du compteur respectif. Un programme est apte à vérifier que le compteur CB associé à l'entité d'authentification B est supérieur au compteur CA de la première entité (A) avant de poursuivre ou
non le processus d'authentification de l'entité A. Grâce à l'utilisation de compteurs, l'invention assure que l'entité s'authentifiant A ne réponde pas deux fois à un même défi DEF. Le risque de détournement est cette fois impossible grâce à cette fonctionnalité. En effet, une entité frauduleuse qui observerait les transactions transitant entre les entités A et B pourrait stocker des valeurs (di, si, ri) et les utiliser pour interroger le dispositif de A avec le couple (di, si) et vérifier qu'il obtient bien ri. Ce type de détournement consisterait en une écoute du protocole d'authentification, contrairement au type de détournement évoqué dans l'introduction de la présente demande qui consistait en une interrogation du dispositif.
D'autre part, on a vu que si la signature du défi DEF est de type symétrique, un programme est apte à calculer une clé secrète KAB, ladite clé secrète étant partagée entre l'entité d'authentification B et une première entité A, à partir d'une clé secrète mère MB et de l'identifiant IdA de l'entité A s'authentifiant. Ainsi, l'entité d'authentification B ne partage pas un même secret KB avec toutes les entités A du système nécessitant une authentification.