WO2020064920A1 - Estimation de temps sécurisée - Google Patents

Estimation de temps sécurisée Download PDF

Info

Publication number
WO2020064920A1
WO2020064920A1 PCT/EP2019/076014 EP2019076014W WO2020064920A1 WO 2020064920 A1 WO2020064920 A1 WO 2020064920A1 EP 2019076014 W EP2019076014 W EP 2019076014W WO 2020064920 A1 WO2020064920 A1 WO 2020064920A1
Authority
WO
WIPO (PCT)
Prior art keywords
time
block
blockchain
series
electronic device
Prior art date
Application number
PCT/EP2019/076014
Other languages
English (en)
Inventor
Andrzej Duda
Faten MKACHER
Original Assignee
Gorgy Timing
Institut Polytechnique De Grenoble
Universite Grenoble Alpes
Centre National De La Recherche Scientifique
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 Gorgy Timing, Institut Polytechnique De Grenoble, Universite Grenoble Alpes, Centre National De La Recherche Scientifique filed Critical Gorgy Timing
Priority to EP19773112.8A priority Critical patent/EP3857843A1/fr
Publication of WO2020064920A1 publication Critical patent/WO2020064920A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • 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/3236—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 cryptographic hash functions
    • H04L9/3239—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 cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present disclosure relates generally to electronic devices capable of communication over communication networks, to a secure time synchronization protocol, and to a device and method for securely obtaining a time estimation.
  • FIG. 1 schematically illustrates a system 100 for providing time synchronization.
  • the system comprises a time server (TS) and a time client device (TC) that communicate over a communication network.
  • the time client device TC is a network entity that wishes to obtain secure time synchronization, for example in order to synchronize its local clock 102 with a precise reference. For this, it contacts the time server TS via the communication network using a time synchronization protocol (TIME SYNC) , such as the network time protocol (NTP) .
  • TIME SYNC time synchronization protocol
  • NTP network time protocol
  • the time server TS for example comprises a precise time source 104, such as a micro atomic oscillator or other means for maintaining a precise time reference.
  • the time client device TC may request time synchronization from the time server TS during an initialization phase following a first activation of the time client TC, and this operation may be repeated at regular intervals in order to ensure time synchronization between the local clock 102 of the time client device TC and the precise time source 104 of the time server TS.
  • Figure 1 illustrates the case of a single time client device TC.
  • the time client device TC and time server TS may form part of a relatively large network in which there are many time client devices TC served by the time server TS.
  • time server TS For example, for applications such as the dissemination of certified legal time for commercial transactions, there may be many points of sale requiring time synchronization.
  • a further technical problem in the system of Figure 1 is that in order to authenticate the time server, the server certificate should generally be verified, including its period of validity. However, upon initial activation of the time client device TC, this device may have no notion of time. This leads to a Catch-22 situation in which the time client device TC should have a prior knowledge of time in order to validate the time server certificate, but obtaining time information from the time server TS requires prior certificate validation .
  • a time client device comprising a network interface for communicating over a communication network, the time client device being configured to: receive, over the communication network from an authentication server, a first key, and a first value containing the first key in encrypted form; generate a second value using the first key; and during a time synchronization phase, transmit to a time server the first and second values.
  • the time client device is configured, during the time synchronization phase, to: transmit the first value to the time server in a first message comprising a first timestamp; and transmit the second value to the time server in a second message.
  • the second value is a message authentication code of the first message generated using the first key.
  • the first value further contains an indication of the encryption algorithm to be used to generate the second value.
  • the time client device is further configured to transmit over the communication network a request to the authentication server for the first key and the first value, the request containing an identifier of the time client device, the identifier for example being an IP (Internet Protocol) address.
  • IP Internet Protocol
  • the time client device is configured to further include in the request an identifier of the time server, the identifier of the time server for example being an IP address.
  • the first value is encrypted using a second key not known by the time client device .
  • the time client device is further configured to: receive from the time server a third message containing one or more further timestamps; receive from the time server a third value corresponding to: a message authentication code of at least part of the first message and/or at least part of the third message generated using the first key; or a digital signature of at least part of the first message and/or at least part of the third message generated based on a private key; and authenticate the third message by verifying the third value based on the first key or on a public key.
  • the time client device is further configured to: generate a time estimation by requesting from a node in a blockchain network headers of a series of blocks of a blockchain, extracting a timestamp from the header of a most recent block of the series; and generating the time estimation based on the extracted timestamp; and validate an authentication certificate of the authentication server based on the time estimation.
  • a time synchronization system comprising: an authentication server comprising a network interface for communicating over a communication network, the authentication server being configured to transmit, over the communication network to a first time client device, a first key, and a first value containing the first key in encrypted form; and a time server configured to receive from the first time client device, during a time synchronization phase, the first value and a second value generated using the first key, the time server being configured to authenticate the first time client device based on the second value.
  • the authentication server is further configured to transmit, over the communication network to a second time client device, a third key, and a third value containing the third key in encrypted form; and the time server is further configured to receive from the second time client device, during a time synchronization phase, the third value and a fourth value generated using the third key, the time server being configured to authenticate the second time client device based on the fourth value.
  • a method of obtaining time synchronization by a time client device comprising a network interface for communicating over a communication network, the method comprising: receiving, over the communication network from an authentication server, a first key, and a first value containing the first key in encrypted form; generating, by the time client device, a second value using the first key; and during a time synchronization phase, transmitting by the time client device the first and second values to a time server.
  • a method of supplying time synchronization by a time synchronization system comprising: transmitting, by an authentication server over a communication network to a time client device, a first key, and a first value containing the first key in encrypted form; during a time synchronization phase, receiving by a time server from the time client device, the first value and a second value generated using the first key; and authenticating, by the time server, the time client device based on the second value.
  • a method of generating a time estimation using an electronic device comprising a network interface for communicating over a communication network, the method comprising: requesting, by the electronic device from a node in a blockchain network, headers of a series of blocks of a blockchain; extracting a timestamp from the header of a most recent block of the series; and generating a time estimation based on the extracted timestamp.
  • the method further comprises: requesting, from a further node in the blockchain network, headers of the series of blocks of the blockchain; and extracting a further timestamp from the header of the most recent block of the series, wherein generating the time estimation is further based on the further timestamp.
  • the blockchain comprises a chain of blocks from a genesis block to an N ' th most recently generated block, the header of the most recent block of the series being an (N'-j')th block of the blockchain, where j' is equal to between 6 and 15.
  • the method further comprises requesting from the node in the blockchain network the headers up to a most recent block of the blockchain, and identifying the (N'-j')th block as the most recent block of the series.
  • each block in the blockchain except for the genesis block, comprises a hash value of a previous block in the chain.
  • the blockchain is the blockchain of a crypto currency.
  • requesting, by the electronic device, headers of the series of blocks comprises requesting the headers of the blockchain starting from an initial block known to the electronic device.
  • the method further comprises, during a configuration phase, receiving by the electronic device a hash of the initial block.
  • a method of verifying an authentication certificate comprising: generating a time estimation according to the above method; and verifying, by the electronic device, the time validity of the authentication certificate based on the generated time estimation .
  • an electronic device comprising a network interface for communicating over a communication network, the electronic device being configured to: request, from a node in a blockchain network, headers of a series of blocks of a blockchain; extract a timestamp from the header of a most recent block of the series; and generate a time estimation based on the extracted timestamp.
  • the electronic device is further configured to: request, from a further node in the blockchain network, headers of the series of blocks of the blockchain; and extract a further timestamp from the header of the most recent block of the series, wherein generating the time estimation is further based on the further timestamp.
  • the blockchain comprises a chain of blocks from a genesis block to an Nth most recently generated block, the header of the most recent block of the series being an (N-j ) th block of the blockchain, where j is equal to between 6 and 15.
  • the electronic device is further configured to request from the node in the blockchain network the headers up to a most recent block of the blockchain, and to identify the (N'-j')th block as the most recent block of the series.
  • the electronic device is further configured to request headers of the series of blocks comprises requesting the headers of the blockchain starting from an initial block, wherein the electronic device stores a hash of the initial block.
  • the electronic device is further configured to verify the time validity of an authentication certificate based on the generated time estimation .
  • Figure 1 (described above) schematically illustrates a system for providing time synchronization
  • Figure 2 schematically illustrates a system for providing time synchronization according to an example embodiment of the present disclosure
  • Figure 3 represents communications between network entities in the system of Figure 2 according to an example embodiment of the present disclosure
  • Figure 4 schematically illustrates a system for securely generating a time estimation according to an example embodiment of the present disclosure
  • Figure 5 represents a blockchain according to an example embodiment of the present disclosure
  • Figure 6 is a flow diagram illustrating operations in a method of securely generating a time estimation according to an example embodiment of the present disclosure
  • Figure 7 schematically illustrates a time client device according to an example embodiment of the present disclosure .
  • FIG. 1 schematically illustrates a system 200 for providing time synchronization according to an example embodiment of the present disclosure.
  • the system 200 comprises time client devices TCI and TC2 each comprising a local clock 102 similar to that of the time client device TC of Figure 1. Furthermore, each of the devices TCI, TC2 for example comprises a network interface for communicating over a network with a time server TS.
  • the network is for example a packet-switched network including for example one or more LANs (local area networks) , WLANS (wireless LANs) and/or the internet. While an example is illustrated with two time client devices, in practice the time server TS may serve many time client devices, for example hundreds or even thousands of such devices.
  • the time client devices TCI, TC2 are points of sale, and the time server TS disseminates certified legal time to the points of sale for commercial transactions.
  • the time server TS is similar to the time server of Figure 1, and comprises a relatively precise time source 104, which for example comprises a micro atomic oscillator or other means for maintaining a precise time reference.
  • the time source 104 is based on a Rubidium oscillator or an OCXO (Oven Controlled X-tal (crystal) Oscillator) , although other types of oscillators would be possible .
  • the system 200 further comprises an authentication server AS, having for example a precise local clock 202.
  • Each of the time clients TCI and TC2 may request time synchronization from the time server TS. For example, such requests may occur when the device TCI or TC2 is activated for a first time, and/or at regular intervals throughout the lifetime of the devices TCI and TC2 in order to maintain time synchronization. Indeed, the local clock 102 of each time client device TCI, TC2 for example deviates to some extent over time, and therefore by resynchronizing with the time server TS, the devices TCI and TC2 are able to maintain relatively precise time, for example with a precision of a few milliseconds with respect to Coordinated Universal Time.
  • a configuration phase is for example implemented using the authentication server AS. This for example involves communications between the authentication server AS and the time server TS, and between the authentication server AS and each time client device TCI, TC2.
  • TIME SYNC time synchronization phase
  • Figure 3 represents communications between the time client device TCI, the authentication server AS, and the time server TS of Figure 2 according to an example embodiment of the present disclosure.
  • a setup operation for example occurs in which mutual authentication based on certificates is implemented between the time client device TCI and the authentication server AS, and between the time server TS and the authentication server AS.
  • This for example involves the establishment of a DTLS (datagram transport layer security) session, as known by those skilled in the art.
  • the DTLS session creates secure channels that are used to exchange messages during the configuration phase .
  • the configuration phase (CONFIG) between the time server TS and the authentication server AS is for example performed once, or at relatively infrequent intervals, for example once a month in order to refresh the cryptographic materials used during time synchronization.
  • the time server TS for example transmits to the authentication server AS its supported cryptographic algorithms ALGO_TS, including in some embodiments its supported MAC (message authentication code) and/or its supported DS (digital signature) .
  • the authentication server AS for example responds by generating and transmitting to the time server TS a key S, which is for example a long term secret to be used by the time server TS.
  • a key S which is for example a long term secret to be used by the time server TS.
  • PKI Public Key
  • the authentication server AS also for example generates and transmits to the time server TS a public key/private key pair Ke/Kd.
  • the same keys S, Ke and Kd are for example used for communications with each time client device, so that the time server TS does not need to store a different key for use with each time client device.
  • the configuration phase (CONFIG) between the time client device TCI and the authentication server AS (and between the other time client devices and the authentication server) is for example performed after the configuration phase with the time server TS described above.
  • the time client device TCI for example initiates the configuration phase by transmitting to the authentication server AS: its identifier TCID, which is for example in the form of an IP address of the time client device included automatically in the transmitted message; an identifier TSID of the time server TS with which the time client device TCI wishes to perform time synchronization; and its supported cryptographic algorithms ALGO_TC, including in some embodiments its supported MAC and/or its supported digital signature DS .
  • the time client device TCI does not transmit the identifier TSID of the time server TS, and instead the authentication server AS proposes a time server TS to the time client device TCI.
  • the time server TS is for example configured to authenticate the time synchronization messages it sends to the time client TCI using either a MAC generated using a symmetric key K, or a digital signature DS generated using the private key Kd.
  • the authentication server AS for example responds by providing to the time client TCI the symmetric key K, and in some cases the public key Ke of the time server TS, and the negotiated cryptographic algorithm (s) ALGO_TC_TS that is/are compatible with both the time server TS and the time client device TCI and is/are to be used for the communications therebetween.
  • the authentication server AS for example comprises a memory storing, for each time client device, and for each time server TS in the case that there is more than one, the relationships TSID-[S, (Ke,Kd)] and TCID-[K,C], where the identifiers TSID and TCID may correspond to IP addresses of the time server and time client device respectively.
  • the authentication server AS also for example provides to the time client device TCI a state C, in the form of an encrypted value.
  • the state C for example corresponds to the symmetric key K and in some embodiments one or more further values, all encrypted using the key S of the time server TS.
  • the key K is for example unique for each time client device, and the use of the state C for example permits the time server to be stateless, in other words it does not need to store the key K associated with each time client device, as will be described in more detail below.
  • the key S is for example not known to the time client device TCI, which cannot therefore decrypt or modify the state C. Only the time server TS is for example able to decrypt the state C.
  • the further values encrypted in the state C may include a value indicating the negotiated algorithm (s) ALGO_TC_TS selected for use for communications between the time client device TCI and the time server TS.
  • the negotiated algorithm for communications between the time client device TCI and the time server TS is the cryptographic primitive known as AES- GCM (Advanced Encryption Standard - Galois/Counter Mode) algorithm, or a Feistel cipher.
  • AES- GCM Advanced Encryption Standard - Galois/Counter Mode
  • the MAC algorithms supported by the time server and/or by the time client device TCI for example include the HMAC- SHA256 (Hash-based Message Authentication Code - Secure Hash Algorithm) algorithm, and/or the AES-CMAC (Advanced
  • Encryption Standard - Cipher-based Message Authentication Code) algorithm and/or the HMAC-MD5 (HMAC - Message Digest 5) .
  • the digital signature DS supported by the time server and/or by the time client device TCI for example includes the Ed25519 signature, which is an EdDSA (Edwards-curve Digital Signature Algorithm) using SHA-512 and Curve25519, and/or the MQQ-SIG (Multivariate Quadratic Quasigroups Signature) signature .
  • Ed25519 signature is an EdDSA (Edwards-curve Digital Signature Algorithm) using SHA-512 and Curve25519
  • MQQ-SIG Multivariate Quadratic Quasigroups Signature
  • the time client device TCI for example transmits a message ml to the time server TS.
  • the message ml for example includes data corresponding to the particular protocol to be used for time synchronization.
  • the message includes a timestamp T1 corresponding to the timestamp of the time client device TCI at the time that the message ml is generated and transmitted.
  • the message ml for example includes a nonce n, and the state C.
  • the nonce n is for example a random value included in every message ml, and provides protection against replay attacks.
  • the time server TS includes this nonce n, or a MAC or digital signature based on this nonce, in a future reply message (described in more detail below) to the time client device, which can thus verify that the nonce n is the same .
  • the time client device TCI also for example transmits to the time server TS a second message m2 comprising a value t ⁇ corresponding for example to a MAC value MAC_K(ml) generated using the symmetric key K.
  • this MAC value is a code generated based on the first message ml already received by the time server TS. Alternatively, it could be generated based on only part of the message ml, for example based on the state C, or on the nonce n.
  • the messages ml and m2 are for example transmitted independently, such that the time server TS can process the initial message ml as soon as it is received without first verifying the MAC. As such, the quality of the time synchronization operation is improved.
  • the messages ml and m2 could be transmitted as a single message.
  • the time server TS for example responds to the message ml by generating and transmitting to the time client device TCI a message m3 containing the timestamp Tl, and also timestamps T2 and T3 in accordance with the NTP protocol.
  • the timestamp T2 corresponds to the reception time of the message ml by the time server TS
  • the timestamp T3 corresponds to the transmission time of the message m3 to the time client device TCI.
  • the time server TS also for example decrypts the encrypted value C based on its secret key S, and extracts therefrom the symmetric key K and in some embodiments the negotiated algorithm ALGO_TC_TS. The time server TS is then for example able to verify the MAC MAC_K(ml) provided in the message m2 based on the symmetric key K.
  • the time server TS also for example transmits a message m4 to the time client device TCI after the message m3, the message m4 being used for authentication.
  • the message m4 comprises a value t2 corresponding for example to a MAC code MAC_K (ml
  • the authentication could be provided by a digital signature DS_kd (ml
  • This digital signature is for example generated using the private key Kd of the time server TS.
  • the time server TS is capable of generating both the MAC code MAC_K (ml
  • the MAC and/or digital signature could be generated based on only part of the messages ml and m3, for example based only on the nonce of the message ml and/or on only the timestamps T2 and T3 of the message m3.
  • the time client device TCI is then able to determine a relatively precise estimation of the time by calculating the time offset of its local clock 102 with respect to the clock 104 of the time server TS and the round-trip time RTT of the communications between time client TCI and the time server TS, which are for example determined by the following equations :
  • T4 is a timestamp corresponding to the reception time of the message m3 by the time client device TCI.
  • the time client device TCI is for example configured to adjust its clock based on the computed values of Offset and RTT. As will be appreciated by those skilled in the art, in some cases the time synchronization operation is repeated multiple times, and the clock adjustment is based on a filtering and/or statistical analysis of the computed set of values of Offset and RTT. Furthermore, in some embodiments, the value of RTT is compared to a threshold parameter D, and the time client device TCI is configured to reject the message m4 and/or abort the time synchronization if the value of RTT exceeds the threshold parameter D, thereby defending against delay attacks.
  • the time client device TCI also for example authenticates the time information provided by the time server TS by verifying the authentication code or digital signature provided with the message m4.
  • the time client device TCI for example verifies this code based on the symmetric key K, for example by recalculating the MAC, and comparing the recalculated MAC with the one provided with the message m4.
  • the time client device TCI for example verifies this signature by decrypting the signature using its public key Ke .
  • initial communications between the authentication server AS and the time client device TCI and time server TS correspond to a setup phase during which mutual authentication is performed, based for example on an exchange of certificates.
  • the time client device TCI may be a device that does not have a synchronous clock and thus has no notion of time upon being power-up for the first time.
  • a system and method of securely obtaining, by an electronic device, a time estimation will now be described with reference to Figures 4 to 6.
  • the electronic device could correspond to the time client device TCI or TC2 of Figure 2 for the purposes of certificate validation, or to any electronic device wishing to obtain an estimate of the current time .
  • Figure 4 schematically illustrates a system 400 for generating a time estimation according to an example embodiment of the present disclosure.
  • an electronic device 402 wishes to obtain an estimate of the current time.
  • the device 402 is a device with no user interface, or with a user interface that does not permit time information to be entered.
  • the device 402 is a portable electronic device capable of wireless communications, such as an IoT (Internet of Things) device.
  • IoT Internet of Things
  • the time estimation is obtained using a blockchain network 406.
  • the blockchain network 406 for example comprises J nodes, each storing similar versions of a same blockchain BC .
  • the number J of nodes is for example equal to at least 2, and could be equal to hundreds or thousands.
  • the device 402 requests certain data of the blockchain BC from a node 404 of a blockchain network 406.
  • the blockchain BC is for example an immutable public blockchain, such the blockchain of a crypto currency such as Bitcoin or the like (the name "Bitcoin” may correspond to a registered trademark) .
  • a blockchain network is, by design, a trusted source due to its particular structure.
  • a timestamp is for example obtained by the device 402 from one or more blocks of the blockchain using peer-to-peer access.
  • Peer-to-peer access to the Bitcoin blockchain is for example described in more detail in the publication by S. Nakamoto entitled “Bitcoin: A peer-to-peer Electronic Cash System", May 2011.
  • the device 402 requests the headers of a series of blocks of the blockchain BC, and extracts a timestamp from one of these headers.
  • Figure 5 represents the blockchain BC of Figure 4 according to an example embodiment.
  • the blockchain BC for example comprises blocks B0 to BN, the block B0 being a genesis block of the blockchain BC, and the block BN being the most recent block of the blockchain BC .
  • Each block for example comprises a header (HEADER) containing an identifier (BLOCK 0 to BLOCK N) of the block, and a timestamp (TIMESTAMP) .
  • Each block further comprises data, which in the case of the crypto currency bloc for example corresponds to ledger data (LEDGER DATA) .
  • LEDGER DATA ledger data
  • the genesis block BO includes a hash (HASH) of itself, and each other block further includes a hash of the previous block (HASH (PREV) ) , thereby rendering it difficult for older blocks to be modified without the approval of the majority of the nodes in the blockchain network .
  • Figure 6 is a flow diagram illustrating operations in a method of generating a time estimation according to an example embodiment of the present disclosure.
  • the device 402 has been configured with the hash of the (N-j ) th block in the blockchain, where N is the last block in the chain at the time of the initial configuration operation.
  • N is the last block in the chain at the time of the initial configuration operation.
  • j is equal to between 6 and 15, and is equal to 10 in one example.
  • the device 402 has for example identified the node 404 as a peer in the blockchain network 406 and knows the IP address of this peer. For example, the device 402 has performed an operation of peer discovery, for example using several DNS seeds or hardcoded IP addresses.
  • the electronic device 402 requests a series of headers from the peer 404 in order to perform header synchronization with the peer 404, and without storing the whole blockchain.
  • a "GetHeaders" command is for example used.
  • the command is for example of the form GetHeaders (X,L) , where X is the identifier of the earliest block requested, and L is the number of headers requested. In the case of Bitcoin nodes, a maximum of 2000 headers can be supplied.
  • the device 402 for example requests the headers starting from the (N-j ) th block hash, which is for example known to the device 402 from the initial configuration operation .
  • the peer 404 takes the hash of the (N-j ) th block, and replies to the device 402 with the requested series of L headers chained after the (N-j ) th block.
  • the device 402 then for example repeats the header synchronization until the most recent block N' of the blockchain is reached, and identifies the header of the block N'-j' in the series.
  • the device 402 only requests the headers of the blocks up to the (N'-j')th block.
  • the device 402 identifies the header of the (N'-j')th block, where the N ' th block is the most recent block, and j' is equal to between 6 and 15, and in one example is equal to 10. In some embodiments, j' and j are equal.
  • the electronic device 402 extracts the timestamp from the header of the block N'-j'.
  • this timestamp has the same format as the 64-bit timestamp used in NTP, while in other embodiments the format of the blockchain timestamp could be different and converted into the appropriate format.
  • the operations 601 and 602 may be repeated for one or more other nodes or peers of the blockchain in order to provide further verification that the headers are genuine, and to protect against MITM (man-in-the-middle ) and masquerade attacks.
  • MITM man-in-the-middle
  • this involves requesting the headers of the series of blocks from the further peer from the (N-j ) th block hash up to an (N'-j')th block, or up to the most recent block N', identifying the header of the (N'-j')th block and extracting the timestamp from this header.
  • the new timestamp is for example compared to the previously extracted timestamp in order to verify that they are identical, thereby verifying the time stamp based on at least two separate nodes.
  • a current time is estimated based on the extracted timestamp ( s ) , and a local clock 102 of the electronic device 402 is for example synchronized based on the time estimate.
  • the timestamp that is relied upon is not from the most recent block of the blockchain, there is likely to be a time offset between the time of the extracted timestamp and the actual time, which will depend on the value of j .
  • the present inventors have found however that it is generally possible to select a value of j that provides a time that is accurate to within a few hours, generally enough for validating an authentication certificate. Indeed, such certificates are generally valid up until a certain date.
  • the choice of the parameter j is for example based on the validity property of the timestamp in the block chain.
  • a certificate is for example validated based on the time estimate.
  • a revoked certificate can be identified and rejected by the device 402.
  • other uses could be made of the generated time estimate .
  • FIG. 7 schematically illustrates the time client device TCI of Figure 2 in more detail according to an example embodiment .
  • the device TCI for example includes a processing device (P) 702 comprising one or more processing cores.
  • the processing device 702 is for example coupled to a local clock (LOCAL CLOCK) 102, which for example comprises a local oscillator, such as a quartz oscillator or the like, and one or more counters.
  • the device TCI also for example comprises a network interface (NETWORK INTERFACE) 704 and a memory (MEMORY) 706 coupled to the processing device 702.
  • NETWORK INTERFACE NETWORK INTERFACE
  • MEMORY memory
  • the memory 706 for example stores instructions that, when executed by the processing device 702, cause the operations of the time client device TCI described above in relation with Figure 3 to be implemented.
  • the time client device TC2, the authentication server AS, and the electronic device 402 of Figure 4 are for example implemented by similar circuits to that of Figure 2.
  • the time server TS is also for example implemented by a similar circuit, except that, instead of or in addition to the local clock 102, the time server TS comprises the secure time source 104.
  • its memory for example stores instructions that implement the method described above in relation with Figure 6.
  • these devices also for example comprise memories storing instructions that implement the operations of these devices described above in relation with Figure 3.
  • An advantage of the embodiments described in relation with Figures 2 and 3 is that the authentication server AS relieves the time server TS of a significant amount of the burden, in particular algorithm negotiation and key exchanges. This permits the time server TS to handle time synchronization operations with a relatively high number of time client devices and permits relatively high availability of the time server TS.
  • the exchanges between the time client device and the time server TS are rendered secure by the generation and transmission to the time server of an authentication code by the time client device based on the symmetric key K supplied by the authentication server AS.
  • the time server TS to be authenticated using a digital signature based on asymmetric keys, non-repudiation can be supported, while time-critical operations still rely on symmetric cryptography using the symmetric key K.
  • An advantage of the embodiments described in relation with Figures 4 to 6 is that a secure time estimation can be obtained in a relatively simple and secure manner. Indeed, the time information contained in the headers of the blocks of a blockchain provides a rough time estimation that is validated by all peers in the blockchain network.
  • time client device TCI being capable of obtaining a time estimation in order to validate an authentication certificate, for example in relation with a DTLS session, prior to the configuration phase with the authentication server AS.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)

Abstract

La présente invention concerne un procédé de génération d'une estimation de temps à l'aide d'un dispositif électronique (402) comprenant une interface réseau pour communiquer sur un réseau de communication, le procédé consistant à : demander, par le dispositif électronique (402) à partir d'un nœud (404) dans un réseau de chaîne de blocs (406), des en-têtes d'une série de blocs d'une chaîne de blocs (BC); à extraire une estampille temporelle de l'en-tête d'un bloc le plus récent de la série; et à générer une estimation de temps sur la base de l'estampille temporelle extraite.
PCT/EP2019/076014 2018-09-27 2019-09-26 Estimation de temps sécurisée WO2020064920A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19773112.8A EP3857843A1 (fr) 2018-09-27 2019-09-26 Estimation de temps sécurisée

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1858872 2018-09-27
FR1858872A FR3086829B1 (fr) 2018-09-27 2018-09-27 Estimation temporelle securisee

Publications (1)

Publication Number Publication Date
WO2020064920A1 true WO2020064920A1 (fr) 2020-04-02

Family

ID=66166018

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/076014 WO2020064920A1 (fr) 2018-09-27 2019-09-26 Estimation de temps sécurisée

Country Status (3)

Country Link
EP (1) EP3857843A1 (fr)
FR (1) FR3086829B1 (fr)
WO (1) WO2020064920A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050251603A1 (en) * 2004-04-27 2005-11-10 Sony Corporation Time setting system and time setting method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050251603A1 (en) * 2004-04-27 2005-11-10 Sony Corporation Time setting system and time setting method

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
FAN KAI ET AL: "Secure Time Synchronization Scheme in IoT Based on Blockchain", 2018 IEEE INTERNATIONAL CONFERENCE ON INTERNET OF THINGS (ITHINGS) AND IEEE GREEN COMPUTING AND COMMUNICATIONS (GREENCOM) AND IEEE CYBER, PHYSICAL AND SOCIAL COMPUTING (CPSCOM) AND IEEE SMART DATA (SMARTDATA), IEEE, 30 July 2018 (2018-07-30), pages 1063 - 1068, XP033556393, DOI: 10.1109/CYBERMATICS_2018.2018.00196 *
FATEN MKACHER ET AL: "Secure Time Synchronization Protocol", 2018 IEEE INTERNATIONAL SYMPOSIUM ON PRECISION CLOCK SYNCHRONIZATION FOR MEASUREMENT, CONTROL, AND COMMUNICATION (ISPCS), 1 September 2018 (2018-09-01), https://hal.archives-ouvertes.fr/hal-01865259v1, pages 1 - 6, XP055604644, Retrieved from the Internet <URL:http://hal.univ-grenoble-alpes.fr/hal-01865259/document> [retrieved on 20190711], DOI: 10.1109/ISPCS.2018.8543077 *
FATEN MKACHERXAVIER BESTELANDRZEJ DUDA: "Secure Time Synchronization Protocol", ISPCS 2018, 30 September 2018 (2018-09-30)
STENN D MILLS P PRINDEVILLE NETWORK TIME FOUNDATION H: "Network Time Protocol: Secure Network Time; draft-stenn-ntp-secure-network-time-00.txt", NETWORK TIME PROTOCOL: SECURE NETWORK TIME; DRAFT-STENN-NTP-SECURE-NETWORK-TIME-00.TXT; INTERNET-DRAFT: INTERNET ENGINEERING TASK FORCE, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205, 2 July 2018 (2018-07-02), pages 1 - 4, XP015127553 *

Also Published As

Publication number Publication date
FR3086829B1 (fr) 2023-01-06
FR3086829A1 (fr) 2020-04-03
EP3857843A1 (fr) 2021-08-04

Similar Documents

Publication Publication Date Title
US10853772B2 (en) Method and system for exchange of value or tokens between blockchain networks
EP3437247B1 (fr) Système et procédé de distribution de matériau et de certificat de clé basée sur l&#39;identité
US7096362B2 (en) Internet authentication with multiple independent certificate authorities
CN105917689B (zh) 以信息为中心的网络中的安全的点对点组
US7461250B1 (en) System and method for certificate exchange
Dowling et al. Authenticated network time synchronization
US20020154782A1 (en) System and method for key distribution to maintain secure communication
US20050010757A1 (en) Public-key infrastructure in network management
WO2017167771A1 (fr) Protocoles d&#39;établissement de liaison &#34;handshake&#34; pour matériau de clé basée sur l&#39;identité et certificats
US10158636B2 (en) Method for setting up a secure end-to-end communication between a user terminal and a connected object
US20240089115A1 (en) Secure time synchronization
EP1493243B1 (fr) Transfert securise de fichiers
Moreira et al. Security mechanisms to protect IEEE 1588 synchronization: State of the art and trends
CN111526001B (zh) 时钟同步方法、装置和系统
Lin et al. An anonymous and secure authentication and key agreement scheme for session initiation protocol
Langer et al. NTS4PTP—A comprehensive key management solution for PTP networks
CN109995723B (zh) 一种域名解析系统dns信息交互的方法、装置及系统
Navas et al. Late: A lightweight authenticated time synchronization protocol for iot
WO2020064920A1 (fr) Estimation de temps sécurisée
Langer et al. PTP Security key management solutions
US20220141199A1 (en) Method and system for transmitting data in a network
Mkacher et al. Secure time synchronization protocol
Langer et al. Extending the network time security protocol for secure communication between time server and key establishment server
Langer et al. A network time security based automatic key management for PTPv2. 1
Cheng Internet Engineering Task Force H. Wang, Ed. Internet-Draft Y. Yang Intended status: Informational X. Kang Expires: April 12, 2020 Huawei International Pte. Ltd.

Legal Events

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

Ref document number: 19773112

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019773112

Country of ref document: EP

Effective date: 20210428