WO2020193664A1 - Élément sécurisé embarqué - Google Patents

Élément sécurisé embarqué Download PDF

Info

Publication number
WO2020193664A1
WO2020193664A1 PCT/EP2020/058434 EP2020058434W WO2020193664A1 WO 2020193664 A1 WO2020193664 A1 WO 2020193664A1 EP 2020058434 W EP2020058434 W EP 2020058434W WO 2020193664 A1 WO2020193664 A1 WO 2020193664A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
volatile memory
pram
execution data
applications
Prior art date
Application number
PCT/EP2020/058434
Other languages
English (en)
Inventor
Olivier Van Nieuwenhuyze
Amedeo Veneroso
Original Assignee
Stmicroelectronics S.R.L.
Proton World International N.V.
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 Stmicroelectronics S.R.L., Proton World International N.V. filed Critical Stmicroelectronics S.R.L.
Publication of WO2020193664A1 publication Critical patent/WO2020193664A1/fr
Priority to US17/479,275 priority Critical patent/US12045336B2/en

Links

Classifications

    • 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/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/126—Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • 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
    • G06F21/77—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 in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44557—Code layout in executable memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44578—Preparing or optimising for loading

Definitions

  • the present description relates generally to electronic systems, and more particularly to on-board electronic systems.
  • the present description relates even more particularly to the use of memories in an on-board electronic system.
  • An on-board electronic system is a stand-alone electronic and software system suitable for being on board an electronic device and / or electronic equipment.
  • a known difficulty in the design of on-board systems is the optimization of data backup, and more particularly of the use of different memories included in the on-board system.
  • the system may include read only memories, non-volatile memories and volatile memories, each suitable for storing data of different types.
  • One embodiment provides for an on-board secure element comprising a volatile memory, and being configured to implement at least part of a first application and at least part of one or more second applications adapted to be implemented. implemented by at least one low-level operating system of the on-board secure element, in which:
  • execution data of said first application is stored in a first reserved part of said volatile memory configured to store only execution data of said first application
  • Another embodiment provides a method of performing at least part of a first application and at least part of one or more second applications adapted to be implemented by at least one system low-level operating in a secure on-board element comprising a volatile memory, in which:
  • said at least one low-level operating system is an operating system suitable for exchanging commands directly with components of the on-board secure element.
  • the execution data of an application are temporary data used by an application only during its execution.
  • the part of said first application is the totality of said first application.
  • the on-board secure element comprises a non-volatile memory.
  • execution data relating to one or more secondary tasks of said first application are stored in a first reserved part of said virtual memory when the first part of said volatile memory is full.
  • execution data relating to one or more secondary tasks of said first application are stored in a first reserved part of said virtual memory when the first part of said volatile memory is full.
  • a secondary task of an application is a task of the application which is not being executed.
  • the secure element is configured to implement at least a third application suitable for being implemented by at least one low-level operating system of the on-board secure element.
  • the execution data of said third application are stored in the first reserved part of said volatile memory configured to store only execution data of said first application.
  • the execution data of said first application remain stored in a first reserved part of said volatile memory when said first application is on standby.
  • the first reserved part of said volatile memory stores the execution data of said second applications when said first application has no execution data stored in said first part.
  • the size of the first reserved part of said volatile memory can be modified.
  • the first and second applications only have access to their execution data in the virtual memory thanks to a protection system.
  • the virtual memory is a part of a non-volatile memory used as a volatile memory.
  • the virtual memory is internal to the secure element.
  • the non-volatile memory is external to the secure element.
  • Another embodiment provides for an application adapted to be implemented by at least one low-level operating system in a secure on-board element described above.
  • FIG. 1 represents, schematically and in the form of blocks, a software architecture of an on-board electronic system
  • FIG. 2 represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, the implementation of a method for executing applications of the on-board electronic system of figure 1;
  • FIG. 3 represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, an embodiment of a method for executing applications of the electronic system embedded in Figure 1;
  • FIG. 4 represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, the implementation of a method for executing applications of the on-board electronic system of figure 1;
  • FIG. 5 represents views (a), (b) and (c) illustrating, schematically and in the form of blocks, another embodiment of a method of executing applications of the system figure board electronics
  • FIG. 1 represents, schematically and in the form of blocks, a software architecture 100 of a secure on-board element E, or secure on-board electronic system.
  • the architecture comprises a primary platform 110 comprising access to the electronic components 111 (HW, Hardware) of the secure element E, and comprising low level operating systems 113 (LLOS, Low Level Operating System) .
  • HW Hardware
  • LLOS Low Level Operating System
  • the components of the secure element E are, for example, one or more processors, one or more memories, one or more communication devices, etc.
  • communication devices make it possible to communicate directly with a near field communication device (NFC, Near Field Communication), a short distance communication device using, for example, the Bluetooth standard, biometric sensors, etc.
  • Low level operating systems 113 are operating systems making it possible to facilitate communication between one or more high level operating systems (HLOS1, HLOS2, HLOS, High Level Operating System) 124A, 124B ( two high-level operating systems in the case illustrated in FIG. 1) of the secure element E and the components 111 of the element E.
  • the low-level operating systems include driver software components 111.
  • the low level operating systems 113 can make it possible to isolate the high level operating systems 124A, 124B from one another. More particularly, the low level operating systems 113 can manage the access of the high level operating systems 124A, 124B to different memories.
  • the low level operating systems 113 can make it possible to manage the data stored in said memories, and more particularly, to manage the access to this data, especially in the case where several high level operating systems are present. in the secure element E.
  • the low-level operating systems 113 can, for example, prohibit the access of certain data to a high-level operating system.
  • the architecture further comprises applications adapted to be implemented by the primary platform 110.
  • These applications are, for example, adapted to process commands coming from communication interfaces, such as for example a banking transaction using a near field communication device.
  • Each of these applications is implemented using fixed data, for example instructions, lines of code, or permanent data such as user data such as an identifier, forming the application, and temporary data, data runtime, or variables like data stacks, temporary encryption keys.
  • Application runtime data is data used by the application only while it is running.
  • an application implements one or more tasks, each task being, for example, a succession of instructions. It is the implementation of a task that produces runtime data. Some runtime data can be used by different tasks in the application, while others can only be used by a single task. It is considered that an application can only be implemented one task at a time.
  • the main task is called the task which is being executed by the application, and the secondary tasks the other tasks of the application which are not being executed.
  • the execution tasks are, for example, tasks which have not yet been implemented, and which have not made it possible to generate execution data, or tasks which have already been implemented but which have been , for example, interrupted, and which have therefore already made it possible to generate execution data.
  • execution data relating to the main task and execution data relating to the secondary tasks.
  • SIM Subscriber Identity Module
  • payment application an application allowing the validation of a public transport ticket, etc.
  • an application 121 (Appl) is suitable for being implemented directly by the primary platform 110.
  • the application 121 is, for example, an application allowing payments to be made in communicating with a near field communication device (NFC).
  • NFC near field communication device
  • another application 122 can be adapted to send commands to the primary platform 110 via one of the high-level operating systems, here the 124B operating system.
  • This high-level operating system can be, for example, one of the operating systems of the secure element E exchanging commands with the primary platform 110.
  • the operating system as well as all the applications which are attached to it, are an application adapted to be implemented by the primary platform 110.
  • another application 123 can be adapted to send commands to the primary platform 110 by means of an execution environment 125 (ENV) and of one of the high level operating systems, here operating system 124A.
  • the operating environment is for example of the Java or JavaCard type.
  • the operating system, as well as all the applications which are attached to it, are an application suitable for being implemented by the primary platform 110.
  • the components 111 of the secure element E comprise, more particularly, at least one non-volatile memory and at least one volatile memory.
  • Non-volatile memory is generally used to store fixed data from one or more applications
  • volatile memory is generally used to store runtime data from one or more applications.
  • protection for example protection software and / or a barrier mechanism. fire, used to prevent an application from accessing the life data and runtime data of another application.
  • At least part of the non-volatile memory is used as a volatile memory.
  • this part of the non-volatile memory forms a virtual volatile memory, or virtual memory, to store temporary data used by the applications during its operation.
  • the non-volatile memory can be internal or external to the secure element E.
  • an application can be in at least three different states.
  • An application can be running by the primary platform 110.
  • An application can be on standby, that is to say that its execution has been interrupted but that it can resume at any time.
  • An application can be deactivated, that is to say its execution cannot be restarted without one or more preliminary operations.
  • the data relating to its main task are stored in the volatile memory and are used for the implementation of the application.
  • the data relating to secondary tasks of the application can be stored in volatile memory or in virtual volatile memory.
  • an application When an application is on standby, the data relating to its main task are stored in the volatile memory and are not in use for the implementation of the application.
  • Data relating to secondary tasks of the application can be stored in volatile memory or in virtual volatile memory.
  • An application can, moreover, be on standby if its execution is interrupted by the execution of another application, in this case all the tasks of the application in standby are secondary tasks since none are executed.
  • FIGS 2 to 5 illustrate different implementations of applications of the secure element E, and more particularly the use of volatile and virtual memories.
  • FIG. 2 comprises three views (a), (b), and (c) each illustrating a phase of an implementation of a method for executing applications App20 and App21 of the secure element E described in relation to FIG. 1.
  • These three views illustrate more particularly the use of virtual volatile memory (NVM - Virtual RAM), bearing the reference VRAM, and of a real volatile memory (Physical RAM), bearing the reference PRAM , of the secure element E during the execution of the applications App20 and App21.
  • NVM - Virtual RAM virtual volatile memory
  • Physical RAM Physical RAM
  • the App21 application is deactivated, but has already been started, before the start of the App20 application.
  • the execution data relating to the main and secondary tasks of the application App21 are stored in a part VRAM21 of the virtual volatile memory VRAM.
  • the App20 application for its part, is also deactivated, but has never been started, it is also deactivated but has not yet generated any execution data.
  • the application App20 is started by the secure element E, more particularly, the application App20 is started by the low-level operating systems 113.
  • the application App20 is then running. Execution data, relating to the main task of the App20 application is downloaded / loaded into the real volatile memory PRAM.
  • the application App20 stores its execution data in the real volatile memory PRAM.
  • the execution data relating to the main task, and, optionally, to secondary tasks, of the application App20 present in the real volatile memory PRAM are stored in a part VRAM20 of the virtual volatile memory VRAM and deleted from the real volatile memory PRAM.
  • the current state of the application App20 is saved in the virtual volatile memory VRAM, and the application App20 then becomes deactivated.
  • App21 stored previously in a VRAM21 part are loaded into the real volatile memory PRAM. So, the use of the App21 application can resume where it left off previously. In other words, the VRAM21 application goes from a deactivated state to a "running" state.
  • the application App21 continues to run, and modifies in the real volatile memory (PRAM) its execution data relating to its main task, and, possibly, to secondary tasks, loaded from the virtual volatile memory VRAM to the real volatile memory PRAM.
  • PRAM real volatile memory
  • FIG. 3 comprises three views (a), (b), and (c) each illustrating a phase of an embodiment of a method for executing applications App30 and App31 of the element secure E described in relation to FIG. 1.
  • These three views illustrate more particularly the use of virtual volatile memory (NVM - Virtual RAM), bearing the reference VRAM, and of real volatile memory (Physical RAM), bearing the PRAM reference, of the secure element E during the activation of the applications App30 and App31.
  • NVM - Virtual RAM virtual volatile memory
  • Physical RAM Physical RAM
  • the application App30 is an application for frequent use, or a resident application, or the application App30 implements a task for frequent use, a resident task.
  • the execution data relating to the resident application App30 is stored in a reserved part PRAM30 of the real volatile memory PRAM.
  • the PRAM30 part of the PRAM memory is always available for storing the execution data of the application App30, and the execution data of one or more applications cannot be stored there.
  • a first phase the application App30 is started but is put on standby.
  • Execution data relating to the main task of the App30 application is stored in the PRAM30 part.
  • the main task of the App30 application is, for example, a resident task.
  • the application App31 is then started by the secure element E.
  • Execution data, relating to the main task, and, optionally to secondary tasks, of the application App31 are downloaded / loaded into a PRAM31 part of the real volatile memory PRAM.
  • the PRAM31 part is separate from the PRAM30 part.
  • the App31 application is therefore running.
  • the application App31 stores its execution data in the PRAM31 part of the real volatile memory PRAM.
  • the resident application App30 In a second phase (view (b)), the resident application App30, hitherto on standby, requests to be executed by the secure element E, more particularly, by low-level operating systems 113 .
  • the execution data relating to the application App31 present in the part PRAM31 of the real volatile memory PRAM is stored in a part VRAM31 of the virtual volatile memory VRAM.
  • the current state of the application App31 is saved in the virtual volatile memory VRAM, and the application App31 is then deactivated.
  • a third phase (view (c)) execution data relating to the main task of the application App30 stored previously in a VRAM30 part are already present in the PRAM30 part of the real volatile memory PRAM.
  • the use of the App30 application can resume where it left off previously, and the App30 application is running.
  • An advantage of this embodiment is that a frequently used application, or resident application, is guaranteed to have room in the physical volatile memory PRAM to store its execution data there.
  • FIG. 4 comprises three views (a), (b), and (c) each illustrating a phase of an implementation of a method for executing applications App40 and App41 of the secure element E described in relation to FIG. 1.
  • These three views illustrate more particularly the use of virtual volatile memory (NVM - Virtual RAM), bearing the reference VRAM, and of a real volatile memory (Physical RAM), bearing the reference PRAM , of the secure element E during the activation of the applications App40 and App41.
  • NVM - Virtual RAM virtual volatile memory
  • Physical RAM Physical RAM
  • the applications App40 and App41 are already started by the secure element E. All the execution data relating to the start-up and operation of the applications App40 and App41 are stored in, respectively, parts VRAM40 and VRAM41 of the volatile memory virtual VRAM. The apps App40 and App41 are both disabled.
  • a the application App40 requests to be executed by the secure element E, and then becomes running.
  • Startup and running runtime data relating to the App40 application is downloaded / loaded into a PRAM40 part of the real volatile memory PRAM, from the VRAM40 part of the virtual volatile memory VRAM, when the main task of the app40 application needs it.
  • the application App41 requests to be executed by the secure element E.
  • the execution data relating to the main task of the application App41 are downloaded / loaded into a part PRAM41 of the real volatile memory PRAM, from the part VRAM41 of the virtual volatile memory VRAM, when the task main application App41 needs it. This data is stored after the execution data relating to the application App40 in the real volatile memory PRAM.
  • the App41 application is then running, and the App40 application is then in standby.
  • a third phase (view (c)
  • the application App41 is still executed by the secure element E, but the real volatile memory PRAM has no more space available to store relative execution data.
  • Execution data relating to secondary tasks of the application App40 present in the PRAM40 part are moved to the VRAM40 part of the virtual volatile memory VRAM to free up storage space in the real volatile memory PRAM.
  • FIG. 5 comprises three views (a), (b), and (c) each illustrating a phase of an embodiment of a method for executing applications App50 and App51 of the element secure E described in relation to FIG. 1.
  • These three views illustrate more particularly the use of virtual volatile memory (NVM - Virtual RAM), bearing the reference VRAM, and of real volatile memory (Physical RAM), bearing the PRAM reference, of the secure element E during the activation of the applications App50 and App51.
  • NVM - Virtual RAM virtual volatile memory
  • Physical RAM Physical RAM
  • the applications App50 and App51 are already started by the secure element E and are deactivated. All execution data relating to the start-up and operation of the applications App50 and App51 are stored in, respectively, parts VRAM50 and VRAM51 of the virtual volatile memory VRAM.
  • the application App50 is an application of frequent use, hereinafter called a resident application, also described in relation to FIG. 3.
  • the resident application App50 requests to be executed by the secure element E.
  • Startup and operating execution data relating to the application App50 are downloaded / loaded. in a reserved part PRAM50 of the real volatile memory PRAM, from the part VRAM50 of the virtual volatile memory VRAM.
  • the PRAM50 part is a part of the real volatile PRAM memory still available to store the execution data of the App50 application, and which cannot be used to store the execution data of other applications.
  • the App50 application is then running.
  • the application App51 requests to be executed by the secure element E.
  • Startup and operating execution data relating to the application App51 are downloaded / loaded into.
  • a part PRAM51 of the real volatile memory PRAM from the part VRAM51 of the virtual volatile memory VRAM. This data is stored after the execution data relating to the application App50 in the real volatile memory PRAM.
  • the App51 application is then running, and the App50 application is then in standby.
  • a third phase (view (c)
  • the application App51 is still being executed by the secure element E, but the real volatile memory PRAM has no more space available to store data. of execution relating to the application App51 additional.
  • certain execution data relating to the App51 application which are no longer used, that is to say relative execution data to secondary tasks, are moved to the VRAM51 part of the volatile memory virtual VRAM to free up storage space in the real volatile memory PRAM.
  • the secure element E implements a third application
  • the real volatile memory PRAM when the real volatile memory PRAM has no more space available to store execution data, it will move the data from the application, which is not resident, whose execution is the oldest.
  • An advantage of this embodiment is that all the applications are loaded into the virtual volatile memory, which allows a rapid start of each application.
  • Another advantage of this embodiment is that an application of frequent use is guaranteed to have space in the real volatile memory VRAM to store its operating execution data therein.
  • low-level operating systems 113 described in relation to FIG. 1 which manage the filling of the memories with the execution data of the resident or non-resident applications. More particularly, low-level operating systems are suitable for detecting whether an application is a resident application or not.
  • a secure element E can include several resident applications.
  • the low-level operating systems 113 are, moreover, suitable for refusing the installation of an application as a resident application, for example, if the secure element E includes too many resident applications, in particular when too much, for example more than half, of the volatile PRAM memory is reserved for resident application execution data.
  • the low-level operating systems 113 are suitable for configuring the sizes of the parts of the volatile memory PRAM reserved for application execution data. residents.
  • the low-level operating systems 113 are suitable for configuring the size of a part of the volatile memory PRAM reserved for execution data of a resident application, to make it equal to zero.
  • the secure element includes several resident applications, then the execution data of these resident applications are all stored in the same "resident" part of the real volatile memory PRAM. When this "resident" part is full, the execution data relating to secondary tasks of the resident applications are moved to the virtual volatile memory VRAM.
  • the "resident" part of the real volatile memory PRAM which is reserved for their execution data of the resident applications can be used to store data from 'execution of other applications of the secure element.
  • the size of the "resident" part of the real volatile memory PRAM can be adjusted according to the needs of the resident applications. Additionally, if a resident application, which requests to be executed, does not have enough room to load its data into the "resident" portion of the volatile PRAM, its execution is suspended and it remains in the disabled state. Said application can only be executed when there is enough space in the "resident" part of the volatile PRAM memory. For example, space can be freed by disabling other resident applications. According to another example, the size of the "resident" part of the volatile memory PRAM can be increased.
  • an application could be divided into a sub-application which is resident, and another conventional sub-application.
  • the resident application could be part of another application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Mathematical Physics (AREA)
  • Memory System (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

La présente description concerne un élément sécurisé embarqué (E) comprenant une mémoire volatile (PRAM), et étant configuré pour mettre en oeuvre au moins une partie d'une première application (App30) et au moins une partie d'une ou plusieurs deuxièmes applications (App31) adaptées à être mises en oeuvre par au moins un système d'exploitation de bas niveau (113) de l'élément sécurisé embarqué (E), dans lequel: - des données d'exécution de ladite première application (App30) sont stockées dans une première partie réservée de ladite mémoire volatile (PRAM) configurée pour stocker uniquement des données d'exécution de ladite première application (App30); et - des données d'exécution desdites deuxièmes applications sont stockées dans une deuxième partie de ladite mémoire volatile (PRAM) distincte de la première partie réservée de ladite mémoire volatile (PRAM).

Description

DESCRIPTION
Elément sécurisé embarqué
La présente demande de brevet revendique la priorité de la demande de brevet français FR19/03168 qui sera considérée comme faisant partie intégrante de la présente description.
Domaine technique
[0001] La présente description concerne de façon générale les systèmes électroniques, et de façon plus particulière les systèmes électroniques embarqués. La présente description concerne encore plus particulièrement l'utilisation des mémoires dans un système électronique embarqué.
Technique antérieure
[0002] Un système électronique embarqué est un système électronique et logiciel autonome adapté à être embarqué dans un appareil électronique et/ou un équipement électronique.
[0003] Les difficultés de conception d'un système embarqué sont fréquemment liées à des contraintes d'encombrement et de consommation énergétique. Une difficulté connue de conception des systèmes embarqués est l'optimisation de la sauvegarde des données, et, plus particulièrement, de l'utilisation de différentes mémoires comprises dans le système embarqué. A titre d'exemple, le système peut comprendre des mémoires mortes, des mémoires non volatiles et des mémoires volatiles, chacune étant adaptée à stocker des données de différents types .
[0004] Il serait souhaitable de pouvoir améliorer, au moins en partie, certains aspects des systèmes électroniques embarqués connus, plus particulièrement de pouvoir améliorer, au moins en partie, certains aspects de l'utilisation des mémoires dans les systèmes électroniques embarqués. Résumé de l'invention
[0005] Il existe un besoin dans la technique pour des systèmes embarqués plus performants.
[0006] Il existe, plus particulièrement, un besoin dans la technique pour des systèmes embarqués dans lequel l'utilisation des mémoires est optimisée.
[0007] Un mode de réalisation prévoit un élément sécurisé embarqué comprenant une mémoire volatile, et étant configuré pour mettre en oeuvre au moins une partie d'une première application et au moins une partie d'une ou plusieurs deuxièmes applications adaptées à être mises en oeuvre par au moins un système d'exploitation de bas niveau de l'élément sécurisé embarqué, dans lequel :
- des données d'exécution de ladite première application sont stockées dans une première partie réservée de ladite mémoire volatile configurée pour stocker uniquement des données d'exécution de ladite première application ; et
- des données d'exécution desdites deuxièmes applications sont stockées dans une deuxième partie de ladite mémoire volatile distincte de la première partie réservée de ladite mémoire volatile.
[0008] Un autre mode de réalisation prévoit un procédé d'exécution d'au moins une partie d'une première application et d'au moins une partie d'une ou plusieurs deuxièmes applications adaptées à être mises en oeuvre par au moins un système d'exploitation de bas niveau dans un élément sécurisé embarqué comprenant une mémoire volatile, dans lequel :
- des données d'exécution de ladite première application sont stockées dans une partie réservée de ladite mémoire volatile configurée pour recevoir uniquement des données d'exécution de ladite première application ; et
- des données d'exécution desdites deuxièmes applications sont stockées dans une deuxième partie de ladite mémoire volatile distincte de la première partie réservée de ladite mémoire volatile.
[0009] Selon un mode de réalisation, ledit au moins un système d'exploitation de bas niveau est un système d'exploitation adapté à échanger des commandes directement avec des composants de l'élément sécurisé embarqué.
[0010] Selon un mode de réalisation, les données d'exécution d'une application sont des données temporaires utilisées par une application uniquement pendant son exécution.
[0011] Selon un mode de réalisation, la partie de ladite première application est la totalité de ladite première application .
[0012] Selon un mode de réalisation, l'élément sécurisé embarqué comprend une mémoire non volatile.
[0013] Selon un mode de réalisation, des données d'exécution relatives à une ou plusieurs tâches secondaires de ladite première application sont stockées dans une première partie réservée de ladite mémoire virtuelle quand la première partie de ladite mémoire volatile est pleine.
[0014] Selon un mode de réalisation, des données d'exécution relatives à une ou plusieurs tâches secondaires de ladite première application sont stockées dans une première partie réservée de ladite mémoire virtuelle quand la première partie de ladite mémoire volatile est pleine.
[0015] Selon un mode de réalisation, une tâche secondaire d'une application est une tâche de l'application qui n'est pas en cours d'exécution.
[0016] Selon un mode de réalisation, l'élément sécurisé est configuré pour mettre en oeuvre au moins une troisième application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau de l'élément sécurisé embarqué . [0017] Selon un mode de réalisation, les données d'exécution de ladite troisième application sont stockées dans la première partie réservée de ladite mémoire volatile configurée pour stocker uniquement des données d'exécution de ladite première application .
[0018] Selon un mode de réalisation, les données d'exécution de ladite première application restent stockées dans une première partie réservée de ladite mémoire volatile lorsque ladite première application est en veille.
[0019] Selon un mode de réalisation, la première partie réservée de ladite mémoire volatile stocke les données d'exécution desdites deuxièmes applications quand ladite première application n'a pas de données d'exécution stockées dans ladite première partie.
[0020] Selon un mode de réalisation, la taille de la première partie réservée de ladite mémoire volatile est modifiable.
[0021] Selon un mode de réalisation, les première et deuxièmes applications n'ont accès qu'à leurs données d'exécution dans la mémoire virtuelle grâce à un système de protection .
[0022] Selon un mode de réalisation, la mémoire virtuelle est une partie d'une mémoire non volatile utilisée comme une mémoire volatile.
[0023] Selon un mode de réalisation, la mémoire virtuelle est interne à l'élément sécurisé.
[0024] Selon un mode de réalisation, la mémoire non volatile est externe à l'élément sécurisé.
[0025] Un autre mode de réalisation prévoit une application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau dans un élément sécurisé embarqué décrit précédemment. Brève description des dessins
[0026] Ces caractéristiques et avantages, ainsi que d'autres, seront exposés en détail dans la description suivante de modes de réalisation particuliers faite à titre non limitatif en relation avec les figures jointes parmi lesquelles :
[0027] la figure 1 représente, de façon schématique et sous forme de blocs, une architecture logicielle d'un système électronique embarqué ;
[0028] la figure 2 représente des vues (a), (b) et (c) illustrant, de façon schématique et sous forme de blocs, la mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1 ;
[0029] la figure 3 représente des vues (a), (b) et (c) illustrant, de façon schématique et sous forme de blocs, un mode de mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1 ;
[0030] la figure 4 représente des vues (a), (b) et (c) illustrant, de façon schématique et sous forme de blocs, la mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure 1 ; et
[0031] la figure 5 représente des vues (a), (b) et (c) illustrant, de façon schématique et sous forme de blocs, un autre mode de mise en oeuvre d'un procédé d'exécution d'applications du système électronique embarqué de la figure
1.
Description des modes de réalisation
[0032] De mêmes éléments ont été désignés par de mêmes références dans les différentes figures. En particulier, les éléments structurels et/ou fonctionnels communs aux différents modes de réalisation peuvent présenter les mêmes références et peuvent disposer de propriétés structurelles, dimensionnelles et matérielles identiques. [0033] Par souci de clarté, seuls les phases et éléments utiles à la compréhension des modes de réalisation décrits ont été représentés et sont détaillés.
[0034] Sauf précision contraire, lorsque l'on fait référence à deux éléments connectés entre eux, cela signifie directement connectés sans éléments intermédiaires autres que des conducteurs, et lorsque l'on fait référence à deux éléments reliés ou couplés entre eux, cela signifie que ces deux éléments peuvent être connectés ou être reliés ou couplés par l'intermédiaire d'un ou plusieurs autres éléments.
[0035] Dans la description qui suit, lorsque l'on fait référence à des qualificatifs de position absolue, tels que les termes "avant", "arrière", "haut", "bas", "gauche", "droite", etc., ou relative, tels que les termes "dessus", "dessous", "supérieur", "inférieur", etc., ou à des qualificatifs d'orientation, tels que les termes "horizontal", "vertical", etc., il est fait référence sauf précision contraire à l'orientation des figures.
[0036] Sauf précision contraire, les expressions "environ", "approximativement", "sensiblement", et "de l'ordre de" signifient à 10 % près, de préférence à 5 % près.
[0037] La figure 1 représente, de façon schématique et sous forme de blocs, une architecture logicielle 100 d'un élément sécurisé embarqué E, ou système électronique embarqué sécurisé .
[0038] L'architecture comprend une plateforme primaire 110 comprenant l'accès aux composants électroniques 111 (HW, Hardware) de l'élément sécurisé E, et comprenant des systèmes d'exploitation de bas niveau 113 (LLOS, Low Level Operating System) .
[0039] Les composants de l'élément sécurisé E sont, par exemple, un ou plusieurs processeurs, une ou plusieurs mémoires, un ou plusieurs dispositifs de communication, etc. A titre d'exemple, les dispositifs de communication permettent de communiquer directement avec un dispositif de communication en champ proche (NFC, Near Field Communication) , un dispositif de communication à courte distance utilisant, par exemple, la norme Bluetooth, des capteurs biométriques, etc .
[0040] Les systèmes d'exploitation de bas niveau 113 sont des systèmes d'exploitation permettant de faciliter la communication entre un ou plusieurs systèmes d'exploitation de haut niveau (HLOS1, HLOS2, HLOS, High Level Operating System) 124A, 124B (deux systèmes d'exploitation de haut niveau dans le cas illustré en figure 1) de l'élément sécurisé E et les composants 111 de l'élément E. A titre d'exemple, les systèmes d'exploitation de bas niveau comprennent des logiciels pilote des composants 111. A titre d'exemple, les systèmes d'exploitation de bas niveau 113 peuvent permettre d'isoler les systèmes d'exploitation de haut niveau 124A, 124B les uns des autres. Plus particulièrement, les systèmes d'exploitation de bas niveau 113 peuvent gérer l'accès des systèmes d'exploitation de haut niveau 124A, 124B à différentes mémoires. Plus particulièrement, les systèmes d'exploitation de bas niveau 113 peuvent permettre de gérer les données stockées dans lesdites mémoires, et plus particulièrement, gérer l'accès de ces données, surtout dans le cas où plusieurs systèmes d'exploitation de haut niveau sont présents dans l'élément sécurisé E. Les systèmes d'exploitation de bas niveau 113 peuvent, par exemple, interdire l'accès de certaines données à un système d'exploitation de haut niveau.
[0041] L'architecture comprend, en outre, des applications adaptées à être mise en oeuvre par la plateforme primaire 110. Ces applications sont, par exemple, adaptées à traiter des commandes provenant d'interfaces de communication, comme par exemple une transaction bancaire utilisant un dispositif de communication en champ proche. Chacune de ces applications est mise en oeuvre à l'aide de données fixes, par exemple les instructions, les lignes de code, ou des données permanentes telles que des données utilisateurs comme un identifiant, formant l'application, et de données temporaires, données d'exécution, ou variables comme des piles de données, des clés de chiffrement temporaires. Les données d'exécution d'une application sont des données utilisées par l'application uniquement pendant son exécution.
[0042] Plus particulièrement, une application met en oeuvre une ou plusieurs tâches, chaque tâche étant, par exemple, une succession d'instructions. C'est la mise en oeuvre d'une tache qui produit des données d'exécution. Certaines données d'exécution peuvent être utilisées par différentes tâches de l'application, alors que d'autres peuvent n'être utilisées que par une seule tâche. On considère qu'une application ne peut être mettre en oeuvre qu'une seule tâche à la fois. Ainsi, dans la suite de la description, on appelle tâche principale la tâche qui est en cours d'exécution par l'application, et tâches secondaires les autres tâches de l'application qui ne sont pas en cours d'exécution. Les tâches d'exécution sont par exemple des tâches qui n'ont pas encore été mises en oeuvre, et qui n'ont pas permis de générer des données d'exécution, ou des tâches qui ont déjà été mises en oeuvre mais qui ont été, par exemple, interrompues, et qui ont donc déjà permis de générer des données d'exécution. Ainsi on distingue, dans la suite de la description, des données d'exécution relatives à la tâche principale, et des données d'exécution relatives aux tâches secondaires.
[0043] Ces applications peuvent être de différents types, par exemple, une application SIM (Subscriber Identity Module) , une application de paiement, une application permettant la validation d'un ticket de transport en commun, etc.
[0044] Selon un exemple de type d'application, une application 121 (Appl) est adaptée à être mise en oeuvre directement par la plateforme primaire 110. L'application 121 est, par exemple, une application permettant d'effectuer des paiements en communiquant avec un dispositif de communication en champ proche (NFC, Near Field Communication) .
[0045] Selon un autre exemple de type d'application, une autre application 122 (App2 ) peut être adaptée à envoyer des commandes à la plateforme primaire 110 par l'intermédiaire d'un des systèmes d'exploitation de haut niveau, ici le système d'exploitation 124B. Ce système d'exploitation de haut niveau peut être, par exemple, un des systèmes d'exploitation de l'élément sécurisé E échangeant des commandes avec la plateforme primaire 110. A titre de variante, on peut également considérer que le système d'exploitation, ainsi que toutes les applications qui lui sont attachées, sont une application adaptée à être mise en oeuvre par la plateforme primaire 110.
[0046] Selon un autre exemple de type d'application, une autre application 123 (App3) peut être adaptée à envoyer des commandes à la plateforme primaire 110 par l'intermédiaire d'un environnement d'exécution 125 (ENV) et d'un des systèmes d'exploitation de haut niveau, ici le système d'exploitation 124A. L'environnement d'exploitation est par exemple de type Java ou JavaCard. A titre de variante, on peut également considérer que le système d'exploitation, ainsi que toutes les applications qui lui sont attachées, sont une application adaptée à être mise en oeuvre par la plateforme primaire 110.
[0047] Pour mettre en oeuvre ces différentes applications 121, 122, 123, les systèmes d'exploitation 124A, 124B, et l'environnement d'exécution 125, les composants 111 de l'élément sécurisé E comprennent, plus particulièrement, au moins une mémoire non volatile et au moins une mémoire volatile. La mémoire non volatile sert généralement à stocker des données fixes d'une ou plusieurs applications, et la mémoire volatile sert généralement à stocker les données d'exécution d'une ou plusieurs applications. Dans le cas où les données fixes et les données d'exécution de plusieurs applications sont stockées en même temps dans la mémoire volatile et dans la mémoire non volatile, il existe une protection, par exemple un logiciel de protection et/ou un mécanisme pare-feu, permettant d'empêcher une application d'accéder aux données fixes et aux données d'exécution d'une autre application.
[0048] Selon un mode de réalisation, au moins une partie de la mémoire non volatile est utilisée comme une mémoire volatile. Autrement dit, cette partie de la mémoire non volatile forme une mémoire volatile virtuelle, ou mémoire virtuelle, pour stocker des données temporaires utilisées par les applications pendant son fonctionnement. A titre d'exemple, la mémoire non volatile peut être interne ou externe à l'élément sécurisé E.
[0049] Par ailleurs, on considère qu'une application peut être dans au moins trois états différents. Une application peut être en cours d'exécution (running) par la plateforme primaire 110. Une application peut être en veille, c'est-à- dire que son exécution a été interrompue mais qu'elle peut reprendre à tout moment. Une application peut être désactivée, c'est-à-dire que son exécution ne peut être redémarrée sans une ou plusieurs opérations préalables.
[0050] Plus particulièrement, lorsqu'une application est en cours d'exécution, tout ou partie des données relatives à sa tâche principale sont stockées dans la mémoire volatile et sont utilisées pour la mise en oeuvre de l'application. Les données relatives à des tâches secondaires de l'application peuvent être stockées dans la mémoire volatile ou dans la mémoire volatile virtuelle.
[0051] Lorsqu'une application est en veille, les données relatives à sa tâche principale sont stockées dans la mémoire volatile et ne sont pas en cours d'utilisation pour la mise en oeuvre de l'application. Les données relatives à des tâches secondaires de l'application peuvent être stockées dans la mémoire volatile ou dans la mémoire volatile virtuelle. Une application peut, en outre, être en veille si son exécution est interrompue par l'exécution d'une autre application, dans ce cas toutes les tâches de l'application en veille sont des tâches secondaires puisqu ' aucune n'est exécutée.
[0052] Lorsqu'une application est désactivée, les données relatives à sa tâche principale sont stockées dans la mémoire virtuelle. Les données relatives à des tâches secondaires de l'application sont stockées dans la mémoire virtuelle.
[0053] Les figures 2 à 5 illustrent différentes mises en oeuvre d'applications de l'élément sécurisé E, et plus particulièrement l'utilisation des mémoires volatile et virtuelle .
[0054] La figure 2 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'une mise en oeuvre d'un procédé d'exécution d'applications App20 et App21 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM) , portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'exécution des applications App20 et App21.
[0055] Selon l'exemple décrit en figure 2, l'application App21 est désactivée, mais a déjà été démarrée, avant le démarrage de l'application App20. Les données d'exécution relatives aux tâches principale et secondaires de l'application App21 sont stockées dans une partie VRAM21 de la mémoire volatile virtuelle VRAM.
[0056] L'application App20, quant à elle, est aussi désactivée, mais n'a jamais été démarrée, elle est aussi désactivée mais n'a pas encore généré de données d'exécution.
[0057] A une première phase (vue (a)), l'application App20 est démarrée par l'élément sécurisée E, plus particulièrement, l'application App20 est démarrée par les systèmes d'exploitation de bas niveau 113. L'application App20 est alors en cours d'exécution. Des données d'exécution, relatives à la tâche principale de l'application App20 sont téléchargées/chargées dans la mémoire volatile réelle PRAM.
[0058] Pendant toute son exécution, et si elle n'est pas interrompue par l'exécution d'une autre application, l'application App20 stocke ses données d'exécution dans la mémoire volatile réelle PRAM.
[0059] A une deuxième phase (vue (b)), l'application App21, jusqu'ici désactivée, demande à être exécutée par l'élément sécurisé E.
[0060] Les données d'exécution relatives à la tâche principale, et, éventuellement, à des tâches secondaires, de l'application App20 présentes dans la mémoire volatile réelle PRAM sont stockées dans une partie VRAM20 de la mémoire volatile virtuelle VRAM et supprimées de la mémoire volatile réelle PRAM. Ainsi l'état actuel de l'application App20 est sauvegardé dans la mémoire volatile virtuelle VRAM, et l'application App20 devient alors désactivée.
[0061] Des données d'exécution relatives à l'application
App21 stockées précédemment dans une partie VRAM21 sont chargées dans la mémoire volatile réelle PRAM. Ainsi, l'utilisation de l'application App21 peut reprendre là où elle s'était arrêtée précédemment. Autrement dit, l'application VRAM21 passe d'un état désactivé à un état "en cours d'exécution".
[0062] A une troisième phase (vue (c) ) , l'application App21 continue de s'exécuter, et modifie dans la mémoire volatile réelle (PRAM) ses données d'exécution relatives à sa tâche principale, et, éventuellement, à des tâches secondaires, chargées depuis la mémoire volatile virtuelle VRAM vers la mémoire volatile réelle PRAM.
[0063] La figure 3 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'un mode de mise en oeuvre d'un procédé d'exécution d'applications App30 et App31 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM) , portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'activation des applications App30 et App31.
[0064] Selon un mode de réalisation, l'application App30 est une application à usage fréquent, ou application résidente, ou l'application App30 met en oeuvre une tâche à usage fréquent, une tâche résidente. Les données d'exécution relatives à l'application résidente App30 sont stockées dans une partie PRAM30 réservée de la mémoire volatile réelle PRAM. La partie PRAM30 de la mémoire PRAM est toujours disponible pour stocker les données d'exécution de l'application App30, et les données d'exécution d'une ou d'autres applications ne peuvent y être stockées.
[0065] A une première phase (vue (a)), l'application App30 est démarrée mais est mise en veille. Des données d'exécution relatives à la tâche principale de l'application App30 sont stockées dans la partie PRAM30. La tâche principale de l'application App30 est, par exemple, une tâche résidente.
[0066] L'application App31 est, ensuite, démarrée par l'élément sécurisée E. Des données d'exécution, relatives à la tâche principale, et, éventuellement à des tâches secondaires, de l'application App31 sont téléchargées/chargées dans une partie PRAM31 de la mémoire volatile réelle PRAM. La partie PRAM31 est distincte de la partie PRAM30. L'application App31 est donc en cours d ' exécution .
[0067] Pendant toute son exécution, et si elle n'est pas interrompue par l'exécution d'une autre application, l'application App31 stocke ses données d'exécution dans la partie PRAM31 de la mémoire volatile réelle PRAM.
[0068] A une deuxième phase (vue (b)), l'application résidente App30, jusque-là en veille, demande à être exécutée par l'élément sécurisé E, plus particulièrement, par les systèmes d'exploitation de bas niveaux 113.
[0069] Les données d'exécution relatives à l'application App31 présentes dans la partie PRAM31 de la mémoire volatile réelle PRAM sont stockées dans une partie VRAM31 de la mémoire volatile virtuelle VRAM. Ainsi l'état actuel de l'application App31 est sauvegardé dans la mémoire volatile virtuelle VRAM, et l'application App31 est alors désactivée.
[0070] A une troisième phase (vue (c) ) , des données d'exécution relatives à la tâche principale de l'application App30 stockées précédemment dans une partie VRAM30 sont déjà présentes dans la partie PRAM30 de la mémoire volatile réelle PRAM. Ainsi, l'utilisation de l'application App30 peut reprendre là où elle s'était arrêtée précédemment, et l'application App30 est en cours d'exécution. [0071] Un avantage de ce mode de réalisation est qu'une application à usage fréquent, ou application résidente, est garantie d'avoir de la place dans la mémoire volatile physique PRAM pour y stocker ses données d'exécution.
[0072] La figure 4 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'une mise en oeuvre d'un procédé d'exécution d'applications App40 et App41 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM) , portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'activation des applications App40 et App41.
[0073] Les applications App40 et App41 sont déjà démarrées par l'élément sécurisé E. Toutes les données d'exécution relatives au démarrage et au fonctionnement des applications App40 et App41 sont stockées dans, respectivement, des parties VRAM40 et VRAM41 de la mémoire volatile virtuelle VRAM. Les applications App40 et App41 sont toutes les deux désactivées.
[0074] A une première phase (vue (a)), l'application App40 demande à être exécutée par l'élément sécurisé E, et devient alors en cours d'exécution. Des données d'exécution de démarrage et de fonctionnement relatives à l'application App40 sont téléchargées/chargées dans une partie PRAM40 de la mémoire volatile réelle PRAM, à partir de la partie VRAM40 de la mémoire volatile virtuelle VRAM, lorsque la tâche principale de l'application App40 en a besoin.
[0075] A une deuxième phase (vue (b)), l'application App41 demande à être exécutée par l'élément sécurisé E. Les données d'exécution relatives à la tâche principale de l'application App41 sont téléchargées/chargées dans une partie PRAM41 de la mémoire volatile réelle PRAM, à partir de la partie VRAM41 de la mémoire volatile virtuelle VRAM, lorsque la tâche principale de l'application App41 en a besoin. Ces données sont stockées à la suite des données d' exécution relatives à l'application App40 dans la mémoire volatile réelle PRAM. L'application App41 est alors en cours d'exécution, et l'application App40 est alors en veille.
[0076] A une troisième phase (vue (c) ) , l'application App41 est toujours exécutée par l'élément sécurisé E, mais la mémoire volatile réelle PRAM n'a plus d'espace disponible pour stocker des données d' exécution relatives à l'application App41 supplémentaires. Des données d'exécution relatives à des tâches secondaires de l'application App40 présentes dans la partie PRAM40 sont déplacées vers la partie VRAM40 de la mémoire volatile virtuelle VRAM pour libérer de l'espace de stockage dans la mémoire volatile réelle PRAM.
[0077] La figure 5 comprend trois vues (a), (b), et (c) illustrant chacune une phase d'un mode de mise en oeuvre d'un procédé d'exécution d'applications App50 et App51 de l'élément sécurisé E décrit en relation avec la figure 1. Ces trois vues illustrent plus particulièrement l'utilisation de la mémoire volatile virtuelle (NVM - Virtual RAM) , portant la référence VRAM, et d'une mémoire volatile réelle (Physical RAM), portant la référence PRAM, de l'élément sécurisé E pendant l'activation des applications App50 et App51.
[0078] Les applications App50 et App51 sont déjà démarrées par l'élément sécurisé E et sont désactivées. Toutes les données d' exécution relatives au démarrage et au fonctionnement des applications App50 et App51 sont stockées dans, respectivement, des parties VRAM50 et VRAM51 de la mémoire volatile virtuelle VRAM.
[0079] Selon l'exemple décrit en figure 5, l'application App50 est une application à usage fréquent, appelée par la suite une application résidente, aussi décrite en relation avec la figure 3. [0080] A une première phase (vue (a)), l'application résidente App50 demande à être exécutée par l'élément sécurisé E. Des données d'exécution de démarrage et de fonctionnement relatives à l'application App50 sont téléchargées/chargées dans une partie PRAM50 réservée de la mémoire volatile réelle PRAM, à partir de la partie VRAM50 de la mémoire volatile virtuelle VRAM. La partie PRAM50 est une partie de la mémoire volatile réelle PRAM toujours disponible pour stocker les données d'exécution de l'application App50, et qui ne peut pas être utilisée pour stocker des données d'exécution d'autres applications. L'application App50 est alors en cours d ' exécution .
[0081] A une deuxième phase (vue (b)), l'application App51 demande à être exécutée par l'élément sécurisé E. Des données d' exécution de démarrage et de fonctionnement relatives à l'application App51 sont téléchargées/chargées dans une partie PRAM51 de la mémoire volatile réelle PRAM, à partir de la partie VRAM51 de la mémoire volatile virtuelle VRAM. Ces données sont stockées à la suite des données d' exécution relatives à l'application App50 dans la mémoire volatile réelle PRAM. L'application App51 est alors en cours d'exécution, et l'application App50 est alors en veille.
[0082] A une troisième phase (vue (c) ) , l'application App51 est toujours en cours d'exécution par l'élément sécurisé E, mais la mémoire volatile réelle PRAM n'a plus d'espace disponible pour stocker des données d'exécution relatives à l'application App51 supplémentaires. Les données d'exécution relatives à l'application App51 ne pouvant être stockées dans la partie PRAM50, certaines données d'exécution relatives à l'application App51 qui ne sont plus utilisées, c'est-à-dire des données d'exécution relatives à des tâches secondaires, sont déplacées vers la partie VRAM51 de la mémoire volatile virtuelle VRAM pour libérer de l'espace de stockage dans la mémoire volatile réelle PRAM.
[0083] Dans le cas où l'élément sécurisé E met en oeuvre une troisième application, quand la mémoire volatile réelle PRAM n'a plus d'espace disponible pour stocker des données d'exécution, elle déplacera les données de l'application, qui n'est pas résidente, dont l'exécution est la plus ancienne.
[0084] Un avantage de ce mode de réalisation est que toutes les applications sont chargées dans la mémoire volatile virtuelle, ce qui permet un démarrage rapide de chaque application .
[0085] Un autre avantage de ce mode de réalisation est qu'une application à usage fréquent est garantie d'avoir de la place dans la mémoire volatile réelle VRAM pour y stocker ses données d'exécution de fonctionnement.
[0086] Selon un mode de réalisation, ce sont les systèmes d'exploitation de bas niveau 113 décrits en relation avec la figure 1 qui gèrent le remplissage des mémoires avec les données d'exécution des applications résidente, ou non. Plus particulièrement, les systèmes d'exploitation de bas niveau sont adaptés à détecter si une application est une application résidente ou non. Un élément sécurisé E peut comprendre plusieurs applications résidentes. Les systèmes d'exploitation de bas niveau 113 sont, en outre, adaptés à refuser l'installation d'une application en tant qu ' application résidente, par exemple, si l'élément sécurisé E comprend trop d'applications résidentes, en particulier lorsqu'une trop grande partie, par exemple plus de la moitié, de la mémoire volatile PRAM est réservée à des données d'exécutions d'applications résidentes. Selon une variante, les systèmes d'exploitation de bas niveau 113 sont adaptés à configurer les tailles des parties de la mémoire volatile PRAM réservées à des données d'exécution d'applications résidentes. En particulier, les systèmes d'exploitation de bas niveau 113 sont adaptés à configurer la taille d'une partie de la mémoire volatile PRAM réservée à des données d'exécution d'une application résidente, pour la rendre égale à zéro.
[0087] De plus, si l'élément sécurisé comprend plusieurs applications résidentes, alors les données d'exécution de ces applications résidentes sont toutes stockées dans une même partie "résidente" de la mémoire volatile réelle PRAM. Lorsque cette partie "résidente" est pleine, les données d'exécution relatives à des tâches secondaires des applications résidentes sont déplacées vers la mémoire volatile virtuelle VRAM.
[0088] De plus, si toutes les applications résidentes de l'élément sécurisé sont désactivées, la partie "résidente" de la mémoire volatile réelle PRAM qui est réservée à leurs données d'exécution des applications résidentes peut être utilisée pour stocker des données d'exécution d'autres applications de l'élément sécurisé. Par ailleurs, la taille de la partie "résidente" de la mémoire volatile réelle PRAM peut être ajustée en fonction des besoins des applications résidentes. En outre, si une application résidente, qui demande à être exécuté, n'a pas assez de place pour charger ses données dans la partie "résidente" de la mémoire volatile PRAM, son exécution est suspendue et elle reste dans l'état désactivé. Ladite application ne pourra être exécutée que lorsqu'il y aura assez de place dans la partie "résidente" de la mémoire volatile PRAM. A titre d'exemple, de la place peut être libérée en désactivant d'autres applications résidentes. Selon un autre exemple, la taille de la partie "résidente" de la mémoire volatile PRAM peut être augmentée.
[0089] Divers modes de réalisation et variantes ont été décrits. L'homme de l'art comprendra que certaines caractéristiques de ces divers modes de réalisation et variantes pourraient être combinées, et d'autres variantes apparaîtront à l'homme de l'art.
[0090] En particulier, l'utilisation de la mémoire volatile virtuelle a été décrite avec l'exécution de deux applications, mais en pratique cette utilisation peut être transposée avec l'utilisation de plus de deux applications.
[0091] De plus, une application pourrait être divisée en une sous-application qui est résidente, et une autre sous- application classique. Autrement dit l'application résidente pourrait être une partie d'une autre application.
[0092] Enfin, la mise en oeuvre pratique des modes de réalisation et variantes décrits est à la portée de l'homme du métier à partir des indications fonctionnelles données ci- dessus .

