DE102005054695A1

DE102005054695A1 - Verfahren und Prüfsystem zum Prüfen eines tragbaren Datenträgers

Info

Publication number: DE102005054695A1
Application number: DE102005054695A
Authority: DE
Inventors: Michael Baldischweiler; Thorsten Ulbricht
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2004-11-17
Filing date: 2005-11-16
Publication date: 2006-05-18

Abstract

Die Erfindung betrifft ein Verfahren zum Prüfen eines tragbaren Datenträgers, der einen integrierten Schaltkreis zur Speicherung und/oder Verarbeitung von Informationen aufweist. Der tragbare Datenträger wird wenigstens einem Prüfdurchlauf unterzogen, bei dem Daten bezüglich einer zu prüfenden Funktionalität des tragbaren Datenträgers erfasst werden. Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass die erfassten Daten wenigstens teilweise mittels eines Zustandsmodells geprüft werden, das eine Reihe von Zuständen und von erlaubten Übergängen zwischen den Zuständen aufweist.

Description

Die Erfindung betrifft ein Verfahren zum Prüfen eines tragbaren Datenträgers. Weiterhin betrifft die Erfindung ein Prüfsystem zum Prüfen eines tragbaren Datenträgers.

Tragbare Datenträger, wie zum Beispiel Chipkarten, können bei einer Vielzahl unterschiedlicher Anwendungen eingesetzt werden. Beispielsweise kann ein tragbarer Datenträger als ein Ausweisdokument, zur Erlangung eines Zutritts zu einem Gebäude, zur Herstellung eines Netzzugangs eines Telekommunikationsgeräts, zur Durchführung einer Transaktion des bargeldlosen Zahlungsverkehrs, zur Erstellung einer elektronischen Unterschrift usw. verwendet werden. Eine Fehlfunktion eines tragbaren Datenträgers kann nicht nur zu Unannehmlichkeiten für den Benutzer führen, sondern auch finanzielle Schäden hervorrufen oder ein Sicherheitsrisiko darstellen. Je nach Anwendungsgebiet, für das der tragbare Datenträger vorgesehen ist, werden daher zum Teil extreme Anforderungen an dessen Funktionsfähigkeit gestellt. Um diese Anforderungen erfüllen zu können, werden bei der Entwicklung tragbarer Datenträger umfangreiche Prüfungen unter möglichst vielen potentiell auftretenden Betriebsbedingungen durchgeführt, um etwaige Fehler der Hardware oder der Software der tragbaren Datenträger zu ermitteln.

Die Prüfungen laufen üblicherweise jeweils so ab, dass von einem Prüfsystem ein Kommando an den tragbaren Datenträger gesendet wird. Der tragbare Datenträger erzeugt daraufhin eine Antwort und sendet diese an das Prüfsystem. Das Prüfsystem wertet die empfangene Antwort aus. Dieser Ablauf wird beispielsweise für alle Teilschritte einer Datenübertragung zwischen dem Prüfsystem und dem tragbaren Datenträger einzeln ausgeführt. Dabei erfolgt die Auswertung der Antwort jeweils anhand konkreter Vorgaben für die erwartete Antwort. Da zum Teil unterschiedliche Antworten des tragbaren Datenträgers möglich und zulässig sind, ist es mitunter erforderlich, in die einzelnen Testskripts, welche die Teilschritte abarbeiten, Fallunterscheidungen einzubauen. Auf diese Weise können sehr komplexe Strukturen entstehen, die aufwendig zu programmieren sind. Insbesondere sind etwaige Änderungen jeweils mit einem hohen Aufwand verbunden. Außerdem steigt mit zunehmender Komplexität das Fehlerrisiko.

Der Erfindung liegt die Aufgabe zugrunde, mit vertretbarem Aufwand eine möglichst zuverlässige und einfach durchzuführende Prüfung tragbarer Datenträger zu ermöglichen.

Diese Aufgabe wird durch ein Verfahren mit der Merkmalskombination des Anspruchs 1 gelöst.

Beim erfindungsgemäßen Verfahren zum Prüfen eines tragbaren Datenträgers, der einen integrierten Schaltkreis zur Speicherung und/oder Verarbeitung von Informationen aufweist, wird der tragbare Datenträger wenigstens einem Prüfdurchlauf unterzogen, bei dem Daten bezüglich einer zu prüfenden Funktionalität des tragbaren Datenträgers erfasst werden. Die Besonderheit des erfindungsgemäßen Verfahrens besteht darin, dass die erfassten Daten wenigstens teilweise mittels eines Zustandsmodells geprüft werden, das eine Reihe von Zuständen und von erlaubten Übergängen zwischen den Zuständen aufweist.

Gemäß einem ersten Ansatz werden die im Rahmen des Prüfdurchlaufs zulässige Ereignisse als Zustände definiert. Die Übergänge zwischen den Zuständen repräsentieren entsprechend ein zulässiges Aufeinanderfolgen je zweier Ereignisse.

Gemäß einem zweiten Ansatz werden Systemszustände als Zustände definiert. Zwischen den Zuständen ist ein Übergang durch ein zulässiges Ereignis möglich.

Die Erfindung hat den Vorteil, dass sich die Prüfung des tragbaren Datenträgers vereinfacht und Fehlerfälle leicht lokalisiert werden können. Durch das Zustandsmodell wird die Prüfung sehr übersichtlich gestaltet und kann ohne großen Aufwand an die jeweiligen Erfordernisse angepasst werden. Weiterer Vorteile besteht darin, dass die Auswertung der Prüfungsergebnisse und eine Dokumentation der Prüfung mit wenig Aufwand möglich sind.

Bei der Prüfung kann ermittelt werden, ob die erfassten Daten einer Abfolge von Zuständen entsprechen, die mit dem Zustandsmodell vereinbar ist. Dabei ist das erfindungsgemäße Verfahren vorzugsweise so ausgebildet, dass die Abfolge von Zuständen mit dem Zustandsmodell vereinbar ist, wenn sie ausschließlich aus Zuständen und Übergängen zusammengesetzt ist, die im Zustandsmodell vorgesehen sind. Auf einen fehlerfreien Prüfdurchlauf kann geschlossen werden, falls die erfassten Daten einer Abfolge von Zuständen entsprechen, die mit dem Zustandsmodell vereinbar ist.

Eine vorteilhafte Variante des erfindungsgemäßen Verfahrens besteht darin, dass die beim Prüfdurchlauf erfassten Daten aufgezeichnet werden und nach der Aufzeichnung aller beim Prüfdurchlauf erfassten Daten die Prüfung anhand der aufgezeichneten Daten durchgeführt wird. Auf diese Weise lässt sich die Prüfung besonders effizient durchführen.

Im Rahmen des erfindungsgemäßen Verfahrens können mehrere unterschiedliche Prüfdurchläufe durchgeführt werden. Dabei können vor oder bei dem ersten Prüfdurchlauf Vorbedingungen für mehrere Prüfdurchläufe gesetzt werden. Durch diese allgemeine Initialisierung kann vermieden werden, dass gleiche Vorbedingungen mehrfach gesetzt werden. Weiterhin kann vor oder bei jedem Prüfdurchlauf wenigstens eine für diesen Prüfdurchlauf vorgesehene Prüfbedingung gesetzt werden. Hierzu kann wenigstens ein Parameter systematisch variiert werden und die jeweilige Prüfbedingung auf Basis dieses Parameters gesetzt werden. Auf diese Weise ist eine effiziente und Übersichtliche Abwicklung mehrerer Prüfdurchläufe möglich. Weiterhin kann vor oder bei jedem Prüfdurchlauf das für diesen Prüfdurchlauf vorgesehene Zustandsmodell gesetzt werden. Das Zustandsmodell kann auf Basis des Parameters gesetzt werden, der auch beim Setzen der Prüfbedingungen verwendet wird. Dies hat den Vorteil, dass auf einfache und zuverlässige Weise eine korrekte Zuordnung zwischen den Prüfbedingungen und dem jeweiligen Zustandsmodell gewährleistet werden kann.

Mit dem erfindungsgemäßen Verfahren kann beispielsweise geprüft werden, ob die Datenübertragung zwischen dem tragbaren Datenträger und einem externen Gerät korrekt abgewickelt wird. Insbesondere kann geprüft werden, ob ein vorgegebenes Übertragungsprotokoll eingehalten wird. Dabei können die erfassten Daten jeweils die Richtung der Datenübertragung und wenigstens eine Information zu den übertragenen Daten enthalten. Vorzugsweise bezieht sich die Information auf die Art der jeweils übertragenen Daten.

Die Erfindung bezieht sich weiterhin auf ein Prüfsystem zum Prüfen eines tragbaren Datenträgers in wenigstens einem Prüfdurchlauf, bei dem Daten bezüglich einer zu prüfenden Funktionalität des tragbaren Datenträgers erfasst werden. Das erfindungsgemäße Prüfsystem zeichnet sich dadurch aus, dass zur wenigstens teilweisen Prüfung der erfassten Daten ein Zustands modell implementiert ist, das eine Reihe von Zuständen und von erlaubten Übergängen zwischen den Zuständen aufweist.

Die Zustände können gemäß einem ersten Ansatz im Rahmen des Prüfdurchlaufs zulässige Ereignisse repräsentieren, wobei die Übergänge zulässige Aufeinanderfolgen je zweier Ereignisse repräsentieren.

Das Zustandsmodell kann gemäß dem ersten Ansatz mittels einer Reihe von Regeln implementiert, die jeweils einen Zustand und einen Folgezustand angeben. Diese Art der Implementierung ist sehr einfach und übersichtlich, so dass sich das Zustandsmodell mit relativ geringem Aufwand implementieren lässt und die Implementierung bei einer Änderung des Zustandsmodells leicht angepasst werden kann. Außerdem können auf diese Weise auch umfangreiche Zustandsmodelle problemlos implementiert werden.

Die Zustände können gemäß einem zweiten Ansatz im Rahmen des Prüfdurchlaufs auftretende Systemzustände repräsentieren, wobei die Übergänge zulässige Ereignisse sind.

