Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol

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

BRC-103 uses the certificate formats, signature preimage, field encryption rules, master keyrings, and verifier keyrings defined by BRC-52. BRC-103 messages MUST NOT define an alternate certificate binary layout or alternate certificate signature preimage.

When BRC-103 carries a certificate in JSON, it carries a BRC-52 core certificate plus any applicable BRC-52 unsigned extension members, such as a verifier keyring. When BRC-103 carries a certificate in binary, it carries either BRC-52 CertificateBinary or a BRC-52 length-prefixed certificate-with-keyring envelope, as required by the surrounding message encoding.

4.2 Master Certificate

A Master Certificate is a BRC-52 core certificate plus a complete master keyring. It is normally stored by the wallet and is not sent to ordinary verifiers.

4.3 Verifiable Certificate

A Verifiable Certificate is derived from a master certificate and contains the BRC-52 core certificate plus a verifier-specific keyring. It still contains all encrypted fields so the verifier can check the certifier signature over the complete certificate, but it only includes field revelation keys for fields disclosed to that verifier.

4.4 Selective Field Encryption

BRC-103 selective disclosure is the BRC-52 selective revelation process:

  1. The holder keeps a master certificate whose master keyring can decrypt all fields.

  2. For a verifier, the holder decrypts the selected field revelation keys from the master keyring.

  3. The holder re-encrypts those field revelation keys for the verifier and includes them in the verifiable certificate keyring.

4.5 Creation and Verification Processes

Certificate creation, signature verification, field decryption, and revocation checks MUST follow BRC-52. The verifier MUST verify the BRC-52 core certificate signature before accepting any decrypted field and MUST treat a spent non-sentinel revocationOutpoint as revoked.

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.

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

Last updated