EP2880588A1 - Systeme de detection de modification d'une pile d'appel de sous-programme - Google Patents

Systeme de detection de modification d'une pile d'appel de sous-programme

Info

Publication number
EP2880588A1
EP2880588A1 EP13756638.6A EP13756638A EP2880588A1 EP 2880588 A1 EP2880588 A1 EP 2880588A1 EP 13756638 A EP13756638 A EP 13756638A EP 2880588 A1 EP2880588 A1 EP 2880588A1
Authority
EP
European Patent Office
Prior art keywords
stack
address
subroutine
memory location
call
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
EP13756638.6A
Other languages
German (de)
English (en)
Other versions
EP2880588B1 (fr
Inventor
Florian GALDO
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.)
Rambus Inc
Original Assignee
Inside Secure SA
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 Inside Secure SA filed Critical Inside Secure SA
Publication of EP2880588A1 publication Critical patent/EP2880588A1/fr
Application granted granted Critical
Publication of EP2880588B1 publication Critical patent/EP2880588B1/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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C29/00—Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
    • G11C29/56—External testing equipment for static stores, e.g. automatic test equipment [ATE]; Interfaces therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/25—Using a specific main memory architecture
    • G06F2212/251—Local memory within processor subsystem

Definitions

  • the invention relates to the detection of untimely modifications of the contents of a routine call stack in a processor system, in particular for detecting fraud attempts.
  • a subroutine call stack is a reserved area in the memory of a processor system, used to store the "return" address, an address at which a program must continue to run at the end of the program. execution of a subroutine.
  • the imaged "stack” reflects a "last-in-first-out” (LIFO) management mode of the memory area, which is particularly well-suited for handling subprogram nesting.
  • LIFO last-in-first-out
  • An inadvertent modification of the call stack may cause, when the routine ends, the jump of the program execution to an arbitrary location, identified by the changed value of the stack.
  • the change may be due to an attempted fraud, where the fraudster seeks to divert the execution to a piece of malicious code or to bypass security checks.
  • a modification of the stack can be made by laser etching, directing a pulsed laser beam on the memory zone of the stack, or on the data bus at the moment when the data of the stack is read. It is also possible to disturb the value conveyed by the bus by generating pulses on the supply voltage at the time of this reading.
  • FIG. 1 illustrates the execution of this pseudo-code.
  • the contents of the call stack are shown above each block illustrating the execution of a subroutine, or function. It is assumed that the stack fills from below in this representation.
  • the main () function calls a funcl () function; the return address @ 1 is then placed on the stack, while the funcl () function is executed.
  • the funcl () function calls a function func2 (); the corresponding return address @ 2 is placed on the stack.
  • the function func2 () calls a function func3 (); a new return address @ 3 is placed on the stack.
  • the completion of the function func3 () is identified by the execution of the dedicated statement "return". This instruction causes the removal of address @ 3 from the stack, and the continuation of the execution from this address, in this case the continuation of the execution of function func2 ().
  • the function func2 () then calls a function VerifyPIN (), whose role is, for example, to verify the entry of a secret code.
  • the corresponding return address @ 4 is placed on the stack.
  • the VerifyPIN () function completes, the @ 4 address is removed from the stack and execution continues from that address, in this case in function func2 ().
  • patent US7581089 proposes to use two redundant call stacks. Each return address is placed on both stacks during subroutine calls. At the end of the execution of a subroutine, it is verified that the same return address is in both stacks. Although a fraudster can manage to modify the addresses contained in the two stacks, the chances of success of such modifications remain rather uncertain: it is particularly difficult to modify the two stacks simultaneously in the same way.
  • a method for detecting modification of a subroutine call stack comprising the steps of, upon a call of a routine, setting a return address to top of the pile; at the end of the routine, use the address at the top of the stack as the return address, and remove the address of the battery; when calling the routine, accumulate the return address in a memory location according to a first operation; at the end of the subroutine, accumulate the address of the top of the stack in the memory location according to a second operation, reciprocal of the first; and detect a change when the contents of the memory location differ from its initial value.
  • the first and second operations are the exclusive-OR operation bit by bit.
  • the first and second operations are addition and subtraction.
  • the return address and the address of the top of the stack are values taken from a memory bus during access phases to the stack.
  • the initial value is random.
  • a modification detection device of a subroutine call stack comprising, associated with a processor, a memory location storing an initial value, accessible for reading and writing by program instructions; an operator configured to replace the value of the memory location with the result of an operation between the contents of the memory location and a current value exchanged with the call stack; and a detection circuit configured to identify the instruction being executed and, if the identified instruction is a subroutine call, commanding the operator to perform a first type of operation, and if the instruction identified is a subroutine return, command the operator to perform a second type of operation, reciprocal of the first type.
  • FIG. 1, previously described, represents an execution of an exemplary pseudo-code, illustrating the evolution of the contents of the call stack
  • FIG. 3 represents an embodiment of a device for detecting changes in the call stack.
  • stacking and removal sequences have the same addresses.
  • the order of the retrieval sequence is not necessarily the inverse order of the stacking sequence, as shown by the @ 3 and @ 4 addresses, since several subroutines can be called in the same function .
  • a recursive operation performed at each write and read in the stack to accumulate the successive addresses in a dedicated memory location, preferably a register.
  • the recursive operation is such that the second operation made on the same address cancels the effect of the first operation made on the address. This can be done using two reciprocal operations, one used at each writing, and the other used at each reading.
  • the first operation is for example the addition, and the second the subtraction.
  • the first operation could be multiplication, and the second division.
  • the initial value REGo is preferably random, and regenerated at each call of the function to check. If it were fixed, the fraudster could be tempted to modify the contents of the register by laser attack, in order to restore it to its initial value at the moment when the return of the subroutine takes place.
  • the REG register is made accessible by software, allowing the programmer to insert before the subroutine call to protect register initialization instructions and, after returning the subroutine, instructions to read the contents of the register and check whether it has changed.
  • function func2 (so all functions nested under function func2 ()) in Figure 1
  • pseudo-code in the definition of function funcl ():
  • REG: REG 0 ;
  • FIG. 3 schematically shows an embodiment of verification device associated with a processor.
  • the processor comprises an arithmetic and logic unit ALU which is controlled by an instruction decoder 10.
  • the decoder 10 receives instruction codes by an instruction acquisition unit 12.
  • a memory interface 14 provides, from a central memory MEM, instruction codes to the unit 12.
  • the current instruction to seek in the memory is identified by the address contained in a dedicated register PC called "program counter", address that the unit ALU communicates to the memory interface 14 by a bus B.
  • the bus B is also used for the exchange of data between the ALU unit and the MEM memory.
  • the subroutine call stack CS is materialized in a reserved area of the memory MEM.
  • the data it stores are addresses pointing into an area of the MEM memory containing the instructions of the program to be executed.
  • a subroutine call is made by executing a CALL statement in the ALU.
  • the ALU calculates and puts on the stack the return address, usually the address of the instruction immediately after the call, defined for example by adding a fixed offset to the current value of the PC program counter.
  • the CALL instruction conveys as a parameter the address of the first instruction of the subroutine; the ALU unit updates the PC program counter with this address.
  • the return of a subroutine is made by executing a RET instruction.
  • the ALU then removes the last address from the stack and updates the PC program counter with that address.
  • the address put on the stack at the execution of the CALL instruction and the address removed from the stack at the execution of the RET instruction are present in turn on the data lines of the bus B , in writing for the first, and in reading for the second.
  • the verification device, 16 comprises a REG register for accumulating these written addresses and read in the call stack. Accumulation is done using an OP operator, configured to preferably calculate an exclusive-OR bit-by-bit between the contents of the REG register and the value present on the bus B data lines.
  • a detection circuit 18 is provided to identify whether the executing instruction is a subroutine call or return. It receives for this purpose the instruction code available in the instruction decoder 10. Whenever such an instruction is detected, the circuit 18 validates (EN) an accumulation in the register REG. If one chooses to use reciprocal operations other than exclusive-OR, the circuit 18 also selects the operation depending on whether the instruction is a call or a return.
  • the contents of the REG register are accessible in writing and reading via the ALU, as the content of work registers typically provided in a processor.
  • the REG register thus becomes accessible by program instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Executing Machine-Instructions (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention est relative à un procédé de détection de modification d'une pile d'appel de sous-programme, comprenant les étapes consistant à, lors d'un appel d'un sous- programme, placer une adresse de retour au sommet de la pile; à la fin du sous- programme, utiliser l'adresse au sommet de la pile comme adresse de retour, et retirer l'adresse de la pile; lors de l'appel du sous-programme, accumuler l'adresse de retour dans un emplacement mémoire (REG) selon une première opération (OP); à la fin du sous-programme, accumuler l'adresse du sommet de la pile dans l'emplacement mémoire selon une deuxième opération, réciproque de la première; et détecter une modification lorsque le contenu de l'emplacement mémoire diffère de sa valeur initiale (REGo).

Description

SYSTEME DE DETECTION DE MODI FICATION D'U N E PI LE
D'APPEL DE SOUS-PROGRAMME
Domaine technique de l'invention
L'invention est relative à la détection de modifications intempestives du contenu d'une pile d'appel de sous-programme dans un système processeur, notamment pour détecter des tentatives de fraude.
État de la technique
Une pile d'appel de sous-programme est une zone réservée de la mémoire d'un système processeur, servant à stocker l'adresse « de retour », adresse à laquelle doit continuer l'exécution d'un programme à la fin de l'exécution d'un sous-programme. Le terme imagé de « pile » reflète un mode de gestion « dernier entré-premier sorti » (LIFO) de la zone mémoire, qui est particulièrement bien adapté pour gérer l'imbrication des sous- programmes. Ainsi, on utilisera ci-après un langage imagé relatif à la gestion d'une pile, comme « mettre sur la pile », « empiler », « retirer de la pile »... sachant que le fonctionnement sous-jacent est en réalité obtenu par une gestion de pointeurs de lecture et d'écriture dans la zone mémoire.
Une modification intempestive de la pile d'appel peut provoquer, lorsque le sous- programme se termine, le saut de l'exécution du programme à un emplacement arbitraire, identifié par la valeur modifiée de la pile. La modification peut être due à une tentative de fraude, où le fraudeur cherche à détourner l'exécution vers un morceau de code malveillant ou bien à contourner des vérifications de sécurité.
Une modification de la pile peut être faite par attaque laser, en dirigeant un faisceau laser puisé sur la zone mémoire de la pile, ou sur le bus de données au moment où la donnée de la pile est lue. On peut également perturber la valeur véhiculée par le bus en générant des impulsions sur la tension d'alimentation au moment de cette lecture.
Pour mieux illustrer ce problème, on considère le pseudo-code en langage C suivant :
void main (void)
{
funcK ) ;
}
void funcl (void)
{ func2 ( ) ;
return ;
}
void func2 (void)
{
func3 ( ) ;
VerifyPINO ;
return ;
}
void func3 (void)
{
return ;
}
void VerifyPIN (void)
{
return ;
} La figure 1 illustre l'exécution de ce pseudo-code. Le contenu de la pile d'appel est représenté au-dessus de chaque bloc illustrant l'exécution d'un sous-programme, ou fonction. On suppose que la pile se remplit par le bas dans cette représentation.
Au cours de son exécution, la fonction main() appelle une fonction funcl() ; l'adresse de retour @1 est alors placée sur la pile, tandis que la fonction funcl() est exécutée. La fonction funcl() appelle une fonction func2() ; l'adresse de retour correspondante @2 est placée sur la pile. La fonction func2() appelle une fonction func3() ; une nouvelle adresse de retour @3 est placée sur la pile.
La fin de l'exécution de la fonction func3() est identifiée par l'exécution de l'instruction dédiée « return ». Cette instruction provoque le retrait de l'adresse @3 de la pile, et la poursuite de l'exécution à partir de cette adresse, en l'occurrence la poursuite de l'exécution de la fonction func2(). La fonction func2() appelle ensuite une fonction VerifyPIN(), dont le rôle est, par exemple, de vérifier la saisie d'un code secret. L'adresse de retour correspondante @4 est placée sur la pile. Lorsque l'exécution de la fonction VerifyPIN() se termine, l'adresse @4 est retirée de la pile et l'exécution se poursuit à partir de cette adresse, en l'occurrence dans la fonction func2().
Au fur et à mesure que l'exécution des fonctions se termine, les adresses de retour sont retirées de la pile, et l'exécution revient à l'adresse @1, dans la fonction main().
A la figure 2, au cours de l'exécution de la fonction func3(), un fraudeur modifie la dernière adresse de la pile @3. Il parvient à la remplacer par l'adresse @4, qui est l'adresse de retour de la fonction VerifyPIN(). Ainsi, dès que l'exécution de la fonction func3() se termine, l'exécution se poursuit à l'adresse @4. La fonction VerifyPIN(), servant à vérifier la saisie d'un code secret, est ainsi contournée.
Il n'est pas nécessaire que le fraudeur connaisse l'adresse exacte @4 de retour de la fonction qu'il souhaite contourner. Il suffit qu'il trouve par tâtonnement une adresse arbitraire au-delà de cette adresse de retour, qui ne provoque pas d'erreur du fait de l'absence d'exécution de la portion de code se trouvant entre l'adresse de retour et l'adresse arbitraire.
Diverses solutions sont connues pour éviter ce type de tentative de fraude. Par exemple, le brevet US7581089 propose d'utiliser deux piles d'appel redondantes. Chaque adresse de retour est placée sur les deux piles lors des appels de sous-programmes. A la fin de l'exécution d'un sous-programme, on vérifie que la même adresse de retour se trouve dans les deux piles. Bien qu'un fraudeur puisse parvenir à modifier les adresses contenues dans les deux piles, les chances de succès de telles modifications restent plutôt aléatoires : il est particulièrement difficile de modifier les deux piles simultanément de la même façon.
Bien que cette solution soit efficace, elle demande une complexité supplémentaire qui accroît la surface du circuit, et réduit ses performances.
Résumé de l'invention
On souhaite donc disposer d'une solution de faible complexité pour détecter des modifications du contenu de la pile d'appel de sous-programme.
On tend à satisfaire ce besoin en prévoyant un procédé de détection de modification d'une pile d'appel de sous-programme, comprenant les étapes consistant à, lors d'un appel d'un sous-programme, placer une adresse de retour au sommet de la pile ; à la fin du sous-programme, utiliser l'adresse au sommet de la pile comme adresse de retour, et retirer l'adresse de la pile ; lors de l'appel du sous-programme, accumuler l'adresse de retour dans un emplacement mémoire selon une première opération ; à la fin du sous- programme, accumuler l'adresse du sommet de la pile dans l'emplacement mémoire selon une deuxième opération, réciproque de la première ; et détecter une modification lorsque le contenu de l'emplacement mémoire diffère de sa valeur initiale.
Selon un mode de mise en œuvre, les première et deuxième opérations sont l'opération OU-exclusif bit à bit.
Selon un mode de mise en œuvre, les première et deuxième opérations sont l'addition et la soustraction. Selon un mode de mise en œuvre, l'adresse de retour et l'adresse du sommet de la pile sont des valeurs prélevées sur un bus mémoire lors de phases d'accès à la pile.
Selon un mode de mise en œuvre, la valeur initiale est aléatoire.
On prévoit également un dispositif de détection de modification d'une pile d'appel de sous-programme, comprenant, associés à un processeur, un emplacement mémoire stockant une valeur initiale, accessible en lecture et écriture par des instructions de programme ; un opérateur configuré pour remplacer la valeur de l'emplacement mémoire par le résultat d'une opération entre le contenu de l'emplacement mémoire et une valeur courante échangée avec la pile d'appel ; et un circuit de détection configuré pour identifier l'instruction en cours d'exécution et, si l'instruction identifiée est un appel de sous-programme, commander l'opérateur pour effectuer un premier type d'opération, et si l'instruction identifiée est un retour de sous-programme, commander l'opérateur pour effectuer un deuxième type d'opération, réciproque du premier type.
Description sommaire des dessins
Des modes de réalisation seront exposés dans la description suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles :
• la figure 1 , précédemment décrite, représente une exécution d'un exemple de pseudo-code, illustrant l'évolution du contenu de la pile d'appels ;
• la figure 2, précédemment décrite, illustre une tentative de fraude dans l'exécution de la figure 1 ; et • la figure 3 représente un mode de réalisation de dispositif de détection de modification de la pile d'appels.
Description d'un mode de réalisation préféré de l'invention
Dans la figure 1 , entre l'appel de la fonction funcl() dans le programme main(), et le retour de cette fonction, on empile au cours des appels de fonction successifs les adresses @1 , @2, @3, et @4 sur la pile d'appels. Pendant cette même phase, au cours des retours de fonction successifs, on retire les adresses @3, @4, @2 et @1 de la pile.
On remarque que les séquences d'empilement et de retrait comportent les mêmes adresses. L'ordre de la séquence de retrait n'est pas forcément l'ordre inverse de la séquence d'empilement, comme le montrent les adresses @3 et @4, du fait qu'on peut appeler plusieurs sous-programmes dans une même fonction. Il subsiste néanmoins la propriété qu'une même adresse apparaît deux fois sur le bus d'accès à la pile, une fois en écriture et une fois en lecture.
Afin de détecter une modification de la pile d'appels, ou des valeurs véhiculées sur le bus d'accès à cette pile, on propose de vérifier, au moins pour une partie de programme estimée critique par le programmeur, que chaque adresse de la pile apparaît deux fois sur le bus d'accès entre l'appel et le retour du sous-programme.
Pour effectuer une telle vérification, une solution consisterait à stocker la séquence complète d'adresses écrites et lues dans la pile, afin de vérifier à la fin que chaque adresse s'y trouve un nombre pair de fois. Cette solution est peu efficace.
On préfère utiliser une opération récursive effectuée à chaque écriture et lecture dans la pile pour accumuler les adresses successives dans un emplacement mémoire dédié, de préférence un registre. L'opération récursive est telle que la deuxième opération faite sur une même adresse annule l'effet de la première opération faite sur l'adresse. On peut pour cela utiliser deux opérations réciproques, l'une utilisée à chaque écriture, et l'autre utilisée à chaque lecture. La première opération est par exemple l'addition, et la deuxième la soustraction.
Dans l'exemple de la figure 1 , en mettant en œuvre la vérification pour la fonction funcl() dans le programme main(), le contenu accumulé dans le registre, initialisé à une valeur REGo, vaudrait :
REG = REGo + @1 + @2 + @3 - @3 + @4 - @4 - @2 - @1 = REGo.
Si tout se passe normalement, le contenu du registre est rétabli à sa valeur initiale REGo au retour dans le programme main().
Dans l'exemple de la figure 2, le contenu du registre vaudrait : REG = REGo + @1 + @2 + @3 - @4 - @2 - @1
= REGo + @3 - @4≠ REGo.
Le fait que le contenu du registre soit différent du contenu initial au retour de la fonction funcl() indique qu'une adresse de la pile a été modifiée.
On constate que cette procédure « protège » l'ensemble des sous-programmes imbriqués sous la fonction funcl() : il suffit que l'une quelconque des adresses de retour de ces sous-programmes soit modifiée pour que la vérification échoue.
Selon une variante, la première opération pourrait être la multiplication, et la deuxième la division.
On préfère toutefois utiliser une opération unique qui est la réciproque d'elle-même : l'opération OU-exclusif bit à bit. Cette opération a par ailleurs l'avantage d'être rapide et simple à mettre en œuvre de manière matérielle.
La valeur initiale REGo est de préférence aléatoire, et régénérée à chaque appel de la fonction à vérifier. Si elle était fixe, le fraudeur pourrait être tenté de modifier le contenu du registre par attaque laser, afin de le rétablir à sa valeur initiale au moment où le retour du sous-programme a lieu.
Il n'est pas utile de mettre en œuvre de telles vérifications de manière systématique, par exemple pour tout appel de sous-programme dans le programme main(). Cela pourrait même être inefficace. En effet, une fonction utile pour le fraudeur pourrait se trouver à plusieurs niveaux d'imbrication sous le programme main(). Dans ce cas, la fraude est détectée au retour dans le programme main(), mais seulement après l'exécution de la fonction utile pour le fraudeur.
Ainsi, il est souhaitable que le programmeur identifie les sous-programmes critiques et les protège individuellement à un niveau d'imbrication adéquat. Pour cela, le registre REG est rendu accessible par logiciel, permettant au programmeur d'insérer avant l'appel du sous-programme à protéger des instructions d'initialisation du registre et, après le retour du sous-programme, des instructions pour lire le contenu du registre et vérifier s'il a changé. Par exemple, si on souhaite protéger la fonction func2() (donc toutes les fonctions imbriquée sous la fonction func2()) dans la figure 1 , on pourrait utiliser le pseudo-code suivant dans la définition de la fonction funcl() :
void funcl (void)
{
REG0 : = RAND () ;
REG := REG0 ;
func2 ( ) ;
IF REG <> REG0 THEN Alert () ;
return;
}
La figure 3 représente schématiquement un mode de réalisation de dispositif de vérification associé à un processeur. Le processeur comprend une unité arithmétique et logique ALU qui est commandée par un décodeur d'instruction 10. Le décodeur 10 reçoit des codes d'instruction par une unité d'acquisition d'instructions 12. Une interface mémoire 14 fournit, à partir d'une mémoire centrale MEM, des codes d'instruction à l'unité 12. L'instruction courante à chercher dans la mémoire est identifiée par l'adresse contenue dans un registre dédié PC dit « compteur de programme », adresse que l'unité ALU communique à l'interface mémoire 14 par un bus B. Le bus B sert par ailleurs à l'échange de données entre l'unité ALU et la mémoire MEM.
La pile d'appel de sous-programme CS est matérialisée dans une zone réservée de la mémoire MEM. Les données qu'elle stocke sont des adresses pointant dans une zone de la mémoire MEM contenant les instructions du programme à exécuter.
Un appel de sous-programme est opéré par l'exécution d'une instruction CALL dans l'unité ALU. L'unité ALU calcule et met sur la pile l'adresse de retour, généralement l'adresse de l'instruction se trouvant immédiatement après l'appel, définie par exemple en ajoutant un décalage fixe à la valeur courante du compteur de programme PC. Par ailleurs, l'instruction CALL véhicule en tant que paramètre l'adresse de la première instruction du sous-programme ; l'unité ALU met à jour le compteur de programme PC avec cette adresse. Le retour d'un sous-programme est opéré par l'exécution d'une instruction RET. L'unité ALU retire alors la dernière adresse de la pile et met à jour le compteur de programme PC avec cette adresse.
On remarque que l'adresse mise sur la pile à l'exécution de l'instruction CALL et l'adresse retirée de la pile à l'exécution de l'instruction RET sont présentes à tour de rôle sur les lignes de données du bus B, en écriture pour la première, et en lecture pour la seconde.
Le dispositif de vérification, 16, comprend un registre REG servant à accumuler ces adresses écrites et lues dans la pile d'appel. L'accumulation est faite à l'aide d'un opérateur OP, configuré pour calculer de préférence un OU-exclusif bit à bit entre le contenu du registre REG et la valeur présente sur les lignes de données du bus B.
Un circuit de détection 18 est prévu pour identifier si l'instruction en cours d'exécution est un appel ou un retour de sous-programme. Il reçoit pour cela le code d'instruction disponible dans le décodeur d'instruction 10. A chaque fois qu'une telle instruction est détectée, le circuit 18 valide (EN) une accumulation dans le registre REG. Si on choisit d'utiliser des opérations réciproques autres que OU-exclusif, le circuit 18 sélectionne également l'opération selon que l'instruction est un appel ou un retour.
Le contenu du registre REG est accessible en écriture et lecture par l'intermédiaire de l'unité ALU, comme le contenu de registres de travail typiquement prévus dans un processeur. Le registre REG devient ainsi accessible par des instructions de programme.
De nombreuses variantes et modifications des modes de réalisation décrits apparaîtront à l'homme du métier. On a notamment exposé un partitionnement logiciel/matériel préférentiel des fonctions à réaliser - il est évident que d'autres partitionnements sont possibles en fonction du compromis vitesse/surface de silicium que l'on souhaite réaliser. La terminologie « sous-programme » ou « fonction » utilisée dans la présente demande est censée être générique et vise toute portion de programme que l'on exécute par un mécanisme de saut et retour utilisant une pile servant à stocker les adresses de retour.

Claims

Revendications
1. Procédé de détection de modification d'une pile d'appel de sous-programme, comprenant les étapes suivantes pour chaque sous-programme d'une succession de sous-programmes imbriqués à partir d'un sous-programme initial :
• lors d'un appel d'un sous-programme courant, placer une adresse de retour au sommet de la pile ; et
• à la fin du sous-programme courant, utiliser l'adresse au sommet de la pile comme adresse de retour, et retirer l'adresse de la pile ; caractérisé en ce qu'il comprend les étapes suivantes :
• associer un emplacement mémoire unique (REG) à la succession de sous- programmes ;
• sauvegarder la valeur initiale (REGo) de l'emplacement mémoire avant l'appel du sous-programme initial ;
• lors de l'appel du sous-programme courant, accumuler l'adresse de retour dans l'emplacement mémoire (REG) selon une première opération (OP) ;
• à la fin du sous-programme courant, accumuler l'adresse du sommet de la pile dans l'emplacement mémoire selon une deuxième opération, réciproque de la première ; et
• au retour du sous-programme initial, détecter une modification lorsque le contenu de l'emplacement mémoire diffère de la valeur initiale (REGo).
2. Procédé selon la revendication 1, dans lequel les première et deuxième opérations sont l'opération OU-exclusif bit à bit.
3. Procédé selon la revendication 1, dans lequel les première et deuxième opérations sont l'addition et la soustraction.
4. Procédé selon la revendication 1, dans lequel l'adresse de retour et l'adresse du sommet de la pile sont des valeurs prélevées sur un bus mémoire lors de phases d'accès à la pile.
5. Procédé selon la revendication 1 à 4, dans lequel la valeur initiale (REGo) est aléatoire.
6. Dispositif de détection de modification d'une pile d'appel de sous-programme, comprenant, associés à un processeur :
• un emplacement mémoire (REG) stockant une valeur initiale, accessible en lecture et écriture par des instructions de programme ;
• un opérateur (OP) configuré pour remplacer la valeur de l'emplacement mémoire par le résultat d'une opération entre le contenu de l'emplacement mémoire et une valeur courante échangée avec la pile d'appel ; et
• un circuit de détection (18) configuré pour identifier l'instruction en cours d'exécution et :
- si l'instruction identifiée est un appel de sous-programme (CALL), commander l'opérateur pour effectuer un premier type d'opération, et
- si l'instruction identifiée est un retour de sous-programme (RET), commander l'opérateur pour effectuer un deuxième type d'opération, réciproque du premier type.
7. Dispositif selon la revendication 6, dans lequel les premier et deuxième types d'opération sont l'opération OU-exclusif.
8. Dispositif selon la revendication 6, dans lequel les premier et deuxième types d'opération sont l'addition et la soustraction.
EP13756638.6A 2012-08-06 2013-07-31 Systeme de detection de modification d'une pile d'appel de sous-programme Active EP2880588B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1257635A FR2994290B1 (fr) 2012-08-06 2012-08-06 Systeme de detection de modification d'une pile d'appel de sous-programme
PCT/FR2013/051854 WO2014023894A1 (fr) 2012-08-06 2013-07-31 Systeme de detection de modification d'une pile d'appel de sous-programme