Claims

REVENDICATIONS
1. Elément sécurisé embarqué (E) comprenant une mémoire volatile (PRAM) , et étant configuré pour mettre en oeuvre au moins une partie d'une première application (App30, App50) et au moins une partie d'une ou plusieurs deuxièmes applications (App31, App51) adaptées à être mises en oeuvre par au moins un système d'exploitation de bas niveau (113) de l'élément sécurisé embarqué (E) , dans lequel :
des données d'exécution de ladite première application (App30, App50) sont stockées dans une première partie réservée de ladite mémoire volatile (PRAM) configurée pour stocker uniquement des données d'exécution de ladite première application (App30, App50) ; et
des données d'exécution desdites deuxièmes applications sont stockées dans une deuxième partie de ladite mémoire volatile (PRAM) distincte de la première partie réservée de ladite mémoire volatile (PRAM) .
2. Procédé d'exécution d'au moins une partie d'une première application (App30, App50) et d'au moins une partie d'une ou plusieurs deuxièmes applications (App31, App51) adaptées à être mises en oeuvre par au moins un système d'exploitation de bas niveau (113) dans un élément sécurisé embarqué (E) comprenant une mémoire volatile (PRAM) , dans lequel :
des données d'exécution de ladite première application (App30, App50) sont stockées dans une partie réservée de ladite mémoire volatile (PRAM) configurée pour recevoir uniquement des données d'exécution de ladite première application ; et
des données d'exécution desdites deuxièmes applications sont stockées dans une deuxième partie de ladite mémoire volatile (PRAM) distincte de la première partie réservée de ladite mémoire volatile (PRAM) .
3. Elément selon la revendication 1, ou procédé selon la revendication 2, dans lequel ledit au moins un système d'exploitation de bas niveau (113) est un système d'exploitation adapté à échanger des commandes directement avec des composants (111) de l'élément sécurisé embarqué (E) .
4. Elément selon la revendication 1 ou 3, ou procédé selon la revendication 2 ou 3, dans lequel les données d'exécution d'une application sont des données temporaires utilisées par une application uniquement pendant son exécution.
5. Elément selon l'une quelconque des revendications 1, 3 ou
4, ou procédé selon l'une quelconque des revendications 2 à 4, dans lequel la partie de ladite première application (App30, App50) est la totalité de ladite première application (App30, App50) .
6. Elément selon l'une quelconque des revendications 1, 3 à 5, ou procédé selon l'une quelconque des revendications 2 à 5, dans lequel l'élément sécurisé embarqué (E) comprend une mémoire non volatile (VRAM) .
7. Elément ou procédé selon la revendication 6, dans lequel des données d'exécution relatives à une ou plusieurs tâches secondaires de ladite première application (App50) sont stockées dans une première partie réservée de ladite mémoire virtuelle (VRAM) quand la première partie de ladite mémoire volatile (PRAM) est pleine.
8. Elément ou procédé selon la revendication 6 ou 7, dans lequel des données d'exécution relatives à une ou plusieurs tâches secondaires de ladite première application (App50) sont stockées dans une première partie réservée de ladite mémoire virtuelle (VRAM) quand la première partie de ladite mémoire volatile (PRAM) est pleine.
9. Elément ou procédé selon revendication 8, dans lequel une tâche secondaire d'une application est une tâche de l'application qui n'est pas en cours d'exécution.
10. Elément selon l'une quelconque des revendications 1, 3 à 9, ou procédé selon l'une quelconque des revendications 2 à 9, dans lequel l'élément sécurisé est configuré pour mettre en oeuvre au moins une troisième application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau (113) de l'élément sécurisé embarqué (E) .
11. Elément ou procédé selon la revendication 10, dans lequel les données d'exécution de ladite troisième application (App50) sont stockées dans la première partie réservée de ladite mémoire volatile (PRAM) configurée pour stocker uniquement des données d'exécution de ladite première application .
12. Elément selon l'une quelconque des revendications 1, 3 à
11, ou procédé selon l'une quelconque des revendications 2 à 11, dans lequel les données d'exécution de ladite première application (App30, App50) restent stockées dans une première partie réservée de ladite mémoire volatile (PRAM) lorsque ladite première application (App30, App50) est en veille.
13. Elément selon l'une quelconque des revendications 1, 3 à
12, ou procédé selon l'une quelconque des revendications 2 à 12, dans lequel la première partie réservée de ladite mémoire volatile (PRAM) stocke les données d'exécution desdites deuxièmes applications quand ladite première application n'a pas de données d'exécution stockées dans ladite première partie.
14. Elément selon l'une quelconque des revendications 1, 3 à
13, ou procédé selon l'une quelconque des revendications 2 à 13, dans lequel la ta ille de la première partie réservée de ladite mémoire volatile (PRAM) est modifiable.
15. Elément selon l'une quelconque des revendications 1, 3 à
14, ou procédé selon l'une quelconque des revendications 2 à 14, dans lequel les première et deuxièmes applications n'ont accès qu'à leurs données d'exécution dans la mémoire virtuelle grâce à un système de protection.
16. Elément selon l'une quelconque des revendications 1, 3 à
15, ou procédé selon l'une quelconque des revendications 2 à 15, dans lequel la mémoire virtuelle (VRAM) est une partie d'une mémoire non volatile utilisée comme une mémoire volatile .
17. Elément selon l'une quelconque des revendications 1, 3 à
15, ou procédé selon l'une quelconque des revendications 2 à 16, dans lequel la mémoire virtuelle (VRAM) est interne à l'élément sécurisé (E) .
18. Elément selon l'une quelconque des revendications 1, 3 à
16, ou procédé selon l'une quelconque des revendications 2 à 16, dans lequel la mémoire non volatile est externe à l'élément sécurisé (E) .
19. Application adaptée à être mise en oeuvre par au moins un système d'exploitation de bas niveau (113) dans un élément sécurisé embarqué selon l'une quelconque des revendications 1, 3 à 18.
PCT/EP2020/058434 2019-03-26 2020-03-25 Élément sécurisé embarqué WO2020193664A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/479,275 US12045336B2 (en) 2019-03-26 2021-09-20 Embedded secure element

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1903168A FR3094526A1 (fr) 2019-03-26 2019-03-26 Elément sécurisé embarqué
FR1903168 2019-03-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/479,275 Continuation-In-Part US12045336B2 (en) 2019-03-26 2021-09-20 Embedded secure element

