Risks and mitigation strategies for Keycard in a payment network

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:

  1. 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
  2. Create several transactions, possibly with different recipient wallets and send them at a later time to cover its track and mask malicious activity
  3. Log any input provided by the user through their terminal

Mitigation strategies

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.

Basic strategies

These are the basic mitigation strategy that will surely be implemented or are implemented already

  1. Keep a payment wallet separate from the main fund wallet, limiting the fraud potential to an amount the user considers acceptable
  2. 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
  3. 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.

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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).
  3. 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.

Limiting theft

Since a PIN is not required to perform payments, theft or skimming are viable attack routes. Possible mitigation strategies are

  1. 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.
  2. 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.
  3. 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.
  4. 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

If Merchants are staking in a network and collecting fees for securing the network, this could also be used as a ‘certification’ process in the sense that if someone challenges their fraudulent transaction their stake could be slashed, merchants would only be able to process transactions up to the amount they have staked, you could also give a small award to the challenger upon successful transactions (and penalising for false claims, by a similar staking mechanism)

How a fraud claim would be confirmed is unknown, maybe it’s majority vote or confirmation from end user or some arbitration process.

This would create a market for fraudulent transaction monitors of the payment network, which wouldn’t necessarily requite the end user to be aware of fraudulent transactions.


Using a smart contract that can undo transactions don’t seems a simple solution because it would require a whole technical and social infrastructure for it to work, and this looks like the role of a company like VISA or MasterCard.
While Keycard would not implement that, it could support this type of “super-visioned” payments for users buying from non trusted sites, but also develop solutions to secure payment between trusted parties, like addresses to whom you commonly transfer for, only needing the nonce signature, and merchant would withdraw from user account - or use a statechannel…

The Chip itself can be considered a smart contract, but differently from regular smart contracts, this one have a private key that can sign messages. Key card is a wallet contract that accepts payments by providing the PIN and transaction data.
Based on this we could implement multiple keys or allowances by using different pins, but this would be horrible from UX perspective.

Education is an option aswell, but risky if the only approach.
Keycard is not a credit card, nor a debit card, is a key card :slight_smile:. It not only can do do payments, but it can also be your self soverign identity, and more - so you should not just put it on other people scanners.


I see, the reputation system in the proposal goes more or less in that direction, although the stake from the merchant is “dynamic” in that it consists of performed transactions in the cooldown period. The fraud claim also has a stake system and the decision is basically a vote in the sense that a certain amount of disputes makes the reputation of the merchant go negative and they lose their transactions. However I think it is complex to adjust all stakes/reputation formulas so that neither part is able to cheat the system without risking huge amounts of tokens. We could also add an initial stake as you proposed to make the barrier of entry for fraudsters higher. The hard part is settings the amount in such a way not to hinder adoption but still deter potential fraudsters

The issue we are trying to tackle here is in-person transactions with the classical card/PoS pair. For remote transactions you have a lot of instruments to decide if a vendor is trustworthy or not (including review sites) so the situation wouldn’t be much different from what it is now. Reversing transactions is indeed dangerous, the reputation system we are working on will surely get some decisions wrong. The question here is what percentage and how hard/expensive it is to trick.

We decided to go PINless for PoS payments because a PIN can be logged if inserted on a third party device and if you have several PINs it is likely that revealing one can reveal the pattern with which you choose PINs, so it is safer not to give one. The card also receives only the transaction hash so it cannot really apply any rule directly. The reason for this, is that we either limit the card to a very restricted subset of known tokens or the card would have no way to understand the actual value of the transactions since it does not have access to exchange rates or things like that. Also the card does not have Keccak so it cannot generate the hash autonomously

Education is the main approach we originally planned to adopt, but it was met with a lot of skepticism, so we started looking for more complex solutions. Personally, I am very fond of the pre-approval service idea (is in the list of solutions in this Discuss post) since it can prevent a lot of bad transactions without needing reversal and gives a lot of flexibility.


Another risk mitigation strategy is to have velocity control in the card. i.e. the card evaluates the transaction and checks if the sum of amounts sent over a period of time (e.g. trailing 24 hours) is below a certain value. The trusted timestamp mechanism mentioned above would be required. Storage of amounts with timestamps would also be needed.

Different cards for the same wallet could implement different velocity limits. The high limit card could be left in a secure location for occasional use.

A physical switch or touch button could also be used to switch to a different velocity limit.

1 Like

that’s a great input, however one immediate issue is that keycard only signs the transaction hash (and wouldn’t be powerful enough with current available javacards to get the transaction and sign it), so the card has not clue of what it’s signing :frowning:

Could you expand on that? what is the operation that the card is not powerful enough to perform? Is it the sha3?

I do see that it takes ~7 seconds based on this impl: https://github.com/MiragePV/OptimizedJCAlgs/tree/master/Sha3