Time checking: Timejacking vs Bitcoin



    In the competition for the most popular word of the year, the word "blockchain" would probably have become the prize-winner of the IT sphere. Despite the fact that there is an unhealthy tendency to actively introduce it anywhere - in medicine, the economy, the Internet of things, breeding rabbits and the production of cakes, the main use of the blockchain is still cryptocurrency. And everyone knows: virtual wallets for hackers are like cat cream.

    In this article, we will look at the Timejacking attack, based on the vulnerability in the processing of timestamps of blocks in the Bitcoin cryptocurrency system, and try to explain why there is an attack, but there is no successful implementation.

    PS There will be many derivatives from the word "time". Lots of.

    In a nutshell


    For the first time, Alex Bowerman wrote about the Timejacking attack. Its publication can be found here . What is the essence: the attack exploits the vulnerabilities of the mechanism for checking the timestamps of blocks and the time counter in Bitcoin. The attacker manipulates one of the timers of the victim node and creates a “poisoned” block. The victim will reject this block, and the rest of the network will successfully accept, and please - we have a fork provoked! The entire network uses a block chain built for the "poisoned", and the victim considers the alternative chain with a token reuse (aka double-spending) valid, in which the "poisoned" block does not appear.

    The attack is carried out in two stages. To make it clearer, let's talk about each of them separately.

    Act 1. Creating a fork and isolating the victim


    The attacker needs to generate an "apple of discord" - the same "poisoned" block that the victim ignores. In the same way, the victim will reject other blocks that will be added sequentially after the "poisoned" one.

    How to deceive the victim and force to drop the correct block?

    In the header of each block there is a timestamp that the node checks during verification. This value should fall within a certain range, we will call it a time window. The time window range is shown in the figure below:


    The time window has two borders:

    • the lower one is t min , it is equal to the median of timestamps of 11 blocks preceding the block being verified
    • top - equal to the network time t 0 + 2 hours

    The timestamp value of the block is not verified relative to the system time of the node, but relative to the median time of its neighbors — network time (aka network-adjusted time).

    How is network time counted:

    • When a new connection is established, the nodes exchange their system time.
    • Each node calculates the deviation of its own system time from the system time of each of its neighbors.
    • For the calculated deviations, the median value is selected.
    • Own system time + median deviation = network time

    Here is an example of calculating network time:


    Thus, an attacker can manipulate the time value of the victim’s network by connecting to it a sufficient number of neighbors announcing a lagging system time. The time value of the victim's network decreases; the upper limit of the range of valid values ​​of the timestamp of the verified block decreases. But if the deviation of the neighbor's time exceeds 70 minutes , then its time will not be taken into account when calculating the network time. Therefore, the maximum value by which the time of the victim’s network can be reduced is 70 minutes.


    Accordingly, our “poisoned” block is a block whose timestamp must fall into the time window of all network nodes, except the victim. Only then the whole network will successfully accept it, and the victim, whose network time has been modified, will be no less successful. The figure below shows the victim’s time window vs the remaining nodes time window.


    Note that, thanks to the NTP protocol, we can assume that most nodes have approximately the same system time, that is, the network time of each node is close in value to their system time.

    As a result, the victim is isolated from the main network and considers the main block chain, which will be built by the remaining nodes from the “poisoned” block, incorrect. In this case, the other blocks, helpfully generated by the attacker for an alternative chain, the victim will confidently accept.


    Act 2. Double-spending


    At this stage, the attacker generates an alternative chain, into which he adds a transaction that transfers tokens to the victim's wallet. Blocks of an alternative chain are sent to the victim. The figure below shows the range of values ​​of the time stamp of the “poisoned” block.


    The victim will accept this chain, since the value of the timestamps is chosen by the intruder from her own time window, and the remaining nodes will be rightfully ignored - after all, they are already building their chain from a “poisoned” block that is longer than the alternative one. As a result, the victim believes that he received tokens, and sends the goods. And the main network is sure that the tokens did not leave the intruder’s wallet, and he gets the goods for “thank you” - because the majority cannot be mistaken. Finale, the hero of the dark side triumphant!

    But not so simple


    Pitfall number 1:

    Huge computational power is now involved in Bitcoin mining. The probability of successful generation of the "poisoned" block can be estimated by the following formula:


    Today, the total Bitcoin network hashrate is approximately equal to H = 34 ∙ 10 18 hash / s. In this case, using the most productive device from this list , the declared hashrate of which is h = 18 10 12 hash / s, the probability to generate a “poisoned” block in 1 year (t = 365 ∙ 24 ∙ 60) is approximately 3%. And if we take from this statistics a relatively small mining pool, which has 0.3% of the total hashrate, then the probability of successful generation of a block within 3 days is 73%.

    Pitfall number 2

    With the passage of time of the victim's network, the timestamp of the “poisoned” block will finally fall into the victim's time window. Then the victim will replace the alternative chain with the main one, since the whole network works on it and its height will be greater. The "poisoned" block will fall into the victim's time window in no more than 70 minutes - this is the maximum time in which the second stage must be completed.

    In order for the victim to accept the double-spending transaction, the block with it must be confirmed by another 6 blocks (for a standard client). The violator will have to generate the confirming blocks independently, and at the same time it is necessary to meet the above 70 minutes. Bowerman examinesa situation where an attacker owns 10% of the power of the entire network. In such a situation, it will take ~ 5.5 hours to generate 6 blocks with a 10% success rate. For 3.3 hours, the success rate drops to 1%, for 140 minutes - 0.147%. According to these estimates, successfully generating 6 blocks in 70 minutes is from the realm of fantasy.

    Pitfall number 3

    When a node calculates network time, it takes into account the system time of only the first 200 neighbors — then the median deviation will not be recalculated. This means that the attack must be implemented until the number of neighbors already connected to the victim does not exceed 99 - otherwise the time announced by the attacker will not be median. This number of neighbors will come back in about 24 hours, and after that the victim will have to be rebooted - for example, using DoS.

    the end


    In conclusion, we can say that the “Timejacking” attack is very good, but in the harsh realities Bitcoin becomes inapplicable. What about other systems using the blockchain? Leave this question for your further research!

    Also popular now: