FR 2964214 A1 20120302 FR 1056850 A 20100830 B10444 - 10-ZV2-156 1 MISE À JOUR DE PROGRAMMES DANS UN MICROCONTRÔLEUR Domaine de l'invention La présente invention concerne de façon générale les circuits électroniques et, plus particulièrement, les circuits intégrant un microcontrôleur. L'invention s'applique plus particulièrement à l'authentification de fichiers et plus particulièrement de programmes de mise à jour reçus par un microcontrôleur. Exposé de l'art antérieur La mise à jour de programmes contenus dans un microcontrôleur pose souvent des problèmes de sécurité pour éviter le téléchargement d'applications pirates et plus généralement pour réserver la possibilité de mise à jour de programmes ou de données à des utilisateurs autorisés. Dans des domaines utilisant des microcontrôleurs pour des applications sécurisées (par exemple, des cartes à puce, des modules d'identifiants d'abonnés, des modules sécurisés gérant des droits d'accès, etc.), il est indispensable de sécuriser la mise à jour des programmes exécutés par le circuit intégré à l'aide de mécanismes authentifiant l'origine du fichier qu'il reçoit et qui contient le programme. Pour cela, on a généralement recours à des algorithmes mettant en oeuvre des mécanismes de signature, le cas échéant associés à des B10444 - 10-ZV2-156 2 mécanismes de chiffrement. Cela requiert que le produit (le circuit intégré) possède une clé lui permettant d'authentifier le fichier qu'il reçoit. Une difficulté réside dans le fait que les mises à jour des programmes sont effectuées après mise en service des produits ou après fourniture de ceux-ci par le fabricant, et par des entités différentes du fabricant du circuit. Or, ces entités souhaitent pouvoir disposer de clés qui leur sont propres de façon à ce que leurs produits leurs soient dédiés. Aujourd'hui, les clés sont enregistrées dans le circuit lors de sa fabrication. Cela requiert que le fabricant prévoit des produits spécifiques pour chaque client susceptible de mettre par la suite à jour le programme d'un lot de produits. Même si matériellement les produits sont identiques, les données qu'ils contiennent (notamment les clés) doivent être adaptées à chaque client. Cela oblige le fabriquant à effectuer une personnalisation différente pour chaque client. Résumé de l'invention Un objet d'un mode de réalisation de la présente invention est de proposer un mécanisme de personnalisation de microcontrôleur qui pallie tout ou partie des inconvénients des solutions usuelles. Un objet d'un autre mode de réalisation de la présente invention est d'éviter à un fabricant de devoir produire (personnaliser) des familles de produits différents pour la seule raison que ces produits devraient contenir des clés d'authentification différentes. Un objet d'un autre mode de réalisation de la présente invention est de proposer une solution compatible avec l'enregistrement d'une même clé d'authentification pour des produits destinés à différents utilisateurs. Pour atteindre tout ou partie de ces objets ainsi que d'autres, on prévoit un procédé de personnalisation d'au moins un circuit électronique programmable contenant une première clé transmise par une première entité, dans lequel une seconde B10444 - 10-ZV2-156 3 entité transmet au circuit au moins une information relative à une deuxième clé, dans un certificat signé par la première entité avec une troisième clé. Selon un mode de réalisation de la présente invention, la deuxième clé est une partie publique d'une paire de clés transmise par la première entité à la seconde, une partie privée de cette paire de clés représentant une quatrième clé conservée par la seconde entité pour signer des fichiers à destination du circuit. Selon un mode de réalisation de la présente invention, ladite information est la deuxième clé. Selon un mode de réalisation de la présente invention, les première et troisième clés sont identiques. Selon un mode de réalisation de la présente invention, 15 les première et troisième clés sont respectivement des parties publique et privée d'une paire de clés. Selon un mode de réalisation de la présente invention, lors de la réception du certificat par la seconde entité, la deuxième clé remplace la première dans le circuit. 20 On prévoit également un procédé de vérification d'authenticité de données par un circuit, personnalisé au moyen du procédé ci-dessus et dans lequel : à réception d'un fichier, le circuit vérifie la présence d'un certificat ; puis 25 si un certificat est présent, le circuit décode ce certificat à l'aide de sa première clé et remplace celle-ci par la deuxième clé contenue dans le certificat ; ou sinon, le circuit vérifie l'authenticité du message avec la première clé. 30 On prévoit un microcontrôleur adapté à la mise en oeuvre des procédés ci-dessus. 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 B10444 - 10-ZV2-156 4 de modes de réalisation particuliers faite à titre non-limitatif en relation avec les figures jointes parmi lesquelles : la figure 1 est un schéma bloc d'un système du type auquel s'applique à titre d'exemple la présente invention ; la figure 2 illustre les échanges entre les éléments du système de la figure 1 lors de la fabrication et de la distribution des produits ; la figure 3 illustre une authentification de fichier avant personnalisation d'un produit ; la figure 4 illustre une authentification après personnalisation ; et la figure 5 est un organigramme simplifié d'un mode de réalisation d'un procédé d'authentification. Description détaillée Par souci de clarté, de mêmes éléments ont été désignés par de mêmes références aux différentes figures. De plus, seuls les éléments et étapes utiles à la compréhension des modes de réalisation décrits ont été représentés et seront décrits. En particulier, les mécanismes de transmission n'ont 20 pas été détaillés, les modes de réalisation décrits étant compatibles avec tout procédé de transmission de fichier usuel. La figure 1 représente, de façon schématique et sous forme de blocs, un exemple d'entités d'un mode de réalisation d'un système de personnalisation. 25 On suppose que le ou les produits à personnaliser sont des microcircuits sécurisés (par exemple intégrés dans des cartes à puce ou des cartes électroniques de microordinateur). Chaque carte 1 comporte un circuit intégré 12 (généralement un microcontrôleur) susceptible de communiquer par l'intermédiaire 30 de contacts 14 ou sans contact (liaison 3) avec d'autres circuits. En fonctionnement normal, cette liaison sert à exploiter les fonctionnalités du circuit intégré. On se préoccupe ici du chargement, dans le circuit 1, des clés dédiées à un client (ou un utilisateur) et de fichiers, 35 notamment de fichiers correctifs de programmes ou de données. Le 10 15 B10444 - 10-ZV2-156 circuit intégré 14 est susceptible de communiquer avec un module de sécurité 5 (HSM - Host Security Module) du fabricant (FAB) du circuit intégré et avec des circuits de personnalisation ou de téléchargement d'un client 7 (CLT) auquel a été fourni un lot de 5 produits 1. Un des rôles du procédé de personnalisation décrit est de permettre au fabricant de livrer à plusieurs clients un produit identique (générique) à la fois du point de vue matériel et logiciel (données), et de permettre à chaque client de rendre le produit dédié à ses applications. Pour cela, il faut que tous les produits aient initialement la même clé et que chaque client puisse introduire sa ou ses clés d'authentification dans les produits. La figure 2 illustre, de façon très schématique, un 15 mode de mise en oeuvre du procédé de gestion des clés appliqué au système de la figure 1. Lors de la fabrication, le fabricant (HSM) génère une clé KROOT commune à un ensemble des produits et enregistre cette clé KROOT dans le circuit intégré CHIP de chaque produit. 20 Lorsque le fabricant fournit un lot de produits à un client (CLT), il génère une paire de clés adaptée à une crytographie asymétrique. Dans la représentation de la figure 2, on suppose un premier client CLT1 et un ième client CLTi. Le fabricant génère autant de paires de clés KipUB, KiPRIV qu'il 25 fournit de produits à des entités différentes, susceptibles de personnaliser le produit. En même temps que les clés KipUB et KipRIV, le fabricant HSM fournit à chaque client un certificat Cert(KipUB)[KROOT] de la clé publique de ce client, signé au 30 moyen de la clé générique KROOT. La figure 3 illustre le fonctionnement du système lors du chargement d'un fichier (PATCH) devant être authentifié, dans un produit CHIP, au moyen du module sécurisé HSM du fabricant, alors que ce produit est encore générique. B10444 - 10-ZV2-156 6 Le module HSM calcule une signature SIGN(PATCH)[KROOT] du fichier PATCH à télécharger dans les microcontrôleurs et transmet, à ces derniers, ce fichier ainsi que la signature. Disposant de la clé générique KROOT, les produits sont à même de vérifier VERIFY SIGN la signature avant d'exécuter le fichier reçu. La figure 4 illustre un exemple de personnalisation d'un ensemble de produits par un client CLTi. On suppose ici que la personnalisation est simultanée à l'envoi d'un premier fichier correctif PATCH. Le client génère le fichier PATCH et calcule une signature SIGN(PATCH)[KipRIV] de ce fichier à l'aide de sa clé privée KipRIV- Il télécharge, dans un ou plusieurs des produits à personnaliser, le fichier PATCH, la signature SIGN ainsi que le certificat Cert que lui a fourni le fabricant. Côté produit CHIP, celui-ci décode le certificat (DECODE Cert) à l'aide de la clé générique KROOT, de façon à extraire la clé publique KipUB contenue dans ce certificat. Cette clé KipUB remplace alors la clé KROOT dans le produit et lui sert à vérifier l'authenticité du fichier en vérifiant la signature VERIFY SIGN de celui-ci. Le remplacement de la clé générique par la clé du client KipUB est soit un remplacement matériel (écrasement de la zone mémoire stockant la clé KROOT par la clé KipUB), soit un remplacement fonctionnel en enregistrant la clé KipUB dans le produit et en mettant à jour un indicateur de la présence de cette clé. Dans les deux cas, le produit n'est plus générique. De préférence, le remplacement de la clé KROOT signifie que le fabricant n'est plus en mesure d'intervenir sur le produit une fois que celui-ci a été personnalisé par le client. En variante, la clé KROOT peut être conservée dans le produit. Le produit est alors compatible à la fois avec une mise à jour générique que seul le fabricant peut faire (les clients ne possèdent pas la clé KROOT) et avec une mise à jour que seul un client peut faire à l'aide de sa propre clé. B10444 - 10-ZV2-156 7 La figure 5 est un organigramme simplifié illustrant les opérations de vérification effectuées par un produit à la réception d'un fichier PATCH ou d'un certificat Cert. Un premier test 21 (Cert ?) consiste à vérifier la présence d'un certificat dans les données reçues. Ce certificat ne contient pas uniquement la clé KipUB, mais peut contenir des informations liées à la validité du programme de téléchargement à la manière des certificats usuels (par exemple, durée de validité, identifiant du récepteur, de l'émetteur, etc.). Si le fichier contient un certificat (sortie Y du bloc 21), le microcontrôleur vérifie alors si une clé enregistrée KipUB existe dans le produit (bloc 22, KipUB EXIST ?), c'est-à-dire si la clé KROOT a déjà été remplacée par la clé KipUB- Si ce n'est pas le cas (sortie N du bloc 22), le microcontrôleur décode le certificat (bloc 23, DECODE Cert(KipUB)[KROOT]) pour en extraire la clé KipUB. La clé KipUB est enregistrée (bloc 24, REG KipUB, REG AUTHENT POL), par exemple en écrasant la clé générique KROOT. En variante, la clé KipUB est enregistrée en plus de la clé KiROOT. Le choix entre les deux solutions correspond, par exemple, à un paramètre du certificat représentant une politique d'authentification (AUTHENTICATION POLICY). Ce paramètre et d'autres du certificat sont également mémorisés. Si le certificat n'est pas valide, la clé KipUB qui est obtenue est fausse. Si la clé KROOT a déjà été remplacée par la clé KipUB (sortie Y du bloc, 22), le certificat est décodé (bloc 23', DECODE Cert(KipUB)[KROOT]) pour extraire des informations sur une éventuelle action sur la clé K. Il s'agit (bloc 25), par exemple, de mettre à jour des paramètres associés à la clé (UPDATE KipUB PARAM) ou de révoquer la clé (REVOKE KipUB)- Puis (sorties des blocs 24 et 25), le microcontrôleur vérifie que les données reçues contiennent bien un fichier correctif (bloc 26, PATCH ?). Dans la négative (sortie N du bloc 26), cela signifie 35 que le client a simplement souhaité supprimer le caractère B10444 - 10-ZV2-156 8 générique du produit sans télécharger de fichier correctif et le programme s'arrête (STOP). Dans l'affirmative (sortie Y du bloc 26), le microcontrôleur doit vérifier la signature (bloc 27, SIGN(KVERIF) OK ?) du fichier avant de poursuivre (sortie Y du bloc 27) le processus (bloc 28, PROCESS). Si la signature est incorrecte (sortie N du bloc 27, le processus s'arrête). La vérification de la signature s'effectue avec une clé (KVERIF) qui correspond soit à la clé KipUB, soit à la clé KROOT en fonction de la politique d'authentification. En sortie Y du bloc 26, on vérifie si le produit a reçu une clé KipUB (bloc 31, KipUB EXIST ?). Si non (sortie N du bloc 31), la clé de vérification est soit la clé KipUB, soit la clé KROOT (bloc 33, 15 KVERIF = KROOT). Si oui (sortie Y du bloc 31), on vérifie d'après la politique d'authentification (bloc 32, AUTHENT POL = KipUB), si l'utilisation de la clé est obligatoire. Dans l'affirmative (sortie Y du bloc 32), la clé de vérification est la clé (bloc 20 34, KVERIF = KipUB). Sinon (sortie N du bloc 32), la clé de vérification est soit la clé KipUB, soit la clé KROOT (bloc 35, KVERIF = KiPUB OR KROOT). Dans le mode de réalisation préféré où la clé KROOT n'est plus utilisable une fois le circuit personnalisé par la 25 clé KipUB, tout fichier transmis sans certificat sera vérifié avec la clé KipUB. Si la clé KROOT est conservée pour des mises à jour par le fabricant, la clé KROOT pourra être réutilisée à chaque fois qu'un fichier sera transmis sans certificat en fonction de la politique d'authentification. 30 On voit que si le fichier ne provient pas de la bonne entité (ou d'une entité pirate), sa signature sera incorrecte et il ne sera pas exécuté. Bien que l'invention ait été plus particulièrement décrite en relation avec un téléchargement de programmes de mise 35 à jour, elle s'applique plus généralement à tout téléchargement B10444 - 10-ZV2-156 9 d'un fichier dans un produit. En sortie du bloc 27, le produit exécute le fichier qu'il a reçu que celui-ci conduise à mettre à jour des données (données proprement dites ou programmes) ou à l'inverse à extraire des données vers l'extérieur du microcontrôleur. Selon une variante de réalisation, le mécanisme est utilisé avec des niveaux de clés intermédiaires, c'est-à-dire que la clé générique KROOT est, dans un premier temps, remplacée par une clé d'un ensemble de produits pour exécuter certaines mises à jour ou phases de personnalisation, puis par une autre clé d'un sous-ensemble de produits pour d'autres mises à jour. La mise en oeuvre pratique des modes de réalisation décrits est à la portée de l'homme du métier à partir des indications fonctionnelles données ci-dessus. En particulier, le choix du type de mémoire dans lequel les clés sont stockées dépend de l'application. Le plus souvent, les différentes clés seront stockées dans des mémoires non volatiles reprogrammables (EEPROM). On notera toutefois, que la clé KROOT, notamment si elle est destinée à être conservée, pourrait être stockée en mémoire morte (ROM). De même, les mécanismes de chiffrement asymétrique utilisés sont des mécanismes usuels et les modes de réalisation décrits sont compatibles avec tout algorithme de chiffrement, tout système de certification et tout algorithme de signature. Divers modes de réalisation ont été décrits, diverses variantes et modifications apparaîtront à l'homme de l'art. En particulier, bien que les modes de réalisation décrits l'aient été en relation avec le stockage d'une seule clé, plusieurs clés pourront être générées pour un même client de façon à autoriser, par exemple, des mécanismes de répudiation de clé. Par ailleurs, les mécanismes d'authentification sont combinables avec un chiffrement des transmissions. De plus, la clé générique KROOT pourra être une clé partagée entre le fabricant et les différents produits et adaptée à un chiffrement symétrique. De préférence, cette clé B10444 - 10-ZV2-156 10 KROOT sera la partie publique d'une paire de clés pour un processus asymétrique, le fabricant signant alors le certificat de transmission des clés aux différents clients au moyen de la partie privée de cette paire de clés. Un avantage est alors que les mécanismes de chiffrement utilisés dans le produit sont tous de même nature (asymétrique). En outre, le certificat signé avec la clé générique à destination des clients peut contenir, à la place de la partie publique de la clé affectée au client, un identifiant de cette clé (une information relative à cette clé), permettant au microcontrôleur de la retrouver, en décodant le certificat, dans une table de clés stockée lors de la fabrication ou lors d'une mise à jour générique. Enfin, bien que l'on ait fait référence à un fabricant et des clients, le mécanisme décrit peut être mis en oeuvre entre toute entité souhaitant fournir des circuits électroniques programmables (ou des produits contenant de tels circuits), identiques matériellement et dans leur contenu, et d'autres entités souhaitant personnaliser ces circuits électroniques. REVENDICATIONS1. Procédé de personnalisation d'au moins un circuit électronique programmable (12) contenant une première clé (KROOT) transmise par une première entité (5), dans lequel une seconde entité (7) transmet au circuit au moins une information relative à une deuxième clé (KipUB), dans un certificat (Cert(KipUB)[KROOT]) signé par la première entité avec une troisième clé. 2. Procédé selon la revendication 1, dans lequel la deuxième clé (KipUB) est une partie publique d'une paire de clés (KipRIV, KipUB) transmise par la première entité (5) à la seconde (7), une partie privée (KipRIV) de cette paire de clés représentant une quatrième clé conservée par la seconde entité (7) pour signer des fichiers à destination du circuit (12). 3. Procédé selon la revendication 1 ou 2, dans lequel ladite information est la deuxième clé (KipUB). 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel les première et troisième clés (KROOT) sont identiques. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel les première et troisième clés sont respectivement des parties publique (KROOT) et privée d'une paire de clés. 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel, lors de la réception du certificat (Cert(KipUB)[KROOT]) par la seconde entité (7), la deuxième clé (KipUB) remplace la première (KROOT) dans le circuit (12). 7. Procédé de vérification d'authenticité de données par un circuit (12), personnalisé au moyen du procédé conforme à l'une quelconque des revendications 1 à 6, dans lequel : à réception d'un fichier, le circuit vérifie la présence d'un certificat (Cert) ; puis si un certificat est présent, le circuit décode ce certificat à l'aide de sa première clé (KROOT) et remplaceB10444 - 10-ZV2-156 12 celle-ci par la deuxième clé (KipUB) contenue dans le certificat ; ou sinon, le circuit vérifie l'authenticité du message avec la première clé. 8. Microcontrôleur adapté à la mise en oeuvre du procédé conforme à l'une quelconque des revendications précédentes.