3

Do programmable smartcards supporting the ISO 14443 contactless specification usually provide a way to disable the contactless interface entirely, of course provided that the configuring entity (whether on- or off-card) has the necessary privileges?

I have seen that it is possible for a card application to discover the interface over which request APDUs are arriving, and to refuse certain or all operations accordingly, but I'm wondering if there is another, lower layer switch available.

If so, is it possible to prevent the card from responding to anticollision requests altogether, or is it usually implemented at a higher level in the ISO 14443 stack, e.g. before or after the card transmits its UID?

Such a switch would seem to be entirely implementation defined, but I'm wondering whether it is generally available in common card (OS and hardware) implementations, and how this feature would be called in data sheets or specification documents.

lxgr
  • 3,719
  • 7
  • 31
  • 46

1 Answers1

1

To judge from a hardware (i. e. smart card controller) suppliers data sheet, this would likely be called similar to [physical] interface deactivation.

Note, that ISO focuses on specifying, how each interface works, the interactions between different interfaces are a grey area right from the beginning. I'm not aware of an existing or planned ISO command for interface deactivation; since it is possible, to specify the allowed interfaces in the access rule anyway, the only benefit would be, that the card does not respond to a power-up on the deactivated interface.

I also currently don't see a scenario, where command-triggered interface deactivation would be essential - while for payment cards this could be an issue, there is no well-established infrastructure, as self-service terminals, to manage cards.

And finally: our card operating system does not provide a command for interface deactivation and I know of no customer request in that direction.

guidot
  • 5,095
  • 2
  • 25
  • 37