0103.md

BRC-103: Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol

Ty Everett ([email protected])

1. Abstract

This document specifies a peer-to-peer protocol for mutual authentication and signed data exchange. The protocol uses certificates, nonce-based challenges, and digital signatures to protect the integrity and authenticity of messages, enabling:

• Selective field disclosure of certificates without revealing unnecessary information.
• Highly extensible message types, suitable for a variety of use cases such as transaction coordination, identity verification, and arbitrary data sharing.
• Interchangeable transport layers, which can be HTTP, NFC, WebSockets, or any mechanism supporting bidirectional message exchange.

The specification provides a standard approach for issuance, storage, retrieval, and verification of identity certificates, as well as the end-to-end handshake and messaging protocols between peers.

2. Motivation

Secure interactions among different wallets and services are critical. These interactions typically require:

• Proving identity in a privacy-preserving manner, possibly revealing only some data fields (e.g. “I am over 18” without revealing full date of birth).
• Ensuring that both parties are authenticated to each other (mutual authentication), reducing the risk of man-in-the-middle or impersonation attacks.

A standard protocol for mutual authentication and certificate exchange addresses these needs and fosters interoperability between applications, wallets, and vendors.

3. Terminology & Definitions

• Wallet: An interface or application managing the user’s keys, capable of signing, encrypting, and decrypting data in conformance with BRC-100.
• Certificate: A data structure that attests to certain user attributes, signed by a certifier.
• Master Certificate: A special form of certificate that has been encrypted field-by-field, each with a unique symmetric key, stored in an internal keyring.
• Verifiable Certificate: A certificate derived from a master certificate, revealing keys for only the fields a particular verifier may see.
• Peer: A party participating in communication, using the protocol to exchange messages.
• Session: The state tracking an authenticated channel between two peers.
• Nonce: A random value used once within a cryptographic exchange to ensure freshness and avoid replay attacks.
• Signature: A digital signature produced by the user’s or certifier’s private key.
• Transport: The underlying communication medium that relays messages between peers.

4. Certificates and Selective Disclosure

4.1 Certificate Format

Certificates are stored and transmitted in a binary format to optimize size and parsing consistency. We specify each field in table form, together with how it is conventionally represented when not in binary. The binary format is always used for signing and verification, but the conventions are useful for human readability. A certificate has the following primary fields:

Field Name	Type	Description
Type	32-byte (base64) string	Certificate category identifier (e.g., unique type associated with “social handles”).
SerialNumber	32-byte (base64) string	Uniquely identifies this certificate instance.
Subject	33-byte compressed pubkey (hex)	The wallet’s (subject’s) public key.
Certifier	33-byte compressed pubkey (hex)	The certifier's public identity key.
RevocationOutpoint	32-byte TXID + varint output idx	On-chain reference to track revocation (if spent, revoked).
Fields	Varint count + repeated pairs	Pairs of: <fieldNameLength, fieldName, fieldValueLength, fieldValue>
Signature	Varint length + bytes	Certifier’s signature over all fields (excluding itself).

Important: Each certificate field is encrypted with a field-specific key. The encrypted version is signed.

4.2 Master Certificate

A Master Certificate includes a master keyring. Each field in the certificate is encrypted with a unique symmetric key. Those keys, in turn, are encrypted for the certificate holder (subject). Hence, a master certificate is able to decrypt any of its own fields locally but can selectively re-encrypt only some fields for a verifier.

4.3 Verifiable Certificate

A Verifiable Certificate is derived from a master certificate. It still contains all fields in ciphertext form (so that signatures can be verified) but also includes a “verifier-specific keyring.” For fields the subject wishes to disclose, the subject decrypts the corresponding symmetric key from the master keyring and re-encrypts it for the verifier. Consequently, the verifier can decrypt only those chosen fields.

4.4 Selective Field Encryption

1. Master Keyring Generation

   • For each field f, create a random symmetric key K_f.
   • Encrypt the field’s plaintext using K_f, store as Fields[f] = E(K_f, fPlaintext).
   • After all fields are encrypted, the certifier signs the assembled certificate, comprising all encrypted fields.
   • The certifier can then encrypt the key K_f for the subject’s own identity: EncryptedKey_f -> E_subject(K_f), the subject can store in the master keyring.

2. Disclosure to a Verifier

   • When selectively disclosing field f, the subject decrypts EncryptedKey_f, obtains K_f, and re-encrypts K_f with the verifier’s identity key, producing K_f_for_verifier.
   • The subject includes K_f_for_verifier in the verifier’s keyring for that verifiable certificate.

4.5 Creation and Verification Processes

Certificate Creation

1. User (subject) or certifier forms certificate fields (including Type, SerialNumber, etc.).
2. Each field is encrypted.
3. The certifier signs the certificate data.

Certificate Verification

1. A party verifying a certificate reassembles the binary structure.
2. Checks the signature against the “signature preimage” (all primary certificate fields except the signature itself, and not including their verifier keyring).
3. Considers the RevocationOutpoint to confirm the certificate is not on-chain revoked (if it is not 36 zero bytes).

Selective Disclosure

• The subject issues a Verifiable Certificate containing:
  • Original field ciphertext.
  • Re-encrypted field keys for fields to reveal.
  • The certifier’s signature.

The verifier can decrypt each revealed field’s ciphertext with the provided key, verifying the signature across the entire certificate to ensure authenticity.

5. Peer-to-Peer Messaging Overview

5.1 Message Types

Each message exchanged between peers contains:

• Version: The protocol version string (e.g. “0.1”).
• MessageType: One of: initialRequest, initialResponse, certificateRequest, certificateResponse, general.
• IdentityKey: Sender’s public key.
• Nonce Fields: For challenge–response patterns (e.g. yourNonce, initialNonce).
• Signature: A digital signature by the sender’s private key over the relevant content.
• Optional Data:
  • Certificates: A list of verifiable certificates.
  • RequestedCertificates: A set specifying certifiers and certificate types with fields.
  • Payload: Arbitrary data included in general messages.

5.2 Transports

The protocol does not mandate a specific transport. Any medium that can:

1. Deliver messages in a reliable or semi-reliable manner, and
2. Allow receiving peer messages,

can be used. HTTP requests, WebSockets, Bluetooth, NFC, or local function calls are all valid.

5.3 Session & Nonce Management

A peer typically maintains a session record containing:

• isAuthenticated: Whether the peer is recognized as fully authenticated.
• sessionNonce: A locally generated random 256-bit value.
• peerNonce: The peer’s random 256-bit value.
• peerIdentityKey: The peer’s public identity key.

A session is created or updated whenever a handshake starts or completes. Nonces and signatures ensure that replaying old messages fails.

6. Mutual Authentication Protocol Flow

6.1 Handshake Sequence

The handshake typically has two messages in the simplest form: an initialRequest and an initialResponse.

1. initialRequest

   • Sender (A) generates a random nonce (A_Nonce).
   • A sends initialRequest containing:
     • messageType = "initialRequest"
     • identityKey = A_publicKey
     • initialNonce = A_Nonce
     • Optionally, a requestedCertificates set if A wants B’s certificates.

2. initialResponse

   • Receiver (B) verifies the request, creates its own random nonce (B_Nonce).

   • B sends initialResponse containing:

     • messageType = "initialResponse"
     • identityKey = B_publicKey
     • initialNonce = B_Nonce (its own newly created nonce)
     • yourNonce = A_Nonce (echoing A’s nonce)
     • Optionally, any certificates B wants to share right away.
     • A signature verifying B truly created this message.

   • When A receives this initialResponse, it verifies B’s authenticity via the signature over (A_Nonce + B_Nonce), marking the session as authenticated.

6.2 Nonce Creation & Verification

• Each party uses a cryptographically secure random generator for the nonce (e.g., 32 bytes).
• The verifying side must ensure the nonce is matched or “echoed” in subsequent messages.
• Optionally, one may use an HMAC-based approach to bind nonces to their key, avoiding the need to keep track of all nonces that they created.

6.3 Message Signing & Verification

Signature ensures authenticity. The signing steps:

1. Collect relevant data from the message. For instance, a general message might sign the raw payload array plus ephemeral fields such as (requestNonce + peerNonce) to bind the message to the session.
2. Use the BKDS-based BRC-100 signature creation and verification mechanisms.
3. Place the resulting signature in the message’s signature field.

Verification:

1. Recompute the same message preimage.
2. Verify the signature with the alleged identityKey.
3. If valid, accept the message. Otherwise, reject or treat as an error.

6.4 Certificate Requests & Responses

After or during handshake, a peer may request:

• certificateRequest: “Please provide certificate(s) of type(s) X, issued by Y (or Z).”
• certificateResponse: Peer responds by attaching a list of verifiable certificates that match the requested type and certifier.

Request:

• Contains a RequestedCertificates structure:
  • certifiers: array of public keys representing permissible certifiers.
  • types: a dictionary of certificateTypeID -> array of fields requested.

Response:

• Contains an array of VerifiableCertificates, each possibly containing:
  • Encrypted fields.
  • Re-encrypted keys for the requester.
  • The certifier’s signature.

6.5 General Message Exchange

Once both sides have completed the handshake (i.e. set isAuthenticated=true in their session records), they can exchange arbitrary data:

• messageType = "general"
• payload can be any binary or text data encoded consistently.
• The message includes a fresh nonce and references the peer’s nonce for ephemeral binding to the session.
• The signature covers the payload plus nonces.

7. Error Handling & Security Considerations

1. Replay Attacks:
   • Nonces must be unique and used once. The receiver ensures that the same nonce is not accepted more than once.
2. Man-in-the-Middle:
   • The handshake uses mutual signature verification. If a middle party tries to modify data, the signature verification fails.
3. Certificate Revocation:
   • The revocationOutpoint can be polled or monitored in the ledger to confirm it has not been spent. A spent outpoint implies the certificate is revoked Non-zero outpoints must be checked.
4. Selective Disclosure:
   • Properly encrypt fields with randomly derived keys.
   • Re-encrypt those keys only for intended verifiers.
5. Privilege Escalation:
   • Carefully manage session state to ensure a partially authenticated session does not gain privileges.
6. Transport Security:
   • Although each message is authenticated, transport-level encryption (e.g. TLS) can still be beneficial, especially to hide message lengths or frequencies.
   • This protocol does not encrypt any data by itself.

---

8. Implementation Notes

• Data Types:
  • Nonces are 32 bytes.
  • Public keys are 33 bytes in compressed DER format.
  • Certificate fields may vary in size, so a length-prefix technique (varint) is standard.
• Storage:
  • A wallet may store certificates in a local database.
  • A session manager maps sessionNonce and peerIdentityKey to a single in-memory record.

9. Acknowledgments

This protocol is heavily inspired by existing cryptographic handshake approaches (SSH, TLS) and identity-certificate systems (X.509), adapted for a BSV-based environment. Contributors within the ecosystem have refined these ideas to align with BKDS, peer-to-peer exchange, selective disclosure, and other needs.