Protocol design suggestion

  • I think embedding an address into the ring has been quite adequately covered already, so I won't go into that here. For a v1 of the NFC ring, this is the best we can expect.

    But let's instead focus on the goal of allowing payment to be initiated by the ring. For the ideal user experience, we need to make the payment with no user interaction beyond "brofisting" (lol) the NFC reader. The obvious answer is to have weak trust assetions for merchants. Having some concept of a "merchant" isn't very bitcoinish, but it's the best we can do with such a limited interaction model.

    There are several parts to this, none of them trivial. We start by embedding not only a Bitcoin address in the ring but also a Bluetooth MAC address. The user must have an Android smartphone with them, which is running an (unsecured) RFCOMM socket. Unsecured is a particular mode of using Bluetooth in which no pairing is required, but the connection is vulnerable to MITM attacks. We have prototyped this technique in the Bitcoin Wallet app already and it works seamlessly.

    When the user touches the ring to the reader, it observes that there is a BT MAC in the rings NDEF records, and proceeds to establish contact with the users phone. The Bluetooth socket might have been intercepted by a man in the middle, so at this point an elliptic curve Diffie-Hellman (ECDH) key agreement protocol is run in which the phones public key is the same as their Bitcoin public key (the hash of which was read from the ring). The merchant side presents their public key as well, which is kept around for checking later.

    Now a (half) authenticated and encrypted channel is established, an extended version of the payment protocol begins (BIP 70). The merchant presents a signed payment request for the amount that they wish to charge the user. The certificate chain is verified as normal, the payment request is likewise validated. The public part of the (SSL) key that's signing the payment request would also be checked to ensure it was used to set up the ECDH connection (or a key signed by that key, etc).

    In a new extension field, a new certificate is also presented. It is issued by one of several "roots of trust" that would have to be set up by the Bitcoin community. This is a bit like a parallel CA infrastructure.

    Essentially, a certificate issued by a RoT is a statement that the merchant identified by the normal certificate chain is a legitimate entity who can be trusted to play by the rules and not try to defraud you. The certificate not only contains this fact via a digital signature, but also spending limits - the amount of money per unit time the merchant is allowed to request "trustlessly".

    Upon seeing this payment request, the phone would then proceed to respond to the payment request with a set of Bitcoin transactions satisfying that request (another message written over the RFCOMM socket), keeping track in a local database of how much payment was made and when to enforce the limits. This prevents a bad merchant insider or hacker from draining a users wallet by modifying the hardware.

    Having these assertions of the trust level of merchants allows all kinds of flexible user experiences. For example, rather than using the ring, your phone can broadcast a small piece of photo + first name data using Bluetooth Low Energy. It's efficient enough to be broadcasting all the time. The merchant can then pick your name from a list of people in the shop and charge you, without a ring even being required.

    The ring protocol can also work without any kind of root-of-trusts, but then you would have to manually approve merchants the first time you interacted with them, and set the spending limits yourself. It's more efficient and less bothersome to outsource that. The low costs of a RoT would be paid for by the business, in order to get the slicker and more convenient experience.

    Implementing this is not hard, but it's not a weekend hack either. The essential parts would be:

    [:26tksz44]Demonstrate a library (ideally java so it's easily used on Android) that sets up a ECDH secured connection over insecured Bluetooth.[/:m:26tksz44]
    [:26tksz44]The payment protocol has to be implemented in bitcoinj (someone is working on this, but there hasn't been a whole lot of progress).[/:m:26tksz44]
    [:26tksz44]Rewrite the Android wallet apps handling of Bluetooth so it uses the above library and the payment protocol instead of the current ultra-simple proprietary thing.[/:m:26tksz44]
    [:26tksz44]Make the Android wallet be able to program the NFC ring with a bitcoin URI. This is just a case of putting the QRcode data into the ring - it's probably the easiest part of the whole project.[/:m:26tksz44]
    [:26tksz44]Write a simple merchant server that can be connected to a USB NFC reader, and runs the ECDH/payment protocol over the socket.[/:m:26tksz44]
    [:26tksz44]Define a payment protocol extension for the parallel Bitcoin-specific CA infrastructure. Add support for that to bitcoinj so the Android wallet knows how to read it.[/:m:26tksz44]
    [:26tksz44]Define some ground rules for the insta-pay feature (how does a RoT operator decide how much money a merchant should be able to insta-charge? total conceivable bill size? 90th percentile of recent payments?). Create an initial RoT that merchants can apply to and get signed.[/:m:26tksz44]
    [:26tksz44]Wire it all together in the Android app and merchant server.[/:m:26tksz44][/list:u:26tksz44]

    Yep, it's pretty complicated, and to prototype you could skip some of the heavier parts like encrypting the Bluetooth connection. But if implemented that would allow a scaleable and easy to use adoption of the NFC ring for initiating payments.

  • NFC Ring Team

    Great write up and some great suggestions.

    My beef here is that you have to have your phone with you, so if your battery dies and/or you lose your phone there is no way to make a payment. Personally I want to avoid this and just have the value of the amount stored and accessible on the ring at any given time an amount that the wearer can "afford to lose" should it be exploited.

  • Banned

    This post is deleted!

  • Maybe multi-sign solutions can be interesting here? New wallets with this functionality is currently in beta, if I've read the news correctly.