0043.md

BRC-43: Security Levels, Protocol IDs, Key IDs and Counterparties

Ty Everett ([email protected])

Abstract

We propose a standard format for invoice numbers that enables secure and permissioned access to a set of restricted key derivation universes within the context of BRC-42 derivation. The format defines a string that includes the security level, protocol ID, and key ID separated by hyphens. Security level 0 implies no permissions, level 1 grants permissions to all key IDs and all counterparties for the given protocol ID, and level 2 grants permissions only to a particular counterparty. The standard aims to enable the creation of protocols that can request permission to access data controlled by a user in a secure and standardized way.

Motivation

The BRC-42 key derivation architecture allows parties to derive child keys for each other based on flexible invoice numbering schemes. However, the lack of a standard format for invoice numbers creates challenges for using different sets of keys for different purposes. This standard proposes a solution to address these challenges by defining a common standard for formatting invoice numbers.

By enabling the development of various classes of protocols, each with different security models, this standard allows for the sharing of a common set of root keys while keeping key universes separate. This approach provides an easy-to-use solution for various applications, including Bitcoin and MetaNet client software, where different applications require access to various classes of a user's data.

The proposed scheme for key IDs is open-ended and can be defined by the rules for each protocol, making it easy to implement and apply to a wide range of use cases. This standard makes it easier for software using BRC-42 key derivation for cryptographic operations to protect user data by granting permission for particular parties to access and use keys based on the security level for the protocol. Overall, the adoption of this standard will simplify and enhance the use of BRC-42 key derivation in a variety of contexts, improving security and facilitating innovation.

Specification

We specify that an invoice number has the following three components:

Component	Description
Security Level	Denotes the level of permissioning security applied to protocols using the scheme.
Protocol ID	The identifier for the protocol that is using the scheme.
Key ID	Protocol-specific information used to arrive at a particular key under a particular protocol.

We specify the following format for invoice numbers:

<securityLevel>-<protocolID>-<keyID>

We specify that there are users who have clients, there are applications and there are protocols. Protocols define a key derivation scheme that facilitates access by applications to user-held keys via their client. For example, an application could use a particular protocol to encrypt some data with the user's client. The keys used for encryption under one protocol are different than the keys used for other protocols, because the invoice number used for key derivation contains the specific protocol ID being used.

We specify the counterparty as the other party whose key is being used for derivation. When there is only one party, we specify that their single key be used both as the sender and the recipient. This is known as self-derivation. When the sender wishes to create a scheme where anyone can derive the corresponding key, we specify the use of the number 1 as the private key. This is known as anyone-derivation.

We specify a permission system in which the security level defined as part of the protocol is employed to determine whether the user is prompted to allow a key derivation operation to succeed. We specify that there exists some mechanism for the client to prompt the user, transparently to the application, about these permission requests. We specify that all permission requests are granted by the client on a per-application basis, and that the client has some reliable manner of identifying applications.

When the protocol specifies a security level of 0, no permissions are required and the key derivation operation is always allowed to succeed without user input. When the security level is 1, the user must grant the application permission to use the protocol, and the application can use the protocol for any counterparty without additional grants of permission. When the security level is 2, the client will require a new permission grant for every new counterparty, and the grants of permission made under level-2 protocols are counterparty-specific.

We specify that the client may provide a mechanism for the expiration of permission grants by the user, at which time the user would need to re-authorize an application's continued use of their keys. Since the permissions process is handled transparently by the client, it is beyond the scope of this standard.

Rules

Protocol IDs are normalized by the following rules:

• only letters, numbers and spaces
• no multiple space " "
• all lower case when used
• maximum 280 characters
• must be at least 5 characters
• must not end with " protocol"
• leading and trailing spaces are removed

All strings that normalize to the same value identify the same protocol.

Key IDs must be a string of at least one byte and no more than 1033 bytes.

Some protocol IDs are used internally by various clients, and thus are never allowed within applications. These are specified by other standards, such as BRC-44.

Examples

To illustrate how the system is intended to function, we provide several examples.

1. An application, example.com, sends a request to the user's client for encrypting some data (as per BRC-2). The application is requesting to use security level 0, a protocol ID of Hello World, a key ID of 1, and counterparty of self.

   • The client makes no permission requests because the security level is 0.
   • The client computes 0-hello world-1 as the invoice number.
   • The client uses its own private key and the corresponding public key for derivation, because counterparty is self.
   • The client derives a child public key as the sender and a child private key as the recipient, using the same invoice number for both operations.
   • The client computes a shared secret between the two child keys.
   • The client uses the shared secret key as a symmetric key for the encryption process.

2. An application, example.com, sends a request to the user's client for creating a digital signature over some data (as per BRC-3). The application is requesting to use security level 1, a protocol ID of Document Signing, a key ID of 1, and counterparty of anyone.

   • The client checks if example.com has already been granted permission to use this protocol. Because the security level is 1, the client does not check for a counterparty-specific permission grant.
   • The client makes a permission request, which the user accepts.
   • The client computes 1-document signing-1 as the invoice number.
   • The client uses its own private key as the sender, and the public key 1 * G as the counterparty, as the counterparty is anyone.
   • The client derives a child private key as the recipient using the invoice number, and uses the derived key to compute the digital signature.
   • Any verifier can now use 1 as a private key in conjunction with the signer's root public key and the same invoice number to derive the corresponding child public key used for the signature.
   • The verifier can then check the signature against the derived child public key for validity.

3. An application, example.com, sends a request to Alice's client for creating a digital signature over some data (as per BRC-3). The application is requesting to use security level 2, a protocol ID of Private Document Signing, a key ID of 1337, and counterparty of Bob's public key.

   • Alice's client checks if example.com has already been granted permission to use this protocol specifically for interacting with Bob. Because the security level is 2, the client must check for a counterparty-specific permission grant specific to Bob under this protocol.
   • Alice's client makes a permission request, which Alice accepts.
   • Alice's client computes 2-private document signing-1337 as the invoice number.
   • Alice's client uses her own private key as the sender, and Bob's public key as the counterparty.
   • Alice's client derives a child private key as the recipient using the invoice number, and uses the derived key to compute the digital signature.
   • Bob's client can now use his private key in conjunction with Alice's root public key and the same invoice number to derive the corresponding child public key used for the signature.
   • Bob's client can then check the signature against the derived child public key for validity. No one aside from Alice and Bob can check the signature for validity.

Implementation

The system is implemented into the Babbage SDK, which employs protocol IDs, key IDs and security levels when facilitating the functionality of the encryption and digital signature creation components.