EP 1 538 509 A1

Printed by Jouve, 75001 PARIS (FR)
Europäisches Patentamt
European Patent Office
Office européen des brevets
(19)
EP 1 538 509 A1
*EP001538509A1*
(11) EP 1 538 509 A1
(12) DEMANDE DE BREVET EUROPEEN
(43) Date de publication:
08.06.2005 Bulletin 2005/23
(21) Numéro de dépôt: 03293036.4
(22) Date de dépôt: 04.12.2003
(51) Int Cl.7:G06F 1/00
(84) Etats contractants désignés:
AT BE BG CH CY CZ DE DK EE ES FI FR GB GR
HU IE IT LI LU MC NL PT RO SE SI SK TR
Etats d’extension désignés:
AL LT LV MK
(71) Demandeur: Axalto S.A.
92120 Montrouge (FR)
(72) Inventeurs:
• Giraud, Nicolas, Schlumberger Systèmes
78431 Louveciennes Cedex (FR)
• Rainsard, Stéphane, Schlumberger Systèmes
78431 Louveciennes Cedex (FR)
(74) Mandataire: Renault, Patricia Marie Jacqueline
Axalto S.A.
Intellectual Property Department
36-38, rue de la Princesse
B.P. 45
78431 Louveciennes Cedex (FR)
(54) Procédé de sécurisation de l’éxécution d’un programme contre des attaques par
rayonnement
(57) Le procédé selon la présente invention concer-
ne un procédé de sécurisation de l'exécution d'un pro-
gramme dans un ensemble électronique comportant
des moyens de traitement de l'information et des
moyens de mémorisation d'informations. Le procédé
consiste à contrôler l'exécution de chacune des instruc-
tions d'au moins une portion dudit programme en effec-
tuant lors de l'exécution de ladite portion un calcul utili-
sant des valeurs prédéterminées, fonction de ou asso-
ciées à chacune desdites instructions et en comparant
le résultat obtenu à une valeur précalculée.
La présente invention concerne également le mo-
dule électronique dans lequel ledit procédé est implé-
menté et la carte comprenant ledit module.

