DE60213632T2

DE60213632T2 - Byte-übertragungsverwaltung in einer chipkarte

Info

Publication number: DE60213632T2
Application number: DE60213632T
Authority: DE
Inventors: Jose Mennecart; Christophe Gien
Original assignee: Axalto SA
Current assignee: Axalto SA
Priority date: 2001-10-10
Filing date: 2002-10-10
Publication date: 2007-10-18
Anticipated expiration: 2022-10-11
Also published as: WO2003032244A1; EP1435066A1; ATE335252T1; JP2005525615A; KR20040045495A; DE60213632D1; CN1568482A; US20040238646A1; KR100960859B1; CN100423025C; EP1435066B1

Description

Technisches Umfeld
Diese Erfindung betrifft die Verwaltung der Byteweisen Übertragung in einer Smartkarte. Das gewählte Beispiel zur Erläuterung der Erfindung betrifft die Übertragung einer als ATR (Answer-To-Reset) bekannten Rückmeldung, die in den Normen der ISO (International Standardisation Organisation) 7816-3 und 7816-4 definiert wird. Diese Nachricht wird von der Smartkarte an das Kartenlesegerät, mit dem es verbunden ist, übermittelt, wenn die Smartkarte vom Lesegerät eingeschaltet wird.
Es sei darauf hingewiesen, dass in Verbindung mit der Erfindung ein Lesegerät eine Vorrichtung ist, welche Informationen mit der Smartkarte austauschen kann.
Stand der Technik
Im Allgemeinen besteht die Einschaltung der Karte in der Durchführung einer Aktion, die vom Mikroprozessor als eine Unterbrechung empfangen wird. Diese Aktion wird im Allgemeinen „RESET" genannt. Sie umfasst einen Unterbrechungsvektor oder eine Codesequenz, die sich an einer bestimmten Adresse im Speicher befindet. Diese Adresse enthält im Allgemeinen auch einen Sprungbefehl zu einer Startsequenz.
Die Kommunikation mit einer Smartkarte erfolgt über ein Lesegerät. Es ist zu erwähnen, dass die Norm ISO 7813-3 das von den Karten zur externen Kommunikation einzusetzende Kommunikationsprotokoll definiert. Dieser Abschnitt beschreibt die elektrischen Signale und die Informationen, die bei allen Kommunikationen ausgetauscht werden. Die Ströme, Spannungen und Signalfrequenzen sind standardisiert, das Gleiche gilt für das Format der Daten, die bei einer Kommunikation zwischen einer Karte und einem Kartenlesegerät ausgetauscht werden.
Wenn die Smartkarte eingeschaltet wird, überträgt sie eine Nachricht an das Lesegerät. Diese Nachricht von der Karte beim Startvorgang heißt normalerweise ATR (Answer-to-Reset) in Übereinstimmung mit den Normen OSI 7816-3 und 7816-4. Diese Nachricht umfasst Informationen, die dem Lesegerät insbesondere die Fähigkeiten der Smartkarte in Bezug auf die Kommunikationsprotokolle anzeigen. So gibt beispielsweise die Karte dem Lesegerät Folgendes an:

– den Protokolltyp (T = 0, T = 1, usw.)
– die Übertragungsgeschwindigkeit (z. Beisp. 9600 Baud, 38400 Baud, usw.)
– die Zeitabschaltung bei der Befehlausführung
– usw.

Die ATR-Nachricht umfasst auch historische Informationen. Diese Informationen enthalten die Produktidentifikation, die Version, die Art des verwendeten Chips, den Zustand der Karte, usw.
Die ATR-Nachricht besteht aus einer Anzahl Bytes. In den meisten Smartkarten mit Mikrokontroller werden die Bytes in dieser Nachricht nacheinander übertragen. Da im Allgemeinen die Betriebssysteme der Karten immer komplexer werden und die Sicherheit immer mehr an Bedeutung gewinnt, muss das Betriebssystem bei der Übertragung einer ATR-Nachricht eine bestimmte Anzahl Verarbeitungsvorgänge durchführen, bevor es die Kontrollübernahme durch den Benutzer zulässt. Konkret bedeutet dies, dass das Betriebssystem ein erstes Byte des ATR übermittelt und dann einen ersten Verarbeitungsvorgang durchführt. Nach diesem Verarbeitungsvorgang übermittelt das Betriebssystem ein zweites Byte und führt dann einen zweiten Verarbeitungsvorgang durch. Nach diesem zweiten Verarbeitungsvorgang übermittelt das Betriebssystem ein drittes Byte und so weiter. Die Verarbeitungsvorgänge können mehr oder weniger komplex sein und unterschiedliche Ausführungszeiten aufweisen. Aufgrund dieser veränderlichen Ausführungszeit ist es deshalb sehr schwierig, den Zeitabstand zwischen jeder einzelnen Byte-Übermittlung in einer ATR-Nachricht zu bestimmen.
Es gibt jedoch Normen, die insbesondere Folgendes definieren:

– einen maximalen nicht überschreitbaren Zeitabstand zwischen den Übermittlungen zweier Bytes in der ATR-Nachricht,
– eine maximale Gesamtdauer für die ATR-Nachricht, die nicht überschritten werden darf.

Diese Normen müssen eingehalten werden, damit das Lesegerät mit der Smartkarte kommunizieren kann. Wenn diese Zeitabstände nicht eingehalten werden, gelingt es dem Lesegerät nicht, die Karte zu erkennen und meistens wirft ein im Lesegerät enthaltener Mechanismus die Karte aus dem Gehäuse. Der Kartenauswurf stellt für den Kartenbenutzer einen Nachteil dar.
Diese Art bekannter Technik zum Senden einer ATR-Nachricht wie obig beschrieben wird insbesondere in EP 88 159 beschrieben.
Kurze Zusammenfassung der Erfindung
Ein Ziel ist deshalb die Erzielung einer größeren Zufriedenheit des Kartennutzers.
Zur Erreichung dieses Ziels wird erfindungsgemäß eine Smartkarte wie in Anspruch 1 beschrieben vorgeschlagen.
Das externe Modul fungiert als Assistent, indem es das Betriebssystem überwacht. In seiner Assistentenrolle kann es das Betriebssystem zwingen, die Byte-Übermittlung auszulösen. Die Folge ist eine bessere Einhaltung der Zeitabstände zwischen den einzelnen Bytes. Die Erfindung vermeidet deshalb den Auswurf der Karte, was zu einer höheren Zufriedenheit des Kartennutzers führt.
Die Erfindung wird leichter verständlich, wenn man die nachfolgende Beschreibung, die als Beispiel aufgeführt wird und Bezug auf die beigefügten Zeichnungen nimmt, liest.
In den Zeichnungen:
ist Bild 1 eine Diagrammansicht der Architektur, auf welche die Erfindung angewandt werden kann,
ist Bild 2 eine Diagrammansicht einer Smartkarte, wobei diese Architektur insbesondere das externe Modul des Betriebssystems zeigt.
sind Bild 3A und 3B Algorithmen zur Erläuterung der einzelnen Schritte eines ersten Ausführungsbeispiels.
ist Bild 4 eine Diagrammansicht des Informationsflusses, der sich aus diesem ersten Ausführungsbeispiel ergibt, und es erläutert den erfindungsgemäßen Informationsaustausch zwischen einem Karten-Lesegerät, dem Betriebssystem und dem externen Modul.
ist Bild 5 ein Algorithmus zur Erläuterung einer Variante dieses ersten Ausführungsbeispiels.
ist Bild 6 eine Diagrammansicht des Informationsflusses, der sich aus der Variante dieses ersten Ausführungsbeispiel ergibt, und es erläutert den Informationsaustausch zwischen dem Karten-Lesegerät, dem Betriebssystem und dem externen Modul.
ist Bild 7 ein Algorithmus zur Erläuterung eines zweiten Ausführungsbeispiels der Erfindung, in dem das externe Modul ein Software-Agent ist.
Ausführliche Beschreibung der Beispiele zur Erläuterung der Erfindung
Zur Vereinfachung der Beschreibung sind die selben in den Zeichnungen erläuterten Elemente mit den gleichen Nummern beschriftet.
Bild 1 zeigt ein System SYS, auf welches die Erfindung angewandt werden kann. Dieses System SYS umfasst eine Smartkarte CAR und ein Smartkarten-Lesegerät LEC, welche über Kommunikationsverbindungen LIA miteinander verbunden sind. Die Kommunikations-Nachrichten werden über diese Verbindungen geleitet, wobei sie vorzugsweise ein Format in Übereinstimmung mit der Norm ISO 7186-4 benutzen.
Bild 2 zeigt eine Diagrammansicht der Architektur einer Smartkarte CAR. Die Smartkarte CAR umfasst ein elektronisches Modul MOD. Das Modul MOD enthält einen Mikrokontroller MIC und Kontakte zur externen Kommunikation. Im Allgemeinen enthält ein Mikrokontroller:

– eine Mikroprozessor CPU zur Ausführung der Befehle,
– nichtflüchtige Speicher ROM (Lesespeicher), deren Inhalt im Werk eingebrannt wird und deshalb nicht verändert werden kann. Ein Verschlüsselungs-Algorithmus, das Betriebssystem SE, Schnittstellen zum Programmieren der Anwenderprogramme (API), usw. können deshalb im ROM-Speicher geschrieben werden,
– nichtflüchtige Speicher, zum Beispiel EEPROM (elektrisch löschbarer programmierbarer Lesespeicher). Er dient im Allgemeinen zum Aufbewahren kartenspezifischer Daten, wie beispielsweise die Identität des Kartenbesitzers, die Zugriffsrechte auf Dienstleistungen, die Dateisysteme, alle Anwenderprogramme der Karte, usw.,
– flüchtige Speicher RAM, Arbeitsraum zur Ausführung der Kartenbefehle,
– Sicherheitseinheiten CRYP zur Datenverschlüsselung,
– Einheiten zur Berücksichtigung der Versorgungsspannung, Taktgeschwindigkeit, usw.
– einen Ein-/Ausgabeport vom Typ UART (Universal Asynchronous Receiver Transmitter) beispielsweise, der den Fachleuten zur Kommunikation zwischen der Karte CAR und dem Lesegerät LEC bekannt ist,
– eine Reihe von Bussen BUS, welche die einzelnen Teile zum Daten-, Adressen- und Befehlsaustausch miteinander verbinden.

Das Modul umfasst auch Kontakte zur Kommunikation mit dem Lesegerät, insbesondere:

– Ein-/Ausgabe-Kontakte I/O,
– elektrische Kontakte VCC und VPP und elektrische Masse GND (der elektrische Kontakt VPP dient im Allgemeinen zur Lieferung einer Spannung für die Programmierung, während der Kontakt VCC zur Stromversorgung der Karte dient),
– ein Kontakt RES zum Reset der Karte oder zu ihrer Einschaltung.

Das Betriebssystem hat einen Befehlssatz, den es nach einer Aufforderung ausführen kann. Es verwaltet die externe Kommunikation mit Hilfe eines standardisierten und gesicherten Kommunikationsprotokolls. Die erteilten Befehle werden vom Betriebssystem vor ihrer Ausführung bestätigt.
Wenn die Karte CAR eingeschaltet wird, übermittelt sie eine Nachricht an das Lesegerät LEC. Diese Nachricht wird im Allgemeinen ATR (Answer-To-Reset) genannt. Diese ATR-Nachricht besteht normalerweise aus einer Anzahl Bytes.
Das bereits in der Einführung erwähnte Problem betrifft den Zeitabstand zwischen zwei Byte-Übermittlungen in der ATR-Nachricht.
Gemäß einem ersten Ausführungsbeispiel besteht die Lösung aus dem Einsatz einer Zeitgebervorrichtung wie beispielsweise einem programmierbaren Taktgeber TIM (Timer). Ein programmierbarer Taktgeber ist eine Schaltung mit einem Taktgeber, welche an jedem „n"-ten Taktzyklus Unterbrechungssignale erzeugt. Dieser Taktgeber gilt als programmierbarer, da seine Taktfrequenz verändert werden kann.
Der programmierbare Taktgeber TIM ist in der Smartkarte CAR enthalten.
Zur Erläuterung der Erfindung, und zum leichteren Verständnis, nehmen wir Bezug auf die Schritte der Algorithmen ALG1 und ALG2 auf den Bildern 3A bzw. 3B.
Diese beiden Algorithmen ALG1 und ALG2 stehen in Wechselwirkung untereinander. Anders gesagt bedeutet dies, wenn das Betriebssystem Verarbeitungsvorgänge durchführt, kann der Algorithmus ALG1 jederzeit durch eine durch den programmierbaren Taktgeber ausgelöste Unterbrechung unterbrochen werden, so dass die ATR-Bytes übermittelt werden können.
In unserem Ausführungsbeispiel umfasst der erste Algorithmus ALG1 folgende Hauptschritte:

– Ein erster Schritt ET11 besteht im Einschalten der Karte.
– In einem zweiten Schritt ET21 aktiviert das Betriebssystem den programmierbaren Taktgeber TIM, so dass dieser Unterbrechungen zur Übermittlung von ATR-Bytes auslöst.
– In einem dritten Schritt ET31 führt das Betriebssystem eine Reihe von Verarbeitungsschritten (T1–Tn) durch. In unserem Beispiel bezeichnet der Parameter „n" die Anzahl der durchzuführenden Verarbeitungsvorgänge.

Die Schritte ET21 und ET31 können in beliebiger Reihenfolge durchgeführt werden. Es liegt nahe, dass weitere Schritte implementiert werden können. Zum Beispiel muss die Aktivierung nicht direkt nach dem Einschaltvorgang erfolgen. Zwischen den Schritten ET11 und ET31 können Verarbeitungsschritte eingeplant werden.
Der zweite Algorithmus ALG2 erläutert die Schritte zur Übermittlung der ATR-Bytes Oj(j = 1, ..., m). Dieser Algorithmus ALG2 wird nach der Aktivierung im zweiten Schritt ET12 des ersten Algorithmus implementiert. Dieser Algorithmus ALG2 ist eine Programmschleife mit den nachfolgenden Schritten:

– In einem ersten Schritt ET12 löst der programmierbare Taktgeber eine Unterbrechung I1 aus, die das Betriebssystem unterbrechen kann. Das Betriebssystem unterbricht seine laufende Arbeit, zum Beispiel einen laufenden Verarbeitungsvorgang (T1–Tn), falls dieser bereits gestartet worden ist.
– Im Schritt ET22 springt das Betriebssystem nach Empfang der Unterbrechung I1 zu einer zur Übertragung von ATR-Bytes vorgesehenen Codesequenz und startet die Übertragung eines ersten ATR-Bytes O1.
– Dann besteht ein Schritt ET42 aus der Bestimmung, ob die ATR-Nachricht noch andere zu übermittelnde Bytes enthält. In unserem Ausführungsbeispiel besteht dieser Schritt aus der Bestimmung der Anzahl Bytes L(ATR), die noch in der ATR-Nachricht zu übermitteln sind und der Verringerung dieser Anzahl um eine Einheit (L(ATR) – 1) nach jeder Übertragung eines Bytes.
– In einem Schritt ET52 wird die noch zu übermittelnde Byte-Anzahl überprüft. Es gibt jetzt zwei Möglichkeiten:

1. Möglichkeit:
Falls die noch zu übermittelnde Byteanzahl L(ATR) größer ist als eins, wird Schritt ET12 wiederholt. In einem Schritt ET12 löst automatisch der programmierbare Taktgeber eine neue Unterbrechung I2 aus, welche die Ausführung des Algorithmus ALG1 wiederum unterbrechen kann. Im Anschluss an diese neuen Unterbrechung I2 übermittelt das Betriebssystem ein zweites Byte O2. Der Vorgang geht weiter, der Wert der noch nicht übermittelten Byteanzahl L(ATR) wird um eine Einheit verringert und der Index j wird ebenfalls um eine Einheit erhöht. Wenn alle Bytes übertragen worden sind, informiert vorzugsweise eine Nachricht das Betriebssystem, dass die Byte-Übertragung in der ATR-Nachricht beendet ist.
2. Möglichkeit:
Falls die in Schritt ET52 durchgeführte Prüfung aufzeigt, dass keine Bytes mehr zu übertragen sind, können die Verarbeitungsvorgänge bis zu ihrer Beendigung weitergeführt werden.
Vorzugsweise startet nach der Übermittlung eines Bytes On das Betriebssystem einen Verarbeitungsvorgang in einem Schritt ET32 oder beendet ihn, falls er vor der Unterbrechung I1 gestartet wurde. Zum Beispiel kann während der Prüfung in Schritt ET52 zur Bestimmung der Anzahl der noch zu übermittelnden Bytes das Betriebssystem die Verarbeitung, die es zuvor unterbrochen hatte, fortführen, bis eine neue Unterbrechung ausgelöst wird.
Bild 4 erläutert den Informationsaustausch über die Zeit zwischen dem Lesegerät LEC, dem Betriebssystem und dem programmierbaren Taktgeber TIM. Dieses Bild zeigt deutlicher den Zeitpunkt, wenn die Byte-Übermittlung in der ATR-Nachricht ausgelöst wird. Auf diesem Bild sind die Verzögerungen bei der Übermittlung einer Unterbrechung oder eines Bytes ΔOn von der Wirklichkeit weit entfernt. Für ein besseres Verständnis der Übereinstimmung zwischen den Bildern 3A–3B und 4 werden in der weiteren Beschreibung die Schritte der Bilder 3A und 3B in Klammern geschrieben.
Nach dem Einschaltvorgang (ET11) übermittelt das Betriebssystem eine erste Nachricht zur Aktivierung des programmierbaren Taktgebers (ET21).
Nach seiner Aktivierung übermittelt der programmierbare Taktgeber eine Unterbrechung I1 an das Betriebssystem, so dass es seine laufenden Verarbeitungsvorgänge (ET12) unterbricht.
Nach Empfang der Unterbrechung übermittelt das Betriebssystem ein erstes Byte O1 an das Karten-Lesegerät (ET22). Die Übertragungszeit betragt beispielsweise ΔO1.
Der Vorgang geht weiter, eine zweite Unterbrechung I2 wird an das Betriebssystem gesendet und nach Empfang der Unterbrechung übermittelt das Betriebssystem ein zweites Byte O2 an das Karten-Lesegerät. Die Übertragungszeit beträgt beispielsweise ΔO2.
Dieses Bild zeigt den Zeitabstand ΔRm zwischen dem Ende der Übertragung eines Bytes O(m – 1) und dem Zeitpunkt, an dem die Übertragung des nächsten Bytes O(m) ausgelöst wird. Dieser Zeitabstand wird ungefähr auf die zur Übertragung einer Unterbrechung notwendige Zeitdauer reduziert.
Eine weitere Ausgestaltung der Erfindung könnte in der Übermittlung mindestens zweier Bytes nach jeder Unterbrechung bestehen. Anstatt der Übermittlung eines Bytes nach einer Unterbrechung kann der programmierbare Taktgeber so programmiert werden, dass nach jeder Unterbrechung die Übermittlung von k Bytes ermöglicht wird. Der programmierbare Taktgeber muss für diese Ausgestaltung so programmiert werden, dass ausreichend Zeit zwischen zwei Unterbrechungen zur Übertragung dieser k Bytes vorhanden ist. Auf Bild 5 wird diese Variante anhand eines Algorithmus ALG3 dargestellt. Auf diesem Bild wurde im Vergleich zu dem auf Bild 2 gezeigten Algorithmus ALG2 ein Schritt ET72 hinzugefügt. Dieser Schritt ET72 umfasst einen Schritt zur Prüfung der Anzahl der nach einer Unterbrechung nacheinander übertragenen Anzahl von Bytes. Es gibt zwei Möglichkeiten:
1. Möglichkeit
Sollte die Anzahl der übermittelten Bytes nicht gleich k sein, überträgt das Betriebssystem ein anderes Byte in Schritt ET22. Die Anzahl k wird dann um eine Einheit erhöht und der Index j um eine Einheit erhöht.
2. Möglichkeit
Ist die Anzahl der übertragenen Bytes gleich k, übermittelt das Betriebssystem eine Unterbrechung und der Schritt ET12 wird durchgeführt. Der Parameter k wird dann zurückgesetzt, so dass die Prüfung in Schritt ET72 durchgeführt werden kann.
Bild 6 erläutert den Informationsfluss über die Zeit t zwischen dem Lesegerät LEC, dem Betriebssystem und dem programmierbaren Taktgeber TIM. Dieses Bild ist ein Beispiel, in dem nach jeder Unterbrechung drei Bytes übertragen worden sind (k = 3). Dieses Bild zeigt klar, dass die Bytes zwischen zwei Unterbrechungen nacheinander ohne Pause übertragen werden. Es ist klar, wie auf Bild 4, dass die Verzögerungen zur Übertragung einer Unterbrechung oder eines Bytes sehr weit von der Wirklichkeit entfernt sind.
Bild 7 ist ein Algorithmus ALG4 zur Erläuterung eines zweiten Ausführungsbeispiels, in dem ein dem Betriebssystem externer Agent geschaffen wird. In diesem Ausführungsbeispiel ist es nicht länger notwendig, das Betriebssystem zu unterbrechen, wie das im ersten Ausführungsbeispiel der Fall war. Dieser Agent ist ein Software-Programm, dessen Funktion die Auslösung der Byte-Übertragung in der ATR-Nachricht sowie die Übermittlung dieser Bytes ist.
Dieser Agent kann beispielsweise die obig beschriebene UART Komponente sein. Er würde programmiert werden, um regelmäßig eine bestimmte Anzahl Bytes zu übertragen. Ein Agent kann auch ein Modul sein, das einen zweiten Mikroprozessor enthält, welcher für die Auslösung der Byte-Übertragung und die Übermittlung der Bytes verantwortlich ist.
Der Algorithmus ALG4 zur Erläuterung des zweiten Ausführungsbeispiels umfasst die folgenden Schritte:
In Schritt ET13 des Algorithmus ALG4 wird die Smartkarte eingeschaltet.
In Schritt ET23 empfängt der Mikroprozessor diesen RESET-Befehl und aktiviert den Agent. Die Aktivierung besteht aus dem Starten des Agenten.
In Schritt ET33 überträgt das Betriebssystem alle Bytes der ATR-Nachricht an den Agenten.
In Schritt ET43 werden die Bytes der ATR-Nachricht in einem Speicher, zum Beispiel in einem mit dem Agenten verbundenen Zwischenspeicher, abgelegt.
Nach der Aktivierung und dem Empfang der Bytes in der ATR-Nachricht wird der Agent verantwortlich für das Auslösen der Byteübertragung und die Übermittlung dieser Bytes. Das Betriebssystem kann sich dann, eventuell parallel dazu, in Schritt 53 auf weitere Aufgaben wie beispielsweise die Verarbeitungsvorgänge (T1–Tn) konzentrieren. Das Übermittlungsverfahren kann das in Bild 3B beschriebene Verfahren sein. Die Byteübertragung besteht dann in einem Schritt ET63 aus der Übermittlung eines Bytes, wie dies in Schritt ET22 auf Bild 3B der Fall ist. Ein anderer Schritt ET73 besteht, wie in Schritt ET42 auf Bild 3B, aus der Bestimmung, ob die ATR-Nachricht andere zu übermittelnde Bytes umfasst. In unserem Ausführungsbeispiel besteht dieser Schritt aus der Bestimmung der Anzahl L(ATR) der noch in der ATR-Nachricht zu übermittelnden Bytes und der Verringerung dieser Anzahl um eine Einheit nach jeder Übertragung eines Bytes. Ein weiterer Schritt ET83, der mit Schritt ET52 auf Bild 3B identisch ist, besteht in der Prüfung der Anzahl der noch zu übermittelnden Bytes. Es gibt nun zwei Möglichkeiten:
1. Möglichkeit
Ist die Anzahl der noch zu übermittelnden Bytes L(ATR) größer als eins, wird der Schritt ET63 wiederholt. Der Agent übermittelt ein zweites Byte O2. Der Vorgang geht weiter, der Wert der noch nicht übermittelten Bytes wird um eine Einheit verringert. Wenn alle Bytes übermittelt worden sind, informiert vorzugsweise eine Nachricht das Betriebssystem, dass die Übermittlung der Bytes in der ATR-Nachricht beendet ist.
2. Möglichkeit
Zeigt die in Schritt ET83 erfolgte Prüfung, dass keine Bytes mehr zu übermitteln sind, informiert eine Nachricht das Betriebssystem in einem Schritt ET93, dass die Übermittlung der Bytes in der ATR Nachricht beendet ist.
Es ist festzustellen, dass der zur Erläuterung dieses zweiten Beispiels gewählte Übermittlungsvorgang dem Algorithmus ALG2 auf Bild 3B entspricht, aber es hätte ebenso gut der Algorithmus ALG3 auf Bild 5 sein können.
Es ist auch darauf hinzuweisen, dass in dem zuvor beschriebenen Schritt ET33 das Betriebssystem dem Agenten alle Bytes der ATR-Nachricht je nach der Größe des Zwischenspeichers und der Anzahl der zu übermittelnden Bytes der ATR-Nachricht in mehreren Arbeitsgängen übermitteln kann.
Im Allgemeinen betrifft die Erfindung eine Smartkarte CAR, in der ein dem Betriebssystem externes Modul (TIM), welches die Auslösung der Byte-Übertragung verwaltet, enthalten ist. In unserem Ausführungsbeispiel löst das Modul die Übertragung jedes Bytes in der die ATR-Nachricht bildenden Bytefolge aus. Es liegt auf der Hand, dass die Erfindung sich nicht auf eine Karte begrenzt, die ein einziges Modul umfasst, sondern auf jede beliebige Karte, die zumindest ein Modul umfasst, Anwendung findet. Wir haben gesehen, dass dieses Modul (TIM) ein Programm umfasst, das vor dem Einsatz vom Betriebssystem aktiviert wird.
Wir haben in einem ersten Ausführungsbeispiel gesehen, dass das Modul TIM ein programmierbarer Taktgeber ist, der nach seiner Aktivierung Unterbrechungen erzeugt, die jeden beliebigen laufenden Verarbeitungsvorgang des Betriebsystems unterbrechen und das Betriebssystem dazu zwingen können, die Byteübertragung auszulösen.
Auch haben wir in der Beschreibung gesehen, dass dieses Modul TIM ein ein Programm umfassender Agent sein kann, der nach seiner Aktivierung sowohl für die Auslösung der Byteübertragung als auch die Übermittlung der Bytes verantwortlich ist. Zur Implementierung dieses Beispiels erfordert der Agent einen Speicher, zum Beispiel einen Zwischenspeicher. Der Agent legt in diesem Speicher alle oder einen Teil der vom Betriebssystem übermittelten Bytes ab. Vorzugsweise verfügt dieser Speicher über einen ausreichend großen Speicherplatz, um alle Bytes der ATR-Nachricht aufzunehmen.
Wie wir zuvor gesehen haben, findet die Erfindung insbesondere auf die Reset-Bytes, die den Fachleuten unter dem Begriff ATR-Bytes (Answer-To-Reset) bekannt sind, Anwendung. Diese ATR-Bytes werden von der Karte nach ihrer Einschaltung übermittelt.
Die Lösung betrifft auch das Smartkartensystem, welches eine Smartkarte und ein Lesegerät für Smartkarten umfasst. Wir haben gesehen, dass dieses System ein oder mehrere dem Betriebssystem der Karte externe Module TIM umfasst, deren Aufgabe es ist, die Auslösung der Byte-Übermittlung zu verwalten.
Zur Durchführung des Auslöseschrittes erzeugt in unserem ersten Ausführungsbeispiel das Modul (TIM) Unterbrechungen, welche jeden beliebigen laufenden Verarbeitungsvorgang des in der Karte enthaltenen Betriebsystems unterbrechen und welche die Übermittlung durch das Betriebssystem zumindest eines Bytes (ATR) an das Kartenlesegerät auslösen können.
In dem zweiten Ausführungsbeispiel haben wir gesehen, dass das Modul ein „intelligenter" Software-Agent sein kann. Nach Aktivierung dieses Agenten beinhaltet das Verfahren einen Schritt zum Laden aller oder eines Teils der Bytes in einen mit diesem Agenten verbundenen Speicher, dieser Agent löst die Übermittlung der in den Speicher geladenen Bytes an das Lesegerät aus.
Die Auslösung wird von einem Programm durchgeführt. Dieses Programm umfasst Programm-Code-Befehle zur Ausführung eines Schrittes zur Aktivierung des besagten Moduls, so dass es die Byte-Übermittlung ab der Karte an das Lesegerät (LEC) auslöst.
Wir haben nun gesehen, dass diese Erfindung weitere deutliche Vorteile bringt. Dies betrifft sowohl die einwandfreie zeitliche Steuerung bei der Byte-Auslösung der ATR-Nachricht; außerdem können, wie wir gesehen haben, die Unterbrechungen von einem in der Smartkarte vorhandenen Modul, z. Beisp. einem programmierbaren Taktgeber, ausgelöst werden. Ein zweites Ausführungsbeispiel hat auch gezeigt, dass der Rückgriff auf Unterbrechungen durch Schaffung eines gegenüber dem Betriebssystem externen Software-Agenten vermieden werden kann. Der Vorteil dieser Software ist, dass sie nach Aktivierung durch das Betriebssystem nicht nur die Auslösung der Byte-Übertragung, sondern auch die Übermittlung der Bytes verwaltet.
Ferner bringt die Erfindung nicht zu vernachlässigende Vorteile. Dank der vollständigen Steuerung der Auslösungszeiten kann die gesamte für die Übertragung aller Bytes in der ATR-Nachricht notwendige Zeitdauer gesteuert werden. Die gesamte zur Übermittlung der ATR-Nachricht notwendige Zeitdauer ist unter Kontrolle und kann somit moduliert werden, so dass das Ende der Übertragung der ATR-Nachricht mit dem Zeitpunkt synchronisiert werden kann, an dem das Betriebssystem bereit ist, vom Lesegerät einen APDU-Befehl zu empfangen.