Publications (2)

Publication Number Publication Date
EP2880588A1 true EP2880588A1 (fr) 2015-06-10
EP2880588B1 EP2880588B1 (fr) 2020-10-28

Family

ID=47594871

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13756638.6A Active EP2880588B1 (fr) 2012-08-06 2013-07-31 Systeme de detection de modification d'une pile d'appel de sous-programme

Country Status (5)

Country Link
US (1) US9268559B2 (fr)
EP (1) EP2880588B1 (fr)
CN (1) CN104520868B (fr)
FR (1) FR2994290B1 (fr)
WO (1) WO2014023894A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9767272B2 (en) 2014-10-20 2017-09-19 Intel Corporation Attack Protection for valid gadget control transfers
CN109446798A (zh) * 2018-09-21 2019-03-08 中国科学院信息工程研究所 检测堆栈中返回地址被篡改历史的装置
CN109446797A (zh) * 2018-09-21 2019-03-08 中国科学院信息工程研究所 检测堆栈中返回地址被篡改的装置
CN109508539A (zh) * 2018-09-21 2019-03-22 中国科学院信息工程研究所 检测堆栈中返回地址被篡改的链式堆栈结构
CN109508538A (zh) * 2018-09-21 2019-03-22 中国科学院信息工程研究所 一种检测堆栈中返回地址被篡改的堆栈结构
US11314855B2 (en) * 2018-12-05 2022-04-26 Webroot Inc. Detecting stack pivots using stack artifact verification
US11720471B2 (en) * 2021-08-09 2023-08-08 International Business Machines Corporation Monitoring stack memory usage to optimize programs

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7752459B2 (en) * 2001-12-06 2010-07-06 Novell, Inc. Pointguard: method and system for protecting programs against pointer corruption attacks
US20040168078A1 (en) * 2002-12-04 2004-08-26 Brodley Carla E. Apparatus, system and method for protecting function return address
CN1447244A (zh) * 2003-04-03 2003-10-08 杭州中天微系统有限公司 一种设计在cpu里的侦测缓冲区溢出的方法
US7546587B2 (en) * 2004-03-01 2009-06-09 Microsoft Corporation Run-time call stack verification
US7467272B2 (en) * 2004-12-16 2008-12-16 International Business Machines Corporation Write protection of subroutine return addresses
DE602005024514D1 (de) * 2005-03-31 2010-12-16 Texas Instruments Inc Verfahren und System zum Vereiteln und Neutralisieren von Pufferüberläufangriffen
JP5090661B2 (ja) * 2006-04-12 2012-12-05 株式会社エヌ・ティ・ティ・ドコモ ソフトウェア動作モデル化装置、ソフトウェア動作監視装置、ソフトウェア動作モデル化方法及びソフトウェア動作監視方法
US7581089B1 (en) * 2006-04-20 2009-08-25 The United States Of America As Represented By The Director Of The National Security Agency Method of protecting a computer stack
US8141163B2 (en) * 2007-07-31 2012-03-20 Vmware, Inc. Malicious code detection
CN101866406A (zh) * 2010-06-18 2010-10-20 中国科学院软件研究所 一种栈溢出攻击防御方法
FR2977694A1 (fr) * 2011-07-08 2013-01-11 St Microelectronics Rousset Microprocesseur protege contre un debordement de pile

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2014023894A1 *

