FR2963451A1

FR2963451A1 - Authentification d'une communication multiprotocole

Info

Publication number: FR2963451A1
Application number: FR1056152A
Authority: FR
Inventors: Gilles Bas; Herve Chalopin; Francois Tailliet
Original assignee: STMicroelectronics Rousset SAS
Current assignee: STMicroelectronics Rousset SAS
Priority date: 2010-07-27
Filing date: 2010-07-27
Publication date: 2012-02-03
Anticipated expiration: 2030-07-27
Also published as: US20120030753A1; FR2963451B1; US8671278B2

Abstract

L'invention concerne un procédé d'authentification d'une transmission entre un premier et un deuxième circuit transitant par au moins un troisième circuit, dans lequel : des données (DATA) sont transmises du premier au troisième circuit, et du troisième au deuxième circuit ; une première signature (SIGN (K1)) des données est calculée par le premier circuit ; au moins une deuxième signature (SIGN(K2)) des données est calculée par le troisième circuit ; au moins une première partie (LSIGN (K1)) de la première signature est transmise par le premier circuit au troisième ; et la deuxième signature est transmise par le troisième circuit au deuxième, une partie (HSIGN(K2)) de cette deuxième signature étant faussée (FHSIGN(K2)) en cas d'échec d'authentification de la première partie de la première signature par le troisième circuit.

Description

B10358 - 10-RO-094 1 AUTHENTIFICATION D'UNE COMMUNICATION MULTIPROTOCOLE

Domaine de l'invention La présente invention concerne de façon générale les circuits électroniques et, plus particulièrement, la transmission de données numériques entre deux circuits, par l'intermédiaire d'un circuit de conversion. L'invention concerne plus particulièrement l'authentification d'une transmission dans le cas où les deux circuits n'utilisent pas le même protocole de transmission et ont recours à un circuit d'interface ou de conversion.

Exposé de l'art antérieur On connaît de nombreux systèmes de conversion ou d'interface entre des bus de communication adaptés à des protocoles différents. Par exemple, le brevet US 6 066 964 décrit un bus 15 dynamique dans lequel une communication peut être établie sur l'une ou l'autre phase d'un signal d'horloge. Selon un autre exemple, les demandes de brevet US 2010/017553 et EP 246 287 (B8881-08-RO-082) décrivent un système d'interface entre un bus bifilaire et un bus unifilaire 20 exploitant les deux demi-périodes du signal d'horloge du bus bifilaire en plaçant les données sur une première demi-période et un motif d'attente sur l'autre demi-période.

B10358 - 10-RO-094

2 D'autres mécanismes de conversion d'une communication entre des circuits utilisant des protocoles différents, donc un circuit intermédiaire de conversion, sont connus. L'invention s'applique plus particulièrement à des 5 systèmes de transmission de type maître-esclave. Dans une transmission maître-esclave, il est souvent souhaitable que le circuit esclave soit en mesure d'authentifier le circuit maître et inversement, que ce soit pour indirectement protéger les données transmises ou pour authentifier les 10 circuits ou les données. Ces mécanismes font habituellement appel à des algorithmes de cryptographie symétriques ou asymétriques. La mise en oeuvre de ces mécanismes ne pose généralement pas de problème lorsque les deux circuits sont 15 connectés sur un même bus. Toutefois, en présence d'un circuit d'interface ou de conversion de protocole de communication faisant intervenir un circuit additionnel, les mécanismes d'authentification habituels ne sont pas adaptés. En particulier, dans le cas d'une authentification 20 maître-esclave, le convertisseur peut altérer, de façon transparente pour le maître et l'esclave, le contenu des trames qui transitent par lui, et fausser ainsi les données d'authentification. Dans d'autres cas où l'authentification repose sur la 25 liaison convertisseur-esclave ou sur la liaison maître-convertisseur, le système peut être trompé en substituant un faux maître ou un faux esclave. L'invention s'applique notamment à des systèmes effectuant une conversion d'un bus multifilaire comportant au 30 moins un signal de synchronisation et un signal de donnée en un bus unifilaire et inversement. Résumé Un objet d'un mode de réalisation de la présente invention est de proposer un mécanisme d'authentification qui 35 pallie tout ou partie des inconvénients des mécanismes usuels.

B10358 - 10-RO-094

3 Un objet d'un autre mode de réalisation de la présente invention est de proposer un mécanisme adapté à une transmission faisant intervenir un circuit de conversion entre l'émetteur et le récepteur.

