This EIP defines a HTTP API standard for a BLS remote signer, consumed by validator clients to sign block proposals and attestations in the context of Ethereum 2.0 (eth2).
A validator client contributes to the consensus of the Eth2 blockchain by signing proposals and attestations of blocks, using a BLS private key which must be available to this client at all times.
The BLS remote signer API is designed to be consumed by validator clients, looking for a more secure avenue to store their BLS12-381 private key(s), enabling them to run in more permissive and scalable environments.
Eth2 utilizes BLS12-381 signatures.
Consensus on the eth2 Blockchain is achieved via the proposal and attestation of blocks from validator clients, using a BLS private key (signing key) which must be available each time a message is signed: that is, at least once every epoch (6.4 minutes), during a small window of time within this epoch (a slot, i.e. 12 seconds), as each validator is expected to attest exactly once per epoch.
The eth2 specification does not explicitly provide a directive on where this BLS private key must/should be stored, leaving this implementation detail to the client teams, who assume that this cryptographic secret is stored on the same host as the validator client.
This assumption is sufficient in the use case where the validator client is running in a physically secure network (i.e. nobody, but the operator, has a chance to log-in into the machine hosting the validator client), as such configuration would only allow outbound calls from the validator client. In this situation, only a physical security breach, or a Remote Code Execution (RCE) vulnerability can allow an attacker to either have arbitrary access to the storage or to the memory of the device.
There are, however, use cases where it is required by the operator to run a validator client node in less constrained security environments, as the ones given by a cloud provider. Notwithstanding any security expectation, nothing prevents a rogue operator from gaining arbitrary access to the assets running inside a node.
The situation is not better when the requirement is to execute the validators by leveraging a container orchestration solution (e.g. Kubernetes). The handling of secret keys across nodes can become a burden both from an operational as well as a security perspective.
The proposed solution comprises running a specialized node with exclusive access to the secret keys, listening to a simple API (defined in the Specification section), and returning the requested signatures. Operators working under this schema must utilize clients with the adequate feature supporting the consumption of this API.
The focus of this specification is the supply of BLS signatures on demand. The aspects of authentication, key management (creation, update, and deletion), and transport encryption are discussed in the Rationale section of this document. Moreover, the Threat Model section of this document provides a (non-exhaustive) list of threats and attack vectors, along with the suggested related mitigation strategy.
GET /upcheckResponses
| Success | |
|---|---|
| Code | 200 |
| Content | {"status": "OK"} |
GET /keysReturns the identifiers of the keys available to the signer.
Responses
| Success | |
|---|---|
| Code | 200 |
| Content | {"keys": "[identifier]"} |
POST /sign/:identifier| URL Parameter | |
|---|---|
:identifier | public_key_hex_string_without_0x |
Request
| JSON Body | ||
|---|---|---|
bls_domain | Required | The BLS Signature domain. As defined in the specification, in lowercase, omitting the domain prefix.Supporting beacon_proposer, beacon_attester, and randao. |
data | Required | The data to be signed. As defined in the specifications for block, attestation, and epoch. |
fork | Required | A Fork object containing previous and current versions.As defined in the specification |
genesis_validators_root | Required | A Hash256 for domain separation and chain versioning. |
| Optional | Any other field will be ignored by the signer |
Responses
| Success | |
|---|---|
| Code | 200 |
| Content | {"signature": "<signature_hex_string>"} |
Where signature is a BLS signature byte array encoded as a hexadecimal string.
or
| Error | |
|---|---|
| Code | 400 |
| Content | {"error": "<Bad Request Error Message>"} |
or
| Error | |
|---|---|
| Code | 404 |
| Content | {"error": "Key not found: <identifier>"} |
This API specification contains only three methods: one for status, one for listing the available keys, and one to produce a signature. There are no methods for authentication, key management, nor transport encryption.
The following subsections discuss aspects to be considered by the client implementers relative to these subjects.
From an API pipeline view, we have two nodes: The validator client (1) that makes requests to the remote signer (2). A more sophisticated chain can be built by introducing elements between these two nodes. Either by setting up reverse proxy services, or by adding plugins to the remote signer implementation.
Can be accomplished through the use of an HTTP Request Header. There are several ways to negotiate and issue a valid token to authenticate the communication between the validator client and the remote signer, each of them with potential drawbacks (e.g replay attacks, challenges in distributing the token to the validator client, etc.). In general, any method of authentication must be combined with transport encryption to be effective.
The operator can also implement network Access Control Lists (ACLs) between the validator client's network and the remote signer's network, reducing the attack surface by requiring a potential attacker to be positioned in the same network as the validator client.
There are several ways to store secret keys, namely Hardware Security Modules (HSM), Secrets management applications (e.g. Hashicorp Vault), cloud storage with tight private network ACL rules, or even raw files in a directory. In general the remote signer implementers will abstract the storage medium from the HTTP API.
It is in this perspective, that any procedure to create, update, or delete keys should be built separate from the client implementation.
If the operator is working with self-signed certificates, it is required that the client enhancement consuming the remote signer allows this option.
0xb7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a.0x68081afeb7ad3e8d469f87010804c3e8d53ef77d393059a55132637206cc59ec.0xb6bb8f3765f93f4f1e7c7348479289c9261399a3c6906685e320071a1a13955c.0xb5d0c01cef3b028e2c5f357c2d4b886f8e374d09dd660cd7dd14680d4f956778808b4d3b2ab743e890fc1a77ae62c3c90d613561b23c6adaeb5b0e288832304fddc08c7415080be73e556e8862a1b4d0f6aa8084e34a901544d5bb6aeed3a612.GET /upcheckGET /keysPOST /sign/:identifier| Repository Url | Language | Organization | Commentary |
|---|---|---|---|
| BLS Remote Signer | Rust | Sigma Prime | Supports proposed specification. |
| Web3signer | Java | PegaSys | Supports proposed specification, although with slightly different methods: { /sign => /api/v1/eth2/sign, /publicKeys => /api/v1/eth2/publicKeys}. |
| Remote Signing Wallet | Golang | Prysmatics Labs | Supports both gRPC and JSON over HTTP. |
Let's consider the following threats and their mitigations:
| Threat | Mitigation(s) |
|---|---|
| An attacker can spoof the validator client. | See the discussion at Authentication. |
| An attacker can send a crafted message to the signer, leading to a slashing offense. | It is the responsibility of the operator of the remote signer to add a validation module, as discussed at Implementation of additional features. |
| An attacker can create, update, or delete secret keys. | Keys are not to be writable via any interface of the remote signer. |
| An attacker can repudiate a sent message. | Implement logging in the signer. Enhance it by sending logs to a syslog box. |
| An attacker can disclose the contents of a private key by retrieving the key from storage. | Storage in Hardware security module (HSM). or Storage in Secrets management applications (e.g. Hashicorp Vault). |
| An attacker can eavesdrop on the uploading of a secret key. | Upload the keys using a secure channel, based on each storage specification. |
| An attacker can eavesdrop on the retrieval of a key from the remote signer. | Always pass the data between storage and remote signer node using a secure channel. |
| An attacker can dump the memory in the remote signer to disclose a secret key. | Prevent physical access to the node running the remote signer. or Prevent access to the terminal of the node running the remote signer: Logs being sent to a syslog box. Deployments triggered by a simple, non-parameterized API. or Implement zeroization of the secret key at memory. or Explore the compilation and running of the remote signer in a Trusted execution environment (TEE). |
| An attacker can DoS the remote signer. | Implement IP filtering. or Implement Rate limiting. |
Copyright and related rights waived via CC0.