Also Published As

Publication number Publication date
FR2994290B1 (fr) 2018-04-06
US20150220328A1 (en) 2015-08-06
CN104520868A (zh) 2015-04-15
EP2880588B1 (fr) 2020-10-28
WO2014023894A1 (fr) 2014-02-13
US9268559B2 (en) 2016-02-23
FR2994290A1 (fr) 2014-02-07
CN104520868B (zh) 2017-08-08

Similar Documents

Publication Publication Date Title
EP2880588B1 (fr) Systeme de detection de modification d&#39;une pile d&#39;appel de sous-programme
US8677326B2 (en) Detecting applications in a virtualization environment
US9038161B2 (en) Exploit nonspecific host intrusion prevention/detection methods and systems and smart filters therefor
EP3182292B1 (fr) Procédé de prédiction d&#39;une donnée a précharger dans une mémoire cache
EP2453356B1 (fr) Procédé, programme d&#39;ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle
US20080148226A1 (en) Apparatus, method, and computer readable medium thereof for generating and utilizing a feature code to monitor a program
EP0637798A1 (fr) Procédé d&#39;analyse d&#39;interblocage dans un système d&#39;exploitation
EP1881404A1 (fr) Procédé de protection dynamique des données lors de l&#39;exécution d&#39;un code logiciel en langage intermédiaire dans un appareil numérique
FR2801693A1 (fr) Procedes et appareils pour detecter la presence eventuelle d&#39;exceptions
EP2836913B1 (fr) Dispositif pour générer une signature à l&#39;exécution d&#39;une tâche de programme et méthode de comparaison de flots d&#39;exécution
EP3284206B1 (fr) Procédé de sécurisation de l&#39; exécution d&#39;un programme
FR2977342A1 (fr) Verification d&#39;integrite d&#39;un programme execute par un circuit electronique
WO2007077142A2 (fr) Procede de securisation de l&#39;execution d&#39;un programme d&#39;ordinateur
FR2864650A1 (fr) Procede de mise a jour d&#39;applications pour carte a puce
EP3032451B1 (fr) Procédé d&#39;exécution d&#39;un programme par un processeur et entité électronique comportant un tel processeur
WO2008125479A1 (fr) Procédé d&#39;exécution sécurisée d&#39;une application
CN113688384A (zh) 程序的检测方法、装置、电子设备和介质
FR2503900A1 (fr) Dispositif de reprise pour installation de traitement de donnees
FR2897452A1 (fr) Procede pour empecher l&#39;execution de logiciels malveillants au sein d&#39;un systeme informatique.
EP4057169B1 (fr) Procédé d&#39;exécution d&#39;un code binaire d&#39;un programme d&#39;ordinateur par un microprocesseur
EP4078418A1 (fr) Système électronique et procédés d&#39;activation dynamique de contre-mesures
FR3072477A1 (fr) Securisation d’instructions de branchement conditionnel compose dans un programme informatique en code intermediaire
EP3422233B1 (fr) Procédé de protection d&#39;un dispositif électronique exécutant un programme contre des attaques par injection de faute
WO2017137675A1 (fr) Instruction combinée d&#39;addition et de vérification de bornes
FR2888369A1 (fr) Protection contre les attaques par generation de fautes sur les instructions de saut

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150112

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: GALDO, FLORIAN

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: VERIMATRIX

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: VERIMATRIX

17Q First examination report despatched

Effective date: 20191104

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: RAMBUS INC.

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20200525

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602013073614

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1328931

Country of ref document: AT

Kind code of ref document: T

Effective date: 20201115

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1328931

Country of ref document: AT

Kind code of ref document: T

Effective date: 20201028

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20201028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210128

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210301

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210129

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210228

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210128

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602013073614

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20210729

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20210731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210731

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210228

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210731

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20130731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20230727

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20230725

Year of fee payment: 11

Ref country code: DE

Payment date: 20230727

Year of fee payment: 11

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201028