Following Guy-Louis’ post we wanted to share and discuss the risk and possible mitigation strategies that we see when using Keycard in a payment network. Some mitigation strategies are a bit complex and I have linked a more technical document describing them in details. In particular the reputation system is a complex topic and I am still working on it (and I am actually wondering if it is too risky to use). Any feedback is very welcome.
First we need to understand what security risks we incur and why. The main considerations to keep in mind is that Keycard does not have any user input output capability so interaction must always happen through a second device. Additionally, the card does not have a battery and as such cannot keep a clock. In a payment scenario this device belongs to the merchant and not to the card holder, making it inherently untrusted. Unlike existing payment networks, we want transactions to be possible through any device, meaning the POS will not have a certification process and remain an untrusted element.
From this perspective, it becomes clear that a malicious merchant can:
- Create a transaction for an amount larger than agreed with the customer (the POS screen can lie). Since the balance of an account can be easily enquired a transaction can take 100% of what is stored
- Create several transactions, possibly with different recipient wallets and send them at a later time to cover its track and mask malicious activity
- Log any input provided by the user through their terminal
These are the options we have come up with so far. Some options can be used together, some are mutually exclusive and some can be impractical. Proposal of new strategies or challenging the proposed ones is the main goal of this post.
These are the basic mitigation strategy that will surely be implemented or are implemented already
- Keep a payment wallet separate from the main fund wallet, limiting the fraud potential to an amount the user considers acceptable
- Do not share credentials between the main wallet and the payment wallet. Even if it might sound counterintuitive, we found the most acceptable solution is to make payments completely pinless. Another solution would be to have a separate payment PIN but this is likely to confuse the user and very likely to be correlated to the main PIN if chosen by the user
- Use a smartcontract to limit per-transaction amount, possibly also allowing a cooldown period between two transactions and hard daily/monthly limits
Mitigation of multiple transaction attacks
When performing a POS transaction, we want the terminal to only sign a single transaction following the rule of one tap/one signature. However the POS can send as many SIGN commands as it wants, eluding this measure. Here are some possible strategies.
- Only allow one SIGN command to be processed per power-up. Although useful, the terminal can reset the card relatively quickly so while this certainly limits the amount of transactions signed in the timeframe of a tap, it cannot guarantee that only one transaction will be signed.
- Add a timestamp field to the SIGN command. The timestamp must be signed by an authority the card trusts. The card can then store the timestamp and refuse all successive SIGN command with a timestamp which is not at least 1 minute in the future (let’s assume a tap lasts no more than two seconds and is usually much quicker). Although this adds an authority in the process, there are several public timestamp servers already operating which can be used. The additional remote request will slow things down a little.
- Add a transaction counter limit on-card. The card will refuse to perform more than X SIGN commands until the user, through an authorized command on their trusted device, allows X more. This is similar to the timestap approach in goal but simpler for all involved parties. However the user must remember to allocate transactions regularly for this to work.
Reducing unauthorized transactions
- Use a transaction pre-approval mechanism. The card will only SIGN transaction hash previously signed by an online pre-approval service. The POS will query the card for the address of server, meaning that as long as the API is respected, the card holder can choose any service or even run their own service. The pre-approval server performs a risk assessment on the transaction according to user defined policies. Some examples include whitelisting, blacklisting, capping transaction amount/count for unknown merchant. The service could send a notification on each preapproved transaction or even require user confirmation. This approach is the most flexible in regards of policies and does not involve central authorities. More technical details here.
- Use a reputation system. Allows the user to dispute transactions by staking a small amount of tokens ($5-10 equivalent?) within x (10-30?) days after the transaction has been performed. Each merchant will have a reputation score based on the number and value of performed transactions, heavily weighted towards recent transactions so that it does not accumulate over time. Each open dispute lowers the merchant score and if it gets negative, the disputes are won by the buyer, otherwise they are won by the merchant. The scoring formulas must be tuned so that the ratio of performed transactions in the last x days and open disputes must be below a certain percentage (15-20%?) for the score to remain positive. This system relies on using smartcontract accounts for all transactions with regulated transfer from/to EOA. As any reputation/dispute system, the outcome of the dispute will not always be just and it will take some fine-tuning to the formula to maximize accuracy. I think however that a very high accuracy can be obtained, especially since it can deter bad behaviour. The goal of this system is to revert transactions performed by fraudsters, not to resolve case-by-case disputes, because honest merchants would win those easily, since they would get a dispute once in a blue moon. More technical details here (WIP).
- Adding a screen and a button on the card. This would allow the user to check the transaction amount and confirm transactions individually, pressing the buttons. This is the most effective mitigation measure, but it would greatly increase the complexity and cost of the hardware. With current technology, implementing such a device in card format is possible but the resulting device is not bound to be very durable because solder joints on a flexible PCB will break easily. The price for flexible PCBs, batteries and screens is also high as of today.
Since a PIN is not required to perform payments, theft or skimming are viable attack routes. Possible mitigation strategies are
- Allowing the user, through their main wallet account, to revoke signing rights to the smartcontract holding the funds. The main wallet account is PIN protected on card and should be backed up either using Keycard facilities or as a regular BIP39 seed. The smartcontract should also allow the user to assign new cards as signers.
- Encourage physical security measures against skimming. Reading a card through a wallet or clothes is not easy and can be effectively prevented by using either an RFID-shielded wallet or a simple RFID-shielded pouch.
- Adding an on/off switch on card can be a sure way to deny any proximity attacks. The cost at manufacturing should be minimal, because placing a toggle or push button between the chip and the coil is enough, the chip does not need to be aware of the switch.
- Adding a biometric sensor would be a good substitute for a PIN, since the card would be able to authenticate it autonomously. This could greatly affect the cost of the card though