ethereum / ethereum/keymanager-APIs
Reconsider allowing keystore export
- 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.