Not Your Keys, Not Your Coins
Are two keys better than one?
Welcome to the new Bearmint Investigation Series. As we near the public release, this extensive series will dive into the brand new ARK framework and consensus called Bearmint while breaking it down as simply as we can.
In our last episode, we covered the need for a new Framework and a basic overview of past dev work that led to the creation of Bearmint, in this episode we’ll cover a short technical topic regarding ARK delegates/validators and basic safety practices.
While this is a little more technical than previous posts, we still feel that everyone should be aware of this, especially delegates. We will also be referring to delegates as validators for the rest of this article.
Your passphrase is your key
This topic should be quite clear for most cryptocurrency users that have held or used any form of crypto. Passphrases, some refer to these as keys or recovery keys. In ARK, we have always referred to these as passphrases. Even bitcoin uses passphrases, either 12 or 24 words that represent your cryptocurrency address. This is also referenced in a very common saying, “not your keys, not your coins”. So of course, always keep these to yourself and never share them with anyone.
For validators, this is a major security issue. Currently, the process is to create a new address and then issue a registration transaction(with the validators name) from that newly created address. This ties the new validators name to that new address until a resignation transaction is issued, essentially tying that name to the address forever unless revoked.
Once the validator server/node is built and synced with the network, the validator would input the passphrase for that associated address into the node itself. This allows the node to talk to the network and for the network to see that it is ready, associated with a valid address, registered appropriately and available to begin forging and securing the network by processing blocks and transactions.
The security issue here is that, the validators passphrase is used for forging, but also used for everyday sending of transactions. Similar to when you need to send a transaction yourself, you need to input your passphrase. This is fine for the everyday user, but for a validator that is securing a network, this may pose a risk. Though unlikely if the delegate is experienced and uses proper security practices, it is still a possible vulnerability if a malicious actor was to gain access to the validators node.
A malicious actor could then use that node to harm the entire network and also drain any funds associated with that single key. This possible attack vector can be mitigated slightly with an additional step, as long as it’s paired with proper security practices.
Say goodbye to single keys
With Bearmint, validators will have two key pairs. One key strictly for forging/validating blocks and one key strictly for transactions. Two separate keys, each of which has a single purpose and cannot perform the same actions as the other one. This may sound complicated but, lets break down the need and simplicity of this new security feature.
Having two key pairs has extreme security benefits:
If a validator’s forging key pair is compromised, their funds remain safe. The forging key pair is unable to authorize on-chain tasks such as sending a transaction and is therefore useless beyond forging blocks.
If your second (transaction) key pair is compromised, your validator remains intact. This key pair is unable to forge blocks, it is only for sending transactions and therefore cannot cause any kind of harm to the network.
Either of these key pairs can be compromised, but as long as you have access to both of them, you will be able to resign your validator, effectively shutting it down and rendering any further abuse or malicious behavior impossible.
If for any reason one key is compromised, it is possible to put an end to any attack and shut it down before any further harm can be done. With the upcoming finality upgrade to consensus, paired with this double key pair design, the ARK network becomes even more secure.
Current network validators wont need to change much more than they are already used to. They will just need to store two keys and take note which key pertains to which task. One key for forging and one key for authorizing transactions.
This is one simple and secure practice that can save a validator from an attack and protect the network as a whole. It’s one extra step in a validators setup process, but well worth the small effort in the long run.
This is episode 3 of our extensive blog overview, with many more to come. Stay tuned for more from this series as we get closer to the Bearmint public testing release. Be sure to subscribe to our blog and follow us on social media to stay up to date, and don’t forget to jump into the conversation on the ARK Community Discord as well.
If you enjoy our content, please consider voting for our validator, more information can be found here https://strake.foundation/delegate/.