FR 2928755 A1 20090918 FR 0801406 A 20080314 1 La présente invention concerne un procédé de sécurisation de l'exécution d'un programme par un microprocesseur, et notamment un microprocesseur d'une carte support de données comme une carte bancaire ou une carte électronique d'identification. ARRIERE PLAN DE L'INVENTION Une telle carte comporte un circuit intégré comprenant généralement un microprocesseur, une mémoire volatile et une mémoire non volatile. La mémoire non vola-file contient des données personnelles telles que l'identité de la personne à qui la carte a été délivrée, un code secret d'identification, des informations bancaires ou autres... et au moins un programme principal permet-tant l'échange d'informations entre la carte et un lec- teur d'un terminal auquel elle serait reliée comme un distributeur automatique de billets ou un terminal de paiement. Ce programme principal met en oeuvre plusieurs fonctions imbriquées permettant notamment de communiquer au terminal certaines des données personnelles, de récu- Aérer un code saisi par l'utilisateur sur le terminal, d'opérer des calculs sur ce code par exemple à des fins cryptographiques ou d'authentification, communiquer au terminal le résultat de l'authentification... Ces fonctions sont imbriquées en ce sens qu'une première fonction en cours d'exécution en appelle une deuxième qui en cours d'exécution en appelle une troisième etc. ; le retour à l'exécution de la deuxième fonction puis de la première fonction s'effectuant successivement, après la fin de l'exécution de la troisième fonction et de la deuxième fonction respectivement. Pour permettre le retour à la fonction appelante, le microprocesseur gère une pile d'appel de fonctions qui lui permet de stocker une adresse de retour à chaque fois qu'une fonction est appelée de telle manière qu'à la fin de l'exécution de la fonction appelée, le microprocesseur récupère l'adresse 2 mémorisée dans la pile d'appel de fonctions et y positionne son pointeur d'exécution pour poursuivre l'exécution de la fonction appelante. Dans ces cartes, l'une des fonctions critiques en matière de sécurité consiste à décrémenter un compteur après chaque échec d'une opération d'authentification consistant à vérifier que le code saisi sur le terminal est bien identique au code secret d'identification mémorisé dans le circuit intégré de la carte. Ce nombre, dans le cas d'une carte bancaire, est généralement fixé à trois tandis que le code lui-même comporte quatre chiffres. Le compteur ainsi décrémenté est remis à sa valeur initiale après une vérification réussie du code. En revanche, après trois échecs de vérification du code, le circuit intégré se bloque. Il existe un mode de fraude consistant à perturber le fonctionnement de la carte à la fin de l'opération d'authentification pour empêcher l'exécution de la fonction assurant la décrémentation du compteur. On comprend que, si cette fonction n'est pas effectuée, le fraudeur peut essayer toutes les combinai-sons possibles de quatre chiffres jusqu'à avoir trouvé la bonne. Un autre mode de fraude consiste à perturber le fonctionnement du microprocesseur pour amener des compor- tements inattendus du microprocesseur permettant éventuellement de récupérer des données devant normalement rester secrètes. Par exemple, il pourrait être envisageable, après qu'une fonction a été appelée par une fonction appelante, de revenir à l'exécution de la fonction appe- lante avant la fin de l'exécution de la fonction appelée. OBJET DE L'INVENTION Par l'invention, on propose un moyen permettant de sécuriser l'exécution d'un programme entraînant l'appel de fonctions imbriquées. RESUME DE L'INVENTION 3 A cet effet, on prévoit, selon l'invention, un procédé de sécurisation d'une exécution d'un programme principal mettant en oeuvre des fonctions imbriquées, comprenant les étapes de : - exécuter un programme gestionnaire de sécurité agencé pour actualiser une liste de fonctions en cours, - signaler au programme gestionnaire de sécurité un début d'exécution de chaque fonction et actualiser la liste de fonctions en cours, - signaler une fin d'exécution de chaque fonction au programme gestionnaire de sécurité, - vérifier après chaque signalement de fin d'exécution d'une fonction que cette fonction est bien la dernière à avoir débuté. Ainsi, la liste tenue par le programme gestionnaire de sécurité permet de détecter un fonctionnement anormal du programme principal et plus particulièrement de l'appel des fonctions. De préférence, en cas d'échec de la vérification, le procédé comprend l'étape d'effectuer une action de protection consistant par exemple en l'émission d'une alerte ou en une interruption du programme principal. Selon un mode de réalisation particulier, la liste de fonctions est une table comportant une suite de champs destinés à recevoir un identifiant de fonctions, le procédé comprenant les étapes de : - initialiser les champs, - au signalement du début d'exécution d'une fonction, inscrire l'identifiant de la fonction dans le pre- mier champ libre. Ce mode de réalisation est particulièrement simple et efficace et sa mise en oeuvre n'entraîne qu'un emploi limité des ressources de calcul et de mémoire. Avantageusement, le procédé comprend l'étape, au signalement de la fin d'exécution d'une fonction appelée 4 par une fonction appelante, de mémoriser la fonction appelée et faire vérifier par la fonction appelante au gestionnaire de sécurité que la dernière fonction exécutée est la fonction appelée. D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit d'un mode de mise en oeuvre particulier non limita-tif de l'invention. BREVE DESCRIPTION DES DESSINS Il sera fait référence aux dessins annexés, parmi lesquels : - la figure 1 est une vue schématique d'une carte de données utilisable pour la mise en oeuvre du procédé de l'invention, - la figure 2 est une représentation illustrant schématiquement le déroulement d'un programme principal dans le cadre du procédé conforme à l'invention, - la figure 3 est une représentation illustrant schématiquement le déroulement d'un programme gestion- naine de sécurité dans le cadre du procédé conforme à l'invention. DESCRIPTION DETAILLEE DE L'INVENTION En référence aux figures, l'invention est ici décrite en application à une carte de données 1 comportant un circuit intégré, généralement désigné en 2, comprenant un microprocesseur 3 relié à une mémoire volatile 4, par exemple de type RAM ("Random Access Memory"), et à une mémoire non volatile 5, par exemple de type EEPROM ("Electrically Erasable Programmable Read Only Memory") ou ROM (Read Only Memory"). La mémoire non volatile 5 contient un programme principal, symbolisé en 6 sur la figure 2, mettant en œuvre des fonctions F1, F2, F3 imbriquées. La fonction F1 est agencée pour, lors de son exécution, appeler la fonc- tion F2 qui elle-même est agencée pour, lors de son exé-cution, appeler la fonction F3. A la fin de l'exécution de la fonction F3, la fonction F2 se poursuit et à la fin de l'exécution de la fonction F2, la fonction F1 se pour-suit. La nature des fonctions F1, F2 et F3 importe peu, 5 ces fonctions assurant par exemple les opérations de récupération d'une valeur d'un code saisi sur un terminal auquel est reliée la carte à circuit intégré, des opérations de calculs, de vérification de ce code, de chiffre-ment, d'incrémentation ou décrémentation d'un compteur, d'inscription d'une mémoire dans une autre... Chaque fonction F1, F2 et F3 possède un identifiant ID-F1, ID-F2 et ID-F3 désignant de manière unique lesdites fonctions. La mémoire non volatile 5 contient en outre un programme gestionnaire de sécurité, symbolisé en 7 sur la figure 3, agencé pour établir et actualiser une liste des fonctions en cours d'exécution ou pile d'appel de fonctions. Cette liste se présente sous la forme d'une table 8 comportant une suite de champs 9 destinés à recevoir l'identification des fonctions en cours d'exécution. Le programme gestionnaire de sécurité 7 utilise, de façon connue en elle-même (et donc non décrite en détail ici), un index pour pointer sur le premier champ libre de la pile. Le procédé de l'invention va maintenant être décrit. En fonctionnement, lorsque le microprocesseur 3 de la carte 1 exécute le programme principal 6, il exécute simultanément le programme gestionnaire de sécurité 7. Au démarrage, les champs 9 de la table 8 sont initialisés en y inscrivant une valeur pour défaut, ici NOFCT, et l'index pointe sur le premier champ contenant cette valeur par défaut (également appelé champ libre). Lorsque le programme principal exécute la fonc- 6 tion F1, la fonction F1 signale le début de son exécution au programme gestionnaire de sécurité 7 au moyen d'une interface FONCTION-BEGIN (une telle interface est connue en elle-même). Le programme gestionnaire de sécurité 7 inscrit alors l'identifiant: ID-F1 de la fonction 1 dans le premier champ 9 libre de la table 8 et fait pointer son index sur le champ 9 suivant qui devient le premier champ libre. Lorsque la fonction F1 appelle la fonction F2, la fonction F2 signale le début de son exécution au pro-gramme gestionnaire de sécurité au moyen de l'interface FONCTION-BEGIN. Le programme gestionnaire de sécurité 7 inscrit alors l'identifiant de la fonction F2 (ici ID-F2) dans le champ 9 pointé puis fait pointer l'index sur le champ 9 suivant. Lorsque la fonction F2 appelle la fonction F3, la fonction F3 signale le début de son exécution au pro-gramme gestionnaire de sécurité 7 qui inscrit dans le champ pointé par l'index l'identifiant ID-F3 de la fonc- tion F3 et pointe l'index sur le champ 9 suivant. Lorsque l'exécution de la fonction F3 se termine, la fonction F3 signale la fin de son exécution au pro-gramme gestionnaire de sécurité 7 au moyen d'une inter-face FONCTION-END (une telle interface est connue en elle-même). Le programme gestionnaire de sécurité 7 vérifie alors que la fonction F3 qui signale la fin de son exécution est bien la dernière à avoir débuté son exécution. Si tel est le cas, l'exécution de la fonction F2 se poursuit jusqu'à son terme, la fonction F2 signalant alors au programme gestionnaire de sécurité 7 la fin de son exécution au moyen de l'interface FONCTION-END. Le programme gestionnaire de sécurité 7 vérifie alors que la fonction F2 est bien la dernière à avoir débuté son exécution. Si tel est le cas, l'exécution de la fonction F1 reprend jusqu'à son terme. 7 Dans l'hypothèse où la fonction signalant au pro-gramme gestionnaire de sécurité 7 la fin de son exécution n'est pas la dernière à avoir débuté celle-ci, le pro-gramme gestionnaire de sécurité 7 effectue une action de protection. Cette action de protection est ici une alerte émise à destination du programme principal 6 qui inter-rompt son exécution. L'action de protection peut égale-ment se traduire par un blocage de la carte, le déblocage ne pouvant être réalisé par exemple que par l'organisme émetteur de la carte après vérification de l'identification du détenteur de celle-ci. En variante, le procédé peut comprendre l'étape de mémoriser la dernière fonction exécutée lorsque celle-ci signale la fin de son exécution. La fonction ayant ap- pelé la dernière fonction exécutée peut alors interroger le programme gestionnaire de sécurité pour lui demander de contrôler la cohérence entre l'exécution nominale du programme et l'exécution réelle. Dans l'exemple décrit ci-dessus, lorsque la fonction F3 a signalé la fin de son exécution, la fonction F2 peut demander au programme gestionnaire de sécurité de vérifier que c'est bien la fonction F3 qui vient de se terminer. Bien entendu, l'invention n'est pas limitée au mode de réalisation décrit et on peut y apporter des va-riantes de réalisation sans sortir du cadre de l'invention telle que définie par les revendications. En particulier, l'identifiant des fonctions peut être construit de manière à contenir sous forme codée des informations propres à la fonction telles qu'un niveau de sécurité. Le programme gestionnaire de sécurité a alors accès à une table mettant en relation des actions de protection à effectuer en fonction des niveaux de sécurité codés dans l'identifiant des fonctions. Ainsi, par exemple, au début de l'exécution d'une fonction, le programme gestionnaire de sécurité détermine à partir de l'identi- 8 fiant de cette fonction quelles contre-mesures sécuritaires activer. Dans un autre exemple, lorsque la fin d'exécution d'une fonction intervient alors que cette fonction n'est pas la dernière à avoir débuté, le programme ges- tionnaire de sécurité peut être agencé pour déduire de l'identifiant de cette fonction l'action de protection à exécuter. Le programme gestionnaire de sécurité peut égale-ment être agencé pour activer au moins une contre-mesure de sécurité au début de l'exécution d'une fonction. L'identifiant de la fonction est alors de préférence dé-terminé pour indiquer au programme gestionnaire de sécurité la nécessité de l'activation d'une telle mesure sans nécessairement constituer une indication de la nature de cette contre-mesure (cette contre-mesure peut être la même pour toutes les fonctions nécessitant cette activation). Par contre-mesure de sécurité, on entend un moyen permettant notamment d'éviter une récupération d'informa-tions par un fraudeur par exemple en : - faisant varier la fréquence d'horloge, - insérant de façon aléatoire des instructions pour modifier la durée d'exécution du code, les émissions électromagnétiques ou la consommation énergétique lors de l'exécution du code... Selon une variante, on peut prévoir une table des appels possibles de fonctions par chaque fonction du pro-gramme principal. A titre d'exemple, si la fonction F2 appelle la fonction F3, le programme gestionnaire de sé- curité contrôle que la fonction F2 a bien le droit d'appeler la fonction F3. Il est également possible d'affecter les fonctions à des groupes et d'élaborer un identifiant des fonctions rattachant celles-ci aux groupes aux-quels elles appartiennent pour permettre au programme gestionnaire de sécurité de vérifier que les fonctions qui s'appellent mutuellement appartiennent bien au même groupe. REVENDICATIONS 1. Procédé de sécurisation d'une exécution d'un programme principal mettant en oeuvre des fonctions imbri- quées, comprenant les étapes de : -exécuter un programme gestionnaire de sécurité agencé pour actualiser une liste de fonctions en cours, - signaler au programme gestionnaire de sécurité un début d'exécution de chaque fonction du programme principal et actualiser la liste de fonctions en cours, - signaler une fin d'exécution de chaque fonction au programme gestionnaire de sécurité, - vérifier après chaque signalement de fin d'exécution d'une fonction que cette fonction est bien la der- nière à avoir débuté. 2. Procédé selon la revendication 1, dans le- quel en cas d'échec de la vérification, le procédé com- prend l'étape de réaliser une action de protection. 3. Procédé selon la revendication 2, dans le- quel l'action de protection consiste en l'émission d'une alerte. 4. Procédé selon la revendication 2, dans le-quel l'action de protection consiste en une interruption du programme principal. 5. Procédé selon la revendication 2, dans le- quel l'action de protection est sélectionnée en fonction d'un niveau de sécurité attaché à chaque fonction. 6. Procédé selon la revendication 1, dans le- quel la liste de fonctions est une table comportant une suite de champs destinés à recevoir un identifiant de fonction, le procédé comprenant les étapes de : -initialiser les champs, - au signalement du. début d'exécution d'une fonction, inscrire l'identifiant de la fonction dans le pre- mier champ libre. 11 7. Procédé selon la revendication 6, dans le-quel l'identifiant de chaque fonction contient un niveau de sécurité associé à la fonction et le programme gestionnaire de sécurité a accès à une table mettant en re-lation des actions de protection à effectuer en fonction des niveaux de sécurité. 8. Procédé selon la revendication 1, dans lequel le programme gestionnaire de sécurité a accès à une table des appels possibles de fonctions par chaque fonction du programme principal. 9. Procédé selon la revendication 1, dans le-quel au signalement de la :_in d'exécution d'une fonction appelée par une fonction appelante, mémoriser la fonction appelée et faire vérifier par la fonction appelante au gestionnaire de sécurité que la dernière fonction exécu- tée est la fonction appelée. 10. Procédé selon la revendication 1, dans lequel au début d'exécution d'une fonction, le programme gestionnaire de sécurité active au moins une contre-mesure de sécurité.