DE69729622T2 - Verfahren und gerät zur evolution eines programmes in rom - Google Patents

Verfahren und gerät zur evolution eines programmes in rom Download PDF

Info

Publication number
DE69729622T2
DE69729622T2 DE69729622T DE69729622T DE69729622T2 DE 69729622 T2 DE69729622 T2 DE 69729622T2 DE 69729622 T DE69729622 T DE 69729622T DE 69729622 T DE69729622 T DE 69729622T DE 69729622 T2 DE69729622 T2 DE 69729622T2
Authority
DE
Germany
Prior art keywords
code
memory
address
jump
sequence
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69729622T
Other languages
English (en)
Other versions
DE69729622D1 (de
Inventor
Azadali Nassor
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CP8 Technologies SA
Original Assignee
CP8 Technologies SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CP8 Technologies SA filed Critical CP8 Technologies SA
Publication of DE69729622D1 publication Critical patent/DE69729622D1/de
Application granted granted Critical
Publication of DE69729622T2 publication Critical patent/DE69729622T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482Procedural
    • G06F9/4484Executing subprograms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355Personalisation of cards for use
    • G06Q20/3552Downloading or loading of personalisation data

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Storage Device Security (AREA)
  • Communication Control (AREA)
  • Circuits Of Receivers In General (AREA)

Description

  • Die vorliegende Erfindung betrifft Computerprogramme, insbesondere solche, die in einen Datenträger mit Mikroschaltungen) eingebettet sind, und auf allgemeinere Art tragbare Objekte, die mit integrierten Schaltungen ausgestattet sind, die mindestens einen Prozessor, einen festen Programmspeicher, einen nichtflüchtigen programmierbaren Speicher und einen Arbeitsspeicher umfassen. Dieser nichtflüchtige Speicher kann Daten und einen Code speichern, den der Prozessor ausführt.
  • Für ein und dasselbe Objekt ist derzeit die Möglichkeit bekannt, zwei sehr unterschiedliche Programmarten zusammen unterzubringen, wobei ein Programm gleich bei der Fertigung in der integrierten Schaltung untergebracht wird und nicht verändert werden kann und das andere während der normalen Anwendung des Objekts nach Bedarf von außen her eingebracht wird.
  • Heutzutage können die Datenträger mit Mikroschaltungen) in technischer Hinsicht zahlreiche Anforderungen erfüllen. Trotzdem ist die Herstellung einer „Maske", d. h. das Programm im ROM-Speicher, noch immer sehr teuer, so dass diese Investition zahlreiche „kleine" Kunden abschreckt, die nur einige tausend Karten kaufen möchten. Eine Lösung könnte darin bestehen, eine bestehende Maske zu verwenden und die Funktionen, die der Kunde verlangt, im programmierbaren Speicher hinzuzufügen.
  • Die Möglichkeit, einen zusätzlichen Code im programmierbaren Speicher einzubringen und auszuführen, bietet den Vorteil, auf einfache Art einem bestehenden Programm neue Funktionen hinzuzufügen oder dieses Programm einem besonderen Bedarf anzupassen.
  • Das Patent FR 2 655 170 beschreibt eine tragbare elektronische Vorrichtung, die im nichtflüchtigen Speicher Codefolgen speichern kann. Der programmierbare nichtflüchtige Speicher umfasst einen besonderen Teil, der für die Aufnahme von Codefolgen konfiguriert ist, wobei dieser Teil selbst in eine Indikatorenzone, eine Codefolgendatenzone und eine Zeichenzone für die blockweise Kontrolle aufgeteilt ist. Im Programm im Festspeicher ist zum Lesen und Testen der Indikatorenzone und im positiven Fall zum Durchführen des Sprungs ein Testbefehl implementiert. Jedem Sprung muss also ein Testbefehl und eine im programmierbaren Speicher zugeordnete Speicherzone entsprechen.
  • Durch die französische Patentanmeldung 2 667 417 ist auch eine Mikroprozessorkarte bekannt, die zur Aufnahme von vielfachen Programmen im programmierbaren Speicher vorgesehen ist und bei der jedem der im programmierbaren Speicher reservierten Speicherplätze sogenannte Filterbefehle zugeordnet sind, um ein Mittel zum Speichern der Adresse des Codes eines durch Ausführung des im Festspeicher der Karte gespeicherten Filterbefehls zugänglichen Befehlunterprogramms zu schaffen. Jeder Filterbefehl muss die Adresse der Speicherzone kennen, die die Adresse des zugeordneten Codes im programmierbaren Speicher enthält, was eine für immer festgelegte Zugriffshierarchie voraussetzt.
  • Die beiden vorausgehend aufgezeigten Lösungen weisen folgende Nachteile auf.
  • Ein Fachmann, der mehrere Sprungbefehle implementieren möchte, muss die Sprungbefehle im Programm des Festspeichers und die spezifischen Zonen im programmierbaren Speicher multiplizieren. Wenn viele Befehle dieser Art im Hauptprogramm installiert werden müssen, wird der von ihnen im Festspeicher eingenommene Gesamtplatz zu Lasten des Platzes für das Programm groß. Außerdem ist der Platz des Unterprogramms im nichtflüchtigen programmierbaren Speicher, auch wenn dieses nicht gespeichert wird, reserviert. Das gleiche gilt für den Platz der Indikatoren, so dass unnützerweise ein erheblicher Platz eingenommen wird. Schließlich kann das Unterprogramm, nachdem es geschrieben wurde, nicht mehr geändert werden. Zusammenfassend lässt sich sagen, dass sich diese Lösung für eine sehr eingeschränkte Anzahl von Sprungbefehlen und für einige Unterprogramme eignet. In keinem Fall ist jedoch das Problem einer großen Anzahl von Sprüngen und Unterprogrammen gelöst.
  • Die vorliegende Erfindung hat ein Verfahren und eine Vorrichtung zum Gegenstand, mit denen die Funktionen einer Chipkarte ohne die Nachteile der genannten Patente weiterentwickelt werden können und mit denen insbesondere mehr Unterprogramme aufgerufen werden können. Die erfindungsgemäße Vorrichtung bietet nämlich den Vorteil, einfach in einem Programm einsetzbar zu sein, bzw. einen geringen Codespeicher zu brauchen, bzw. die genutzte Speichergröße zu minimieren, bzw. weiterentwickelbar zu sein und alle Arten von Änderungen zuzulassen bzw. die Ausführungszeiten zu optimieren.
  • Dazu ist die Vorrichtung zur Ausführung von Codefolgen in einem Datenträger mit einer zur Ausführung von Codefolgen fähigen integrierten Schaltung und einerseits einem ersten Speicher mit einem Hauptprogramm und eventuell weiteren von der integrierten Schaltung ausführbaren Codefolgen und andererseits einem programmierbaren permanenten zweiten Speicher, der eventuell von der integrierten Schaltung ausführbare Codefolgen enthält, und einem dritten Arbeitsspeicher dadurch gekennzeichnet, dass eine im zweiten Speicher enthaltene Richtungstabelle mindestens ein Feld mit Codereferenzdaten enthält: wobei erste Mittel (INS_INT) ermöglichen:
    • – das Vorhandensein einer Codereferenz zu prüfen,
    • – im Arbeitsspeicher die der Codereferenz zugeordneten Adressendaten zu speichern und einen Sprungindikator DI zu positionieren und
    zweite Mittel (INS_ORT) ermöglichen:
    • – den Sprungindikator DI zu testen und
    • – den Sprung zu der vom Inhalt des Arbeitsspeichers markierten Adresse durchzuführen.
  • Gemäß einer weiteren Besonderheit werden die der Codereferenz zugeordneten Adressendaten einer in einem der drei Speicher enthaltenen Codefolge ausgehend von der Codereferenz berechnet.
  • Gemäß einer weiteren Besonderheit enthält ein zweites Feld die Adressendaten einer in einem der drei Speicher enthaltenen Codefolge.
  • Gemäß einer weiteren Besonderheit umfasst die Vorrichtung in einer eventuell geschützten Zone des programmierbaren Speichers eine Information, die die erste Adresse und eventuell die Suchrichtung für die ersten Prüfmittel definiert.
  • Gemäß einer weiteren Besonderheit umfasst die Richtungstabelle ein zusätzliches Feld, das die nächste Adresse in der Tabelle angibt, an der sich die der nächsten Codereferenz entsprechenden Informationen befinden.
  • Gemäß einer weiteren Besonderheit umfasst die Richtungstabelle ein zusätzliches Feld, das die Ganzzahligkeit der vorausgehenden Felder und/oder der zugehörigen Codefolge durch Vergleich mit dem von einem Rechenmittel einer Kontrollsumme bereitgestellten Ergebnis gewährleistet.
  • Gemäß einer weiteren Besonderheit umfassen die zweiten Mittel Mittel zum Speichern im Arbeitsspeicher einer Rücksprungadresse nach einem Sprung, wenn mehrere zweite Mittel vorhanden sind, um einen Sprung zur selben Sequenzadresse zu machen.
  • Gemäß einer weiteren Besonderheit umfasst die Vorrichtung Mittel CAI zum Verhindern des Speicherns eines Zusatzcodes sowie Mittel RCI zum Verhindern einer Regenerierung der Karte.
  • Ein weiteres Ziel ist es, ein Speicherverfahren für neue Funktionen vorzuschlagen.
  • Dieses Ziel wird durch die Tatsache erreicht, dass das Speicherverfahren eines neuen Codes in einer Vorrichtung gemäß einem der vorausgehenden Ansprüche dadurch gekennzeichnet ist, dass es in Folgendem besteht:
    • – Aufnehmen eines Speicherbefehls;
    • – Prüfen, ob ein erstes Feld vorhanden ist, das die Codereferenz A, B, C ... bildet und ob ein zweites Feld AD_Cod_A, AD_Cod_B, AD_Cod_C ... vorhanden ist, das die der Codereferenz zugeordnete Adresse darstellt;
    • – Prüfen, ob der Wert der ersten Adresse, welche die Adresse der Richtungstabelle AD_TAB bildet, in sich widerspruchsfrei ist;
    • – Prüfen, ob kein ECA-Kennzeichen aktiv ist;
    • – Kontrollieren, ob die vom ersten Feld bereitgestellte Referenz nicht in der Tabelle existiert;
    • – Positionieren des ECA-Kennzeichens in den aktiven Zustand in der geschützten programmierbaren Speicherzone;
    • – Aufnehmen und Schreiben der dem neuen Code entsprechenden Informationen;
    • – Prüfen, ob die Operation richtig abgelaufen ist und Aktualisieren der Richtungstabelle;
    • – Positionieren des ECA-Kennzeichens in den inaktiven Zustand.
  • Gemäß einer weiteren Besonderheit umfasst der Aktualisierungsvorgang der Tabelle ein Schreiben des nächsten Adressenfeldes in der Richtungstabelle an der Adresse, die dem Richtungswort des dem geschriebenen Code vorausgehenden Codes entspricht.
  • Weitere Besonderheiten und Vorteile der vorliegenden Erfindung werden anhand der folgenden Beschreibung eines Ausführungsbeispiels der Vorrichtung und der Anwendung des Verfahrens deutlich, welche anhand der folgenden Zeichnungen geschildert werden, wobei:
  • 1 eine Einteilung des programmierbaren Speichers der Karte darstellt, bei der eine Variante des Verwaltungsverfahrens der Richtungstabelle zum Einsatz kommt;
  • 2 ein Beispiel für die Einteilung des Festspeichers der Karte darstellt;
  • 3 in einem Hauptprogramm ein Beispiel für die Verkettung eines im Laufe des Hauptprogramms ausgeführten Befragungsbefehls und später eines Richtungsbefehls darstellt;
  • 4 ein Beispiel einer möglichen Verkettung von Befragungs- und Richtungsbefehlen darstellt;
  • 5 ein Beispiel für einen Ablaufalgorithmus einer Codefolge darstellt, die den Befragungsbefehl bildet;
  • 6 ein Ausführungsbeispiel der Einteilung des programmierbaren Speichers darstellt, bei dem die Richtungstabelle und die Zonen der Codefolgen enthalten sind;
  • 7 ein zweites Ausführungsbeispiel der Einteilung des Speichers darstellt, bei dem die Richtungstabelle und die Zonen der Codefolgen enthalten sind;
  • 8 ein Fließdiagramm über den Ablauf einer Codefolge darstellt, die einen Richtungsbefehl bildet;
  • 9 ein Beispiel der Felder darstellt, die Bestandteil eines Schreibbefehls einer Folge sind;
  • 10 ein Fließdiagramm über den Ablauf einer durch einen Schreibbefehl ausgelösten Speicherfolge darstellt;
  • 11 die Bestandteile eines Datenträgers mit Mikroschaltungen) darstellt, der zum Einsatz der Vorrichtung und des Verfahrens der Erfindung erforderlich ist.
  • Die Erfindung wird anhand der Beschreibung des folgenden Anwendungsbeispiels in einer Mikroprozessorkarte gemäß 11 deutlicher.
  • Eine Mikroprozessorkarte besitzt eine zur Ausführung von Befehlsfolgen fähige Zentraleinheit (10) vom Typ Mikroprozessor oder mit integrierter Schaltung, einen RAM-Arbeitsspeicher (14), einen nichtflüchtigen ROM-Speicher (12), der das Hauptprogramm enthält, einen durch die Zentraleinheit programmierbaren und ausführbaren nichtflüchtigen EPROM-, EEPROM- oder FRAM-Speicher (11), der Daten enthält sowie Eingangs-/Ausgangsorgane (13) für den Dialog mit einem Lesegerät über eine kontaktlose oder kontaktbehaftete Verbindung (15). Das Programm wird bei der Fertigung des Bauteils in den ROM-Speicher gebrannt und kann daher später nicht mehr geändert werden.
  • Der programmierbare Speicher (11) ist, wie in 1 abgebildet, in mehrere Teile eingeteilt. Ein erster als Systemzone bezeichneter Teil (110) enthält Systeminformationen, die von außen her nicht lesbar sind und die Kontrolle der Gültigkeit (Authentizität und/oder Ganzheit) und die Lokalisierung der im Rest des Speichers (Zeiger...) enthaltenen Informationen oder Datengruppe ermöglicht. Ein zweiter als Datenzone bezeichneter Teil (111) ist von außen her zugänglich und dient zur Speicherung der Anwenderdaten. Ein dritter als Richtungstabelle bezeichneter Teil (112) enthält die Richtungstabelle, die aus identischen Elementen besteht, wobei jedes Element mehrere Felder, darunter zwei Hauptfelder enthält: das erste sind Codereferenzdaten: „A", „B", ... und das zweite ist die Anfangsadresse der entsprechenden Codefolge, die in einem vierten Teil (113) des Speichers gespeichert ist: AD_Cod_A, AD_Cod_B ... Die vierte als Codefolgezone bezeichnete Zone enthält die Codefolgen, die vom Hauptprogramm aufgerufen werden können. Es ist darauf hinzuweisen, dass die Richtungstabelle bzw. die Codefolge in einer Variante der Erfindung im Arbeitsspeicher (RAM) anstatt im EEPROM gespeichert werden kann.
  • Die mit AD_TAB bezeichnete Anfangsadresse der Richtungstabelle wird in der Systemzone gespeichert, eine zweite als SENS bezeichnete Information bestimmt, in welcher Richtung der Zeiger diese Tabelle abliest, d. h. entweder in der Richtung der ansteigenden Adressen oder in der Richtung der absteigenden Adressen. Die Adressen der Werte AD_TAB und SENS können also die einzigen Werte hinsichtlich der Erfindung sein, die das Programm im ROM kennt. Es kann auch nützlich sein, die Bytegröße bzw. die maximale Anzahl der Elemente (Ta Ta) der Richtungstabelle zu speichern.
  • Folgendes Beispiel zeigt die Bedeutung des Verfahrens nichtprogrammierter Sprünge gemäß der Erfindung. Das Hauptprogramm kann einen Algorithmus wie z. B. D. E. S. (Data Encryption Standard) enthalten, der Informationen bzw. gewisse Authentifikationsfunktionen verschlüsseln/entschlüsseln kann. Es kann von Interesse sein, diesen Algorithmus durch einen anderen zu ersetzen bzw. seine Implementierung ganz zu ändern, damit er zum Beispiel schneller wird. Der Code des Algorithmus bildet einen Block im ROM-Speicher des Betriebssystems, kann nicht verändert werden und kann von verschiedenen Stellen des Hauptprogramms aufgerufen werden.
  • Anhand 2 wird das Beispiel noch deutlicher. Der unter anderem das Hauptprogramm enthaltende ROM-Speicher ist in drei Teile aufgeteilt. Der erste Teil führt nach einem Unterspannungsetzen die Initialisierung der Karte durch: Test des Arbeitsspeichers, Ablesen des Kartenzustands, Senden der Bytes der Antwort auf das RESET. Der zweite Teil enthält das Applikationsprogramm, das die einzelnen vom Terminal verlangten Befehle ausführt (der erste Codeteil wird immer vor dem zweiten ausgeführt). Erster und zweiter Teil bilden das Hauptprogramm. Der dritte Teil enthält den „schlafenden" Code, dessen Rolle im Weiteren erklärt wird.
  • Der als ALGO_1 bezeichnete Algorithmus, dessen Funktionsweise man ändern will, ist im Applikationsteil enthalten. In dem Beispiel wird dieser Algorithmus von fünf verschiedenen Stellen des Codes aufgerufen. Der neue Algorithmus wurde vorausgehend in der Codefolgezone im programmierbaren Speicher geladen, die Richtungstabelle wurde aktualisiert, und die Ausführungsadresse seiner Codefolge ist AD_Cod_A.
  • Beim Einschalten führt das Hauptprogramm den Initialisierungsteil aus. In diesem Teil findet man den ersten Sprung zu ALGO_1, der mit „APPEL_0" bezeichnet wird. Es ist kein nichtprogrammierter Sprung vorgesehen, so dass dieser Sprung durch keinen Befehl für einen nichtprogrammierten Sprung bedingt ist. Es ist auch eine Befragungsbefehlfolge INS_INT_A vorzufinden, die der Programmierer vorsichtshalber in diesem Teil implementiert hat, um sicher zu gehen, dass sie mindestens einmal vor Ausführen des Programms des Applikationsteils ausgeführt wird. In dem Beispiel ist die dieser Befragungsbefehlfolge zugeordnete Codereferenz „A" und ist im Hauptprogramm eingetragen. Als erstes sucht der Befragungsbefehl in der Systemzone die Adresse der Richtungstabelle AD_TAB. Anschließend wird ausgehend von dieser Adresse und in der Richtung der aufsteigenden bzw. absteigenden Adressen gemäß dem Wert von „SENS" jedes Element der Tabelle abgelesen. Der Wert der ersten den Codereferenzen entsprechenden Felder wird mit dem Wert „A" verglichen. Wenn der Wert „A" in einem ersten Feld der Richtungstabelle gefunden wird, wird der entsprechende Wert des zweiten Feldes (AD_Cod_A) abgelesen und im Register AD_SAUT des Arbeitsspeichers (RAM) gespeichert. Außerdem wird ein Sprungindikator (DI) im Arbeitsspeicher in den aktiven Zustand versetzt.
  • Wenn DI nicht aktiv ist, wird das Unterprogramm ALGO_1 fünf Mal von APPEL_0, APPEL_1, ... APPEL_4 im Hauptprogramm aufgerufen. Wenn der Sprungindikator DI aktiv ist, kommt es bei APPEL_1, APPEL_2 und APPEL_3 zu einem Sprung zu einem anderen Programm ALGO_2, welches im Festspeicher oder im programmierbaren Speicher sein kann, da der Programmierer vorgesehen hat, im Code des Hauptprogramms vor jedem tatsächlichen Sprung APPEL_1, APPEL_2, APPEL_3 in ALGO_1 einen Richtungsbefehl INS_ORT_1, INS_ORT_2 und INS_ORT_3 zu implementieren. Wie in 3 zu sehen ist, besteht der Richtungsbefehl zunächst darin, zu testen, ob der Sprungindikator DI aktiv ist. Wenn dieser inaktiv ist, folgt das Hauptprogramm seinem normalen Verlauf und führt im ROM-Speicher den Algorithmus aus, indem zum Beispiel der Sprung APPEL_1 zu ALGO_1 durchgeführt wird. Wenn der Sprungindikator DI aktiv ist, lenkt der Richtungsbefehl das Programm zu der Adresse um, die durch den Inhalt des Registers AD_SAUT angegeben wird. Der vorab im Register AD_SAUT gespeicherte Wert AD_Cod_A wird im Befehlszähler des Prozessors geladen und die Codefolge mit geladener Adresse wird ausgeführt. Dagegen wird das Unterprogramm ALGO_1 nach dem Willen des Programmierers ohne Umleitungsmöglichkeit von APPEL_4 aufgerufen, da diesem kein Richtungsbefehl zugeordnet ist.
  • Es ist darauf hinzuweisen, dass die Befragungsbefehl- und Richtungsbefehlexpressionen in Wirklichkeit Makrobefehle sind, die durch eine Reihe von der Zentraleinheit ausführbaren Grundbefehlen gebildet werden.
  • Solange der Indikator aktiv bleibt, kann ein und derselbe Richtungsbefehl unbegrenzt oft ausgeführt werden, wobei der Sprung immer zu der in AD_SAUT gespeicherten Adresse stattfindet. Ebenso können, wie es 2 zeigt, mehrere Richtungsbefehle „INS_ORT_1, INS_ORT_2, INS_ORT_3 mit demselben Referenzcode „A" im Hauptprogramm implementiert werden, wobei deren Ausführung immer dieselbe Wirkung hat. In diesem Fall muss mit ganz besonderer Sorgfalt die Rücksprungadresse zum Hauptprogramm untersucht werden. Im Folgenden der Beschreibung werden Ausführungsbeispiele eines Rücksprungbefehls erklärt.
  • In der Regel muss der Programmierer darauf achten, dass mindestens eine Befragungsbefehlfolge vor jeglichem Richtungsbefehl ausgeführt wird. Wenn die Codefolge nur ein einziges Mal umgelenkt werden soll, wird von der Codefolge ein Löschbefehl des Sprungindikators DI ausgeführt, der den Sprungindikator DI inaktivieren soll. Nach der Rückkehr ins Hauptprogramm kann also bei den folgenden Richtungsbefehlen kein Umleiten mehr stattfinden.
  • Anhand dieses Beispiels wird der erste Vorteil, die zwei Folgen der Befragungs- und Richtungsbefehle zu trennen, deutlich. Die umfangreichere und also an Code aufwändigere Befragungsbefehlfolge wird nur einmal in das Programm eingebracht. Die sehr kurzen und daher nur wenig Speicherplatz einnehmenden Richtungsbefehlfolgen werden so oft wie erforderlich eingebracht, wodurch im Programmspeicher Platz gewonnen wird.
  • Der Sprungindikator DI kann sehr wohl durch einen besonderen Wert des Registers AD_SAUT ersetzt werden. Wenn das Register AD_SAUT den Wert „NULL" enthält, welcher für ein bestimmtes Bauteil kein bedeutender Adressenwert des nichtflüchtigen Speichers ist, bedeutet dies, dass kein nichtprogrammierter Sprung des Hauptprogramms zu berücksichtigen ist. Außerdem kann man davon ausgehen, dass wenn der Inhalt des Speichers AD_TAB ein Wert ist, der nicht mit dem Anfangswert der Richtungstabelle (zum Beispiel „NULL") zusammenhängt, keine Folge verfügbar und folglich kein nichtprogrammierter Sprung vorgesehen ist.
  • Wie in 4 zu sehen, können mehrere Befragungsbefehle (INS_INT_A, INS_INT_B) in das Hauptprogramm eingebracht werden. Jeder dieser Befehle besitzt seinen eigenen im Programmspeicher eingetragenen Referenzcode und sucht unter den ersten Werten der Richtungstabelle im Programmspeicher nach dem Vorhandensein dieses Codes. Wenn der Wert dieses Codes tatsächlich in der Tabelle ist, kommt die Adresse der zugeordneten Codefolge in das Arbeitsregister AD_SAUT. So wird durch die Ausführung eines Befragungsbefehls der durch den vorausgehenden Befragungsbefehl aktualisierte Wert des Registers AD_SAUT gelöscht und ersetzt.
  • Wenn ein vorausgehender Befragungsbefehl das Register AD_SAUT mit der Sprungadresse aktualisiert hat und ein zweiter Befragungsbefehl mit einem anderen Referenzcode ausgeführt wird und dabei in der Richtungstabelle sein Referenzcode nicht gefunden wird, reicht es und ist es sinnvoll, den vorherigen Wert von AD_SAUT zu löschen und somit jeglichen nichtprogrammierten Sprung bis zum nächsten Befragungsbefehl abzubrechen. Man entfernt sich allerdings nicht vom Sinn der Erfindung, wenn man den vorherigen Wert beibehält und somit den nichtprogrammierten Sprung bewahrt.
  • Außerdem wird ein zweiter Vorteil deutlich, in einer Richtungstabelle eingetragene Codereferenzen „A", „B" ... zu verwenden: diese Tabelle enthält nur nützliche Daten, die sich ausschließlich auf tatsächlich im Hauptprogramm gewollte nichtprogrammierte Sprünge beziehen. Auf diese Weise ist ihre Größe zu jedem Zeitpunkt optimal und ermöglicht eine Speicherplatzeinsparung.
  • Vorteilhafterweise können im Hauptprogramm Codefolgen gespeichert werden, die nicht von diesem aufgerufen werden. Mithilfe des erfindungsgemäßen Mechanismus kann jeder dieser Folgen eine Codereferenz zugeordnet werden, die in der Richtungstabelle mit der Anfangsadresse der Folge gespeichert wird. Auf diese Weise kann ein „schlafender" Code im Programmspeicher der tragbaren Vorrichtung aktiviert werden.
  • Vorteilhafterweise können durch die Richtungsbefehle auch mehrere Eingangspunkte zur selben Codefolge definiert und diese verschiedenen Referenzcodes zugeordnet werden. Außerdem können zum Beispiel mehrere Folgen „A", „B" und „C" zu einer einzigen Folge zusammengefasst werden, die in einem Zug im programmierbaren Speicher mit dem Referenzcode „A" und dem Eingangspunkt „AD_Cod_A" geschrieben wird. Die beiden anderen Referenzcodes und die Eingangspunkte werden anschließend geschrieben. Ein Beispiel einer Richtungstabelle, die diese Operation ermöglicht, wird im Folgenden (7) dargestellt.
  • Gehen wir nun anhand der 5 auf den Ablauf der Befragungsbefehle ein. Ein Eingangsparameter dieses Befehls ist der mit „X" bezeichnete Wert des der Codefolge entsprechenden Referenzcodes. Diese Codefolge wird bei einem folgenden Richtungsbefehl ausgeführt. In unserem Beispiel ist dieser Wert „X". Im Schritt 1 liest das Hauptprogramm unter Ausführung der Befragungsbefehlfolge in der Systemzone an der vom Programm im ROM bekannten Adresse @ den Inhalt AD_TAB ab, der die Anfangsadresse der Richtungstabelle bildet. Im Schritt 2 testet die Befragungsbefehlfolge das gelesene Wort. Wenn das gelesene Wort nicht signifikant ist, existiert keine Richtungstabelle und ein Codesprung ist nicht möglich. Die Befragungsbefehlfolge ist beendet und der Sprungindikator DI ist inaktiv (Schritt 10). Wenn das gelesene Wort signifikant ist, aktualisiert die Befragungsbefehlfolge im Schritt 3 im Arbeitsspeicher einen Zeiger wie zum Beispiel AD_SAUT mit dem gelesenen Wert AD_TAB. Im Schritt 4 liest die Befragungsfolge dann ein durch diesen Zeiger markiertes Element der Tabelle ab. Im Schritt 5 der Befragungsfolge wird der Wert des der Codereferenz entsprechenden Feldes mit dem Wert „X" des Referenzcodes verglichen, der als Eingangsparameter bereitgestellt wird. Wenn die zwei Werte identisch sind, stellt die Befragungsfolge im Schritt 8 den Sprungindikator DI auf den aktiven Zustand ein. Mithilfe des Zeigers liest die Befragungsfolge im Schritt 9 den Adressenwert „AD_Cod_X" ab, der sich unmittelbar nach dem Referenzcode in der Richtungstabelle befindet. Dieser Wert wird im Register AD_SAUT im RAM-Arbeitsspeicher gespeichert. Wenn die zwei Codereferenzwerte nicht identisch sind, wird im Schritt 6 der Zeiger aktualisiert, um den nächsten Referenzcode in der Richtungstabelle zu markieren. Diese Aktualisierung erfolgt unter Berücksichtigung der Größe jedes Tabellenelements. Wenn die Tabelle zum Beispiel aus 32-Bit-Wörtern besteht, wird der Wert des Zeigers, der 8-Bit-Gruppen adressiert, um 4 erhöht. Die Befragungsfolge prüft im Schritt 7, ob das vom Zeiger adressierte Wort des programmierbaren Speichers noch in der Richtungstabelle ist. Dieser Test hängt von der Organisation der Tabelle ab, von der im Folgenden mehrere Beispiele aufgezeigt werden. Wenn das markierte Wort nicht mehr zur Tabelle gehört, ist die Befragungsbefehlfolge beendet und der Sprungindikator DI wird durch den Schritt 10 auf den inaktiven Zustand gestellt. Wenn das markierte Wort noch in der Richtungstabelle ist, springt die Befragungsfolge wieder zu Schritt 4 zurück.
  • Nach Abschluss der Befragungsbefehlfolge ist der Sprungindikator DI immer noch positioniert. Wenn er aktiv ist, ist der Wert in AD_SAUT signifikant. Vorteilhafterweise kann die Befragungsbefehlfolge vom Programmierer geschrieben werden. Dieser realisiert das Hauptprogramm als ein Unterprogramm mit einerseits dem Referenzcode, z. B. X, der in der Tabelle gesucht werden muss und eventuell einer Rücksprungadresse als Eingangsparameter, sowie andererseits mit einem Sprungindikator DI, der festlegt, ob der Sprung tatsächlich durchgeführt werden muss, als Ausgangsparameter. Während der Initialisierung können die Richtungstabelle abgelesen und alle den bestehenden Referenzcodes entsprechenden Adressen im Arbeitsspeicher gespeichert werden. Dadurch lässt sich vermeiden, bei jedem Befragungsbefehl die Tabelle systematisch abzutasten und einen nicht existierenden Code umsonst zu suchen.
  • 6 zeigt ein Beispiel einer Richtungstabelle. Diese Tabelle besteht zum Beispiel aus 32-Bit-Richtungswörtern. Das erste Feld, zum Beispiel aus einem Byte, enthält den Referenzcode; das zweite Feld, zum Beispiel aus den zwei folgenden Bytes, enthält die Anfangsadresse der Codefolge im nichtflüchtigen Speicher; das letzte Feld, zum Beispiel aus einem Byte, ist wahlweise und kann einen Kontrollsummencode (CheckSum): (CHK_A) enthalten, durch den die Ganzzahligkeit des Wertes der ersten zwei Felder und/oder der angehängten Codefolge geprüft werden kann. In dieser Richtungstabelle sind die Elemente aneinandergrenzend. Das Tabellenende wurde erreicht, wenn das folgende Wort leer ist. Der in der Systemzone abgelesene Wert SENS gibt die Fortbewegungsrichtung des Tabellenzeigers an: entweder in aufsteigender oder absteigender Richtung der Adressen. In 6 wurde die aufsteigende Richtung der Adressen gewählt.
  • Die Anordnung dieser Tabelle ist interessant, da sie zahlreiche Elemente enthält. Die Referenzcodes dieser Elemente können nämlich in einer bestimmten Reihenfolge eingeordnet werden. Die Organisation dieser Elemente in der Tabelle kann also gemäß ansteigenden Referenzen erfolgen: „A", „B", „C", „D", „E" ... oder gemäß abfallenden Referenzen „Z", „Y", „X", „W" ... Die Byte-Größe der Tabelle ist festgelegt. Sie ist entweder in einer Zone (Ta Ta in 1) der Systemzone gespeichert oder durch ein Vorab-Lesen der Tabelle bei der Initialisierung. Bei der Suche eines bestimmten Referenzcodes können demnach Sortieralgorithmen angewendet werden. Zum Beispiel wird der Zeiger mit der Adresse des Elements in der Mitte der Tabelle durch Hinzufügen der Hälfte der Byte-Anzahl der vorausgehend festgelegten Tabelle zum in AD_TAB enthaltenen Wert initialisiert. Anschließend wird der vom Zeiger abgelesene Referenzcode mit dem zu suchenden verglichen. Je nach Ergebnis bewegt sich der Zeiger vor- bzw. rückwärts und zeigt dann in die Mitte der restlichen noch zu durchsuchenden Zone. Durch diesen Mechanismus kann bei der Suche einer Codereferenz in einer Tabelle Zeit gewonnen werden. Wenn also die Tabelle n geordnete Elemente besitzt, führt die klassische Suchmethode, bei der von einem Element zum nächsten übergegangen wird, durchschnittlich zum Ablesen von n/2 Elementen bis das richtige gefunden wird. Durch eine wie oben aufgezeigte Suche können durch Ablesen (log n) Elemente gesucht werden, was einen Vorteil darstellt, wenn der Wert n groß ist.
  • Wenn nach dem Abtasten der gesamten Tabelle kein gelesener Wert in der Tabelle die gesuchte Referenz „A" besitzt, findet kein Sprung des Hauptprogramms zur Codefolge „A" statt, und ein Sprungindikator DI im Arbeitsspeicher ist in diesem Fall in inaktiver Position.
  • Diese Anordnung verpflichtet den Programmierer, gleich bei der ersten Eintragung einer Codefolge die Größe der Richtungstabelle derart vorzusehen, dass nach dem Wert von AD_TAB ausreichend Speicherplatz bleibt, um diese Tabelle zu ergänzen und gegebenenfalls weitere Codefolgen zu schreiben.
  • Eine Ausführungsvariante einer Richtungstabelle kann zum Beispiel nur die Codereferenz enthalten. In diesem Fall berechnet das Befragungsbefehlprogramm unter Anwendung eines Algorithmus, der die Codereferenz als Eingangsparameter hat, die Sprungadresse.
  • 7 zeigt ein anderes Beispiel einer Richtungstabelle, das dem Programmierer erspart, im Speicher Ta Ta die der Tabellengröße entsprechende Information vorzusehen oder ein Vorab-Lesen der Tabelle durchzuführen, um deren Größe zu bestimmen. Diese Tabelle enthält Richtungswörter mit einem Feld mehr als die drei vorausgehenden Felder: Referenzcodewert, Anfangsadresse der Codefolgen und Kontrollsumme (Check-Sum). Das zusätzliche Feld, das zum Beispiel das vierte und fünfte Byte einnimmt, enthält den Adressenwert des folgenden Elements in der Richtungstabelle. Die Tabelle ist auf folgende Weise abzulesen: das der ersten Codefolge entsprechende Richtungswort befindet sich an der Adresse AD_TAB, der Referenzcode ist „A" und die Folge beginnt an der Adresse AD_Cod_A, das nächste Richtungswort befindet sich an der Adresse AD_TT2. An dieser Adresse AD_TT2 befindet sich das der zweiten Codefolge entsprechende Wort mit dem Referenzcode „B", wobei die Codefolge an der Adresse AD_Cod_B beginnt. Das nächste Wort befindet sich an der Adresse AD_TT3 und so weiter. Das Tabellenende ist erreicht, wenn der Adressenwert des nächsten Richtungswortes zum Beispiel „NULL" ist. Bei diesem Beispiel ist darauf hinzuweisen, dass die mit „C" und „D" bezeichneten Codefolgen zum selben Block gehören. Dieser Block besitzt in Wirklichkeit zwei Eingangspunkte: AD_Cod_C und AD_Cod_D.
  • Es ist durchaus vorstellbar, dass eine oder mehrere Codefolgen oder Teile von Folgen in der Datenzone des programmierbaren Speichers geschrieben werden. In diesem Fall wird empfohlen, diese in einer gut abgegrenzten und einer als solche vom Applikationsbereich des Hauptprogramms bekannten Zone anzuordnen und gegebenenfalls aus Sicherheitsgründen das Lesen von außen zu untersagen.
  • Anhand 8 wird nun der Ablauf einer Richtungsbefehlfolge erklärt. Im Schritt 11 testet die Richtungsfolge den Sprungindikator DI. Wenn er inaktiv ist, fährt das Hauptprogramm dementsprechend fort. Wenn der Sprungindikator DI aktiv ist, wird die Folge mit Schritt 12 durch ein Speichern der Rücksprungadresse zum Hauptprogramm fortgesetzt. Dieses Speichern ist nicht zwingend, da ohnehin die Folge über die Rücksprungadresse in das Hauptprogramm oder an eine andere Stelle entscheidet. Wenn mehrere Richtungsbefehlfolgen dieselbe Codefolge aufrufen können, ist es von Interesse, die für jede Richtungsbefehlfolge spezifische Rücksprungadresse zu speichern, so dass man in die Nähe des Befehls zurückkommen kann, der den Sprung verursacht hat. Diese Speicherung kann in einem Arbeitsregister AD_RET oder in einem Stapel erfolgen. Bei Letzterem wird die im programmierbaren Speicher gespeicherte Codefolge als ein Unterprogramm betrachtet, das zum Beispiel mit einem spezifischen „Unterprogramm-Rücksprung"-Code („RTS") endet. Im Schritt 13 endet die Richtungsfolge dann durch einen Sprung zur Codefolge, die bei der im Register des Arbeitsspeichers AD_SAUT durch eine vorausgehende Befragungsfolge gespeicherte Adresse beginnt.
  • Im Folgenden werden das Eintragen von neuen Codefolgen und das Aktualisieren der Richtungstabelle erläutert.
  • Ein Codefolgenspeicherbefehl ECR_SEQ_E wird von außen durch die Eingangs- und Ausgangsvorrichtung (13) an die Karte geschickt. Die Daten dieses Befehls gliedern sich, wie in 9 dargestellt, in mehrere Felder auf. Der Befehl ECR_SEQ_E umfasst:
    • – in einem ersten Feld den Referenzcode: „A", „B", ...,
    • – in einem zweiten Feld die Anfangsadresse der Folge,
    • – in einem dritten fakultativen Feld die Größe der Folge, d. h. die Anzahl der zu schreibenden Bytes,
    • – und in einem vierten fakultativen Feld die Folge, d. h. die zu schreibenden Bytes.
  • Das dritte und vierte Feld sind überflüssig, wenn die Codefolge bereits im nichtflüchtigen Speicher (FRAM, EPROM, EEPROM oder ROM) vorhanden ist.
  • 10 zeigt ein Fließdiagramm, das den Ablauf des PENR-Ausführungsprogramms des Speicherbefehls ECR_SEQ_E einer neuen Folge E darstellt. In Schritt 21 wird der Befehl an die Karte geschickt und die ersten zwei Felder des Befehls werden analysiert. Nachdem die an die Karte geschickte Befehlsart von dieser erkannt wurde, kann das Verwaltungsprogramm der Speicherung prüfen, ob der Wert in AD_TAB in sich widerspruchsfrei ist. Wenn dem nicht so ist, ist die Richtungstabelle nicht einsatzbereit, so dass keine neue Codefolge geschrieben werden kann und der Befehl unterbrochen wird.
  • In Schritt 211 fährt das Programm mit dem nächsten Schritt fort, wenn ein ECA-Kennzeichen inaktiv ist, ansonsten wird die Ausführung des Programms unterbrochen.
  • In Schritt 22 kontrolliert das Speicherprogramm, ob bereits eine identische Referenz eingetragen wurde. Wenn die Tabelle bereits eine zur erhaltenen Codereferenz identische Codereferenz enthält, wird der Befehl unterbrochen. Diese besondere, der vorliegenden Erfindung eigene Kontrolle bietet einen reellen Vorteil in Bezug auf den eingangs beschriebenen Stand der Technik, da sie verhindert, versehentlich zwei Codefolgen mit derselben Referenz zu schreiben. Im Schritt 23 aktiviert das Verwaltungsprogramm des Speicherns ein Kennzeichen im nichtflüchtigen Speicher: ECA_en_cours (Schreiben eines Zusatzcodes in Bearbeitung) und zeigt somit an, dass gerade ein Abspeichern einer neuen Folge vorgenommen wird. Im Schritt 24 testet das Programm PENR dann die Anzahl der zu schreibenden Code-Bytes. Ist diese Anzahl gleich null, ist keine neue Codefolge zu schreiben und es muss nur eine neue Codereferenz in der Tabelle hinzugefügt werden. Dies ist der Fall bei der Aktivierung des „schlafenden" Codes im ROM oder beim Hinzufügen eines Eingangspunktes zu einer bereits im programmierbaren Speicher geschriebenen Codefolge.
  • Wenn die Anzahl der zu schreibenden Code-Bytes nicht null ist, wird die Karte im Schritt 25 auf Empfangsmodus geschaltet. Die Bytes werden aufgenommen, eventuell entschlüsselt und/oder mit Vorzeichen versehen, wenn dieser Modus gewählt wurde, und anschließend sofort an der im zweiten Feld des Befehls ECR_SEQ_E definierten Anfangsadresse der Folge geschrieben. In jedem Fall muss die Schreibadresse leer sein, ansonsten wird der Befehl unter Belassen des Kennzeichens ECA_en_cours im aktiven Zustand unterbrochen, was mit Ausnahme des im Folgenden beschriebenen Regenerierungsmechanismus ein endgültiges Blockieren der Karte zur Folge hat. Sobald alle Code-Bytes aufgenommen und die entsprechende Folge geschrieben wurde, prüft das Programm (PENR) im Schritt 26, ob das Schreiben ordnungsgemäß verlaufen ist. Ein Mittel dazu besteht darin, eine Kontrollsummenberechnung (CheckSum) oder ausgehend vom Wert der geschriebenen Bytes und ihrer Adressen eine Unterschrift zu erstellen. Im Schritt 27 testet das Programm (PENR) die Gültigkeit des gespeicherten Codes. Wenn das Schreiben nicht ordnungsgemäß verlaufen ist, wird der Befehl unter Belassen des Kennzeichens ECA_en_cours im aktiven Zustand unterbrochen.
  • Wenn das Schreiben ordnungsgemäß verlaufen ist, oder wenn keine Codefolge zu schreiben ist, aktualisiert das Programm PENR im Schritt 28 die Richtungstabelle und schreibt dazu das neue Richtungswort. Im in 6 beschriebenen Tabellenschema wird das neue Richtungswort sofort nach dem letzten Wort geschrieben. Das Programm PENR bestimmt das letzte Element und durchläuft dazu die Tabelle ab der Adresse AD_TAB und fährt gemäß der in SENS angegebenen Richtung fort. Die im dritten Feld des Richtungswortes geschriebene Kontrollsumme (CheckSum) kann ohne Unterschied von außen geschickt oder von der Karte berechnet werden. Bei dieser Kontrollsumme (CheckSum) kann es sich um eine einfache Summe oder um ein exklusives ODER (XOR) des Bytes oder um eine kryptographische Summe handeln, sie kann sich auf das Wort der Tabelle beziehen oder die diesem Wort zugeordnete Codefolge einschließen. Im in 7 beschriebenen Tabellenschema wird das neue Wort in eine leere Stelle der Zone der Folgen und Richtungswörter der Tabelle geschrieben. Das Programm PENR muss auch das dritte Feld des vorletzten Feldes der Tabelle ändern, damit es die Adresse AD_Cod_E dieser neuen Codefolge „E" enthält.
  • Wenn all diese Operationen ordnungsgemäß verlaufen sind, wird im Schritt 29 des Programms PENR das Kennzeichen ECA_en_cours inaktiviert, was als Hauptfolge zur Bestätigung der Richtungstabelle und der Folgen führt. Wenn der Befehl nicht ordnungsgemäß abgelaufen ist, informiert eine vom Programm PENR nach außen geschickte Fehlermeldung den Anwender über die Art des Fehlers.
  • Man sollte auf den Sonderfall zum Eintragen des Inhalts von AD_TAB und eventuell von SENS eingehen. Die vorausgehende Beschreibung trifft nämlich nur für eine bereits begonnene Richtungstabelle zu. Es wird noch mal darauf hingewiesen, dass AD_TAB die Anfangsadresse der Richtungstabelle enthält und dass, wenn diese gemäß 6 organisiert ist, das Feld SENS die Verlaufsrichtung in dieser Tabelle angibt.
  • Unter Anwendung des in 9 beschriebenen Datenformats kann man eine besondere Codereferenz benennen, um den Inhalt von AD_TAB und eventuell von SENS einzutragen. Stets in Bezugnahme auf 9 wäre das Feld AD_Cod_A für diese besondere Referenz nicht signifikant, während das den Code der Folge enthaltende Feld den in AD_TAB und eventuell SENS zu bringenden Inhalt enthalten würde.
  • Eine andere Vorgehensweise, die für die Eintragung von beliebigen Daten (Codefolge, Elemente der Richtungstabelle...) von Interesse wäre, wäre die Anwendung des folgenden Formats:
  • Figure 00210001
  • Diese Methode bietet den wesentlichen Vorteil, dass unter der Verantwortung des Erstellers eines Zusatzcodes beliebige Daten geschrieben werden können.
  • Zur Identifikation eines Betriebssystems oder gewisser Besonderheiten davon, wie z. B. die Anwendung eines Zusatzcodes, reicht es, wenn man die Karte, während sie unter Spannung gesetzt wird, Identifikations-Bytes schicken lässt. Das Unterspannungsetzen ist eine unerlässliche Operation, bevor man mit einer Karte dialogieren kann. Das Betriebssystem kann auf interne Art seine Antwort auf die Rückstellung durch die Analyse des Zeigers AD_SAUT der Richtungstabelle und der Tabelle selbst aufbauen.
  • Ein von außerhalb der Karte geschickter Ungültigkeitserklärungsbefehl INS_INA_C einer Codefolge hat zum Ziel, durch sein Bearbeitungsprogramm (PINA) einen einem bestimmten Referenzcode, zum Beispiel C, entsprechenden Sprung zu inaktivieren. Eine erste Vorgehensweise besteht darin, alle Daten bezüglich dieses Codes zu löschen: das Element in der Richtungstabelle und die gesamte entsprechende Folge, sowie anschließend die Richtungstabelle zu aktualisieren. Eine zweite, schnellere Vorgehensweise besteht darin, den der ungültig zu machenden Codefolge entsprechenden Referenzcode in der Richtungstabelle durch einen anderen Wert, wie z. B. „NULL" zu ersetzen. Da es diesen Code nicht mehr gibt, kann kein Befragungsbefehl den Arbeitsspeicher AD_SAUT aktualisieren, um diese Folge auszuführen. Schließlich besteht eine letzte Vorgehensweise darin, den Adressenwert in der Richtungstabelle durch einen unmöglichen Adressenwert, wie z. B. „NULL" zu ersetzen oder den Anrufer auf eine einfache Codefolge zu verweisen, welche „die Kontrolle wieder aufnimmt". Die zuletzt aufgeführte Vorgehensweise eignet sich bestens für die im ROM geschriebenen Codefolgen. Auf diese Weise kann dieser „schlafende" Code sehr einfach aktiviert und deaktiviert werden.
  • Ein von außerhalb der Karte kommender Regenerierungsbefehl INS_REG hat zum Ziel, durch sein Bearbeitungsprogramm PREG eine oder mehrere Codefolgen und/oder Tabellenelemente oder ganz allgemein eine Datenfolge zu löschen. Dazu sind mehrere Methoden möglich: die Anfangs- und Endadressen eines Speicherplatzes werden an die Karte geschickt, und alle Bytes dieses Bereichs werden gelöscht. Diese etwas „brutale" Art muss mit Vorsicht verwendet werden, um Folgen, die nicht gelöscht werden dürfen, nicht unverwendbar zu machen. Eine andere Methode besteht darin, der Karte die zu löschenden Referenzcodes sowie, soweit vorhanden, die entsprechenden Codefolgen im programmierbaren Speicher genau anzugeben. Nach einem solchen Befehl muss das Programm die entsprechende Adresse der Tabellenelemente bestimmen, diese Elemente löschen und die Anfangs- und Endandressen der Codefolgen bestimmen und schließlich den Inhalt löschen. Die Suchmethode dieser Adressen sowie die Aktualisierungsweise der Tabelle hängen stark von der Struktur der Richtungstabelle ab, siehe 6 und 7. Die Methode stellt für den Fachmann kein Problem dar und braucht daher nicht weiter erläutert zu werden.
  • Ein letzter Befehl REC_ESP_VRG, der das Aktualisieren der Tabelle und der Codefolgen vereinfachen kann, ist die sogenannte „Suche nach leeren Platz". Durch diesen ohne besondere Daten an die Karte geschickten Befehl kann man das Verarbeitungsprogramm PREV dieses Befehls die leeren Speicherplätze des programmierbaren Speichers (11) mit den Anfangs- und Endadressen jedes einzelnen Platzes nach außen schicken lassen. Der Anwender, der Codefolgen anfügen möchte, kann nach diesem Befehl prüfen, ob der vorhandene Platz ausreicht und die Codefolge gemäß ihrer Einbindungsadresse definieren.
  • In einer Ausführungsvariante, die die Kontrolle der Ganzzahligkeit der Zusatzcodefolge ermöglicht, müssen also kurz vor Ausführen des Sprungs in die Richtungsbefehlfolge in jedem Element der Richtungstabelle zwei zusätzliche Felder vorgesehen werden.
  • Hierbei gibt ein erstes zusätzliches Feld die Größe der dem Element zugeordneten Zusatzcodefolge an und ein zweites zusätzliches Feld enthält die richtige ursprüngliche Kontrollsumme (CheckSum).
  • Wenn die berechnete Kontrollsumme (CheckSum) von der ursprünglichen abweicht, stoppt das Betriebssystem die Ausführung und gibt dazu ein geeignetes Zustandswort als Signal ab. Diese Methode bietet den Vorteil, dass vor jeder Ausführung der neuen Codefolge eine Kontrolle durchgeführt wird, sie verlängert allerdings die Ausführungsdauer des betreffenden Befehls oder kann sich auf diese Kontrolle während ausschließlich der ersten Ausführung beschränken.
  • Die zweite Methode besteht darin, über einen zugeordneten Befehl zu verfügen, der eine Berechnung der Kontrollsumme (CheckSum) einer programmierbaren Speicherzone durchführt und den berechneten Wert mit dem bereitgestellten oder vorab in das Feld CHK_X geschriebenen vergleicht. Auf diese Weise kann der Systemverwalter regelmäßig diesen Befehl aktivieren, um sicherzustellen, dass alles in Ordnung ist.
  • Ein Betriebssystem, welches den Speicher- und Ausführungsmechanismus von Zusatzcodes beinhaltet, kann gedrosselt werden, um durch Verbotsriegel im programmierbaren Speicher seine Kapazitäten zu reduzieren. Dazu zählen zum Beispiel:
    • – CAI: Zusatzcode verboten, der vom Betriebssystem vor jedem Speichern getestet wird,
    • – RCI: Kartenregenerierung verboten, der vom Betriebssystem vor jeder Regenerierung getestet wird.
  • Diese Riegel können hinsichtlich ihrer Verwaltung mit Verwaltungsriegeln (locks) der Lebensphasen der Betriebssysteme der Karten verglichen werden.
  • Eine Anwendungsmöglichkeit besteht darin, einen Zusatzcode im EEPROM (11) zu laden und die Verbotsriegel RCI und CAI anzubringen, um diesen hinzugefügten Code endgültig festzulegen.
  • Natürlich beschränkt sich die Erfindung in keinster Weise auf das vorab beschriebene Ausführungsbeispiel, sondern umfasst ganz im Gegenteil alle Mittel, die den vorausgehend genau beschriebenen Mitteln sowie deren Kombinationen technisch gleichwertig sind, wenn diese im Sinne der Erfindung ausgeführt und im Rahmen der folgenden Ansprüche eingesetzt werden.