EP 1 538 509 A1
2
5
10
15
20
25
30
35
40
45
50
55
Description
[0001] La présente invention concerne un procédé et
un dispositif de sécurisation d'un ensemble électronique
mettant en oeuvre un programme à protéger. Plus pré-
cisément, le procédé vise à proposer une parade aux
attaques par rayonnement, flash, lumière, laser, glitch,
ou autres ou plus généralement à toute attaque pertur-
bant l'exécution des instructions du programme. De tel-
les attaques ont pour conséquence de modifier des ins-
tructions à exécuter et pour résultat l'inexécution ou la
mauvaise exécution de certaines parties du program-
me.
DOMAINE TECHNIQUE
[0002] Lors de l'exécution d'un programme, les atta-
ques par exemple par laser, glitch ou rayonnement élec-
tromagnétique ont pour conséquence de modifier les
codes d'instructions exécutés par le processeur comme
transformer un codop d'instruction quelconque en co-
dop 00h (BRSETO sur 6805, NOP sur 8051 et AVR) :
les instructions du programme sont remplacées par des
instructions inopérantes. De ce fait, il en résulte une
inexécution ou une exécution irrégulière de certaines
parties du code, par exemple l'exécution d'instructions
inopérantes au lieu et place d'une séquence de traite-
ment sécuritaire par exemple dans un système d'exploi-
tation pour carte à puce. Les attaques peuvent perturber
le fonctionnement du processeur et provoquer des
sauts intempestifs dans la mémoire programme.
[0003] Le présent demandeur a déposé une deman-
de de brevet français n°0016724 le 21 décembre 2000
portant sur un procédé de sécurisation de l'exécution
d'un programme implanté dans un module électronique
à microprocesseur, ainsi que le module électronique et
la carte à microcircuit associés. La solution protégée
dans ladite demande consiste à déclencher par inter-
mittence des interruptions et dérouter ainsi l'exécution
du programme pour parer à des attaques éventuelles.
Cette solution permet de détecter et d'empêcher les at-
taques par rayonnement avec une bonne probabilité.
Cependant, certaines attaques peuvent ne pas être ré-
vélées, en particulier si l'attaque a lieu brièvement entre
deux interruptions.
[0004] Parmi les parades connues, une autre solution
consiste à positionner des drapeaux dans un octet de
la mémoire RAM à intervalles réguliers et à vérifier qu'à
un point précis du déroulement du logiciel tous les dra-
peaux devant être positionnés le sont effectivement.
Toutefois la mise en place de cette parade est fastidieu-
se car il est nécessaire d'allouer des zones de mémoire
volatile spécifiques et de rajouter les traitements dans
le code à protéger partout où cela est nécessaire. De
plus, les attaques de ce type devenant de plus en plus
courte et précises, les solutions connues perdent en ef-
ficacité. D'une part, l'attaque peut être suffisamment
courte pour que le positionnement des drapeaux n'en
soit pas affecté ; l'exécution d'une partie du logiciel peut
ainsi être empêchée de manière totalement indécela-
ble. D'autre part, le logiciel de vérification des drapeaux
peut être lui-même perturbé.
[0005] Un but de la présente invention est de propo-
ser une protection efficace même pour des attaques très
courtes.
[0006] Un autre but de la présente invention est de
proposer une solution susceptible d'être implémentée
dans les composants actuels sans adaptation, peu con-
sommatrice en ressources et ne diminuant pas les per-
formances de l'ensemble dans lequel elle est implémen-
tée.
RESUME DE L'INVENTION
[0007] La présente invention concerne un procédé de
sécurisation de l'exécution d'un programme dans un en-
semble électronique comportant des moyens de traite-
ment de l'information et des moyens de mémorisation
d'informations caractérisé en ce qu'il consiste à contrô-
ler l'exécution de chacune des instructions d'au moins
une portion dudit programme en effectuant lors de l'exé-
cution de ladite portion un calcul utilisant des valeurs
prédéterminées, fonction de ou associées à chacune
desdites instructions et en comparant le résultat obtenu
à une valeur précalculée.
[0008] La présente invention concerne également un
module électronique dans lequel ledit procédé est im-
plémenté, une carte comprenant ledit module, un pro-
gramme permettant d'implémenter ledit procédé.
DESCRIPTION SOMMAIRE DES DESSINS
[0009] D'autres buts, avantages et caractéristiques
de l'invention apparaîtront à la lecture de la description
qui va suivre de la mise en oeuvre du procédé selon
l'invention et d'un mode de réalisation d'un ensemble
électronique adapté pour cette mise en oeuvre, donnés
à titre d'exemple non limitatif en référence aux dessins
ci-annexés dans lesquels :
-la figure 1 représente de manière schématique un
exemple de dispositif dans lequel le procédé selon
la présente invention est implémenté ;
-la figure 2 est une légende pour interpréter l'ensem-
ble des figures 3 à 7 annexées : un rectangle a non
grisé représentent une portion de code exécutée,
un rectangle b grisé une portion de code non exé-
cutée. Les flèches c grisées représentent une
attaque : leur longueur indique la durée de
l'attaque ; leur positionnement indique la portion de
code du programme attaquée. Le rectangle d à
bords gras représente une détection d'anomalie. Le
rectangle e grisé clair à bords fins représente des
données pré calculées. L'accolade f représente la
portée d'un pré-calcul. Le rectangle g à coins arron-
dis représente une adresse du code. Les rectangles
1 2

