WO2013004854A2 - Système de traitement - Google Patents

Système de traitement Download PDF

Info

Publication number
WO2013004854A2
WO2013004854A2 PCT/EP2012/069498 EP2012069498W WO2013004854A2 WO 2013004854 A2 WO2013004854 A2 WO 2013004854A2 EP 2012069498 W EP2012069498 W EP 2012069498W WO 2013004854 A2 WO2013004854 A2 WO 2013004854A2
Authority
WO
WIPO (PCT)
Prior art keywords
trusted
memory
access
region
verification
Prior art date
Application number
PCT/EP2012/069498
Other languages
English (en)
Other versions
WO2013004854A3 (fr
Inventor
Peter Rombouts
Ventzislav Nikov
Original Assignee
Nxp B.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 Nxp B.V. filed Critical Nxp B.V.
Publication of WO2013004854A2 publication Critical patent/WO2013004854A2/fr
Publication of WO2013004854A3 publication Critical patent/WO2013004854A3/fr

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
    • 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
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • 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/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • This invention relates to processing systems, and more particularly to controlling access of a processing unit of a processing system to data stored by a memory of the processing system
  • Security is an important consideration for processing systems such as microcontrollers. For example, it may be desirable to ensure that a processor only executes a specific task which is described by a piece of executable program code (or equivalent set of instructions, such as a script for example)
  • Attacks may include any of the following exemplary list:
  • signatures computed over code binaries are used to prevent the loading of an unauthorized program code image into memory or to verify the integrity of program code before running it.
  • signature verification concepts are typically implemented as a software routine in a boot program or an operating system.
  • Such memory protection units are controlled by the same processor they are designed to protect and, as a result, are still vulnerable to attacks.
  • a processing system is proposed that can be protected against attacks and/or the execution of unsafe or unauthorized code. Embodiments may therefore prevent the execution of untrusted software or program code. Further protection may also be provided against software reverse engineering by controlling access to the stored program code. Embodiments may achieve this by verifying program code and subsequently assuring that this verified code is executed unaltered.
  • the processing system may be a smart card, an integrated circuit, a microcontroller, a microprocessor, a microchip or a processing platform. Therefore the processor may be a central processing unit (CPU) or a processor core.
  • CPU central processing unit
  • Figure 1 is a schematic block diagram of a processing system according to an embodiment of the invention.
  • Figure 2 is a schematic block diagram of a microcontroller arrangement according to an embodiment of the invention.
  • Figure 3 is a flow diagram of a method according to an embodiment of the invention.
  • proposed embodiments further comprise two additional devices: a verification unit (otherwise referred to as a 'verifier') and an access control unit (otherwise referred to as a 'gatekeeper').
  • a verification unit otherwise referred to as a 'verifier'
  • an access control unit otherwise referred to as a 'gatekeeper'
  • the verifier and the gatekeeper work in conjunction which each other to protect the processing system from unwanted or unauthorized attacks.
  • the verification unit (or verifier) is responsible for verifying areas of the memory and configuring conditions and/or parameters which can be used by the access control unit (or gatekeeper) to control access to the memory.
  • the verifier may be adapted to check program code signatures and to set trust parameters for use by the gatekeeper.
  • the access control unit controls access to the memory. It may therefore restrict access that components of the processing system have to areas of memory. A decision by the gatekeeper to grant or deny access to certain memory areas may be conditional on a set of configurable parameters. For example, in a particular embodiment, the gatekeeper may be adapted to allow or deny fetching of program code from certain regions in memory based on whether this code is indicated to be trusted by the verifier. Thus, the processor unit may be restricted to only have access to the areas of memory that are identified as requiring trust (e.g. areas having a signatures) and also confirmed as being trusted by verification of the trusted status. Put another way, the processor unit can be prevented from accessing all areas of memory except those which have been verified by the verifier.
  • requiring trust e.g. areas having a signatures
  • the processor unit may have full (data) read/write access to the memory, except for the regions which are configured to require verification. These regions may only become accessible after a successful verification (i.e. once they are confirmed to be trusted) and their access conditions may depend on their contents (as defined in a header field for example). By way of example, code regions become execute only and constant data regions become read-only. Further, a more extensive header format may be used and allow the definition of further memory regions and corresponding access restrictions.
  • Exemplary pseudo-code to determine the access conditions may be as follows: (i) If an identified region is not a protected region, then allow data access (read and write) and disallow code (fetch) access. End procedure.
  • Embodiments may also protect the program code by restricting read access.
  • a verification unit acts as a strong root of trust
  • This verification unit performs code verification and configures the access control unit depending on the result of the verification
  • the access control unit only accepts configuration from the verification unit; i.e. its configuration is inaccessible from any other part of the system such as e.g. the CPU;
  • the access control unit prevents modification of the verified code (for example, all writing permissions, may be revoked prior to the start of a verification process undertaken by the verification unit);
  • the access control unit prevents fetching of code from any part of memory except for code verified by the verification unit (i.e. verified code);
  • the access control unit prevents data read operations from the program code image, except for the verification unit (including all read attempts prior to it having been verified);
  • the access control unit is adapted to be able to distinguish between a code fetch and a data read operation. In most conventional processing systems, these operations are performed using different busses or can be distinguished based on the bus signals. This can therefore be used by the access control unit to make the distinction. In other cases, a signal to differentiate the two operations may be generated which can then be used by the access control unit.
  • FIG 1 there is shown a schematic block diagram of a processing system 100 according to an embodiment of the invention.
  • the system comprises a processor unit or CPU 102 connected to communication bus 104. Also connected to the communication bus 104 (via respective interfaces 106a, 108a, and 110a) are volatile 106 and non- volatile 108 memory units, and peripherals 110.
  • system of Figure 2 further comprises a verification unit 112 and an access control unit 114 connected to the communication bus 104.
  • the verification unit 112 is adapted to determine trusted areas of the memory 106,108 by verifying the authenticity of stored program code for example.
  • the verification unit 1 12 is also adapted to determine conditions and/or parameters which can be used by the access control unit 114 to control access to the memory 106, 108.
  • the access control unit 114 is adapted to control access to the memory 106,108. It is therefore configured to restrict access that components of the processing system have to areas of the memory 106,108.
  • the access control unit 114 determines whether to grant or deny access to certain memory areas based on information from the verification unit 112 which indicates the authenticity or trustworthiness of the access request and/or data within the memory area(s). For example, here, the access control unit 1 14 is adapted to allow or deny fetching of program code from the non- volatile memory 108 based on whether program code stored by the non- volatile memory 108 is indicated to be trusted by the verification unit 112.
  • Trusted program code resides in a trusted code image which may, for example, be stored in non-volatile memory 108.
  • a trusted code image may, for example, be stored in non-volatile memory 108.
  • one or more trusted code images may be stored by the non- volatile memory 108 of the system 100.
  • the trusted code image comprises at least the following components:
  • - header contains information for verifying the code image
  • - program code the executable part of the code image, preferably read-only and executable; and - constant data: the non-executable part of the code image containing constants and initialization data required by the code (it is preferably readonly and non-executable).
  • the header, program code and constant data segments are stored in non-overlapping continuous memory regions (although it will be understood that alternative embodiments may be adapted to also support non- continuous memory regions).
  • the three segments do not need to be stored in consecutive memory areas.
  • the header comprises the following information: the address range that contains the program code; the address range that contains the constant data; and signature over the concatenation of the two address ranges, the code and the constant data
  • MAC Message Authentication Code
  • the verification unit 1 12 holds the processing unit (CPU) 102 in reset mode and configures the access control unit 114 such that all access to trusted code images is blocked (i.e. non-executable, non-readable and non-writable), except for the verification unit 112 itself which has read-only access.
  • the verification unit 112 then verifies one or more trusted code images (see verification procedure below). When verification succeeds for a trusted code image, the verification unit 112 re-configures the corresponding access restrictions for the access control unit 114 such that instruction fetch from program code segment and read-only access from the constant data segment are permitted.
  • the verification unit 112 releases processing unit (CPU) 102 from the reset mode and a normal boot procedure starts.
  • the access control unit 114 monitors all memory access operations and blocks/denies or allows certain operations based on the configuration information provided by the verification unit 112.
  • the verification unit 112 may perform additional verifications triggered by a request from software running on the processor unit (CPU) 102.
  • the verification unit 1 12 may also be periodically triggered (e.g. by a hardware timer) to perform a re-verification of an already verified trusted code image.
  • This section describes an exemplary verification procedure.
  • the verification unit 112 knows the starting address of the header of the trusted code image(s) it needs to verify.
  • the verification unit 112 may store a list of such addresses. The verification procedure is repeated for each of the trusted code images.
  • the verification unit 112 reads the header of the trusted code image and computes a message digest over the address ranges of the header, the code segment and the constant data segment. It then uses the message digest to verify the signature using any suitable prior art method.
  • the Verification Unit 112 The Verification Unit 112
  • the verification unit 112 acts as the root of trust and verifies a code image. Depending on the result of this verification, it configures the access control unit 112 to permit or deny retrieval and/or execution of the code image.
  • the code image contains redundant information.
  • this redundant information may be a cryptographic signature, message authentication code (MAC) or any other suitable information.
  • the verification of the code image by the verification unit 112 may be triggered automatically or on request. Also, the verification unit 1 12 may perform the verification on the entire code image at once or it may perform the verification in chunks.
  • verification unit 112 can be implemented. Some exemplary implementations may be as follows:
  • the verification unit 112 may be implemented as a hardware core performing verification of the code image and the configuration of the access control unit 114. When implemented in this way, the verification unit 1 12 will be difficult to attack and therefore provide a strong root of trust.
  • the verification unit 112 may be partly implemented in the processor (platform) and partly in a secure device such as a secure element (SE).
  • SE secure element
  • the part implemented in the processor (platform) acts as a gateway providing a secure link to the secure device which performs the verification of the code image and the configuration of the access control unit.
  • the secure device provides a strong root of trust and offers more flexibility than implementation as a hardware core. However, the gateway will have to provide a strong secure link to the secure device.
  • the verification unit 1 12 may be implemented as a software routine running on the processor (platform) and performing the verification of the code image and the configuration of the access control unit 114.
  • This implementation provides only a weak root of trust since the access control unit 1 14 needs to accept configuration by software.
  • the access control unit 114 may therefore need to implement additional security measures, such as a source check for example.
  • a source check checks that that the code that is configuring the parameters is in fact the code that is supposed to do this.
  • the addresses of the fetched instructions can be recorded, and when parameters are configured, a check can be made that these addresses have the expected values.
  • the code of the verification unit 112 can also not be checked it should preferably not be alterable (for example, reside in ROM or be protected against writing by the access control unit 114).
  • the verification unit 1 12 may use secrets or key values and as such become a target for attack itself.
  • the processing system 100 may therefore need to provide secure storage and the implementation of the verification unit 112 may require countermeasures against side channel and fault attacks.
  • the access control unit 114 maintains the trust established by the verification unit 112 by controlling access to program code and enforcing that only trusted code is accessed and/or executed.
  • the access control unit 114 may also enforce further access restrictions that prevent a code image from being copied, and may also protect other memory areas.
  • the access control unit 114 bases its determination of the memory regions it must protect and/or the access restrictions it must enforce on information from the verification unit 112. Preferably, the access control unit 1 14 only accepts information from the verification unit 112 when making such a determination.
  • the access control unit 114 is adapted to remain active at all times.
  • the initial configuration of the access control unit 114 may depend on the embodiment, but in most cases it will be adapted to block all memory accesses except those performed by the verification unit 1 12.
  • the initial configuration may need to allow access of the processor 102 (CPU) to the memory.
  • the configuration of the access control unit 1 14 may contain any of the following parameters:
  • memory (address) regions which the source address of the instruction being executed comes from for example, read access to a certain memory region may be restricted to certain software routines who's code resides in a specific memory region
  • the source device the access attempt comes from for example, the verification unit 1 12 may be allowed to read from all memory regions but not from peripherals, whereas the processor may only be allowed to read from certain memory regions but is allowed to read from all peripherals).
  • the access control unit 1 14 may be implemented in a centralized or distributed manner, depending on the embodiment.
  • one device implements the access control unit 114 functionality and manages all memories.
  • each memory type may have its own device implementing a part of the access control unit 114 functionality only for that particular memory.
  • the access control unit 114 may be implemented, depending on the embodiment, as part of an existing component of a processor (platform) such as a Memory Management Unit, a Memory Protection Unit, an Address Decoder, a Memory Interface (in case of a distributed implementation), or it may be implemented as a separate device.
  • a processor platform
  • a Memory Management Unit such as a Memory Management Unit, a Memory Protection Unit, an Address Decoder, a Memory Interface (in case of a distributed implementation)
  • a Memory Interface in case of a distributed implementation
  • the access control unit 114 may therefore prevent the processing unit (CPU) 102 from executing a command in several different ways. For example it may generate a memory error, trigger an interrupt, provide a non-executable instruction, return a NOP instruction, or a combination thereof.
  • the microcontroller arrangement 200 comprises a microcontroller unit (MCU) 202, otherwise referred to as a central processing unit (CPU).
  • Memory 204 for storing program code is connected to the MCU 202 via an access control unit 206.
  • Also connected to the MCU 202 is a shared memory unit 208 and a mixed signal unit 210.
  • An I/O interface 212 for inputting/outputting data to/from shared memory unit 208 is provided.
  • a verification unit 214 is connected to the access control unit 206, but is also adapted to have access to the MCU 202 and memory 204 (as indicated by the dashed lines in Figure 2).
  • the access control unit 206 contains a set of records, whereby each record comprises the following fields: start address, end address, execute flag, read flag, write flag.
  • the start and end address define a region of the memory 204 for which access permissions are defined by the flags. If the execute flag is set, then program code fetches are allowed from addresses within the defined region of memory 204. The same applies mutatis mutandis to the read and write flags, i.e. executable-only for program code and read-only for constant data.
  • the set of records are configured by the verification unit 214. More specifically, the verification unit 214 determines trusted areas of the memory 204 by verifying the authenticity of stored program code for example. If verification succeeds for stored program code, the verification unit 214 configures the corresponding access restrictions for the access control unit 114 by setting the fields of a corresponding record to have appropriate values.
  • the access control unit 206 continuously monitors communication between the MCU 202 and the memory 204 to determine if access is permitted or not.
  • the access control unit 206 can extract the following information from the communication link between the MCU 202 and the memory 204:
  • the access control unit 206 looks up a record corresponding to the requested address. If no record is found, access is granted or denied depending on a predetermined default setting. If a record is found, the access control unit 206, grants or denies the access depending on the flag value set in the record for the requested type of access.
  • FIG. 3 there is illustrated a flow diagram of a method according to an embodiment of the invention.
  • the method provides for the controlling of access of a processing unit of a processing system to data stored by a memory of the processing system.
  • the method begins in step 302 with the step of identifying a region of the memory that is indicated to be trusted.
  • the starting address of the header of a trusted code image may be identified (from a database or by scanning the memory for example).
  • step 304 the data stored in the identified trusted memory region is processed in accordance with a verification algorithm to verify is the trusted status of the memory region is correct.
  • a message digest may be computed over the address ranges of the header, the code and the constant data segments of the trusted code image. The computed message digest may then be used to verify if the trusted code image does in fact adhere to security requirements that indicate the code image is to be trusted.
  • step 306 access of the processing unit to data stored in the trusted memory region is controlled based on the result of the verification step (step 204), i.e. base on whether or not the trusted status of the trusted memory region has been verified as correct. For example, access to data stored in the trusted memory region can be granted or denied depending on whether the trustworthiness of the trusted memory region has been verified in step 204.
  • Embodiments may be captured in a computer program product for execution on a processor of a computer, e.g. a personal computer or a network server, where the computer program product, if executed on the computer, causes the computer to implement the steps of a method according to an embodiment. Since implementation of these steps into a computer program product requires routine skill only for a skilled person, such an implementation will not be discussed in further detail for reasons of brevity only.
  • the computer program product is stored on a computer- readable medium.
  • a computer-readable medium e.g. a CD-ROM, DVD, USB stick, memory card, network-area storage device, internet-accessible data repository, and so on, may be considered.
  • a computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid- state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système de traitement comprenant: un processeur; une mémoire conçue pour stocker des données utilisables par le processeur; une unité de vérification conçue pour identifier une zone de confiance de la mémoire et y traiter les données stockées, selon un algorithme de vérification prédéterminé, en vue de vérifier l'état de confiance de la zone mémoire de confiance; et une unité de commande d'accès à la mémoire conçue pour commander l'accès de l'unité de traitement aux données stockées dans la zone mémoire de confiance selon que l'état de confiance de cette dernière est vérifié ou non par l'unité de vérification.