Publications (1)

Publication Number Publication Date
WO2020193664A1 true WO2020193664A1 (fr) 2020-10-01

Family

ID=67660243

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/EP2020/058434 WO2020193664A1 (fr) 2019-03-26 2020-03-25 Élément sécurisé embarqué
PCT/EP2020/058432 WO2020193663A1 (fr) 2019-03-26 2020-03-25 Elément sécurisé embarqué

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/058432 WO2020193663A1 (fr) 2019-03-26 2020-03-25 Elément sécurisé embarqué

Country Status (2)

Country Link
FR (1) FR3094526A1 (fr)
WO (2) WO2020193664A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11768943B2 (en) 2021-02-02 2023-09-26 Proton World International N.V. Secure element and method for starting an application by a low-level operating system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170269863A1 (en) * 2016-03-21 2017-09-21 Kabushiki Kaisha Toshiba Electronic apparatus including memory modules that can operate in either memory mode or storage mode

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170269863A1 (en) * 2016-03-21 2017-09-21 Kabushiki Kaisha Toshiba Electronic apparatus including memory modules that can operate in either memory mode or storage mode

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DUO LIU ET AL: "Non-Volatile Memory Based Page Swapping for Building High-Performance Mobile Devices", IEEE TRANSACTIONS ON COMPUTERS, vol. 66, no. 11, 1 November 2017 (2017-11-01) - 1 November 2017 (2017-11-01), USA, pages 1918 - 1931, XP055435524, ISSN: 0018-9340, DOI: 10.1109/TC.2017.2711620 *
HAN JUNYEONG ET AL: "A Hybrid Swapping Scheme Based On Per-Process Reclaim for Performance Improvement of Android Smartphones (August 2018)", IEEE ACCESS, vol. 6, 25 February 2018 (2018-02-25), pages 56099 - 56108, XP011693606, DOI: 10.1109/ACCESS.2018.2872794 *
KLAUS KURSAWE ET AL: "Flexible [mu]TPMs through disembedding", INFORMATION, COMPUTER, AND COMMUNICATIONS SECURITY, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 10 March 2009 (2009-03-10), pages 116 - 124, XP058175313, ISBN: 978-1-60558-394-5, DOI: 10.1145/1533057.1533075 *
SEUNGKYUN KIM ET AL: "Demand Paging Techniques for Flash Memory Using Compiler Post-Pass Optimizations", ACM TRANSACTIONS ON EMBEDDED COMPUTING SYSTEMS., vol. 10, no. 4, 1 November 2011 (2011-11-01), US, pages 1 - 29, XP055220750, ISSN: 1539-9087, DOI: 10.1145/2043662.2043664 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11768943B2 (en) 2021-02-02 2023-09-26 Proton World International N.V. Secure element and method for starting an application by a low-level operating system

