EP3214613B1 - Protecting the content of different ip cores in a system on chip using pufs - Google Patents
Protecting the content of different ip cores in a system on chip using pufs Download PDFInfo
- Publication number
- EP3214613B1 EP3214613B1 EP16464002.1A EP16464002A EP3214613B1 EP 3214613 B1 EP3214613 B1 EP 3214613B1 EP 16464002 A EP16464002 A EP 16464002A EP 3214613 B1 EP3214613 B1 EP 3214613B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- puf
- core
- monitor
- mon
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000004044 response Effects 0.000 claims description 40
- 238000000034 method Methods 0.000 claims description 29
- 238000004891 communication Methods 0.000 claims description 19
- 238000013461 design Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 10
- 230000015654 memory Effects 0.000 description 10
- 230000007246 mechanism Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 6
- 238000004519 manufacturing process Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 229920000729 poly(L-lysine) polymer Polymers 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
- G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
- H04L9/3278—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response using physically unclonable functions [PUF]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/12—Details relating to cryptographic hardware or logic circuitry
Definitions
- the present invention relates to a method implemented in a computer system for protecting the content of different IP cores in a system on chip using at least one. PUF device.
- the present invention also comprises a respective system on chip device.
- SoC system on chip
- IC integrated circuit
- SoCs A system on chip (IC) that integrates all components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and often radio-frequency functions, all on a single chip substrate.
- a typical application of SoCs is in the area of embedded systems.
- An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints.
- SoCs can be implemented as an application-specific integrated circuit (ASIC) or using a field-programmable gate array (FPGA).
- a field-programmable gate array (FPGA) is an integrated circuit designed to be configured by a customer or a designer after manufacturing.
- the FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC).
- HDL hardware description language
- IP core In electronic design a semiconductor intellectual property core, IP core, or IP block, is a reusable unit of logic, cell, or chip layout design that is the intellectual property of one party. IP cores may be licensed to another party or can be owned and used by a single party alone. The term is derived from the licensing of the patent and/or source code copyright that exist in the design. IP cores can be used as building blocks within ASIC chip designs or FPGA logic designs. IP cores can have the form of soft cores or hard cores.
- Soft cores are typically offered as synthesizable RTL (register-transfer level). Synthesizable cores are delivered in a hardware description language such as Verilog or VHDL. IP cores delivered to chip makers as RTL permit chip designers to modify designs at the functional level. Soft IP cores are also sometimes offered as generic gate-level netlists. The netlist is a boolean-algebra representation of the IP's logical function implemented as generic gates or process specific standard cells. An IP core implemented as generic gates is portable to any process technology. Both netlist and synthesizable cores allow a synthesis, placement and route (SPR) design flow.
- SPR synthesis, placement and route
- Hard cores by the nature of their low-level representation, offer better predictability of chip performance in terms of timing-performance and area.
- Analog and mixed-signal logic are generally defined as a lower-level, physical description.
- analog IP SerDes, PLLs, DAC, ADC, PHYs, etc.
- Digital IP cores are sometimes offered in layout format, as well.
- Such cores, whether analog or digital, are called “hard cores” (or hard macros), because the core's application function cannot be meaningfully modified by chip designers.
- a PUF (physical unclonable function) device or short “PUF" is a physical entity that is embodied in a physical structure and is easy to evaluate but hard to predict.
- a PUF is the hardware analog of a one-way function.
- PUFs are usually implemented in integrated circuits with high security requirements. PUFs depend on the uniqueness of their physical microstructure. This microstructure depends on random physical factors introduced during manufacturing. These factors are unpredictable and uncontrollable which makes it virtually impossible to duplicate or clone the structure.
- PUFs implement challenge-response authentication to evaluate this microstructure.
- a physical stimulus When a physical stimulus is applied to the structure, it reacts in an unpredictable (but repeatable) way due to the complex interaction of the stimulus with the physical microstructure of the device.
- the applied stimulus is called the challenge
- the reaction of the PUF is called the response.
- a specific challenge and its corresponding response together form a challenge-response pair.
- the device's identity is established by the properties of the microstructure itself. As this structure is not directly revealed by the challenge-response mechanism such a device is resistant to spoofing attacks.
- PUFs can also be used to extract a unique strong cryptographic key from the physical microstructure. The same unique key is reconstructed every time the PUF is evaluated. The challenge-response mechanism is then implemented using cryptography. In many applications it is important that the output is stable. If the PUF is used for a key in cryptographic algorithms it is necessary that error correction will be done to correct any errors caused by the underlying physical processes and reconstruct the exact same key each time under all operating conditions.
- a PUF establishes a data string which depends upon partially random physical characteristics of the physically unclonable function.
- the contents of a PUF cannot be predetermined, and PUF responses are somewhat noisy.
- PUFs have proven to be advantageous alternatives for many forms of secure identification, including the storing of keys, identifiers and the like in secure memories.
- the data string may depend on a stable state in which a configuration of components of the PUF settles upon the SoC's power-up.
- An example of a PUF is a volatile memory which shows a power-up contents which depends on the partially random physical characteristics of the memory. Manufacturing variations lead to different physical characteristics for different memories.
- a PUF furthermore provides natural protection against unauthorized attempts to obtain the cryptographic key through physical reverse engineering (also known as tampering), since damage inflicted on the PUF during the attempt would change the initial data string beyond repair. Since the behavior of a PUF depends on small variations, a certain error percentage is unavoidable. An error correction procedure can be used to correct for these fluctuations, and make sure that the reliable data string is identical, each time it is derived from the PUF. Using so-called helper data the initial data string is mapped to one or more error correctable data words.
- An error correctable data, word is a data word which is close to a code word of an error correcting code.
- An error correctable data word may be seen as the sum of a code word and an error word.
- PUF based security mechanisms are used to derive a device unique key, based on the intrinsic physical qualities of the silicone device itself.
- the helper data is generated, based on the PUF response and the encryption key provided by the manufacturer of the SoC or the IP core, respectively, and stored on-chip.
- the PUF response is used together with the helper data to regenerate the key. Once the helper data is generated there is no possibility to regenerate it as the enrolment mechanism is disabled.
- IP intellectual property
- US 6305005 B1 refers to methods to securely configure an FPGA using encrypted macros, that is, to methods for programming licensed software in an FPGA, specifically each CLB, IOB, PSM and PIP contains a configuration memory which must be configured before each CLB, IOB, PSM or PIP can perform a specified function.
- the method is only for using macros from dedicated vendors and with authorized FPGA programming tools.
- US 8181008 B2 refers to a secure system-on-chip for processing data and presents a method for securing real-time processing chains implemented in large SoCs.
- a supervision module compares the current conditions to a predefined set of values.
- the method also provides cryptographic primitives which are used to secure data transfer and memories.
- US 8670561 B1 refers to a method and apparatus for limiting use of IP. Megafunctions are pre-designed, pre-tested, parameterized cores (or blocks of IP) which, when used, complement and augment existing design methodologies. Use of a megafunction IP Core or other IP in a configurable device is controlled by a combination of protection circuits implemented in the configurable device with the IP and a secure device.
- One object of the present invention is to provide a possibility to protect two or more different IP cores from each other and to allow for secure communication between different IP cores of one system on chip.
- the method for protecting the content of different IP cores in a system on chip using at least one PUF device thus includes the following steps:
- this monitor By using this monitor as a security monitor, none of the two IP cores has any knowledge of the others secrets, like the secret keys for encryption and decryption, and no secret information, like the secret keys, is sent from one,IP core to the other.
- the system on chip can have more than two IP cores, so one monitor could also link three or more IP cores with each other, i.e. all communication between the three or more IP cores would run over the monitor only.
- the security monitor module ensures that only initially setup devices are allowed to exchange data and only if the respective keys are "paired", that is, if a certain IP core is allowed to exchange data with another certain IP core.
- One aspect of the invention is using a first PUF device of the first IP core for encrypting and decrypting data in the first IP core and/or using a second PUF device of the second IP core for encrypting and decrypting data in the second IP core.
- PUF devices provide for an easy encrypting/decrypting mechanism so the overhead for communication between different IP cores can be kept low.
- another embodiment of the invention is using the first PUF device to alter its PUF response if the first IP core has been physically changed and/or using the second PUF device to alter its PUF response if the second IP core has been changed. So if an IP core has been tampered with or if an IP core has been changed physically, e.g. if his location inside the system on chip (e.g. the FGPA) has been changed, this could be seen from the PUF response of the respective IP core which also has changed. Any physical change to the IP core influences the PUF response.
- Enrolment of the IP cores takes place only once, enrolment normally is done by the manufacturer using the manufacturer's encryption keys. Enrolment is disabled after the first enrolment. During enrolment helper data is created. During normal operation of the system on chip, that is, after enrolment, the keys are reconstructed using the PUF device and the helper data. So during normal operation of the SoC a PUF device is challenged. The PUF response is error corrected and the encryption key is reconstructed from the corrected PUF response and the previously stored helper data. The so generated key is then used to encrypt or decrypt data.
- the present invention further comprises a system on chip device for protecting the content of different IP cores according to the method of the present invention.
- the system includes
- This system on chip can include a first PUF device of the first IP core for encrypting and decrypting data in the first IP core and a second PUF device of the second IP core for encrypting and decrypting data in the second IP core.
- every IP core of the system on chip has its own PUF device.
- the first PUF device will normally be configured (meaning that it is the intrinsic function of such PUF device) to alter its PUF response if the first IP core has been physically changed and/or the second PUF device will normally be configured (meaning that it is the intrinsic function, of such PUF device) to alter its PUF response if the second IP core has been physically changed. This to detect any changes (attacks, heating, cooling, taking apart, etc.) in or to the respective IP core, as explained above.
- So the present invention provides for protection against leakage of sensitive information based on PUF circuits in a complex system on chip which contains third party IP cores.
- the system on chip can contain FPGA based designs and can be formed by a multitude of IPs, so it integrates several components in order to form an application specific hardware platform. These IPs are typically RTL synthesizable or layout level designs.
- the method targets SoCs implemented on FPGA devices, see Fig. 1 , but can also be extended to ASICs.
- the proposed method is used to secure data traffic between IP cores with critical or sensitive IPs. In order to reduce the performance impact only critical data is secured, e.g. only data generated by sensitive applications, similar to the concept known as TrustZone®.
- each critical IP component has a unique key.
- each critical/sensitive IP core has its own chip ID generation circuit, here e.g. a PUF device embedded into the IP core which PUF device uniquely characterizes the IP core.
- the communication partners that is, none of the IP cores, has any knowledge of the others secrets and none of the communication partners have to exchange their secrets.
- the first IP core does not know the secret key of the second IP core and vice versa.
- the security monitor only knows which data has to be sent to which IP core and has no possibility to change the data content.
- the encryption/decryption operations may be achieved using light cryptographic algorithms or by only securing critical data payloads.
- the object of the method according to the invention is to secure the data traffic between sensitive IPs and not the individual components (PUF device, error correction mechanism, cryptographic primitives, etc.) as such which are used for the method.
- PAF device error correction mechanism, cryptographic primitives, etc.
- Fig. 1 shows a possible structure for a system on chip device SoC according to the invention, implemented as FPGA.
- the system on chip device SoC here has two CPUs, CPU-0 and CPU-1, two communications protocol devices CoPr1, CoPr2, a memory MEM and an IP core IP_. All these items are connected by an internal bus B.
- Communications protocol device CoPr1 serves as interface to an authentication module AutM which is not part of the system on chip device SoC.
- Communications protocol device CoPr2 serves as interface to an external network NW outside the system on chip device SoC.
- One CPU CPU-0, communications protocol device CoPr1, part of the memory MEM (see respective box in Fig. 1 ) and part of the IP core IP_ (see respective box in Fig. 1 ) are dedicated to computing of critical data where the data traffic has to be secured.
- These components are having their traffic secured when communicating with an external device or component or system, such as for example an authentication module AutM.
- An authentication module AutM is used by the manufacturer to authenticate the chip in order to perform e.g. a software update for the system on chip device SoC. If the authentication fails then it is not an original chip or the system on chip device SoC has been tampered with (attacked, heated, cooled, etc).
- IP core IP_ is replaced by a security monitor, short monitor Mon, which connects the IP cores IP_A, IP_B to each other, see Fig. 2 .
- Monitor Mon and the IP cores IP_A, IP_B are part of the system on chip device SoC.
- each IP core IP_A, IP_B is placed in a fixed physical location inside the FGPA device. Afterwards the so called enrolment is performed. During this phase, each IP core IP_A, IP_B is provided with a unique encryption key, generated by the manufacturer. Each IP core IP_A, IP_B uses its key and the response of its own PUF device PUF_A, PUF_B to generate the so called helper data which is stored. More specifically, the process of enrolment starts with a first step where a challenge is sent to the PUF device and a PUF response, also called PUF answer, is generated.
- the PUF response is processed, that is, possible errors are corrected and this corrected data is used for the generation of the helper data, based on the corrected PUF response and on the manufacturer's encryption key, and next the helper data is stored in the SoC, e.g. in the respective own IP core IP_A, IP_B.
- the enrolment process starts with challenging the first PUF device PUF_A of the first IP core IP_A and generating first helper data HD_A by using the response of the first PUF device PUF_A and a first manufacturer's encryption key which is unique for the first IP core IP_A.
- the helper data HD_A is saved in the first IP core IP_A.
- the second PUF device PUF_B of the second IP core IP_B is challenged and generates second helper data HD_B by using the response of the second PUF device PUF_B and a second manufacturer's encryption key which is unique for the second IP core IP_B.
- the helper data HD_B is saved in the second IP core IP_B.
- the monitor During enrolment of protected IP cores IP_A, IP_B the monitor generates its own helper data to obtain the same keys as the ones of the authorized IP cores IP_A, IP_B. Therefore, for each key that is enrolled, that is for each IP core IP_A, IP_B that is secured, the monitor Mon module generates its own helper data. Referring to Fig.
- helper data HD_Mon_A is generated by using the (especially corrected) response of the monitor's PUF device PUF_Mon and the manufacturer's encryption key for the first IP core IP_A
- helper data HD_Mon_B is generated by using the (especially corrected) response of the monitor's PUF device PUF_Mon and the manufacturer's encryption key for the second IP core IP_B.
- the monitor Mon also contains a list of authorized IP cores and allowed communication schemes, e.g. which IP core is allowed to exchange data with another IP core, or which data may be exchanged. Based on this pre-programmed information the monitor Mon allows or denies the inter-IP-core communication.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Description
- The present invention relates to a method implemented in a computer system for protecting the content of different IP cores in a system on chip using at least one. PUF device. The present invention also comprises a respective system on chip device.
- A system on chip (SoC) is an integrated circuit (IC) that integrates all components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and often radio-frequency functions, all on a single chip substrate. A typical application of SoCs is in the area of embedded systems. An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints.
- SoCs can be implemented as an application-specific integrated circuit (ASIC) or using a field-programmable gate array (FPGA). A field-programmable gate array (FPGA) is an integrated circuit designed to be configured by a customer or a designer after manufacturing. The FPGA configuration is generally specified using a hardware description language (HDL), similar to that used for an application-specific integrated circuit (ASIC).
- In electronic design a semiconductor intellectual property core, IP core, or IP block, is a reusable unit of logic, cell, or chip layout design that is the intellectual property of one party. IP cores may be licensed to another party or can be owned and used by a single party alone. The term is derived from the licensing of the patent and/or source code copyright that exist in the design. IP cores can be used as building blocks within ASIC chip designs or FPGA logic designs. IP cores can have the form of soft cores or hard cores.
- Soft cores are typically offered as synthesizable RTL (register-transfer level). Synthesizable cores are delivered in a hardware description language such as Verilog or VHDL. IP cores delivered to chip makers as RTL permit chip designers to modify designs at the functional level. Soft IP cores are also sometimes offered as generic gate-level netlists. The netlist is a boolean-algebra representation of the IP's logical function implemented as generic gates or process specific standard cells. An IP core implemented as generic gates is portable to any process technology. Both netlist and synthesizable cores allow a synthesis, placement and route (SPR) design flow.
- Hard cores, by the nature of their low-level representation, offer better predictability of chip performance in terms of timing-performance and area. Analog and mixed-signal logic are generally defined as a lower-level, physical description. Hence, analog IP (SerDes, PLLs, DAC, ADC, PHYs, etc.) are provided to chip makers in transistor-layout format (such as GDSII). Digital IP cores are sometimes offered in layout format, as well. Such cores, whether analog or digital, are called "hard cores" (or hard macros), because the core's application function cannot be meaningfully modified by chip designers.
- A PUF (physical unclonable function) device, or short "PUF", is a physical entity that is embodied in a physical structure and is easy to evaluate but hard to predict. A PUF is the hardware analog of a one-way function. PUFs are usually implemented in integrated circuits with high security requirements. PUFs depend on the uniqueness of their physical microstructure. This microstructure depends on random physical factors introduced during manufacturing. These factors are unpredictable and uncontrollable which makes it virtually impossible to duplicate or clone the structure.
- Rather than embodying a single cryptographic key, PUFs implement challenge-response authentication to evaluate this microstructure. When a physical stimulus is applied to the structure, it reacts in an unpredictable (but repeatable) way due to the complex interaction of the stimulus with the physical microstructure of the device. The applied stimulus is called the challenge, and the reaction of the PUF is called the response. A specific challenge and its corresponding response together form a challenge-response pair. The device's identity is established by the properties of the microstructure itself. As this structure is not directly revealed by the challenge-response mechanism such a device is resistant to spoofing attacks.
- Using a fuzzy extractor or key extractor PUFs can also be used to extract a unique strong cryptographic key from the physical microstructure. The same unique key is reconstructed every time the PUF is evaluated. The challenge-response mechanism is then implemented using cryptography. In many applications it is important that the output is stable. If the PUF is used for a key in cryptographic algorithms it is necessary that error correction will be done to correct any errors caused by the underlying physical processes and reconstruct the exact same key each time under all operating conditions.
- A PUF establishes a data string which depends upon partially random physical characteristics of the physically unclonable function. The contents of a PUF cannot be predetermined, and PUF responses are somewhat noisy. PUFs have proven to be advantageous alternatives for many forms of secure identification, including the storing of keys, identifiers and the like in secure memories. The data string may depend on a stable state in which a configuration of components of the PUF settles upon the SoC's power-up. An example of a PUF is a volatile memory which shows a power-up contents which depends on the partially random physical characteristics of the memory. Manufacturing variations lead to different physical characteristics for different memories.
- Using a PUF the need for secure memory to store a key is circumvented. A PUF furthermore provides natural protection against unauthorized attempts to obtain the cryptographic key through physical reverse engineering (also known as tampering), since damage inflicted on the PUF during the attempt would change the initial data string beyond repair. Since the behavior of a PUF depends on small variations, a certain error percentage is unavoidable. An error correction procedure can be used to correct for these fluctuations, and make sure that the reliable data string is identical, each time it is derived from the PUF. Using so-called helper data the initial data string is mapped to one or more error correctable data words. An error correctable data, word is a data word which is close to a code word of an error correcting code. An error correctable data word may be seen as the sum of a code word and an error word. By applying an error correcting algorithm corresponding to the error correcting code, the error correctable data words are decoded into corrected and decoded data words.
- PUF based security mechanisms are used to derive a device unique key, based on the intrinsic physical qualities of the silicone device itself. During enrolment phase the helper data is generated, based on the PUF response and the encryption key provided by the manufacturer of the SoC or the IP core, respectively, and stored on-chip. During normal operation the PUF response is used together with the helper data to regenerate the key. Once the helper data is generated there is no possibility to regenerate it as the enrolment mechanism is disabled.
- In today's complex SoCs sensitive and less sensitive data are processed together on the same device, therefore keeping processing elements for different levels of sensitivity properly separated is compulsory. Custom IP cores, which are either acquired from third parties or developed in-house by the SoC designer, are subject to intellectual property (IP) rights. These IPs need to be protected against leakage of sensitive information caused either by hardware or software. Protecting IPs is a long standing problem for which solutions have been proposed in numerous publications and patents.
- "Survey of protection techniques for IP cores implemented in FPGA", Laavanya Sridhar, V. Lakshmi Prabha, International Journal of Emerging Trends in Engineering and Development (IJETED), Issue 2., Vol. 5, July 2012, categorizes attacks on FPGA-based IP cores as copying, reverse engineering and tampering. A tampered device may contain harmful design code capable of causing a system malfunction or stealing sensitive data. Many protection techniques have been in place such as those developed by the Virtual Socket Alliance.
-
US 6305005 B1 refers to methods to securely configure an FPGA using encrypted macros, that is, to methods for programming licensed software in an FPGA, specifically each CLB, IOB, PSM and PIP contains a configuration memory which must be configured before each CLB, IOB, PSM or PIP can perform a specified function. The method is only for using macros from dedicated vendors and with authorized FPGA programming tools. -
US 8181008 B2 refers to a secure system-on-chip for processing data and presents a method for securing real-time processing chains implemented in large SoCs. A supervision module compares the current conditions to a predefined set of values. The method also provides cryptographic primitives which are used to secure data transfer and memories. - "Designing secure systems on reconfigurable hardware", Huffmire, T., Brotherton, B., Callegari, N., Valamehr, J., White, J., Kastner, R., and Sherwood, T., ACM Trans. Des. Autom. Electron. Syst. Vol.13, No. 3, Article 44, July 2008, referring to a so called red/black system, in order to achieve isolation within a single device, introduces the concept of a fence. The fence is nothing more than a set of unused CLBs (Configurable Logic Blocks). In the fence, no routing or logic may be present.
-
US 8670561 B1 refers to a method and apparatus for limiting use of IP. Megafunctions are pre-designed, pre-tested, parameterized cores (or blocks of IP) which, when used, complement and augment existing design methodologies. Use of a megafunction IP Core or other IP in a configurable device is controlled by a combination of protection circuits implemented in the configurable device with the IP and a secure device. - Hiroyuki Tomiyama ET AL:
- "PUF_based Security Enhancement for Automotive Software Update", 21 June 2015 (2015-06-21) discloses a system for remote update of Automotive software comprising a OEM external server which can be connected to the infotainment or navigation system of a vehicle for updating remotely the software of the vehicle. The system comprises a security gateway comprising a PUF connected by a CAN to the vehicle system. The system permitting to update securely the vehicle.
- STANCIU ALEXANDRA ET AL: "A novel PUF-based encryption protocol for embedded System on Chip",2016 INTERNATIONAL CONFERENCE ON DEVELOPMENT AND APPLICATION SYSTEMS.
- All presented solutions tackle the same problems but neither of them uses .intrinsic security features in order to protect individual IPs nor do they provide means for inter-IP-communication based on strong security.
- The invention is defined by the independent claims. Preferred embodiments are set out in the dependent claims.
- One object of the present invention is to provide a possibility to protect two or more different IP cores from each other and to allow for secure communication between different IP cores of one system on chip.
- According to the present invention the method for protecting the content of different IP cores in a system on chip using at least one PUF device thus includes the following steps:
- decrypting data from the first IP core with a monitor, which is situated as a security gateway between first IP core and second IP core so that communication between first IP core and second IP core is only possible via the monitor, by using the monitor's PUF device,
- encrypting the data with the monitor by using the monitor's PUF device for the second IP core and sending the so encrypted data to the second IP core.
- By using this monitor as a security monitor, none of the two IP cores has any knowledge of the others secrets, like the secret keys for encryption and decryption, and no secret information, like the secret keys, is sent from one,IP core to the other. Of course, the system on chip can have more than two IP cores, so one monitor could also link three or more IP cores with each other, i.e. all communication between the three or more IP cores would run over the monitor only.
- The security monitor module ensures that only initially setup devices are allowed to exchange data and only if the respective keys are "paired", that is, if a certain IP core is allowed to exchange data with another certain IP core.
- One aspect of the invention is using a first PUF device of the first IP core for encrypting and decrypting data in the first IP core and/or using a second PUF device of the second IP core for encrypting and decrypting data in the second IP core. PUF devices provide for an easy encrypting/decrypting mechanism so the overhead for communication between different IP cores can be kept low.
- If PUF devices are used in the IP cores another embodiment of the invention is using the first PUF device to alter its PUF response if the first IP core has been physically changed and/or using the second PUF device to alter its PUF response if the second IP core has been changed. So if an IP core has been tampered with or if an IP core has been changed physically, e.g. if his location inside the system on chip (e.g. the FGPA) has been changed, this could be seen from the PUF response of the respective IP core which also has changed. Any physical change to the IP core influences the PUF response.
- One possibility to use the monitor's PUF device according to the invention is
- challenging the monitor's PUF device as part of the monitor,
- generating helper data by using the response of the monitor's PUF device and the manufacturer's encryption keys of first and second IP cores and storing the respective monitor's helper data during the enrolment phase,
- for sending data from the first IP core to the second IP core during normal operation, decrypting the data encrypted by the first IP core with the monitor by using the monitor's PUF device and the stored monitor's helper data for the first IP core and then encrypting the data with the monitor by using the monitor's PUF device and the stored monitor's helper data for the second IP core and sending the so encrypted data to the second IP core.
- Enrolment of the IP cores takes place only once, enrolment normally is done by the manufacturer using the manufacturer's encryption keys. Enrolment is disabled after the first enrolment. During enrolment helper data is created. During normal operation of the system on chip, that is, after enrolment, the keys are reconstructed using the PUF device and the helper data. So during normal operation of the SoC a PUF device is challenged. The PUF response is error corrected and the encryption key is reconstructed from the corrected PUF response and the previously stored helper data. The so generated key is then used to encrypt or decrypt data.
- The present invention further comprises a system on chip device for protecting the content of different IP cores according to the method of the present invention. The system includes
- a first IP core,
- a second IP core,
- a monitor which is situated as a security gateway between first IP core and second IP core so that communication between first IP core and second IP core is only possible via the monitor, said monitor containing a monitor's PUF device and being configured to decrypt data from the first IP core by using the monitor's PUF device and to encrypt data by using the monitor's PUF device for the second IP core and to send the so encrypted data to the second IP core.
- This system on chip can include a first PUF device of the first IP core for encrypting and decrypting data in the first IP core and a second PUF device of the second IP core for encrypting and decrypting data in the second IP core. Generally speaking, every IP core of the system on chip has its own PUF device.
- A specific aspect is characterized by
- the first IP core containing the first PUF device configured to generate first helper data by using the response of the first PUF device and a manufacturer's encryption key during the enrolment phase of the first IP core and to store the first helper data,
- the second IP core containing the second PUF device configured to generate second helper data by using the response of the second PUF device and a second manufacturer's encryption key during the enrolment phase of the second IP core and to store the second helper data,
- the monitor configured to generate helper data by using the response of the monitor's PUF device and the manufacturer's encryption keys of first and second IP cores and to store the respective monitor's helper data during the enrolment phase,
- for sending data from the first IP core to the second IP core during normal operation, the monitor being further configured to decrypt the data encrypted by the first IP core by using the monitor's PUF device and the stored monitor's helper data for the first IP core and then to encrypt the data by using the monitor's PUF device and the stored monitor's helper data for the second IP core and to send the so encrypted data to the second IP core.
- The first PUF device will normally be configured (meaning that it is the intrinsic function of such PUF device) to alter its PUF response if the first IP core has been physically changed and/or the second PUF device will normally be configured (meaning that it is the intrinsic function, of such PUF device) to alter its PUF response if the second IP core has been physically changed. This to detect any changes (attacks, heating, cooling, taking apart, etc.) in or to the respective IP core, as explained above.
- So the present invention provides for protection against leakage of sensitive information based on PUF circuits in a complex system on chip which contains third party IP cores. The system on chip can contain FPGA based designs and can be formed by a multitude of IPs, so it integrates several components in order to form an application specific hardware platform. These IPs are typically RTL synthesizable or layout level designs. The method targets SoCs implemented on FPGA devices, see
Fig. 1 , but can also be extended to ASICs. The proposed method is used to secure data traffic between IP cores with critical or sensitive IPs. In order to reduce the performance impact only critical data is secured, e.g. only data generated by sensitive applications, similar to the concept known as TrustZone®. - The proposed method is based on the fact that each critical IP component has a unique key. To generate the unique key each critical/sensitive IP core has its own chip ID generation circuit, here e.g. a PUF device embedded into the IP core which PUF device uniquely characterizes the IP core.
- None of the communication partners, that is, none of the IP cores, has any knowledge of the others secrets and none of the communication partners have to exchange their secrets. The first IP core does not know the secret key of the second IP core and vice versa. Also the security monitor only knows which data has to be sent to which IP core and has no possibility to change the data content. In order to minimize the communication overhead for each transfer of data the encryption/decryption operations may be achieved using light cryptographic algorithms or by only securing critical data payloads.
- The object of the method according to the invention is to secure the data traffic between sensitive IPs and not the individual components (PUF device, error correction mechanism, cryptographic primitives, etc.) as such which are used for the method.
- The invention will be explained in closer detail by reference to a preferred embodiment, which is depicted schematically in the figures.
- Fig. 1
- shows a possible basic structure for a SoC device according to the invention,
- Fig. 2
- shows the structure of a monitor and two IP cores according to the invention.
-
Fig. 1 shows a possible structure for a system on chip device SoC according to the invention, implemented as FPGA. The system on chip device SoC here has two CPUs, CPU-0 and CPU-1, two communications protocol devices CoPr1, CoPr2, a memory MEM and an IP core IP_. All these items are connected by an internal bus B. Communications protocol device CoPr1 serves as interface to an authentication module AutM which is not part of the system on chip device SoC. Communications protocol device CoPr2 serves as interface to an external network NW outside the system on chip device SoC. - One CPU CPU-0, communications protocol device CoPr1, part of the memory MEM (see respective box in
Fig. 1 ) and part of the IP core IP_ (see respective box inFig. 1 ) are dedicated to computing of critical data where the data traffic has to be secured. These components, for example, are having their traffic secured when communicating with an external device or component or system, such as for example an authentication module AutM. An authentication module AutM is used by the manufacturer to authenticate the chip in order to perform e.g. a software update for the system on chip device SoC. If the authentication fails then it is not an original chip or the system on chip device SoC has been tampered with (attacked, heated, cooled, etc). - Now if there is not just One IP core IP_ but two or more IP cores, IP core IP_ is replaced by a security monitor, short monitor Mon, which connects the IP cores IP_A, IP_B to each other, see
Fig. 2 . Monitor Mon and the IP cores IP_A, IP_B are part of the system on chip device SoC. There is no direct connection between the IP cores IP_A, IP_B via the bus B ofFig. 1 . Only monitor Mon is directly connected the bus B. - During manufacturing of the FGPA device, i.e. during place & route, each IP core IP_A, IP_B is placed in a fixed physical location inside the FGPA device. Afterwards the so called enrolment is performed. During this phase, each IP core IP_A, IP_B is provided with a unique encryption key, generated by the manufacturer. Each IP core IP_A, IP_B uses its key and the response of its own PUF device PUF_A, PUF_B to generate the so called helper data which is stored. More specifically, the process of enrolment starts with a first step where a challenge is sent to the PUF device and a PUF response, also called PUF answer, is generated. Next the PUF response is processed, that is, possible errors are corrected and this corrected data is used for the generation of the helper data, based on the corrected PUF response and on the manufacturer's encryption key, and next the helper data is stored in the SoC, e.g. in the respective own IP core IP_A, IP_B.
- So referring to
Fig. 2 , the enrolment process starts with challenging the first PUF device PUF_A of the first IP core IP_A and generating first helper data HD_A by using the response of the first PUF device PUF_A and a first manufacturer's encryption key which is unique for the first IP core IP_A. The helper data HD_A is saved in the first IP core IP_A. Then the second PUF device PUF_B of the second IP core IP_B is challenged and generates second helper data HD_B by using the response of the second PUF device PUF_B and a second manufacturer's encryption key which is unique for the second IP core IP_B. The helper data HD_B is saved in the second IP core IP_B. - During enrolment of protected IP cores IP_A, IP_B the monitor generates its own helper data to obtain the same keys as the ones of the authorized IP cores IP_A, IP_B. Therefore, for each key that is enrolled, that is for each IP core IP_A, IP_B that is secured, the monitor Mon module generates its own helper data. Referring to
Fig. 2 , the monitor's PUF device PUF_Mon is challenged, helper data HD_Mon_A is generated by using the (especially corrected) response of the monitor's PUF device PUF_Mon and the manufacturer's encryption key for the first IP core IP_A and helper data HD_Mon_B is generated by using the (especially corrected) response of the monitor's PUF device PUF_Mon and the manufacturer's encryption key for the second IP core IP_B. - Following the enrolment the key "programming" mechanism is disabled or physically removed from the FPGA design.
- During normal operation of the system on chip SoC, if the first IP core IP_A needs to send data to the second IP core IP_B, the following process takes place:
- 1) IP core IP_A challenges its PUF device PUF_A and using the helper data HD_A reconstructs the IP core's IP_A unique key.
- 2) IP core IP_A encrypts the data using the reconstructed unique key.
- 3) Monitor Mon receives the encrypted data E_D from IP core IP_A and challenges its own PUF device PUF_Mon.
- 4) As the monitor Mon receives the encrypted data from IP core IP_A is uses the corresponding helper data HD_Mon_A to reconstruct the IP core's IP_A key.
- 5) The monitor Mon decrypts the data E_D from IP core IP_A.
- 6) The monitor Mon needs to send the data D to the IP core IP_B (as initially "stated" by IP core IP_A), therefore monitor Mon challenges its own PUF device PUF-Mon again.
- 7) Using the helper data HD_Mon_B the Monitor Mon regenerates the key of IP core IP_B and encrypts the data D originating from IP core IP_A with the key of IP core IP_B.
- 8) IP core IP_B receives encrypted data from the monitor Mon, challenges its own PUF device PUF_B and regenerates its own key.
- 9) IP core IP_B decrypts the data received from the monitor Mon.
- If either of the IP cores IP_A, IP_B is modified or changed in any way or if the monitor module is tampered with, the PUF responses will differ and thus the encryption keys will not be correctly regenerated. The monitor Mon also contains a list of authorized IP cores and allowed communication schemes, e.g. which IP core is allowed to exchange data with another IP core, or which data may be exchanged. Based on this pre-programmed information the monitor Mon allows or denies the inter-IP-core communication.
-
- AutM
- Authentication module
- B
- Bus
- CoPr1
- Communications protocol device
- CoPr2
- Communications protocol device
- CPU-0
- CPU
- CPU-1
- CPU
- D
- Data
- E_D
- Encrypted Data
- HD_A
- Helper data for IP core IP_A
- HD_B
- Helper data for IP core IP_B
- HD_Mon_A
- Monitor's helper data for IP core IP_A
- HD_Mon_B
- Monitor's helper data for IP core IP_B
- IP_
- IP-core
- IP_A
- first IP core
- IP_B
- second IP core
- MEM
- Memory
- Mon
- Monitor
- NW
- Network
- PUF_A
- first PUF device for IP_A
- PUF_B
- second PUF device for IP-B
- PUF_Mon
- Monitor's PUF device
- SoC
- System on chip device
Claims (7)
- Method implemented in a computer system for protecting the content of different IP cores (IP_A, IP_B) in a system on chip (SoC) using at least one PUF device, characterized by the following steps
challenging a first PUF device (PUF_A) of the first IP core (IP_A) and generating first helper data (HD_A) by using the response of the first PUF device (PUF_A) and a first manufacturer's encryption key during the enrolment phase of the first IP core (IP_A) and storing the first helper data (HD_A),- challenging at least a second PUF device (PUF_B) of the second IP core (IP_B) and generating second helper data (HD_B) by using the response of the second PUF device (PUF_B) and a second manufacturer's encryption key during the enrolment phase of the second IP core (IP_B) and storing the second helper data (HD_B),- challenging a monitor's PUF device (PUF_Mon) as part of a monitor (Mon),- generating helper data (HD_Mon_A, HD_Mon_B) by using the response of the monitor's PUF device (PUF_Mon) and the manufacturer's encryption keys of first and second IP cores (IP_A, IP_B) and storing the respective monitor's helper data (HD_Mon_A, HD_Mon_B) during the enrolment phase,- for sending data from the first IP core (IP_A) to the second IP core (IP_B) during normal operation, decrypting data from the first IP core (IP_A) with the monitor (Mon), which is situated as a security gateway between first IP core (IP_A) and second IP core (IP_B) so that communication between first IP core (IP_A) and second IP core (IP_B) is only possible via the monitor (Mon), by using the monitor's PUF device (PUF_Mon) and the stored monitor's helper data (HD_Mon_A) for the first IP core (IP_A) and then,- encrypting the data with the monitor (Mon) by using the monitor's PUF device (PUF_Mon) and the stored monitor's helper data (HD_Mon_B) for the second IP core (IP_B) and sending the so encrypted data to the second IP core (IP_B). - Method according to claim 1, characterized by- using the first PUF device (PUF_A) of the first IP core (IP_A) for encrypting and decrypting data in the first IP core (IP_A).
- Method according to claim 1 or 2, characterized by- using the second PUF device (PUF_B) of the second IP core (IP_B) for encrypting and decrypting data in the second IP core (IP_B).
- Method according to claim 2 or 3, characterized by- using the first PUF device (PUF_A) to alter its PUF response if the first IP core (IP_A) has been physically changed and/or using the second PUF device (PUF_B) to alter its PUF response if the second IP core (IP_B) has been changed.
- System on chip device (SoC) for protecting the content of different IP cores (IP_A, IP_B) in the system on chip (SoC) according to the method of one of claims 1 to 4, characterized by the system having- a first IP core (IP_A) containing a first PUF device (PUF_A) configured to generate first helper data (HD_A) by using the response of the first PUF device (PUF_A) and a manufacturer's encryption key during the enrolment phase of the first IP core (IP_A) and to store the first helper data (HD_A),- a second IP core (IP_B) containing a second PUF device (PUF_B) configured to generate second helper data (HD_B) by using the response of the second PUF device (PUF_B) and a second manufacturer's encryption key during the enrolment phase of the second IP core (IP_B) and to store the second helper data (HD_B),- a monitor (Mon) which is situated as a security gateway between first IP core (IP_A) and second IP core (IP_B) so that communication between first IP core (IP_A) and second IP core (IP_B) is only possible via the monitor (Mon), said monitor containing a monitor's PUF device (PUF_Mon) and being configured to generate helper data (HD_Mon_A, HD_Mon_B) by using the response of the monitor's PUF device (PUF_Mon) and the manufacturer's encryption keys of first and second IP cores (IP_A, IP_B) and to store the respective monitor's helper data (HD_Mon_A, HD_Mon_B) during the enrolment phase,for sending data from the first IP core (IP_A) to the second IP core (IP_B) during normal operation, the monitor (Mon) being further configured to decrypt data from the first IP core (IP_A) by using the monitor's PUF device (PUF_Mon) and the stored monitor's helper data (HD_Mon_A) for the first IP core (IP_A) and to encrypt data by using the monitor's PUF device (PUF_Mon) for the second IP core (IP_B) and the stored monitor's helper data (HD_Mon_B) for the second IP core (IP_B) and to send the so encrypted data to the second IP core (IP_B).
- System on chip device (SoC) according to claim 5, characterized by- the first PUF device (PUF_A) of the first IP core (IP_A) for encrypting and decrypting data in the first IP core (IP_A) and- the second PUF device (PUF_B) of the second IP core (IP_B) for encrypting and decrypting data in the second IP core (IP_B).
- System on chip device (SoC) according to any of claims 5 to 6, characterized by the first PUF device (PUF_A) being configured to alter its PUF response if the first IP core (IP_A) has been physically changed and/or the second PUF device (PUF_B) being configured to alter its PUF response if the second IP core (IP_B) has been physically changed.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP16464002.1A EP3214613B1 (en) | 2016-03-01 | 2016-03-01 | Protecting the content of different ip cores in a system on chip using pufs |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP16464002.1A EP3214613B1 (en) | 2016-03-01 | 2016-03-01 | Protecting the content of different ip cores in a system on chip using pufs |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3214613A1 EP3214613A1 (en) | 2017-09-06 |
EP3214613B1 true EP3214613B1 (en) | 2020-07-08 |
Family
ID=55628973
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP16464002.1A Active EP3214613B1 (en) | 2016-03-01 | 2016-03-01 | Protecting the content of different ip cores in a system on chip using pufs |
Country Status (1)
Country | Link |
---|---|
EP (1) | EP3214613B1 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109165482B (en) * | 2018-06-22 | 2020-10-09 | 芯启源(上海)半导体科技有限公司 | IP soft core property protection and infringement identification method based on USB3.1 protocol TS1 training sequence |
CN110912881B (en) * | 2019-11-19 | 2022-04-05 | 天津津航计算技术研究所 | Honeypot scrambling method for cryptographic algorithm IP core |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6305005B1 (en) | 1999-01-14 | 2001-10-16 | Xilinx, Inc. | Methods to securely configure an FPGA using encrypted macros |
US8670561B1 (en) | 2005-06-02 | 2014-03-11 | Altera Corporation | Method and apparatus for limiting use of IP |
EP1811415A1 (en) | 2005-12-23 | 2007-07-25 | Nagracard S.A. | Secure system-on-chip |
-
2016
- 2016-03-01 EP EP16464002.1A patent/EP3214613B1/en active Active
Non-Patent Citations (1)
Title |
---|
None * |
Also Published As
Publication number | Publication date |
---|---|
EP3214613A1 (en) | 2017-09-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Zhang et al. | Recent attacks and defenses on FPGA-based systems | |
JP6998435B2 (en) | Memory operation encryption | |
KR102345379B1 (en) | Crypto ASIC with self-verifying internal identifier | |
US20210081536A1 (en) | Secure boot systems and methods for programmable logic devices | |
US8732468B2 (en) | Protecting hardware circuit design by secret sharing | |
CN104252881B (en) | Semiconductor integrated circuit and system | |
Trimberger et al. | FPGA security: Motivations, features, and applications | |
Maes et al. | A pay-per-use licensing scheme for hardware IP cores in recent SRAM-based FPGAs | |
EP2973198B1 (en) | Integrated circuit with parts activated based on intrinsic features | |
US20100284539A1 (en) | Methods for Protecting Against Piracy of Integrated Circuits | |
US11329833B2 (en) | Programmable device key provisioning | |
Amir et al. | Comparative analysis of hardware obfuscation for IP protection | |
US20230315913A1 (en) | Multi-chip secure and programmable systems and methods | |
Roy et al. | Protecting bus-based hardware IP by secret sharing | |
EP3214613B1 (en) | Protecting the content of different ip cores in a system on chip using pufs | |
Mohammad et al. | Required policies and properties of the security engine of an SoC | |
EP3214797B1 (en) | Deriving a device unique encryption key of a system on chip using a physical unclonable function | |
Zhang et al. | Public key protocol for usage-based licensing of FPGA IP cores | |
CN112368701A (en) | Key provisioning system and method for programmable logic devices | |
Ray et al. | The curious case of trusted IC provisioning in untrusted testing facilities | |
Mohankumar et al. | Lightweight Logic Obfuscation in Combinational Circuits for Improved Security—An Analysis | |
US11582021B1 (en) | Protection against differential power analysis attacks involving initialization vectors | |
US20240232439A1 (en) | Tamper detection systems and methods for programmable logic devices | |
Saha et al. | FPGA-Based IP and SoC Security | |
Chi | FPGA Implementation of Secure Protocol for Hardware Authentication and Activation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20180305 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20190909 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTG | Intention to grant announced |
Effective date: 20200207 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP Ref country code: AT Ref legal event code: REF Ref document number: 1289311 Country of ref document: AT Kind code of ref document: T Effective date: 20200715 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602016039447 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG4D |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1289311 Country of ref document: AT Kind code of ref document: T Effective date: 20200708 |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20200708 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201109 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201008 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201009 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201008 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20201108 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602016039447 Country of ref document: DE |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
26N | No opposition filed |
Effective date: 20210409 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20210331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210301 Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210331 Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210301 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20210331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20160301 |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230510 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: FR Payment date: 20240319 Year of fee payment: 9 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200708 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20240409 Year of fee payment: 9 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20240517 Year of fee payment: 9 |