FR3082030A1 - Carte a puce personnalisable et procede de personnalisation - Google Patents

Carte a puce personnalisable et procede de personnalisation Download PDF

Info

Publication number
FR3082030A1
FR3082030A1 FR1854874A FR1854874A FR3082030A1 FR 3082030 A1 FR3082030 A1 FR 3082030A1 FR 1854874 A FR1854874 A FR 1854874A FR 1854874 A FR1854874 A FR 1854874A FR 3082030 A1 FR3082030 A1 FR 3082030A1
Authority
FR
France
Prior art keywords
microcontroller
secure element
configuration
data
smart card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1854874A
Other languages
English (en)
Other versions
FR3082030B1 (fr
Inventor
Aissa Waknioun
Marco DE OLIVEIRA
Ludovic Martin-Martinasso
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Priority to FR1854874A priority Critical patent/FR3082030B1/fr
Priority to PCT/FR2019/051324 priority patent/WO2019234346A1/fr
Publication of FR3082030A1 publication Critical patent/FR3082030A1/fr
Application granted granted Critical
Publication of FR3082030B1 publication Critical patent/FR3082030B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/07716—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising means for customization, e.g. being arranged for personalization in batch
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card payments
    • G06Q20/3563—Software being resident on card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Storage Device Security (AREA)
  • Microcomputers (AREA)

Abstract

L'invention concerne une carte à puce personnalisable (20) comprenant : - un élément sécurisé (211) dont la configuration peut être modifiée via une interface de communication (28) avec un dispositif externe, - un microcontrôleur (221) dont la configuration peut être modifiée ; la carte à puce (20) étant caractérisée en ce que l'élément sécurisé (211) est configuré pour configurer le microcontrôleur (221).

Description

DOMAINE DE L’INVENTION
L’invention est dans le domaine des dispositifs de sécurité du type cartes à puce comprenant un élément sécurisé ainsi qu’un microcontrôleur personnalisable. Elle concerne, en particulier, une carte à puce personnalisable et un procédé de personnalisation d’une telle carte à puce.
CONTEXTE DE L’INVENTION
La présente invention concerne un dispositif de sécurité tel qu’une carte à puce, par exemple de type bancaire ou document d’identité.
Pour ce faire, la carte à puce comporte typiquement un élément sécurisé dédié au paiement sécurisé et/ou au stockage de données sensibles, par exemple des données d’identité.
L’élément sécurisé peut communiquer avec un lecteur de carte par l’intermédiaire d’une interface de communication par exemple conforme à la norme ISO 7816 (communication à contact) ou aux normes ISO14443 ou NFC/ISO 15693 (communication sans contact). Classiquement, la configuration de l’élément sécurisé se fait via cette interface de communication. II est ainsi possible de modifier les applications ou applets de l’élément sécurisé afin de le personnaliser et de faire évoluer, entre autre, la politique de sécurité de la carte à puce.
La présente invention se place dans le cas où la carte à puce comprend également un ou plusieurs microcontrôleur(s) personnalisable(s) du type microcontrôleur Bluetooth (Bluetooth est une marque) ou extracteur de données biométriques (par exemple empreinte digitale). D’autres types de microcontrôleurs peuvent être envisagés, notamment un composant de pilotage d’interface tel qu’un afficheur, une diode électroluminescente (LED) ou encore un buzzer.
De tels microcontrôleurs personnalisables permettent d’offrir des performances et fonctionnalités sur mesure aux utilisateurs de ce type de carte. La personnalisation de ces microcontrôleurs peut se faire à des moments différents : soit lors de la production du microcontrôleur, c’est-à-dire avant son installation sur la carte à puce, soit au cours de la vie de la carte.
D’un point de vue industriel, il est particulièrement coûteux et contraignant d’envisager la production différentiée de tels microcontrôleurs. De plus, dans ce cas, la configuration est généralement figée une fois que le microcontrôleur est installé sur la carte.
Par ailleurs, la personnalisation du microcontrôleur au cours de la vie de la carte à puce nécessite une adaptation des équipements de personnalisation existants. En effet, les équipements de personnalisation de cartes à puce connus sont adaptés à la communication avec l’élément sécurisé mais nécessitent des adaptations pour communiquer avec le microcontrôleur également présent sur la carte. De plus, les communications avec l’élément sécurisé et le microcontrôleur doivent alors être mises en œuvre séquentiellement pour exécuter leur personnalisation respective, de sorte que le temps de personnalisation augmente notablement.
Il existe ainsi un besoin d’améliorer la personnalisation des cartes à puce comprenant un microcontrôleur en plus de l’élément sécurisé.
RESUME DE L’INVENTION
La présente invention a ainsi pour objet de pallier au moins un de ces inconvénients.
Dans ce contexte, un premier aspect de l’invention concerne une carte à puce personnalisable comprenant :
- un élément sécurisé dont la configuration peut être modifiée via une interface de communication avec un dispositif externe,
- un microcontrôleur dont la configuration peut être modifiée ;
la carte à puce étant caractérisée en ce que l’élément sécurisé est configuré pour configurer le microcontrôleur.
Ainsi, l’élément sécurisé est configuré pour appliquer une configuration au microcontrôleur et/ou modifier la configuration actuelle/courante du microcontrôleur.
De façon générale, l’invention permet de faire évoluer les fonctionnalités de la carte à puce sans nécessiter de modification de l’équipement de personnalisation pour ce faire.
Avantageusement, elle permet notamment de contrôler et de faire évoluer la politique de sécurité de la carte à puce dans son ensemble, y compris celle du microcontrôleur qui y est installé, sans nécessiter de modification de l’équipement de personnalisation pour ce faire.
La sécurité d’une telle carte à puce est donc renforcée grâce au contrôle du microcontrôleur exercé par l’élément sécurisé.
La configuration du microcontrôleur peut consister en des paramètres, données, et/ou tout ou partie du logiciel du microcontrôleur.
La configuration du microcontrôleur permet notamment d’adapter son comportement et/ou celui du logiciel exécuté par celui-ci, notamment vis-à-vis de l’élément sécurisé et/ou d’un dispositif externe. La configuration du microcontrôleur permet également d’adapter le comportement d’interfaces de communication entre celui-ci et l’élément sécurisé, un bouton, un capteur ou autre. Enfin, la configuration du microcontrôleur permet d’adapter son comportement interne.
Corrélativement, un deuxième aspect de l’invention concerne un procédé de personnalisation d’une carte à puce comprenant :
- un élément sécurisé dont la configuration peut être modifiée via une interface de communication avec un dispositif externe;
- un microcontrôleur dont la configuration peut être modifiée ;
le procédé étant caractérisé en ce qu’il comprend la configuration, par l’élément sécurisé, du microcontrôleur.
D’autres caractéristiques de la carte à puce selon des modes de réalisation particuliers sont décrites dans les revendications dépendantes.
Dans un mode particulier de réalisation de l’invention, l’élément sécurisé est configuré pour vérifier la configuration du microcontrôleur.
Ainsi, dans des modes de réalisation, le microcontrôleur n’est autorisé à accéder à des services et/ou données de l’élément sécurisé qu’après vérification de la configuration du microcontrôleur, notamment de son intégrité par l’élément sécurisé.
Dans ces modes de réalisation, l’élément sécuriser pourrait également vérifier l’ensemble du logiciel du microcontrôleur.
Dans un mode particulier de réalisation de l’invention, le microcontrôleur est un gestionnaire de communication sans fil.
Dans des modes de réalisation, la carte à puce comprend un capteur biométrique, et le microcontrôleur est configuré pour extraire des données biométriques à partir du capteur biométrique.
Dans un mode particulier de réalisation de l’invention, la configuration du microcontrôleur définit un service de communication sans fil.
Un tel service peut être généralement défini comme une structure/collection de messages/données associée à un comportement pour accomplir une fonction particulière. Cette structure/collection est éventuellement associée à un identifiant et peut être hiérarchisée.
Dans un mode particulier de réalisation de l’invention, la configuration du microcontrôleur définit des règles relatives au routage des données par le microcontrôleur.
Par exemple, dans le cas d’une carte ayant plusieurs afficheurs, le routage pourrait consister à identifier l’afficheur sur lequel le microcontrôleur doit afficher les données reçues pour chaque application de l’élément sécurisé.
Dans un mode particulier de réalisation de l’invention, la configuration du microcontrôleur indique une donnée ou un type de données ou un service que le microcontrôleur est autorisé à obtenir de l’élément sécurisé ou d’un dispositif externe.
Par exemple, une telle configuration peut comprendre un certificat électronique contenant des indicateurs relatifs aux données que le microcontrôleur peut recevoir. Notamment, le certificat peut être signé par un tiers de confiance reconnu par l’élément sécurisé et/ou le dispositif externe qui envoie les données.
Dans un mode particulier de réalisation de l’invention, la configuration du microcontrôleur précise une durée de validité de la donnée ou du type de données, au terme de laquelle la donnée ne peut plus être utilisée par le microcontrôleur ou une durée de validité du service, au terme de laquelle le service ne peut plus être utilisé par le microcontrôleur.
De manière équivalente, une date de péremption pourrait être définie au lieu d’une durée de validité.
Cela permet d’activer un mécanisme de cache côté microcontrôleur pour des données pendant une durée déterminée et permet de limiter la sollicitation de l’élément sécurisé et donc la consommation d’énergie de la batterie, prolongeant ainsi la durée de vie de celle-ci.
II est important de noter que l’élément sécurisé contrôle la politique de sécurité de l’ensemble de la carte, même dans ce mode à économie d’énergie, puisqu’il dicte la configuration à appliquer. Ainsi, même dans le cas où l’élément sécurisé est l’esclave dans une configuration maitre-esclave avec le microcontrôleur, l’élément sécurisé dicte la politique de sécurité à appliquer pour l’ensemble des données de la carte.
Au terme de la durée de validité, le service peut être effacé de la mémoire par le microcontrôleur.
Dans un mode particulier de réalisation de l’invention, la configuration du microcontrôleur précise le mode d’écriture à utiliser par le microcontrôleur pour stocker les données ou le service. Le mode d’écriture peut être synchrone ou asynchrone.
Dans un mode particulier de réalisation de l’invention, la configuration définit des règles pour la mise en œuvre de contremesures sécuritaires par le microcontrôleur en réponse à la détection d’une attaque.
Une telle contremesure comprend par exemple l’écriture d’une donnée de blocage (ou verrou) dans une mémoire non-volatile réinscriptible du microcontrôleur.
La présence d’une donnée de blocage en mémoire empêchera tout fonctionnement ultérieur du microcontrôleur.
Une telle contremesure peut également consister par exemple en l’effacement de données ou services dont l’utilisation a été préalablement autorisée par l’élément sécurisé, bien que la durée de validité n’ait pas expiré et/ou l’inhibition du mécanisme permettant au microcontrôleur de stocker de telles données.
L’attaque détectée est par exemple une attaque non invasive au cours de laquelle la carte n’est pas modifié/altéré, une attaque semi invasives au cours de laquelle la carte est physiquement endommagée, ou encore une attaque invasive au cours de laquelle l’intégrité physique de l’élément sécurisé et/ou du microcontrôleur est altérée.
Des exemples d’évènements pouvant être considérés comme des attaques sont :
- la réception d’un signal d’un capteur de l’élément sécurisé/microcontrôleur indiquant une température anormale, une perte d’intégrité de la couche protectrice, un nombre prédéterminé d’essais successifs de code PIN erronés ;
- les attaques par injection de fautes.
Dans un mode particulier de réalisation de l’invention, l’élément sécurisé est configuré pour authentifier le microcontrôleur, la configuration du microcontrôleur ne pouvant être modifiée qu’après authentification du microcontrôleur par l’élément sécurisé.
Inversement, la configuration du microcontrôleur peut être conditionnée par l’authentification de l’élément sécurisé par le microcontrôleur.
Dans un mode particulier de réalisation de l’invention, le microcontrôleur est configuré pour appliquer une configuration modifiée par l’élément sécurisé à détection d’un évènement prédéfini.
Dans des modes de réalisation, le microcontrôleur est configuré pour solliciter (auprès de l’élément sécurisé) la modification de sa configuration. Typiquement, cette requête peut avoir lieu à détection d’un évènement prédéfini.
Dans un mode particulier de réalisation de l’invention, l’élément sécurisé est configuré pour configurer le microcontrôleur à détection d’un évènement prédéfini.
Dans des modes de réalisation, cet évènement peut être la réception d’une information de l’élément sécurisé, par exemple suite à la détection d’une attaque par l’élément sécurisé ou suite à la vérification réussie d’un code PIN par l’élément sécurisé.
Dans d’autres modes de réalisation, cet événement prédéfini peut être la réception d’une information par le microcontrôleur. Par exemple, la réception d’une donnée via Bluetooth si le microcontrôleur est un contrôleur Bluetooth, la détection d’un doigt si le microcontrôleur contrôle un capteur d’empreinte digitale, ou l’appui sur un bouton si le microcontrôleur contrôle un bouton.
Selon d’autres modes de réalisation, l’évènement peut être l’expiration d’un délai/d’une temporisation. Par exemple, cette temporisation est gérée par le microcontrôleur et démarre par exemple à partir de l’instant où la carte est alimentée (power-on).
Dans un mode particulier de réalisation de l’invention, l’élément sécurisé est configuré pour configurer le microcontrôleur à la première mise sous tension de la carte à puce suivant la fin d’une configuration initiale de l’élément sécurisé via l’interface de communication ou suivant la fin de la configuration de l’élément sécurisé via l’interface de communication.
Dans des modes de réalisation, la modification de la configuration de l’élément sécurisé comprend l’ajout d’une nouvelle application ou la mise à jour du paramétrage associé à une application ou à un groupe d’applications de l’élément sécurisé.
L’élément sécurisé peut refuser de fournir un service et/ou une donnée au microcontrôleur tant que celui-ci n’a pas demandé et/ou enregistré et/ou appliqué la configuration modifiée.
Dans un mode particulier de réalisation de l’invention, l’interface de communication est une interface de communication par contact conforme à la norme ISO 7816 ou une interface de communication sans contact conforme à la norme ISO 14443 et/ou ISO 15693.
En variante, l’interface de communication peut comprendre une liaison série de type SPI ou I2C.
Les avantages, buts et caractéristiques particulières du microcontrôleur et de l’élément sécurisé sont similaires à ceux des procédés précités qu’ils mettent en œuvre.
Dans un mode particulier de réalisation, les différentes étapes des procédés précités sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi des programmes d'ordinateur sur des supports d'information, ces programmes étant susceptibles d'être mis en œuvre par des microprocesseurs, et comprenant des instructions adaptées à la mise en œuvre des étapes des procédés tels que mentionnés ci-dessus.
Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi des supports d'information lisibles par un microprocesseur, et comprenant des instructions de programmes d'ordinateur tels que mentionnés ci-dessus.
Les supports d'information peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash.
D'autre part, les supports d'information peuvent être des supports transmissibles tels que des signaux électriques ou optiques, qui peuvent être acheminés via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur une plateforme de stockage d’un réseau de type Internet.
Alternativement, les supports d'information peuvent être des circuits intégrés dans lesquels les programmes sont incorporés, les circuits étant adaptés pour exécuter ou pour être utilisés dans l'exécution des procédés en question.
Les supports d'information et les programme d'ordinateurs précités présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en œuvre.
BREVE DESCRIPTION DES FIGURES
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures :
- La Figure 1 comprend les Figures 1a et 1b qui illustrent, de manière simplifiée, des exemples de carte à puce conformes à des modes de réalisation de la présente invention ;
- la Figure 2 représente schématiquement un exemple d’architecture possible pour une carte à puce conforme à des modes de réalisation de l’invention ;
- la Figure 3 représente, sous forme de chronogramme, des étapes de personnalisation de l’élément sécurisé de la carte à puce ;
- la Figure 4 représente, sous forme de chronogramme, des étapes d’un procédé de personnalisation de carte à puce selon un premier mode de réalisation de l’invention ;
- la Figure 5 représente, sous forme de chronogramme, des étapes d’un procédé de personnalisation de carte à puce selon un second mode de réalisation de l’invention ;
- la Figure 6 représente, sous forme de chronogramme, des étapes mises en œuvre pour la vérification de la configuration ;
- la Figure 7 représente, sous forme de chronogramme, des étapes mises en œuvre pour la vérification de la configuration par l’élément sécurisé selon une variante de la figure 6;
- la Figure 8 représente, sous forme de chronogramme, des étapes d’un routage entre l’élément sécurisé et un dispositif externe, mises en œuvre par le microcontrôleur;
- la Figure 9 illustre, sous forme de chronogramme, des étapes mises en œuvre pour l’obtention de données ou d’accès à un service de l’élément sécurisé par le microcontrôleur;
- la Figure 10 illustre, sous forme de chronogramme, des étapes mises en œuvre par le microcontrôleur pour l’obtention de données ou d’accès à un service d’un dispositif externe;
- la Figure 11 illustre, sous forme de chronogramme, des étapes mises en œuvre pour l’utilisation de données associées à une durée de validité par un dispositif externe selon un premier exemple;
- la Figure 12 illustre, sous forme de chronogramme, des étapes mises en œuvre pour l’utilisation de données associées à une durée de validité par un dispositif externe selon un deuxième exemple ;
- la Figure 13 comprend les Figures 13a et 13b qui illustrent respectivement, sous forme de chronogrammes, une écriture synchrone et une écriture asynchrone selon des modes de réalisation.
DESCRIPTION DETAILLEE DE L’INVENTION
De façon générale, l’invention concerne une carte à puce comprenant un élément sécurisé ainsi qu’un microcontrôleur, tel qu’un microcontrôleur Bluetooth (Bluetooth est une marque).
L’invention n’est pas limitée à ce mode de réalisation particulier. Notamment, elle pourrait s’appliquer à une carte à puce sans microcontrôleur
Bluetooth, par exemple avec un analyseur biométrique. D’autres types de microcontrôleurs peuvent bien entendu être envisagés. L’élément sécurisé de la carte peut être personnalisé, c’est-à-dire que sa configuration peut être modifiée, via une interface de communication avec un dispositif externe, par exemple un lecteur de carte à puce, typiquement un terminal de paiement.
Conformément à la présente invention, c’est l’élément sécurisé qui va personnaliser le microcontrôleur, c’est à dire modifier sa configuration.
Selon un mode de réalisation particulier, l’élément sécurisé va également vérifier la configuration du microcontrôleur afin de s’assurer que sa politique de sécurité est bien respectée/appliquée.
Diverses applications de l’invention sont envisagées, par exemple le routage de données de l’élément sécurisé via l’interface Bluetooth du microcontrôleur, ou encore l’authentification de données ou de services ou de dispositifs externes.
Un service peut être généralement défini comme une structure/collection de messages/données associée à un comportement pour accomplir une fonction particulière. Cette structure/collection est éventuellement associée à un identifiant et peut être hiérarchisée.
Dans la description suivante, les termes « configuration » et « personnalisation » se rapportent à la configuration d’un composant pendant la production de la carte aussi bien qu’à la configuration du composant au cours de l’utilisation de la carte.
Les termes « modifier la configuration » sont synonymes de « configurer ». Ainsi, il peut s’agir d’une configuration intervenant pendant la fabrication de la carte à puce aussi bien que d’une configuration intervenant au cours de la vie de la carte.
La Figure 1 comprend les Figures 1a et 1b qui illustrent, de manière simplifiée, des exemples de carte à puce conformes à des modes de réalisation de la présente invention.
Dans un premier exemple illustré sur la Figure 1a, la carte à puce 1 comprend un élément sécurisé 10 qui communique avec un terminal 12 via une interface de communication à contact 11 conforme au standard ISO 7816. Le terminal 12 est par exemple un lecteur de carte à puce. L’invention n’est pas limitée à ce type d’interface de communication. En variante, il pourrait s’agit d’un lien série I2C ou SPI, ou d’une interface sans contact conforme aux normes ISO14443 ou NFC/ISO 15693.
La carte à puce 1 comprend également un microcontrôleur 14 configuré pour contrôler un capteur biométrique 16. Le capteur biométrique 16 est par exemple un capteur d’empreinte digitale.
Ainsi, dans ce premier exemple, le microcontrôleur communique avec le terminal externe via le lien ISO 7816 entre l’élément sécurisé 10 et le terminal 12.
Dans un second exemple illustré sur la Figure 1b, la carte à puce T diffère de celle de l’exemple de la figure 1a en ce qu’elle comprend un microcontrôleur 14’ configuré pour contrôler une interface de communication sans fil 16’, ici conforme au standard Bluetooth (Bluetooth est une marque).
Ainsi, dans ce second exemple, le microcontrôleur peut communiquer avec le terminal externe soit via le lien ISO 7816 entre l’élément sécurisé 10 et le terminal 12 soit via l’interface de communication sans fil 16’.
La Figure 2 représente schématiquement un exemple d’architecture possible pour une carte à puce 20 conforme à des modes de réalisation de l’invention. Cette architecture peut par exemple s’appliquer à la carte 1,1’ représentée sur les figures 1a et 1b.
Cette carte à puce 20 comporte un élément sécurisé 211 et un microcontrôleur 221. L’élément sécurisé 211 comporte une unité de traitement 22 (ou microprocesseur) reliée par un bus à une mémoire vive (ou volatile) 24 et une mémoire non volatile réinscriptible 26. L’élément sécurisé peut également comporter une mémoire non volatile non réinscriptible (du type ROM par exemple).
La mémoire vive 24 est par exemple une RAM (pour Random Access Memory) comprenant des registres adaptés à l’enregistrement des variables et paramètres créés et modifiés au cours de l'exécution d’un programme informatique comprenant des instructions pour la mise en œuvre d’un procédé conforme à des modes de réalisation de l’invention, lors de la mise en œuvre de l’invention. Les codes d’instructions du programme stocké en mémoire non volatile 26 sont chargés en mémoire RAM en vue d’être exécutés par l’unité de traitement 22.
La mémoire non volatile réinscriptible 26 est par exemple une mémoire EEPROM (pour de Electrically Erasable Read Only Memory) ou encore une mémoire Flash et peut constituer un support au sens de l’invention, c’est-à-dire qu’elle peut comprendre un programme informatique comprenant des instructions pour la mise en œuvre d’un procédé conforme à des modes de réalisation de l’invention. De manière correspondante, si l’élément sécurisé comporte une mémoire non volatile non réinscriptible, celle-ci peut constituer un support au sens de l’invention.
De même, le microcontrôleur 221 comporte une unité de traitement 212 (ou microprocesseur) reliée par un bus à une mémoire vive 214 (par exemple du même type que la mémoire 24) et une mémoire non volatile réinscriptible 216 (par exemple du même type que la mémoire 26).
L’élément sécurisé 211 est relié à une interface de communication 28 avec un lecteur de carte à puce. Par exemple, l’interface de communication 28 est conforme à la norme ISO 7816 (communication à contact) ou aux normes ISO14443 ou NFC/ISO 15693 (communication sans contact). L’élément sécurisé 211 est relié au microcontrôleur 221 par une interface de communication 250. Par exemple, l’interface de communication 250 conforme à la norme ISO 7816, I2C ou SPI. Dans des modes de réalisation, les interfaces 28 et 250 ne sont qu’une seule et même interface.
Dans cet exemple, le microcontrôleur 221 est de plus relié à une interface annexe 231, par exemple une interface de communication sans fil Bluetooth ou une interface du type capteur d’empreinte, bouton, capteur de lumière, buzzer ou afficheur.
Conformément à des modes de réalisation de la présente invention, l’élément sécurisé est configuré pour configurer le microcontrôleur et/ou modifier la configuration actuelle/courante du microcontrôleur.
Dans certains modes de réalisation, une telle configuration définit un service de communication sans fil, éventuellement associé à au moins une application de l’élément sécurisé.
Par exemple, la configuration du microcontrôleur peut définir des règles relatives au routage des données par le microcontrôleur, comme décrit en référence à la figure 8.
Dans des modes de réalisation, la configuration définit un service type service « battery » définit dans la norme Bluetooth. En pratique, ce service ne concerne que les microcontrôleurs montés dans une carte avec batterie et permet au microcontrôleur d’envoyer le pourcentage de charge de la batterie interne de la carte au dispositif externe. Le microcontrôleur peut déduire cette valeur de charge via l’électronique de la carte sans nécessiter une interrogation de l’élément sécurisé (et/ou d’une de ses application).
Selon un autre exemple, la configuration définit un service « RSSI » (Received Signal Strength Indication).
Dans des modes de réalisation, la configuration du microcontrôleur peut indiquer une donnée ou type(s) de données que le microcontrôleur est autorisé à obtenir de l’élément sécurisé ou d’un dispositif externe et/ou un service que le microcontrôleur est autorisé à utiliser.
Par exemple, une telle configuration peut comprendre un certificat électronique contenant des indicateurs relatifs aux données que le microcontrôleur peut recevoir. Notamment, le certificat peut être signé par un tiers de confiance reconnu par l’élément sécurisé et/ou le dispositif externe qui envoie lesdites données.
La configuration du microcontrôleur peut notamment préciser une durée de validité de la donnée ou du type de données, au terme de laquelle la donnée ne peut plus être utilisée par le microcontrôleur ou une durée de validité du service, au terme de laquelle celui-ci ne peut plus être utilisé par le microcontrôleur.
La configuration du microcontrôleur peut également préciser le mode d’écriture (par exemple synchrone ou asynchrone) à utiliser par le microcontrôleur pour stocker des données ou un service.
La configuration peut définir des règles pour la mise en œuvre de contremesures sécuritaires par le microcontrôleur en réponse à la détection d’une attaque. Des exemples d’évènements pouvant être considérés comme des attaques sont la réception d’un signal d’un capteur de l’élément sécurisé/microcontrôleur indiquant une température anormale, une perte d’intégrité de la couche protectrice, ou encore un nombre prédéterminé d’essais successifs de code PIN erronés. Les règles définies sont par exemple l’effacement des données mémorisées dans le microcontrôleur (même si elles sont valides eu égard à leur durée de validité) ou encore l’écriture d’une donnée de blocage dans une zone de mémoire dédiée ou non.
La Figure 3 représente, sous forme de chronogramme, des étapes de personnalisation de l’élément sécurisé de la carte à puce. Ces étapes sont mises en œuvre préalablement au procédé selon l’invention, dont des exemples de modes de réalisation seront décrits en référence aux prochaines figures.
Au cours d’une première étape E300, la carte à puce est allumée (Power On). En pratique, un dispositif externe, typiquement un lecteur de carte à puce, peut alimenter la carte à puce. En variante, la carte à puce comprend une batterie interne qui permet d’alimenter ses composants.
Au cours d’une étape E310, le dispositif externe et l’élément sécurisé établissent une communication pour échanger des données via l’interface 28 représentée sur la figure 2.
Au cours d’une étape E320, l’élément sécurisé authentifie le dispositif externe. Par exemple cette étape comprend la génération d’un challenge CH 1 par l’élément sécurisé puis sa transmission au dispositif externe et la réception d’une réponse au challenge, par exemple sous la forme d’une signature S1. L’élément sécurisé vérifie ensuite la validité de cette signature.
En variante, l’étape E320 pourrait comprendre une authentification mutuelle.
Au cours d’une étape E330, le dispositif externe transmet une configuration à l’élément sécurisé. Il peut s’agir d’une configuration initiale ou bien d’une nouvelle configuration venant modifier/remplacer la configuration existante.
Au cours d’une étape E340, l’élément sécurisé enregistre/charge la configuration reçue à l’étape E330. En pratique, au cours d’une étape E350, l’élément sécurisé modifie un indicateur indiquant que la configuration a bien été modifiée/chargée.
Au cours de l’étape E360, la carte à puce s’éteint (Power OFF). Dans des modes de réalisation, des étapes supplémentaires, par exemple certaines étapes décrites en référence aux figures 4, 5, 6, 7, sont mises en œuvre avant cette étape E360. Autrement dit, il n’y a pas nécessairement de redémarrage de la carte entre la mise en œuvre de ces étapes.
La Figure 4 représente, sous forme de chronogramme, des étapes d’un procédé de personnalisation de carte à puce selon un premier mode de réalisation de l’invention.
Dans cet exemple, l’élément sécurisé et le microcontrôleur sont dans une configuration maître-esclave dans laquelle l’élément sécurisé joue le rôle d’esclave et le microcontrôleur celui de maître.
Au cours d’une étape E400, l’élément sécurisé et le microcontrôleur s’authentifient mutuellement. Cette authentification est ici à l’initiative du microcontrôleur car il joue le rôle du maître et l’élément sécurisé celui de l’esclave. En variante, seul le microcontrôleur ou seul l’élément sécurisé pourrait s’authentifier.
A détection d’un évènement (étape E410), le microcontrôleur interroge l’élément sécurisé afin de savoir si sa configuration doit être modifiée.
Dans des modes de réalisation, cet événement prédéfini peut être la réception d’une information par le microcontrôleur. Par exemple, la réception d’une donnée via Bluetooth si le microcontrôleur est un contrôleur Bluetooth, la détection d’un doigt si le microcontrôleur est connecté à un capteur d’empreinte digitale, ou l’appui sur un bouton si le microcontrôleur est connecté à un bouton.
Selon d’autres modes de réalisation, l’évènement peut être l’expiration d’un délai/d’une temporisation. Par exemple, cette temporisation est gérée par le microcontrôleur et démarre par exemple à partir de l’instant où la carte est alimentée (power ON).
En variante, l’étape d’authentification E400 peut être mise en œuvre après la détection de l’évènement (étape E410).
Au cours d’une étape E420, l’élément sécurisé vérifie si la configuration du microcontrôleur doit être modifiée puis renvoie la réponse au microcontrôleur. Cela peut se faire, par exemple, par vérification de l’état de l’indicateur mentionné à l’étape E350 de la figure 3.
Au cours d’une étape E430, si sa configuration doit être modifiée, le microcontrôleur demande à l’élément sécurisé qu’il lui envoie la configuration modifiée.
Au cours d’une étape E440, l’élément sécurisé envoie la configuration modifiée au microcontrôleur.
Au cours d’une étape E450, la configuration reçue est enregistrée et appliquée par le microcontrôleur.
Au cours d’une étape E460, le microcontrôleur informe l’élément sécurisé du bon déroulement de la configuration (statut ok).
Au cours d’une étape E470, l’élément sécurisé accuse bonne réception de cette information.
En variante, l’application de la configuration reçue de l’élément sécurisé à l’étape E440 peut être différée, par exemple jusqu’à ce que le microcontrôleur détecte un évènement particulier. L’évènement particulier peut être par exemple le prochain allumage (Power ON) de la carte. En variante, cet évènement peut être la réception d’une information indiquant le début d’une transaction bancaire dans un distributeur de billets. Ceci permettrait par exemple d’assurer que la carte ne sera pas arrachée de l’alimentation avant la fin de l’enregistrement de la configuration modifiée par le microcontrôleur, empêchant ainsi la corruption de la configuration modifiée.
Cette variante présente l’avantage d’éviter notamment un problème de cohérence et de corruption de données qui pourrait survenir au cours de l’utilisation de la carte à puce si la configuration du microcontrôleur est modifiée trop longtemps après l’allumage de la carte. Cela pourrait par exemple être le cas si la transmission de la configuration par l’élément sécurisé à l’étape E440 et/ou son enregistrement par le microcontrôleur (étape E450) sont longs. En effet, dans un tel cas il y a un risque que l’alimentation de la carte soit interrompue, interrompant ainsi la configuration en cours du microcontrôleur par l’élément sécurisé.
La Figure 5 représente, sous forme de chronogramme, des étapes d’un procédé de personnalisation de carte à puce selon un second mode de réalisation de l’invention.
Dans cet exemple, l’élément sécurisé et le microcontrôleur sont dans une configuration maître-esclave dans laquelle l’élément sécurisé joue le rôle de maître et le microcontrôleur celui d’esclave.
Au cours d’une étape E500, l’élément sécurisé et le microcontrôleur s’authentifient mutuellement. Cette authentification est ici à l’initiative de l’élément sécurisé car il joue le rôle du maître et le microcontrôleur celui de l’esclave. En variante, seul le microcontrôleur ou seul l’élément sécurisé pourrait s’authentifier.
Au cours d’une étape E520 similaire à l’étape E420, l’élément sécurisé vérifie si la configuration du microcontrôleur doit être modifiée puis renvoie la réponse au microcontrôleur.
L’étape E520 peut être mise en œuvre régulièrement ou bien à détection d’un évènement prédéfini. Par exemple, cet événement prédéfini peut être la réception d’un statut particulier du microcontrôleur par l’élément sécurisé. Par exemple, ce statut peut indiquer la réception d’une donnée via Bluetooth si le microcontrôleur est un contrôleur Bluetooth, la détection d’un doigt si le microcontrôleur est associé à un capteur d’empreinte digitale, ou l’appui sur un bouton si le microcontrôleur est connecté à un bouton.
Selon d’autres modes de réalisation, l’évènement peut être l’expiration d’un délai/d’une temporisation. Par exemple, cette temporisation est gérée par l’élément sécurisé et démarre par exemple à partir de l’instant où la carte est alimentée (power ON).
Au cours d’une étape E540 similaire à l’étape E440, si la configuration doit être modifiée, l’élément sécurisé envoie la configuration modifiée au microcontrôleur.
Au cours d’une étape E550 similaire à l’étape E450, la configuration reçue est enregistrée et appliquée par le microcontrôleur.
Au cours d’une étape E560 similaire à l’étape E460, le microcontrôleur informe l’élément sécurisé du bon déroulement de la configuration (statut ok).
La Figure 6 représente, sous forme de chronogramme, des étapes mises en œuvre pour la vérification de la configuration du microcontrôleur par l’élément sécurisé. Ces étapes font par exemple suite à l’installation d’une nouvelle configuration du microcontrôleur sous le contrôle de l’élément sécurisé. En variante, elles peuvent être mises en œuvre au démarrage de la carte (power ON). En effet, l’accès aux données et services de l’élément sécurisé depuis un dispositif externe et/ou depuis le microcontrôleur peut être conditionné au bon déroulement de ces étapes.
Dans cet exemple, l’élément sécurisé et le microcontrôleur sont dans une configuration maître-esclave dans laquelle l’élément sécurisé joue le rôle d’esclave et le microcontrôleur celui de maître.
Au cours d’une étape E600 similaire à l’étape E400, l’élément sécurisé et le microcontrôleur s’authentifient mutuellement. Cette authentification est ici à l’initiative du microcontrôleur car il joue le rôle du maître et l’élément sécurisé celui de l’esclave. En variante, seul le microcontrôleur ou seul l’élément sécurisé pourrait s’authentifier.
Au cours d’une étape E610, le microcontrôleur interroge l’élément sécurisé. Cette étape est nécessaire dans la mesure où l’élément sécurisé joue le rôle d’esclave. Dans cet exemple, cette interrogation prend la forme d’une demande d’accès à un service ou une donnée à l’élément sécurisé. Toutefois, l’invention n’est pas limitée à ce type d’interrogation.
Par exemple, l’étape E610 pourrait consister en l’envoi d’une donnée ou d’un challenge par le microcontrôleur à l’élément sécurisé. En variante, l’étape E610 pourrait comprendre l’envoi d’une commande dédiée au déclenchement du procédé de vérification.
Au cours d’une étape E620, l’élément sécurisé informe le microcontrôleur qu’une vérification de sa configuration est nécessaire, ici pour déterminer si l’accès demandé est accordé ou non. Pour ce faire, il demande au microcontrôleur de lui envoyer sa configuration actuelle ou tout autre donnée lui permettant de vérifier son intégrité. Il s’agit par exemple d’un hash ou d’une signature de la configuration pouvant comprendre la réponse à un challenge préalablement reçu de l’élément sécurisé.
En réponse, le microcontrôleur transmet sa configuration actuelle ou la donnée demandée (étape E630) à l’élément sécurisé qui vérifie (étape E640) si le microcontrôleur a la bonne configuration.
La vérification peut être une comparaison de la configuration reçue à l’étape E630 avec celle stockée dans la mémoire de l’élément sécurisé. Le résultat de la comparaison est alors un statut indiquant si la configuration reçue est identique à celle stockée dans l’élément sécurisé. Selon un mode d’implémentation alternatif cette vérification peut consister à comparer le hash ou signature reçu à l’étape E630 avec un hash ou une signature de référence stocké dans l’élément sécurisé ou calculé par l’élément sécurisé à partir de la configuration stockée dans celui-ci (et éventuellement du challenge qu’il a envoyé au microcontrôleur).
Dans cet exemple, si le microcontrôleur a effectivement la bonne configuration, l’élément sécurisé peut déterminer si selon la configuration, il est autorisé à obtenir la donnée requise ou à accéder au service demandé.
A cet effet, la configuration reçue à l’étape E630 peut indiquer des données ou type(s) de données que le microcontrôleur est autorisé à obtenir de l’élément sécurisé ainsi que les services que le microcontrôleur est autorisé à utiliser.
Par exemple, une telle configuration peut comprendre un certificat électronique contenant des indicateurs relatifs aux données que le microcontrôleur peut recevoir. Notamment, le certificat peut être signé par un tiers de confiance reconnu par l’élément sécurisé.
Optionnellement, un challenge peut être soumis au microcontrôleur à l’étape E620 qui y répond à l’étape E630. En variante ou en combinaison, le microcontrôleur peut également envoyer une signature de la configuration.
Au cours d’une étape E650, l’élément sécurisé renvoie sa réponse au microcontrôleur en fonction du résultat de la vérification de l’étape E640. Cette réponse consiste ainsi à dire si la configuration du microcontrôleur est à jour et/ou intègre, ou non. Elle peut également autoriser l’accès au service ou à la donnée demandé(e) à l’étape E610, ou l’interdire. Dans le cas où la configuration n’est pas à jour et/ou intègre, l’élément sécurisé peut décider de la mettre à jour.
Selon un mode de réalisation alternatif, l’étape E610 est remplacée par une demande de challenge à l’élément sécurisé et l’étape E620 comprend en outre l’envoi de ce challenge au microcontrôleur. L’étape E630 comprend alors l’envoi d’une réponse au challenge à l’élément sécurisé avec la configuration.
La Figure 7 représente, sous forme de chronogramme, des étapes mises en œuvre pour la vérification de la configuration par l’élément sécurisé selon une variante de la figure 6. Ces étapes font par exemple suite à l’installation d’une nouvelle configuration du microcontrôleur sous le contrôle de l’élément sécurisé. En variante, elles peuvent être mises en œuvre au démarrage de la carte (power ON). En effet, l’accès aux données et services de l’élément sécurisé depuis un dispositif externe et/ou depuis le microcontrôleur peut être conditionné au bon déroulement de ces étapes.
Dans cet exemple, l’élément sécurisé et le microcontrôleur sont dans une configuration maître-esclave dans laquelle l’élément sécurisé joue le rôle de maître et le microcontrôleur celui d’esclave.
Au cours d’une étape E700 similaire à l’étape E500, l’élément sécurisé et le microcontrôleur s’authentifient mutuellement. Cette authentification est ici à l’initiative de l’élément sécurisé car il joue le rôle du maître et le microcontrôleur celui de l’esclave. En variante, seul le microcontrôleur ou seul l’élément sécurisé pourrait s’authentifier.
Au cours d’une étape E720 similaire à l’étape E620, l’élément sécurisé demande au microcontrôleur de lui envoyer sa configuration actuelle ou tout autre donnée lui permettant de vérifier son intégrité. Il s’agit par exemple d’un hash ou d’une signature de la configuration pouvant comprendre la réponse à un challenge préalablement reçu de l’élément sécurisé, afin de la vérifier.
En réponse, le microcontrôleur transmet sa configuration actuelle ou cette autre donnée (étape E730) à l’élément sécurisé qui la vérifie (étape E740).
La vérification peut être une comparaison de la configuration reçue à l’étape E730 avec celle stockée dans la mémoire de l’élément sécurisé. Le résultat de la comparaison est alors un statut indiquant si la configuration reçue est identique à celle stockée dans l’élément sécurisé. Selon un mode d’implémentation alternatif cette vérification peut consister à comparer le hash ou signature reçu à l’étape E730 avec un hash ou une signature de référence stocké dans l’élément sécurisé ou calculé par l’élément sécurisé à partir de la configuration stockée dans celui-ci (et éventuellement le challenge qu’il a envoyé au microcontrôleur).
Au cours d’une étape E750, l’élément sécurisé envoie le résultat de la vérification au microcontrôleur en fonction de l’étape E740. Cette réponse consiste ainsi à dire si la configuration du microcontrôleur est à jour et/ou intègre, ou non. Dans le cas où la configuration n’est pas à jour et/ou intègre, l’élément sécurisé peut décider de la mettre à jour.
Au cours d’une étape E760, le microcontrôleur accuse réception de cette information et/ou demande l’accès à un service ou une donnée de l’élément sécurisé.
La Figure 8 représente, sous forme de chronogramme, des étapes d’un routage entre l’élément sécurisé et un dispositif externe, mises en œuvre par le microcontrôleur.
Dans cet exemple, l’élément sécurisé et le microcontrôleur sont dans une configuration maître-esclave dans laquelle l’élément sécurisé joue le rôle d’esclave et le microcontrôleur celui de maître.
Dans cet exemple, la configuration consiste en une table de routage qui établit une correspondance entre des applications de l’élément sécurisé (App1, App2) et les services (Service 1, Service 2, Service 3) proposés et/ou supportés par le microcontrôleur sur l’interface annexe 231.
A titre d’illustration, la table de routage peut être par exemple figurée comme suit :
App1 Service 1 Sortie
App2 Service 2 Entrée
App1 Service 3 Entrée
Les indicateurs « entrée » et « sortie » permettent au microcontrôleur de connaître le sens de transit associé à chaque paire application/service. Ainsi quand le microcontrôleur reçoit des données du dispositif externe via un service, il peut rechercher l’application associée au service parmi les couples application/service associés à l’indicateur « Entrée ». Quand le microcontrôleur reçoit des données de l’élément sécurisé, il peut rechercher le service à utiliser pour transmettre la donnée au dispositif externe parmi les couples application/service associés à l’indicateur « Sortie ».
Au cours d’une étape E800, le dispositif externe envoie un service « Service 3 », c’est-à-dire une structure de données particulière « Service 3 », comprenant par exemple un code PIN, au microcontrôleur de la carte. Ceci peut faire suite à la saisie du code PIN par un utilisateur sur le dispositif externe. La réception peut se faire en Bluetooth sur l’interface annexe 231.
Au cours d’une étape E805, le microcontrôleur effectue un routage.
En pratique, au cours de cette étape, le service reçu à l’étape E800 est identifié, puis le microcontrôleur recherche l’application de l’élément sécurisé qui est associée à ce service dans sa table de routage (i.e. sa configuration), c'est-à-dire l’application à laquelle le microcontrôleur doit faire suivre tout ou partie des données contenues dans le service. Dans le cas présent, le microcontrôleur conclut à l’étape E805 qu’il doit envoyer la donnée reçue via le service 3 (le PIN) à l’application « App 1 » de l’élément sécurisé.
Au cours d’une étape E810, le microcontrôleur envoie une commande de sélection d'une application App1 de l’élément sécurisé. Par exemple, cette application permet de vérifier un code PIN.
Au cours d’une étape E815, l’élément sécurisé sélectionne son application App1 et en informe le microcontrôleur au cours d’une étape E820.
Au cours d’une étape E825, le microcontrôleur envoie le code PIN reçu à l’étape E800 à l’élément sécurisé.
Au cours d’une étape E830, l’élément sécurisé traite le code PIN à l’aide de l’application App1.
Au cours d’une étape E835, l’élément sécurisé renvoie un challenge au microcontrôleur afin de faire une vérification supplémentaire.
Au cours d’une étape E840, le microcontrôleur met en œuvre une opération de routage. En pratique, au cours de cette étape, le microcontrôleur recherche le service à utiliser pour faire suivre la donnée reçue à l’étape E835 au dispositif externe dans sa table de routage (i.e. sa configuration). Dans le cas présent, le microcontrôleur conclut à l’étape E840 qu’il doit envoyer la donnée reçue dans l’étape E835 (le challenge) via le « Service 1 » au dispositif externe.
Au cours d’une étape E845, le microcontrôleur envoie le challenge au dispositif externe via le service « Service 1 », c’est-à-dire en utilisant une structure de donnée avec éventuellement un identifiant associé, identifié lors de l’étape de routage E840.
Dans l’exemple présent, le challenge est envoyé au dispositif externe via le service 1.
Au cours d’une étape E850, le dispositif externe répond au challenge auprès du microcontrôleur via le service « Service 2 ».
Au cours d’une étape E855, le microcontrôleur met en œuvre une opération de routage. En pratique, au cours de cette étape, le microcontrôleur identifie le service reçu à l’étape E850, puis recherche l’application de l’élément sécurisé qui est associé à ce service dans la table de routage (i.e. sa configuration), c'est-à-dire l’application à laquelle le microcontrôleur doit faire suivre tout ou partie des données contenues dans le service. Dans le cas présent, le microcontrôleur conclut à l’étape E855 qu’il doit envoyer la donnée reçue via le « Service 2 » (la réponse au challenge) à l’App2 de l’élément sécurisé.
Au cours d’une étape E860, le microcontrôleur envoie une commande de sélection d'une application App2 de l’élément sécurisé. Par exemple, cette application permet de vérifier la réponse apportée au challenge.
Au cours d’une étape E865, l’élément sécurisé sélectionne son application App2 et en informe le microcontrôleur au cours d’une étape E870.
Au cours d’une étape E875, le microcontrôleur envoie la réponse au challenge reçue à l’étape E850 à l’élément sécurisé.
Au cours d’une étape E880, l’élément sécurisé traite cette réponse à l’aide de l’application App2.
Au cours d’une étape E885, l’élément sécurisé renvoie le résultat au microcontrôleur.
La Figure 9 illustre, sous forme de chronogramme, des étapes mises en œuvre pour l’obtention de données ou l’accès à un service de l’élément sécurisé par le microcontrôleur. Ces étapes peuvent faire suite à l’installation d’une nouvelle configuration du microcontrôleur sous le contrôle de l’élément sécurisé.
Dans cet exemple, la configuration du microcontrôleur prend la forme d’un certificat électronique. Ce certificat comprend une liste des données et services que le microcontrôleur est autorisé à accéder auprès de l’élément sécurisé. De plus, le certificat comprend une signature générée à partir de cette liste et d’une clé privée PRK_AUT délivrée par une autorité de confiance. L’élément sécurisé possède la clé publique PUK_AUT associée à la clé privée PRK_AUT. Cette clé publique peut avoir été installée dans sa mémoire au moment de sa personnalisation (voir Figure 3).
Au cours d’une étape E900, le microcontrôleur envoie son certificat à l’élément sécurisé.
Au cours d’une étape E910, l’élément sécurisé vérifie la signature du certificat à l’aide de sa clé publique PUK_AUT associée à la clé privée PRK_AUT.
Au cours d’une étape E920, l’élément sécurisé envoie le résultat de la vérification au microcontrôleur. On suppose pour les prochaines étapes que la signature a bien été authentifiée.
Au cours d’une étape E930, le microcontrôleur demande l’accès à un service ou une donnée de l’élément sécurisé.
Cette demande peut faire suite à une demande de cette donnée ou de ce service par le dispositif externe au microcontrôleur.
Au cours d’une étape E940, l’élément sécurisé parcourt la liste de données/services dont l’accès est autorisé par le certificat reçu à l’étape E900.
Au cours d’une étape E950, si le service ou la donnée demandé(e) est autorisé(e) dans la liste, et sous réserve que la signature ait bien été authentifiée à l’étape E910, l’élément sécurisé donne accès au service ou à la donnée demandé(e).
La Figure 10 illustre, sous forme de chronogramme, des étapes mises en œuvre par le microcontrôleur pour l’obtention de données ou d’accès à un service d’un dispositif externe. Ces étapes peuvent faire suite à l’installation d’une nouvelle configuration du microcontrôleur sous le contrôle de l’élément sécurisé.
Dans cet exemple, la configuration du microcontrôleur prend également la forme d’un certificat électronique. Ce certificat comprend une liste des données et services que le microcontrôleur est autorisé à accéder auprès du dispositif externe. De plus, le certificat comprend une signature générée à partir de cette liste et d’une clé privée PRK_AUT délivrée par une autorité de confiance. Le dispositif externe possède la clé publique PUK_AUT associée à la clé privée PRK_AUT.
Au cours d’une étape E1000, le microcontrôleur envoie son certificat au dispositif externe, par exemple via l’interface annexe 231. On rappelle que cette interface est par exemple une interface de communication sans fil Bluetooth.
Au cours d’une étape E1010, le dispositif externe vérifie la signature du certificat à l’aide de sa clé publique PUK_AUT associée à la clé privée PRK_AUT.
Au cours d’une étape E1020, le dispositif externe envoie le résultat de la vérification au microcontrôleur. On suppose pour les prochaines étapes que la signature a bien été authentifiée.
Au cours d’une étape E1030, le microcontrôleur demande l’accès à un service ou une donnée du dispositif externe.
Cette demande peut faire suite à une demande de cette donnée ou de ce service par l’élément sécurisé au microcontrôleur.
Au cours d’une étape E1040, le dispositif externe parcourt la liste de données/services dont l’accès est autorisé par le certificat reçu à l’étape E1000.
Au cours d’une étape E1050, si le service ou la donnée demandé(e) est autorisé(e) dans la liste, et sous réserve que la signature ait bien été authentifiée à l’étape E1010, le dispositif externe donne accès au service ou à la donnée demandé(e).
La Figure 11 illustre, sous forme de chronogramme, des étapes mises en œuvre pour l’utilisation de données associées à une durée de validité par un dispositif externe selon un premier exemple.
Dans cet exemple, la configuration du microcontrôleur précise la durée de validité des données / type(s) de données ou de l’accès à un service, au terme de laquelle les données / le service ne peuvent plus être accédées par le microcontrôleur.
La référence de temps peut provenir d’une horloge interne de la carte à puce. Elle peut par exemple être interne à l’élément sécurisé ou au microcontrôleur. En variante, elle peut être reçue d’un dispositif externe, par exemple via l’interface de communication 28 avec la carte à puce ou encore via l’interface annexe 231.
En variante, la référence de temps peut être un compteur d’un ou plusieurs évènements prédéterminés, par exemple : nombre d’appuis sur un bouton, nombre de power ON, nombre de transactions bancaires réalisées avec succès, ou nombre d’utilisations d’un service.
Au cours d’une étape E1100, le dispositif externe envoie une donnée D au microcontrôleur qui l’enregistre dans sa mémoire au cours d’une étape E1120.
Au cours d’une étape E1130, le microcontrôleur informe le dispositif externe de la bonne réception et de l’enregistrement de la donnée D.
Au cours d’une étape E1140, qui peut intervenir plus tard, par exemple après un rallumage de la carte à puce, le microcontrôleur demande l’accès à un service à l’élément sécurisé.
Au cours d’une étape E1150, l’élément sécurisé requiert l’envoi de la donnée D afin de vérifier si l’accès au service peut être accordé.
Au cours d’une étape E1160, le microcontrôleur vérifie sa configuration afin de déterminer si la donnée D est toujours valide. Si tel est le cas, il l’envoie à l’élément sécurisé au cours d’une étape E1170. On suppose ici que c’est le cas. Sinon, la donnée D n’est pas envoyée à l’élément sécurisé et l’accès au service demandé n’est donc pas accordé.
On notera que l’action réalisée par le microcontrôleur, quand la donnée n’est plus valide, peut dépendre de la configuration du microcontrôleur. Ainsi ladite configuration peut comprendre un ou plusieurs indicateurs à cet effet.
Des exemples d’actions possibles sont :
- (cas illustré) la donnée D n’est pas envoyée à l’élément sécurisé et l’accès au service demandé n’est donc pas accordé ;
- le microcontrôleur supprime la donnée D de sa mémoire non volatile ;
- le microcontrôleur demande au dispositif externe une nouvelle donnée D.
Au cours d’une étape E1180, l’élément sécurisé autorise l’accès au service car il a bien reçu la donnée D qui est encore valide.
La Figure 12 illustre, sous forme de chronogramme, des étapes mises en œuvre pour l’utilisation de données associées à une durée de validité par un dispositif externe selon un deuxième exemple.
Au cours d’une étape E1200, le dispositif externe demande une donnée E au microcontrôleur qui vérifie s’il l’a dans sa mémoire au cours d’une étape E1210.
Si ce n’est pas le cas, le microcontrôleur demande la donnée E à l’élément sécurisé au cours d’une étape E1230.
Au cours d’une étape E1240, l’élément sécurisé renvoie la donnée E au microcontrôleur.
Au cours d’une étape E1250, le microcontrôleur vérifie que sa configuration l’autorise à mémoriser la donnée E et si oui, il la stocke.
Au cours d’une étape E1260, le microcontrôleur envoie la donnée E demandée au dispositif externe.
Au cours d’une étape E1270, qui peut intervenir plus tard, par exemple après un rallumage de la carte à puce, le dispositif externe demande de nouveau la donnée E au microcontrôleur.
Au cours d’une étape E1280, le microcontrôleur vérifie si la donnée E en mémoire est toujours valide et si oui, il la renvoie au dispositif externe à l’étape E1290. Sinon il efface la donnée E de sa mémoire à l’étape E1295 et les étapes E1230, E1240, E1250 et E1260 sont remises en œuvre.
La Figure 13 comprend les Figures 13a et 13b qui illustrent respectivement, sous forme de chronogrammes, une écriture synchrone et une écriture asynchrone selon des modes de réalisation.
Dans des modes de réalisation, la configuration du microcontrôleur précise le mode d’écriture (par exemple synchrone ou asynchrone) à utiliser pour stocker une donnée ou un service.
La Figure 13a illustre le principe d’une écriture synchrone.
Au cours d’une étape E1300, le dispositif externe demande au microcontrôleur d’écrire la donnée A ce qu’il fait aux étapes E1310 et E1320 sous le contrôle de l’élément sécurisé. Le microcontrôleur répond ensuite au dispositif externe (étape E1330).
Ainsi, l’écriture est synchrone car le microcontrôleur ne répond qu’une fois celle-ci effectuée.
La Figure 13b illustre le principe d’une écriture asynchrone.
Dans ce cas, le microcontrôleur répond au dispositif externe (étape E1305) avant que l’écriture ne soit effectivement effectuée. II peut, optionnellement, également envoyer un message au dispositif externe une fois l’écriture terminée (étape E1330 optionnelle).
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims (15)

  1. REVENDICATIONS
    1. Carte à puce personnalisable (1,1’,20) comprenant :
    - un élément sécurisé (10,211) dont la configuration peut être modifiée via une interface de communication (11,28) avec un dispositif externe,
    - un microcontrôleur (14,14’,221) dont la configuration peut être modifiée ;
    la carte à puce (1,1’,20) étant caractérisée en ce que l’élément sécurisé (10,211) est configuré pour configurer le microcontrôleur (14,14’,221).
  2. 2. Carte à puce selon la revendication 1, dans laquelle l’élément sécurisé est configuré pour vérifier la configuration du microcontrôleur.
  3. 3. Carte à puce selon la revendication 1 ou 2, dans laquelle le microcontrôleur est un gestionnaire de communication sans fil.
  4. 4. Carte à puce selon la revendication 3, dans laquelle la configuration du microcontrôleur définit un service de communication sans fil.
  5. 5. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle la configuration du microcontrôleur définit des règles relatives au routage des données par le microcontrôleur.
  6. 6. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle la configuration du microcontrôleur indique une donnée ou un type de données ou un service que le microcontrôleur est autorisé à obtenir de l’élément sécurisé ou d’un dispositif externe.
  7. 7. Carte à puce selon la revendication 6, dans laquelle la configuration du microcontrôleur précise une durée de validité de ladite donnée ou dudit type de données, au terme de laquelle la donnée ne peut plus être utilisée par le microcontrôleur ou une durée de validité dudit service, au terme de laquelle ledit service ne peut plus être utilisé par le microcontrôleur.
  8. 8. Carte à puce selon la revendication 6 ou 7, dans laquelle la configuration du microcontrôleur précise le mode d’écriture à utiliser par le microcontrôleur pour stocker lesdites données ou ledit service.
  9. 9. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle la configuration définit des règles pour la mise en œuvre de contremesures sécuritaires par le microcontrôleur en réponse à la détection d’une attaque.
  10. 10. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle l’élément sécurisé est configuré pour authentifier le microcontrôleur, la configuration dudit microcontrôleur ne pouvant être modifiée qu’après authentification du microcontrôleur par l’élément sécurisé.
  11. 11. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle le microcontrôleur est configuré pour appliquer une configuration modifiée par l’élément sécurisé à détection d’un évènement prédéfini.
  12. 12. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle l’élément sécurisé est configuré pour configurer le microcontrôleur à détection d’un évènement prédéfini.
  13. 13. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle l’élément sécurisé est configuré pour configurer le microcontrôleur à la première mise sous tension de la carte à puce suivant la fin d’une configuration initiale de l’élément sécurisé via l’interface de communication ou suivant la fin de la configuration de l’élément sécurisé via l’interface de communication.
  14. 14. Carte à puce selon l’une quelconque des revendications précédentes, dans laquelle l’interface de communication est une interface de communication par contact conforme à la norme ISO 7816 ou une interface de communication sans contact conforme à la norme ISO 14443 et/ou ISO 15693.
  15. 15. Procédé de personnalisation d’une carte à puce comprenant :
    - un élément sécurisé dont la configuration peut être modifiée via une interface de communication avec un dispositif externe;
    - un microcontrôleur dont la configuration peut être modifiée ;
    le procédé étant caractérisé en ce qu’il comprend la configuration, par l’élément sécurisé, du microcontrôleur.
FR1854874A 2018-06-05 2018-06-05 Carte a puce personnalisable et procede de personnalisation Active FR3082030B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1854874A FR3082030B1 (fr) 2018-06-05 2018-06-05 Carte a puce personnalisable et procede de personnalisation
PCT/FR2019/051324 WO2019234346A1 (fr) 2018-06-05 2019-06-04 Carte a puce personnalisable de façon securisée et procede de personnalisation securisé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1854874 2018-06-05
FR1854874A FR3082030B1 (fr) 2018-06-05 2018-06-05 Carte a puce personnalisable et procede de personnalisation

Publications (2)

Publication Number Publication Date
FR3082030A1 true FR3082030A1 (fr) 2019-12-06
FR3082030B1 FR3082030B1 (fr) 2021-04-23

Family

ID=65951611

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1854874A Active FR3082030B1 (fr) 2018-06-05 2018-06-05 Carte a puce personnalisable et procede de personnalisation

Country Status (2)

Country Link
FR (1) FR3082030B1 (fr)
WO (1) WO2019234346A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2797074A1 (fr) * 1999-07-28 2001-02-02 Gemplus Card Int Architecture de carte a puce integrant des peripheriques
US20120123937A1 (en) * 2010-03-02 2012-05-17 Douglas Spodak Portable e-wallet and universal card

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2797074A1 (fr) * 1999-07-28 2001-02-02 Gemplus Card Int Architecture de carte a puce integrant des peripheriques
US20120123937A1 (en) * 2010-03-02 2012-05-17 Douglas Spodak Portable e-wallet and universal card

Also Published As

Publication number Publication date
WO2019234346A1 (fr) 2019-12-12
FR3082030B1 (fr) 2021-04-23

Similar Documents

Publication Publication Date Title
EP3243178B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
EP2688010B1 (fr) Mise à jour d'un système d'exploitation pour élément sécurisé
EP2463833A1 (fr) Procédé et dispositif de contrôle d'exécution pour des fonctions internes et des applications protégées embarquées dans des cartes à microcircuits pour terminaux mobiles
EP3794538B1 (fr) Procédé et système d'enrolement autonome pour détenteur de dispositif biometrique
EP3168769B1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
FR2989799A1 (fr) Procede de transfert d'un dispositif a un autre de droits d'acces a un service
EP2735969A1 (fr) Ensemble électronique comprenant un module de desactivation
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
EP3465584A1 (fr) Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant
FR2966620A1 (fr) Procede et systeme de controle de l'execution d'une fonction protegee par authentification d'un utilisateur, notamment pour l'acces a une ressource
EP1258004B1 (fr) Ecriture en temps reel securisee pour memoire non volatile
EP3598328A1 (fr) Procede d'enregistrement d'une donnee biometrique de reference dans une carte a puce biometrique
EP2336938B1 (fr) Procédé de contrôle d'accès à une interface sans contact dans un circuit intégré à double interface de communication avec et sans contact
EP3417592A1 (fr) Système d'authentification d'un utilisateur auprès d'un serveur
FR3082030A1 (fr) Carte a puce personnalisable et procede de personnalisation
EP4125240A1 (fr) Element securise pre-personalise et personnalisation embarquee
FR2945141A1 (fr) Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel
FR3070076A1 (fr) Procede de protection d'un dispositif electronique contre des attaques par injection de faute
EP3671519A1 (fr) Sécurisation d'une transaction au moyen d'une carte à puce et carte à puce
FR2916881A1 (fr) Entite electronique portable, station hote et procede associe
FR3020164A1 (fr) Module d'emulation d'au moins une carte de paiement, procede, dispositif de paiement, produit programme d'ordinateur et medium de stockage correspondants
EP3690685A1 (fr) Procede d'authentification d'un utilisateur et dispositif associe
WO2020260316A1 (fr) Procede de communication radiofrequence entre un lecteur et un dispositif relie a un peripherique, avec mesure de champ radiofrequence
FR3062501A1 (fr) Procede pour la securite d'une operation electronique
EP3179400B1 (fr) Procédé de chargement d'une ressource informatique au sein d'un dispositif électronique, module électronique et programme d'ordinateur correspondant

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191206

PLFP Fee payment

Year of fee payment: 3

CA Change of address

Effective date: 20200909

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6