An LndHub NFC Lightning card proposal
In our journey to bring Bitcoin to mass adoption, we have to face a very practical problem: paying in shops with BTC isn't simple. I don't mean it's complicated cause you need to have any particular knowledge, everyone can use a smartphone, what I mean is that best you can do still requires a lot of steps compared to fiat payments. Merchant generates a QR code Lightning invoice, you do this:
Pick your phone -> Unlock it -> Open Bluewallet -> Select wallet -> Press "Send" -> Press "Scan" -> Choose "Use Camera" -> Scan QR code -> Confirm Payment
The usage of QR codes seems fast compared to copying and pasting addresses, but when transposed in everyday life becomes slow and annoying. People use plastic cards to pay cause are quick, lightweight, don't need an internet connection or battery.
How can we apply this to a Bitcoin payment? Here is my proposal for an NFC Lightning card payment protocol for LndHub.
What's needed:
- NFC Java Card
- NFC Reader
- Lightning account on a LndHub node
Java Cards are a powerful type of programmable smart cards used for ePassports, SIM cards, banking cards and other applications where security is crucial. Their cost is high ($10-$20), but the capabilities are way superior to conventional NFC cards like Mifare, especially cryptography wise cause they can generate key pairs on the chip and this is what we need.
When a user linked to LndHub server asks for a Lightning card, a key pair is generated and public key exported and saved on the database. The private key never leaves the device.
Data collected on Lightning Card:
- LndHub UserID
- LndHub server address
- Private key
Payment Process:
A regular lightning invoice is created by the merchant and is transferred to the card to be signed, the reader gets server address and user ID.
At this point, the reader knows where to ask for the payment and sends a request to the indicated server attaching the signed invoice and the UserID.
LndHub server checks the signature using UserID's corresponding key, checks user balance and finally authorises the transaction and pays the invoice.
It's important to notice that the payer doesn't need to trust the merchant's NFC reader to not store his data cause anyway, without the card, it can't send another valid payment request.
Every smartphone with NFC capabilities potentially become a Lightning payment POS as it doesn't need any certification to operate, you can write your own app, the important part is that at the end it communicates to LndHub server in the same format: signed invoice + UserID
With the same logic, we can build other payment instruments like a browser extension.
Technicalities and proposed setup:
This part of the article will be updated with the chosen signing algorithm once I get the Java Card development kit.
Signing algorithm: ECDSA
I preferred this over RSA cause of smaller size of the keys, with a 256 bit ECC key having the same security level as a 3072 bit RSA key. ECDSA is faster in signing and slower in verification, but this is ok cause signing will be executed on underpowered smart cards, verification is on server.