signatory

module
v1.1.7 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jan 26, 2024 License: Apache-2.0

README

Signatory Logo

A Tezos Remote Signer

CII Best Practices GitHub Actions Maintainability Test Coverage Go Report Card

What is Signatory?

Signatory is a remote signing daemon that allows Tezos bakers and Tezos Application teams to protect their private keys.

The goal of the Signatory service is to make key management as secure as possible in a Cloud and on-premise HSM context.

Why Use Signatory?

Security and convenience are typically at odds with each other. Signatory makes it easier for Tezos teams to manage their keys securely by offering several well-tested & supported signing options for cloud-based or hardware-based HSMs.

Quick Start

See docs


Features

Remote Signing

Signatory receives requests to sign Tezos operations. These operations may be consensus operations when used in a Baking context, or they may be transactions or any other Tezos operation type.

Signatory will inspect the operations and assert that the operation request is in line with Signatory's policy. If the operation passes the policy rules, Signatory will then have a signature produced using the appropriate backend system.

Signatory operators can choose from AWS, Azure or Google Cloud KMS systems, or self-hosted solutions such as the YubiHSM2, Hashicorp Vault or Ledger Hardware wallet.

Observability

Signatory is also focused on observability, exposing metrics about its performance, volume and possible errors. Metrics allow operators to see historical trends, signing volumes, errors and latencies, enabling rich reporting and alerting capabilities.

Private-Key Import

Private-key import is an important security consideration when choosing a Cloud KMS offering. Some KMS's allow you to generate the secret key internally so that no one can extract the private key from the HSM. Others allow for private-key import with different levels of security. The trade-offs in this context are essential to understand.


How it Works

  • A Tezos operation is sent to the Signatory API
  • Signatory decodes and checks that the operation is permitted based on the defined policy
  • Signatory sends the operation to the configured vault backend for signing
  • Upon receiving the signature produced by backend, Signatory validates the signature
  • Signatory returns the signature to Signatory client

Why

Our goal in supporting multiple Cloud KMS/HSM services is to help prevent centralization on the network or infrastructure level. A goal of Tezos is to have a highly decentralized network of bakers. That goal is not fully realized if, of those bakers, a large majority operate on a single infrastructure provider.

In the first year of the Tezos network operation, there was anecdotal evidence that many bakers ran 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. By supporting multiple Cloud KMS/HSM systems, we hope to prevent the network from centralization on a particular Cloud offering.

Supported Signing Backends

Backend KMS/HSM Support Status

Status
YubiHSM2
Azure KMS
Google Cloud KMS
AWS KMS
Ledger Nano S/S+ (Baking only)
Hashicorp Vault

Tezos Address Types

In Tezos, you can infer the signing algorithm from the first three characters of an address. For example, an address beginning with tz3 uses the P-256 algorithm. HSMs and Cloud-based HSMs have support for a subset of the three algorithms supported by Tezos.

Signing Algorithm Support From Various Backends

tz1 tz2 tz3
Hashicorp Vault
Google Cloud KMS
AWS KMS
Azure KMS
YubiHSM2

Reporting Issues

Security Issues

To report a security issue, please contact security@ecadlabs.com

Other Issues & Feature Requests

Please use the GitHub issue tracker to report bugs or request features.

Contributions

To contribute, please check the issue tracker to see if an 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 is required to have complete documentation and come with unit tests and integration tests where appropriate. Submitting a "work in progress" pull request is welcome!


Alternative Remote Signers

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.

Disclaimer

THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Directories

Path Synopsis
cmd
pkg
hashmap
Package hashmap implements a generic wrapper around a built in map type which allows interface types like PublicKeyHash to be used as map keys
Package hashmap implements a generic wrapper around a built in map type which allows interface types like PublicKeyHash to be used as map keys
vault/memory
Package memory provides a basis for file based and in-memory vaults
Package memory provides a basis for file based and in-memory vaults

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL