We have implemented two main variations on mobile payment using versions of SHCBK, A and B. In the first, the payee is assumed to be a merchant, as is the case for today's credit and debit card payments. The second is peer-to-peer payment between mobile phones. In both cases we have assumed that the payment is managed through online banking accessed through the mobile phone.
A. On-line payment
The paying telephone does not interact with the
user's computer at all. The only function of that computer in the
protocol is to display the digest value on the https
ecommerce site.
B. Peer to peer payment between two mobile phones
The payment method
illustrated here is
by mobile banking. The protocol allows secure acquisition of the
payee's bank account details
and other information to help secure the transaction.
In scenario A, we have assumed that the purchase is made online.
However, it would be easy to convert the following to Point of Sale (POS).
The customer C has come to the point of paying on an internet session and is confident that the HTTPS session is connected to the merchant M.
C presses a button on the website for mobile payment and starts (*) the payment application on his mobile phone. The button gives C's phone payment number to M securely via HTTPS.
M calls C's mobile phone and runs the initial messages of the protocol with it.
M calculates the digest and displays it on existing HTTPS window.
Assuming C wishes to carry on; he types this number into phone which then decides if numbers agree. Agreement gives secure connection.
M sends details of the payment it wants over the secure (authenticated and encrypted) connection including amount, name, possible logo and bank information.
The payment is displayed on mobile phone (in our implementation, in the form of a cheque) and C is asked to confirm payment (*).
Payment is processed by e-banking, which generates a receipt to send to M.
As discussed earlier in this paper, it will be necessary in practice to have the customer prove his identity as part of this process. One or both of the points marked (*) are appropriate.
The second works similarly. In our implementation, the mobile phones connect via Bluetooth, but telephony and other routes are also possible.
The two users will connect their phones much as C and M are connected above. Now C will probably enter the amount to pay rather than confirming the payee's request. In our implementation, the payer sees a cheque appear on his/her mobile phone to confirm paying it.
We note that in neither scenario is any confidential information given by C to the payee. This will considerably reduce the opportunities for fraud.
The cryptography functions we have applied in the applications comply with the guidance published in FIPS 186 -3, FIPS 196, SP 800-78.