PCT/EP2012/069498 2012-09-26 2012-10-02 Système de traitement WO2013004854A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP12186083.7 2012-09-26
EP12186083 2012-09-26

Publications (2)

Publication Number Publication Date
WO2013004854A2 true WO2013004854A2 (fr) 2013-01-10
WO2013004854A3 WO2013004854A3 (fr) 2013-07-18

Family

ID=47115295

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/069498 WO2013004854A2 (fr) 2012-09-26 2012-10-02 Système de traitement

Country Status (1)

Country Link
WO (1) WO2013004854A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017102295A1 (fr) * 2015-12-15 2017-06-22 Siemens Aktiengesellschaft Procédé et module de sécurité pour produire une fonction de sécurité pour un appareil
WO2020079389A1 (fr) * 2018-10-19 2020-04-23 Arm Limited Signature de paramètre pour des paramètres de configuration de sécurité de domaine

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7509644B2 (en) * 2003-03-04 2009-03-24 Secure 64 Software Corp. Operating system capable of supporting a customized execution environment
MX2010014464A (es) * 2008-06-24 2011-02-22 Nagravision Sa Sistema y metodo para el manejo seguro de memoria.
JP5519773B2 (ja) * 2009-04-15 2014-06-11 インターデイジタル パテント ホールディングス インコーポレイテッド ネットワークとの通信のためのデバイスの正当化および／または認証

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017102295A1 (fr) * 2015-12-15 2017-06-22 Siemens Aktiengesellschaft Procédé et module de sécurité pour produire une fonction de sécurité pour un appareil
WO2020079389A1 (fr) * 2018-10-19 2020-04-23 Arm Limited Signature de paramètre pour des paramètres de configuration de sécurité de domaine
CN112789613A (zh) * 2018-10-19 2021-05-11 Arm有限公司 用于领域安全性配置参数的参数签名
US12001541B2 (en) 2018-10-19 2024-06-04 Arm Limited Parameter signature for realm security configuration parameters

