Out of Band Address Exchange using Payment Protocol Encryption

  BIP: 75
  Layer: Applications
  Title: Out of Band Address Exchange using Payment Protocol Encryption
  Authors: Justin Newton 
           Matt David 
           Aaron Voisine 
           James MacWhyte 
  Comments-Summary: Recommended for implementation (one person)
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075
  Status: Deployed
  Type: Specification
  Assigned: 2015-11-20
  License: CC-BY-4.0

Abstract

This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.

# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.

# It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Copyright

This work is licensed under a Creative Commons Attribution 4.0 International License.

Definitions

Sender	Entity wishing to transfer value that they control
Receiver	Entity receiving a value transfer

Motivation

The motivation for defining this extension to the BIP70 Payment Protocol is to allow two parties to exchange payment information in a permissioned and encrypted way, such that wallet address communication can become a more automated process. This extension also expands the types of PKI (public-key infrastructure) data that is supported, and allows it to be shared by both parties (with BIP70, only the receiver could provide PKI information). This allows for automated creation of off-blockchain transaction logs that are human readable, now including information about the sender and not just the recipient.

The motivation for this extension to BIP70 is threefold:

# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.

# Enhance the Payment Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests.

# Allow a sender of funds the option of sharing their identity with the receiver. This information could then be used to:

#* Make Bitcoin logs (wallet transaction history) more human readable #* Give the user the ability to decide whether or not they share their Bitcoin address and other payment details when requested #* Allow for an open standards based way for businesses to keep verifiable records of their financial transactions, to better meet the needs of accounting practices or other reporting and statutory requirements #* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience

In short we wanted to make Bitcoin more human, while at the same time improving transaction privacy.

Example Use Cases

1. Address Book

A Bitcoin wallet developer would like to offer the ability to store an "address book" of payees, so users could send multiple payments to known entities without having to request an address every time. Static addresses compromise privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications, and there is always a risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the corresponding private key.

With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding an entry to one's address book could be done by using a Wallet Name, scanning a QR code, sending a URI through a text message or e-mail, or searching a public repository. When the user wishes to make a payment, their wallet would do all the work in the background to communicate with the payee's wallet to receive a unique payment address. If the payee's wallet has been lost, replaced, or destroyed, no communication will be possible, and the sending of funds to a "dead" address is prevented.

2. Individual Permissioned Address Release

A Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, BIP70 shares the receiver’s payment address and identity information with anyone who requests it.

With this BIP, Bitcoin wallets could use the sender’s identifying information to make a determination of whether or not to share their own information. This gives the receiving party more control over who receives their payment and identity information. Additionally, this could be used to automatically provide new payment addresses to whitelisted senders, or to protect users’ privacy from unsolicited payment requests.

3. Using Store & Forward Servers

A Bitcoin wallet developer would like to use a public Store & Forward service for an asynchronous address exchange. This is a common case for mobile and offline wallets.

With this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address or payment information, only delete encrypted messages.

Modifying BIP70 pki_type

This BIP adds additional possible values for the pki_type variable in the PaymentRequest message. The complete list is now as follows:

pki_type	Description
x509+sha256	A x.509 certificate, as described in BIP70
pgp+sha256	An OpenPGP certificate
ecdsa+sha256	A secp256k1 ECDSA public key

NOTE: Although SHA1 was supported in BIP70, it has been deprecated and BIP75 only supports SHA256. The hashing algorithm is still specified in the values listed above for forward and backwards compatibility.

New Messages

Updated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as the messages newly defined in this BIP.

NOTE: Public keys from both parties must be known to each other in order to facilitate encrypted communication. Although including both public keys in every message may get redundant, it provides the most flexibility as each message is completely self-contained.

InvoiceRequest

The InvoiceRequest message allows a Sender to send information to the Receiver such that the Receiver can create and return a PaymentRequest.

message InvoiceRequest {
        required bytes  sender_public_key = 1;
        optional uint64 amount = 2 [default = 0];
        optional string pki_type = 3 [default = "none"];
        optional bytes  pki_data = 4;
        optional string memo = 5;
        optional string notification_url = 6;
        optional bytes  signature = 7;
}

