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 entiretyvalidating_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.
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
DELETEAPI 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.htmlThe fields added to the
DELETEresponse in Lighthouse are:validating_keystore: a string of the JSON keystore in its entiretyvalidating_keystore_password: the password for decryptingvalidating_keystorePresently 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.