Guide to Securing an Ethereum 2.0 Validator Wallet From Getting Slashed Due to Theft (Ubuntu/ Linux)

Image provided by: @executium

This is a step-by-step guide to securing a validator wallet (that is used for staking on the Ethereum 2.0 mainnet) from getting slashed in the event that the PC containing it, is stolen.

Acknowledgments

Special thanks to u/IBhagwan and Nishant for their time. You two essentially pushed me in the right direction, which in turn helped me to come up with the solution presented here. In addition, this whole topic was originally inspired by htimsk (whose material is also referenced here); so thank you all!

Disclaimer

This article (the guide) is for informational purposes only and does not constitute professional advice. The author does not guarantee the accuracy of the information in this article and the author is not responsible for any damages or losses incurred by following this article. A full disclaimer can be found at the bottom of this page — please read before continuing.

Prerequisites

This guide assumes knowledge of Ethereum, ETH, staking, and Linux.

This guide also requires the following before getting started:

• Ubuntu server v20.04 (LTS) amd64 or newer, installed and running on a local computer. Though in theory, this method should work on any Linux distribution.
• A running Ethereum 2.0 setup. There are plenty of resources online if you need help to set one up. That said, the two most helpful, in my opinion, are Somer Esat’s and CoinCashew’s. *I used Somer’s guide.
• An Apricorn Aegis Secure Key 3 NXC. A 256-Bit Hardware-Encrypted USB 3.2 Type-C Flash Drive that we’ll use to secure your validator wallet. The same company also makes a USB 3.2 Type-A Flash Drive called the Apricorn Aegis Secure Key 3 NX. You can use either one depending on your setup (though if you’d like to keep it unlocked while the computer is shutdown, I suggest going with the USB 3.2 Type-C version since not all PCs come with powered USB Type-A ports. *The products mentioned are using affiliate links.

Overview

If you followed any of the guides mentioned above or most of those found online, you should by now have an Ethereum 2.0 staking setup that is reasonably secured from online threats. But have you thought about what would happen if the PC containing your staking setup was physically stolen? Well, if you’ve properly secured your PC, then there isn’t much the thief can do to hurt you further (they’ve already stolen a valuable piece of hardware, and that may just be it). That said, the thief’s next step will most likely be to try and start the PC, only to find out that it is password protected/ encrypted, etc., at which point they will logically resort to either replacing the hard drive completely or formating the existing one. Both of which would be great news for you. However, if the perpetrator decides to keep the now stolen PC AS-IS, online and running, you could be at risk of getting slashed. Why is that? Because if you run a new setup (using the same validator keys/ wallet) while your now stolen setup is still active (assuming you’ve had it all configured to start on reboot), you are essentially committing a slashable offense. At that point, your validator will be forced to exit the network causing you to lose on any future staking rewards, which would result in an even greater loss to you!

So… what we’re going to do now, is make it so that if your PC is unplugged or the USB Secure Key is disconnected, it will then also disable your wallet’s password from being accessed by the validator, which in turn will disable your machine from being able to become active again. Do keep in mind that the Secure Key will be configured to remain unlocked when connected to your machine during normal operations, reboots, and powered shutdowns. When combined with a UPS that will issue commanded shutdowns upon a mains power failure, it will also remain unlocked so long as standby power is provided to your machine by that very same UPS. If that sounds like a plan, then let’s go ahead and start!

Don’t worry, if you unplug your own PC (or disconnect the USB key itself),- the Aegis Secure Key can be unlocked using an 8 digit keycode of your choosing.

Keep in mind that for powered shutdowns, you will need to disable “ErP” (found in your machine’s BIOS) so as to make sure that the USB key remains powered if the PC is simply turned off but still plugged into your mains. If “ErP” is enabled, the key will lock when the system is shutdown.

Step 1 — Configure the Secure Key

1. Setup an Admin password on the Secure Key following the First-Time Use instruction found in the Aegis User Manual on page 5.
2. Enable Lock-Override Mode (see page 19 of the manual). This enables the key to remain unlocked during reboots and powered shutdowns.
3. Set the number of brute-force attempts to 6 by following the Brute-Force Protection instruction on page 14. Set the number of before/after attempts to 3 as this is consistent with a Ledger-like hardware wallet.
4. Unlock the Aegis Key by entering the Admin PIN and plug it into your PC within 30 seconds.

Step 2 — Format the Secure Key

1. If you’re using Ubuntu Desktop simply go to the “Disks” app. If you’d rather use CLI (command-line interface), skip to line item #4.
2. Select the “Apricorn Secure Key 3.0” drive, then click on the “Gears” icon i.e. “Additional Partition Options”.
3. Select “Format Partition”. Give it a name, and select to “Erase” by using the available toggle switch. Then set “Type” to: “Internal Disk for Use with Linux Systems Only (Ext4)”. Proceed to format. You’re now done. Please proceed to Step 3.
4. If you’re using Ubuntu Server or rather use the command-line interface, you should first find the device name:

sudo fdisk -l

The disk model will be titled Secure Key 3.0. Note the Device name assigned to the drive. In the example below, it is /dev/sda1

Image provided from htimsk’s GitHub

5. Choose the GPT partitioning standard:

sudo parted /dev/sda mklabel gpt

6. Once the format is selected, you can create a partition spanning the entire drive by typing:

sudo parted -a opt /dev/sda mkpart primary ext4 0% 100%

7. Now that we have a partition available, we can format it as an Ext4 filesystem. To do this, pass the partition to the mkfs.ext4 utility:

sudo mkfs.ext4 /dev/sda1

Note: Make sure you pass in the partition and not the entire disk. In Linux, disks have names like sda, sdb, hda, etc. The partitions on these disks have a number appended to the end. So we would want to use something like sda1 and not sda.

Step 3 — Mount the Secure Key + Set Access Permissions

1. You should make sure that the Secure Key is accessible by “Others” i.e. other users (as your Validator is most likely set up under a “Validator User”). If you’re using Ubuntu Desktop, you can do that by simply right-clicking the Secure Key via the “Files” app, then go to “Permissions” and make sure that “Others” can “Access Files” on the Secure Key. If you’d rather use CLI (command-line interface), skip to line item #5.
2. Now we’ll need to mount the Secure Key. To do so, simply go to the “Disks” app.
3. Select the “Apricorn Secure Key 3.0” drive, then click on the “Gears” icon i.e. “Additional Partition Options”.
4. Select “Edit Mount Options”. Toggle off the “User Session Defaults” and make sure that under “Mount Options” you selected “Mount at System Startup” and “Show In User Interface”. Then edit the “Mount Point” field to wherever your current validator’s Password.txt file is currently saved. In my case, I’ve used Somer’s guide and the Prysm client so I have it set to (/var/lib/CLIENT/validator/KEY_FOLDER_NAME_OF_YOUR_CHOICE)

/var/lib/prysm/validator/key 

Leave the rest as is, and confirm by clicking the ‘OK’ button at the bottom. You’re now done. Please proceed to Step 4.

5. If you’re using Ubuntu Server or rather use the command-line interface, you should create a /key subdirectory under wherever your current validator’s Password.txt file is currently saved. In my case, I’ve used Somer’s guide and the Prysm client so that directory is: /var/lib/prysm/validator

sudo mkdir /var/lib/prysm/validator/key

6. Edit the /etc/fstab file (sudo nano /etc/fstab) to mount the filesystem automatically each time the server boots by adding the following to the bottom of the /etc/fstab file and save.

/dev/sda1 /var/lib/prysm/validator/key ext4 defaults 0 2

7. Mount the filesystem now by typing:

sudo mount -a

8. Use the following in order to keep your read/write permission to the Secure Key while allowing “Others” i.e. other users, to read it:

sudo chmod 644 /var/lib/prysm/validator/key

Step 4 — Move Password.txt to the Secure Key + Create a Symbolic Link

1. This would be a lot easier by simply using CLI, so let’s go ahead and do that. First, stop the validator client service. If you’ve used Somer’s guide, this command should work AS-IS. Otherwise please adjust the service’s name accordingly.

sudo systemctl stop prysmvalidator

2. Move the validator Password.txt file from its current location to the Secure Key drive. In the example code below, I’m once again assuming Prysm is the validator client used, but the same applies to all other clients; especially if you’ve used Somer’s guide.

sudo mv /var/lib/prysm/validator/password.txt /var/lib/prysm/validator/key/password.txt

3. Now we’ll be creating a Symbolic Link so that our current setup still thinks to look for the Password.txt file in its original location.

sudo ln -s /var/lib/prysm/validator/key/password.txt /var/lib/prysm/validator/password.txt

4. Start the validator client service. You’re now done!

sudo systemctl start prysmvalidator

Step 5 — Test Your Setup

1. Make sure that your setup works as it should by first disconnecting the Secure Key (it will be the same as if the PC was unplugged), followed by stopping the Validator service, then starting it once again and checking its status. It should show you that the validator is no longer active but instead simply attempting to load (and failing). That is expected since it can no longer activate without the password.txt file.

sudo systemctl stop prysmvalidator
sudo systemctl start prysmvalidator
sudo systemctl status prysmvalidator

2. Now plug the Secure Key back. Stop the validator, and then start it once again. Now check the status. It should be back to active.

sudo systemctl stop prysmvalidator
sudo systemctl start prysmvalidator
sudo systemctl status prysmvalidator

3. You can now test and see that your setup starts as it normally would if you simply reboot your PC.

4. Finally, you can also test and see what happens if the PC was unplugged, then plugged back in, and started up again (such as what would actually happen if a thief was to steal it from you and set it up at their own place), and see that the validator indeed does not initiate.

That’s it! I hope my guide helped with this niche yet plausible scenario. Hopefully, you’re feeling more confident about the security of your precious validator machine.

Full Disclaimer

This article (the guide) is for informational purposes only and does not constitute professional advice. The author does not warrant or guarantee the accuracy, integrity, quality, completeness, currency, or validity of any information in this article. All information herein is provided “as is” without warranty of any kind and is subject to change at any time without notice. The author disclaims all express, implied, and statutory warranties of any kind, including warranties as to the accuracy, timeliness, completeness, or fitness of the information in this article for any particular purpose. The author is not responsible for any direct, indirect, incidental, consequential, or any other damages arising out of or in connection with the use of this article or in reliance on the information available in this article. This includes any personal injury, business interruption, loss of use, lost data, lost profits, or any other pecuniary loss, whether in an action of contract, negligence, or other misuse, even if the author has been informed of the possibility.