1

I run LEMP stack on Ubuntu 18.04. I need to sign / verify transactions for Ethereum real-time. Where can I store the private key for it? Is storing it in .env good enough? It just seems super dangerous but I can't think of a way of me losing that key. But I am not a security specialist, so want to make sure and use the best practice.

Anders
  • 64,406
  • 24
  • 178
  • 215
evening
  • 461
  • 1
  • 6
  • 15

4 Answers4

1

Check out the HSM products of Nitrokey and Yubikey. They are explicitly produced for this kind of use-case, where you need to sign with a key, while keeping it on-device.

sbstrkt
  • 21
  • 3
  • Can you explain why specifically these manufacturers and not others? We aim to avoid promoting specific vendors. –  Nov 26 '20 at 19:14
  • 1
    Every one of your posts mentions Nitrokey. Do you work for them? – schroeder Nov 26 '20 at 21:26
  • 1
    I have been testing the Nitrokey devices, and have been active on their support forum. However, (fair disclosure) I am not employed by Nitrokey. I am familiar with the stack, that is why I am replying to the questions related to the topic. – sbstrkt Nov 30 '20 at 14:45
1

Consider a Hardware Security Module

A Hardware Security Module (HSM) is a piece of hardware designed for safe storage of cryptographic material. For your use-case, it allows you to generate the private key directly on the HSM, store it on the HSM and use it to perform any cryptographic functions. This allows you to offload all cryptographic operations onto the HSM and only receive the result of the operation (e.g. the signed data).

The private key is never visible to you an in most cases cannot even be extracted by you. As such, even if an attacker would compromise the server, they cannot directly steal the private key.

0

You have two main aspects to take care of: you need to keep the key a secret while actively using it, and you need to keep a backup for when (not if) the media the key is stored on breaks.

A HSM can perform cryptographic operations for anyone presenting the correct PIN without disclosing the key, so that allows you to keep the key itself secure -- but what you actually want to protect against is generation of signatures under spending transactions you didn't authorize, so it's not a full solution. Holding the private key to an empty wallet isn't worth much.

The HSM concept is basically sound: you have a separate trustworthy computer that has a primitive auditable and defensible interface. Typically, this is implemented as a smartcard: a hardened computer with protection against leaving permissible power supply and clock ranges and ionizing radiation that exposes only a single serial port to the outside, with well-defined message framing.

This will allow you to keep the key secret, however smartcards are designed to destroy themselves in preference to divulging secrets, so if losing the key is disastrous rather than inconvenient, you definitely want a backup that can be regularly tested whether it would work for restoration, but not in a way that would potentially expose the key.

My own backups are on paper, encrypted with a password and then extended with per-line checksums (IHEX) that allows me to type them in by hand if needed and be alerted of typos right away. As long as I can read that paper, I can be reasonably sure that I can restore the key material, and I'm not dependent on any media that might fail in a way that I could not repair.

For the best security in a server-based application, I would probably add another device that gives me a secondary communications channel to verify transactions before they are signed, or I'd have the server create batches of transactions that I download, verify and sign locally. The attack scenario I'm thinking about here is generating a transaction that transfers all of your tokens out of the wallet and have that transaction signed by the HSM. Since the HSM does not understand the contents of the message, it has no reason not to.

Simon Richter
  • 1,482
  • 11
  • 8
-1

Put it on a USB (or more reliable media) and lock it in a safe.

It's not just security you should be considering, it's the safety of the key too. Don't store any information on your PC which you wouldn't mind losing one day when the SSD fails

Daniel
  • 3
  • 1
  • 2
    This is for a server. –  Nov 25 '20 at 15:06
  • Same deal - if it's something important like a private key, I wouldn't be dismissing the idea of a backup. Servers are usually more reliable than consumer storage but that doesn't mean it won't fail. – Daniel Nov 25 '20 at 15:12
  • 1
    @Daniel I must store the private key on the server directly (I have a backup as well) because I need to sign transactions real-time. And my question is how to store it on the server (Ubuntu 18.04, running LEMP stack) in the most secure way. At the moment it is just in .env in `/var/www` folder running Docker. – evening Nov 25 '20 at 15:13
  • Hmm ok fair point then. Purely from a sensibility standpoint in that case, .env doesn't seem like a terrible place to have it. – Daniel Nov 25 '20 at 15:14
  • @Daniel That's what I'm doing atm. Feeling slightly uneasy so I've been thinking if there are any better solutions. – evening Nov 25 '20 at 15:15
  • I can't name any product solution here due to the policies. But a quick Google search for: "A system for distributing and managing secrets" or "Centralized key vault" could help you out. – Jeroen Nov 25 '20 at 15:19