Claims (11)

  1. Vorrichtung zur Ausführung von Codefolgen in einem Datenträger mit einer zur Ausführung von Codefolgen fähigen integrierten Schaltung (10) und einerseits einem ersten Speicher (12) mit einem Hauptprogramm und eventuell weiteren von der integrierten Schaltung ausführbaren Codefolgen und andererseits einem programmierbaren permanenten zweiten Speicher (11), der eventuell von der integrierten Schaltung ausführbare Codefolgen enthält, und einem dritten Arbeitsspeicher (14), dadurch gekennzeichnet, dass eine im zweiten Speicher (11) enthaltene Richtungstabelle mindestens ein Feld mit Codereferenzdaten enthält: wobei erste Mittel (INS_INT) ermöglichen: – das Vorhandensein einer Codereferenz zu prüfen, – im Arbeitsspeicher die der Codereferenz zugeordneten Adressdaten zu speichern und einen Sprungindikator DI zu positionieren, und zweite Mittel (INS_ORT) ermöglichen: – den Sprungindikator DI zu testen und – den Sprung zu der vom Inhalt des Arbeitsspeichers AD_SAUT angezeigten Adresse durchzuführen.
  2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die der Codereferenz zugeordneten Adressdaten einer in einem der drei Speicher enthaltenen Codefolge ausgehend von der Codereferenz berechnet werden.
  3. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass ein zweites Feld die Adressdaten einer in einem der drei Speicher enthaltenen Codefolge enthält.
  4. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass sie in einer eventuell geschützten Zone des programmierbaren Speichers (11) eine Information (AD_TAB) enthält, die die erste Adresse und eventuell die Suchrichtung (SENS) für die ersten Prüfmittel definiert.
  5. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die Richtungstabelle ein zusätzliches Feld (AD_TT) umfasst, das die nächste Adresse in der Tabelle angibt, an der sich die der nächsten Codereferenz entsprechenden Informationen befinden.
  6. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die Richtungstabelle ein zusätzliches Feld (CHK) umfasst, das die Ganzzahligkeit der vorausgehenden Felder und/oder der zugehörigen Codefolge im Vergleich zu dem von einem Rechenmittel einer Kontrollsumme bereitgestellten Ergebnis gewährleistet.
  7. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die zweiten Mittel Mittel zum Speichern im Arbeitsspeicher (AD_RET) einer Rücksprungadresse nach einem Sprung umfassen, wenn mehrere zweite Mittel vorhanden sind, um einen Sprung zur selben Sequenzadresse zu machen.
  8. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass sie Mittel CAI zum Verhindern des Speicherns eines zusätzlichen Codes umfasst sowie Mittel RCI zum Verhindern einer Regenerierung der Karte.
  9. Speicherverfahren eines neuen Codes in einer Vorrichtung nach Anspruch 4, dadurch gekennzeichnet, dass es in folgendem besteht: – Aufnehmen eines Speicherbefehls; – Prüfen, ob ein erstes Feld vorhanden ist, das die Codereferenz A, B, C ... bildet und ob ein zweites Feld vorhanden ist, das die der Codereferenz AD_Cod_A, AD_Cod_B, AD_Cod_C ... zugeordnete Adresse darstellt; – Prüfen, ob kein ECA-Kennzeichen aktiv ist; – Prüfen, ob der Wert der ersten Adresse AD_TAB in sich widerspruchsfrei ist; – Kontrollieren, ob die vom ersten Feld bereitgestellte Referenz nicht in der Tabelle existiert; – Positionieren des ECA-Kennzeichens in den aktiven Zustand in der geschützten programmierbaren Speicherzone; – Aufnehmen und Schreiben der dem neuen Code entsprechenden Informationen; – Prüfen, ob der Vorgang richtig abgelaufen ist und Aktualisieren der Richtungstabelle; – Positionieren des ECA-Kennzeichens in den inaktiven Zustand.
  10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass der Aktualisierungsvorgang der Tabelle ein Schreiben des nächsten Adressfelds in der Richtungstabelle an der Adresse umfasst, die dem Richtungswort des dem geschriebenen Code vorausgehenden Codes entspricht.
  11. Computerprogrammprodukt für eine Vorrichtung mit Mikroschaltung, welche folgendes umfasst: – eine zur Ausführung von Codefolgen fähige integrierte Schaltung (10); – einen ersten Speicher mit einem Hauptprogramm und eventuell weiteren von der integrierten Schaltung ausführbaren Codefolgen; – einen programmierbaren permanenten zweiten Speicher (11) mit eventuell von der integrierten Schaltung ausführbaren Codefolgen; und – einen dritten Arbeitsspeicher dadurch gekennzeichnet, dass das Computerprogrammprodukt folgendes umfasst: – eine Richtungstabelle für den zweiten Speicher, wobei die Richtungstabelle mindestens ein Feld enthält, das Codereferenzdaten umfasst, – eine Reihe von Anleitungen, welche, wenn sie auf die Vorrichtung mit Mikroschaltung geladen werden, die Mikroschaltung dazu veranlassen, folgende Operationen auszuführen: – Prüfen, ob eine Codereferenz vorhanden ist; – Speichern im Arbeitsspeicher der der Codereferenz zugeordneten Adressdaten und Positionieren eines Sprungindikators DI; – Testen des Sprungindikators DI, – und Ausführen des Sprungs zur vom Inhalt des Arbeitsspeichers AD_SAUT angezeigten Adresse.