Field Name	Description
sender_public_key	Sender's SEC-encoded EC public key
amount	amount is integer-number-of-satoshis (default: 0)
pki_type	none / x509+sha256 / pgp+sha256 / ecdsa+sha256 (default: "none")
pki_data	Depends on pki_type
memo	Human-readable description of invoice request for the receiver
notification_url	Secure (usually TLS-protected HTTP) location where an EncryptedProtocolMessage SHOULD be sent when ready
signature	PKI-dependent signature

ProtocolMessageType Enum

This enum is used in the newly defined ProtocolMessage and EncryptedProtocolMessage messages to define the serialized message type. The ProtocolMessageType enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.

enum ProtocolMessageType {
    UNKNOWN_MESSAGE_TYPE = 0;
    INVOICE_REQUEST = 1;
    PAYMENT_REQUEST = 2;
    PAYMENT = 3;
    PAYMENT_ACK = 4;
}

ProtocolMessage

The ProtocolMessage message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, non-encrypted communication of Payment Protocol messages. The message also includes a status code and a status message that is used for error communication such that the protocol does not rely on transport-layer error handling.

message ProtocolMessage {
    required uint64 version = 1
    required uint64 status_code = 2;
    required ProtocolMessageType message_type = 3;
    required bytes serialized_message = 4;
    optional string status_message = 5;
    required bytes identifier = 6;
}

Field Name	Description
version	Protocol version number (Currently 1)
status_code	Payment Protocol Status Code
message_type	Message Type of serialized_message
serialized_message	Serialized Payment Protocol Message
status_message	Human-readable Payment Protocol status message
identifier	Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)

Versioning

This BIP introduces version 1 of this protocol. All messages sent using these base requirements MUST use a value of 1 for the version number. Any future BIPs that modify this protocol (encryption schemes, etc) MUST each increment the version number by 1.

When initiating communication, the version field of the first message SHOULD be set to the highest version number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.

EncryptedProtocolMessage

The EncryptedProtocolMessage message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.

message EncryptedProtocolMessage {
    required uint64 version = 1 [default = 1];
    required uint64 status_code = 2 [default = 1];
    required ProtocolMessageType message_type = 3;
    required bytes encrypted_message = 4;
    required bytes receiver_public_key = 5;
    required bytes sender_public_key = 6;
    required uint64 nonce = 7;
    required bytes identifier = 8;
    optional string status_message = 9;
    optional bytes signature = 10;
}

Field Name	Description
version	Protocol version number
status_code	Payment Protocol Status Code
message_type	Message Type of Decrypted encrypted_message
encrypted_message	AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message
receiver_public_key	Receiver's SEC-encoded EC Public Key
sender_public_key	Sender's SEC-encoded EC Public Key
nonce	Microseconds since epoch
identifier	Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String)
status_message	Human-readable Payment Protocol status message
signature	DER-encoded Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively

Payment Protocol Process with InvoiceRequests

The full process overview for using InvoiceRequests in the Payment Protocol is defined below.

All Payment Protocol messages MUST be encapsulated in either a ProtocolMessage or EncryptedProtocolMessage. Once the process begins using EncryptedProtocolMessage messages, all subsequent communications MUST use EncryptedProtocolMessages.

All Payment Protocol messages SHOULD be communicated using EncryptedProtocolMessage encapsulating messages with the exception that an InvoiceRequest MAY be communicated using the ProtocolMessage if the receiver's public key is unknown.

The process of creating encrypted Payment Protocol messages is enumerated in Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages, and the process of decrypting encrypted messages can be found under Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages.

A standard exchange from start to finish would look like the following:

# Sender creates InvoiceRequest # Sender encapsulates InvoiceRequest in (Encrypted)ProtocolMessage # Sender sends (Encrypted)ProtocolMessage to Receiver # Receiver retrieves InvoiceRequest in (Encrypted)ProtocolMessage from Sender # Receiver creates PaymentRequest # Receiver encapsulates PaymentRequest in EncryptedProtocolMessage # Receiver transmits EncryptedProtocolMessage to Sender # Sender validates PaymentRequest retrieved from the EncryptedProtocolMessage # The PaymentRequest is processed according to BIP70, including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages.

NOTE: See [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public K