Digital Signature Creation and Verification
Ty Everett (ty@projectbabbage.com)
Abstract
We define a mechanism for requesting and receiving digital signatures over the abstract communications channel first described by BRC-1. We rely on the BRC-43 invoice numbering and permission scheme on top of BRC-42 for key derivation, enabling the creation of private digital signatures that can only be verified by the counterparty. A signer derives their own child private key and uses it to compute an ECDSA signature, which is then communicated to the verified, together with the signer's identity key, the message, and the protocol ID and key ID used. The verifier uses this information to derive the corresponding child public key for the signer, which is then checked against the signature and message with ECDSA. Without the BRC-42 shared secret, no third parties can discover the correct child public key, making then unable to validate the signature.
Motivation
The increasing use of Bitcoin wallets has highlighted the need for a secure and interoperable digital signature standard that can be used across different applications. Digital signatures provide a vital aspect of data authentication, allowing for the verification of information and secure transactions, and are critical to ensuring the integrity of the Bitcoin network.
While other solutions have proposed digital signatures within a wallet, none of them have provided a unified and open standard that supports both privately and publicly verifiable signatures, while also incorporating proper BRC-42 key derivation. The lack of such a standard has created a fragmentation within the ecosystem, with each application requiring its own solution, thus hindering interoperability and leading to duplicated effort.
To address this issue, the BRC-3 standard has been created to enable the creation and verification of digital signatures using BRC-43 invoice numbering and permission scheme on top of BRC-42 for key derivation. This allows for the creation of private digital signatures that can only be verified by the intended counterparty, while maintaining security against third-party tampering.
The BRC-3 standard not only provides a secure and interoperable solution for wallet implementations, but it also enables new use cases and experiences that were previously not possible. With a unified standard, different wallets can create and verify each other's digital signatures seamlessly, reducing friction and enabling greater innovation.
Specification
We start with the same constructs defined in BRC-43: users with clients, protocols and applications. We stipulate the use of BRC-43 invoice numbers in the context of BRC-42 key derivation, and we build on top of the permissions architecture defined by BRC-43.
When an application sends a message to a client requesting that data be signed, the message comprises:
The data to sign
We stipulate the following process for digital signature creation:
The message signer begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID
The message signer uses BRC-42 key derivation with the computed invoice number to derive their own child private key
The message signer computes the digital signature using ECDSA with their derived child private key (this specification is silent about ECDSA k-value utilization)
We stipulate the following process for message verification:
The verifier somehow comes to know the signature, the counterparty (signer), the security level, protocol ID, and key ID. The mechanism for conveying this information to the verifier is beyond the scope of this specification.
The verifier begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID
The verifier uses BRC-42 key derivation with the computed invoice number, their own private key and the public key of the sender, to compute the signer's child public key
The verifier uses ECDSA to verify the signature against the message using the signer's child public key
We build upon the abstract messaging layer first described in BRC-1. Specifically, we define five new BRC-1 messages to facilitate requests and responses for signatures and verification operations, and error handling. For each of the messages, we stipulate that there exists some out-of-band mechanism for the parties to communicate which of the messages are being exchanged, removing the need for a message type field. Finally, specifically for the request messages, we stipulate that the message comprises a header and a payload, with the payload containing the data (ciphertext or plaintext), and the header containing the other information. For the response messages, no message header is defined and the payload simply contains the specified data.
Signature Creation Request
The signature creation request is a message sent by the BRC-43 application to the client. It contains a header with the following information:
The message payload comprises the data to sign.
Signature Creation Response
The response message comprises the ECDSA digital signature in DER format.
Signature Verification Request
The signature verification request is a message sent by the application to the client. It contains a header with the following information:
protocolID
The BRC-43 security level and protocol ID represented as an array. For example, [0, "hello world"] represents a level-0 protocol with open permissions, while [2, "document signing"] represents a level 2 protocol.
keyID
The BRC-43 key ID
counterparty
The BRC-43 counterparty, self or anyone
signature
The DER-formatted signature for verification
The message payload comprises the data to verify.
Signature Verification Response
The response message comprises a JSON payload containing the following fields:
result
The value is true if the signature is valid, otherwise it is false.
Signature Error
If the client is unable to fulfill the signature creation or verification requests for any reason, we specify that it should respond with a JSON-formatted Signature Error. The fields for the object are specified as follows:
status
This should always be a string comprising "error".
code
A machine-readable error code. Extensions to this standard can define specific error codes and standardize additional fields. Codes are strings, for example "ERR_VERIFICATION_FAILED".
description
All errors must have a human-readable description field that describes the error. This allows the application to represent the error for the user.
One example of a Signature Error is given below:
Test Vectors
For compatibility with this signature scheme, we stipulate the following:
Any user who knows the following identity private key (counterparty=anyone)...
...should be able to use security level 2, the BRC3 Test protocolID with keyID 42 and the following counterparty (signer)...
...to verify the message with the following digital signature (DER format)...
The message that was signed is:
Implementations
This digital signature capability is incorporated into the Babbage SDK
Last updated