ethereum / ethereum/keymanager-APIs

Reconsider allowing keystore export

Open
#75 4 comments 1 reaction 0 assignees View on GitHub
Dominant language
HTML
Stars
43
Forks
25
Avg merge
21h 47m
Merged PRs (30d)
4

Description

Currently the key manager API intentionally provides no way to extract keystores. This decision was made for security, as exfiltrating keystores via an API is potentially dangerous.

However, this functionality is also _very useful_, and when guarded by appropriate safeguards (authentication, HTTPS, private networking), it can be safe. Further, the greatest risk from keystore theft is _not_ theft of funds, but slashing. Given the difficulty of stealing 1/3+ of signing keys to make slashing impactful and worthwhile for the attacker, I believe this makes signing keys relatively less appealing to hackers than other keys like wallets & withdrawal keys. And this is the absolute worst worst worst case scenario if a VC API is compromised.

In Lighthouse we have extended the `DELETE` API with non-standard fields in order to support moving keys. The CLI frontend which uses this non-standard API to relocate validators atomically has proved popular with our devops engineers and with users. See: https://lighthouse-book.sigmaprime.io/validator-manager-move.html

The fields added to the `DELETE` response in Lighthouse are:

- `validating_keystore`: a string of the JSON keystore in its entirety
- `validating_keystore_password`: the password for decrypting `validating_keystore`

Presently these fields are only added if the user runs the VC with the flag `--http-allow-keystore-export`. If we standardise this, we could require _all_ implementations to disable keystore export by default, and only turn it on when a flag is supplied. This should reduce the likelihood of an accident.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.