Security

To protect Ankr validators' private keys, Ankr has teamed up with Cubist — a Polychain-backed company that specializes in high-security Web3 development and deployment tools. Cubist's team includes leading experts in cryptography and computer security and drives an HSM approach to managing private keys.

Problem

The problem we had to tackle is the one of losing money due to validator's private key exposure. If the key is compromised, there is a significant risk of double-signing and subsequent slashing. Even if you quickly exit (unstake funds from) the validator, exiting process takes several days, and you'll have to wait several weeks for the activation of a new validator — you lose a lot of rewards which translates into a noticeable loss of money.

Solution

We improve our security system and keep validators' keys in HSM.

These measures shield us from popular attacks such as the one where attacker steals the key and demands ransom otherwise creating double-sign events that lead to the validator's slashing and loss of money.

How do our security system and HSM protect us?

While HSM keeps our keys safe, we run various security checks before sending a signing request to it. For signing requests, we use short-lived and long-lived tokens that we issue through hardware tokens.

1. Short-lived tokens are used to authenticate signing requests from validators when they validate and publish blocks to the network. An attacker stealing a short-lived token will not be able to produce a double-sign event — our security system will run a double-sign check, reject attacker's request, and inform us. We will quickly issue a new token.
2. Long-lived tokens are used to authenticate signing request when unstaking (withdrawing) from our validators. These tokens, whitelisting the IP of our server, restricting the unstake amount, and other measures protect us from any attacker meddling with the unstakes. What's more, Ethereum doesn't allow withdrawing to a custom address, only to one pre-programmed at the validator.

Mechanics of remote signing

The mechanics are very straightforward:

1. Our server calculates what needs to be signed.
2. Our system runs multiple security checks, incl. the double-sign one.
3. If the checks pass, we send a signing request to HSM; and if they fail, we immediately take action about any detected malicious activities.

Additional details

HSM is protected from physical damage by being replicated in multiple geo-locations. In case of an unlikely emergency event where all the replicas are damaged, we can apply the majority of our hardware tokens to decrypt an HSM backup.

In case our users make a very big unstake, we can temporarily adjust the security policy concerning the unstaking amount by using our hardware keys.

Official news and more information

Official announcement (opens in a new tab) on Ankr Blog.
Also, read "Securing staking keys properly (opens in a new tab)".