EP 1 538 509 A1
3
5
10
15
20
25
30
35
40
45
50
55
h en perspective visualisent l'état de la pile. Les lar-
ges flèches i grisées dont l'extrémité en pointe pro-
longe le rectangle de base et les ellipses grisées j
représentent des mécanismes matériels, les ellip-
ses k non grisées à bord double représentant des
mécanismes logiciels. Les rectangles I en perspec-
tive à bords gras représentent des mécanismes lo-
giciels en pile ;
-la figure 3 est une représentation schématique de
l'exécution d'un programme en l'absence d'une at-
taque dans laquelle les étapes du procédé de sé-
curisation selon une forme de réalisation de la pré-
sente invention ont été mises en évidence ;
-la figure 4 est une représentation schématique de
l'exécution d'un programme en présence d'une at-
taque dans laquelle les étapes du procédé de sé-
curisation selon la forme de réalisation représentée
sur la figure 3 ont été mises en évidence ;
-la figure 5 est une représentation schématique de
l'exécution d'un programme en l'absence d'une at-
taque dans laquelle les étapes du procédé de sé-
curisation selon une autre forme de réalisation de
la présente invention ont été mises en évidence ;
-la figure 6 est une représentation schématique de
l'exécution d'un programme en présence d'une at-
taque dans laquelle les étapes du procédé de sé-
curisation selon la forme de réalisation représentée
sur la figure 5 ont été mises en évidence ;
-la figure 7 est une représentation schématique de
l'exécution d'un programme en l'absence d'une at-
taque dans laquelle les étapes du procédé de sé-
curisation selon une variante de la forme de réali-
sation représentée sur la figure 5 ont été mises en
évidence.
MANIERE DE REALISER L'INVENTION
[0010] Le procédé selon l'invention vise à sécuriser
un ensemble électronique, et par exemple un objet por-
table tel qu'une carte à puce mettant en oeuvre un pro-
gramme. L'ensemble électronique comprend au moins
des moyens de traitement tels qu'un processeur et des
moyens de mémorisation tels qu'une mémoire. Le pro-
gramme à sécuriser est installé dans la mémoire, par
exemple de type ROM (Read Only Memory) dudit en-
semble.
[0011] A titre d'exemple non limitatif, l'ensemble élec-
tronique décrit dans ce qui suit correspond à un système
embarqué comprenant un module électronique 1 illustré
sur la figure 1. De tels modules sont réalisés le plus sou-
vent sous la forme d'un microcircuit électronique intégré
monolithique, ou puce, qui une fois protégé physique-
ment par tout moyen connu peut être monté sur un objet
portatif tel que par exemple une carte à puce, carte à
microcircuit ou circuit intégré (carte à
microprocesseur ...) ou autre utilisable dans divers do-
maines.
[0012] Le module électronique 1 comprend un micro-
processeur CPU 3 relié de façon bidirectionnelle par un
bus 5 interne à une mémoire 7 non volatile de type ROM,
EEPROM, Flash, FeRam ou autre contenant le pro-
gramme PRO 9 à exécuter, une mémoire 11 vive de type
RAM, des moyens 13 I/O d'entrée/sortie pour commu-
niquer avec l'extérieur, des moyens 15 d'évaluation tels
qu'au moins un compteur COUNTER.
[0013] Le procédé selon l'invention consiste à s'assu-
rer que le programme 9 est exécuté dans son intégralité
tel qu'il est implanté dans la mémoire en vérifiant que
chaque instruction du flot d'exécution est effectivement
exécutée par le microprocesseur 3.
[0014] Le procédé selon l'invention consiste à contrô-
ler l'exécution de chacune des instructions d'au moins
une portion dudit programme en effectuant lors de l'exé-
cution de ladite portion un calcul arithmétique utilisant
des valeurs prédéterminées, fonction de ou associées
à chacune des instructions et en comparant le résultat
obtenu à une valeur précalculée stockée dans lesdits
moyens de mémorisation. On entend par valeur prédé-
terminée toute valeur ne dépendant pas des caractéris-
tiques physiques du système dans lequel le procédé est
implémenté et des caractéristiques physiques de l'exé-
cution de ladite instruction dans ce système.
[0015] La valeur prédéterminée fonction d'une ins-
truction est par exemple une valeur fonction du contenu,
du type, de la fonction, du résultat et/ou de toute autre
caractéristique attachée à ladite instruction proprement
dite. Le contenu d'une instruction est entendu au sens
de tout élément constituant ladite instruction, y compris
le code opératoire et les paramètres. Le type d'une ins-
truction est entendu au sens d'une caractéristique de
l'instruction classant celle-ci dans une catégorie parti-
culière d'instructions. La fonction d'une instruction est
entendue au sens de la fonction exercée par ladite ins-
truction dans la portion de programme concernée. Le
résultat d'une instruction est entendu de toute valeur ob-
tenue par l'exécution de ladite instruction s'il en existe
une.
[0016] Selon une forme de réalisation selon la pré-
sente invention représentée sur les figures 3 et 4, le pro-
cédé consiste à effectuer pendant le fonctionnement du
microprocesseur le calcul d'une somme de contrôle sur
le contenu des instructions exécutées simultanément à
leur exécution et à vérifier la somme de contrôle calcu-
lée en la comparant à une valeur pré-calculée et inscrite
en mémoire. La valeur pré-calculée peut par exemple
être mémorisée dans le code protégé lors du dévelop-
pement du programme correspondant. Une somme de
contrôle, en anglais « checksum », est une « somme »
d'un ensemble de données, à savoir une valeur calculée
dépendant du contenu desdites données, utilisée à des
fins de vérification.
[0017] Un programme comprend de multiples tests
conditionnels et appels de routine traduits en langage
machine à l'aide d'instructions de branchement, de saut,
d'appel de routine ou équivalent, à savoir des instruc-
tions qui créent des embranchements dans le flot d'exé-
3 4

