Timejacking & Bitcoin

[EPiSKiNG]

Anyone seen this article?  http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

Curious to know what your thoughts are and what implications this has on the network...

-EP

[1714194273]

1714194273

[1714194273]

1714194273

[1714194273]

1714194273

[1714194273]

1714194273

[1714194273]

1714194273

[grondilu]

Anyone seen this article?  http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

Curious to know what your thoughts are and what implications this has on the network...

Too complicated for me but if I was to try to attack the bitcoin network, I would probably explore an idea like that.

The time adjustment algorithm might indeed be the most obvious possible weakness in the protocol.

[markm]

It seems to rely though on knowing exactly which machine you need to timejack in order to double-spend in a way that results in useable services or merchandise.

For example suppose I run a website that accepts Bitcoin payments in return for some promptly delivered readily-resellable product or service.

It knows the IP address and port of my, or my financial service provider's, bitcoind or of a tunnel to such a bitcoind.

The attacker tells my website it wants to buy, my website asks the remote bitcoind for an address for the transaction and tells it to the attacker.

What machine is the attacker going to try to timejack in order to fool my website into handing over its good or service?

-MarkM- (Could Ocean's Thirteen timejack all the major pools' pool-servers at once, maybe?)

[MoonShadow]

This is an elaborate version of a known attack vector, but one that is limited to a particular target, not the blockchain itself or the network as a whole.  Basicly, it's another way to perform a double spend fraud against a particular node.  There are many ways that a major vendor node could use to thwart this that are not mentioned by the article, probably due to lack of research on the author's part in this forum's thread history.  One defense is mentioned in the article, but he largely dismisses it's value. 

"Monitor network health and shutdown if there's suspicious activity.
Definitely a good thing, but wouldn't resolve conflicts automatically."

This is the 'blockchain watchdog' process mentioned in many prior threads.  It does not exist, but it could.  There are many signs that known attack vectors are underway.  No, this would not necessarily result in an automatic response, but it could notify the user that something is wrong as well as suspend transactions on an ecommerce site.

"Use the median block chain time exclusively when validating blocks."


This is a client issue, and one that can differ between client versions.  If a programmer wishes to come out with a version that does this, he is free to do so.

In short, this attack is possible, but very difficult even if the attacker is aware of any secret defenses the target may have already taken.  Nor is it a threat to bitcoin itself.
 

[FreeMoney]

I'm surprised there isn't something more damaging that can be done if you get enough nodes to change a majorities time. It seems like all he gets is a small chance to put a few false confirms on one or a few nodes.

[theymos]

I think it is a legitimate attack, though it's difficult to perform. The max time the network is allowed to adjust your clock should be reduced to 40 minutes.

[Mike Hearn]

The complicated time handling in Bitcoin has bothered me for a while. Good to see somebody really explore this in depth.

It's one place where Satoshi took a shortcut. Nodes could just use pool.ntp.org to find the current time. If an attacker is able to control that, it means they control your entire internet connection and thus can fork you onto a separate block chain anyway if you aren't paying attention.

And sure enough, the source code says this:

Code:

