> [...] one of the main vulnerabilities in protocols like these is in the 'personalization' stage of the setup, where each card gets a set of default 'provisioning keys,' which are used to register the card and get unique user keys for it. A sample of unpersonalized blanks would yield that, and the costs associated with mitigating this with batch specific keys for provisioning is typically too much complexity.
Is your point "some smartcard schemes don't use key diversification, so this one probably doesn't either", and more generally "some smartcard schemes are implemented insecurely, so surely this one must be too"?
> There may be a DoS vulnerability in some card schemes where you can use 'torn' NFC connections to get the key and transaction counter on the card applet to increment and desynchronize from the counter recorded on the server, bricking the card
Speculation again, or do you have concrete evidence for this protocol being susceptible to torn transactions? Some are, some aren't.
Also, you know what else you can do to a card when you have physical access to it? You can take a pair of scissors and cut it in half! A remote bricking capability would be concerning, but requiring an intentional and repeated transaction tear hardly seems noteworthy.
> Given the physical user enrollment costs, there are some basic impossibilities in these protocols [...] I am very grateful this researcher has done work to discredit this scheme.
It seems like you are generalizing from one concrete project to all smartcard systems, for what seem to be somewhat irrational motives.