AT508649A2 - Chipkarte mit überwachung der integrität auf softwarebasis - Google Patents

Description

t« ··«· · • · · · · ···· · · • · · ♦ · · · · • · ·« · · ···· ···

Chipkarte mit Überwachung der Integrität auf Softwarebasis

Gegenstand der Erfindung ist eine Chipkarte mit Maßnahmen zur Überwachung der Datenintegrität der auf der Chipkarte gespeicherten Daten und Maßnahmen zur 5 Gewährleistung der Ablaufintegrität, wobei diese Maßnahmen in der auf der Chipkarte ablaufenden Software (Betriebssystem und Applikationen) realisiert sind und automatisch bei der Softwareerstellung erzeugt werden.

Erfindungsgemäß ist vorgesehen, dass auf der in der Chipkarte implementierten 10 Software (Betriebssystem und Applikationen) Gegenmaßnahmen eingebaut werden müssen, um die Chipkarte gegen äußere Angriffe zu schützen.

Solche Angriffe werden Penetrationsversuche genannt, wo im konkreten Fall der Chip der Chipkarte physikalischen und/oder chemischen Prozessen ausgesetzt wird 15 und hierbei versucht wird, gezielt Fehler auf der Karte zu erzeugen (im Folgenden „Fehlerinduktion“ auch bekannt unter dem Begriff „fault induction“). Bekannt sind unter anderem Angriffe mit Hilfe von Laserstrahlen, Licht, ionisierender Strahlung und mit Spannungs- und Frequenzveränderungen sowie Stromimpulsen an den Anschlüssen des Chips, sowie physikalische Manipulationen mittels sehr feinen 20 Sonden / Kontakten und chemische Manipulationen.

Um solchen Angriffen zu entgegnen ist es im Stand der Technik bekannt, dass man bei der Programmierung der Chipkartensoftware zur Sicherung der Datenintegrität Daten, Adresswerte und Rücksprungadressen mit Prüfsummen oder redundanten 25 Daten versieht und dazu benutzt die Datenintegrität vor und oder nach der Datenverwendung zu überprüfen. Bezüglich der Ablaufintegrität besteht ein weiteres bekanntes Verfahren darin, zum Beispiel die Ausführung von Codes dadurch abzusichern, dass die Abfrage von Bedingungen doppelt (ggf. in komplementärer Weise) ausgeführt wird oder bestimmte Code-Abschnitte redundant vorhanden sind. 30 Eine weitere Möglichkeit besteht darin die Ablaufintegrität dadurch sicherzustellen, dass logische Programmabfolgen (z.B. Unterprogrammaufrufe) durch die Weitergabe zusätzlicher redundanter Informationen auf ihre logische Korrektheit geprüft werden. Weiters ist auch bekannt, dass Daten zunächst geschrieben werden, danach zurück gelesen werden und dann verglichen wird, ob die Daten richtig geschrieben wurden oder nach mathematischen Operationen zusätzlich die inversen Operationen durchgeführt und die Ergebnisse überprüft werden. Weiters kann durch die Dokumentation der Chip-Hardware vorgegeben sein, welche Hardware-Gegenmaßnahmen in bestimmten Fällen zu Aktivieren oder zu Deaktivieren sind. 5

Die Grundidee der vorliegenden Erfindung besteht nun darin, dass man den vorher beschriebenen Sicherungsprozess, gemeint ist die Implementierung der Gegenmaßnahmen in die Chipkartensoftware, automatisiert und durch Parameter steuerbar macht. 10

Bisher war es bei der Programmierung einer solchen Software notwendig auf den speziellen Programmablauf abgestimmte - Sicherungsmechanismen (Gegenmaßnahmen) - sozusagen „von Hand“ - einzubauen. 15 Weiterer Nachteil ist, dass bei einer umfangreichen Programmierung von Chipkartensoftware, wie es beim Stand der Technik der Fall ist, ein außerordentlich hoher Programmieraufwand entsteht, dessen Prüfung schwierig ist, der fehleranfällig ist und der einem großen Entwicklungsaufwand führt. Durch die implementierten Gegenmaßnahmen steigen weiters der Speicherbedarf und die Berechnungszeit der 20 Software.

Der Erfindung liegt deshalb die Aufgabe zugrunde eine Chipkarte der eingangs genannten Art mit einer Absicherung der Software über Software-Gegenmaßnahmen so weiter zu bilden, dass die Implementierung der Gegenmaßnahmen in der 25 Chipkartensoftware automatisiert und über Parameter steuerbar erfolgt.

Zur Lösung der gestellten Aufgabe ist die Erfindung dadurch gekennzeichnet, dass die Gegenmaßnahmen durch ein Software-Modul erzeugt werden, welches in die Toolchain eingreift oder integriert ist.

Die Erfindung sieht deshalb eine Chipkarte mit Maßnahmen zur Überwachung der Datenintegrität und Maßnahmen zur Gewährleistung der Ablaufintegrität auf Softwarebasis (Software - Gegenmaßnahmen vor, wobei diese Maßnahmen in der 30 • # • · · · · ···· t · ····« t · · t« ·· · · ·♦·· ##· 3 auf der Chipkarte ablaufenden Software und Applikationen realisiert sind, um die Chipkarte gegen äußere Angriffe zu schützen.

Solche äußeren Angriffe auf die Chipkarte sind insbesondere 5 · Angriffe mit Hilfe von o Elektromagnetischen Wellen (Laserstrahlen, Licht, ionisierender Strahlung) o Spannungs- und Frequenzveränderungen an den Kontakten des Chips o physikalische Manipulationen des Chips mittels sehr feine Sonden / 10 Kontakten o chemische Manipulationen Das Resultat eines solchen Angriffes ist im Erfolgsfall, dass • der Inhalt einer Speicherzelle (im flüchtigen oder nicht-flüchtigen Speicherbereich) geändert wird oder 15 · der Inhalt eines Prozessor-Registers (eines Haupt- oder Co-Prozessors oder ein spezielles Hardware-Register) geändert wird. Handelt es sich hierbei beispielsweise um den so genannten Programm Counter, welcher den als nächsten auszuführenden Befehl bezeichnet, so wird das Programm an einer anderen Stelle fortgesetzt. 20

Eine solche Veränderung des Inhaltes kann grundsätzlich persistent oder transient sein. Folgende Fälle sind zu unterscheiden: • persistente Veränderung im nicht flüchtigen Speicher: alle nachfolgenden Lese-Zugriffe liefern den geänderten Wert zurück. 25 · Persistente Veränderung im flüchtigen Speicher: alle nachfolgenden Lese-

Zugriffe bis zum nächsten Reset des Chips liefern den veränderten Wert zurück (nach dem Reset ist der Inhalt des flüchtigen Speichers im Allgemeinen Undefiniert). • Persistente Veränderung eines Prozessor-Registers: alle nachfolgenden 30 Lese-Zugriffe bis zu dem Zeitpunkt an dem ein neuer Wert in das Register geschrieben wird (das kann auch selbsttätig von der Chip-Hardware verursacht werden), liefern den geänderten Wert zurück ·« ·· ·♦·· · ·· · • · · · · · · · ·· ···· · · · · · • · ♦ · · ···» · · • · · t t · · · ·· ♦♦ · ♦ ···* *·♦ 4 • Transiente Veränderung einer Speicherzelle oder eines Registers: nur der aktuelle Lese-Zugriff auf die Speicherzelle oder ein Register liefert einen geänderten Wert zurück. Alle nachfolgenden Lese-Zugriffe liefern wieder den korrekten Wert zurück. Dieser Angriff funktioniert im Allgemeinen nur 5 dann, wenn der Angriff exakt zum Zeitpunkt des Lese-Zugriffs ausgeführt wird. Es handelt sich hier um den Angriff mit der derzeit höchsten - da auf realer Hardware am einfachsten ausführbaren - Erfolgsrate. 10 15 20 25

Die derzeit bekannten Angriffe auf reale Hardware haben gemeinsam, dass das Setzen einer Speicherzelle auf einen bestimmten Wert im Allgemeinen sehr schwierig ist, sondern ein zumeist ein - von außen für den Angreifer aufgrund von Speicherverschlüsselungsmechanismen - nicht vorhersehbares Bit-Muster gesetzt wird oder alle Bits der zu verändernden Speicherzelle auf den Wert Null oder alle Bits auf den Wert Eins gesetzt werden.

Erfindungsgemäß werden die Gegenmaßnahmen (redundante Daten und Prüfroutinen) von einem Software-Modul erzeugt, insbesondere folgende Gegenmaßnahmen • Versehen der Daten, Adresswerte und Rücksprungadressen mit Prüfsummen oder redundanten Daten und deren Verarbeitung durch Prüfroutinen • Einbringen von redundanten Codeabschnitten (z.B. doppeltes und ggf. komplementäres Abfragen von Bedingungen, Weitergabe redundanter Information bei Unterprogrammaufrufen) zur Sicherung der Ablaufintegrität logischer Programmabfolgen • Einbringen von zusätzlichem Code und Daten zur Erkennung von unbeabsichtigten Sprüngen (z.B. von einem Angreifer induziert) innerhalb des Programmablaufes. • Das Schreiben und nachfolgende Zurücklesen von Daten • Durchführen von mathematisch inversen Operationen und Kontrolle der Ergebnisse • Aktivieren und Deaktivieren von Hardware-Gegenmaßnahmen gemäß den Vorgaben in der Dokumentation der Chip-Hardware 30 ·· ·· ···· · fff • · fff·· ff ff · • · · · · · · · · • ff ff t f ff··· · · • •••ff ·· · • ff ·· · · ff··· f fff 5

Mit der Verwendung eines Software-Moduls besteht der Vorteil, dass dieses automatisch (selbsttätig) arbeitet und der Benutzereingriff nur beim Start und möglicherweise bei der Auslesung und Auswertung der Ergebnisse notwendig ist. Ein solches Software-Modul ist vorteilhaft in die sogenannte Toolchain integriert. 5

Die Toolchain (deutsch: Werkzeugkette) ist ein Gesamtbegriff für die Programmier-und insbesondere Übersetzungswerkzeuge, die in einem Projekt eingesetzt werden um den Source-Code zu Erstellen und in den ablauffähigen Binärcode zu übersetzen. Diese Produkte bilden ein Gesamtsystem oder eine Werkzeugkette, die 10 für die Programmierung von sowohl Anwendungen als auch Betriebssystemen genutzt werden. Der Begriff Toolchain ist ein wichtiger Bestandteil bei der Entwicklung des Linux Kernels, der Entwicklung der BSD und ein Standardtool bei der Entwicklung von Eingebetteten Systemen. 15 Demzufolge versteht man unter einer Toolchain (Toolkette) die gesamte Kette von Softwareentwicklungswerkzeugen, beginnend von der Programmerstellung und Quellkodeverwaltung über den Pre- Prozessor, Compiler, Assembler und den Linker bis hin zum Simulator und Emulator. In manchen Fällen werden die Werkzeuge für die Anforderungs- und Änderungsverwaltung ebenfalls zur Toolchain gezählt. 20

Erfindungsgemäß ist nun vorgesehen, dass man das Softwaremodul zur automatischen Generierung der Gegenmaßnahmen in diese Toolchain einfügt.

Es bestehen bei der vorliegenden Erfindung also wesentliche Vorteile gegenüber der 25 manuellen Programmierung der Gegenmaßnahmen.

Die Erfindung vermeidet diese aufwendige Programmierung und sieht stattdessen ein Software-Modul vor, welches in die Toolchain (in dem Bereich zwischen dem Source-Code und dem resultierenden Maschinencode) dazwischen geschaltet ist. 30 Hier bestehen besondere Vorteile, denn der Hardware-Hersteller legt dem Verwender der Chipkarte (Softwareentwickler) besondere Sicherungsmaßnahmen auf, wie beispielsweise das Aktivieren und Benutzen von Schutzfunktionen, die in der Chip-Hardware eingebaut sind sowie von Software- Sicherungsmaßnahmen. • · ·* ···· · Μ · • « · · · · · · · · • « · · · · · · · • « « · · ···· · · ····· · · · ·· ·· · · ·♦*· ··« 6

Hier setzt die Erfindung ein, die vorsieht, dass die Software- Sicherheitsfunktionalität automatisch und über Parameter steuerbar in der Toolchain generiert wird.

Es handelt sich also um eine Software-Anwendung, welche in die einzelnen 5 Elemente der Toolchain (insbesondere Pre-Prozessor, Compiler, Linker, Assembler) integriert ist, d.h. um eine spezielle Ausführung der Toolchain bzw. der Compiler-Software.

Das Software-Modul zur Erzeugung der Gegenmaßnahmen wird durch Parameter 10 gesteuert, welche die Art und den Umfang der Gegenmaßnahmen definieren, insbesondere • Welche Arten von Daten durch redundante Daten abgesichert werden sollen (z.B. Daten im RAM oder EEPROM, Adresswerte, Registerinhalte) • Wie die redundanten Daten gestaltet sein sollen (z.B. Art der zu benutzenden 15 Prüfsummen) • Welche Arten von Prüfroutinen erzeugt werden sollen (Erstellen und Prüfen von Prüfsummen vor/nach der Datenverwendung, doppeltes Abfragen von Bedingungen ggf. in komplementärer Weise, redundante Code-Abschnitte, Weitergabe redundanter Information zur Kontrolle der logischen 20 Programmablauffolgen, Schreiben und nachfolgendes Lesen und Vergleichen von Daten, Durchführen von mathematisch inversen Operationen)

Wie viel Prüfroutinen eingebracht werden sollen (absolute oder relative Maßzahl der Codegröße 25 Das folgende Beispiel illustriert die Vorgehensweise:

Wenn in der Smartcard-Software z. B. ein Speicherbereich angelegt wird und es handelt sich dabei um einen kritischen Speicherbereich, wie z. B. einen Schlüssel, dann wird üblicherweise vom Entwickler gefordert, dazu auch eine Prüfsumme abzuspeichem. Der Entwickler muss die Berechnung der Prüfsumme 30 programmieren, muss einen Speicherbereich für diese Prüfsumme reservieren und muss dann auch an bestimmten Stellen des von ihm entwickelten Programms die Prüfsumme wieder prüfen. Die Erfindung besteht nun darin, dass dieser Schritt, das Berechnen der Prüfsumme, das Reservieren des Speicherplatzes, das Abspeichern und das nachträgliche Wiederprüfen automatisch in diesen Software-Code • · ·· ···· · ♦ ···· • « · · 9 9 9 · · • 9 9 ♦ · #··* · 9 9 9 9 ·· · · · 99 99 · · ···· ··· 7 automatisch durch die Tooichain eingefügt, wird und damit für den Entwickler auch weitgehend transparent abläuft.

Zusätzlich kann nach einer Weiterbildung das Softwaremodul dynamische Parameter 5 erzeugen, welche zur Laufzeit des Chipkartenbetriebssystem und der Applikationen vorgeben, wie ausführlich und wie zeitaufwendig die Gegenmaßnahmen auszuführen sind.

Aus dem beigefügten Blockschaltbild ergibt sich, dass die Sicherheit einer Chipkarte 10 durch das Zusammenspiel sowohl der sicheren Chip-Hardware als auch der sicheren Software (Applikationen, Betriebssystem und Software-Gegenmaßnahmen, wie von der Dokumentation gefordert) erzeugt werden muss.

Der Erfindungsgegenstand der vorliegenden Erfindung ergibt sich nicht nur aus dem 15 Gegenstand der einzelnen Patentansprüche, sondern auch aus der Kombination der einzelnen Patentansprüche untereinander.

Alle in den Unterlagen, einschließlich der Zusammenfassung offenbarten Angaben und Merkmale, insbesondere die in den Zeichnungen dargestellte räumliche 20 Ausbildung, werden als erfindungswesentlich beansprucht, soweit sie einzeln oder in Kombination gegenüber dem Stand der Technik neu sind.

Es zeigen: 25 Figur 1: Blockschaltbild mit allgemeiner Darstellung des Zusammenspiels von Software-Entwicklung, sicherer Chip-Hardware und Software Gegenmaßnahmen in einer Chipkarte.

Figur 2: Implementierung des Sicherheitscodes in der Tooichain. 30 Die Chipkarte 4 besteht im Prinzip aus einer sicheren Chip-Hardware 2, Applikationen 6, einem Betriebssystem 7 und Software Gegenmaßnahmen 1. Die zur sicheren Chip-Hardware gehörige Dokumentation 3 schreibt vor, welche Software -Gegenmaßnahmen 1 zu implementieren sind, um mir dieser sichere Chip-Hardware 2 ein bestimmtes Produkt (Chipkarte 4) in sicherer Weise umzusetzen. ·· ···· · ·· • « · ♦ • · · i • · 9 · • « · · I« ·· • · · • · · ···♦ · • · • ···· 8

Der Programmierer 5 implementiert Applikationen 6, Betriebssystem 7 und die Software - Gegenmaßnahmen 1 gemäß den Vorgaben der Dokumentation 3 für die sichere Chip-Hardware 2. 5

Erfindungsgemäß soll nun die auf der Chipkarte ablaufende Software (Betriebssystem 7 und Applikationen 6) durch eine automatisch Erzeugung von Gegenmaßnahmen 15 in der Toolchain 8 abgesichert werden, ohne dass es der manuellen Einfügung von bestimmten Gegenmaßnahmen bedarf. 10

Der Source-Code 9, der vom Entwickler 5 verfasst wurde, wird durch die Toolchain 8, die z. B. aus einem Preprozessor 10, einem Compiler 11, einem Assembler 12 und einem Linker 13 besteht in den Maschinencode 14 umgewandelt. 15 Das Wichtige der vorliegenden Erfindung ist nun in der zweiten Abbildung, Figur 2 dargestellt, dass herkömmlich vom Programmierer 5 verlangt wird, Software Gegenmaßnahmen gemäß Dokumentation 3 zu implementieren, beispielsweise bei Datenelementen redundante Daten zu definieren und ferner Prüfroutinen, um beispielsweise diese redundanten Daten auf Integrität zu prüfen oder Maßnahmen, 20 welche die Ablaufintegrität sicherstellen.

Erfindungsgemäß soll dies nun vermieden werden und stattdessen sollen die Erzeugung der Gegenmaßnahmen 15 (z.B. redundanten Daten und die Prüfroutinen) in der den Sourcecode verarbeitenden Software (Toolchain 8) unter Verwendung des 25 Softwaremoduls 17 erzeugt werden.

Damit wird der Programmieraufwand wesentlich verringert, denn es ist nicht mehr notwendig, im Source-Code 9 die Erzeugung der Gegenmaßnahmen 15 durch den Programmierer 5 durchzuführen, sondern dies wird nachfolgend in der 30 nachgeschalteten Toolchain 8 zusammen mit dem Softwaremodul 15 gesteuert durch die Parameter 18 durchgeführt.

Die Gegenmaßnahmen werden somit mit wesentlich geringerem Entwicklungsaufwand generiert, wobei auch die Fehlerträchtigkeit minimiert wird. ·· ·· ···· • ·« • · • · · • · · · • · • · · • · · • · • t · ···» t • · • · · • · ·· ·« · • ··«· · 9

Das Software-Modul (17) zur Erzeugung der Gegenmaßnahmen (15) ist vorteilhaft in die Toolchain (Bereich zwischen dem Source-Code (9), dem Preprozessor (10), dem Compiler (11), dem Assembler (12), dem Linker (13)) und dem ausführenden Organ 5 für die Ausführung des Maschinencodes (14) dazwischen geschaltet.

Damit besteht der Vorteil, die manuelle und damit nur aufwendig anpassbare Implementierung der Gegenmaßnamen zu vermeiden und in die Toolchain zu verlagern, wobei dynamische Parameter definieren und damit der Toolchain 10 vorgeben, wie und in welchem Ausmaß die Umsetzung der Gegenmaßnahmen stattzufinden hat. Beispielsweise können hier der zur Verfügung stehende Speicherplatz für die redundanten Daten sowie der gewünschte Abarbeitungsaufwand der Prüfroutinen definiert werden. Die Implementierung eines dynamischen Parameters hat also den Vorteil, dass man über diese Variablen frei 15 entscheiden kann, wie die Sicherheitsprozeduren und in welcher Zeit sie ablaufen, während dies bei einer manuellen Source-Code-Programmierung nicht oder nur mit großen Aufwand möglich ist.

Mit den Maßnahmen der Erfindung wird individuell notwendiger Programmieraufwand 20 eingespart, weil die Implementierung von Gegenmaßnahmen in die selbsttätig ablaufende Toolchain verlagert ist.

Zeichnunasleaende

Software-Gegenmaßnahmen

Sichere Chip-Hardware

Dokumentation

Chipkarte

Programmierer

Applikationen

Betriebssystem

Toolchain

Source-Code

Preprozessor

Compiler

Assembler

Linker

Maschinencode

Erzeugung von Gegenmaßnahmen

Analyseinformation

Software-Modul

Parameter

Claims (7)

1. 5 1. Chipkarte mit Maßnahmen zur Überwachung der Datenintegrität und Maßnahmen zur Gewährleistung der Ablaufintegrität auf Softwarebasis (Software -Gegenmaßnahmen (1)), wobei diese Maßnahmen in der auf der Chipkarte (4) ablaufenden Software (Betriebssystem (7) und Applikationen (6)) realisiert sind, um die Chipkarte (4) gegen äußere Angriffe zu schützen, insbesondere durch Software -Gegenmaßnahmen (1) wie 10 15 20 25 *» ·· ···· • • · • · • • • * • · • • · • · • · • **# • · • · • • t« ·« • • ·· 11 Patentansprüche

   • Versehen der Daten, Adresswerte und Rücksprungadressen mit Prüfsummen oder redundanten Daten und deren Verarbeitung durch Prüfroutinen • Einbringen von redundanten Codeabschnitten (z.B. doppeltes und ggf. komplementäres Abfragen von Bedingungen, Weitergabe redundanter Information bei Unterprogrammaufrufen) zur Sicherung der Ablaufintegrität logischer Programmabfolgen • Einbringen von zusätzlichem Code und Daten zur Erkennung von unbeabsichtigten Sprüngen (z.B. von einem Angreifer induziert) innerhalb des Programmablaufes. • Das Schreiben und nachfolgende Zurücklesen von Daten • Durchführen von mathematisch inversen Operationen und Kontrolle der Ergebnisse • Aktivieren und Deaktivieren von Hardware-Gegenmaßnahmen gemäß den Vorgaben der Dokumentation (3) dadurch gekennzeichnet, dass diese Erzeugung von einer oder mehreren der Gegenmaßnahmen (15) (redundante Daten und Prüfroutinen) von einem Software-Modul (17) durchgeführt wird.
2. 2. Chipkarte nach Anspruch 1, dadurch gekennzeichnet, dass das Software-Modul (17) selbsttätig abläuft.
3. 3. Chipkarte nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Software-Modul (17) zur Erzeugung der Gegenmaßnahmen in eine oder alle Komponenten der Toolchain (bestehend aus zumindest Preprozessor (10), dem Compiler (11), dem Assembler (12), dem Linker (13)) eingreift oder integriert ist. 5 #· »9*· · ·* • · · • · · • · · ·· • · • · · · · ·« ♦· · • · *»« ···· 12
4. 4. Chipkarte nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das Software-Modul (17) zur Erzeugung der Gegenmaßnahmen durch Parameter (18) gesteuert wird, welche die Art und den Umfang der Gegenmaßnahmen definieren, insbesondere • Welche Arten von Daten durch redundante Daten abgesichert werden sollen (z.B. Daten im RAM oder EEPROM, Adresswerte, Registerinhalte) • Wie die redundanten Daten gestaltet sein sollen (z.B. Art der zu benutzenden Prüfsummen) 10 15 • Welche Arten von Prüfroutinen erzeugt werden sollen (Erstellen und Prüfen von Prüfsummen vor/nach der Datenverwendung, doppeltes Abfragen von Bedingungen ggf. in komplementärer Weise, redundante Code-Abschnitte, Weitergabe redundanter Information zur Kontrolle der logischen Programmablauffolgen, Schreiben und nachfolgendes Lesen und Vergleichen von Daten, Durchführen von mathematisch inversen Operationen) • Wie viel Prüfroutinen eingebracht werden sollen (absolute oder relative Maßzahl der Codegröße)
5. 5. Chipkarte nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die 20 Toolchain (8) zusätzlich die Werkzeuge für das Anforderungsmanagement (insbesondere Sicherheitsanforderungen, welche automatisch in Gegenmaßnahmen umgesetzt werden) umfasst.
6. 6. Chipkarte nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass 25 das Software-Modul (17) zur Erzeugung der Gegenmaßnahmen (15) in einen speziellen Bereich der Toolchain, konkret den Bereich zwischen dem Source-Code (9) und dem Preprozessor (10, dazwischen geschaltet ist.
7. 7. Verfahren zum Betrieb einer Chipkarte nach einem der Ansprüche 1 bis 6, 30 dadurch gekennzeichnet, dass das Softwaremodul (17) weiters dynamische Parameter erzeugt, welche zur Laufzeit des Chipkartenbetriebssystem und der Applikationen vorgeben, wie ausführlich und wie zeitaufwendig die Gegenmaßnahmen auszuführen sind.