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
  • Abstract
  • Motivation
  • BRFCID
  • Specification
  • Implementations
  • Flow

Was this helpful?

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

Proven Identity Key Exchange (PIKE)

Darren Kellenschwiler (deggen@kschw.com) Damian Orzepowski (damian.orzepowski@4chain.studio)

Abstract

Allowing humans to securely exchange public keys using web apis and an off channel sharing of TOTPs.

Motivation

When you use hosted servers for payment output generation there's no way to detect if the host has been compromised and is sharing keys not associated with the intended recipient.

BRFCID

A random ID was generated in order to avoid label collisions in the capability document of a paymail server.

brfcid: 8c4ed5ef8ace
title: Proven Identity Key Exchange (PIKE)
author: Darren Kellenschwiler, Damian Orzepowski
version: 1.0.0

Specification

Roughly speaking you create a shared secret between you and the counterparty using their public key and your private key. If you each do this you can arrive at a shared secret. You then derive a time hashed one time pass code to prove you both have the same value - each sharing the TOTP and validating the counterparty's. Thereafter you can use that public key knowing that it really is that counterparty without fear of MITM attacks.

Implementations

Flow

  1. Sender wallet: generate random hash

  2. Sender wallet generate public key from private key and random hash

  3. Sender wallet is sending "add contact request" to Sender BUX containing: a. contact paymail address b. random hash c. generated public key

  4. Sender BUX is performing Paymail host discovery (which is described on this page: https://tsc.bsvblockchain.org/standards/paymail/#ServiceDiscovery)

  5. Sender BUX is performing Paymail capability discovery on Receiver BUX by requesting /.well-known/bsvalias

  6. If Receiver BUX doesn't contain Proven Identity Key Exchange (PIKE) capability, Sender BUX should return an error to Sender Wallet

  7. else the Sender BUX is sending a "Add a contact" request to Receiver BUX on the endpoint provided in PIKE capability. This request contains: a. sender paymail address b. random hash c. generated public key

  8. Receiver BUX stores that "contact" as "waiting" in database

  9. Receiver BUX is answering to Sender BUX with success

  10. Sender BUX is storing the "contact" as "waiting"

  11. Receiver Wallet asks Receiver BUX for "waiting" "contact" to confirm or reject

  12. Receiver BUX is responding with the list of contacts

  13. If Receiver Wallet reject the contact, then: a. it is sending rejection request to Receiver BUX b. Receiver BUX is removing the contact from database c. In that case the flow ends

  14. else: Receiver Wallet generate public key from private key and random hash from the contact

  15. Receiver Wallet is sending the request for Receiver BUX for accepting the contact with informations: a. paymail address for contact to accept b. generated public key

  16. Receiver BUX is marking a "contact" as "accepted"

  17. Receiver BUX is sending the "contact accepted" request to Sender BUX with: a. paymail address of Receiver b. generated public key c. random hash

  18. Sender BUX is validating random hash, and stores received public key in "contact" and marks it as accepted

  19. Sender Wallet is asking Sender to confirm contact

  20. Sender asks Receiver for TOTP

  21. Receiver checks TOTP for Senders paymail in Receiver Wallet

  22. Receiver Wallet calculates shared secret based on private key and Senders public key

  23. Receiver Wallet generates TOTP based on shared secret

  24. Receiver Wallet sends back TOTP to Receiver

  25. Receiver is responding with TOTP to Sender

  26. Sender is providing TOTP to Sender Wallet

  27. Sender Wallet calculates shared secret based on private key and Receiver public key

  28. Sender Wallet generates TOTP based on shared secret

  29. Sender Wallet is comparing received TOTP with generated TOTP. If their match then it marks contact as confirmed.

  30. Sender Wallet is now generating another TOTP and provides to Sender

  31. Sender is providing TOTP to Receiver

  32. Receiver is providing TOTP to Receiver Wallet

  33. Receiver Wallet is generating TOTP and comparing it with received TOTP If their match then it marks contact as confirmed.

sequenceDiagram
actor Sender
participant Sender Wallet
participant Sender BUX
participant Receiver BUX
participant Receiver Wallet
actor Receiver

    Sender->>Sender Wallet: Add receiver as contact
    activate Sender Wallet
    Sender Wallet->>Sender Wallet: Generate random hash
    Sender Wallet->>Sender Wallet: Generate public key from private key and random hash
    deactivate Sender Wallet
    activate Sender Wallet
    Sender Wallet->>Sender BUX: Add contact request
    activate Sender BUX
    Sender BUX->>Sender BUX: Paymail host discovery
    Sender BUX->>Receiver BUX: Paymail capability discovery
    activate Receiver BUX
    Sender BUX->>Receiver BUX: Add a contact request
    Receiver BUX->>Receiver BUX: Store contact as "waiting" in database
    Receiver BUX->>Sender BUX: Success
    deactivate Receiver BUX
    Sender BUX->>Sender BUX: Store contact as "waiting"
    Sender BUX->>Sender Wallet: success
    deactivate Sender BUX
    Sender Wallet->>Sender: Display success
    deactivate Sender Wallet
    
    Receiver Wallet->>Receiver BUX: Get "waiting" "contact" to confirm or reject
    activate Receiver Wallet
    activate Receiver BUX
    Receiver BUX->>Receiver Wallet: List of contacts
    deactivate Receiver BUX
    alt reject contatct
        Receiver Wallet->>Receiver BUX: Rejection request
        activate Receiver BUX
        Receiver BUX->>Receiver BUX: Remove contact from database
        deactivate Receiver BUX
    else accept contact
        Receiver Wallet->>Receiver Wallet: Generate public key from private key and random hash
        Receiver Wallet->>Receiver BUX: Accept contact request
        activate Receiver BUX
        Receiver BUX->>Receiver BUX: Mark contact as "accepted"
        Receiver BUX->>Sender BUX: Contact accepted request
        Sender BUX->>Sender BUX: Validate random hash and store received public key
        Sender BUX->>Receiver BUX: success
        Receiver BUX->>Receiver Wallet: success
        deactivate Receiver BUX
        deactivate Receiver Wallet
    end
    Sender Wallet->>Sender: Confirm contact?
    activate Sender
    Sender->>Receiver: TOTP request
    activate Receiver
    activate Receiver
    Receiver->>Receiver Wallet: Check TOTP for Senders paymail
    activate Receiver Wallet
    Receiver Wallet->>Receiver Wallet: Calculate shared secret based on private key and Senders public key
    Receiver Wallet->>Receiver Wallet: Generate TOTP based on shared secret
    Receiver Wallet->>Receiver: TOTP
    deactivate Receiver Wallet
    Receiver->>Sender: TOTP
    deactivate Receiver
    Sender->>Sender Wallet: TOTP
    activate Sender
    activate Sender Wallet
    Sender Wallet->>Sender Wallet: Calculate shared secret based on private key and Receiver public key
    Sender Wallet->>Sender Wallet: Generate TOTP based on shared secret
    Sender Wallet->>Sender Wallet: Compare received TOTP with generated TOTP
    Sender Wallet->>Sender Wallet: Mark contact as confirmed
    Sender Wallet->>Sender Wallet: Generate another TOTP
    Sender Wallet->>Sender: TOTP
    deactivate Sender Wallet
    deactivate Sender
    Sender->>Receiver: TOTP
    deactivate Sender
    activate Receiver
    Receiver->>Receiver Wallet: TOTP
    activate Receiver Wallet
    Receiver Wallet->>Receiver Wallet: Generate TOTP and compare it with received TOTP
    Receiver Wallet->>Receiver Wallet: Mark contact as confirmed
    deactivate Receiver Wallet
    deactivate Receiver
    deactivate Receiver
PreviousDefining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update DeliveryNextPeer-to-Peer Mutual Authentication and Certificate Exchange Protocol

Last updated 9 months ago

Was this helpful?

SPV Wallet