WARNING: This project is in active development. While we welcome users and feedback, please be warned that this project is a work in progress and users should proceed with caution.
Signatory is a remote signing daemon that allows people running Tezos bakers to securely sign endorsement and baking operations with a variety of different key management systems.
The goal of the Signatory service is to make key management as secure as possible in a Cloud and on premise HSM context.
Security and convenience are typically diametrically opposed. Signatory makes it easier for Tezos node operators to manage their keys in a secure way by offering several well-tested & supported signing options for cloud-based or hardware-based HSMs.
Coming soon
Signatory receives signing requests from either a baker or an endorser, signs the data using one of its backends, and returns a signature.
Signatory is also focused on observability, meaning that it exposes metrics about its operations. This allows operators to see historic trends, signing volumes, errors and latencies, enabling rich reporting and alerting capabilities.
Key import is an important security consideration when choosing a Cloud HSM offering. Some HSM's allow you to generate the secret key internally, and the secret key can never be exported. Others allow for key import with different levels of security. The trade-offs in this setting are important.
- Tezos will send a signing request to Signatory
- Signatory checks that the operation is either
block
orendorsement
- Signatory will send the operation to the configured backend for singing
- Upon receiving the signing operation from the backend, Signatory will validate the signature with a Tezos node (optional)
- Signatory returns the operation signature to the Tezos node
Signatory currently supports Azure Key Vault. Other backend signing services are either in the planning phase, or are currently being added.
The service will support a variety of backend Key Management Systems (KMS) for secure handling of private keys. Most cloud based KMS systems offer a HSM backed mode, which is strongly recommended.
By supporting multiple Cloud KMS/HSM systems, we hope to help the network from centralization on a particular Cloud offering. In the first year of the Tezos network operation, there was anecdotal evidence that a lot of bakers run on AWS. AWS is a superb provider, but having a concentration of nodes on one cloud vendor centralizes the underlying infrastructure of the network, which is not desirable.
Status | |
---|---|
Azure KMS | In Testing |
YubiHSM2 | In Testing |
Google Cloud KMS | Planned |
AWS KMS | Planned |
In Tezos, the signing algorithm can be inferred from the the first three
characters of an address. For example, an address beginning with tz3
uses the
P-256 algorithm. HSM's and Cloud based HSM's have support for a subset of the
three algorithms supported by Tezos.
tz1 | tz2 | tz3 | |
---|---|---|---|
Google Cloud KMS | ☒ | ☒ | ☑ |
AWS KMS | ☒ | ☑ | ☑ |
Azure KMS | ☒ | ☑ | ☑ |
YubiHSM2 | ☑ | ☑ | ☑ |
To report a security issue, please contact security@ecadlabs.com or via keybase/jevonearth on keybase.io.
Reports may be encrypted using keys published on keybase.io using keybase/jevonearth.
Please use the GitHub issue tracker to report bugs or request features.
To contribute, please check the issue tracker to see if an existing issue exists for your planned contribution. If there's no Issue, please create one first, and then submit a pull request with your contribution.
For a contribution to be merged, it must be well documented, come with unit tests, and integration tests where appropriate. Submitting a "work in progress" pull request is welcome!
At least three other remote signers are available to use with Tezos. Tezos also provides native support for baking with a Ledger Nano. We encourage bakers to, at a minimum, review these projects. We are eager to collaborate and be peers with these great projects.