EP 1 538 509 A1
4
5
10
15
20
25
30
35
40
45
50
55
cution. Dans le cas où des tests conditionnels ou appels
de routine ou retour d'appel se suivent, la section de
code peut compter seulement quelques instructions
avant l'embranchement suivant dans l'arborescence
des chemins d'exécution possibles. Dans le cas d'un
saut à une autre routine, le point d'entrée de la routine
est susceptible d'être atteint par différents chemins.
Dans la présente invention, chaque point d'entrée ou
instruction de saut ou équivalent dans le code du pro-
gramme constitue le début d'une nouvelle section de co-
de pour le calcul de sommes de contrôle.
[0018] Pour implémenter un mécanisme de vérifica-
tion de sommes de contrôle, le procédé selon la présen-
te invention effectue un pré-calcul des sommes de con-
trôle sur chaque portion de code à protéger délimitée
par des points d'entrée ou de sortie ou des adresses de
saut ou par des instructions de branchement ou de saut
ou d'appel de routine ou de retour d'appel ou équivalent.
Pour appliquer ledit procédé à l'ensemble du code, com-
me le montrent les figures 3 et 4, la présente invention
utilise un compilateur spécifiquement adapté pour réa-
liser la tâche de pré-calcul des sommes de contrôle (ac-
colade « somme de contrôle pré-calculée sur les figures
3 et 4 »). Le passage des sommes de contrôle pré-cal-
culées en paramètre des instructions de fin de section
de code exige des modifications importantes des com-
pilateurs de type connu puisque le jeu d'instruction du
processeur est modifié.
[0019] La vérification de la somme de contrôle peut
être effectuée par le processeur. Pour cela, le procédé
selon la présente invention fournit au microprocesseur
à la fin de chaque portion de code à protéger la somme
de contrôle pré-calculée qui sera comparée
(« Vérification CKS » sur les figures 1 et 2) à la somme
de contrôle calculée par le processeur au fil de l'exécu-
tion (« Calcule CKS » fig. 1 et 2). Cette valeur est fournie
par exemple en paramètre de l'instruction de branche-
ment ou de saut ou d'appel de routine ou de retour d'ap-
pel ou équivalent et/ou marquant la fin d'une portion de
code à protéger ou d'une instruction marquant la fin
d'une portion de code à protéger. Dans le cas d'une por-
tion de code à protéger terminée par une adresse de
saut, la vérification de la somme de contrôle peut s'ef-
fectuer soit par une instruction spécialement ajoutée
dans le jeu d'instruction du processeur ou simplement
en ajoutant une instruction de saut inconditionnel à l'ins-
truction suivante.
[0020] La vérification est effectuée pendant l'instruc-
tion de fin de portion de code à protéger avec la valeur
pré-calculée fournie en paramètre. La somme de con-
trôle calculée par le processeur au cours de l'exécution
est réinitialisée pour la section de code suivante. Dans
le cas où la vérification de la somme de contrôle révèle
une différence, une action est déclenchée (« Détection
anomalie sur la figure 4).
[0021] La vérification de la somme de contrôle pour-
rait également être effectuée par le logiciel sans modi-
fication du jeu d'instruction du processeur en comparant
la valeur calculée par le processeur et la valeur pré-cal-
culée. Dans ce cas, il n'est pas nécessaire de modifier
le jeu d'instructions du processeur pour passer la som-
me de contrôle pré-calculée en paramètre de l'instruc-
tion de fin de section de code à protéger. Il suffit que la
somme de contrôle calculée par le processeur à l'exé-
cution soit accessible au programme dans un registre
ou autre.
[0022] Cette méthode peu consommatrice en res-
sources présente l'avantage de fournir une protection
intégrale sur le code à exécuter comprenant non seule-
ment le codop mais également les paramètres.
[0023] Selon une autre forme de réalisation du procé-
dé selon la présente invention représentée sur les figu-
res 5 à 7, un compteur 15 est attribué à au moins une
fonction, une séquence ou plus généralement à au
moins une portion dudit programme, et selon une forme
de réalisation, à chaque portion, au début de son exé-
cution. Une portion de programme comprend au moins
une instruction. Dans la suite de la description, à titre
illustratif, la portion considérée est une fonction. Le pro-
cédé consiste à incrémenter ledit compteur par le pro-
cesseur simultanément à l'exécution de chaque instruc-
tion de ladite fonction en cours d'une valeur spécifique
à l'instruction exécutée. A la fin de la fonction, la valeur
atteinte, résultat de la séquence d'instruction exécutée,
est vérifiée en comparaison à une valeur pré-calculée
lors du développement du programme et inscrite dans
le code protégé.
[0024] Le procédé selon ladite forme de réalisation
est implémentable sans ajout ou modification du jeu
d'instruction du processeur. Le procédé peut également
être mis en oeuvre sans adaptation du compilateur.
[0025] Au début de chaque fonction, un compteur est
attribué à la fonction dans une structure de données qui
peut être la pile du processeur. Le compteur est initialisé
à 0 ou à une valeur fixée pour la fonction (« Initialisation
compteur » sur les figures 5 à 7). Pour chaque instruc-
tion du corps de la fonction exécutée avant l'instruction
de retour d'appel, le compteur de la fonction est incré-
menté d'une valeur spécifique à l'instruction (« Calcule
CF ou CP » sur les figures 5 à 7). A la fin de la fonction,
la valeur atteinte par le compteur est comparée à la va-
leur attendue, pré-calculée et utilisée comme valeur de
référence dans le logiciel (« Comparaison CF » sur les
figures 5 à 7).
[0026] Comme le montre la figure 6, dans le cas où
une attaque aurait eu lieu au cours de la fonction, les
instructions n'ont pas été exécutées selon la séquence
prévue dans le programme et la valeur du compteur à
la fin de la fonction (CF1=0x25 sur la figure 6) est diffé-
rente de la valeur attendue et contrôlée (Valeur pré cal-
culée VP=0x92 sur la figure 6) ; l'attaque est ainsi dé-
tectée (« Détection anomalie » sur la figure) et une ac-
tion spécifique est effectuée par le programme ou le pro-
cesseur. Dans le cas où la vérification ne révélerait
aucune anomalie, le compteur de la fonction est dé-al-
loué dans la structure de donnée (sur la figure 5, le
5 6

EP 1 538 509 A1
5
5
10
15
20
25
30
35
40
45
50
55
compteur CF1 est dé-alloué).
[0027] Le code d'une fonction est constitué de multi-
ples tests conditionnels et appels de routine ou équiva-
lents, à savoir d'instructions qui créent des embranche-
ments dans le flot d'exécution. De manière à obtenir la
même valeur pour le compteur à la fin de la fonction quel
que soit le chemin d'exécution, il est nécessaire d'équi-
librer les différentes branches d'exécution possible.
[0028] La valeur d'incrémentation du compteur pour
une instruction peut être le code machine de l'instruction
(code opératoire + valeur des paramètres). Dans ce cas,
le compte calculé sur les instructions exécutées corres-
pond à une somme de contrôle calculée sur les instruc-
tions du flot d'exécution appartenant à la fonction. Les
instructions exécutées dans les fonctions appelées sont
prises en compte dans le compteur de ces fonctions et
ne sont donc pas prises en compte dans le compteur de
la fonction appelante.
[0029] L'équilibrage de tous les chemins d'exécution
possibles dans la fonction doit être réalisé pour obtenir
la même valeur du compteur à la fin de la fonction. Cet
équilibrage est compliqué du fait que les instructions ne
sont pas interchangeables entre elles. Il sera donc sou-
vent nécessaire de rajouter une ou plusieurs instruc-
tions ayant uniquement pour but de rééquilibrer une
branche par rapport à une autre. Cette solution induit
une augmentation plus ou moins importante de la taille
du code du fait du rééquilibrage des branches.
[0030] Une autre solution consiste à définir des clas-
ses d'instructions pour lesquelles la valeur d'incrémen-
tation est la même. Ces classes ayant le même incré-
ment regroupent des instructions similaires, par exem-
ple la classe des branchements conditionnels, la classe
des opérations arithmétiques et logiques, la classe des
sauts et appels de fonctions. L'instruction NOP aura une
valeur d'incrément 0 ; lors d'une attaque ayant pour effet
de transformer les instructions du programme en NOP,
le compteur ne sera pas incrémenté, ce qui aura pour
effet de mettre en évidence l'attaque. Ce mécanisme
permet de vérifier que chaque instruction du chemin
d'exécution à l'intérieur d'une fonction s'exécute correc-
tement.
[0031] Le regroupement des instructions en classes
avec la même valeur d'incrément facilite l'équilibrage
des branches : si chaque branche effectue des opéra-
tions différentes mais similaires, il est possible qu'elles
utilisent des instructions ayant des valeurs d'incrément
égales. De plus, il est possible d'équilibrer en employant
des instructions différentes mais de la même classe que
celles utilisées dans une autre branche. Par exemple
un branchement conditionnel dans une branche peut
être équilibré avec un branchement inconditionnel à
l'instruction suivante dans une autre branche. Les pa-
ramètres des instructions ne sont pas pris en compte
dans l'incrémentation du compteur, ce qui contribue
également à faciliter l'équilibrage des branches. L'équi-
librage des branches peut également se faire par accès
direct au compteur de la fonction dans le cas où l'écart
serait important.
[0032] La vérification de la valeur du compteur de la
fonction, effectuée à la sortie de la fonction ou lors de
vérifications intermédiaires, peut se faire de manière lo-
gicielle en lisant la valeur du compteur de la fonction en
cours, incrémentée par le processeur au cours de l'exé-
cution, et en la comparant avec la valeur pré-calculée.
Cette vérification peut également être effectuée par le
matériel en fournissant au processeur la valeur de con-
trôle pré-calculée. Cette valeur peut être fournie en pa-
ramètre d'une instruction de retour d'appel modifiée ou
d'une instruction spécifiquement ajoutée dans le jeu
d'instruction du processeur. L'instruction effectue la vé-
rification en comparant la valeur pré-calculée fournie en
argument à la valeur du compteur de la fonction en
cours.
[0033] Les opérations d'allocation du compteur de la
fonction dans une structure de données et l'initialisation
de ce compteur à 0 ou à une autre valeur spécifique
peuvent être effectuées de manière logicielle ou en ma-
tériel par le processeur dans une instruction d'appel de
fonction modifiée.
[0034] Selon une variante, le procédé consiste à ini-
tialiser au début de chaque routine un pointeur sur le
compteur de la routine après avoir sauvegardé sa pré-
cédente valeur. En sortant de la routine, le pointeur est
réinitialisé à sa valeur précédente (l'adresse du comp-
teur de la fonction appelante). Ce mécanisme permet
de faire des vérifications intermédiaires du compteur au
cours de la routine et notamment avant une opération
sensible. Si la valeur du compteur n'est pas la valeur
attendue à ce point de l'exécution de la routine, cela ré-
vèle que l'exécution de la routine a été perturbée.
[0035] L'allocation du compteur de la fonction sur la
pile du processeur présente un intérêt si celle-ci n'est
utilisée que pour sauvegarder les adresses de retour et
éventuellement certains registres lors des appels de
fonction. Dans ce cas, le compteur reste sur le sommet
de la pile dans le corps de la fonction, ce qui dispense
de maintenir par ailleurs un pointeur sur ce compteur
dans le but d'effectuer des vérifications au cours de la
routine. Dans un autre mode de réalisation, les comp-
teurs des routines peuvent être alloués dans une struc-
ture de données différente de la pile du processeur
(pouvant être une pile du compilateur) avec un moyen
de retrouver le compteur de la routine en cours d'exé-
cution (pouvant être un pointeur de pile).
[0036] Un mode de réalisation du procédé illustré sur
la figure 7 consiste à utiliser un compteur global (CP sur
la figure 7) du processeur pour réaliser le comptage.
L'incrémentation au cours de l'exécution des instruc-
tions est effectuée par le processeur dans ce compteur
global (CP). Lors de chaque appel de fonction, la valeur
du compteur global est ajoutée au compteur de la fonc-
tion appelante et réinitialisé à 0 (« Ajout CP à valeur en
pile CF=CF+CP et remise à zéro de CP » sur la figure).
Lors du retour d'une fonction, la valeur finale du comp-
teur de la fonction est obtenue en ajoutant la valeur du
7 8