Last week I gave a keynote talk at CCS about DigiTally, a project we’ve been working on to extend mobile payments to areas where the network is intermittent, congested or non-existent.
The Bill and Melinda Gates Foundation called for ways to increase the use of mobile payments, which have been transformative in many less developed countries. We did some research and found that network availability and cost were the two main problems. So how could we do phone payments where there’s no network, with a marginal cost of zero? If people had smartphones you could use some combination of NFC, bluetooth and local wifi, but most of the rural poor in Africa and Asia use simple phones without any extra communications modalities, other than those which the users themselves can provide. So how could you enable people to do phone payments by simple user actions? We were inspired by the prepayment electricity meters I helped develop some twenty years ago; meters conforming to this spec are now used in over 100 countries.
We got a small grant from the Gates Foundation to do a prototype and field trial. We designed a system, Digitally, where Alice can pay Bob by exchanging eight-digit MACs that are generated, and verified, by the SIM cards in their phones. For rapid prototyping we used overlay SIMs (which are already being used in a different phone payment system in Africa). The cryptography is described in a paper we gave at the Security Protocols Workshop this spring.
Last month we took the prototype to Strathmore University in Nairobi to do a field trial involving usability studies in their bookshop, coffee shop and cafeteria. The results were very encouraging and I described them in my talk at CCS (slides). There will be a paper on this study in due course. We’re now looking for partners to do deployment at scale, whether in phone payments or in other apps that need to support value transfer in delay-tolerant networks.
There has been press coverage in the New Scientist, Engadget and Impress (original Japanese version).
Further comment from Payment Week.
In the initial “Basic Protocol”, how does Alice verify C in step 3? She doesn’t have K_B that was used to generate the MAC.
In the basic protocol, all the cards use the same key. We rely on tamper-resistance and intrusion detection, as in many electronic purse systems. Bank risk management rules typically limit such systems to $30 or so per transaction, so we discuss later how to set up a key KAB shared by Alice and Bob to authenticate larger transactions.
Ahh. Could I humbly suggest that the paper might need some light editing then? The introduction to section 3 explicitly describes per-card keys K_A and K_B, then 3.1 goes on to assume a shared key K instead. Section 3.3 uses K_A and K_B in equations (8) and (9) but it’s not clear if this is intended (that is, separately from the shared key K_AB).
Is it just the introduction to section 3 that is in error, and should describe the shared key K instead?
This is a fair comment. The paper should make clear that, on initialisation, Sam not only puts KA in Alice’s card and KB in Bob’s card, but a universal secret K in all cards – which is used only for low-value transactions. We’ll make this edit for the next version.