FR3086829A1 - SECURE TEMPORAL ESTIMATE - Google Patents

Abstract

The present invention relates to a method for producing a time estimate by means of an electronic device (402) comprising a network interface for communicating through a communication network, this method comprising: the request, by the electronic device (402 ) at a node (404) of a network of block chains (406), of headers of a series of blocks of a block chain (BC); extracting a timestamp from the header of a most recent block in the series; and producing the time estimate from the extracted timestamp.

Description

DESCRIPTION

TITLE: TEMPORAL ESTIMATE SECURE

Technical area

The present invention relates in general the

electronic positives suitable for communicating via communication networks, a secure time synchronization protocol and a device and method for obtaining a secure time estimate.

Prior art

Figure 1 illustrates schematically a 100 system time synchronization. The system includes a synchronization server (TS) and ui n client device

synchronization (TC) that communicate across a network

Communication. The die device : nt of: synchronization TC is a network entity which wish to get a s y n c h r ο n i s a t i o n t e mp o r e 11 e s c u r i. e, for example, for synchronize your local clock 10 2 with a reference precise. To do this, it cont : act the server of

TS synchronization via the cornetwork

munication using a protocol synchronization e TIME SYNC, such as pr network time otocole

NTP: network time protocol).

This synchronization server T: 3 includes for example a synchronization source creates ise 104, such as a

micro-atomic oscillator or other means of maintaining a precise time reference.

004] The TC synchronization client device can

m a n d e r u n e s yn c h r ο n i s a t i οn t e mp o r e) The to the syn- server TS chronization during a phase of: ïn i t i a1i s a 11on s u i van t

a first activation of the synchronization client TC, this operation can be repeated at intervals

regular to ensure synchrony temporal ation between

B17674 the local clock 102 of the synchronization client TC and the precise synchronization source 104 of the synchronization server TS.

0005] Figure 1 illustrates the case of a single TC synchronization client device. However, the device

customer of TC synchronization and the server synchro- nization TS ! can be part from then has network relatively great in leguel lie of numerous devices

TC synchronization clients served by the TS synchronization server. For example, for applications such as the dissemination of certified legal time for business transactions, there may be many outlets requesting time synchronization. However, it has been observed that when a TS synchronization server has to provide services to many synchronization client devices, the capacities of the TS synchronization server can be overloaded and cause synchronization delays or even synchronization failures. Providing a system suitable for handling requests from numerous synchronization client devices in a network poses a technical problem.

Another technical problem of the system of FIG. 1 is that in order to authenticate the synchronization server, it is generally necessary to check the certificate of the server, including its period of validity. However, during the initial activation of the TC synchronization client device, this device may have no notion of time. This results in a Catch-22 situation in which the synchronization client device TC should have a prior notion of the time to validate the certificate of the synchronization server but where obtaining temporal information from the synchronization server.

B17674 TS synchronization requests prior validation of the certificate.

SUMMARY OF THE INVENTION An object of embodiments of the present description is to respond to one or more problems of the prior art.

According to one aspect, the present invention provides a synchronization client device comprising a network interface for communicating through a communication network, the synchronization client being configured so as to: receive, through the communication network, in coming from an authentication server, a first key and a first value containing the first key in encrypted form; producing a second value using the first key; and during a time synchronization phase, transmitting the first and second values to a synchronization server.

According to one embodiment, the synchronization client device is configured, during the time synchronization phase, so as to: transmit the first value to the synchronization server in a first message comprising a first timestamp; and transmit the second value to the synchronization server in a second message.

According to one embodiment, the second value is a message authentication code of the first message produced by means of the first key.

According to one embodiment, the first value also contains an indication of the encryption algorithm to be used to produce the second value.

B17674

According to one embodiment, the synchronization client device is also configured so as to transmit a request through the communication network to an authentication server to obtain the first key and the first value, this request containing an identifier of the synchronization client device, the identifier being for example an IP address (Internet Protocol: Internet protocol).

According to one embodiment, the synchronization client device is configured so as to further comprise in the request an identifier of the synchronization server, the identifier of the synchronization server being for example an IP address.

