Handling fake payment requests

[emschwartz]

From Security Issue #1:

A server-side validation of the Merchand Identification during the pull-payment request. That way, the Ledger of the tapFi user can do a real-time validation of the payment. Unthrusted stores wouldn't be accepted by the Ledger, canceling the payment.

If that's the case though, it'll be difficult to open a new store that accepts tapFi because you'll first need to be accepted by all of the ledgers.

Another potential option would be to add a delay (and opportunity for cancellation) in between when the Interledger payment is prepared and executed. In that case, the merchant (if they're online) would be able to confirm that the money had been prepared for them, meaning that the payment request seen by the tapFi was the correct one. If the user doesn't cancel in, say, 10 seconds then the fulfillment is transmitted to the merchant and they can fulfill the payment.

Regarding this idea:

An approach to reduce the risk, is to limit the signal strenght reception to high values, so that the attacker trying to fake the purshase needs to be close to the victim.

Could the merchant's system also detect if someone else was broadcasting payment requests right near them?

[ivanseidel]

[...] the merchant (if they're online) would be able to confirm that the money had been prepared for them [...]

How would the Merchant get a confirmation (that doesn't come from the tapFi) about a Payment? tapFi is offline all the time

What I thought was to Blacklist stores/Ledgers instead of Whitelisting them. That way, it can prevent already discovered frauds.

Could the merchant's system also detect if someone else was broadcasting payment requests right near them?

tapFi is the only one broadcasting. Stores "connect" to tapFi and make requests to it, just like a tapFi was a Server.

Although you cannot know what's going on inside a channel (and even if someone is connected), tapFi device could do that.

The way it works today, is:

1. tapFi enters broadcast mode (Just saying he provides tapFi payments, and hist BLE name)
2. Store discovers tapFi, and connects to it
3. Then fetches the user domain and domain.
4. Store Disconnects.
5. Merchant selects tapFi for payment
6. Store connects
7. Store send request for payment
8. tapFi validates request and send payload
9. Store disconnects
10. Store makes payment online, or hold the payload for usage when connected

We could insert, after step 4, a "counting" of how many stores have connected to the device. And make it publicly accessible by anyone connecting to the device. That way, the Merchant/Store, can have a list of "who's" connecting to tapFi's around there that is not him.

And also, when a tapFi device receives two or more requests for reading the username and domain, it might do a two-round payment (first listen to requests, then confirms/deny all of them).

That way, we are able to identify and at least block those fake payments requests, but not yet "know who is te right one", because there isn't a way to trust the store unless we hold information about them inside tapFi.

[emschwartz]

How would the Merchant get a confirmation (that doesn't come from the tapFi) about a Payment? tapFi is offline all the time

The merchant can get a notification about and incoming payment being prepared from their ledger.

What I thought was to Blacklist stores/Ledgers instead of Whitelisting them. That way, it can prevent already discovered frauds.

If you rely only on blacklisting, couldn't an attacker trivially rotate their keys to avoid having their active ones in the blacklist?

And also, when a tapFi device receives two or more requests for reading the username and domain, it might do a two-round payment (first listen to requests, then confirms/deny all of them).

I like the idea of tapFis getting more suspicious when they get more than one connection request at once, though couldn't that happen for legitimate reasons if it were in range of multiple POS systems?

[ivanseidel]

If you rely only on blacklisting, couldn't an attacker trivially rotate their keys to avoid having their active ones in the blacklist?

I assume it's not trivial to own a trusted ledger with a "store" authorization for it. Just like with banks, you need to sign real things and that process takes times. The Ledger should provide some sort of "legitimacy" confirmation of the Store. And if the Ledger is doing that in a wrong way, then it's peers should be careful...

Not sure I'm seeing things as I should, but for me it's not going to be as easy as filling in a registration form online and getting the SDK to play with. The receiving account would need to be enabled for that sort of payment or anything else.

The merchant can get a notification about and incoming payment being prepared from their ledger.

But still, if I'm faking a payment request, I can receive the notification of incoming payment confirmation as well, don't I? How would that prevent fake stores from stealing money?

[emschwartz]

I assume it's not trivial to own a trusted ledger with a "store" authorization for it. Just like with banks, you need to sign real things and that process takes times. The Ledger should provide some sort of "legitimacy" confirmation of the Store.

What you're describing is effectively a whitelist 😄 . In general we're trying to make a more open system than what exists today. Today the security is provided by the fact that a single company controls the whole network, they can impose any restrictions they want, and can kick out anyone they want. In a more open system, anyone could create a ledger or a store but the question is how do they get others to trust them.

But still, if I'm faking a payment request, I can receive the notification of incoming payment confirmation as well, don't I? How would that prevent fake stores from stealing money?

The case I'm thinking of is where the tapFi gets two payment requests at the same time. One is from the legitimate merchant and one is from the attacker. The tapFi doesn't know which one is which. Let's say it tries one (instead of freaking out because it's gotten two requests).

In the flow I'm describing, the tapFi would prepare funds to pay one of the payment requests. If the funds are prepared to the attacker, the merchant would not get a notification of prepared funds. The store POS could alert the user that they should cancel the payment. You could do that by tapping or holding the tapFi, or something like that.

If the tapFi prepares a payment to the legitimate merchant, the store POS would get a notification that funds are on hold and could display that to the user. If the user doesn't cancel the payment, the tapFi would transmit the fulfillment to the POS, enabling the merchant to fulfill the incoming transfer and claim the funds.