Point of Sales use cases for Keycard

Status Mobile
1

Current Keycard API and applet are mostly designed to be used between someone’s Keycard and his own mobile. They are not fully designed to support cases where one uses his Keycard with an app running on somebody else’s device.

Still we want to have Keycard API and applet ready to handle use cases where a Keycard is tapped with a Point Of Sales to purchase simply (most simple being a simple tap) goods with a wallet account protected by the Keycard.

The goal of this post is to share what’s at stake, brainstorm on the relevant use cases for PoS, so that we design the right evolution of Keycard protocol.

Some considerations about the of PoS role in security

What we call a PoS here is either:

  • any mobile phone or tablet running an application that allows to sell stuff. This can be Status app with some PoS functionalities,
  • a PoS terminal, which is a dedicated hardware to perform sales (with printer, more powerfull NFC etc.)

One important thing in Keycard security fundamentals is that the client side must be trusted. This comes from the fact that Keycard does not have buttons or a screen, and the client is thus used for:

  • Keycard PIN entry
  • Display transactions details (especially the amount)

Most POS terminals are Android based and are functionaly not more than a mobile phone, but being a dedicated hardware they can provide some authentification mechanism (software based or hardware based) so that Keycard can check the PoS it’s talking to is legit.

A generic PoS use case for Keycard

The most generic use case we can think of between a PoS and Keycard is the following one, breaked down into those simple steps:
1/ PoS forges a transaction for something to purchase
2/ PoS displays the amount of crypto of the purchase
3/ (Optional) user enters his Keycard PIN on the PoS
4/ User taps his card, the card sign the transaction with a key pair embedded on the keycard
5/ PoS acknowledges that the transaction has been signed and transmitted to the network, and is now waiting for approval
6/ When transaction is confirmed, PoS shows that the transaction is confirmed, and there happens the transfer of property

Impacts on Keycard protocol

The current secure channel mechanism of Keycard (current Keycard API is v2) uses a pairing code as a shared secret, at setup.

To enable the PoS use case described above we need to make the API and applet evolve to a v3 that handles the following:

  • create a new secure channel mode that
    • does not require a pairing code
    • when in this mode no other commands can be performed by the client
      - than PIN verification,
      - and signing transaction with a fixed and given keypair in the keycard
  • the following open questions are:
    • do PoS transactions require a PIN or not ?
    • If not how can I protect my Keycard from being stolen some crypto by just taping my Keycard through my pocket ?
    • how many accounts the user can set-up for PoS transactions ?
    • if several how are they set-up ?
    • if there are PIN, are they different from the main PIN (non PoS mode), how are they set-up ?

Please note that the Keycard does only get a hash of the transactions, and thus cannot apply some logic like “if the amount is <x euros, then I do not need a PIN to sign the transaction”

What are the real world use cases that will come first?

To help decide with the open questions, could you share your ideas on how do you think Keycard will be used with PoS, for what usages ? for what type of transactions ? to buy what kind of goods?

Especially your real world ideas of when could a user turn his Status app into a PoS to make a transaction with someone else’s Keycard would be nice to hear!

1 Like
2

My first instinct is some sort of integration with Teller Network.

Completing a Teller Network transaction.

As a new user of Status I find a teller (Keycard holder), I provide cash, the teller marks the funds as received and gives me crypto by tapping the keycard to my phone.

2 Likes
3

Traditional taxis (like the Black Cabs in London) are struggling to compete with the likes of Uber. One of the issues for London cabs is that the card terminal providers take a significant chunk of the total in transaction fees, and therefore the drivers prefer cash (and thus deter passengers from paying by card). I think drivers would welcome the ability to turn their phone into a PoS for fast, low-fee, transactions.

1 Like
5

There’s been some discussion in the past week on how to use Status as a Point of Sales.

Here’s the debrief on the discussions we had

and here is some early draft of the flow for the receiving screen function that dApps would call

6

Also just sharing with you an interesting remark (potential security issue) from Julien about these scenario.

When the Keycard is used as a hardwallet, the mobile used must be trusted. Which is fine, since the user is using his own phone, and he has some level of control that he downloaded the official Status app which is trusted.

In the PoS scenario, it’s different because the user taps his keycard on someone else’s mobile phone, we can’t prevent this mobile phone to run an app that looks like Status, but where the receiving screen would be hacked to send the keycard tapped payments to another wallet for instance.

Any idea to prevent that ? apart from the fact that the keycard payment path is not supposed to hold large amount of money.

7

I don’t think there’s a complete solution since, for technical reasons, the card receives only a hash to sign, so it doesn’t know anything about transactions.

But if we use the card to sign meta-transactions that are then executed from a smart contract, we can add more features there like max tx value, max daily txs, etc…

2 Likes
8

Hypothetical solution:

  • Can the keycard pass on information to the reader?
  • If so, can reading a keycard give a visual indicator either in GUI or native on the phone LED?
  • If so, can the keycard owner indicate a pattern?

This would be a variation to or application of the signing phrase. Still no way around a merchant using a malicious build holding the phone out of view.

9

The meta transaction with a max-amount limit in the smart contract is a great mitigation strategy. Even if the card had the full transaction, since it has no context it could also do no more than limit the amount anyway.

One thing to note, though, is the context of the transaction. If it is a peer-to-peer exchange then a feedback system can sort out the bad apples (of course, a few users will potentially get burned). If instead we are talking about merchants with a physical location, they have little incentive to defraud a customer and ruin their reputation forever and possibly face legal consequences.

I’d say lets first list detailed scenarios of fraud (with all involved actors and situation) so we can provide a mitigation strategy for each. These strategy might be not card related or not even directly technology-related.

Unfortunately not, card-to-device communication is fully driven by the client side and the application doing the reading has full access, so such a feature would require support at the operating system level which is not present.

2 Likes
10

+1, this is a good point !