Time jacking exploits a theoretical vulnerability in Bitcoin timestamp handling. During a time-jacking attack, a hacker alters the network time counter of a node on the blockchain network and forces the node to accept an alternative network.
This can be achieved when a malicious user adds multiple fake peers to the network with inaccurate timestamps. However, a time jacking attack can be prevented by restricting acceptance time ranges or using the node’s system time.
How does a Time-jacking Attack work?
In a time-jacking attack, the hacker 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 provoke a fork. The entire network then uses a blockchain built for the “poisoned,” and the victim considers the alternative chain with a token reuse (or double-spending) valid, in which the “poisoned” block does not appear.
The attack is carried out in two stages; Fork and isolate and Double-spend.
1. Fork & Isolate
The attacker needs to generate a new block, 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.
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, the “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.
This results in the victim being isolated from the main network and considers the main blockchain, 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.
At this stage, the attacker starts generating an alternative chain, in which he adds a transaction that transfers tokens to the victim’s wallet. Blocks of an alternative chain are sent to the victim.
The victim accepts this chain since the value of the timestamps is chosen by the intruder from his or 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. 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. After performing all of these tasks, the attacker is deemed successful in his or her illicit act.
There are ways to mitigate or prevent time-jacking attacks from happening. Here are some preventive measures to keep in mind.
- Use the node’s system time: Using the node’s system time, rather than network time, for block timestamps is advisable. Relying on hardware time sources would need extra calibration and maintenance. Even a slight discrepancy among nodes (as they adjust their clocks) could enable an attacker to disrupt the network or isolate a node.
- Strengthen acceptable time ranges: The node’s network time could be restricted to a value within 30 minutes. This changes the maximum initial attack window to between 30 and 60 minutes instead of 70 and 140, but would not prevent splits entirely. Nodes with incorrect daylight savings handling might be left behind, though.
- More confirmations: It’s advisable to demand more confirmations for transactions, striking a balance between speed and security against potential reversals. However, even with increased confirmations, a substantial financial attack could succeed if other miners manipulate timestamps or if the target system is offline.
- Only trusted peers: Requiring secure nodes to rely solely on trusted peers can weaken security, as a few trusted peers might be compromised. A fully decentralized system doesn’t rely on a select group of peers. Mandating operators to manage their own networks or distribute servers geographically adds maintenance and synchronization challenges. Trusting peers or a distributed network alone doesn’t solve the global time agreement issue.
- Median Blockchain Time Validation: Validate blocks and transactions exclusively using the median blockchain time, eliminating the possibility of timestamp splits. This ensures consensus as all peers rely on the chain’s embedded timestamps, removing disagreements based on variable clocks.
- Delayed Timestamp Validation: Delayed validation involves retaining blocks with excessive timestamps for later re-checking, reducing timestamp inflation risk. Nodes rejoin the main chain once their system clocks catch up, minimizing synchronization delay compared to solely relying on system time. However, it’s more complex and may still allow timestamp-based splits.
While this attack only affects the Bitcoin chain, we should not disregard the fact that attackers continue to develop methods to intrude on other chains and perform their illicit intentions or acts. A time-jacking attack is more rigorous and time-consuming to perform, so once someone tries to pull off an attack, security can easily identify it, considering the drastic improvements of blockchain over the years.