LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • 1. Abstract
  • 2. Motivation
  • 3. Terminology & Definitions
  • 4. Certificates and Selective Disclosure
  • 4.1 Certificate Format
  • 4.2 Master Certificate
  • 4.3 Verifiable Certificate
  • 4.4 Selective Field Encryption
  • 4.5 Creation and Verification Processes
  • 5. Peer-to-Peer Messaging Overview
  • 5.1 Message Types
  • 5.2 Transports
  • 5.3 Session & Nonce Management
  • 6. Mutual Authentication Protocol Flow
  • 6.1 Handshake Sequence
  • 6.2 Nonce Creation & Verification
  • 6.3 Message Signing & Verification
  • 6.4 Certificate Requests & Responses
  • 6.5 General Message Exchange
  • 7. Error Handling & Security Considerations
  • 8. Implementation Notes
  • 9. Acknowledgments

Was this helpful?

Edit on GitHub
Export as PDF
  1. Peer-to-Peer

Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol

PreviousProven Identity Key Exchange (PIKE)NextHTTP Transport for BRC-103 Mutual Authentication

Last updated 4 months ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

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 .

  • 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.

BRC-100