-
Die
Erfindung betrifft ein Verfahren zur Generierung von Programmcode
in einem Betriebssystemspeicher eines Datenträgers, insbesondere zur Generierung
von Maskencode in einem ROM eines tragbaren Datenträgers. Darüber hinaus
betrifft die Erfindung ein Verfahren zur Generierung von Applikationscode
in einem Applikationsspeicher eines Datenträgers, insbesondere in einem
nichtflüchtigen Speicher
eines tragbaren Datenträgers.
-
Insbesondere
bei tragbaren Datenträgern mit
geringer Speicherkapazität
ist es wünschenswert, beim Übersetzen
von Sourcecode in auf dem Datenträger zu speichernden Objektcode
entsprechende Optimierungen vorzunehmen, welche die Größe des Codes
vermindern. Zum einen sollte die Menge an Programmcode in dem Betriebssystemspeicher
des Datenträgers
möglichst
gering gehalten werden, wobei dieser Programmcode insbesondere als ROM-Maskencode
in einem ROM gespeichert wird. Zum anderen sollten in den Applikationsspeicher
des Datenträgers
nachladbare Programmapplikationen größenoptimiert im Hinblick auf
geringen Speicherbedarf sein.
-
Aus
dem Stand der Technik sind Verfahren bekannt, wie in geeigneter
Weise größere Mengen an
digitalen Daten effizient auf Übereinstimmung überprüft werden
können.
In dem Dokument
DE
100 45 926 A1 wird ein Verfahren zum Auffinden einer Anwendungsdatei
in dem Speicher einer Chipkarte beschrieben, wobei für den Dateibezeichner
der Anwendungsdatei ein Hashwert mit Hilfe einer Hashfunktion erzeugt
wird und zusammen mit dem Dateibezeichner auf der Chipkarte abgespeichert
wird. Dieser Hashwert wird bei der Suche nach den Anwendungdateien
verwendet, indem für
den in der Suchanfrage enthaltenen Dateibezeichner auch ein Hashwert
mit der gleichen Hashfunktion erzeugt wird und mit den auf der Chipkarte
abgelegten Hashwerten verglichen wird. Da die Hashwerte eine vordefinierte
Größe aufweisen,
die im Regelfall kleiner als die Größe der Bezeichner der Anwendungsdateien ist,
wird auf diese Weise eine schnelle Suche nach Dateien ermöglicht.
-
In
dem Dokument
GB 2 242
549 A ist die Verwendung von Hashwerten im Zusammenhang
mit Dateien in Datenbanken beschrieben. Für den Inhalt der einzelnen
Datenbankdateien werden Hashwerte erzeugt, welche mit dem Namen
der jeweiligen Datei verknüpft
werden. Hierdurch wird ein eindeutiger, vom Inhalt der Datei abhängiger Bezeichner
für die Datenbankdateien
geschaffen. Mit Hilfe dieses Bezeichners kann bei der Hinzufügung von
neuen Dateien in die Datenbank effizient überprüft werden, ob eine Datei mit
dem gleichen Inhalt bereits in der Datenbank existiert. Auf diese
Weise kann das Duplizieren von Daten in der Datenbank vermieden
werden.
-
Gemäß den oben
genannten Dokumenten ist es aus dem Stand der Technik bekannt, große Datenmengen
in komprimierter Form durch Hashwerte zu beschreiben. Die Hashwerte
werden dabei zur Erleichterung der Verwaltung der Daten genutzt.
-
Aus
der Veröffentlichung
von K. D. Cooper „Enhanced
code compression for embedded RISC processors”, ACM SIGPLAN Notices, vol.
34, iss 5 (May 1999), S. 139 bis 149, ist der Vorschlag bekannt,
Programmcode zu optimieren, indem sich wiederholende Programmfragmente
identifiziert und in eine „Repeat
Table” aufgenommen
werden, anhand derer die sich wiederholenden Programmfragmente dann
durch Verweise ersetzt werden.
-
Aufgabe
der Erfindung ist es, ein Verfahren zur Generierung von Programmcode
in dem Betriebssystemspeicher eines Datenträgers zu schaffen, wobei der
generierte Programmcode eine größenoptimierte
Erzeugung von Applikationscode auf dem Datenträger ermöglicht. Ferner ist es Aufgabe der
Erfindung, ein Verfahren anzugeben, mit dem größenoptimierter Applikationscode
in dem Applikationsspeicher eines Datenträgers erzeugt wird.
-
Diese
Aufgabe wird durch ein Verfahren gemäß dem Patentanspruch 1 sowie
ein Verfahren gemäß dem Patentanspruch
12 gelöst.
Des Weiteren wird die Aufgabe durch einen tragbaren Datenträger gemäß Patentanspruch
20 gelöst.
-
Erfindungsgemäß wird bei
der Generierung von Programmcode in dem Betriebsspeicher eines Datenträgers zunächst in
an sich bekannter Weise aus Quellcode Objektcode erzeugt. Anschließend wird
in dem Objektcode nach auszuzeichnenden Codesequenzen gesucht, die
für eine
Optimierung in Frage kommen. Vorzugsweise werden dazu Codegruppen
von übereinstimmenden
Code enthaltenden Codesequenzen identifiziert, wobei für jede aufgefundene
Codegruppe von übereinstimmenden
Code enthaltenden Codesequenzen der übereinstimmende Code vorzugsweise
in einem Speicherbereich eines Segments des Betriebssystemsspeichers
gespeichert wird. Desweiteren werden zweckmäßig auch nur einmal vorkommende
Codesequenzen als auszuzeichnende Codesequenzen identifiziert, die
in später
nachgeladenem Applikationscode typischerweise vorkommen.
-
Neben
der Identifizierung von auszuzeichnendem Code wird erfindungsgemäß ferner
eine Tabelle erzeugt, welche für
jeden identifizierte auszuzeichnende Codesequenz einen Hashwert
enthält, der
aus dem Code der zugehörigen
Codesquenzen mit einer vorgegebenen Hashfunktion erzeugt wird, sowie
zu diesem Hashwert eine oder mehrere Adressinformationen bezüglich des
Speicherbereichs des Codes im Segment des Betriebssystemspeichers. Diese
Tabelle ist ein wichtiges Ergebnis der Erfindung, da sie bei der
anschließenden
Generierung von größenoptimiertem
Applikationscode benötigt wird.
-
Der
Begriff „Hashwert” ist hier
und im Folgenden als ein Wert zu verstehen, der durch Anwenden einer
Hashfunktion auf eine Ursprungsdatenmenge generiert wird und eine
feste Länge
aufweist. Die Hashfunktion ist hierbei derart konstruiert, dass
sie weitestgehend eindeutig ist, d. h. für eine unterschiedliche Ursprungsdatenmenge
wird auch ein unterschiedlicher Hashwert erzeugt. Der Hashwert stellt somit
eine komprimierte Darstellung der ursprünglichen Datenmenge dar, und
dieser Wert ist vorzugsweise auch nicht auf die Ursprungsdatenmenge
rückrechenbar.
-
Zur
Optimierung des Objektcodes für
den Betriebssystemspeicher des Datenträgers wird dieser Code erfindungsgemäß derart
modifiziert, dass jede Codesequenz einer aufgefundenen Codegruppe
von übereinstimmenden
Code enthaltenden Codesequenzen durch einen Aufruf des übereinstimmenden
Codes im Speicherbereich des Segments des Betriebssystemspeichers
ersetzt wird. Der modifizierte Objektcode ist somit besonders klein,
da er übereinstimmenden
Code aus unterschiedlichen Sequenzen nur einmal aufweist. Dieser
optimierte Objektcode wird schließlich in an sich bekannter
Weise als Programmcode in dem Betriebssystemspeicher hinterlegt.
-
Das
erfindungsgemäße Verfahren
weist den Vorteil auf, dass zum einen der Code im Betriebssystemspeicher
optimiert wird und zum anderen Informationen in der Form einer Tabelle
aus diesem Code extrahiert werden, wobei diese Tabelle anschließend Dritten
bereitgestellt werden kann, welche die Tabelle zur Optimierung des
Codes für
den Applikationsspeicher nutzen. Obwohl er genutzt werden kann,
ist der eigentliche Code dabei im Betriebssystemspeicher für einen
damit befaßten
Applikationsentwickler nicht sicht bar. Der Code kann daher trotz
seiner Nutzbarkeit nicht ausspioniert werden.
-
Die
erfindungsgemäße Erzeugung
des Programmcodes für
den Betriebssystemspeicher wird insbesondere durch einen zur Codegenerierung
verwendeten Compiler und einen Linker durchgeführt. Der Aufruf des übereinstimmenden
Codes im Speicherbereich des Segments erfolgt in einer bevorzugten
Ausführungsform über den
aus dem übereinstimmenden
Code erzeugten Hashwert.
-
Die
in der Tabelle enthaltenen Adressinformationen bezüglich des
Speicherbereichs des übereinstimmenden
Codes enthalten in einer bevorzugten Ausführungsform die Startadresse
des übereinstimmenden
Codes in dem Segment sowie die Länge des übereinstimmenden
Codes. Gegebenenfalls können
auch noch weitere Informationen in der Tabelle enthalten sein, welche
eine geeignete Codeoptimierung bei der späteren Verwendung der Tabelle bei
der Erzeugung von Applikationsobjektcode ermöglichen. Beispielsweise können Debug-Informationen
zum Auffinden von Programmfehlern in der Tabelle enthalten sein.
-
Zur
einfachen Identifikation von Codesequenzen wird in einer bevorzugten
Ausführungsform der
Erfindung eine RETURN-Anweisung im Objektcode verwendet, d. h. eine
Codesequenz ist durch den Code zwischen zwei aufeinander folgenden
RETURN-Anweisungen definiert.
-
In
einer weiteren, besonders bevorzugten Ausgestaltung der Erfindung
werden die aus dem Objektcode erstellten Hashwerte neutral gegenüber den
im Code verwendeten Registerangaben gehalten. Dies geschieht dadurch,
dass aus im Objektcode verwendeten Registerangaben Pseudoadressen
erzeugt werden und für
die Erzeugung der Hashwerte aus den Codesequenzen die Registerangaben
durch die Pseudoadressen ersetzt werden. Um bei einer späteren Erzeugung
von Applikationsobjektcode die ursprünglichen Registerangaben wieder
verwenden zu können,
werden die Registerangaben und die Pseudoadressen ebenfalls in der
Tabelle hinterlegt. Vorzugsweise sind die Pseudoadressen auch Hashwerte,
welche mit einer geeigneten Hashfunktion generiert werden.
-
In
einer weiteren, bevorzugten Ausführungsform
der Erfindung wird eine Codemindestgröße festgelegt, wobei in dem
Objektcode nur nach Codegruppen gesucht wird, deren übereinstimmender
Code größer oder
zumindest genauso groß wie
die Codemindestgröße ist.
Um sicherzustellen, dass der Aufruf des übereinstimmenden Codes weniger
Speicherplatzbedarf als der übereinstimmende
Code benötigt,
wird die Codemindestgröße vorzugsweise derart
gewählt,
dass sie der Länge
von jeweiligen Aufrufen des übereinstimmenden
Codes entspricht.
-
Die
mit dem erfindungsgemäßen Verfahren erzeugte
Tabelle kann zur Generierung von größenoptimiertem Applikationscode
in einem Applikationsspeicher eines Datenträgers, insbesondere in dem nichtflüchtigen
Speicher eines tragbaren Datenträgers,
eingesetzt werden. Es kann hierbei die gesamte Tabelle, jedoch nach
Anwendungsfall auch nur ein Teil der Tabelle benutzt werden. Im
Folgenden wird der Begriff eines Abschnitts einer Tabelle verwendet, wobei
ein Abschnitt sowohl die gesamte Tabelle als auch nur Teile der
Tabelle umfassen kann. Dieser Abschnitt steht dem Verfahren zur
Generierung von Applikationscode zur Verfügung.
-
Bei
der Erzeugung von Applikationscode wird zunächst in an sich bekannter Weise
aus Applikationsquellcode Applikationsobjektcode erzeugt. Anschlie ßend werden
aus den Codesequenzen im Applikationsobjektcode jeweils Hashwerte
generiert, wobei zur Erzeugung der Hashwerte die gleiche Hashfunktion
wie in dem oben beschriebenen Verfahren zur Generierung von Programmcode
im Betriebssystemspeicher eingesetzt wird. Für gleichen Code wird somit
auch der gleiche Hashwert erzeugt.
-
Schließlich erfolgt
ein Vergleich der aus den Codesequenzen des Applikationsobjektcodes
erzeugten Hashwerte mit den Hashwerten des Abschnitts der Tabelle,
um übereinstimmende
Hashwerte zu ermitteln. Anschließend wird ein modifizierter Applikationsobjektcode
derart erzeugt, dass eine Codesequenz, deren daraus erzeugter Hashwert
mit einem Hashwert des Abschnitts der Tabelle übereinstimmt, durch einen entsprechenden
Verweis ersetzt wird, der auf die zu dem übereinstimmenden Hashwert in
der Tabelle enthaltenen Adressinformationen verweist. Auf diese
Weise wird der Applikationsobjektcode entsprechend minimiert, da übereinstimmende
Codesequenzen mit einem platzsparenden Verweis auf die Adresse des
Betriebssystemspeichers ersetzt werden. Schließlich wird der auf diese Weise
modifizierte Applikationsobjektcode als Applikationscode in dem
Applikationsspeicher gespeichert. Analog zu dem oben beschriebenen
Verfahren zur Generierung von Programmcode für den Betriebssystemspeicher
erfolgt die Generierung des Applikationscodes vorzugsweise durch
einen Compiler und einen entsprechenden Linker.
-
Mit
Hilfe der gemäß der Erfindung
erzeugten Tabelle können
nunmehr externe Dritte optimierten Programmcode für den entsprechenden
Datenträger erzeugen.
Um Missbrauch bzw. Ausspionieren des Programmcodes auf dem Betriebssystemspeicher basierend
auf der Tabelle zu vermeiden, wird in einer bevorzugten Ausführungsform
der Abschnitt der Tabelle verschlüsselt und die aus den Codesequenzen des
Applikationsobjektcodes erzeugten Hashwerte werden mit Hilfe eines
Programms mit den Hashwerten des verschlüsselten Abschnitts der Tabelle
zur Ermittlung von übereinstimmenden
Hashwerten verglichen, wobei von dem Programm bei Ermittlung eines übereinstimmenden
Hashwerts die zu dem übereinstimmenden
Hashwert in der Tabelle enthaltenen Adressinformationen und/oder
der Verweis auf diese Adressinformationen ausgegeben werden. Auf
diese Weise wird ein gekapseltes Programm geschaffen, in dem verschlüsselt die Überprüfung der
Hashwerte auf Übereinstimmung
abläuft.
-
In
einer bevorzugten Ausführungsform
des Verfahrens zur Generierung von Applikationscode werden im Applikationsobjektcode
enthaltene Registerangaben durch die oben beschriebenen Pseudoadressen
ersetzt. Diese Adressen sind vorzugsweise Hashwerte, die mit der
gleichen Hashfunktion wie die Pseudoadressen der Registerangaben
im Objektcode des Betriebssystemspeichers erzeugt wurden. Im modifizierten
Applikationsobjektcode werden die Pseudoadressen anschließend durch
Zugriff auf die Tabelle, welche die Pseudoadressen enthält, mit
den Registerangaben rückersetzt,
um hierdurch ausführbaren
Applikationsobjektcode zu erzeugen.
-
Analog
zu dem oben beschriebenen Verfahren zur Generierung von Code auf
dem Betriebssystemspeicher werden die Codesequenzen des Applikationsobjektcodes
ebenfalls vorzugsweise durch eine RETURN-Anweisung spezifiziert,
wobei diese Anweisung das Ende einer Codesequenz anzeigt.
-
Gegebenenfalls
kann auch bei der Erzeugung von Applikationsobjektcode eine Codemindestgröße festgelegt
werden, wobei in dem Applikationsobjektcode nur Hashwerte für Codesequenzen
generiert werden, deren Code größer oder
zumindest genauso groß wie
die Codemindestgröße ist.
Die Codemindestgröße entspricht
dabei vorzugsweise der Länge
von jeweiligen Verweisen auf Adressinformationen. Auf diese Weise
ist sichergestellt, dass nur solche Verweise im Applikationsobjektcode
generiert werden, welche kürzer
als die ursprüngliche
Codesequenz sind.
-
Neben
den oben beschriebenen Verfahren betrifft die Erfindung ferner einen
Datenträger,
insbesondere einen tragbaren Datenträger, mit einem Betriebssystemspeicher,
wobei der Betriebssystemspeicher Programmcode enthält, der
mit dem oben beschriebenen Verfahren zur Generierung von Programmcode
im Betriebssystemspeicher erzeugt ist. Vorzugsweise enthält der Datenträger ferner
auch einen Applikationsspeicher, der Applikationscode enthält, der
mit dem oben beschriebenen Verfahren zur Generierung von Applikationscode
erzeugt ist.
-
Ausführungsbeispiele
der Erfindung werden nachfolgend anhand der beigefügten Figuren
detailliert beschrieben.
-
Es
zeigen:
-
1 eine
schematische Darstellung, welche die Generierung von Objektcode
aus Sourcecode für
den Betriebssystemspeicher einer Chipkarte in einer Ausführungsform
der Erfindung wiedergibt;
-
2 eine
schematische Darstellung, welche die Modifikation von Objektcode
und dessen Speicherung als ROM-Maskencode sowie die Generierung
einer Hash-Tabelle gemäß einer
Ausführungsform
der Erfindung verdeutlicht; und
-
3 eine
schematische Darstellung, welche die Erzeugung von Applikationscode
für einen nichtflüchtigen
Speicher einer Chipkarte mit Hilfe der Hash-Tabelle gemäß einer
Ausführungsform
der Erfindung wiedergibt.
-
Das
erfindungsgemäße Verfahren
wird nachfolgend für
die Erzeugung von Programmcode auf einer Chipkarte erläutert. Das
Verfahren besteht aus zwei wesentlichen Bestandteilen. Der erste
Teil betrifft die Erzeugung von ROM-Maskencode in einem entsprechenden ROM
auf einer Chipkarte. Der ROM-Maskencode
beinhaltet das Betriebssystem der Chipkarte, auf dessen Basis Steuervorgänge der Chipkarte,
wie die Datenübertragung
von und zur Chipkarte und die Dateiverwaltung auf der Chipkarte und
dergleichen, durchgeführt
werden. In der hier beschriebenen Ausführungsform wird eine Chipkarte mit
einem nachladbaren nichtflüchtigen
Speicher betrachtet, wobei entsprechende Applikationen für die Chipkarte
auf dem nichtflüchtigen
Speicher unabhängig
vom Betriebssystem hinterlegt werden können. Ziel des nachfolgend
beschriebenen Verfahrens ist es nunmehr, einen optimierten Programmcode
für das
Betriebssystem der Chipkarte zu generieren, der wiederum eine platzsparende
Codeoptimierung des nachladbaren Applikationscodes im nichtflüchtigen Speicher
der Chipkarte ermöglicht.
-
Mit
Bezug auf 1 und 2 wird zunächst die
Codeoptimierung des ROM-Maskencodes beschrieben. Diese Optimierung
läuft im
Wesentlichen im Compiler und Linker ab, welche den ursprünglichen
Quelicode in Objektcode übersetzen. 1 zeigt
den Schritt der Wandlung von Quellcode SC des Betriebssystems in
Objektcode OC1 mit Hilfe des Compilers. Der Quellcode liegt in der
Form einer Mehrzahl von Quelldateien 1, 2, 3 vor,
welche mit dem Compiler in an sich bekannter Weise in den Objektcode
OC1 übersetzt
werden. Dieser Objektcode ist ausschnittsweise in 1 wiedergegeben
und umfasst eine Vielzahl von Codesequenzen 101, 102, 103 und 104.
Eine Codesequenz ist hierbei ein Codeabschnitt, der sich von einem
RETURN im Objektcode bis zum nächsten
RETURN erstreckt. Anfang und Ende einer Codesequenz können aber
auch gemäß anderen
Regeln festgelegt sein. Beispielsweise kann vorgesehen sein, daß Funktionen
trotz mehrerer enthaltener RETURNs als eine Codesequenz behandelt
werden, oder daß etwa
C-Funktion stets
als ganzes als Codesequenz angesehen werden, unabhängig von
der Zahl der in ihr enthaltenen RETURNs; denkbar ist ferner auch
eine individuelle, manuelle Definition von Codesequenzen.
-
Es
kann nunmehr der Fall auftreten, dass einzelne Codesequenzen identischen
Code enthalten. Ein solches Szenario ist in 1 wiedergegeben,
wobei die Codesequenzen 101 und 102 den gleichen
Code C1 und die Codesequenzen 103 und 104 den
gleichen Code C2 enthalten. Solche Codesequenzen mit gleichem Code
werden erfindungsgemäß mit dem
verwendeten Linker als auszuzeichnende Codesequenzen identifiziert.
Auf diese identifizierten Codesequenzen wird zur Erzeugung eines Hashwerts
eine Hashfunktion angewendet, beispielsweise die Funktion SHA1.
Eine Hashfunktion erzeugt aus einer großen Datenmenge einen Kompaktbezeichner
dieser Datenmenge mit fester Länge,
wobei der Kompaktbezeichner im Idealfall immer eine eindeutige Identifikation
der Datenmenge darstellt.
-
Zweckmäßig ist
vorgesehen, daß auch
zumindest ein Teil der nur einmal vorkommende Codesequenzen als
auszuzeichnende Codesequenzen identifiziert werden kann und entsprechend
Hashwerte dazu gebildet werden. Die Identifikation entsprechender
auszuzeichnender Codesequenzen kann z. B. erfolgen, wenn sie eine
Mindestgröße aufweisen
oder sie typischerweise in später
nachgeladenem Applikationscode zu erwarten sind.
-
Die
Hashwerte können
gegebenenfalls bereits bei der Identifikation auf übereinstimmende Codesequenzen
generiert werden, wobei in diesem Fall für jede Codesequenz ein Hashwert
erzeugt wird und durch Vergleich der Hashwerte der Codesequenzen Übereinstimmungen
ermittelt werden. Vorzugsweise wird eine Codemindestgröße festgelegt,
welche derart gewählt
ist, dass nur für
Codesequenzen mit einer Größe, welche
größer oder
gleich der Mindestgröße ist,
auch ein Hashwert generiert wird. Für Codesequenzen unterhalb dieser
Codemindestgröße erfolgt
nicht die Generierung eines entsprechenden Hashwerts. Die Codemindestgröße entspricht hierbei
vorzugsweise der Länge
des weiter unten beschriebenen Aufrufs des übereinstimmenden Codes.
-
Gemäß 2 wurde
für den
Code C1 der Hashwert H1 und für
den Code C2 der Hashwert H2 generiert, welche in der Hash-Tabelle
HT enthalten sind. Die Erzeugung der Hash-Tabelle HT wird weiter unten
noch näher
beschrieben. In der Ausführungsform
der 2 wird durch den Linker festgestellt, dass in
dem ursprünglichen
Objektcode OC1 sowohl die beiden Codesequenzen 101 und 102 als
auch die beiden Codesequenzen 103 und 104 den
gleichen Code enthalten. Diese übereinstimmenden
Codes C1 für
die Sequenzen 101 und 102 und C2 für die Sequenzen 103 und 104 werden
anschließend
zweckmäßig in einem
Speichersegment 401 auf dem ROM 4 der Chipkarte
gespeichert. Wie schematisch im rechten unteren Teil der 2 angedeutet
ist, werden hierbei die Codes C1 bzw. C2 mit entsprechenden Labels
LA1 bzw. LA2 versehen, wobei diese Labels aus den entsprechenden
Hashwerten H1 bzw. H2 abgeleitet sind bzw. diesen Hashwerten entsprechen.
-
Soweit
nur einmal auftretende Codesequenzen mit Hashwerten versehen wurden,
können
diese ebenfalls in das Speichersegment 401 gespeichert werden;
alternativ werden sie nicht verschoben.
-
Um
nunmehr die Größe des ursprünglichen Objektcodes
OC1 zu optimieren, werden die ursprünglichen übereinstimmenden Codesequenzen im
Objektcode OC1 durch Aufrufe ersetzt, mit denen die entsprechenden,
in dem Segment 401 gespeicherten Codes der Codesequenzen
aufgerufen werden. Zum Aufruf werden dabei die oben beschriebenen
Labels verwendet, und in 2 ist beispielhaft ein solcher
Aufruf als „Call
LA1” bezeichnet.
Da der Speicherbedarf für
einen solchen Aufruf wesentlich geringer als der ursprüngliche
Code in der Codesequenz ist, wird die Größe des ROM-Maskencodes vermindert. Der auf diese
Weise erzeugte optimierte Objektcode OC2 wird schließlich als
Programmcode im ROM 4 abgespeichert.
-
Parallel
zur Erzeugung des ROM-Maskencodes OC2 wird ferner die Hash-Tabelle HT in einem Dateiformat,
z. B. als Excel-Tabelle oder im XML-Format, erzeugt, wobei die Hash-Tabelle
zum einen für jeden
Code, der zumindest in zwei Codesequenzen mit entsprechender Codemindestgröße enthalten
ist, und zum anderen für
alle weiteren identifizierten Codes einen Eintrag enthält. In 2 sind
hierbei exemplarisch die Einträge
für die
Codes C1 und C2 gezeigt. Die erste Spalte von links der Hash-Tabelle
HT enthält
die Längen
der einzelnen Codes, wobei L1 die Länge des Codes C1 und L2 die
Länge des
Codes C2 bezeichnet. Die zweite Spalte von links enthält die Startadressen
der entsprechenden Codes im Segment 401, wobei A1 die Startadresse
des Codes C1 und A2 die Startadresse des Codes C2 bezeichnet. Schließlich folgen
in der dritten Spalte von links die entsprechenden Hashwerte H1
des Codes C1 und H2 des Codes C2. In der vierten Spalte von links sind
Debug-Informationen in der Form von Byte-Sequenzen BS1 für den Code
C1 und BS2 für
den Code C2 enthalten. Diese Debug-Informationen werden bei der
nachfolgend beschriebenen Generierung von Applikationscode in dem
nichtflüchtigen
Speicher der Chipkarte zur Fehlerbehebung verwendet. Wurden für die Festlegung
der Codesequenzen mehrere Regeln ange wandt, werden diese zweckmäßig ebenfalls,
in einer weiteren Spalte in die Hash-Tabelle HT eingetragen.
-
Die
Tabelle HT selbst wird vorzugsweise in einem separaten Speicherelement
bei der Generierung von nachladbarem Applikationscode für den dabei
eingesetzten Linker bereitgestellt. Alternativ kann die Tabelle
HT Teil des ROM-Maskencodes oder in einem anderen nichtflüchtigen
Speicher des Datenträgers
abgelegt sein.
-
In 3 ist
die erfindungsgemäße Generierung
von nachladbarem Applikationscode für Programmapplikationen in
dem nichtflüchtigen
Speicher der Chipkarte erläutert.
Sie erfolgt mit einem grundsätzlich
gleichen Werkzeug zum Compilieren und Linken von Quellcode, wie
es für
die Optimierung des ROM-Maskencodes eingesetzt wurde und verfügt über die
gleiche vorgegebene Hashfunktion zum Erzeugen von Hashwerten für auszuzeichnenden
Code. Zusätzlich
ist das Werkzeug zur Verwertung der Tabelle HT eingerichtet. Die
Tabelle HT wird dem Werkzeug auch zur Verfügung gestellt.
-
Zunächst wird
aus Applikationsquelldateien 5, 6 und 7 des
Applikationsquellcodes ASC in an sich bekannter Weise mit einem
Compiler ein Applikationsobjektcode AOC1 erzeugt. Analog zu dem
Objektcode OC1 der 1 enthält dieser Code wieder Codesequenzen,
von denen beispielhaft in 3 die Sequenzen 201, 202 und 203 gezeigt
sind. Mit der gleichen Hashfunktion, die zur oben beschriebenen Generierung
des ROM-Maskencodes verwendet wird, werden aus den einzelnen Codes
der Codesequenzen wieder entsprechende Hashwerte generiert. In 3 ist
dabei der Fall gezeigt, dass die Codesequenzen 201 und 202 den übereinstimmenden
Code C1 enthalten und die Codesequenz 203 den Code C2 enthält. Somit
wird der Hashwert H1 für
die Codesequenzen 201 und 202 der Hashwert H2
für die
Codesequenz 203 generiert. Anschließend erfolgt der Vergleich
dieser Hashwerte H1 und H2 mit den Hashwerten der Hash-Tabelle HT,
welche dem Compiler bei der Erzeugung des Applikationscodes zur
Verfügung
steht.
-
Schließlich wird
festgestellt, dass der Hashwert H1 des Codes C1 der Sequenzen 201 und 202 auch
als Eintrag in einer Zeile der Hash-Tabelle HT enthalten ist. Ebenso
wird ermittelt, dass auch der Hashwert H2 einen entsprechenden Eintrag
in der Tabelle HT hat. Zur Erzeugung von optimiertem Applikationsobjektcode
werden nunmehr die Codesequenzen 201 und 202 mit
einem entsprechenden Verweis auf die Startadresse A1 in dem Segment 401 des
ROMs 4 ersetzt. Ebenso wird die Codesequenz 203 mit
einem solchen Verweis auf die entsprechende Startadresse A2 im Segment 401 ersetzt.
Diese Verweise sind in 3 mit „Call A1” bzw. „Call A2” bezeichnet. Die Startadressen
A1 bzw. A2 können hierbei
der Hash-Tabelle HT entnommen werden. Durch die Erzeugung der Verweise
auf die Startadressen im Segment 401 des ROMs 4 kann
die Größe des Applikationsobjektcodes
vermindert werden. Bei großen
ROM-Masken lassen sich bis zu 40% an Code sparen. Der modifizierte
Applikationsobjektcode AOC2 wird schließlich in dem nichtflüchtigen Speicher 8 in
an sich bekannter Weise als Applikationscode gespeichert. Zur weiteren
Codeoptimierung kann eine Codemindestgröße zur Generierung eines Hashwerts
für Codesequenzen
in Applikationsobjektcode AOC1 vorgesehen sein, wobei diese Mindestgröße vorzugsweise
der Länge
der jeweiligen Verweise auf die Startadresse entspricht.
-
Mit
der beschriebenen Lösung
kann einem Dritten die Möglichkeit
verschafft werden, einen erstellten eigenen Applikationscode unter
Zugriff auf den ROM-Maskencode zu optimieren, ohne daß er dabei
Kenntnis vom dem ROM-Maskencode erhalten kann. Dem Dritten werden
hierzu als Werkzeug ein Linker und Compiler, der auch die Hash-Tabelle
HT verarbeiten kann, sowie die Hash-Tabelle HT selbst übergeben.
Bei der Überlassung
der Hash-Tabelle
an einen außenstehenden
Programmierer von Applikationscode, dem der ROM-Maskencode nicht
bekannt gemacht werden soll, ist allerdings zu berücksichtigen,
dass die ungesicherte Hash-Tabelle HT Rückschlüsse auf Codesequenzen und deren
Position im ROM erlaubt. Vorzugsweise sind deshalb Sicherungsmechanismen
vorgesehen.
-
Eine
erste, besonders einfache Art der Sicherung besteht darin, dass
Einträge
von sicherheitskritischen Codes in der Hash-Tabelle Dritten nicht
zur Verfügung
gestellt werden.
-
Eine
andere Sicherungsmöglichkeit
besteht in der Verwendung eines gesonderten Analyse-Programms, das
dem außenstehenden
Programmierer des nichtflüchtigen
Speichers bereitgestellt wird. Dieses Analyse-Programm hat Zugriff
auf die Hash-Tabelle HT, die in verschlüsselter Form vorliegt. Zweckmäßig liegt
die verschlüsselte
Hash-Tabelle HT in einem, nichtflüchtigen Speicher des Datenträgers für den der
Applikationscode bestimmt ist. Der außenstehende Programmierer weiß dadurch
nicht, wie viele Tabelleneinträge
für das
ROM vorhanden sind und welche Länge
und Adressen die entsprechenden Codes aufweisen. Das Analyse-Programm
kann in einem nichtflüchtigen
Speicher des Datenträgers,
für den
der Applikationscode bestimmt ist, liegen oder selbst Bestandteil
des ROM-Maskencodes sein. Der Linker ist dazu eingerichtet, mit
dem Analyse-Programm zu kommunizieren.
-
Der
von dem außenstehenden
Programmierer des nichtflüchtigen
Speichers verwendete Linker startet dabei wie zuvor beschrieben.
Die für
Codesequenzen des Applikationsobjektcodes AOC1 erzeugten Hashwerte übergibt
er nun jedoch an das gesonderte Analyse-Programm, welches die verschlüsselte Hash-Tabelle
HT entschlüsselt
und jeden übergebenen
Hashwert auf Übereinstimmung
mit einem Eintrag in der verschlüsselten
Hash-Tabelle HT überprüft. Alternativ
verschlüsselt
das Analyse-Programm die übergebenen
Hashwerte und vergleicht sie mit den verschlüsselten Werten der Tabelle
HT; die Verschlüsselung
kann dann auch bereits durch den Linker erfolgen. Die Prüfung durch
das Analyse-Programm erfolgt in jedem Fall ohne weiteren Zugriff
des außenstehenden
Programmierers. Wird ein übereinstimmender
Hashwert ermittelt, werden die passenden Informationen, d. h. insbesondere
die entsprechenden Startadressen, an den Linker zurückgegeben.
Kann für
einen an das gesonderte Programm übergebenen Hashwert kein übereinstimmender Hashwert
in der Tabelle ermittelt werden, wird die entsprechende Abfrage
des Hashwerts beendet, beispielsweise mit einer Ausgabe „nicht
gefunden”.
-
Eine
weitere Möglichkeit
zur Absicherung des ROM-Maskencodes kann auch darin bestehen, dass
nur eine bestimmte Anzahl an Vergleichen zwischen den Hashwerten
des Applikationsobjektcodes und der Tabelle zugelassen werden.
-
Eine
weitere Optimierung des Applikationscodes kann erreicht werden,
indem die Registerangaben im ROM-Maskencode für die Generierung der Hashwerte
aus dem Maskencode durch Pseudoadressen ersetzt werden, die die
ursprünglichen
Registerangaben neutralisieren. Dadurch wird ermöglicht, daß ein Linker bei einer Codesequenz,
die bei sonst gleichem Codeablauf andere Register als eine im übrigen identische
Codesequenz benutzt, den diese Codesequenz umschließenden Code
so umstellt, daß beide
Codesequenzen dieselben Register benutzen und die Hashwerte damit
tatsächlich
identisch sind. Die Zuordnung zwischen ursprünglicher Registerangabe und
Pseudoadresse wird ebenfalls in der Hash-Tabelle mitgeführt. Bei
der Erzeugung des Applikationsobjektcodes AOC1 generiert der Compiler auch
für den
Applikationsobjektcode die entsprechenden Pseudoadressen für die Registerangaben und
erzeugt aus den Codesequenzen, welche nunmehr die Pseudoadressen
enthalten, die entsprechenden Hashwerte, um diese dann mit den Hashwerten
in der Tabelle zu vergleichen. Zur Erzeugung des modifizierten Codes
AOC2 entnimmt der Compiler anschließend die Informationen bezüglich der
tatsächlichen
Registerangaben aus der Hash-Tabelle HT und ersetzt die Pseudoadressen
durch diese Registerangaben. Auf diese Weise wird sichergestellt, dass
die in der Hash-Tabelle HT enthaltenen Hashwerte neutral gegenüber den
Registerangaben sind, denn bei der Erzeugung der Hashwerte werden
Codes verwendet, bei denen die tatsächlichen Registerangaben durch
Pseudoadressen ersetzt sind.
-
Die
Verwendung von Pseudoadressen verringert zudem die Möglichkeit,
ROM-Codesequenzen auszuspähen,
indem die aus dem ROM-Maskencode erstellten Hashwerte keinen Rückschluß auf die
verwendeten Register ermöglichen.