DE69729622T 1996-04-30 1997-04-29 Verfahren und gerät zur evolution eines programmes in rom Expired - Lifetime DE69729622T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9605454A FR2748134B1 (fr) 1996-04-30 1996-04-30 Procede et dispositif permettant a un programme fige de pouvoir evoluer
FR9605454 1996-04-30
PCT/FR1997/000759 WO1997041510A1 (fr) 1996-04-30 1997-04-29 Procede et dispositif permettant a un programme fige de pouvoir evoluer

Publications (2)

Publication Number Publication Date
DE69729622D1 DE69729622D1 (de) 2004-07-29
DE69729622T2 true DE69729622T2 (de) 2005-07-07

Family

ID=9491735

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69729622T Expired - Lifetime DE69729622T2 (de) 1996-04-30 1997-04-29 Verfahren und gerät zur evolution eines programmes in rom

Country Status (12)

Country Link
US (1) US6275982B1 (de)
EP (1) EP0838053B1 (de)
JP (1) JP3592335B2 (de)
KR (1) KR19990028574A (de)
CN (1) CN1109296C (de)
AU (1) AU2779697A (de)
BR (1) BR9702294A (de)
CA (1) CA2225786A1 (de)
DE (1) DE69729622T2 (de)
FR (1) FR2748134B1 (de)
NO (1) NO317558B1 (de)
WO (1) WO1997041510A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434738B1 (en) * 1999-04-22 2002-08-13 David Arnow System and method for testing computer software
JP2003507813A (ja) * 1999-08-24 2003-02-25 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ プログラムとデータの両方を格納する不揮発性メモリを有するデータ処理装置
US7266842B2 (en) * 2002-04-18 2007-09-04 International Business Machines Corporation Control function implementing selective transparent data authentication within an integrated system
FR2928754B1 (fr) * 2008-03-13 2012-05-18 Sagem Securite Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant
JP5824849B2 (ja) * 2011-04-22 2015-12-02 ソニー株式会社 情報処理装置および情報処理方法
US20140006867A1 (en) * 2012-06-29 2014-01-02 National Instruments Corporation Test Executive System With Process Model Plug-ins
US20160132251A1 (en) * 2014-11-11 2016-05-12 Wisconsin Alumni Research Foundation Operating method of storage device and data writing method for writing data into storage device
CN108446242A (zh) * 2018-03-07 2018-08-24 珠海昇生微电子有限责任公司 一种固化代码的替换方法及系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01273136A (ja) * 1988-04-26 1989-11-01 Oki Electric Ind Co Ltd オペレーティングシステムのファームウェア化方式
US5615349A (en) * 1990-09-04 1997-03-25 Mitsubishi Denki Kabushiki Kaisha Data processing system capable of execution of plural instructions in parallel
US5202923A (en) 1989-11-30 1993-04-13 Kabushiki Kaisha Toshiba Portable electronic device capable of registering subprograms
FR2667417B1 (fr) 1990-10-02 1992-11-27 Gemplus Card Int Carte a microprocesseur concue pour recevoir des programmes multiples en memoire programmable.
FR2668274B1 (fr) * 1990-10-19 1992-12-31 Gemplus Card Int Circuit integre a securite d'acces amelioree.
FR2676294B1 (fr) * 1991-05-06 1993-07-16 Gemplus Card Int Procede de verrouillage pour carte a memoire.
TW261687B (de) * 1991-11-26 1995-11-01 Hitachi Seisakusyo Kk
KR950003013B1 (ko) * 1992-03-30 1995-03-29 삼성전자 주식회사 틀림정정회로를 가지는 이이피롬
FR2700040B1 (fr) * 1992-12-31 1995-02-17 Gemplus Card Int Carte à puce avec données et programmes protégés contre le vieillissement.
US5829013A (en) * 1995-12-26 1998-10-27 Intel Corporation Memory manager to allow non-volatile memory to be used to supplement main memory
US5901330A (en) * 1997-03-13 1999-05-04 Macronix International Co., Ltd. In-circuit programming architecture with ROM and flash memory

Also Published As

Publication number Publication date
CN1189901A (zh) 1998-08-05
NO317558B1 (no) 2004-11-15
WO1997041510A1 (fr) 1997-11-06
CA2225786A1 (en) 1997-11-06
BR9702294A (pt) 1999-07-20
FR2748134A1 (fr) 1997-10-31
AU2779697A (en) 1997-11-19
KR19990028574A (ko) 1999-04-15
DE69729622D1 (de) 2004-07-29
EP0838053A1 (de) 1998-04-29
JPH10510652A (ja) 1998-10-13
NO976126L (no) 1998-02-27
FR2748134B1 (fr) 1998-06-26
JP3592335B2 (ja) 2004-11-24
US6275982B1 (en) 2001-08-14
CN1109296C (zh) 2003-05-21
NO976126D0 (no) 1997-12-29
EP0838053B1 (de) 2004-06-23

Similar Documents

Publication Publication Date Title
DE69835879T2 (de) Multifunktionschipkarte mit delegierungsmerkmal
EP1011080B1 (de) Verfahren zum bidirektionalen Datentransfer zwischen einem Terminal und einer Chipkarte sowie Chipkarte
DE2551239C3 (de) Datenverarbeitungsanlage
DE3805291A1 (de) Tragbare elektronische vorrichtung
DE1499175A1 (de) Digitalrechner-Datenverarbeitungszentralanlage
DE19536169A1 (de) Multifunktionale Chipkarte
DE3640238A1 (de) Tragbare elektronische vorrichtung
DE3102150A1 (de) "schaltungsanordnung mit einem cachespeicher fuer eine zentraleinheit einer datenverarbeitungsanlage
EP0010186B1 (de) Vorrichtung zum Bearbeiten bezeichneter Hinweise
DE2151472A1 (de) Mikroprogrammspeicher fuer Elektronenrechner
DE69931297T2 (de) Verfahren und System zum mehrmals Lesen einer Sammlung von Etiketten mit verschiedenen Identifikationskoden
DE102006029690A1 (de) Beibehaltung einer Identifikation einer elektronischen Steuereinheit bei Umprogrammierungsereignissen
DE69729622T2 (de) Verfahren und gerät zur evolution eines programmes in rom
DE102009033961A1 (de) Emulation eines einmal programmierbaren Speichers
DE3511683A1 (de) Elektronisch programmierbarer rechner mit einem speicherpaket
DE10324337B4 (de) Rechnersystem und zugehöriges Verfahren zum Durchführen eines Sicherheitsprogramms
DE69932412T2 (de) Chipkartenkonfiguration
EP0935214B1 (de) Chipkarte mit integrierter Schaltung
DE60224937T2 (de) Verfahren und anordnung zum verknüpfen von verwandelten appletdateien
DE3732614A1 (de) Verarbeitungssystem fuer tragbare elektronische vorrichtung
DE19626972A1 (de) Verfahren und Vorrichtung zur vorläufigen Freigabe für die Anwendung eines von einer elektronischen Kassette geschützten Programms
DE2136270A1 (de) Verfahren und Vergleicher zum Vergleich zweier Binärzahlen
DE10357257A1 (de) Java Smart Card Chip mit für globale Variablen reserviertem Speicherbereich
DE1965506A1 (de) Einrichtung und Verfahren zur Programmsteuerung eines elektronischen Digitalrechners
EP1559111B1 (de) Verfahren zum betreiben einer speicheranordnung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition