EOS out-of-band block signer server
A simple and secure OOB block signing server for EOS.IO Software blockchains, from your friends at EOS Canada.
Slightly before EOS.IO 1.0 release, Block.one introduced Out-of-band signing for block producers. It involves setting up your configuration with something like this:
signature-provider=EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV=KEOSD:http://localhost:6666/v1/wallet/sign_digest keosd-provider-timeout=20 # default value is 5 ms
This means that
nodeos can sign blocks with the private key
EOS6MR...W5CV through an external
eos-blocksigner is such a program, and integrates with
eosc's vault, the
wallet and command-line tool.
WARNING: you do NOT want to expose that software to any public
endpoint, even in an internal network. It should run and listen
strictly on a loopback interface. The
sign_digest endpoint can
actually sign anything with the associated private key. If you are
using the same private key for
active permissions on
some accounts (which you should not), then any transaction can be
signed with the
Two modes of operation
As of May 2018,
eos-blocksigner has two modes of operation:
- using a vault encrypted through Google Cloud Platform's Key Management System
- using a plain-text private keys file
As demand grows, we can add more strategies, like AWS's KMS system, passphrase-encrypted vaults, or some other HSM systems.
GCP KMS integration
To use the KMS-GCP strategy, create a vault locally using
eosc this way:
$ eosc vault create --import \ --vault-type kms-gcp \ --comment "Block signing key vault" \ --kms-gcp-keypath projects/PROJNAME/locations/LOC/keyRings/RINGNAME/cryptoKeys/KEYNAME ...
This implies you have authenticated through
gcloud and have
permissions to Encrypt using KMS, in the specified project and
You can then drop the
eosc-vault.json wallet on your production
infrastructure, and run
eos-blocksigner with these parameters:
$ eos-blocksigner --wallet-path path/to/eosc-vault.json \ --kms-gcp-keypath projects/PROJNAME/locations/LOC/keyRings/RINGNAME/cryptoKeys/KEYNAME Listening on 127.0.0.1:6666
You will need the Decrypt KMS scopes on your servers to handle decryption of the vault.
Plain-text private keys file
This is a method which is not very secure, yet is still more secure
than keeping your private keys in plain-text in your
Remote code execution vulnerabilities often allow reading the process'
memory easily. Having the out-of-band (read: separate process) signing
server already makes it more complex to access memory with your
private keys. With proper isolation (containers, network access, and
eos-blocksigner), you can mitigate the risk of leaking your private
keys through an unforeseen
--keys-file is a simple file that looks like this (
5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFFF 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3 // This matches EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
It has one private key per line. Anything after an optional whitespace is ignored.
With a keys-file, you don't need an
eosc-vault.json, and can run:
$ eos-blocksigner --keys-file=myfile.keys Listening on 127.0.0.1:6666