Das Zustandsmodell kann gemäß dem zweiten Ansatz mittels einer Matrix der zulässigen Zustandsübergänge und einer Referenzliste der zugehörigen Ereignisse implementiert werden. Der an einer Matrixposition enthaltene Wert ist ein Verweis in die Referenzliste, wenn der entsprechende Zustandsübergang zulässig ist.

Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten Ausführungsbeispiele erläutert, wobei der tragbare Datenträger jeweils als eine Chipkarte ausgebildet ist.
Es zeigen:
1 eine Anordnung zum Prüfen einer Chipkarte in einer schematischen Darstellung,
2 ein Flussdiagramm zur Veranschaulichung des Ablaufs bei einem Ausführungsbeispiel für das erfindungsgemäße Prüfverfahren,
3 eine erste Darstellungsform für ein Zustandsmodell der Datenübertragung zwischen dem Endgerät und der Chipkarte, das beim erfindungsgemäßen Prüfverfahren zum Einsatz kommen kann,
4 eine zweite Darstellungsform eines Zustandsmodells für einen Ausschnitt des Zustandsmodells aus 3 und
5 eine Darstellung der datentechnischen Systemkomponenten, die bei einer Prüfung mit Hilfe des Zustandsmodells aus 4 verwendet werden.
1 zeigt eine an sich bekannte Anordnung zum Prüfen eines tragbaren Datenträgers in einer schematischen Darstellung. Die Anordnung umfasst eine Chipkarte 1 gemäß ISO 7816 und ein Prüfsystem 4.
Die Ausführungsbeispiele werden für die Chipkarte 1 als tragbarem Datenträger beschrieben. Alternativ kann der getestete tragbare Datenträger beispielsweise auch ein RFID-Transponder, ein USB-Token oder ähnliches sein.
Das Prüf- oder Testsystem 4 umfasst eine Schnittstelleneinheit 6 und eine Steuereinheit 5. In der Regel wird die Steuereinheit 5 durch einen Computer gebildet, auf dem eine entsprechende Software 7 zum Testen der Chipkarte 1 abläuft. Die Schnittstelleneinheit 6 wird üblicherweise ein Kartenleser sein, der einen kontaktlosen und/oder kontaktbehafteten Datenaustausch mit der Chipkarte 1 ermöglicht.
Über die Schnittstelleneinheit 6 wird die Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1 abgewickelt. Außerdem werden der Chipkarte 1 darüber von dem Prüfsystem 4 die für den Betrieb benötigten Versorgungssignale zur Verfügung gestellt. Die Datenübertragung wird so durchgeführt, dass das Prüfsystem 4 – beispielsweise gemäß ISO 7816-4 – jeweils ein Kommando an die Chipkarte 1 sendet und die Chipkarte 1 daraufhin eine Antwort an das Prüfsystem 4 sendet.
Die Chipkarte 1 wird im Folgenden auch kurz als ICC (Integrated Chip Card) bezeichnet und weist einen integrierten Schaltkreis 2 auf, an den ein Kartenschnittstelle 3 angeschlossen ist. Der integrierte Schaltkreis 2 kann die bekannten Komponenten einer Chipkarte, also insbesondere einen Mikroprozessor sowie verschiedene Speicher, umfassen und dient der Speicherung und Ausführung von Software, die für den Einsatz der Chipkarte 1 benötigt wird.
Das Prüfsystem 4 ist vorgesehen, um die Eigenschaften der Chipkarte 1 anhand vorgegebener Kriterien zu prüfen. Insbesondere wird das Verhalten der Chipkarte 1 mittels der für ein Kommando erhaltenen Antwort überprüft.
Geprüft werden können derart beispielsweise das Betriebsystem, Datenstrukturen und temporär geladene oder persistente Anwendungen der Chipkarte 1. Auch wenn primär die auf der Chipkarte vorliegende Software geprüft wird, können auch Eigenschaften der Chipkarte, die von der Hardware beeinflußt sein können, überprüft werden. So könnte ein denkbarer Prüfablauf beispielsweise die für die Chipkarte 1 bereitgestellte Versorgungsspannung variieren und das gleiche Kommando bei verschiedenen Versorgungsspannungen senden.
Mit dem erfindungsgemäßen Prüfverfahren kann unter anderem auch ermittelt werden, ob die in Teilschritte unterteilte Datenübertragung für ein Kommando ordnungsgemäß abgewickelt wird.
2 zeigt ein Flussdiagramm zur Veranschaulichung des Ablaufs bei einem Ausführungsbeispiel für das erfindungsgemäße Prüfverfahren. Ausschnitte aus zugehörigen Programmlistings für das erfindungsgemäße Prüfverfahren sind jeweils in der Beschreibung eingefügt.
Das dargestellte Ausführungsbeispiel bezieht sich auf die Prüfung der ordnungsgemäßen Abwicklung eines standardisierten Übertragungsprotokolls für die Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1. Bei dem Übertragungsprotokoll handelt es sich beispielsweise um das Protokoll T = 1 oder T = 0.
Das Flussdiagramm beginnt mit einem Schritt S1, in welchem eine Initialisierung durchgeführt wird. Bei der Initialisierung werden Vorbedingungen für die Prüfung gesetzt. Auf Schritt S1 folgt ein Schritt S2, bei dem ein Zähler iCntr auf einen Startwert 1 gesetzt wird. Der Zähler iCntr wird dazu verwendet, die Bedingungen, unter denen die Prüfung durchgeführt wird, systematisch zu variieren. Beispielsweise kann die Prüfung der Reihe nach für eine Datenübertragung mit unterschiedlichen Blockgrößen (IFS) durchgeführt werden. Im Programmlisting der Funktion Test_Example ist hierfür eine Schleife vorgesehen, die mit dem Programmcode „for (iCntr = 0x01; iCntr < 0xFF; iCntr++)" eingeleitet wird.
Die Funktion Test_Example setzt die aktuellen Testbedingungen, indem sie die Datenfeldgröße der Chipkarte verändert, erstellt das entsprechende Modell (Scenario) und ruft eine Funktion SendCAPDU auf.
An Schritt S2 schließt sich ein Schritt S3 an, bei dem die Prüfbedingungen gesetzt werden, die für den aktuellen Wert des Zählers iCntr vorgesehen sind. Für das Beispiel verschiedener Blockgrößen bedeutet dies, dass abhängig vom aktuellen Wert des Zählers iCntr die Blockgröße (IFS) der Chipkarte für die Durchführung der Datenübertragung gesetzt wird. Im Programmcode ist der Schritt S3 des Setzens der Blockgröße im Rahmen einer Abfrage „if (SIFSRequest (iCntr) ! = 0)" codiert.
Danach wird ein Schritt S4 ausgeführt, bei dem ein Zustandsmodell gesetzt wird, das hier abhängig vom aktuellen Wert des Zählers iCntr ist. Aufbau und Funktionsweise des Zustandsmodells werden im Einzelnen anhand von 3 erläutert. Das Zustandsmodell kann, wie im Beispiel der Funktion Test_Example durch die Folge von Aufrufen der Funktion Scenario. Append erkennbar, aus einer Vielzahl erlaubter Zustandsübergänge aufgebaut werden. Das Zustandsmodell kann insbesondere als verknüpfte Liste oder gerichteter Graph eingegeben und gespeichert werden.
Auf Schritt S4 folgt ein Schritt S5, bei dem eine vorgesehene Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1 vollständig durchgeführt wird. Dabei wird ein Kommando vom Prüfsystem 4 an die Chipkarte 1 und die zugehörige Antwort von der Chipkarte 1 an das Prüfsystem 4 übermittelt.
Bei einem sich gemäß 2 anschließenden Schritt S6 wird die Datenübertragung aufgezeichnet. Die Aufzeichnung umfasst sämtliche Teilschritte der Datenübertragung, d. h. das Kommando, die Antwort und die beim verwendeten Übertragungsprotokoll möglichen Zwischenschritte, die als eine Folge von Übertragungsereignissen aufgezeichnet werden. Dabei werden beispielsweise bei einer Datenübertragung gemäß dem Protokoll T = 1 für jedes Übertragungsereignis die Art des übertragenen Blocks und die Übertragungsrichtung aufgezeichnet.
Bei den Blöcken kann es sich um I-Blöcke, R-Blöcke oder S-Blöcke handeln. Dabei ist ein I-Block ein Informationsblock, der zur transparenten Übertragung von Daten der Anwendungsschicht genutzt wird. Beim R-Block handelt es sich um einen Empfangsbestätigungsblock, der kein Informationsfeld enthält und einer positiven oder negativen Empfangsbestätigung dient. Der S-Block stellt einen Systemblock dar, der für Steuerinformationen genutzt wird, die das Übertragungsprotokoll betreffen. Abhängig von diesen Steuerinformationen kann der S-Block ein Informationsfeld besitzen. Es wird auch aufgezeichnet, ob eine Datenübertragung vom Prüfsystem 4 zur Chipkarte 1 oder von der Chipkarte 1 zum Prüfsystem 4 vorliegt.
Bei einer Variante des Prüfverfahrens erfolgt die Aufzeichnung der Übertragungsereignisse jeweils gleich bei deren Durchführung, so dass die Schritte S5 und S6 gleichzeitig ausgeführt werden. Diese Variante kommt insbesondere dann zur Anwendung, wenn die Daten bezüglich der Übertragungsereignisse danach nicht mehr verfügbar sind.
Die in der Funktion Test_Example aufgerufene Funktion SendCAPDU beispielsweise sendet Kommandoblöcke zur Chipkarte, empfängt entsprechen de Antwortblöcke von der Chipkarte, protokolliert die Blöcke und ruft eine Funktion MatchScenario auf.
Da in diesem Anwendungsbeispiel primär nicht der Inhalt der übertragenen Daten bzw. der Returncode der Chipkarte überprüft werden soll, sondern die Blockfolge in ihrer Konsistenz mit dem Zustandsmodell entsprechend den Vorgaben aus der ISO 7816, werden die Antwortdaten nur optional bzw. der Returncode SW1/2 nur in bekannter Art überprüft.
Anschließend an Schritt S6 wird ein Schritt S7 ausgeführt, bei dem die aufgezeichneten Übertragungsereignisse mit Hilfe des in Schritt S4 gesetzten Zustandsmodells geprüft werden. Das Ergebnis der Prüfung wird gespeichert. Nach Erläuterung eines konkreten Zustandsmodells anhand von 3, wird die Prüfung in Schritt S7 anhand von 4 genauer beschrieben.
Auf Schritt S7 in 2 folgt ein Schritt S8, bei dem der Zähler iCntr auf den nächsten vorgesehenen Wert gesetzt wird. Dann schließt sich ein Schritt S9 an, bei dem geprüft wird, ob der Zähler iCntr kleiner als der Hexadezimalwert FF ist. Ist dies der Fall, so sind noch weitere Prüfbedingungen vorhanden, unter denen die Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1 durchgeführt werden soll. Der Durchlauf des Flussdiagramms wird dann mit Schritt S3 fortgesetzt. Andernfalls wurden bereits alle vorgesehenen Prüfbedingungen berücksichtigt und der Durchlauf des Flussdiagrammsist beendet.
3 zeigt eine Darstellung eines Zustandsmodells für die Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1, das beim erfindungsgemäßen Prüfverfahren zum Einsatz kommen kann. Das Zustandsmodell bildet dabei einen Ausschnitt der Vorgaben für Blockfolgen durch die ISO 7816 ab.
Das Zustandsmodell weist eine Reihe von Zuständen auf, die als Kreise dargestellt sind und jeweils ein zulässiges Übertragungsereignis der Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1 repräsentieren. Jeder Zustand wird durch die Richtung der Datenübertragung und die Art des übertragenen Blocks charakterisiert. Die Richtung der Datenübertragung wird jeweils durch die Angabe des Senders gekennzeichnet. Ein Zustand, der eine Datenübertragung vom Prüfsystem 4 zur Chipkarte 1 repräsentiert, wird somit durch die Abkürzung IFD gekennzeichnet. Eine Datenübertragung in umgekehrter Richtung wird durch die Abkürzung ICC kenntlich gemacht. Bei den übertragenen Blöcken kann es sich jeweils um einen I-Block, einen R-Block oder einen S-Block handeln. Dementsprechend ist jeder Zustand zusätzlich zur Angabe des Senders mit einem I, R oder S bezeichnet. Die Blöcke sind zum Teil durch einen Klammerausdruck hinter der Blockbezeichnung näher charakterisiert, auf dessen Bedeutung jeweils im Folgenden bei der Erläuterung der einzelnen Zustände noch eingegangen wird.
Als weitere Bestandteile des Zustandsmodells sind zwischen einigen der Zustände Übergänge vorgesehen, die jeweils durch einen Pfeil dargestellt sind. Die Pfeile geben jeweils die Richtung der Übergänge an. Es sind nur solche Abfolgen von Zuständen mit dem Zustandsmodell vereinbar, die sich mit den im Zustandsmodell vorgesehenen Übergängen rekonstruieren lassen.
In 3 sind insgesamt sechs Zustände dargestellt, wobei die Datenübertragung mit einem Zustand IFD I(x, 0) startet. Der Klammerausdruck (x, 0) enthält dabei zusätzliche Informationen bezüglich des I-Blocks, die insbesondere dann benötigt werden, wenn Informationen auftreten können, die so lang sind, dass sie nicht mit einem einzigen I-Block übertragen werden können. Der Parameter x steht zunächst für beliebige Daten, welche aktuell mit dem I-Block übertragen werden. Der Wert 0 zeigt an, dass kein weiterer Teil der Information mehr folgt, also keine Verkettung (Chaining) von Blöcken erfolgt. Der Zustand IFD I(x, 0) repräsentiert somit die vollständige Übertragung eines Kommandos vom Prüfsystem 4 zur Chipkarte 1.
Ausgehend von diesem Zustand existieren ein Übergang U1 zu einem Zustand ICC I(x, 0), ein Übergang U2 zu einem Zustand ICC I(x, 1) und ein Übergang U3 zu einem Zustand ICC S(WTX req.). Der Zustand ICC I(x, 0) bezieht sich auf die Übertragung des letzten Teils x einer Antwort als I-Block von der Chipkarte 1 zum Prüfsystem 4, d. h. es folgt kein weiterer Teil der Antwort. Dabei kann dieser letzte Teil auch die vollständige Antwort darstellen, wenn diese ausreichend kurz ist. Mit dem Zustand ICC I(x, 0) endet die Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1. Es besteht somit die Möglichkeit, dass bei der Datenübertragung lediglich die beiden Zustände IFD I(x, 0) und ICC I(x, 0) durchlaufen werden. Es kann aber auch eine Reihe weiterer Zustände beteiligt sein.
Der Zustand ICC I(x, 1) repräsentiert die Übertragung eines Teils der Antwort von der Chipkarte 1 an das Prüfsystem 4, wobei durch den Wert 1 angezeigt wird, dass danach noch wenigstens ein weiterer Teil der Antwort zu übertragen ist. Dieser Zustand kann beispielsweise im Rahmen des Testablaufes erzwungen werden, indem für das Kommando „Lese Daten der Länge 1 aus der Chipkarte" die Blockgröße IFS der Chipkarte kleiner als die Länge der Daten gewählt wird.
Beim Zustand ICC S(WTX req.) steht WTX req. für Waiting Time Extension request, d. h. bei diesem Zustand wird mittels eines S-Blocks von der Chipkarte 1 beim Prüfsystem 4 eine Wartezeitverlängerung angefordert. Eine derartige Anforderung wird dann erfolgen, wenn die Chipkarte 1 innerhalb der ursprünglich vorgesehenen Wartezeit keine Antwort auf das vom Prüfsystem 4 empfangene Kommando liefern kann.
Vom Zustand ICC I(x, 1) besteht ein Übergang U4 zu einem Zustand IFD R, der eine Aufforderung des Prüfsystems 4 an die Chipkarte 1 darstellt, den nächsten Teil der Antwort zu senden. Vom Zustand ICC S(WTX req.) besteht ein Übergang U5 zu einem Zustand IFD S(WTX res.). Dieser Zustand repräsentiert die Übertragung einer Bestätigung vom Prüfsystem 4 an die Chipkarte 1 als Reaktion auf die Wartezeitanforderung der Chipkarte 1. WTX res. steht dabei für Waiting Time Extension response.
Vom Zustand IFD R bestehen ein Übergang U6 zum Zustand ICC I(x, 1), ein Übergang U7 zum Zustand ICC S(WTX req.) und ein Übergang U8 zum Zustand ICC I(x, 0). Vom Zustand IFD S(WTX res.) bestehen ein Übergang U9 zum Zustand ICC S(WTX req.), ein Übergang U10 zum Zustand ICC I(x, 1) und ein Übergang U11 zum Zustand ICC I(x, 0).
Bei dem in 3 dargestellten Zustandsmodell kann noch insofern differenziert werden, dass ein Übergang oder mehrere Übergänge in bestimmten Fällen nicht zugelassen werden. Beispielsweise können die Übergänge U7 und/oder U9 unter bestimmten Prüfbedingungen gestrichen werden oder dann nicht mehr zugelassen werden, wenn vom Prüfsystem 4 bereits wenigstens zwei Teile der Antwort empfangen wurden. Dies bedeutet, dass in diesem Fall keine Wartezeitanforderung der Chipkarte 1 mehr zugelassen wird.
Neben dem direkten Übergang U1 vom Zustand IFD I(x, 0) zum Zustand ICC I(x, 0) existieren weitere Pfade, die aus mehreren Übergängen zusammengesetzt sind und dementsprechend über mehrere Zustände verlaufen. Auch diese weiteren Pfade stehen jeweils für eine ordnungsgemäße Durch führung der Datenübertragung zwischen dem Prüfsystem 4 und der Chipkarte 1, wenn sie ausschließlich von den im Zustandsmodell vorgesehenen Zuständen und Übergängen Gebrauch machen.
Bei der Prüfung gemäß Schritt S7 des in 2 dargestellten Flussdiagramms muss somit ermittelt werden, ob durch die in Schritt S6 aufgezeichnete Folge von Übertragungsereignissen bei Berücksichtigung ihrer Reihenfolge ein Pfad durch das Zustandsmodell ausgebildet wird. Mit anderen Worten, es ist zu prüfen, ob die aufgezeichnete Folge von Übertragungsereignissen eine mit dem Zustandsmodell vereinbare Abfolge von Zuständen darstellt.
Zur Durchführung dieser Prüfung wird die aufgezeichnete Folge der Übertragungsereignisse im Zustandsmodell nachvollzogen. Hierzu wird zunächst der zum ersten aufgezeichneten Übertragungsereignis korrelierende Zustand des Zustandsmodells ermittelt. Dabei handelt es sich hier um den Zustand IFD I(x, 0). Dann wird der zum zweiten aufgezeichneten Übertragungsereignis korrelierende Zustand des Zustandsmodells ermittelt, und geprüft ob im Zustandsmodell ein Übergang vom vorhergehenden Zustand zu diesem Zustand vorgesehen ist. Fehlt ein solcher Übergang, so ist die Datenübertragung, für welche die Übertragungsereignisse aufgezeichnet wurden, nicht mit dem Zustandsmodell vereinbar. Falls weitere aufgezeichnete Übertragungsereignisse vorhanden sind, werden in analoger Weise die korrelierenden Zustände des Zustandsmodells ermittelt und es wird jeweils geprüft, ob im Zustandsmodell entsprechende Übergänge vorgesehen sind. Wenn auf diese Weise der Zustand ICC I(x, 0) für das letzte aufgezeichnete Übertragungsereignis erreicht wird und hierzu ausschließlich die im Zustandsmodell vorgesehenen Übergänge beschritten wurden, ist nachgewiesen, dass die Datenübertragung, deren Übertragungsereignisse aufgezeichnet wurden, fehlerfrei abgelaufen ist. Stellt die Folge der aufgezeichneten Übertragungsereignisse dagegen keinen Pfad durch das Zustandsmodell dar, so ist bei der Datenübertragung ein Fehler aufgetreten und es wird eine Fehlermeldung ausgegeben. Die Fehlermeldung kann insbesondere auch Informationen darüber enthalten, welches der aufgezeichneten Übertragungsereignisse nicht mit dem Zustandsmodell vereinbar und damit fehlerhaft ist.
Wie aus dem Programmlisting der Funktion Test_Example hervorgeht, ist der Programmieraufwand für das Zustandsmodell relativ gering. Das Zustandsmodell kann als ein Satz von Regeln programmiert werden, die jeweils einen Zustand und einen möglichen Folgezustand angeben, so dass jede Regel einen im Zustandsmodell vorgesehenen Übergang definiert. Beispielsweise wird der Übergang U4 des in 3 dargestellten Zustandsmodells durch die Programmzeile Scenario.Append („ICC I(x, 1)", „IFD R"); repräsentiert. Für die weiteren Übergänge sind weitere Programmzeilen vorgesehen, wobei in einigen Programmzeilen Variable verwendet werden, so dass diese Programmzeilen mehrere Übergänge repräsentieren können. Auf diese Weise ist das gesamte Zustandsmodell gemäß 3 programmiert, allerdings ohne den Übergang U7. Das Programmlisting bezieht sich somit auf einen der bereits erwähnten Fälle, bei denen der Übergang U7 nicht vorgesehen ist.
Die Funktion Matchscenario arbeitet die verknüpfte Liste der protokollierten Blöcke (History) ab und ruft für jeden protokollierten Block die Funktion IsInScenario auf.
Für den Fachmann ist erkennbar, dass der Vergleichsoperator "==" für diesen Zweck entsprechend angepaßt werden muss, denn eine Beschreibung eines Blocks ist mit einem protokollierten Block zu vergleichen. Ohne auf die Umsetzung tiefer einzugehen wird ein Programmierungsbeispiel eines solchen Vergleichsoperators im Folgenden angegeben.
Mit Hilfe des Zustandsmodells können auch extrem komplexe Datenübertragungen oder sonstige Abläufe, an denen die Chipkarte 1 beteiligt ist, geprüft werden. Zur Prüfung verschiedenartiger Abläufe ist nicht die gesamte Prüfsoftware zu ändern, sondern es muss lediglich das jeweils verwendete Zustandsmodell angepasst werden.
In den bisher gezeigten Ausführungsbeispielen werden protokollierte Blockpaare als Zustandsübergänge auf Konsistenz mit einem in einer verketteten Liste abgelegten Modell geprüft. Zusätzlich können vorbestimmte erlaubte Pfade durch das Zustandsmodell verwendet werden und als weiteres Kriterium geprüft werden.
Mit Bezug auf die 4 und 5 wird eine optimierte Möglichkeit beschrieben, die Ergebnisse einer Aufzeichnung der Kommunikation zwischen Karte und Kartenleser gegenüber einem hinterlegten Zustandsmodell zu prüfen.
In den bisher beschriebenen Varianten wurden in dem Zustandsmodell zulässige Ereignisse als Zustände und das zulässige Aufeinanderfolgen je zweier Ereignisse als Übergänge definiert. Alternativ können im Zustandsmodell auch die im Rahmen des Prüfdurchlaufs auftretenden Systemzustände als Zustände und die zulässigen Ereignisse als Übergänge definiert werden. Diese alternative Abbildung des Systems in das Zustandsmodell und deren Folgen für eine mögliche Implementierung des Prüfsystems werden anhand der 4 und 5 näher erläutert.
4 zeigt in einer modifizierten Darstellungsform ein Zustandsmodell für einen Teil der Übergänge aus dem Zustandsmodell gemäß 3.
Für Zustände Z0 bis Z3 gibt es Zustandsübergänge Ba bis Bd, die jeweils einem empfangenen Kommandoblock oder einem gesendeten Antwortblock der zu testenden Karte entsprechen. Das Modell aus 4 entspricht inhaltlich dem System, das in der rechten Hälfte von 3 dargestellt ist.
Im einzelnen ist Z0 der Ausgangszustand und Z1 der Endzustand einer Kommunikation zwischen Karte und Kartenleser. Im einfachsten Fall sendet der Kartenleser ein Kommandoblock Ba an die Karte und die Karte antwortet mit einem Antwortblock Bb, so dass das System aus dem Anfangszustand Z0, über den ersten Zwischenzustand Z2 direkt in den Endzustand Z1 übergeht. Die zu testende Karte darf auf das Kommando Ba des Kartenlesers aber auch eine Verlängerung der Wartezeit Bc (WTX) anfordern, welche dann durch den Kartenleser durch eine entsprechende Bestätigung Bd zu quittie ren wäre. Aus dem ersten Zwischenzustand Z2 kann das System somit beliebig oft zu dem zweiten Zwischenzustand Z3 und wieder zurück wechseln.
In 5 sind die Datenelemente dargestellt, die eine effiziente Prüfung der aufgezeichneten Kommunikation zwischen Karte und Kartenleser gegenüber dem Zustandsmodell ermöglichen.
Ein Zustandsmodell wird in dem Prüfungssystem durch eine Matrix der Zustandsübergänge 41 sowie eine Referenzliste der Sollwerte 42 dargestellt. In der dargestellten Form sind für die Matrix der Zustandsübergänge 41 in der ersten (optionalen) Spalte die möglichen Ausgangszustände Z0 bis Z3 und in der ersten (optionalen) Zeile die möglichen Folgezustände Z0 bis Z3 enthalten. Die Matrix 41 besteht in einer speicheroptimierten Ausführungsform aus einer reinen Blocktypmatrix, die nicht die erste Zeile und die erste Spalte gemäß der Darstellung in 5 enthält. In der Matrix codiert die Zeile einer Matrixposition den Ausgangszustand, die Spalte einer Matrixposition den Folgezustand und der Matrixwert sowohl die Möglichkeit des Übergangs als auch den zugehörigen Sollwert (Ereignis).
Wenn von einem Ausgangszustand ein Übergang zu einem Folgezustand erlaubt ist, enthält die entsprechende Matrixposition einen Matrixwert als Verweis in die Referenzliste 42. Der Matrixwert codiert sowohl, dass ein Zustandsübergang möglich ist, als auch den zugehörigen Sollwert, also in dem vorliegenden Fall den für den Übergang nötigen Blocktyp Ba bis Bd. Der Matrixwert kann im einfachsten Fall ein Index in die Referenzliste 42 sein. Beispielsweise verweisen Matrixwerte „1" oder „3" auf den ersten respektiven dritten Eintrag der Referenzliste 42. Ist dagegen kein Übergang zwischen den durch die Matrixposition vorgegebenen Zuständen möglich, so enthält die entsprechende Matrixposition keinen Eintrag bzw. den Defaultwert der Matrix beispielsweise den Wert „0".
Die Referenzliste der Sollwerte 42 ist hier als Tabelle mit einer optionalen ersten Spalte der Referenzwerte dargestellt. Sie enthält für jeden Referenzwert die Angaben eines Blocktyps Ba bis Bd, der dem System den Vergleich zwischen aufgezeichnetem Blocktyp als Istwert und erlaubten Blocktyp als Sollwert ermöglicht.
Diese Darstellungsform des Zustandsmodells ist nicht nur im Hinblick auf den Speicherplatzverbrauch effizient, sondern erlaubt auch eine schnelle Überprüfung, ob das Zustandsmodell durch eine jeweils aufgezeichnete Kommunikation eingehalten wurde.
Um eine Liste der aufgezeichneten Kommunikation 45 (Istwertliste) zwischen Karte und Kartenleser mit dem Zustandsmodell – codiert in der Matrix 41 und der Referenzliste 42 – zu vergleichen, werden zumindest ein aktueller Zustand 46 und ein aktueller Prüfungsgegenstand 47 als weitere Datenelemente verwendet. Beispielsweise kann der aktuelle Zustand 46 als Zeiger auf die entsprechende Zeile der Matrix 41 und der aktuelle Prüfungsgegenstand 47 als Verweis auf das aktuell zu prüfende, aufgezeichnete Kommando in der zu prüfenden Liste der aufgezeichneten Kommunikation 45 verwaltet werden.
Das Prüfsystem durchläuft für den jeweils aktuellen Zustand 46 spaltenweise die Matrix 41. Wird in einer Spalte erkannt, daß ein Zustandsübergang möglich ist, überprüft das System, ob sich aus dem Verweis in die Referenzliste 42 an der Matrixposition ein Sollwert, hier in Form eines Blocktyps, er gibt, der dem aktuelle Prüfungsgegenstand 47 in der Istwertliste 45 entspricht.
Fällt diese erste Prüfung positiv aus, so wird der aktuelle Zustand 46 auf den durch die Spalte der Matrixposition codierten neuen Folgezustand gesetzt. In der Istwertliste 45 kann mit der Prüfung des nächsten aufgezeichneten Blocktyps als neuem, aktuellem Prüfungsgegenstand 47 fortgefahren werden.
Fällt dagegen diese erste Prüfung negativ aus, so bleibt der aktuelle Prüfungsgegenstand 47 unverändert und in der Matrix 41 wird für den aktuellen Zustand 46 die nächstfolgende Spalte überprüft. Erst wenn das Prüfsystem für die aktuellen Zustand 46 alle Spalten der Matrix erfolglos (keine Übereinstimmung der Blocktypen oder kein Übergang) durchlaufen hat, wird – für den aktuellen Prüfungsgegenstand 47 und den aktuellen Zustand 46 -vermerkt, dass die Prüfung einen Fehler entdeckt hat.
In der in 5 dargestellten Situation, ist die in der Istwertliste 45 zum Zeitpunkt t1 aufgezeichnete Anfrage einer Wartezeitverlängerung der Karte (ICC S(WTX)) der aktuelle Prüfungsgegenstand 47. Der aktuelle Ausgangszustand 46 ist Z2. Die Überprüfung des Blocktyps für den Folgezustand Z1, mit dem Sollwert Bb, fällt negativ aus. Erst die Prüfung für den Folgezustand Z3, ergibt, dass der mögliche Blocktyp Bc als Sollwert dem aufgezeichneten Blocktyp des Prüfungsgegenstandes 47 entspricht.
Es gibt zu testende Systeme, in denen zwischen zwei Systemzuständen zwei unterschiedliche Übergänge erlaubt sind. Es ist eine erste Möglichkeit, in dem Zustandsmodell zwischen den zwei Zuständen auch zwei mögliche Übergänge zu definieren und diese Situation in der Zustandsmatrix dadurch abzubilden, daß die Matrix mehrdimensional ausgestaltet ist. Ein Datenelement zur Verwaltung des aktuellen Zustands müsste in diesem Fall nicht nur eine Zeile für den aktuellen Zustand, sondern auch einen Index für die aktuelle Ebene innerhalb der mehrdimensionalen Matrix enthalten. Alternativ oder ergänzend zu einer mehrdimensionalen Matrix ist es eine zweite Möglichkeit, bei der Darstellung des Zustandsmodells aus den beiden an sich gleichen Systemzuständen unterschiedliche Folgezustände zu machen zumindest sofern es für die Überprüfung des Systems notwendig ist. Der Zustand wird somit auch hinsichtlich seiner Historie, d. h. auf welchem Weg er erreicht wurde, eindeutig.