According to one embodiment, the first value is encrypted by means of a second unknown key of the device c 1 i e n t d e s y n c h r ο n i .s a t i ο n.

According to one embodiment, the synchronization client device is further configured so as to: receive from the synchronization server a third message containing one or more time stamps; receiving from the synchronization server a third value corresponding to: a first authentication code of at least part of the first message and / or at least part of the third message produced by means of the first key; or a digital signature of at least part of the first message and / or at least part of the third message produced from a private key; and authenticating the third message by checking the third value from the first key or a public key.

According to one embodiment, the synchronization client device is further configured so as to: produce a time estimate by asking a node

B17674 of a network of block chains of the headers of a series of blocks of a block chain, extract a timestamp from the header of a most recent block in the series; and producing the time estimate from the extracted timestamp; and validating an authentication certificate of the authentication server from the time estimate.

In another aspect, the present invention provides a time synchronization system comprising: an authentication server comprising a network interface for communicating through a communication network, the authentication server being configured so as to transmit to through the communication network to a first synchronization client device a first key and a first value containing the first key in encrypted form; and a synchronization server configured so as to receive from the first synchronization client device, during a time synchronization phase, the first value and a second value produced by means of the first key, the synchronization server being configured so as to authenticate the first synchronization client device from the second value.

According to one embodiment: the authentication server is also configured so as to transmit through the communication network to a second synchronization client device a third key and a third value containing the third key in encrypted form; and the synchronization server is also configured so as to receive from the second synchronization client device, during a time synchronization phase, the third value and a fourth value produced by means of the third key, the synchronization server being configured. of

B17674 so as to authenticate the second synchronization client device from the fourth value.

According to another aspect, the present invention provides a method for obtaining time synchronization by a synchronization client device comprising a network interface for communicating through a communication network, this method comprising: reception, at through the communication network from an authentication server, a first key and a first value containing the first key in encrypted form; the production, by the synchronization client device, of a second value by means of the first key; and during a time synchronization phase, the transmission by the synchronization client device of the first and second values to a synchronization server.

According to yet another aspect, the present invention provides a time synchronization method by a time synchronization system, this method comprising: the transmission, by an authentication server through a communication network to a client device synchronization, a first key and a first value containing the first key in encrypted form; during a time synchronization phase, the reception by a synchronization server from the synchronization client device of the first value and of a second value produced by means of the first key; and authentication, by the synchronization server, of the synchronization client device from the second value.

In another aspect, the present invention provides a method of producing a time estimate at

B17674 means of an electronic device comprising a network interface for communicating through a communication network, this method comprising: the request, by the electronic device to a node of a blockchain network, of headers of 'a series of blocks in a block chain; extracting a timestamp from the header of a most recent block in the series; and produce a time estimate from the extracted timestamp.

According to one embodiment, the method further comprises: requesting another node of the blockchain network from the headers of the series of blocks in the blockchain; and extracting another timestamp from the header of the most recent block in the series, wherein the production of the time estimate is further based on the other timestamp.

According to one embodiment, the block chain comprises a block chain going from an original block to an N-th block produced most recently, the header of the most recent block in the series being a (Nj) -th block of the block chain, j being between 6 and 15.

According to one embodiment, each block of the block chain, apart from the original block, comprises an imprint of a previous block of the chain.

According to one embodiment, the block chain is the block chain of a cryptocurrency.

In another aspect, the present invention provides a method of verifying an authentication certificate comprising: producing a time estimate according to the above method; and verification by the electronic device of the temporal validity of the certificate of authentication from the estimated temoorelle oroduite.

B17674

According to yet another aspect, the present invention provides an electronic device comprising a network interface for communicating through a communication network, the electronic device being configured so as to: request a node from a blockchain network headers of a series of blocks in a blockchain; extract a timestamp from the header of a most recent block in the series; and produce a time estimate from the extracted timestamp.

According to one embodiment, the electronic device is further configured so as to: ask another node of the blockchain network for headers of the series of blocks in the blockchain; and extracting another timestamp from the header of the most recent block in the series, in which the production of the time estimate is additionally performed from the other timestamp.

According to one embodiment, the block chain comprises a block chain going from an original block to an N-th block produced most recently, the header of the most recent block in the series being a (N- j) -th block of the block chain, j being between 6 and 15.

