[qaisjp]

I really enjoyed this read, thanks.

In the footnotes you said:

> One complication is that the counters have an "anti-tearing" feature for additional security

Two questions:

1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters? 2. I would love to learn more about how the anti-tearing feature works!

[kens]

The problem is that if the user tears the card away from the reader in the middle of an update, that card can end up with corrupted data. This makes implementing the increment-only counters more complicated. For instance, the straightforward approach might hold 00 FF in two bytes. If you increment the counter by updating the low-order byte first, but the card gets torn away before you update the high-order byte, you end up with 00 00, and the counter has gone backward.

A simple way of preventing tearing is to have two copies of each counter; if there is tearing, then the two values will be different.

Looking at an NXP patent [1], they use a much more complicated approach, using a level of indirection. They write the new value to a different memory page and then update a pointer to the new page. There are various progress bits recorded along the way so they can roll back as needed.

[1]: https://patents.google.com/patent/EP3226141A1

Here's an article describing an attack on the anti-tearing feature: https://blog.quarkslab.com/rfid-monotonic-counter-anti-teari...