Also Published As

Publication number Publication date
WO2013004854A3 (fr) 2013-07-18

Similar Documents

Publication Publication Date Title
US8464011B2 (en) Method and apparatus for providing secure register access
JP5007867B2 (ja) 安全な環境におけるプロセッサ実行を制御するための装置
US7139915B2 (en) Method and apparatus for authenticating an open system application to a portable IC device
US7010684B2 (en) Method and apparatus for authenticating an open system application to a portable IC device
CN106855814B (zh) 管理基本输入输出系统设定的系统和方法
EP2854066B1 (fr) Système et méthode de vérification de l'intégrité du firmware en utilisant plusieurs clés et mémoire OTP
US7917741B2 (en) Enhancing security of a system via access by an embedded controller to a secure storage device
JP5402498B2 (ja) 情報記憶装置、情報記憶プログラム、そのプログラムを記録した記録媒体及び情報記憶方法
KR101567620B1 (ko) 데이터 처리 시스템 및 방법
US20090193211A1 (en) Software authentication for computer systems
US20090288161A1 (en) Method for establishing a trusted running environment in the computer
CN113254949B (zh) 控制设备、用于控制访问的系统及由控制器执行的方法
KR20110104481A (ko) 비휘발성 메모리에 대한 데이터 액세스 제어
WO2016065636A1 (fr) Procédé de gestion de données et dispositif de gestion de données pour terminal, et terminal
US10742412B2 (en) Separate cryptographic keys for multiple modes
US20160004859A1 (en) Method and system for platform and user application security on a device
WO2013004854A2 (fr) Système de traitement
CN113678129A (zh) 授权对计算机化系统中的对象的访问的方法、计算机程序产品和现场设备
KR100439171B1 (ko) 접근제어 처리 기법을 이용한 클라이언트와 시스템간의신뢰경로 보장 방법
CN108345804B (zh) 一种可信计算环境中的存储方法和装置
KR20180015723A (ko) 보안 구역과 하위 보안 구역 사이의 전이를 위한 장치 및 방법
KR102201218B1 (ko) 모바일 단말의 보안 엔진의 접근 제어 시스템 및 방법
KR930004434B1 (ko) 다중 등급기밀 데이타 보호용 액세스 제어방법
WO2024078159A1 (fr) Procédé et appareil de mesure d'intégrité
EP4155957A1 (fr) Procédé de gestion de l'accès par fil à un dispositif esclave

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: 12780428

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 12780428

Country of ref document: EP

Kind code of ref document: A2