> [...] 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.
These were presented areas for further research, as there are precedents for these vulns, and the economics of card distribution haven't changed much. This is a technical discussion about vulns in protocols, and given I've worked on them in the past, these were how I broke previous proposed protocols that were reimplementations of a variation on the EMV protocols. What's changed in the protocols is they have been simplified to use ECC keys (they couldn't support PKI previously because RSA keys were too long to fit in the SE key slots), but the main issue of effectively tokenizing authentication transactions (using those AES-GCM keys) has the same limitations as the original protocol - albeit with an ECC keypair to do app/device attestation.
Is this scheme vulnerable to that? Unknown. Are these attacks paths for additional vuln research that is exceptionally valuable and has significant policy consequences? Absolutely.
EMV is a completely different protocol, though! You wouldn't use a vulnerability discovered in TLS (or its implementation in OpenSSL) as an example for why SSH/OpenSSH is an insecure protocol, would you?
A smartcard is in the end just a general purpose computer (with some physical hardening and a really weird and poorly layered protocol stack that costs hundreds of CHF to even read; thank you, ISO!) – it can be just as secure or insecure as any computer system.
> Is this scheme vulnerable to that? Unknown.
Yes, but you sprinkle your comment with just enough domain language to make it seem like you have a concrete security concern for the scheme presented in the article.
I'd consider that pretty misleading, especially in the context of trying to make a point on policy, as opposed to security ("significant policy consequences", as you say).
Security protocols have a short list of moving parts and trade offs and where to attack them. RNGs, key storage, key derivation, counters, and access modes, to name a few. They're only completely different to people who don't understand them.
If you are using symmetric secrets in smart cards, you're using something within a degree of EMV because you need compatability with existing reader infrastructure, and alignment to existing standards to get anyone to accept it. the AES-GCM was the giveaway because I seem to remember a related vuln where to facilitate compatability in software instead of the smart card, the designers used the counter as an additional secret. If the designers of this scheme were not constrained by existing reader infrastructure and standards schemes, they would have done this in a more modern and elegant way, likely using a Schnorr signature or a ratchet.
Protocol designers make trade-offs that they don't advertise because they represent a consensus of the risk between the solution parties. It appears in this case, there are some obvious opportunities for further research.
> Security protocols have a short list of moving parts and trade offs and where to attack them. RNGs, key storage, key derivation, counters, and access modes, to name a few. They're only completely different to people who don't understand them.
Funny, I would have said that they only look very similar to one another to people who aren't deep enough in the weeds of a particular one.
Yes, they're ultimately all built out of the same building blocks. But just with these few you've mentioned, together with possibly having more than two actors in your system and corresponding privileged keys, the complexity of the aggregate protocol hockey sticks very quickly, and you absolutely can't reduce all problems to one another anymore.
Humans are made of atoms, yet when you're sick you go to a physician, not to a physicist.
> If you are using symmetric secrets in smart cards, you're using something within a degree of EMV
Oh, absolutely not. Sorry, but with this statement you show that you aren't familiar with other protocols in this space. There are so many smartcard (and adjacent, e.g. stored-value cards like MIFARE) protocols that use symmetric keys, yet don't share any of EMVs historical problems. I mean, even GlobalPlatform itself uses symmetric cryptography!
That's like saying that SSH and TLS are very similar protocols, since they both use asymmetric key exchanges to secure and authenticate a symmetrically-encrypted application layer channel.
A two party protocol that involves mutual authentication and key exchange has a short set of essential variations, with some features and even some theatre wrapped around it. Not sure if you're being obtuse or misleading, but yes, GlobalPlatform used symmetric cryptography because that's the literal compatability problem they impose that is a constraint on developing more modern smart card based protocols. There are also only a few main smart card vendors and they have ecosystem constraints that favor compromises like the ones discussed. Yeah, I totally don't know what I'm talking about.
The protocols and proposals I did evaluations for implemented the trade offs I mentioned above. The reason it's important for hackers to focus on these technologies is because this is literally the bar institutions use to make decisions about infrastructure security. What the original post demonstrated was the protocol implemented in these cards had vulnerabilities that were consistent with the limitations of using symmetric keys that incorporate constraints from legacy protocols.
My follow up was that there are some very obvious places to check for futher vulnerabilities, and the research is important to do so because it antagonizes just the sort of authoritarian personalities you want to keep in check in a free society. This is what hackers are for. I've made my contributions to ensuring privacy laws were upheld and that backdoored digital identity schemes could not survive, and I'm very glad a younger generation of hackers is taking up this most important work.
To anyone working on these problems, don't let the personalities discourage you, it means you're over the target.
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.