Also Published As

Publication number Publication date
WO2020193663A1 (fr) 2020-10-01
FR3094526A1 (fr) 2020-10-02

Similar Documents

Publication Publication Date Title
EP2735969B1 (fr) Ensemble électronique comprenant un module de desactivation
EP2988243B1 (fr) Dispositif et procédé pour assurer des services de module de plateforme sécurisée
WO2002025437A1 (fr) Architecture de microprocesseur virtuel multiplate-forme et son systeme d'exploitation complementaire, notamment pour le domaine de l'informatique embarquee et mobile
FR2892261A1 (fr) Procede et systeme de gestion des applications d'un terminal mobile
WO2020193664A1 (fr) Élément sécurisé embarqué
EP1605333A1 (fr) Contrôle de l'exécution d'un programme
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
EP2466471A1 (fr) Module matériel de sécurité et procédé de débogage d'un tel module
EP2024798B1 (fr) Procédé et dispositif de configuration sécurisée d'un terminal au moyen d'un dispositif de stockage de données de démarrage
EP1960934B1 (fr) Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif
EP1228654A1 (fr) Procede de mise a jour d'un programme principal execute par un module de radiocommunication
WO2006111441A2 (fr) Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce
FR3114671A1 (fr) Elément sécurisé embarqué
FR3114670A1 (fr) Elément sécurisé embarqué
EP1810129A1 (fr) Systeme et calculateur embarque permettant la mise en suspens du dechargement de donnees en cas d'arret du calculateur
EP4036717A1 (fr) Démarrage d'une application
EP2252978B1 (fr) Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant
WO2008125479A1 (fr) Procédé d'exécution sécurisée d'une application
FR3144338A1 (fr) Protection d'un dispositif électronique
EP3907638B1 (fr) Contrôleur de démarrage sécurisé pour un système embarqué, système embarqué et procédé de démarrage sécurisé associés
WO2017001770A1 (fr) Procédé de gestion de profils dans un élément sécurisé
EP3893135A1 (fr) Procédé d'authentification
EP3923169A1 (fr) Démarrage sécurisé d'un circuit électronique
FR2962241A1 (fr) Verification de la mise en fonction d'un equipement embarque dans un vehicule
FR3087919A1 (fr) Carte a puce multiapplicative et procede de communication mis en oeuvre par une telle carte a puce

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20712601

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20712601

Country of ref document: EP

Kind code of ref document: A1