2

ISO7816-3 standard for Smart Card states that some cards is not obliged to support character repetition (due to parity error). Now let's say interface device (ID) receives parity error data from the unknown card during ATR (answer to reset). It (ID) signals the error to the card, but knowing nothing about if card supports repetition, how can it determine whether next character from the card is repeated one (that had parity error) or next one (in case the card doesn't support repetition).

vlp
  • 7,811
  • 2
  • 23
  • 51
Djole
  • 142
  • 11

1 Answers1

1

As far as I understand the standard, the error detection works in the following way:

  • for T=0 the error signal and character repetition is used

  • for the others there is always a frame checksum which is used for error detection (TCK byte in Answer-to-reset, LRC/CRC in T=1 frames)

Citing ISO/IEC 7816-3:2006, section "Answer to reset", subsection "Characters and coding conventions":

The error signal and character repetition according to 7.3 is mandatory for the cards offering T=0; it is optional for the interface devices and for other cards.

Citing subsection "Check byte TCK" under section "Answer-to-Reset":

If only T=0 is indicated, possibly by default, then TCK shall be absent. If T=0 and T=15 are present and in all the other cases, TCK shall be present. When TCK is present, exclusive-oring all the bytes T0 to TCK inclusive shall give '00'. Any other value is invalid.

The above means that the correct transmission of ATR is checked by error signal/character repetition for pure T=0 cards. And by TCK byte for the rest.

In your scenario the interface device really cannot distinguish repeated character from the not-repeated one after parity error, but in case the card does not support error signal/character repetition the resulting TCK byte (which is mandatory in this case) should be wrong with a high probability.

Disclaimer: This is my interpretation of the standard, please do validate my thoughts...

Good luck!

vlp
  • 7,811
  • 2
  • 23
  • 51
  • It does have sense to me, although I ask myself why in some cases (parity detection) I was given an opportunity to acquire repeated character and in other cases (no TCK) I can just learn that something is not OK. But suppose there should be some historical reasons behind that. Although I accepted this answer, I can hardly validate it- see [link]https://electronics.stackexchange.com/questions/329913/smart-card-parity-error-notification.. – Djole Sep 20 '17 at 21:17
  • @Djole I wish I had a verified answer for you (maybe someone else gives a better one). [Here](https://github.com/vlp/ssim/blob/master/src/common/me_io.inc) is a very simple (busy-waiting) card side implementation for PIC with error detection. Good luck! – vlp Sep 20 '17 at 22:16
  • I'm going to read the code you pointed to, however PIC has nice feature regarding issue we were talking about- it announces the error at the half of stop bit (statement from their application note [link]http://ww1.microchip.com/downloads/en/AppNotes/01370A.pdf). At the moment I decided to ignore parity, because there are still many questions, other then this parity issue, that I'll have to make clear. – Djole Sep 21 '17 at 06:44
  • @Djole By chance a found [another card side implementation for AVR](https://github.com/popovec/oseid)..Might be interesting for you... – vlp Sep 22 '17 at 19:47