Introduction: Time Server Attacks and Mitigations in ETH2
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)here, author: dankrad, translation: A Jian, reproduced by Odaily with authorization.
Abstract: Time server attacks in Eth2 have also been discussed before. But so far, the mainstream opinion is that this kind of attack can only take the validator temporarily offline, and wait for the node operator to re-establish the correct time synchronization measures, and the node can come back online. However, if nodes can be tricked into signing an attestation for an epoch in the distant future, the danger goes beyond simply being temporarily offline: because of the consensus algorithm's wrap-around vote slashing rules, these nodes will not be available until the entire network actually arrives at that epoch. No more attestation messages can be signed until the target epoch of the wrongly sent attestation message (otherwise a slash will be triggered)
here
). Under the operation of consensus rules, this kind of time server attack will cause the attacked verifier to go offline almost forever, and the relevant stakeholders will also pay a heavy price due to inactivity leak.
attack surface
We can concoct a time server attack as follows: the first step is to jump to a certain time in the future by manipulating the time of the time server, so that the time of the attacked verifier also jumps to the future (for example, 15 to 20 days), this time must be shorter than the time when the laziness penalty causes the validator's balance to drop to zero, otherwise the validator will not sign the attestation message again.
result
We then need to trick the relevant node into thinking it is actually in sync with the chain, and then it will sign the attestation. This is always possible if an attacker controls multiple peers, just by sending some attestations and blocks from a future time in a peer-to-peer network channel. Controlling multiple nodes is also easily achievable, so this is not an unrealistic attacker assumption.
Once a target validator has signed an attestation message targeting a future epoch, the attacker can save the message and make sure that the validator cannot sign any more attestations until the entire network actually arrives at that future epoch. message (otherwise the attacker could send this message, causing it to be slashed). All validator clients currently implemented in Eth2 have measures to prevent the validator from signing conflicting attestations, so the validator is effectively offline.
result
An attacker can use a time server (or similar facility, such as roughtime) to evict all validators that the TA can influence. Such an attack would be worse than an attack [2] previously conceived using the same interface, since the effects are not temporary but much more persistent. While it is possible that we could detect such an attack within minutes, and all professional nodes could recover normal time within a few hours, this does not help because the damage has already been done - and can lead to validators , for example, there may be many validators who will be withdrawn from the network due to exponentially increasing laziness penalties.
Mitigation
Add validator client non-slashing rules
We can add a non-slashing rule to validator clients: requiring them to evaluate the current time before signing all messages, and not to pre-sign future messages. This method is actually only useful when the validator client and the beacon chain node are not deployed on the same machine and are not affected by the attack. However, it is a definite improvement for key-splitting validators, because this rule will not allow the leader to propose a future attestation message, which can block the validator's actions.
Add more protections for time synchronization measures