Un objet d'un autre mode de réalisation de la présente invention est de proposer une solution particulièrement adaptée à une conversion d'un bus bifilaire de type I2C en un bus unifilaire. Pour atteindre tout ou partie de ces objets ainsi que d'autres, il est prévu un procédé d'authentification d'une transmission entre un premier et un deuxième circuit transitant par au moins un troisième circuit, dans lequel : des données sont transmises du premier au troisième circuit, et du troisième au deuxième circuit ; une première signature des données est calculée par le premier circuit ; au moins une deuxième signature des données est calculée par le troisième circuit ; au moins une première partie de la première signature est transmise par le premier circuit au troisième ; et la deuxième signature est transmise par le troisième circuit au deuxième, une partie de cette deuxième signature étant faussée en cas d'échec d'authentification de la première partie de la première signature par le troisième circuit.

Selon un mode de réalisation de la présente invention, la deuxième signature est transmise en au moins deux parties. Selon un mode de réalisation de la présente invention, la deuxième signature est vérifiée par parties par le deuxième dispositif.

Selon un mode de réalisation de la présente invention, la deuxième partie de la première signature n'est pas transmise au troisième dispositif. Selon un mode de réalisation de la présente invention : B10358 - 10-RO-094

4 les premier et troisième circuits partagent une première clé ; et les deuxième et troisième circuits partagent une deuxième clé différente de la première.

Selon un mode de réalisation de la présente invention, plusieurs troisièmes circuits interviennent dans la trans- mission, chaque troisième circuit partageant une clé d'authentification avec les circuits précédant et suivant, et une deuxième partie de signature destinée au circuit suivant étant faussée en l'absence d'authentification de la première partie de signature provenant du dispositif précédant. Selon un mode de réalisation de la présente invention, les signatures sont calculées par un algorithme AES. Selon un mode de réalisation de la présente invention, la transmission entre les premier et troisième circuits s'effectue sur un bus comprenant au moins un fil de transmission des données et un fil de transmission d'un signal de synchronisation, la liaison entre les troisième et deuxième circuits étant un bus unifilaire.

On prévoit également un système de transmission entre un premier et un deuxième circuit par l'intermédiaire d'au moins un troisième circuit. Selon un mode de réalisation de la présente invention, le premier circuit est un circuit maître et le deuxième circuit est un circuit esclave, le troisième circuit étant un convertisseur de protocole de communication. Brève description des dessins Ces objets, caractéristiques et avantages, ainsi que d'autres seront exposés en détail dans la description suivante de modes de réalisation particuliers faite à titre non-limitatif en relation avec les figures jointes parmi lesquelles : la figure 1 représente sous forme de blocs, un exemple d'architecture de système de transmission auquel s'applique la présente invention ; B10358 - 10-RO-094

la figure 2 illustre un mode de réalisation du procédé d'authentification selon la présente invention ; et la figure 3 est un organigramme illustrant de façon plus détaillée un autre mode de réalisation du procédé d'authen- 5 tification selon l'invention. Description détaillée De mêmes éléments ont été désignés par de mêmes références aux différentes figures. Par souci de clarté, seuls les éléments et étapes utiles à la compréhension de l'invention ont été représentés et seront décrits. En particulier, la génération des trames de communication n'a pas été détaillée, l'invention étant compatible avec tout protocole de communication usuel. La figure 1 est un schéma bloc d'un exemple d'un mode de réalisation d'un système de communication entre un circuit maître 1 (HOST) susceptible de transmettre des données selon un premier protocole et un circuit esclave 2 (SLAVE) susceptible de communiquer selon un autre protocole. Par exemple, le premier protocole exploite un bus bifilaire de type I2C comportant un fil véhiculant un signal de synchronisation et un fil véhiculant un signal de données, et le second protocole exploite un bus unifilaire véhiculant à la fois le signal de synchronisation et les données et, le cas échéant l'alimentation. Un circuit 4 d'interface (INTERFACE) ou de conversion est intercalé entre les deux bus pour convertir la transmission. Les différents circuits du système peuvent être alimentés indépendamment les uns des autres ou par un bus d'alimentation susceptible de véhiculer au moins un potentiel d'alimentation et un potentiel de référence, par exemple la masse.

Pour authentifier les circuits et les données transmises, on prévoit d'utiliser un algorithme symétrique de calcul de signature de ces données. De nombreux algorithmes de ce type sont connus, par exemple, des algorithmes connus sous les dénominations MAC ou AES. Ces algorithmes soumettent les données à signer (les données transmises) à un algorithme B10358 - 10-RO-094

