2
Ich habe eine Frage zu T = 1 Smart Card-Kommunikationsprotokoll. Angenommen, das Terminal sendet einen I-Block mit erwarteten Ne-Daten, die von der Karte zurückgegeben werden sollen (sog. Fall 2S), und die Karte hat weniger zu sendende Daten. Bedeutet dies, dass das Terminal bis zum Timeout warten und dann prüfen sollte, was für die letzten zwei Bytes empfangen wurde (was der Status SW1 und SW2 sein sollte)? Oder gibt es ein anderes Szenario in Bezug auf dieses Problem? Mit T = 0 Protokoll wird dieses Problem durch Prozedur-Byte angesprochen, aber in T = 1 sehe ich nur den obigen Weg.T = 1 Smartcard-Protokoll
Dank
Ich nehme an, dass Karte sollte Prolog LEN Feld, was ist die Menge der Daten, die es zurückgibt, aber Frage ist, wenn das LEN-Feld korrekt empfangen wird (überprüfen Bytes kommt später während der Antwort). Allerdings nicht so sicher. – Djole
Obwohl ich kein Protokollexperte bin, scheint das ein Missverständnis zu sein. Le gibt nur die * maximale * Anzahl der vom Terminal akzeptierten Bytes an. Es kann weniger sein. (Dies unterscheidet sich von dem LEN-Feld der Protokollblöcke, die natürlich exakt übereinstimmen müssen, und die Antwort-APDU ist vollständig von dem Befehl, den Sie senden, entkoppelt.) Das LRC-Byte folgt später ist irrelevant, da wir über a sprechen blockorientiertes Protokoll. – guidot
Was mich in ISO7816-3 wahrscheinlich in die Irre geführt hat, war: "Ne bezeichnet die maximale Anzahl von Bytes, die im Antwortdatenfeld erwartet werden". Für mich sah es aus wie etwas, was erwartet wird, aber mehr sein könnte. Egal, Frage bezieht sich mehr auf die Möglichkeit, beschädigtes LEN-Feld zu erhalten, was ich als Indikator dafür verwenden möchte, wie viele Bytes noch kommen werden. Also, wenn es (LEN) ist beschädigt und sage größer als die Menge der Bytes kommen, ist es meine einzige Möglichkeit, die Zeitüberschreitung zu fangen? Von falschem LEN konnte ich nur von Check-Byte (s) lernen, die später kommen, aber ich kann es nicht in der Nachricht finden (mit schlechtem LEN). – Djole