EP2862120B1 - Systèmes, procédés et appareils pour gestion de temps sécurisée - Google Patents

Systèmes, procédés et appareils pour gestion de temps sécurisée Download PDF

Info

Publication number
EP2862120B1
EP2862120B1 EP13742265.5A EP13742265A EP2862120B1 EP 2862120 B1 EP2862120 B1 EP 2862120B1 EP 13742265 A EP13742265 A EP 13742265A EP 2862120 B1 EP2862120 B1 EP 2862120B1
Authority
EP
European Patent Office
Prior art keywords
time
counter
current
response
timekeeper
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
Application number
EP13742265.5A
Other languages
German (de)
English (en)
Other versions
EP2862120A1 (fr
Inventor
Sergey Ignatchenko
Dmytro IVANCHYKHIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OLogN Technologies AG
Original Assignee
OLogN Technologies AG
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 OLogN Technologies AG filed Critical OLogN Technologies AG
Publication of EP2862120A1 publication Critical patent/EP2862120A1/fr
Application granted granted Critical
Publication of EP2862120B1 publication Critical patent/EP2862120B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/12—Synchronisation of different clock signals provided by a plurality of clock generators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G06F21/725—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits operating on a secure reference time value
    • 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/3247—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 involving digital signatures
    • 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/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/3297—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 involving time stamps, e.g. generation of time stamps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/10—Distribution of clock signals, e.g. skew
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/14—Time supervision arrangements, e.g. real time clock
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the systems, methods and apparatuses described herein relate to improved mechanisms for data security.
  • time values in software and hardware applications is common. For example, in some applications it may be desirable to securely calculate the "current time,” or the length of time that has elapsed since a specific event in the past. It may also be desirable to factor in any possible error in those calculations, as in some applications, a high degree of precision may be required. In other cases, high precision may not be required, but it still may be valuable to know that a time or duration is guaranteed to be within certain predefined limits (even if the precision is on the order of minutes, hours, or days). For example, relatively low-precision (on the order of hours or even days) but secure timers are often necessary in the context of validating security certificates (such as, for example, PKI certificates).
  • United States Patent Application Publications US2009/0006854 and US 2009/0083372 exemplify requesting and receiving, from a remote trusted time source, time information in the form of digitally-signed timestamps, wherein the requesting entity verifies the reported time information by checking the validity of the digital signature and the presence of a randomly-generated nonce.
  • FIG. 1 shows an exemplary computing device 120 according to the present disclosure.
  • a suitable computing device 120 may be any form of electronic device, such as laptop, smart phone, tablet, smart television set, etc.
  • a computing device 120 may first comprise a secure zone 150 that may execute certain applications or functions which may request use of an accurate time, or an accurate time interval, in the performance of certain activities.
  • the secure zone 150 may be configured, as described herein, to receive a current, real-world time from one or more external trusted timekeepers 110 via a communications channel 105 coupled to the device 120.
  • each message may be digitally signed, such that the originating timekeeper 110 may be authenticated; in these embodiments, the secure zone 150 may verify the digital signature to ensure that the message came from a legitimate, trusted timekeeper 110. Then, the secure zone 150 may process the received timing information, using secure, internal hardware and/or software components, to provide accurate timing information to the requesting application.
  • the computing device 120 may also have a non-secure zone 152, which may contain an operating system 111 and one or more applications 112 running in it; in other embodiments, the non-secure zone 152 may run applications (or pieces of code) without an operating system (e.g., as described with respect to U.S. Provisional Patent Application No. 61/623,861 , entitled “Secure Zone for Digital Communications," and filed on April 13, 2012).
  • the secure zone 150 may comprise an interface 151 to communicate with the non-secure zone 152.
  • the secure zone 150 may first comprise a timer block 140, capable of (i) processing messages received from one or more trusted timekeepers 110 ( e.g ., via a supervisor 160), and (ii) keeping track of the amount of time elapsed since the device 120 was initialized or since it was synchronized by a trusted timekeeper 110.
  • the timer block 140 may first comprise one or more counters which may be used to determine the time elapsed between the occurrence of two events.
  • a suitable counter may take the form of an oscillator (including, but not limiting to a multivibrator) having a known frequency (in which the frequency may be optionally stabilized by using, for example, a quartz crystal resonator) and a digital counter, or any other type of apparatus capable of incrementing a count at a known frequency.
  • the present state of the counter may be recorded (e.g ., in a memory, shown as 146 within the timer block 140) at the first event and again at the second event. Then, in conjunction with the known frequency of the counter, the total number of counter increments occurring between the two events can be used to derive the elapsed time in seconds (or whatever other appropriate time measurement).
  • a counter operating at 60 ticks/minute could have value 60 at the time of a first event and 180 at the time of a second event. The difference between the first and second events, in ticks, is 120. Thus, at 60/ticks per minute, it can be calculated that 2 minutes elapsed between the two events.
  • counters generally may be subject to drift. This drift can work both ways, such that, counter increments may take more or less actual time than the known frequency of the counter. This may occur for various reasons, including the environment in which the timer block operates (temperature may, for example, affect frequency), and wear and tear on timer block components (such as, for example, capacitor aging). This can obviously reduce the precision of timing devices, and as the time intervals to be calculated increase in length, any errors introduced by drift are likely to increase in magnitude. While the actual drift of a particular counter accumulated over time periods of the same duration may vary (for example, because of temperature), it is generally possible to specify the maximum possible drift for a given counter (or for a particular type of counters).
  • This maximum drift parameter may be expressed, for example, as a ratio, e.g., 0.01 seconds of drift/minute, and may be stored in non-volatile memory 146 within the timer block 140.
  • the maximum drift may vary, for example, from less than 0.001 seconds of drift per minute for quartz-based timers to up to a few seconds per minute for non-quartz-based timers.
  • a counter may be able to operate at multiple frequencies. These frequencies may be used to operate the device in different energy modes. For example, a counter in a low energy mode might operate at a lower frequency, while a counter operating at a higher frequency might require more energy.
  • the timer block 140 might be able to operate in different energy modes by using multiple counters. In such an exemplary embodiment, as shown on Figure 1 , there may be a first, standard counter 141 and a second, low-energy counter 143.
  • each of the standard counter 141 and the low-energy counter 143 may have their own operating frequencies and maximum drifts, and may be optimized for different operational requirements.
  • An exemplary standard counter 141 may be implemented using a quartz-based oscillator, with a frequency of 32,768 Hz and with precision on the order of 0.001%.
  • a low-energy counter 143 may be implemented using CMOS technology and operating at a very low frequency.
  • An exemplary low-energy counter 143 may have a frequency as low as 3 Hz; because it may be impractical to use quartz resonators at such low frequencies, the precision of the timer (or more precisely, the guaranteed maximum possible drift) may be on the order of 1%. Thus, it will be understood that in many cases there may be a tradeoff between minimizing energy consumption and maximizing precision of the device.
  • the low-energy timer counter 143 may be capable of operating when external power sources are turned off.
  • the low-energy timer counter 143 may have a battery (or other form of power supply, such as a super-capacitor) 144, which may be used to continue to power the counter 143 even when the computing device 120 has been turned "off.”
  • the low-energy timer counter 143 may use a battery or other power source (not shown) of the computing device 120.
  • FIG. 2 shows an exemplary structure of a timer data structure 200 which might be used by the timer block 140 to store and manipulate timer data used in the performance of its operations.
  • certain elements of this timer data structure 200 may be read-only after the device is manufactured. This may be achieved, for example, by either placing such data into read-only, non-volatile memory, or by enforcing correspondent policies inside the secure zone 150 by, for example, preventing the over-writing of such data.
  • This timer data may be stored, for example, within memory 146.
  • the timer data structure 200 may contain a timer characteristics data block 210.
  • This timer characteristics data block 210 may contain, for example, the real-world time at which the timer block 140 is first initialized, an initialization_time 211.
  • the timer characteristics data block 210 may include certain properties of either the standard timer counter 141, the low-energy timer counter 143, or both.
  • the block 210 may store the respective operating frequencies of the two timers (the frequency of the standard counter 141 shown as standard_counter_frequency 212, and the frequency of the low-energy timer counter 143 shown as low-energy_counter_frequency 213).
  • the timer characteristics data block 210 may further store the maximum drift rates (e.g., 0.1 seconds of drift per hour) of the standard timer counter 141 and the low-energy timer counter 143, shown as standard_counter_maximum_drift 214, and low-energy_counter_maximum_drift 215, respectively.
  • all of the data contained in this block 210 may be initialized at the time the secure zone 150 is manufactured ( e.g., in accordance with the exemplary method described with respect to Figure 3 , below) and may not be further modified.
  • this policy may be enforced by storing this data into read-only, non-volatile memory, may be enforced through coded policies, or any other appropriate mechanism for preventing modification of these data fields.
  • the data structure 200 may contain a switching event data block 220, which may be used to store any information about the last energy mode switching event, i.e., the last instance at which the timer block 140 switched from operating in one energy mode (e.g., standard mode) to another mode (e.g., low-energy mode). This information can be used to make timing determinations at the time of the next energy mode switching event.
  • a switching event data block 220 may be used to store any information about the last energy mode switching event, i.e., the last instance at which the timer block 140 switched from operating in one energy mode (e.g., standard mode) to another mode (e.g., low-energy mode). This information can be used to make timing determinations at the time of the next energy mode switching event.
  • information may be stored in the switching event data block 220 when the timer block 140 switches from using a standard counter 141 to a low-energy counter 143. Then, when the timer block 140 switches again, from the low-energy counter 143 back to the standard counter 141, information stored in the switching event data block 220 about the last energy mode transition (i.e., from standard counter 141 to low-energy counter 143) may be used, for example, to calculate the amount of time elapsed while the timer block 140 operated in low-energy mode.
  • energy_mode 221 may store a value representative of the new energy mode type in effect following the transition.
  • time_elapsed_until_energy_mode_switch 222 may store the total elapsed time since the device 120 was first initialized and the most recent energy transition, calculated based on counters 141 and 143 and expressed, for instance, in seconds.
  • energy_mode_drift 223 may store the maximum total amount of drift accumulated between the time the device 120 was first initialized and the time of the most recent energy mode switch.
  • counter_start_value_at_energy_mode_switch 224 may store the starting value of the counter which is operational immediately following the most recent energy mode switch.
  • counter_start_value_at_energy_mode_switch 224 may store the value of the low-energy counter 143 at the time it is activated. In certain embodiments, it may be desirable to reset the associated counter to zero when a switch from one energy mode to another occurs. For example, if the timer block 140 switches into a low-energy mode, at the point the switch is made it may be desirable to reset the value of the low-energy counter 143 to zero.
  • time_elapsed_until_energy_mode_switch 222 and energy_mode_drift 223 it may be desirable to use two other values, (i) the minimum amount of time elapsed until the most recent energy mode switch, and (ii) the maximum amount of time elapsed until the most recent energy mode switch (not shown).
  • the difference between these two values will be twice the energy_mode_drift 223 and the time_elapsed_until_energy_mode_switch 222 will be the midway point between these two values.
  • this switching event data block 220 may not be necessary.
  • the data structure 200 may comprise a third, synchronization data block 230, which may store information about the last synchronization event -- that is, the most recent event during which a real-world time was securely received from a trusted timekeeper 110. Five values may be associated with such an event, each of which is discussed in greater detail below.
  • timekeeper_ID 231 may store a globally-unique identifier of the trusted timekeeper 110 from which a new time was received, which may include a trusted timekeeper certificate or a reference to the timekeeper's certificate (such as a serial number of the timekeeper's certificate).
  • the synchronization data block 230 may store as synchronization_time 232 the real-world time received from the trusted timekeeper 110 (identified by timekeeper_ID 231) during the most recent synchronization event.
  • the block 230 may store as time_elapsed_until_synchronization 233 the amount of time elapsed (according to counters 141 and 143) from the time the device 120 was first initialized until the most recent synchronization.
  • the block 230 may store as synchronization_drift 234 the maximum amount of drift accumulated from time of the device 120 was first initialized until the most recent synchronization.
  • the block 230 may store as response_time 235 the amount of time it took to receive a response from a timekeeper 110 after a request for secure time data.
  • data structure 200 is shown as a single structure with three component blocks, the data may in fact be organized into more than one data structure or a different number of component blocks. In other words, the data may be organized into any number of structures or blocks as appropriate for a specific implementation. It should also be understood that additional data also may be associated with the timer block 140, the data structure 200, or any of their respective components.
  • Figure 3 is a flow chart showing an exemplary process by which a computing device 120 may be initialized for timekeeping at, for example, the time at which the device 120 is manufactured. This process involves initializing any values stored within a timer data structure 200.
  • any memory 146 associated with any existing timer data may be cleared.
  • the memory 146 may be zeroed.
  • the timer characteristics data block 210 may be filled.
  • the frequency and maximum drift rates shown as standard_counter_frequency 212, low-energy_counter_frequency 213, standard_counter_maximum_drift 214, and low-energy_counter_maximum_drift 215 on Figure 2
  • the current, real-world time may be saved as the initialization_time 211. This real-world time may be provided by, for example, a computer connected to the U.S. National Institute of Standards (NIST) official U.S. time clock, a GPS receiver, an atomic clock, or some other form of precise timing mechanism.
  • the timer block 140 may begin keeping track of the amount of time elapsed since the computing device 120 was initialized.
  • the timer block 140 may start in low-energy mode, making use of the low-energy counter 143.
  • the low-energy counter 143 may run all the time, while the standard counter 141 may run only when external power is available.
  • the values of the switching event data block 220 may be initialized.
  • energy_mode 221 may be set to a value representative of the energy mode in which the device 120 started
  • time_elapsed_until_energy_mode_switch 222 i.e., the time elapsed between initialization and the most recent energy mode switch (which has likely not yet occurred since the device is currently being initialized) may be set to zero
  • energy_mode_drift 223 the amount of timer drift accumulated from time of the first initialization, also may be set to zero
  • counter_start_value_at_energy_mode_switch 224 the starting value of the currently operational counter, also may be set to the value of the counter at the time it was started, e.g. , at step 330. In many cases, this fourth value may also be zero.
  • the values of the synchronization block 230 may be initialized.
  • the timekeeper_ID 231 may be set to zeroes, NULL, or some other appropriate indicator that the timer block 140 has not been synchronized.
  • the synchronization_time 232 i.e., the time of the most recent synchronizing event, may be set to the initialization_time 211; the time_elapsed_until_synchronization 233 may be set to zero; and the synchronization_drift 234, the maximum drift accumulated from time of the first initialization, also may be set to zero. This initialization may simplify further calculations since the latest synchronization event data is always initialized.
  • the timer block 140 can be used to calculate the current time or the time elapsed between two events.
  • Figure 8 illustrates one method by which the current time may be calculated.
  • the number of counter increments since the computing device 120 was initialized may be obtained. Assuming that the counter was set to zero at initialization, this amount may simply be the present value of the counter.
  • this value may be divided by the counter frequency, which provides the total amount of time elapsed since the computing device 120 was initialized. Then, at step 810, this amount may be added to the initialization_time 211 to produce the current time.
  • a 3-Hz counter may have been initialized to have a value of zero at 12:00 am, January 1, 2012.
  • the present value of the counter may be 5400.
  • the current time may be calculated as follows: First, 5400 counter increments divided by 3 Hz gives 1800 seconds (or 30 minutes) of elapsed time. This value is then added to the initialization_time 211 of 12:00 am, to give a current time of 12:30 am.
  • the counter may be subject to drift.
  • the potential error in the calculated time may be as large as the maximum drift accumulated since the device 120 initialization. Therefore, it may be desirable to also calculate the maximum amount of drift time since device 120 initialization.
  • the total amount of time elapsed since the device was initialized e.g. , as determined at step 805
  • the counter's maximum drift rate For example, if the elapsed time was calculated at step 805 as 30 minutes, and the maximum drift rate of the counter is 1%, then the maximum drift since the time of device initialization is 1800 seconds * 0.01, or 18 seconds.
  • Figure 9 shows one exemplary method for calculating this time interval.
  • the value of the counter may be recorded, contemporaneously with the occurrence of the first event.
  • the value of the counter may again be recorded.
  • the value of counter recorded at the time of the first event may be subtracted from the value of counter recorded at the time of the second event to determine the number of count increments between two events.
  • this difference may be divided by the counter frequency (e.g ., to convert counter increments into seconds or some other unit of time) to determine the interval between the two events.
  • this amount may be calculated at step 920.
  • the difference between (i) the maximum drift accumulated since initialization as of the time of the second event and (ii) the maximum drift accumulated since initialization as of the time of the first event may be calculated.
  • the maximum amount of drift accumulated during time between two events may be calculated by multiplying the time elapsed between the two events (as calculated at step 915) by the maximum drift rate of the timer.
  • the timer block 140 may have one or more counters enabling two or more energy modes.
  • Figure 4 is a flow chart showing one exemplary method by which timer data may be updated when an energy mode is changed.
  • the energy mode may be changed.
  • the computing device 120 may have been unplugged from an external power source, causing the timer block 140 to start operating in a low-energy mode. This may be accomplished, for example, by using a low-energy time counter 143 configured to receive power from an internal battery 144.
  • Steps 420 and 430 may be used to calculate the amount of time elapsed in the previous energy mode.
  • the computing device 120 had been operating in standard mode until it was unplugged from an external power source, causing the timer block 140 to start operating in a low-energy mode.
  • steps 420 and 430 may be used to calculate the amount of time elapsed while the device 120 was operating in standard mode (right up until the point the device 120 transitioned into low-energy mode).
  • the difference may be calculated between the value of the counter (corresponding to the old energy mode) at the time of the energy mode transition (e.g., the value at step 410), and its value at the beginning of operating in that mode (previously stored in counter_start_value_at_energy_mode_switch 224).
  • this difference is merely the then-current value of the counter at the time of step 410.
  • the difference is calculated between the value of the standard counter 141 at the time the energy mode switch was effected (at step 410), and the value of the standard counter 141 at the time it had been started (previously stored in counter_start_value_at_energy_mode_switch 224). If the value of the standard counter 141 had been reset to zero when the device 120 began operating in standard energy mode, this "difference" will simply be the value of the standard counter 141 at the time the device 120 transitions into low-energy mode ( e.g ., the value at step 410).
  • the difference calculated at step 420 may be used to calculate the length of time that the device operated in the previous energy mode. This may be calculated, for example, by multiplying the difference calculated at step 420 (e.g., the number of counter ticks elapsed during operation in the previous energy mode) and the known frequency of the counter. For example, if the timer block 140 transitioned from operating in standard-energy mode to low-energy mode, the number of counter increments calculated at step 420 may be divided by the frequency stored as standard-energy_counter_frequency 212 in timer characteristics data block 210. Thus, for example, if the frequency in standard energy mode 212 were 2000 ticks per second, and the difference calculated at step 420 is 7,200,000 ticks, then the time of operation in the standard-energy mode was 3600 seconds, or 1 hour.
  • the amount of time elapsed from the time that the timer block 140 was first initialized until the time of the last energy mode transition may be computed based on the amount of time that the timer block 140 operated in the previous energy mode (as just calculated in steps 420 and 430) and the amount of time elapsed since the device 120 was first initialized, which is stored as time_elapsed_until_energy_mode_switch 222 of the data block 220.
  • the record 222 may show a value of 1900800 seconds, indicating that three weeks and one day had passed since the time the computing device 120 was initialized up until the immediately preceding energy mode transition.
  • step 430 it may have been determined that the timer block 140 operated in the previous energy mode for a total of 7200 seconds.
  • the total time elapsed since the device 120 was initialized up through the last energy mode transition is 1908000 seconds (or 3 weeks, 1 day and 2 hours).
  • the maximal potential drift which may have accumulated during the previous energy mode may be computed.
  • the maximal possible total drift (i.e., the maximum drift which could have accumulated from the time the device 120 was first initialized) may be computed. This amount may be calculated as the sum of the maximum possible drift accumulated from the time the secure zone 150 was first initialized up until the time of the immediately preceding energy mode switch (this value may be found within energy_mode_drift 223 of the switching event data block 220) and the maximum potential drift accumulated during the previous energy mode (e.g., the amount calculated at step 450).
  • Figure 5 illustrates, in graphical format, how the maximum possible drift may accumulate over 4 time intervals (which may correspond, for example, to 4 energy mode transitions).
  • the new values -- pertaining to the energy mode immediately prior to the most recent energy mode switch -- may overwrite any values previously within the data block 220.
  • the value of the current energy mode type (generated by transitioning the timer block 140 from one mode to another) may be stored into energy_mode 221 of the existing data block 220, overwriting the old value.
  • the present time e.g. , the time elapsed since the device 120 was initialized, as determined at step 440
  • the maximum possible drift accumulated since the device 120 was first initialized e.g ., as determined at step 460
  • timer data may be updated when an energy mode is changed. In some embodiments, however, it may be difficult to perform these operations when the power is turned off. In such embodiments, it may be useful to update timer data at regular intervals (for example, once per minute) while the device 120 remains powered, rather than performing these operations after the power has been turned off.
  • Figure 8 illustrated an exemplary method by which the current time may be calculated in embodiments having only one counter. Similar computations may be performed to determine the current time in embodiments having two or more counters. In one exemplary embodiment, these amounts may be calculated based on the values stored at the last energy mode change, e.g., within data block 220.
  • Figure 10 shows one such exemplary method for calculating the current time in embodiments having two or more counters.
  • the difference may be calculated between the present value of the currently operational counter and the value of counter_start_value_at_energy_mode_switch 224.
  • this value may be divided by the appropriate counter frequency (depending on the current energy mode, this could be, for example, either standard_counter_frequency 212 or low-energy_counter_frequency 213). The result of this division may be interpreted as the amount of time passed since the last energy mode change.
  • this amount may be added to time_elapsed_until_energy_mode_switch 222 to obtain the total amount of time elapsed since the device 120 was initialized. Then, at step 1030, the initialization_time 211 may be added to the total amount of time elapsed since device initialization ( e.g ., the amount calculated at step 1020) to calculate the current time.
  • the present value of the low-energy counter 143 is 10800
  • its value at the time it began operating in the present energy mode i.e., the value of counter_start_value_at_energy_mode_switch 224) was 5400
  • the low-energy_counter_frequency 213 is 3Hz
  • the time_elapsed_until_energy_mode_switch 222 is 9000 seconds
  • the initialization_time 211 is 12:00am 1/1/2012.
  • the current time would be calculated as follows:
  • This amount may be calculated by, at step 1040, multiplying the amount of time elapsed since the last energy mode change (i.e., the amount calculated at step 1010) by the appropriate counter drift rate to obtain the maximum amount of drift accumulated since the last energy mode change.
  • this amount may be added to the total maximum amount of drift accumulated since device initialization up until the last energy mode change (i.e., energy_mode_drift 223) to provide the total maximum amount of drift accumulated since the device 120 was initialized.
  • the counter's maximum drift rate is 0.01 and the energy_mode_drift 223 is 12 seconds.
  • the maximum drift since initialization may be calculated as follows:
  • Figure 9 illustrated an exemplary method by which the amount of time and drift accumulated between two events may be calculated in embodiments having only one counter. Similar computations may be performed to determine the amount of time and drift accumulated between two events in embodiments having two or more counters. In one exemplary embodiment, these amounts may be calculated based on the values stored at the last energy mode change, e.g., within data block 220.
  • Figure 11 shows one such exemplary method for calculating the amount of time elapsed between two events, as well as the maximum drift accumulated during that time, in embodiments having two or more counters.
  • the elapsed time since the device 120 was initialized, and the maximum drift accumulated during that interval may be calculated, e.g., as described with respect to Figure 8 , and recorded, contemporaneously with the occurrence of the first event.
  • step 1105 contemporaneously with the occurrence of the second event, the elapsed time and maximum accumulated drift since device 120 initialization may again be recorded.
  • the elapsed time recorded at the time of the first event may be subtracted from the elapsed time recorded at the time of the second event to determine the duration between the two events.
  • the value of the maximum accumulated drift recorded at the time of the first event may be subtracted from the value of the maximum accumulated drift recorded at the time of the second event to determine the maximum accumulated drift during the period between the two events.
  • the time elapsed between the two events may be calculated as follows:
  • a secure zone 150 may comprise a supervisor 160 in support of secure timekeeping.
  • This supervisor 160 may be able to: (1) receive information from one or more trusted timekeepers 110; (2) validate received timing information; (3) estimate the value of the present real-world time and any possible errors in such an estimation, and provide one or both pieces of information to entities interested in such information; and/or (4) enforce certain internal or external policies based on the present time or a period of elapsed time, such as checking a digital certificate expiration time in the process of performing certificate validation.
  • the supervisor 160 further may perform certain other, additional functions, such as: (5) receiving executable code which can be run on one or more processors (not shown) within the secure zone 150; (6) verifying any digital certificates associated with this code; and/or (7) if one or more predetermined requirements are fulfilled, instruct a processor (not shown) within the secure zone 150 to execute the code.
  • the supervisor 160 might be able to fulfill one or more tasks as described in U.S. Provisional Application No. 61/623,861 (previously mentioned) or U.S. Provisional Patent Application No. 61/636,201 , entitled “Improved Secure Zone for Secure Purchases," and filed on April 20, 2012.
  • the timer block 140 may be implemented as a part of the supervisor 160; in other embodiments, the timer block 140 and the supervisor 160 may be implemented as two separate units,
  • the supervisor 160 may be used to control access to one or more components of the secure zone 150, and may be used to enforce certain operational rules of the secure zone 150 so as to provide certain security guarantees to the end-user.
  • the supervisor 160 may be implemented in hardware and/or software within the secure zone 150. Regardless of the implementation, however, the integrity of the supervisor 160 should be guaranteed by using, for example, tamper-resistant and/or tamper-detection techniques.
  • the secure zone 150 implements the option to load and execute third-party code, measures should be taken to ensure that any such third-party code is not capable of affecting or learning the state of the supervisor 160.
  • the secure zone 150 may further comprise one or more cryptographic engines 121, which may be used by the supervisor 160, among other things, in support of timekeeper certificate verification. These cryptographic engines 121 may be configured to implement one or more cryptographic algorithms, such as AES or RSA. The cryptographic engine 121 may receive data from the supervisor 160 for encryption or decryption, and may provide the resulting ciphertext (or plaintext, as appropriate) back to the supervisor 160.
  • the secure zone 150 may also comprise a random number generator 124 to provide support to cryptographic processes.
  • the supervisor 160 may be configured to perform some or all of the functionality of the cryptographic engine 121, and a separate cryptographic engine 121 may not be required.
  • the secure zone 150 further may contain one or more dedicated certificate storages 166, which may be implemented as read-only, non-volatile memory.
  • the certificate storage 166 may store one or more root certificates of one or more Certification Authorities (CA), which, in turn, may be used for trusted timekeeper 110 certificate validation.
  • CA Certification Authority
  • the secure zone 150 may be physically secured, such that it is tamper-resistant.
  • the secure zone 150 may also (alternatively, or in addition to being tamper-resistant) incorporate one or more tamper detection techniques. For example, several tamper-resistant methods for protecting cryptographic processors are already known and have been described in the art; see http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-641.pdf.
  • the secure zone 150 might have a secure enclosure.
  • the secure zone 150 may be configured to execute one or more possible responses if it detects that the chip's integrity has been compromised, and/or if it detects penetration of the secure enclosure. These responses may vary from erasing sensitive data to the physical destruction of all or part of the secure zone 150.
  • the secure zone 150 should treat as reliable only time data received from a certified, secure timekeeper 100 which was received using one or more secure data transmission algorithms.
  • Figures 6a - 6c illustrate one exemplary method by which the timer block 140 may be synchronized using time data received from a trusted timekeeper 110.
  • step 600 it may be determined that the timer block 140 should be resynchronized. This may happen for any number of reasons including, but not limited to: (i) the timer drift accumulated since the last synchronization event exceeds a predefined, maximal allowable amount of drift (i.e., the time that will be produced by the timer block 140 will be too unreliable/erroneous for the application), which may depend, for example, on the operation which needs to be performed by the supervisor 160; (ii) the supervisor 160 has received a request from code running in the secure zone 150 for a current time, and the request has further specified that the error associated with that time should be less than a predetermined amount; or (iii) a similar request has been received from outside the secure zone 150, e.g., from an application 112 (directly or by means of operating system 111 system calls) running in the non-secure zone 152.
  • the secure zone 150 may be configured to periodically determine whether it needs to be a predefined, maximal allowable amount of drift (i.e.,
  • the supervisor 160 may begin preparing a request for a current time for transmission to a trusted timekeeper 110.
  • the supervisor 160 may generate a nonce, i.e., a cryptographically-safe random number, to be forwarded to a trusted timekeeper 110.
  • the supervisor 160 may use RNG 124 to generate the nonce.
  • This nonce may be saved, e.g., within memory 146. Use of the nonce, as described further herein, may be used, for example, to ensure that a time received from a timekeeper 110 corresponds to the most recent time request generated by the supervisor 160, which may be used to prevent 'replay attacks.'
  • the supervisor 160 may instruct the timer block 140 to calculate the total amount of time elapsed since the device 120 was initialized; this time may be saved, e.g., within memory 146.
  • the supervisor may select a particular timekeeper 110 from which a secure time will be sought from a list of available trusted timekeepers.
  • a list may reference timekeepers by, for example, their absolute domain names (e.g., "example-time-keeper.com").
  • This list may be provided to the secure zone 150 in conjunction with a task currently running within the supervisor 160 (for example, within a predefined field of the task's associated digital certificate), or may come from and may be supported and updated within the non-secure zone 152 such as, for example, by the operating system 111 or an application 112 running within the operating system 111.
  • the supervisor 160 may form the request for a current time.
  • This request may comprise the nonce, and may optionally comprise a reference to the timekeeper 110 selected at step 610.
  • a request for a current time (e.g ., as formed at step 615) may be sent to the selected trusted timekeeper 110 using, for example, the non-secure zone 152 and/or the operating system 111.
  • the selected timekeeper 110 may receive the request and may form a reply containing: (i) a present, real-world time value; (ii) a trusted timekeeper 110 certificate revocation list (CRL), which may include certificates of any timekeepers whose certificates have been revoked, and which may be signed, for example, by the same certificate authority which signs timekeeper certificates; and (iii) the nonce received within the request.
  • the timekeeper 110 may sign the reply with its private key (which corresponds to the public key contained in its digital certificate) before sending the reply back to the computing device 120.
  • the computing device 120 may receive the reply from the selected trusted timekeeper 110, and may forward it to the secure zone 150 for handling by the supervisor 160.
  • the supervisor 160 may receive the reply; (ii) verify, using the cryptographic engine 121, that the certificate was validly signed by a trusted timekeeper 110; and (iii) verify that the value of the nonce received with the reply is the same as the value provided in the request.
  • a standard PKI certificate validity check may include time checks. For example, it may be desirable to determine that a certificate has not yet expired. In some embodiments, however, at this step 630, it may be preferable not to execute these standard time checks.
  • the supervisor 160 may repeat its attempts to obtain a trusted time by repeating steps 605-620, but may choose to contact a different timekeeper 110.
  • the supervisor 160 may request that the timer block 140 calculate the difference between (i) the current amount of time elapsed since device 120 initialization, and (ii) the amount of time passed since device 120 initialization until the time when the request was made ( e.g ., the amount of time saved at step 607). If, at step 633, this time interval is greater than some predefined value (for instance, 30 seconds), the reply could be discarded. In most cases, this duration should be on the order of seconds or even less. Not limiting this duration appropriately may increase the possibility of certain kinds of attacks.
  • the supervisor 160 may temporarily store this duration (e.g. in memory 146). If, ultimately, the reply time is accepted for resynchronization, this duration may be saved permanently as response_time 235 within the synchronization event data block 200.
  • the supervisor 160 may compare the time received from the trusted timekeeper 110 ( e.g., at step 620) against the timing information generated by the timer block 140 itself, i.e., against the current time as calculated based on the time elapsed since device 120 initialization, e.g., in accordance with the methods described with respect to Figures 8 and 10 , above.
  • the time received from the trusted timekeeper 110 falls outside the range of the current time, as calculated based on the amount of time elapsed since the device 120 was initialized, plus or minus the maximum amount of drift accumulated since the device 120 was initialized, the time may be considered invalid.
  • the current time may be calculated as January 1, 2012, and the maximum amount of possible drift time since device 120 initialization may be calculated as two days. If the time provided by the timekeeper 110 is before December 30, 2011 or after January 3, 2012, the timekeeper's time may be considered invalid. In such an event, no resynchronization should occur, and the old synchronization_time 232 should continue to be used in time calculations.
  • the supervisor 160 expressly may verify whether the timekeeper used during the previous resynchronization (i.e., the "old" timekeeper) is listed in the CRL received within the reply. If the old timekeeper is found in the CRL list, it may be assumed that the old timekeeper was compromised and that the previous synchronization_time 232 is unreliable. In this case, the newly received time value -- which has been checked against the time elapsed since the device was initialized ( e.g ., at step 635)-- should be used to resynchronize the timer block 140, e.g., in accordance with step 650, below.
  • the timekeeper used during the previous resynchronization i.e., the "old" timekeeper
  • the supervisor 160 may verify that the time received from the new timekeeper 110 falls somewhere within the range of the current time calculated based on the last successful synchronization, synchronization_time 232, plus or minus the maximum possible amount of drift since the last synchronization. If the two time values are found to be in conflict -- e.g., the time received from the new timekeeper 110 is outside of this range -- the conflict between trusted timekeepers may be resolved in favor of the old timekeeper 110 used during the last successful synchronization, no resynchronization should occur, and the old synchronization_time 232 should continue to be used.
  • step 645 it may be determined whether the digital certificate provided by the trusted timekeeper 110 during the current resynchronization request has expired. This may be determined, for example, by comparing the certificate's expiration time with the current time kept by the timer block 140 based on the last successful resynchronization. (To account for the fact that the timer may experience drift, it may be preferable to first subtract the maximum amount of drift which could have accumulated from the time of the last successful resynchronization from the current time.) If the certificate has not expired, the newly received time value may be used to resynchronize the timer block 140, e.g., in accordance with step 650, below.
  • the supervisor 160 may report this conflict to any or all parties with which it may be connected, as this may lead to the external resolution of conflict between timekeepers. For example, a system operator may check the conflict report to determine if there was a compromise of any of timekeeper keys; in such a case, the certificate associated with any compromised timekeeper keys could be invalidated, and, subsequently, the supervisor 160 may receive this update in a CRL.
  • the maximum amount of drift accumulated from the time the timer block 140 was last successfully synchronized may exceed a permissible value.
  • This permissible value might be set, for example, by the supervisor 160, or by code running within or outside the secure zone 150.
  • the supervisor 160 may repeat its attempts to synchronize by repeating steps 600-645.
  • the values of the synchronization block 230 may be updated to reflect the new time.
  • the timekeeper_ID 231 may be updated with the identifier for the timekeeper reporting the new time.
  • the synchronization_time 232 may be updated with the current time received from the timekeeper 110 ( e.g., at step 620).
  • the time_elapsed_until_synchronization 233 may be updated to store the total amount of time elapsed since device 120 initialization until the time of this most recent synchronization.
  • time_elapsed_until_synchronization 233 the time elapsed since the device 120 was initialized until the middle of the interval between a secure time request and the timekeeper's reply.
  • the maximum possible drift since the device 120 was initialized until the time of this most recent synchronization may be stored into synchronization_drift 234.
  • the duration of time it took to receive a response from the timekeeper 110 e.g., as calculated at step 632 and temporarily stored at step 634) may be stored into response_time 235.
  • Figure 6d is a graph showing how the error associated with a current time computation may be reduced due to one or more resynchronizations.
  • Curve 680 represents the maximum drift that could have accumulated since the computing device 120 was initialized. If computations of the current time are based on the time set during initialization ( e.g ., as calculated in accordance with the method shown on Figure 8 ), this drift curve 680 will provide an upper boundary on the possible error.
  • Curve 682 represents the maximum error associated with a current time which was calculated based on a previous synchronization event occurring at time T resync 690.
  • the shape of this curve is the same as that of the part of the curve 680 to the right of T resync 690, as if that part were shifted down.
  • the initial value of any error associated with the current time calculation may not necessarily be zero.
  • the initial error may be some value E1 (shown on Figure 6d as value 694), which may depend on the duration of time between sending a secure time request and receiving a response from a trusted timekeeper 110 (which may be stored as response_time 235).
  • E1 shown on Figure 6d as value 694
  • the maximum amount of drift accumulated since device 120 initialization will become greater than E1 694.
  • T resync2 692 T nec 691.
  • This delay may occur, for example, because during the period between T nec and T resync2 the device 120 was turned off, and no operations (except, perhaps, time monitoring in low-energy power mode, which in itself may result in greater imprecision), can be performed.
  • Figure 7 shows one exemplary method by which a secure time may be calculated using information received during the most recent synchronization with a trusted timekeeper 110.
  • a task may request the supervisor to provide the current time and the maximum error associated with that estimation. (This may be calculated, e.g ., as described with respect to Figure 8 .)
  • the time elapsed and the maximum drift accumulated since the last synchronization event may be calculated as described in greater details above.
  • the time elapsed since the last synchronization event may be added to synchronization_time 232 to calculate the current time.
  • the error associated with the time derived from the most recent synchronization_time 232 may be computed. It will be understood that error is a function of both the maximum drift associated with a timer, which increases over time, as well as any delay in receiving a response from a timekeeper; therefore, both components should be taken into account. As used throughout, the concept of drift has been represented as a quantity which is either subtracted from or added to the calculated time; in other words, the actual time falls within a range of the calculated time +/- the maximum drift.
  • time_elapsed_until_synchronization 233 selected to be exactly in the middle of the interval between sending the request to the timekeeper and receiving its reply.
  • one-half of the response_time 235 may be added to the drift accumulated since the last synchronization event to calculate the total error associated with the current time.
  • the described functionality can be implemented in varying ways for each particular application-such as by using any combination of microprocessors, microcontrollers, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and/or System on a Chip (SoC)--but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
  • FPGAs field programmable gate arrays
  • ASICs application specific integrated circuits
  • SoC System on a Chip
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Electric Clocks (AREA)

Claims (15)

  1. Appareil permettant une gestion du temps sécurisée, comprenant:
    - un stockage non volatil pour stocker une heure de synchronisation et un premier taux de dérive maximum associé à un premier compteur;
    - le premier compteur étant configuré pour s'incrémenter avec une première fréquence prédéterminée; et
    - un processeur configuré pour:
    - générer une demande d'heure courante, la demande devant comporter une valeur de circonstance générée dans l'appareil;
    - transmettre la demande à un garde-temps de confiance;
    - recevoir une réponse contenant une heure courante du monde réel, transmise par le garde-temps de confiance, la réponse étant signée numériquement avec une signature numérique;
    - vérifier la signature numérique de la réponse;
    - vérifier que la réponse est reçue dans un intervalle de temps prédéfini;
    - comparer la valeur de circonstance présente dans la demande à une valeur de circonstance présente dans la réponse;
    - déterminer que l'heure courante du monde réel transmise par le garde-temps de confiance se trouve dans une plage d'une première heure courante calculée dans l'appareil en se basant sur l'heure de synchronisation, un nombre compté par le premier compteur et le premier taux de dérive maximum; et
    - actualiser l'heure de synchronisation avec l'heure courante du monde réel présente dans la réponse transmise par le garde-temps de confiance quand l'heure courante du monde réel se trouve dans la plage de la première heure courante.
  2. Appareil selon la revendication 1, dans lequel le processeur est configuré en outre pour déterminer qu'un précédent garde-temps utilisé pour une dernière synchronisation réussie est répertorié dans une liste de révocation de certificat (CRL) présente dans la réponse reçue, ou
    dans lequel le processeur est configuré en outre pour déterminer que l'heure courante du monde réel transmise par le garde-temps de confiance se trouve dans une plage d'une deuxième heure courante calculée dans l'appareil en se basant sur un intervalle de temps écoulé depuis que l'appareil a été initialisé.
  3. Appareil selon la revendication 2, comprenant en outre une batterie, dans lequel le premier compteur est configuré pour être alimenté par la batterie pour s'incrémenter avec une fréquence parmi une pluralité de fréquences différentes prédéterminées quand l'appareil est mis hors tension.
  4. Appareil selon la revendication 2, comprenant en outre un deuxième compteur configuré pour s'incrémenter avec une deuxième fréquence prédéterminée, et dans lequel le stockage non volatil mémorise un deuxième taux de dérive maximum associé au deuxième compteur pour la deuxième fréquence prédéterminée.
  5. Appareil selon la revendication 4, comprenant en outre une batterie, dans lequel la première fréquence prédéterminée est inférieure à la deuxième fréquence prédéterminée, et le premier compteur est configuré pour être alimenté par la batterie quand l'appareil est mis hors tension.
  6. Appareil selon la revendication 5, dans lequel le processeur est configuré en outre pour:
    - stocker des informations concernant la commutation entre les premier et deuxième compteurs, et
    - fournir une référence de temps et une valeur de dérive maximum de la référence de temps en utilisant des nombres comptés respectivement par les premier et deuxième compteurs selon les informations stockées concernant lequel des premier et deuxième compteurs a été mis sous tension, l'heure de synchronisation et le premier taux de dérive maximum et le deuxième taux de dérive maximum.
  7. Procédé informatique de gestion du temps sécurisée, comprenant les étapes suivantes :
    - générer, dans un appareil, une demande d'heure courante, la demande devant comporter une valeur de circonstance générée dans l'appareil;
    - transmettre la demande à un garde-temps de confiance;
    - recevoir une réponse contenant une heure courante du monde réel, transmise par le garde-temps de confiance, la réponse étant signée numériquement avec une signature numérique;
    - vérifier la signature numérique de la réponse;
    - vérifier que la réponse est reçue dans un intervalle de temps prédéfini;
    - comparer la valeur de circonstance présente dans la demande à une valeur de circonstance présente dans la réponse;
    - déterminer que l'heure courante du monde réel transmise par le garde-temps de confiance se trouve dans une plage d'une première heure courante calculée dans l'appareil en se basant sur l'heure de synchronisation stockée dans un stockage non volatil de l'appareil, un nombre compté par un premier compteur incrémenté avec une première fréquence prédéterminée, et un premier taux de dérive maximum associé au premier compteur stocké dans le stockage non volatil de l'appareil; et
    - actualiser l'heure de synchronisation avec l'heure courante du monde réel présente dans la réponse transmise par le garde-temps de confiance quand l'heure courante du monde réel se trouve dans la plage de la première heure courante.
  8. Procédé informatique selon la revendication 7, comprenant en outre l'étape consistant à déterminer qu'un précédent garde-temps utilisé pour une dernière synchronisation réussie est répertorié dans une liste de révocation de certificat (CRL) présente dans la réponse reçue.
  9. Procédé informatique selon la revendication 7, comprenant en outre l'étape consistant à déterminer que l'heure courante du monde réel transmise par le garde-temps de confiance se trouve dans une plage d'une deuxième heure courante calculée dans l'appareil en se basant sur un intervalle de temps écoulé depuis que l'appareil a été initialisé.
  10. Procédé informatique selon la revendication 7, comprenant en outre l'étape consistant à alimenter le premier compteur en utilisant une batterie pour incrémenter le premier compteur avec une fréquence parmi une pluralité de fréquences différentes prédéterminées quand l'appareil est mis hors tension.
  11. Procédé informatique selon la revendication 10, comprenant en outre les étapes suivantes:
    - stocker des informations concernant la commutation entre les différentes fréquences prédéterminées, et
    - fournir une référence de temps et une valeur de dérive maximum de la référence de temps en utilisant des nombres comptés respectivement par le premier compteur dans les différentes fréquences prédéterminées, un taux de dérive maximum associé à chacune des différentes fréquences prédéterminées, et l'heure de synchronisation.
  12. Procédé informatique selon la revendication 8, comprenant en outre les étapes suivantes:
    - incrémenter le premier compteur avec la première fréquence prédéterminée ou un deuxième compteur avec une deuxième fréquence prédéterminée; et
    - stocker un deuxième taux de dérive maximum associé au deuxième compteur pour la deuxième fréquence prédéterminée.
  13. Procédé informatique selon la revendication 12, comprenant en outre l'étape consistant à alimenter le premier compteur pour qu'il s'incrémente avec la première fréquence prédéterminée quand l'appareil est mis hors tension, dans lequel la première fréquence prédéterminée est inférieure à la deuxième fréquence prédéterminée.
  14. Procédé informatique selon la revendication 13, comprenant en outre les étapes suivantes:
    - stocker des informations concernant la commutation entre les premier et deuxième compteurs, et
    - fournir une référence de temps et une valeur de dérive maximum de la référence de temps en utilisant des nombres comptés respectivement par les premier et deuxième compteurs selon les informations stockées concernant lequel des premier et deuxième compteurs a été mis sous tension, l'heure de synchronisation et le premier taux de dérive maximum et le deuxième taux de dérive maximum.
  15. Support informatique non transitoire contenant des instructions de programme pour un procédé de gestion du temps sécurisée, les instructions faisant exécuter le procédé par un ordinateur, comprenant les étapes suivantes:
    - générer, dans un appareil, une demande d'heure courante, la demande devant comporter une valeur de circonstance générée dans l'appareil;
    - transmettre la demande à un garde-temps de confiance;
    - recevoir une réponse contenant une heure courante du monde réel, transmise par le garde-temps de confiance, la réponse étant signée numériquement avec une signature numérique;
    - vérifier la signature numérique de la réponse ; vérifier que la réponse est reçue dans un intervalle de temps prédéfini;
    - comparer la valeur de circonstance présente dans la demande à une valeur de circonstance présente dans la réponse;
    - déterminer que l'heure courante du monde réel transmise par le garde-temps de confiance se trouve dans une plage d'une première heure courante calculée dans l'appareil en se basant sur une heure de synchronisation stockée dans un stockage non volatil de l'appareil, un nombre compté par un premier compteur incrémenté avec une première fréquence prédéterminée, et un premier taux de dérive maximum associé au premier compteur stocké dans le stockage non volatil de l'appareil; et
    - actualiser l'heure de synchronisation avec l'heure courante du monde réel présente dans la réponse transmise par le garde-temps de confiance quand l'heure courante du monde réel se trouve dans la plage de la première heure courante.
EP13742265.5A 2012-06-18 2013-06-18 Systèmes, procédés et appareils pour gestion de temps sécurisée Active EP2862120B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261661248P 2012-06-18 2012-06-18
PCT/IB2013/001275 WO2013190363A1 (fr) 2012-06-18 2013-06-18 Systèmes, procédés et appareils pour gestion de temps sécurisée

Publications (2)

Publication Number Publication Date
EP2862120A1 EP2862120A1 (fr) 2015-04-22
EP2862120B1 true EP2862120B1 (fr) 2019-05-08

Family

ID=49757081

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13742265.5A Active EP2862120B1 (fr) 2012-06-18 2013-06-18 Systèmes, procédés et appareils pour gestion de temps sécurisée

Country Status (5)

Country Link
US (3) US9338010B2 (fr)
EP (1) EP2862120B1 (fr)
CA (3) CA2879819C (fr)
TW (1) TW201411403A (fr)
WO (1) WO2013190363A1 (fr)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW201407412A (zh) 2012-04-13 2014-02-16 Ologn Technologies Ag 基於電腦之安全交易之裝置、方法與系統
EP2836956B1 (fr) 2012-04-13 2019-06-26 OLogN Technologies AG Zone sécurisée pour communications numériques
TW201403375A (zh) 2012-04-20 2014-01-16 歐樂岡科技公司 用於安全購買之安全區
EP2973180B1 (fr) 2013-03-15 2020-01-15 OLogN Technologies AG Systèmes, procédés et appareils de stockage et de fourniture sécurisés d'informations de paiement
WO2015015473A1 (fr) 2013-08-02 2015-02-05 Ologn Technologies Ag Serveur sécurisé sur un système avec des machines virtuelles
KR101550552B1 (ko) * 2014-09-19 2015-09-07 성균관대학교산학협력단 시간 동기화 주기를 조절할 수 있는 시간 동기화 슬레이브 장치 및 시간 동기화 주기 결정 방법
US10680833B2 (en) 2016-02-26 2020-06-09 Apple Inc. Obtaining and using time information on a secure element (SE)
US10523447B2 (en) * 2016-02-26 2019-12-31 Apple Inc. Obtaining and using time information on a secure element (SE)
US10630490B2 (en) 2016-02-26 2020-04-21 Apple Inc. Obtaining and using time information on a secure element (SE)
CN105915636B (zh) * 2016-06-03 2019-08-20 青岛海信移动通信技术股份有限公司 一种联系人信息的同步方法和装置
US10192177B2 (en) * 2016-06-29 2019-01-29 Microsoft Technology Licensing, Llc Automated assignment of errors in deployed code
JP2018046349A (ja) * 2016-09-13 2018-03-22 沖電気工業株式会社 通信システム、時刻同期方法、通信装置、及び通信プログラム
EP3333750A1 (fr) * 2016-12-06 2018-06-13 Safenet Canada Inc. Procédé destiné à créer un groupe de confiance de dispositifs
CN108958915A (zh) * 2018-06-28 2018-12-07 中国建设银行股份有限公司 定时任务执行方法及装置
US11924360B2 (en) 2018-10-08 2024-03-05 Green Market Square Limited Blockchain timestamp agreement
US10608829B1 (en) 2018-10-08 2020-03-31 International Business Machines Corporation Blockchain timestamp agreement
CN111008402B (zh) * 2018-10-08 2024-03-08 绿市广场有限公司 区块链时间戳协定

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090083372A1 (en) * 1999-07-02 2009-03-26 Time Certain Llc System and methods for distributing trusted time

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5001752A (en) * 1989-10-13 1991-03-19 Fischer Addison M Public/key date-time notary facility
US5327468A (en) * 1992-06-19 1994-07-05 Westinghouse Electric Corp. Synchronization of time-of-day clocks in a distributed processing network system
US5444780A (en) 1993-07-22 1995-08-22 International Business Machines Corporation Client/server based secure timekeeping system
US6473607B1 (en) * 1998-06-01 2002-10-29 Broadcom Corporation Communication device with a self-calibrating sleep timer
US6728880B1 (en) * 1999-09-17 2004-04-27 Adobe Systems Incorporated Secure time on computers with insecure clocks
US20020104004A1 (en) * 2001-02-01 2002-08-01 Bruno Couillard Method and apparatus for synchronizing real-time clocks of time stamping cryptographic modules
US7124299B2 (en) * 2001-05-18 2006-10-17 Claymore Systems, Inc. System, method and computer program product for auditing XML messages in a network-based message stream
US7065656B2 (en) * 2001-07-03 2006-06-20 Hewlett-Packard Development Company, L.P. Tamper-evident/tamper-resistant electronic components
DE10333932A1 (de) * 2003-07-25 2005-02-24 Robert Bosch Gmbh Synchronisation von datenverarbeitenden Einheiten
FI118309B (fi) * 2003-12-29 2007-09-28 Innoka Oy Menetelmä ja järjestely reaaliaikaiseksi veikkaamiseksi offlinepäätteen avulla
ATE480920T1 (de) 2006-03-28 2010-09-15 Nokia Siemens Networks Gmbh Flexible erzeugung vertrauenswürdiger zeitquellen
US8646096B2 (en) * 2007-06-28 2014-02-04 Microsoft Corporation Secure time source operations for digital rights management
WO2009105542A2 (fr) * 2008-02-19 2009-08-27 Interdigital Patent Holdings, Inc. Méthode et appareil associés à des techniques de mesure du temps sécurisées éprouvées
US8977881B2 (en) * 2011-08-12 2015-03-10 Apple Inc. Controller core time base synchronization
US8892923B2 (en) * 2011-12-20 2014-11-18 Arm Limited Data processing apparatus and method for maintaining a time count value in normal and power saving modes of operation
US10419907B2 (en) * 2012-02-22 2019-09-17 Qualcomm Incorporated Proximity application discovery and provisioning
US8943352B1 (en) * 2012-05-07 2015-01-27 Dust Networks, Inc. Low power timing, configuring, and scheduling
US8667288B2 (en) * 2012-05-29 2014-03-04 Robert Bosch Gmbh System and method for message verification in broadcast and multicast networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090083372A1 (en) * 1999-07-02 2009-03-26 Time Certain Llc System and methods for distributing trusted time

Also Published As

Publication number Publication date
EP2862120A1 (fr) 2015-04-22
US9654297B2 (en) 2017-05-16
CA2879819A1 (fr) 2013-12-27
WO2013190363A1 (fr) 2013-12-27
US20170317838A1 (en) 2017-11-02
US9338010B2 (en) 2016-05-10
US20130339742A1 (en) 2013-12-19
CA3113258A1 (fr) 2013-12-27
CA3113258C (fr) 2023-01-24
US10374811B2 (en) 2019-08-06
CA3080045A1 (fr) 2013-12-27
TW201411403A (zh) 2014-03-16
US20160254919A1 (en) 2016-09-01
CA2879819C (fr) 2021-04-20

Similar Documents

Publication Publication Date Title
US10374811B2 (en) Systems, methods and apparatuses for secure time management
JP6166397B2 (ja) セキュアな信頼された時刻技法のための方法および装置
KR101086568B1 (ko) 무선 장치에 대한 보안 시간 기능
Carpent et al. ERASMUS: Efficient remote attestation via self-measurement for unattended settings
US20060074600A1 (en) Method for providing integrity measurements with their respective time stamps
JP2013165494A5 (fr)
De Oliveira Nunes et al. On the TOCTOU problem in remote attestation
EP1806672A2 (fr) Dispositif et procédé pour stockage de l'heure actuelle
US11245484B2 (en) Authenticating time sources using attestation-based methods
US10250392B2 (en) Arbitrary base value for EPID calculation
JP5223860B2 (ja) 時刻情報配信システム、時刻配信局、端末、時刻情報配信方法及びプログラム
JP5039931B2 (ja) 情報処理装置
CN101133401A (zh) 时间戳装置、时刻校正方法、以及时刻校正程序
WO2006092833A1 (fr) Dispositif d’horodateur, procede et programme d’etalonnage temporel
CN109804414A (zh) 确定一时间的方法
US11182463B2 (en) Method to create a trusted pool of devices
CN101111813A (zh) 时间戳装置、时刻校正方法、以及时刻校正程序
WO2024094629A1 (fr) Procédé et dispositif mobile permettant de fournir une lecture temporelle
KR20100017715A (ko) 시간 추정의 정확성을 향상시키기 위한 회로를 구비하는 메모리 디바이스와, 메모리 디바이스를 사용하기 위한 방법

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150107

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

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20171213

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

Owner name: OLOGN TECHNOLOGIES AG

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602013055023

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0021720000

Ipc: G06F0001040000

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 1/04 20060101AFI20181017BHEP

Ipc: G06F 1/12 20060101ALI20181017BHEP

Ipc: G06F 12/14 20060101ALI20181017BHEP

Ipc: H04L 9/32 20060101ALI20181017BHEP

Ipc: G06F 21/72 20130101ALI20181017BHEP

Ipc: G06F 1/14 20060101ALI20181017BHEP

Ipc: G06F 1/10 20060101ALI20181017BHEP

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

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

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

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190515

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602013055023

Country of ref document: DE

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20190508

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

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

Ref country code: 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: 20190508

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

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

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

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

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

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

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

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

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

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

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

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

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

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1131191

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190508

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

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

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

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

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

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

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602013055023

Country of ref document: DE

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

Ref country code: IT

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

Effective date: 20190508

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

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

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

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20190630

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

26N No opposition filed

Effective date: 20200211

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

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

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

Ref country code: LU

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

Effective date: 20190618

Ref country code: BE

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

Effective date: 20190630

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

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

Ref country code: IS

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

Effective date: 20190908

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

Ref country code: MT

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

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

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 11

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525

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

Ref country code: FR

Payment date: 20230411

Year of fee payment: 11

Ref country code: DE

Payment date: 20230425

Year of fee payment: 11

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

Ref country code: GB

Payment date: 20230427

Year of fee payment: 11

Ref country code: CH

Payment date: 20230701

Year of fee payment: 11