net.h:
    void PushVersion()
    {
        /// when NTP implemented, change to just nTime = GetAdjustedTime()

So clearly Satoshi intended to integrate NTP into the client at some point, he just never got around to it.

I'd rather we drop the median-time-of-peers technique. It leads to obscure and subtle attacks like this one. Theymos' suggestion is something that can be done easily for the next release, but integrating an NTP library would be the best long term approach because it's trivial to convince yourself the approach is correct.

[theymos]

With NTP we'd really need to reduce the max adjustment time, or else whoever controls pool.ntp.org could easily attack people.

Originally NTP was supposed to be used along with peer time. Maybe that would be better than relying only on NTP.

[Mike Hearn]

pool.ntp.org is itself a peer to peer network. It's no different from LFnet in that sense. The DNS name is just a rendezvous point.

At any rate, somebody (a government) trying to hijack the NTP pool just to screw with Bitcoin would be an incredible escalation. All kinds of things rely on that service to work properly. Breaking it would have tremendous collateral damage, there are far easier technical methods of hurting the Bitcoin network. I don't think "somebody hijacks the NTP pool" is a scenario worth worrying about.

[theymos]

It's still centralized. Someone controls pool.ntp.org.

[theymos]

NTP + median peer time + system clock seems like the perfect solution to me. If two or more sources are in agreement within 40 minutes, use the average of those times. If all three disagree, ask the user to fix it.

Edit: instead of using the average, you could get a more accurate time by using NTP if it agrees, or the system time otherwise.

[Mike Hearn]

Accurate timestamping is basically free. If somebody were to hijack pool.ntp.org (which will never happen), Bitcoin users could switch to some other NTP pool. Bear in mind these timestamp drift attacks are only useful if one node believes the current time is different to other nodes, so changing the time reported by the NTP pool wouldn't help you (it would be detected very quickly though).

Satoshi didn't use highly reliable distributed service here, and it backfired by opening up obscure attacks. Simplicity is good.

[kjj]

The huge majority of stratum 1 NTP nodes are getting their feed from GPS, so trust in NTP is essentially trust in the US Government.

[MoonShadow]

Different nodes could get their timing from different sources.  It's rational for an Android client to get it's timing directly from GPS whenever it can, and for servers to get their timing from ntp.  Different methods of achieving timing mean that it's pratically impossible for this kind of attack to work, because how it is achieved is dependent upon all the nodes involved in the attack using the same timing methodology.

[osmosis]

but integrating an NTP library would be the best long term approach

How about config options to set which ntp server to use,
or even a setting to turn off time syncs and use host time if you have a ntp service already running locally.

[2112]

The huge majority of stratum 1 NTP nodes are getting their feed from GPS, so trust in NTP is essentially trust in the US Government.

A huge majority of internet routers use NTP. A huge majority of the long distance synchronous optical links use GPS to synchronize clocks. To use the IP protocol is essentially to trust in the US Goverment.

Any sufficiently self-deluded internet cryptoanarchist is indistinguishable from a crackpot.

The un-deluded cryptoanarchist would probably research how to transmit bitcoin over shortwave radio. Or better yet, use VHF/UHF moon bounce (EME). It is the only way to be safe.

[kjj]

The huge majority of stratum 1 NTP nodes are getting their feed from GPS, so trust in NTP is essentially trust in the US Government.

A huge majority of internet routers use NTP. A huge majority of the long distance synchronous optical links use GPS to synchronize clocks. To use the IP protocol is essentially to trust in the US Goverment.

Any sufficiently self-deluded internet cryptoanarchist is indistinguishable from a crackpot.

The un-deluded cryptoanarchist would probably research how to transmit bitcoin over shortwave radio. Or better yet, use VHF/UHF moon bounce (EME). It is the only way to be safe.

IP has no concept of time, and routers only set their clocks so the logs are coherent when aggregated.

For what it is worth, I run NTP on everything that I possibly can, and I personally maintain two NTP nodes with GPS receivers.  But I am keenly aware that for 99% of users, NTP time is GPS time (central authority), and not necessarily UTC (distributed), even though they are in total agreement right now.

I also patch my clients not to accept time corrections from the bitcoin network and think that the clock skew acceptance built in to the bitcoin network is insane.  Or at least silly and out dated.

With regards to the suggestions of integrating NTP into the bitcoin client, I think it is a bad idea.  The bitcoin client is simply not an appropriate place to put timekeeping software.

If I were emperor, I would make the client turn red if it thinks the local clock is off by more than 5 seconds from what the peers report, and refuse to run if off by more than 30 seconds.

[bcforum]

With regards to the suggestions of integrating NTP into the bitcoin client, I think it is a bad idea.  The bitcoin client is simply not an appropriate place to put timekeeping software.

If I were emperor, I would make the client turn red if it thinks the local clock is off by more than 5 seconds from what the peers report, and refuse to run if off by more than 30 seconds.

Code:

Added time data, samples 405, offset +0 (+0 minutes)
-86493  -86018  -3606  -277  -168  -121  -100  -98  -87  -80  -79  -75  -74  -60  -56  -54  -53  -52  -36  -36  -36  -32  -31  -31  -30  -29  -27  -26  -26  -26  -24  -24  -23  -22  -19  -18  -18  -16  -16  -16  -15  -14  -14  -14  -14  -13  -13  -13  -12  -12  -11  -11  -11  -11  -11  -11  -10  -10  -10  -10  -9  -9  -9  -8  -8  -8  -8  -8  -8  -7  -7  -7  -7  -6  -6  -6  -6  -6  -6  -6  -6  -6  -6  -6  -6  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +2  +2  +2  +2  +2  +2  +2  +2  +2  +2  +2  +3  +3  +3  +3  +3  +3  +3  +3  +3  +4  +4  +4  +4  +4  +4  +4  +4  +4  +4  +5  +5  +5  +5  +5  +5  +5  +6  +6  +6  +7  +7  +7  +7  +7  +8  +8  +8  +9  +9  +9  +9  +9  +11  +11  +13  +14  +14  +15  +19  +20  +20  +22  +23  +26  +26  +37  +43  +44  +45  +50  +59  +85  +87  +93  +96  +124  +126  +169  +189  +284  +311  +3596  +3687  +7217  +83428  +5654326511063269263  +5790349588594885090  

Some of these systems need a color worse than red, but I think 5 seconds is too tight. 1 minute would throw a blanket of most of them, and a popup message to the rest pointing them to instruction on how to fix their clock would suffice for the rest.
It's interesting to note three are 1 hour, one is 2 hours, and three are ~24 hours off. I wonder if that is deliberate (run your computer in a different timezone so you now when to skype your grandkids), or a curious mistake.

[kjj]

With regards to the suggestions of integrating NTP into the bitcoin client, I think it is a bad idea.  The bitcoin client is simply not an appropriate place to put timekeeping software.

If I were emperor, I would make the client turn red if it thinks the local clock is off by more than 5 seconds from what the peers report, and refuse to run if off by more than 30 seconds.

Some of these systems need a color worse than red, but I think 5 seconds is too tight. 1 minute would throw a blanket of most of them, and a popup message to the rest pointing them to instruction on how to fix their clock would suffice for the rest.

In light of a global system capable of keeping every clock on or near the planet (maybe even in the entire solar system) synchronized to within a dozen milliseconds or so, I would say that a 5 second skew is evidence of a serious error.

It's interesting to note three are 1 hour, one is 2 hours, and three are ~24 hours off. I wonder if that is deliberate (run your computer in a different timezone so you now when to skype your grandkids), or a curious mistake.

Both.  Computers are capable of displaying the time as an arbitrary offset from the system time.  If the system time is wrong, that is a mistake, even if the reason it is wrong is because someone did it intentionally.

[osmosis]

Here is the time_sync doc for gtk-gnutella

https://github.com/gtk-gnutella/gtk-gnutella/blob/master/doc/gnutella/msg/time_sync

It has an option in the settings which allows a user to specify if their host is using NTP and to trust the system time.  For systems that havent taken the time to configure ntp, the default behavior is to perform time synchronization with the network. This is the best of both worlds. Disciplined admins can make sure their clock is not pulled off by an attacker, while other hosts that are possibly misconfigured would default to syncing with the network. With many hosts using NTP, the rest of the networks time should drift closer and closer to the correct time.

This of course would not protect a host not using NTP from having a time attack done on it individually. But individual hosts are not protected from DDoS attacks or most of types of flood or packet attacks either.