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.
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.
We improve our security system and keep validators' keys in HSM.
HSM is a hardware security module with a dedicated crypto processor that is specifically designed to protect crypto key's lifecycle.
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.
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.
- 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.
- 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.
The mechanics are very straightforward:
- Our server calculates what needs to be signed.
- Our system runs multiple security checks, incl. the double-sign one.
- If the checks pass, we send a signing request to HSM; and if they fail, we immediately take action about any detected malicious activities.
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 announcement (opens in a new tab) on Ankr Blog.
Also, read "Securing staking keys properly (opens in a new tab)".