According to one embodiment, the electronic device is also configured so as to check the time validity of an authentication certificate from the time estimate produced.

Brief description of the drawings These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures, among which:

B17674 [Fig. 1] the figure s thematically a s y s t. th [Fig. 2] the figure s y s t è m e des y n c h r ο n i s a t i ο n realization of this

L (described above) illustrates time synchronization;

schematically illustrates a temporal according to an example of invention;

[Fig. 3] Figure 3 shows communications between network entities in the system of Figure 2 according to an exemplary embodiment of the present invention;

[Fig. 4] FIG. 4 schematically illustrates a system for the secure production of a time estimate according to an exemplary embodiment of the present invention;

[Fig. 5] FIG. 5 represents a block chain according to an exemplary embodiment of the present invention;

[Fig. 6] FIG. 6 is a flowchart representing operations of a method for the secure production of a time estimate according to an exemplary embodiment of the present invention; and [Fig. 38] 7] Figure 7 schematically illustrates a client synchronization device according to an exemplary embodiment of the present invention.

Description of the embodiments

The same elements have been designated by the same references in the different figures. In particular, the structural and / or functional elements common to the various embodiments may have the same references and may have identical structural, dimensional and material properties.

Unless otherwise indicated, the term connected is used to denote a direct electrical connection between circuit elements, while the term connected or coupled is used to denote an electrical connection.

B17674 between circuit elements which can be direct or can be carried out via one or more elements.

Unless otherwise specified, the expressions approximately, approximately, substantially and of the order of mean to within 10%, preferably to within 5%.

Figure 2 schematically illustrates a time synchronization system 200 according to an exemplary embodiment of the present invention.

The system 200 comprises client synchronization devices TCI and TC2 each comprising a local clock 102 similar to that of the client synchronization device TC of FIG. 1. In addition, each of the devices TCI, TC2 comprises for example an interface for network to communicate over a network with a TS synchronization server. This network is for example a packet switched network comprising for example one or more local networks (LAN), wireless local area networks (WLAN) and / or the Internet. Although the example illustrated includes two synchronization client devices, in practice, the synchronization server TS can serve many synchronization client devices, for example hundreds or even thousands of such devices. In an exemplary embodiment, the synchronization client devices TCI, TC2 are points of sale and the synchronization server TS disseminates certified legal time at the points of sale for commercial transactions.

The synchronization server TS is similar to the synchronization server of FIG. 1 and comprises a relatively precise synchronization source 104, which for example comprises an atomic micro-oscillator or other means for maintaining a time reference

B17674 specifies. In some embodiments, the synchronization source 104 is based on a rubidium oscillator or an OCXO (thermostatically controlled quartz oscillator), but other types of oscillator are possible.

The system

200 further comprises an authentication server AS, for example comprising a local orecise clock 202.

Each of the TCI and synchronization clients. TC2 can request a time synchronization from the TS synchronization server. For example, such requests may occur when the TCI or TC2 device is activated for the first time and / or at regular intervals during the life of the TCI and TC2 devices to maintain time synchronization. Indeed, the local clock 102 of each synchronization client device TCI, TC2 for example drifts to a certain extent over time, so that by resynchronizing with the synchronization server TS, the devices TCI and TC2 can maintain a relatively precise time, for example with an accuracy of a few milliseconds compared to the coordinated universal time.

To allow secure time synchronization between the synchronization client devices TCI and TC2 and the synchronization server TS, a configuration phase (CONFIG) is for example implemented by means of the authentication server AS. This implies for example communications between the authentication server AS and the synchronization server TS and between the authentication server AS and each synchronization client device TCI, TC2. We will now describe in more detail a method for implementing this configuration phase and a subsequent phase of

B17674 TIME SYNC with the TCI synchronization client device with reference to Figure 3. A similar method could be implemented for the TCz synchronization client device.

FIG. 3 represents the communications between the synchronization client device TCI, the authentication server AS and the synchronization server TS of FIG. 2 according to an exemplary embodiment of the present invention.