Claims

Verfahren in einem Prüfsystem (4) zum Prüfen eines tragbaren Datenträgers (1), der einen integrierten Schaltkreis (2) zur Speicherung und/oder Verarbeitung von Informationen aufweist, wobei der tragbare Datenträger (1) wenigstens einem Prüfdurchlauf unterzogen wird, bei dem Daten bezüglich einer zu prüfenden Funktionalität des tragbaren Datenträgers (1) erfasst werden, dadurch gekennzeichnet, dass die erfassten Daten wenigstens teilweise mittels eines Zustandsmodells geprüft werden, das eine Reihe von Zuständen und von erlaubten Übergängen zwischen den Zuständen aufweist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei der Prüfung ermittelt wird, ob die erfassten Daten einer Abfolge von Zuständen entsprechen, die mit dem Zustandsmodell vereinbar ist.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Abfolge von Zuständen mit dem Zustandsmodell vereinbar ist, wenn sie ausschließlich aus Zuständen und Übergängen zusammengesetzt ist, die im Zustandsmodell vorgesehen sind.
Verfahren nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet, dass auf einen fehlerfreien Prüfdurchlauf geschlossen wird, falls die erfassten Daten einer Abfolge von Zuständen entsprechen, die mit dem Zustandsmodell vereinbar ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die beim Prüfdurchlauf erfassten Daten aufgezeichnet werden und nach der Aufzeichnung aller beim Prüfdurchlauf erfassten Daten die Prüfung anhand der aufgezeichneten Daten durchgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mehrere unterschiedliche Prüfdurchläufe durchgeführt werden.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass vor oder bei dem ersten Prüfdurchlauf Vorbedingungen für mehrere Prüfdurchläufe gesetzt werden.
Verfahren nach einem der Ansprüche 6 oder 7, dadurch gekennzeichnet, dass vor oder bei jedem Prüfdurchlauf wenigstens eine für diesen Prüfdurchlauf vorgesehene Prüfbedingung gesetzt wird.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass wenigstens ein Parameter (iCntr) systematisch variiert wird und die jeweilige Prüfbedingung auf Basis dieses Parameters (iCntr) gesetzt wird.
Verfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass vor oder bei jedem Prüfdurchlauf das für diesen Prüfdurchlauf vorgesehene Zustandsmodell gesetzt wird.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass das Zustandsmodell auf Basis des Parameters (iCntr) gesetzt wird, der auch beim Setzen der Prüfbedingungen verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass geprüft wird, ob die Datenübertragung zwischen dem tragbaren Datenträger (1) und dem Prüfsystem (4) korrekt abgewickelt wird.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass geprüft wird, ob ein vorgegebenes Übertragungsprotokoll eingehalten wird.
Verfahren nach einem der Ansprüche 12 oder 13, dadurch gekennzeichnet, dass die erfassten Daten jeweils die Richtung der Datenübertragung und wenigstens eine Information zu den übertragenen Daten enthalten.
Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass die Information sich auf die Art der jeweils übertragenen Daten bezieht.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zustände im Rahmen des Prüfdurchlaufs zulässige Zustände des Systems aus tragbarem Datenträger und Prüfsystem repräsentieren und die Übergänge zulässige übertragene Daten repräsentieren.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine verkettete Liste oder ein gerichteter Graph als das Zustandsmodell verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Zustandsmodell im Prüfsystem als Matrix von Zustandsübergängen 41 und zugeordneter Referenzliste der Sollwerte 42 abgebildet wird.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die Matrix von Zustandsübergängen 41 in Matrixpositionen, für die ein Zustandsübergang erlaubt ist, als Matrixwert einen Verweis in die Referenzliste der Sollwerte 42 enthält.
Verfahren nach Anspruch 18 oder 19, dadurch gekennzeichnet, dass ein aus der Matrix von Zustandsübergängen 41 und der zugeordneten Referenzliste der Sollwerte 42 bestimmter Sollwert mit einem Istwert aus einer aufgezeichneten Istwertliste verglichen wird.
Verfahren nach einem der Ansprüche 18 bis 20, dadurch gekennzeichnet, dass in der Matrix der Zustandsübergänge 41 die Zeile und die Spalte der Matrixposition Ausgangs- und Folgezustand codieren.
Prüfsystem zum Prüfen eines tragbaren Datenträgers (1) in wenigstens einem Prüfdurchlauf, bei dem Daten bezüglich einer zu prüfenden Funktionalität des tragbaren Datenträgers (1) erfasst werden, dadurch gekennzeichnet, dass zur wenigstens teilweisen Prüfung der erfassten Daten ein Zustandsmodell implementiert ist, das eine Reihe von Zuständen und von erlaubten Übergängen zwischen den Zuständen aufweist, wobei die Zustände im Rahmen des Prüfdurchlaufs zulässige Ereignisse und die Übergänge zulässige Aufeinanderfolgen je zweier Ereignisse repräsentieren.
Prüfsystem nach Anspruch 22, dadurch gekennzeichnet, dass das Zustandsmodell mittels einer Reihe von Regeln implementiert ist, die jeweils einen Zustand und einen Folgezustand angeben.