Claims

Eine einen Prozessor (CPU) und einen Speicher umfassende Smartkarte (CAR), wobei besagter Prozessor und besagter Speicher ein Betriebssystem implementieren, wobei besagte Smartkarte ausgelegt ist, um einem Lesegerät (LEC) eine Anfangsmeldung mit Angabe von Daten für das Lesegerät über die Kommunikationsfähigkeiten der Smartkarte (ATR) zu übertragen, wobei besagte Anfangsmeldung eine Reihe von Untermeldungen umfasst, die an das Lesegerät zu übermitteln sind, dadurch gekennzeichnet, dass die Karte ein vom Betriebssystem getrenntes Modul umfasst, welches in regelmäßigen Abständen die Übermittlung einer oder mehrerer Untermeldungen aus einer verbleibenden Reihe von noch nicht an das Lesegerät gesandten Untermeldungen auslöst.
Die Smartkarte nach Anspruch 1, dadurch gekennzeichnet, dass besagtes getrenntes Modul einen Algorithmus (ALG2) umfasst, welcher vom Betriebssystem (ALG1) getrennt ist und welcher mit einem Verarbeitungsalgorithmus des Betriebssystems (ALG1) in Wechselwirkung steht, so dass besagter Verarbeitungsalgorithmus des Betriebssystems unterbrochen und dabei die Übermittlung einer Untermeldung durch das Betriebssystem ausgelöst wird.
Die Smartkarte nach Anspruch 1, dadurch gekennzeichnet, dass besagtes getrenntes Modul einen Speicher zum Laden besagter Reihe von Untermeldungen aus dem Betriebssystem in besagten Speicher des getrennten Moduls aufweist, und wobei besagtes getrenntes Modul in regelmäßigen Abständen die Übermittlung von Untermeldungen aus einer verbleibenden Reihe von in den Speicher des getrennten Moduls geladenen und noch nicht übermittelten Untermeldungen auslöst.
Die Smartkarte nach Anspruch 1, dadurch gekennzeichnet, dass das getrennte Modul einen Taktgeber zur zeitgesteuerten besagten Auslösung der Übermittlung von Untermeldungen aufweist.
Die Smartkarte nach Anspruch 1, dadurch gekennzeichnet, dass das besagte Modul eine getrennte Verarbeitungsvorrichtung aufweist, welche von besagtem Prozessor und Speicher zur Implementierung des Betriebssystems getrennt ist.
Die Smartkarte nach Anspruch 1, dadurch gekennzeichnet, dass die Anfangsmeldung eine Antwort auf einen Reset-Befehl darstellt.