Before the start of communications between the parties, a setting operation (SETUP) takes place, for example, during which mutual authentication from certificates is implemented between the TCI synchronization client device and the authentication server. AS and between the synchronization server TS and the authentication server AS. This implies for example the establishment of a DTLS session (datagram transport layer security: security of the transport layer in datagram mode), in a manner known to those skilled in the art. The DTLS session creates secure channels which are used to exchange messages during the phase of configu0050] The configuration phase (CONFIG) between the synchronization server TS and the authentication server AS is for example implemented once or at relatively infrequent intervals, such as once a month to refresh the cryptographic materials used during time synchronization. During this phase, the synchronization server TS transmits, for example to the authentication server AS, the supported ALGO TS cryptographic algorithms, including, in certain embodiments, the authentication codes.

B17674 message cation (MAC: message authentication code) supported and / or digital signatures (DS: digital signature) supported.

The authentication server AS responds by producing and transmitting to the synchronization server TS a key S which is, for example, a long-term secret intended for use by the synchronization server TS. If a public key infrastructure (PKI) is to be used to sign messages to the synchronization client, the authentication server AS produces and transmits, for example also to the synchronization server TS, a private key / key pair public Ke / Kd. The same keys S, Ke and Kd are for example used for communications with each synchronization client device, so that the synchronization server TS does not need to store a different key to be used with each synchronization client device.

The configuration phase (CONFIG) between the synchronization client device TCI and the authentication server AS (and between the other synchronization client devices and the authentication server) is for example implemented after the phase of configuration with the TS synchronization server described above. The TCI synchronization client device 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 synchronization client device automatically contained in the transmitted message ; a TSID identifier of the synchronization server TS with which the synchronization client device TCI wishes to perform time synchronization; and cryp14 algorithms

B17674 ALGO TC tographics supported, including, in some embodiments, MAC codes supported and / or DS digital signature supported. In alternative embodiments, the timing TCI does not transmit synchronization server TS authentication server AS timing TS to the device TCI.

synpas client device the TSID identifier of the but, instead, the synchronization synclient server proposes it As will be described in more detail below, the synchronization server TS is for example configured to authenticate the time synchronization messages which it sends to the synchronization client TCI using either a MAC code produced using a symmetric key K or a digital signature DS produced using the private key Kd.

Assuming that at least one of the cryptographic algorithms supported by the synchronization server TS is also supported by the synchronization client device TCI, the authentication server AS responds for example by providing the client synchronization key the symmetric key K and, in some

some cases the access key public Ke O-U S Θ l V6Ul 0-0 S W chronization T S, as well as the OR the encrypted algorithm (s) tographic (s) negotiated ALOG__TC JT S compatible with

both with the TS synchronization server and the TCI synchronization client device and to be used for communications between them. To do this, the authentication server AS comprises for example a memory storing, for each synchronization client device and for each synchronization server TS in the case where there is more than one, the relations TSID- [S, (Ke, Kd)] and TCID- [K, C], in which the identifiers TSID and TCID

B17674 can correspond to IP addresses of the synchronization server and the synchronization client device respectively.

The authentication server AS provides for example to the synchronization client device TCI a state C, in the form of an encrypted value. In particular, state C corresponds for example to the symmetric key K and in certain embodiments, to one or more values, all encrypted by means of the key S of the synchronization server TS. The key K is for example unique for each synchronization client device and the use of state C allows for example the synchronization server to be stateless, that is to say that there There is no need to memorize the key K associated with each synchronization client device, as will be described in more detail below. The key S is for example unknown to the synchronization client device TCI, which therefore cannot decrypt or modify the state C. Only the synchronization server TS is for example suitable for decrypting the state C. The other values encrypted in state C can include a value indicating the negotiated algorithm (s) ALOG_TC_TS chosen to be used in communications between the synchronization client device TCI and the synchronization server TS.

For example, the algorithm negotiated for communications between the TCI synchronization client device and the TS synchronization server is the cryptographic primitive known as the AES-GCM (Advanced Encryption Standard - Galois / Counter Mode) algorithm. or a Feistel network.

B17674 The MAC algorithms supported by the synchronization server and / or by the synchronization client device

TCI certification includes ent for example the algorithm HMAC- SHA256 (Hash-based Messa .ge Authentication Code - Secure Hash Algorithm.) And / or The AES-CMAC algorithm (Advanced Encryption o La. N ci a rd. ui | oher-based Message Authentication Code) and / or the algorithm HMAC-MD5 (HMAC - Message Digest The digital signature: Which DS supported by

synchronization server and / or by the TCI synchronization client device includes for example the signature Ed25519, which is an EdDSA signature (Edwards-curve Digital

Signature Algorrtnm) utii isant SHA-512 and Curve25519, and / or. the MQQ-SIG signature (Ml 111. i v a r i a t Qu a d r a t i c Qu a s i g r o up s

Signature).

To initiate a time synchronization phase

(TIME SYNC), has it: Lf TCI synchronization client

for example transmits an ml message to the synchronization server TS. The message ml includes for example data

corresponding to the protocol The particular to use for the s y n c h r ο n i s a. t i o n. t e mp o r e 1) the. For example, in the case of.

NTP protocol, the message includes a time stamp Tl corresponding to the time stamp of the synchronization client device TCI at the time when the message ml is

produced and transmitted. In c in addition, the ml message includes example one. nonce n, as well . than state C. The nonce n is. by example a random value Say included in each message

and provides protection against replay attacks

For example, the server < synchronization TS understands this nonce n, or a MAC code oi j. a digital signature based on this nonce, in a message subsequent response (described more in detail below) i to the client device of

B17674 synchronization, which can then verify that the nonce n is

1st same.

The synchronization client device TCI for example also transmits to the synchronization server TS a second message m2 comprising a value τΐ corresponding for example to a value of MAC code MAC__K (ml) produced by means of the symmetric key K. For example , this MAC code value is a code produced from the first ml message already received by the synchronization server TS. Alternatively, it could be produced from part of the ml message only, for example, from state C or nonce n.

The ml and m2 messages are for example transmitted independently, so that the synchronization server TS can process the initial message ml as soon as it is received without first checking the MAC code. Thus, the quality of the time synchronization operation is improved. However, in alternative embodiments, the messages ml and m2 could be transmitted in a single message.

The synchronization server TS responds for example to the message ml by producing and transmitting to the synchronization client device TCI a message m3 containing the time stamp Tl as well as the time stamps T2 and T3 in accordance with the NTP protocol. For example, the time stamp T2 corresponds to the instant of receipt of the message ml by the synchronization server TS and the time stamping T3 corresponds to the instant of transmission of the message m3 to the synchronization client device TCI, [0063] The synchronization server TS also decrypts for example the encrypted value C from its secret key S and extracts from it the symmetric key K and, in certain modes

B17674 of realization, the algorithm negotiated ALGO TC TS. The synchronization server TS is then for example able to check the authentication code of MAC message MAC MAC K (ml) supplied in the message m2 using the symmetric key t r i that K.

The TS synchronization server also transmits, for example, a message m4 to the synchronization client device TCI after the message m3, the message m4 being used for authentication. For example, the message m4 comprises a value τ2 corresponding for example to a MAC MAC MAC code K (ml || m3) produced by means of the symmetric key K and from at least one of the messages ml and m3, and preferably from the two messages ml and m3. Alternatively, authentication could be carried out by a digital signature DS kd (ml || m3), corresponding to a signature of at least one of the messages ml and m3, and preferably from the two messages ml and m3. This digital signature is for example produced by means of the private key Kd of the synchronization server TS. In certain cases, the synchronization server TS is adapted to produce both the MAC code MAC_K (ml || m3) and the digital signature DS kd (ml || ni3) and a selection is made, for example by the client device TCI synchronization, between these two kinds of message authentication types depending on whether the non-repudiation property is desired or not.

In alternative embodiments, the MAC code and / or the digital signature could be produced from only part of the ml and m3 messages, for example from the nonce of the ml message only and / or T2 timestamps and T3 of the message m3 only.

B17674

The TCI synchronization client device is able to determine a relatively precise estimate of the terms by calculating the temporary transfer of its local clock 102 with respect to TS synchronization and the RTT return of the communications TCI and the server, for example determined; by [0 0 6 1] [Math 1] the clock 104 of the forward and ms propagation time server between the synchronization client TS synchronization, which are the following equations:

[Mat where. T4 is a time stamp corresponding to the time of reception of the message m3 by the synchronization client device TCI.

The device ^: TCI synchronization client is by configured example to set your clock from calculated values Offset and RTT. As will understand The skilled person. in some cases, the syn- timing is repeated several times and the setting clock is done from filtering and / or ana-

statistical lysis of the calculated set of offset and RTT values. In addition, in certain embodiments,

sation, the value of RTT is compared to a parameter of threshold Δ, and the disf positive TCI synchronization client is configured to rej discard message m.4 and / or have an abortion 1 a s y n c n r ο n x s a i x ο n . time if the RTT value exceeds

tee threshold parameter Δ, thus ensuring defense against attack by introducing a delay.

B17674 The TCI synchronization client device also authenticates, for example, the time information supplied by the synchronization server TS by checking the authentication code or the digital signature supplied with the message m.4. In the case where the message m4 includes the MAC MAC code K (ml || m3), the TCI synchronization client device checks, for example, this code using the symmetric key K, for example by recalculating the MAC code and comparing the MAC code recalculated with that provided with the message m4. In the case where the message m4 comprises the digital signature DS kd (ml || m3), the synchronization client device TCI verifies, for example, this signature by decrypting, the signature by means of its public key Ke.

As described above in relation to FIG. 3, the initial communications between the authentication server AS and the synchronization client device TCI and the synchronization server TS correspond to an adjustment phase during which mutual authentication is performed, for example from an exchange of certificates. However, the TCI synchronization client device can be a device that does not have a synchronous clock and therefore has no notion of the time when it is first powered up.

We will now describe a system and a method for obtaining a secure time estimate with reference to Figures 4 to 6. The electronic device could correspond to a synchronization client device TCI or TC2 of Figure 2 to certificate validation purposes or any electronic device wishing to obtain an estimate of the current time.

B17674

FIG. 4 schematically illustrates a system 400 for producing a time estimate according to an exemplary embodiment of the present invention.

In the system 400, an electronic device 402 wishes to obtain an estimate of the current time. For example, the device 402 is a device without user interface or provided with a user interface which does not allow the input of time information. In some embodiments, the device 402 is a portable electronic device suitable for wireless communications, such as a law device (Internet of Things).

According to the embodiments described here, the time estimate is obtained using a network of block chains 406. The network of block chains 406 comprises for example J nodes, each memorizing similar versions of the same chain of BC blocks. 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 block chain BC from a node 404 of a network of block chains 406.

The blockchain BC is for example an immutable public blockchain, such as the blockchain of a cryptocurrency such as Bitcoin or equivalent (the name Bitcoin is likely to correspond to a registered trademark). In a manner known to those skilled in the art, a network of block chains is by design a source of confidence, due to its particular structure.

A timestamp is for example obtained by the device 402 from one or more blocks of the block chain by peer-to-peer access. Peer-to-peer access to the Bitcoin blockchain is for example described

B17674 in more detail in the publication by S. Nakamoto entitled Bitcoin: A peer-to-peer Electronic Cash System, May 2011. In some embodiments, the device 402 requests the headers of a series of blocks in the chain of BC blocks and extracts a timestamp from one of these headers.

FIG. 5 represents the block chain BC of FIG. 4 according to an exemplary embodiment. The block chain BC comprises for example the blocks B0 to BN, the block B0 being an original block of the block chain BC and the block BN being the most recent block of the block chain BC. Each block includes for example a header (HEADER) containing an identifier (BLOCK 0 to BLOCK N) of the block, as well as a time stamp (TIMESTAMP). Each block also includes data which, in the case of the cryptocurrency block, corresponds for example to ledger data (LEDGER DATA). In addition, the original block B0 includes an imprint (HASH) of its own content and each other block also includes an imprint of the previous block (HASH (PREV)), making it difficult to modify the oldest blocks without approval. of the majority of the nodes in the blockchain network.

Figure 6 is a flowchart illustrating steps of a method for producing a time estimate according to an exemplary embodiment of the present invention.

It is assumed that the device 402 has for example identified the node 404 as a peer in the network of block chains 406 and knows the IP address of this peer.

For example, the device 402 has performed a peer discovery operation, using for example several DNS seeds or hard coded IP addresses.

In an operation 601, the electronic device 402 requests a series of au pair headers 404. A command

B17674

GetHeaders is used, for example. This command is for example in the form GetHeaders (X, L), X being the identifier of the last block requested and L being the number of headers requested. In the case of Bitcoin nodes, a maximum of 2,000 headers can be provided.

In some embodiments, a number of headers of the most recent blocks, which may remain subject to change and are not necessarily immutable, are excluded from the request. For example, the header of the most recent block requested is the header of the (Nj) -th block, the N-th block being the most recent block, and j being between 6 and 15, and in a example equal to 10.

The peer 404 takes for example the imprint of the (N-j) th block and responds to the device 402 with the requested series of chain headers after the block N-j. The device 402 then repeats, for example, the synchronization of the headers to reach the end of the block chain and identifies the header of the most recent block N-j in the series.

In an operation 602, the electronic device 402 extracts the time stamp from the header of the most recent block N-j. In some embodiments, 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 in the appropriate format.

As the arrow in dashed lines in FIG. 6 shows, operations 601 and 602 can be repeated for one or more nodes or peers in the block chain to ensure other verifications of the authenticity of the -heads and to provide protection against attack

B17674

M.T.TM (man-in-the-middle: by interposed host) and by identity theft. This implies for example to request the headers of the series of blocks from another peer, to identify the header of the most recent block of the series, which is for example again the header of ( Nj) -ème block, then extract the timestamp from this header. The new timestamp is for example compared to the timestamp previously extracted to verify that they are identical, thereby verifying the timestamp from two separate nodes.

In an operation 603, a current time is estimated from the timestamp (s) extracted (s) and a local clock 102 of the electronic device 402 is for example synchronized from the time estimate.

Since the timestamp on which we rely is not that of the most recent block in the blockchain, there may be a tempore.1 offset between the time of the extracted timestamp and the time real, which will depend on the value of j. The present inventors have however observed that it is generally possible to choose a value of j which provides a precise time to within a few hours, which is generally sufficient to validate an authentication certificate. Indeed, such certificates are generally valid until a certain date. The choice of the parameter j is based for example on the property of validity of the timestamp in the block chain.

In an operation 604, a certificate is for example validated from the time estimate. Thus, a revoked certificate can be identified and rejected by the device 402. As a variant, other uses of the temporal estimate produced could be made.

B17674 FIG. 7 schematically illustrates the TCI synchronization client device of FIG. 2 in more detail according to an exemplary embodiment.

The TCI device comprises for example a processor (P) '7 02 comprising one or more processor cores. The processor 702 is for example coupled to a local clock

(LOCAL CLOCK) 102, who understands by example a bone ; cillator 1 o c a 1, like a bone ; quar cillator tz or equivale ; nt, so that a < had several counters. The c TCI device understands

also for example a network interface (NETWORK INTERFACE) 704 and a memory (MEMORY) 706 coupled to the processor 702.

The memory 706 stores, for example, instructions which, when executed by the processor 702, cause the implementation of the operations of the synchronization client device TCI described above in relation to FIG. 3.

The synchronization client device TC2, the authentication server AS and the electronic device 402 in FIG. 4 are for example produced by circuits similar to that of FIG. 2. The synchronization server TS is also for example set implemented by a similar circuit, except that, instead of or in addition to the local clock 102, the synchronization server TS comprises the secure synchronization source 104. Furthermore, in the case of the device 402, its memory stores for example instructions which implement the method described above in relation to FIG. 6. With regard to the synchronization server TS and the authentication server AS, these devices also include memories storing instructions cul

B17674 implement the operations of these devices described above in relation to FIG. 3.

An advantage of the embodiments described in connection with FIGS. 2 and 3 is that the authentication server AS relieves the synchronization server TS of a significant amount of its load, in particular the negotiation of the algorithm and the key exchanges. This allows the synchronization server TS to handle time synchronization operations with a relatively large number of synchronization client devices and ensures relatively high availability of the synchronization server TS. Despite

Use of server authentic AS fication, the exchanges between 1 st î device customer of s y n c h r ο n i s a t i ο n e t the server of s yn chronisatic DR T S are secured by production and tr ciiiS1TL1 S S 10ii to the server synchronization

an authentication code by the synchronization client device from the symmetric key K provided by the authentication server AS. In addition, by allowing the TS synchronization server to be authenticated by means of a digital signature from asymmetric keys, non-repudiation can be supported, while time-critical operations continue to take place. press symmetric cryptography using the symmetric key K.

An advantage of the embodiments described in relation to FIGS. 4 to 6 is that it is possible to obtain a reliable time estimate in a simple and secure manner.

Various embodiments and variants have been described. Those skilled in the art will understand that it is possible to combine certain characteristics of these embodiments and other variants will appear to those skilled in the art.

B17674 art. It will appear in particular to those skilled in the art that although embodiments have been described in relation to the NTP protocol, the principles described here can be applied to any time synchronization protocol. In addition, although embodiments have been described in which one or more cryptographic algorithms to be used in communications between a synchronization client device and the synchronization server are negotiated, such negotiation can be omitted in alternative embodiments, if for example a single cryptographic algorithm is designated to be used by all synchronization client devices for each particular cryptographic operation (encryption, production of MAC code, production of DS signature).

In addition, although Figure 5 gives an example of a blockchain, the principles described here can be applied to a wide range of types of blockchains in which each block includes a time stamp.

It will also appear to those skilled in the art that it is possible to combine the embodiment of FIG. 2 with the embodiment of FIG. 4, the TCI synchronization client device being capable of obtaining a time estimate to validate an authentication certificate, for example in connection with a DTLS session, before the configuration phase by the authentication server AS.

Claims (10)

1. A method for producing a time estimate by means of an electronic device (402) comprising a network interface (704) for communicating through a communication network, this method comprising: - the request, by the electronic device (402) to a node (404) of a network of block chains (406), of headers of a series of blocks (B0 to BN) of a block chain ( BC); - extracting a timestamp from the header of a most recent block (B (N-j)) in the series; and - the production of a temporal estimate from the ex ro t age ho ro t. 2. Method according to claim 1, further consisting in: - request, from another nosud in the block chain network, headers from the block series (B0 to BN) of the chain d e b 1 o c s (B C); and - extract another timestamp from the header of the most recent block (B (N-j)) of the series requested at said other node, in which the production of the time estimate is also based on said other timestamp. 3. Method according to claim 1 or 2, in which the block chain comprises a block chain going from an original block (B0) to an N-th most recently produced block (BN), in which the header of the most recent block in the series is a (Nj) -th block of the block chain (BC), j being between 6 and 15. 4. Method according to claim 3, in which each block of the block chain, apart from the original block (B0), comprises an imprint of a previous block (HASH (PREV)) of the chain. B17674 5. Method according to any one of claims 1 to 4, wherein the block chain (BC) is the block chain of a cryptocurrency. 6. Method for verifying an authentication certificate comprising: - the production of a time estimate according to a method according to any one of claims 1 to 5; and - Verification, by the electronic device (402), of the time validity of the certificate of authentication from the time estimate produced. 7. Electronic device comprising a network interface (704) for communicating through a communication network, the electronic device being configured so as to: - asking a node (404) of a network of block chains (406) for headers of a series of blocks (B0 to BN) of a block chain (BC); - extract a timestamp from the header of a most recent block (B (N — j)) in the series; and produce a time estimate from the ex ro t age ho ro t. 8. Electronic device according to claim 7, further configured so as to: - request, from another node of the blockchain network, headers from the series of blocks (B0 to BN) from the blockchain (BC); and - extract another timestamp from the header of the most recent block in the series requested from said other node, in which the production of the time estimate is also based on said other timestamp. 9. Electronic device according to claim 7 or 8, wherein the block chain comprises a block chain B17674 ranging from an original block (B0) to an N-th most recently produced block (BN), in which the header of the most recent block in the series is an (Nj) -th block of the block chain (BC), j being between 6 and 15. 10. Electronic device according to any one of claims 7 to 9, further configured so as to verify the time validity of an authentication certificate from the time estimate produced.