Brevet FR2803933A1 — publié le 20010720

PROCEDE DE PROTECTION CONTRE LE VOL DU CODE SECRET DANS LES CARTES A PUCE (S) MULTI-APPLICATIONS ET CARTES A PUCE (S) METTANT EN #UVRE LE PROCEDE L'invention concerne un procédé de protection contre le vol du code secret dans les cartes à puce (s) multi applications. Elle concerne également les cartes à puce(s) mettant en oeuvre ledit procédé. On entend par cartes à puce (s) multi-applications des cartes contenant une ou plusieurs puces de circuit intégré lesdites cartes étant destinées à pouvoir exécuter différents programmes d'application chargés ou téléchargés au cours de la vie de la carte. Parmi les solutions de cartes multi-applications existantes à ce jour, nous pouvons signaler JavaCard défini/spécifié par Sun ou SmartCard for Windows défini/spécifié par Microsoft. Pour simplifier, on parlera dans la suite d'applications pour désigner les programmes d'applications (ou Applet en terminologie anglo saxonne). On entend par code secret le numéro d'identification personnel du titulaire de la carte que l'on dénomme également PIN (Personnal Identifier Numb e r) . Pour des raisons de compatibilité avec les cartes à puce (s) ne supportant qu'une unique application, et de simplicité pour l'utilisateur de la carte, les cartes à puce(s) multi-applications ont généralement un seul PIN global pour toutes les applications. Ainsi, la spécification OP définie par VISA, et qui tient lieu actuellement de standard pour le chargement/téléchargement et la gestion interne d'applications sur les cartes à puce (s) multi- applications, définit un unique code secret pour toutes les applications résidentes et futures de la carte. Le problème soulevé par le déposant dans le cas d'une carte multi-applications, vient de ce que la carte est prévue pour pouvoir charger ou télécharger de nouvelles applications pendant toute sa vie. A priori ceci est un avantage, mais en pratique cette caractéristique rend la carte vulnérable, car des applications malveillantes pourront être chargées avec d'autres applications de manière transparente vis à vis du titulaire. C'est donc une porte ouverte à de telles applications qui bien sûr en pratique vont chercher à découvrir le code secret de la carte. Suite à cette observation, le déposant a identifié une attaque permettant de trouver le PIN de la carte Cette attaque suppose l'existence d'une application malveillante qui ne possède pas d'accès vers un terminal de transaction avec la carte c'est à dire non prévue pour dialoguer vers l'extérieur. Une application ne possède pas d'accès vers un terminal dès lors qu'il n'existe pas de terminaux mettant en #uvre un protocole permettant de directement dialoguer avec cette application. De telles applications peuvent néanmoins s'exécuter au sein de la carte, car elles proposent/ fournissent des services aux autres applications de la carte. On peut citer par exemple les applications de fidélité ( loyalties application ) qui sont des applications prévues pour comptabiliser des points de fidélité. Voici alors la procédure suivie lors de cette attaque au moyen d'une application qui ne peut pas dialoguer avec l'extérieur. En fait l'application exploite l'interface logique offerte par le système d'exploitation (ou par une application dédiée) et permettant de vérifier le code secret. Ainsi pour VOP, l'implémentation OP pour JavaCard , cette interface est l'opération verify PIN . Une application pouvant dialoguer avec l'extérieur et désirant vérifier l'identité du porteur commence par demander à l'utilisateur d'entrer son code secret par affichage d'un message sur l'écran du terminal dans lequel est insérée la carte à puce. Ensuite, l'application utilise l'interface fournie par le système d'exploitation (ou par l'application dédiée afin de vérifier que la valeur entrée par l'utilisateur est identique à la valeur du code secret de la carte). Si telle est le cas, le système d'exploitation (ou l'application en charge de la vérification du code) répond par l'affirmation ; par la négation dans le cas contraire. Dans la mesure où l'interface de vérification de code secret est accessible à l'ensemble des applications de la carte, une application malveillante peut déclencher l'exécution de cette opération et faire tester ainsi différentes valeurs jusqu'à l'obtention d'une réponse positive signalant que le code secret présenté est valide. Une application malveillante peut donc faire appel à l'opération de vérification de code secret (verify PIN pour VOP) et ainsi essayer différentes valeurs pour le code (0, 01, 02, 03, ... 9999). Pour éviter que ne soit testées un trop grand nombre de valeurs, la carte dispose généralement d'un compteur de ratification qui bloque son fonctionnement au bout d'un nombre déterminé de codes incorrects. En pratique ce nombre est généralement de 3. I1 est donc possible pour une application malveillante de présenter successivement deux valeurs de code (ou plus généralement, n-1 si le nombre de codes incorrects provocant le blocage de la carte est n), si les deux fois le code est mauvais, c'est-à-dire la réponse de la vérification du code secret est négative, le compteur de ratification sera incrémenté de 2, l'application étant bien évidemment prévue pour arrêter les tests et attendre que ce compteur soit réinitialisé par une entrée du code correct par l'utilisateur. En effet, le déclenchement par l'utilisateur d'une application dialoguant avec l'extérieur met en #uvre la procédure de vérification du code secret comme cela a été précédemment décrit. Le code secret est demandé à l'utilisateur, qui le rentre à partir du clavier du terminal. La procédure de vérification est mise en #uvre, et si l'utilisateur ne s'est pas trompé, le compteur de ratification qui était à 2 du fait des essais de l'application malveillante est remis à zéro. Ainsi, l'application malveillante peut recommencer des essais. La présente invention a pour but de remédier à ces problèmes. La présente invention a pour objet un procédé de protection contre le vol du code secret pour cartes à puce(s) multi applications, principalement caractérisé en ce qu'il consiste à détecter des opérations de vérification du code secret par une ou des applications ne possédant pas d'accès vers l'extérieur de la carte et à bloquer le fonctionnement de ladite carte ou de la ou desdites applications lorsque le nombre d'opération détectées a atteint une valeur de seuil prédéterminée. Selon une caractéristique de l'invention, la détection d'opérations de vérification du code secret comprend le déclenchement d'un compteur de ratification pour le comptage d'essais infructueux de code secret. Selon un premier mode de réalisation, le procédé consiste à utiliser deux compteurs de ratification, un premier compteur pour comptabiliser les essais infructueux ledit compteur étant remis à zéro lorsque le titulaire présente un code secret correct avant d'avoir atteint un nombre maximal prédéterminé de présentations possibles, le fonctionnement de la carte étant bloqué dans le cas contraire, et en ce qu'il consiste à incrémenter un deuxième compteur à chaque fois que le premier compteur s'approche de la valeur maximale et à bloquer le fonctionnement de la carte ou de l'application lorsque la valeur de ce deuxième compteur atteint la valeur de seuil prédéterminée. Selon un autre mode de réalisation, le procédé consiste à utiliser un compteur de ratification par application, chaque compteur étant apte à comptabiliser les essais infructueux de code secret relatifs à chaque application susceptible d'être mise en #uvre par la carte, le blocage du fonctionnement de la carte étant provoqué dés que l'un des compteurs a atteint une valeur de seuil prédéterminée pour le dit compteur. L'invention a également pour objet une carte à puce multi applications, principalement caractérisée en ce qu'elle comporte des moyens de détection d'opérations de vérification du code secret par une application ne possédant pas d'accès vers l'extérieur et des moyens de blocage de son fonctionnement lorsque le nombre d'opération de vérification a atteint une valeur de seuil prédéterminée. Les moyens de détection d'opérations de vérification du code secret comprennent au moins deux compteurs de ratification pour le comptage d'essais infructueux de code secret. Selon un premier mode de réalisation, les moyens de comptage comportent deux compteurs de ratification, un premier compteur pour comptabiliser les essais infructueux ledit compteur étant remis à zéro lorsque le titulaire présente un code secret correct avant d'avoir atteint un nombre maximal prédéterminé de présentations possibles, le fonctionnement de la carte étant bloqué dans le cas contraire, et un deuxième compteur incrémenté à chaque fois que le premier compteur s'approche de la valeur maximale et qui est utilisé par les moyens de blocage pour bloquer le fonctionnement de la carte lorsque la valeur de ce compteur atteint une valeur maximale prédéterminée. Selon un autre mode de réalisation les moyens de comptage de ratification comportent un compteur pour chaque application, chaque compteur étant apte à comptabiliser les essais infructueux de code secret relatifs à chaque application susceptible d'être mise en #uvre par la carte, le blocage du fonctionnement de la carte ou de l'application étant provoqué dés que l'un des compteurs a atteint une valeur de seuil prédéterminée pour le dit compteur. D'autres particularités et avantages de l'invention apparaîtront clairement à la lecture de la description qui est faite ci après et en regard des dessins sur lesquels - la figure 1 représente le schéma fonctionnel d'une carte à puce multi applications, - la figure 2 représente le schéma fonctionnel d'un premier mode de réalisation, - la figure 3 représente le schéma fonctionnel d'un deuxième mode de réalisation. Une carte à puce multi applications a été schématisée sur la figure 1 afin d'illustrer les différents éléments entrant dans la mise en #uvre du procédé conforme à l'invention. Une première solution proposée selon le procédé, consiste à utiliser deux compteurs de ratification, un premier pour compter toutes les mauvaises compositions du code secret quelle que soit l'application, ledit compteur étant remis à zéro lors d'une présentation correcte du code secret avant d'avoir atteint un nombre maximal prédéterminé de présentations possibles, le fonctionnement de la carte étant bloqué dans le cas contraire, le second compteur pour comptabiliser le nombre de fois que le premier compteur dépasse la valeur d'un seuil prédéterminé, ledit compteur n'étant pas remis à zéro après présentation d'un code correct. Une deuxième solution consiste à utiliser un compteur de ratification par application A1, A2,.., An. Pour mieux comprendre l'invention on rappelle qu'une carte à puce possède une unité de traitement U munie d'une mémoire de programme dans laquelle se trouve le système d'exploitation de la carte ainsi que des application pouvant étendre les fonctionnalités fournies par le système d'exploitation en proposant des services aux autres applications par l'intermédiaire de leur interface, par exemple une application dédiée à la vérification du code secret. Les différents programmes d'application A1, A2, An, peuvent se trouver dans cette même mémoire de programme Ml ou dans une autre mémoire de programme M2 qui sera alors prévue à cet effet de manière à pouvoir charger de nouvelles applications pendant la vie de la carte. Dans ce cas la mémoire sera une mémoire électriquement effaçable (du type EEPROM). Une zone Z pour le comptage d'essais infructueux pourra être prévue dans cette mémoire M2. Selon un premier mode de réalisation illustré par la figure 2, la détection d'essais infructueux opérés par une application n'ayant pas d'accès vers l'extérieur est effectuée au moyen de deux compteurs CP1 et CP2. A l'issue de la vérification opérée par la procédure de vérification lancée par une quelconque des applications, et en présence d'un code secret mauvais, le compteur CPl est incrémenté. Ainsi, lorsqu'il s'agit d'une application qui ne possède pas d'accès vers l'extérieur, le code secret fourni pour vérification ne peut provenir que de cette application qui cherche à faire des essais pour découvrir le code secret. Dans le cas d'applications ayant un accès vers l'extérieur, le code servant à la vérification du code secret est demandé par l'application au titulaire de la carte. A priori le titulaire d'une carte va se tromper moins souvent qu'une application malveillante qui fait des essais pour découvrir le çode secret. L'invention propose, d'utiliser un compteur de ratification de second ordre CP2. Cela consiste à ne plus compter le nombre de fois que l'on a présenté un code mauvais, mais le nombre de fois où la valeur du premier compteur CP1 est proche de la valeur qui va provoquer un blocage du fonctionnement. De façon pratique, le premier compteur CP1 est incrémenté chaque fois que le code présenté est mauvais, qu'il s'agisse d'une présentation faite par le titulaire de la carte ou par une application malveillante. La valeur maximale de ce compteur est par exemple de trois (trois essais possibles). Si le code secret correct est entré lors de ces trois essais ce compteur CP1 est remis à zéro. Lorsque ce compteur a une valeur proche de la valeur maximale, c'est à dire deux dans cet exemple, le deuxième compteur CP2 est incrémenté. On compte ainsi avec le deuxième compteur chaque fois que le premier compteur de ratification passe à 2 (si la valeur de blocage est par exemple 3). Ce deuxième compteur n'est pas remis à zéro et lorsque sa valeur atteint une valeur de seuil prédéterminée N', le système bloque le fonctionnement de la carte. Le seuil fixé pour ce deuxième compteur peut être choisi en fonction de la longueur du code secret. Plus le code est long plus les utilisateurs auront tendance à se tromper en le tapant, on choisira dans ce cas une valeur de seuil plus importante que dans le cas où le code est court (4 chiffres par exemple). La deuxième solution proposée et illustrée par le schéma de la figure 3 consiste à prévoir un compteur de ratification par application CP1 pour Al, CP2 pour A2,..., CPn pour An ( pour n applications). Le code secret reste global, c'est-,à-dire qu'il est le même pour toutes les applications, mais à chaque application est associé un compteur. Le compteur relatif à une application va par conséquent s'incrémenter chaque fois qu'un mauvais code secret est entré. Lorsque le bon code secret est entré le compteur de l'application est remis à zéro. Lorsque la valeur du compteur atteint une valeur maximale (par exemple 3) le fonctionnement de la carte ou de l'application est bloqué. Ce mécanisme est le même pour toutes les applications présentes dans la carte. Lorsqu'une nouvelle application est chargée dans la carte le système d'exploitation associe un compteur à cette nouvelle application. Chaque application est reconnue par le système d'exploitation grâce au champ identification AID (Applet Identifier). A chaque identification d'application, le système d'exploitation associe le compteur de ratification correspondant et l'incrémente pour chaque mauvaise présentation de code secret. Dans le cas d'une application malveillante n'ayant pas d'accès vers l'extérieur effectuant des essais infructueux de code secret, c'est cette dernière qui fournit le code. Pour les autres applications, c'est l'utilisateur de la carte qui entre son code sur le clavier du terminal. Ainsi une application malveillante ne pourra pas présenter plus de trois fois un mauvais code secret (si le compteur est fixé à trois). REVENDICATIONS 1.Procédé de protection contre le vol du code secret pour cartes à puce(s) multï applications, caractérisé en ce qu'il consiste à détecter des opérations de vérification du code secret par une ou des applications ne possédant pas d'accès vers l'extérieur de la carte et à bloquer le fonctionnement de ladite carte ou de la ou desdites applications lorsque le nombre d'opération détectées a atteint une valeur de seuil prédéterminée. 2. Procédé de protection contre le vol du code secret selon la revendication 1, caractérisé en ce que la détection d'opération de vérification du code secret comprenant le déclenchement d'au moins un compteur de ratification pour le comptage d'essais infructueux de code secret. 3. Procédé de protection contre le vol du code secret selon la revendication 1 ou 2, caractérisé en ce qu'il consiste à utiliser deux compteurs de ratification, un premier compteur pour comptabiliser les essais infructueux ledit compteur étant remis à zéro lorsque le titulaire 'présente un code secret correct avant d'avoir atteint un nombre maximal prédéterminé de présentations possibles, le fonctionnement de la carte étant bloqué dans le cas contraire, et en ce qu'il consiste à incrémenter un deuxième compteur à chaque fois que le premier compteur s'approche de la valeur maximale et à bloquer le fonctionnement de la carte lorsque la valeur de ce deuxième compteur atteint la valeur de seuil prédéterminée. 4. Procédé contre le vol du code secret selon la revendication 1 ou 2, caractérisé en ce qu'il consiste à utiliser un compteur de ratification par application, chaque compteur étant apte à comptabiliser les essais infructueux de code secret relatifs à chaque application susceptible d'être mise en ceuvre par la carte, le blocage du fonctionnement de la carte étant provoqué dés que l'un des compteurs a atteint une valeur de seuil prédéterminée pour ledit compteur. 5. Carte à puce multi applications, caractérisée en ce qu'elle comporte des moyens de détection d'opérations de vérification du code secret pour une application ne possédant pas d'accès vers l'extérieur et des moyens de blocage de son fonctionnement lorsque le nombre d'opérations de vérification a atteint une valeur de seuil prédéterminée. 6. Carte à puce multi applications selon la revendication 5, caractérisée en ce que les moyens de détection d'opérations de vérification du code secret comprennent au moins deux compteurs de ratification pour le comptage d'essais infructueux de code secret. 7. Carte à puce multi applications selon la revendication 6, caractérisé en ce que le premier compteur est apte à comptabiliser les essais infructueux ledit compteur étant remis à zéro lorsque le titulaire présente un code secret correct avant d'avoir atteint un nombre maximal prédéterminé de présentations possibles, le fonctionnement de la carte étant bloqué dans le cas contraire, et le deuxième compteur est incrémentè à chaque fois que le premier compteur s'approche de la valeur maximale et qui est utilisé par les moyens de blocage pour bloquer le fonctionnement de la carte lorsque la valeur de ce compteur atteint une valeur maximale prédéterminée. 8. Carte à puce multi applications selon la revendication 5, caractérisé en ce que les moyens de comptage de ratification comportent un compteur pour chaque application chaque compteur étant apte à comptabiliser les essais infructueux de code secret relatifs à chaque application susceptible d'être mise en #uvre par la carte, le blocage du fonctionnement de la carte ou de l'application étant provoqué dés que l'un des compteurs a atteint une valeur de seuil prédéterminée pour ledit compteur.