6 utilisant une clé numérique et fournissent une signature. Cette signature est transmise avec les données. Le récepteur possède la même clé numérique et le même algorithme, ce qui lui permet, selon l'algorithme utilisé, de calculer une signature à partir des données reçues et de la comparer à la signature reçue, ou d'extraire une copie des données à partir de la signature reçue pour comparer cette copie aux données reçues. En cas de différence, cela signifie soit que les données ont été modifiées accidentellement ou volontairement (piratage de la liaison) pendant le transfert, soit que le circuit émetteur ou récepteur n'est pas celui attendu. On prévoit d'effectuer un contrôle de signature au niveau de chaque tronçon de la transmission (entre l'émetteur et le circuit de conversion et entre ce dernier et le récepteur).

On pourrait penser valider, au niveau du circuit de conversion, les données transmises entre l'émetteur et le circuit de conversion, puis faire suivre ces données si elles sont valides au récepteur et vérifier de nouveau leur validité par le récepteur. Toutefois, une telle validation séquentielle des données serait incompatible avec un transfert en temps réel. De plus, pour le cas où les données sont modifiées sur le bus, il serait souhaitable que le récepteur avertisse l'émetteur d'un éventuel problème afin qu'il cesse de transmettre des données.

La figure 2 représente un exemple d'échange de messages entre les circuits 1, 2 et 4 de la figure 1, illustrant un mode de réalisation du procédé d'authentification prévu. Selon ce mode de réalisation, les deux liaisons circuit maître 1 à interface 4, et interface 4 à circuit esclave 2 sont authentifiées séparément en prévoyant une clé d'authentification différente pour chaque liaison (K1 pour le bus I2C et K2 pour le bus SW). Toutefois, les données transitent par l'interface sans être retardées. Des données DATA sont envoyées (flèche 31) par le 35 circuit maître HOST au convertisseur INTERFACE, puis (flèche 33) B10358 - 10-RO-094

7 par ce dernier au circuit esclave SLAVE. Après l'envoi 31, le circuit maître calcule une signature SIGN(K1) des données avec la clé K1 qu'il partage avec l'interface. Puis (flèche 41), il envoie une partie seulement LSIGN(K1) de cette signature (par exemple la moitié des bits) à l'interface. En parallèle (plus précisément, sans attendre la réception de la signature SIGN(K1), l'interface calcule une deuxième signature SIGN(K2) des données qu'elle a reçues du circuit maître. Puis, elle envoie (flèche 43) un première partie seulement LSIGN(K2) de cette signature (par exemple la moitié des bits) au circuit esclave. Ces opérations de calcul des signatures et d'envoi d'une première partie de celles-ci au circuit suivant dans le sens de la transmission s'effectuent donc indépendamment pour chaque tronçon, donc sans délai. De plus, l'envoi des données DATA entre l'interface et le circuit esclave n'est pas conditionné par l'authentification entre le circuit maître et l'interface. A réception de la partie LSIGN(K1) de la signature du circuit maître par l'interface, celle-ci vérifie (CHECK(K1)) la cohérence de cette partie. Pour cela, elle signe les données reçues avec la clé K1 qu'elle possède et vérifie que la première partie de cette signature est conforme à celle reçue du circuit maître. Le calcul de la signature avec la clé K1 par l'interface peut même être effectué avant réception de la partie LSIGN(K1). Selon le résultat de cette vérification, le circuit d'interface transmet (flèche 53) au circuit esclave, soit la deuxième partie HSIGN(K2) de la deuxième signature, soit une deuxième partie corrompue FHSIGN(K2) de cette deuxième signature. Cette signature corrompue peut être un mot de bits arbitraire, par exemple issu d'un tirage aléatoire, un mot prédéfini ayant une chance négligeable de correspondre à une signature exacte, la signature modifiée sur au moins un bit, etc.

B10358 - 10-RO-094

8 Le circuit esclave vérifie alors la deuxième signature. Pour cela, il signe les données reçues avec la clé K2 qu'il partage avec l'interface et vérifie (CHECK(K2)) que cette signature est cohérente avec celle reçue en deux fois de l'interface. En cas d'incohérence, le circuit esclave prend des contre-mesures adaptées à l'application. Par exemple, il ne traite pas les données reçues, il ne répond pas au circuit maître, il se réinitialise, il efface sa clé, etc. Selon une variante de mise en oeuvre, si la deuxième signature n'est pas correctement vérifiée par le circuit esclave, celui-ci envoie un message d'erreur de transmission au circuit maître. Dans la plupart des protocoles de communication, il est prévu des codes d'erreurs de transmission. L'envoi d'un tel code par le circuit esclave renseigne le circuit maître sur le fait que la communication n'est pas fiable. Si le code d'erreur peut être différencié d'autres messages d'erreur, le circuit maître peut prendre des contre-mesures spécifiques, adaptées à une situation de piratage. Un examen des parties de la deuxième signature permet au circuit esclave de déterminer d'où vient l'éventuel problème. Si la première partie n'est pas cohérente, c'est que la liaison SW (ou le circuit esclave) n'est pas authentique. Si la deuxième partie n'est pas cohérente, c'est que la première liaison I2C (ou le circuit maître) n'est pas authentique. Cela peut permettre de prendre des contre-mesures différentes selon les cas. Les deux signatures utilisent, par exemple mais non nécessairement, le même algorithme symétrique. La figure 3 est un organigramme plus détaillé d'un mode de mise en oeuvre du procédé de vérification de signature. Dans l'exemple de la figure 3, on utilise un algorithme AES pour signer les données. De préférence, on choisit une longueur de signature en fonction de la granularité de blocs de données transmis. L'algorithme AES fournit ici une signature sur 16 octets.

B10358 - 10-RO-094

9 On suppose que les bits de données (par exemple, également 16 octets) ont déjà été transmis du circuit maître au circuit d'interface et du circuit d'interface au circuit esclave.

Dans une première étape (bloc 51, H-1 AESh<15:8>, I-S AESm<15:8>), le circuit maître H transmet à l'interface I huit premiers octets AESh<15:8> d'un AES sur 16 octets calculé sur la base des données qu'il vient de transmettre à l'interface. Cette signature peut être calculée au moment de l'envoi ou être précalculée et mémorisée par le circuit maître. Dans cette étape 51, l'interface I calcule et transmet au circuit esclave S les huit premiers octets AESm<15:8> d'un AES calculé sur les données qu'il a reçues du circuit maître. Côté circuit d'interface I, celui-ci vérifie (bloc 61, Interface teste AESh<15:8>) que les huit premiers octets de la signature reçue correspondent bien à celle qu'il calcule avec la clé qu'il partage avec le circuit maître. Si la signature entre le circuit maître et l'interface n'est pas vérifiée (sortie N du bloc 62, match), on considère que la liaison I2C (figure 1) est corrompue ou que le circuit maître n'est pas authentique (bloc 63, Host-interface fail). Le circuit d'interface corrompt (bloc 64, Corrompt AESm<7:0>) les huit octets suivants AESm<7:0> de la deuxième signature. Par contre, si l'interface valide le premier octet de la signature (sortie Y du bloc 62) avec le maître, on considère que la liaison entre le circuit maître et l'interface est correcte (bloc 65, Host-interface OK). Dans les deux cas, la deuxième partie de signature (correcte ou faussée) est transmise au circuit esclave (bloc 66 I-S AESm<7:0>). Côté circuit esclave, les premier et second groupes de huit octets de la deuxième signature peuvent être traités indépendamment. Le circuit esclave teste (bloc 71 Slave teste AESh<15:8>) les huit premiers octets de la deuxième signature sur la base des données qu'il a reçues de l'interface. Selon que cette première partie est ou non correcte (sortie Y ou N du bloc 76, match), on considère que la liaison interface esclave est B10358 - 10-RO-094

10 correcte (bloc 77, Interface-slave OK) ou est incorrecte (bloc 78, Interface-slave fail). Dans ce dernier cas, le circuit esclave refuse les données (bloc 75, Slave rejette data) en adoptant un traitement adapté. Par ailleurs, le circuit esclave vérifie les huit octets suivants (bloc 72, Slave teste AESh<7:0>). Selon que cette signature calculée est ou non correcte (sortie Y ou N du bloc 73, match), le circuit esclave accepte les données transmises (bloc 74, Slave accepte data) ou les rejette (bloc 75).

En variante, la deuxième signature est transmise entière (avec une deuxième partie faussée ou non) au circuit esclave pour vérification. Ce qui vient d'être décrit pour authentifier les liaisons maître-interface et interface-esclave s'applique également dans l'autre direction. Il suffit de considérer le maître comme étant l'esclave et inversement. Les modes de réalisation décrits tirent profit du fait que le souhait est ici d'authentifier la communication et non de protéger les données transmises. Par conséquent, les données peuvent être envoyées indépendamment de la vérification de signature qui ne sert qu'à les valider. L'authentification peut d'ailleurs être combinée à un chiffrement des données transmises, pourvu que les signatures soient calculées sur la base des données chiffrées. L'interface n'a alors pas besoin de connaître la clé de chiffrement. Le fait de transmettre systématiquement les données empêche à un éventuel utilisateur frauduleux ayant piraté une des liaisons de savoir quel est le circuit qui a détecté l'erreur.

Dans les modes de réalisation décrits ci-dessus, la deuxième partie de la première signature entre le circuit maître et l'interface n'est jamais transmise à l'interface. Toutefois, le risque que deux premières parties de signature soient identiques avec des données différentes peut dans la plupart des cas être négligé, surtout avec une signature de taille B10358 - 10-RO-094

11 relativement importante (du même ordre de grandeur que les données). Divers modes de réalisation ont été décrits, diverses variantes et modifications apparaîtront à l'homme de l'art. En particulier, bien que l'invention ait été décrite en relation avec une transmission entre deux circuits par l'intermédiaire d'une interface, celle-ci s'applique plus généralement à une transmission en cascade par l'intermédiaire de plusieurs circuits intermédiaires, pourvu qu'au moins un de ces circuits effectue une conversion de protocole. Dans un tel cas, le circuit intermédiaire qui détecte une éventuelle erreur corrompt la signature du reste du message. De plus, la mise en oeuvre pratique de l'invention est à la portée de l'homme du métier à partir des indications fonctionnelles données ci-dessus et en utilisant des moyens matériels et logiciels usuels. En outre, bien que l'invention ait été décrite en relation avec un exemple de communication maître esclave sur des bus I2C et SW, elle s'applique plus généralement à toute transmission entre un émetteur et un récepteur dans laquelle une conversion de protocole de communication intervient. Enfin, bien que l'invention ait été décrite plus particulièrement en relation avec l'utilisation d'un algorithme de type AES, elle s'applique plus généralement à tout algorithme de calcul de signature ou de message d'authentification.

Claims

REVENDICATIONS1. Procédé d'authentification d'une transmission entre un premier (1) et un deuxième circuit (2) transitant par au moins un troisième circuit (4), dans lequel : des données (DATA) sont transmises du premier au 5 troisième circuit, et du troisième au deuxième circuit ; une première signature (SIGN(K1)) des données est calculée par le premier circuit ; au moins une deuxième signature (SIGN(K2)) des données est calculée par le troisième circuit ; 10 au moins une première partie (LSIGN(K1)) de la première signature est transmise par le premier circuit au troisième ; et la deuxième signature est transmise par le troisième circuit au deuxième, une partie (HSIGN(K2)) de cette deuxième 15 signature étant faussée (FHSIGN(K2)) en cas d'échec d'authentification de la première partie de la première signature par le troisième circuit.
2. Procédé selon la revendication 1, dans lequel la deuxième signature est transmise en au moins deux parties 20 (LSIGN (K2) , HSIGN (K2)) .
3. Procédé selon la revendication 1 ou 2, dans lequel la deuxième signature (SIGN(K2)) est vérifiée par parties par le deuxième dispositif (2).
4. Procédé selon l'une quelconque des revendications 1 25 à 3, dans lequel la deuxième partie de la première signature (SIGN(K1)) n'est pas transmise au troisième dispositif.
5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel : les premier et troisième circuits partagent une 30 première clé ; et les deuxième et troisième circuits partagent une deuxième clé différente de la première.
6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel plusieurs troisièmes circuits interviennentB10358 - 10-RO-094 13 dans la transmission, chaque troisième circuit partageant une clé d'authentification avec les circuits précédant et suivant, et une deuxième partie de signature destinée au circuit suivant étant faussée en l'absence d'authentification de la première partie de signature provenant du dispositif précédant.
7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel les signatures sont calculées par un algorithme AES.
8. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel la transmission entre les premier et troisième circuits s'effectue sur un bus comprenant au moins un fil de transmission des données et un fil de transmission d'un signal de synchronisation, la liaison entre les troisième et deuxième circuits étant un bus unifilaire.
9. Système de transmission entre un premier (1) et un deuxième (2) circuit par l'intermédiaire d'au moins un troisième circuit (4), dans lequel les circuits sont adaptés à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 8.
10. Système selon la revendication 9, dans lequel le premier circuit (1) est un circuit maître et le deuxième circuit (2) est un circuit esclave, le troisième circuit (4) étant un convertisseur de protocole de communication.