-
Das
Gebiet der Erfindung sind manipulationsgesicherte Einheiten und
insbesondere die Vergabe von Rechenzeit in manipulationsgesicherten
Einheiten.
-
Die
Erfindung bezieht sich insbesondere auf das Gebiet von Smartcards
und Verfahren gemäß den Oberbegriffen
der Patentansprüche
1, 4, 13 und 16.
-
In
modernen Programmiersprachen (z. B. PHP, JavaScript, Visual Basic)
sind zwar Kommandos vorgesehen, um Speicherplatz zu reservieren,
Kommandos zum Freigeben von Speicherplatz fehlen jedoch oder sind
nicht populär.
Das Suchen und Freigeben von nicht mehr benötigtem Speicherplatz übernimmt
ein im Hintergrund ablaufender Prozess, der als Garbage Collection
(Müllsammlung)
bezeichnet wird.
-
In
modernen Computersystemen gibt es Multitasking und Multithreading.
Computersysteme, die Multitasking unterstützen, ermöglichen es, mehrere Programme
quasi gleichzeitig auszuführen.
Die parallel ausgeführten
Programme befinden sich üblicherweise
in einem von den anderen Programmen abgegrenzten und geschützten Adressraum
und können
nur über
spezielle Mechanismen Daten miteinander austauschen. Multithreading
ermöglicht
es einem Programm, quasi gleichzeitig mehrere Aufgaben auszuführen. Die
einzelnen Threads (Pfade) eines Programms benutzen dabei üblicherweise
einen gemeinsamen Adressraum. Da es in dieser Schrift nicht um den
Adressraum geht, werden Multitasking und Multithreading synonym
verwendet.
-
Smartcards
sind für
benutzerinteraktive Kommunikation gedacht und liefern Antworten
auf Kommandos. Sie sind ungeeignet für umfangreiche Rechenaufgaben,
weil diese viel Rechenzeit benötigen
und eine Antwort verzögern, was
den Benutzer stört
und zu einer Überschreitung
der für
die Antwort vorgesehenen Zeit (timeout) führen kann.
-
Smartcards
weisen wie andere Rechnersysteme auch eine Recheneinheit (CPU, Central
Processing Unit), einen Coprozessor (NPU, Numerical Processing Unit)
für aufwändige arithmetische
Operationen, insbesondere Ver- und Entschlüsselung, einen Festwertspeicher
(ROM, Read only memory), einen nicht flüchtigen Speicher (EEPROM, Electrically
Erasable Programmable ROM), einen schnellen, aber flüchtigen
Speicher (RAM, Random Access Memory) sowie mindestens eine Schnittstelle
auf. Auch der Festwertspeicher ist ein nicht flüchtiger Speicher. Anstelle
eines EEPROM kann auch ein Flash-EEPROM
eingesetzt werden. Die Schnittstelle kann kontaktlos oder kontaktbehaftet
sein. Als kontaktlose Schnittstelle kommt beispielsweise ein RFID
(Radio Frequency Identification) – System beispielsweise gemäß ISO 10
536, 14 443 und 15693 in Betracht. Als kontaktbehaftete Schnittstelle
kommt beispielsweise eine Chipkartenschnittstelle gemäß ISO 7816 in
Betracht.
-
Obwohl
auch bei Smartcards die Rechenleistung und der zur Verfügung stehende
Speicher entsprechend der allgemeinen Entwicklung im Halbleiterbereich
stetig zunehmen, sind sowohl Rechenleistung als auch Speicher verglichen
mit anderen Rechnersystemen bescheiden. Aus Effizienzgründen haben
die meisten Smartcards eine Einpfadstruktur (single thread Operation
structure) und es ist nur ein Anwendungsprogramm während einer
Benutzerinteraktion aktiv. Deshalb können solche Smartcards auch
keinen getrennten Prozess zum Durchführen der Garbage Collection
aufweisen.
-
Aus
der
WO 2005/045683
A1 ist bekannt, im Rahmen der Abarbeitung eines auf einer
Smartcard empfangenen Kommandos eine Restausführungszeit auf der Karte zu
bestimmen. Die Restausführungszeit
wird gegebenenfalls für
andere Aufgaben wie beispielsweise die Garbage Collection verwendet.
Die Restausführungszeit
ist die Zeit vom Ende der Ausführung
eines Kommandos bis zu einer Antwortzeitgrenze oder einer Benutzerwartezeitgrenze.
Letztere Zeitgrenze ist kürzer,
um eine bestimmte QoS (Quality of Service, Dienstqualität) sicherzustellen.
-
In
einer Markierungsphase (mark phase) des Garbage-Collection-Prozesses
wird eine Liste der Objekte aufgestellt, die nicht gelöscht werden
sollen. Basierend auf dieser Liste wird eine Löschliste von Objekten aufgestellt,
die gelöscht
werden sollen. Immer wenn ein Objekt während der Ausführung eines
Anwendungsprogramms neu erzeugt oder gelöscht wird, werden beide Listen
aktualisiert.
-
In
einer Kehrphase (sweep phase) des Garbage-Collection-Prozesses wird
die Restausführungszeit eines
Kommandos benutzt, um zumindest einen Teil der zu löschenden
Objekte zu löschen.
Die in der Löschliste
verbleibenden Objekte werden im RAM oder EEPROM gespeichert und
während
der Restausführungszeit des
nächsten
Kommandos teilweise oder vollständig
gelöscht.
Falls die Löschliste
nur wenige Objekte enthält, kann
diese auch unmittelbar nach Eingang eines Kommandos und vor der
Verarbeitung des Kommandos abgearbeitet werden. Da das Schreiben
auf das EEPROM lange Zeit dauert, kann man Schreibvorgänge, die beim
Verarbeiten eines Kommandos als auch in der Kehrphase des Garbage-Collection-Prozesses
auftreten, manchmal so ordnen, dass alle Schreibvorgänge auf
eine Seite des EEPROM zusammen ausgeführt werden. So werden Blockzeiten
zwischen Schreibvorgängen
auf unterschiedliche Seiten des EEPROM vermieden.
-
Das
Handbuch der Chipkarten von Wolfgang Rankl und Wolfgang Effing,
2002, Carl Hanser Verlag, München,
Wien weist darauf hin, dass es bei manchen Chipkarten möglich ist,
durch Messung des Stromverbrauchs einer Chipkarte auf den gerade
abgearbeiteten Befehl zu schließen.
Dabei wird die einfache Leistgungsanalyse auch SPA (simple power
analysis) und die differentielle Leistungsanalyse auch DPA (differential power
analysis) unterschieden. Als Abwehrmaßnahme kann über einen
Shunt-Widerstand ein zeitunabhängiger
Stromverbrauch sichergestellt werden. Alternativ können gerade
nicht benötigte
Komponenten wie ein CRC-Prüfsummengenerator
oder der Coprozessor mit Zufallsdaten als Eingangswerte aktiviert
werden um den Stromverbrauch zu verschleiern. Man kann unter anderem
zufallsgesteuerte Wartezeiten einführen oder in gleiche Berechnungen
in Kryptoalgorithmen verschiedener Abläufe einführen, welche jeweils zufällig ausgewählt werden.
-
Kontaktlose
Chipkarten können
auch andere Funktionselemente wie Magnetstreifen oder Chipkontakte
aufweisen.
-
Andere
portable Datenträger
sind beispielsweise USB (Universal Serial Bus)-Sticks oder Multimedia Cards (MMC) oder
sogenannte embedded consumer products wie Mobiltelephone oder PDAs
(Personal Digital Assistants). Als Schnittstelle werden bei diesen
Produkten USB-Stecker, parallele und serielle Schnittstellen (Centronics,
IEEE 1284, RS232), Bluetooth, Infrarot-Schnittstellen, GSM, UMTS etc. verwendet.
-
Es
ist Aufgabe der Erfindung eine manipulationsgesicherte Einheit anzugeben,
die flexibel eingesetzt werden kann, sowie ein Verfahren für eine manipulationsgesicherte
Einheit und ein Speichermedium mit einem entsprechenden Programm
für eine
manipulationsgesicherte Einheit anzugeben, das einen flexiblen Einsatz der
manipulationsgesicherten Einheit unterstützt.
-
Diese
Aufgabe wird durch die Lehre der unabhängigen Ansprüche gelöst.
-
Bevorzugte
Ausführungsformen
der Erfindung sind Gegenstand der Unteransprüche.
-
Vorteilhaft
an der Festlegung von minimalen und maximalen Ausführungszeiten
auf Aktions-, Funktion- und/oder Kommando-Ebene ist, dass man die
korrekte Ausführung
und Angriffe auf die Smartcard überwachen
kann. Diese minimalen und maximalen Ausführungszeiten können in überraschend
einfacher Weise auch dazu benutzt werden, Aktionen in einer Multithreading-Smartcard
zu priorisieren.
-
Das
Definieren von Hintergrundprozessen und die Verwendung von Multithreading
erlaubt es in vorteilhafter Weise, in einen determinierten Programmablauf
in einzelne Teile, also Aktionen, aufzugliedern und bis zu einem
gewissen Grad zufällig
ablaufen zu lassen, um eine DPA zu erschweren. Ferner ist vorteilhaft, dass
kein Strom für
die unnötige
Aktivierung nicht benötigter
Baugruppen verschwendet wird und die Smartcard nicht unnötig aufgeheizt
wird.
-
Im
Folgenden wird eine bevorzugte Ausführungsform der Erfindung unter
Bezugnahme auf die beiliegenden Zeichnungen näher erläutert. Dabei zeigen:
-
1 ein
funktionales Blockdiagramm einer Smartcard;
-
2 einen
erfindungsgemäßen Programmablauf
in einer Smartcard;
-
3 den
ersten Teil eines erfindungsgemäßen Programmablaufs
in einer multithreadingfähigen Smartcard;
und
-
4 den
zweiten Teil des erfindungsgemäßen Programmablaufs
in der multithreadingfähigen
Smartcard.
-
1 zeigt
ein funktionales Blockdiagramm einer Smartcard 1 sowie
zwei mögliche
Schnittstellen zur Außenwelt.
Die Smartcard 1 kann einerseits über den ersten Transportmanager 4 vom
ersten Terminal 2 Kommandos erhalten und auf umgekehrten
Weg Antworten zurücksenden.
Diese Schnittstelle ist beispielsweise drahtgebunden. Eine zweite,
beispielsweise drahtlose Schnittstelle bildet ein zweites Terminal 3 sowie
ein zweiter Transportmanager 5. Die Smartcard 1 umfasst
ferner eine Recheneinheit 6, einen Timer 7 sowie
einen Speicher 8, die untereinander und mit den beiden
Transportmanagern 4 und 5 elektrisch über geeignete
Busse verbunden sind. Im Speicher 8 sind zwei Tabellen 9 und 10 abgelegt.
Der Speicher 8 umfasst wie bei Smartcards üblich ein
RAM, ein ROM und ein EEPROM. Meist liegen die beiden Tabellen 9 und 10 im
EEPROM, können
aber auch im ROM fest vorgegeben sein. Schließlich können Tabellen 9 und 10 dynamisch
im RAM erzeugt werden oder auf die drei Speicherarten ROM, RAM und
EEPROM verteilt sein.
-
Der
Timer 7 kann auf Anfrage eine Bitkombination t liefern,
deren Wert proportional zu der seit einem beliebigen Startzeitpunkt
vergangenen Zeit ansteigt. Weil es Smartcards gibt, ihre Taktfrequenz ändern, um einen
DPA-Angriff zu erschweren,
braucht der Zusammenhang zwischen Bitkombination und vergangener
Zeit nicht einmal linear zu sein. Der Timer 7 kann zusätzlich oder
alternativ aus einem Zähler
bestehen, in den anfangs eine Bitkombination geschrieben wird. Anschließend zählt der
Zähler
die Taktzyklen der Recheneinheit 6 und löst bei einem
bestimmten Zählerwert,
beispielsweise 111 ... 1 oder 0, einen Interrupt aus. Dann unterbricht
die Recheneinheit 6 die Abarbeitung des aktuellen Programms
und führt
eine meist kurze Interrupt-Funktion aus. Die Interrupt-Funktion
legt auch fest, was nach dem Ende der Interrupt-Funktion passiert,
also dass beispielsweise die Abarbeitung des aktuellen Programms
fortgesetzt wird.
-
Die
Tabelle 9 ordnet einem Teil der Kommandos oder allen Kommandos 11, 12, 13 der
Smartcard 1 in der linken, mit CMD überschriebenen Spalte je eine
maximale Ausführungszeit 14 tmax,
eine minimale Ausführungszeit 15 tmin, eine
zweite maximale Ausführungszeit 16 tdo
sowie eine Zeitgrenze 18 tto zu.
-
Die
zweite maximale Ausführungszeit
tdo ist kürzer
als die oder gleich der maximalen Ausführungszeit tmax, die wiederum
kürzer
als die oder gleich der Zeitgrenze tto ist. Wird ein Kommando innerhalb
der zweiten maximalen Ausführungszeit
tdo abgearbeitet, ist noch genügend
Zeit, um einen Hintergrundprozesses zu starten, bevor die Antwort
auf das Kommando rechtzeitig vor der Zeitgrenze tto zurückgegeben
wird. Erhält
ein Terminal auf ein Kommando innerhalb der entsprechenden Zeitgrenze
tto keine Antwort (Timeout), nimmt das Terminal an, dass bei der
Kommunikation etwas schief gelaufen ist, wartet nicht weiter auf
eine Antwort und handelt entsprechend, indem es beispielsweise einen
Zugang nicht freigibt oder kein Geld herausgibt. Die Zeitgrenze
tto wird also vor allem durch Normen und/oder eine geforderte Servicequalität (QoS,
Quality of Service) bestimmt und ist vor allem für kontaktbehaftete und kontaktlose
Kommandos unterschiedlich.
-
Wird
bei der Ausführung
des Kommandos die maximale Ausführungszeit
tmax überschritten
oder die minimale Ausführungszeit
unterschritten, wird dies als Fehler interpretiert und einen Fehlerzähler auf
der Smartcard, der vorher prophylaktisch incrementiert wurde, nicht
wieder zurückgesetzt.
Ein solcher Fehler kann auf eine falsche Programmierung der Chipkarte
zurückgehen
oder darauf zurückzuführen sein,
dass in der Chipkarte eine oder mehrere Speicherzellen "umgefallen" sind, also ihren
Sprecherinhalt vergessen haben. So etwas kann mit einer Wahrscheinlichkeit
von 10–9 bis
10–16 hin
und wieder vorkommen oder z. B. durch Lichtblitze bewusst hervorgerufen
werden. Falls die mithilfe des Fehlerzählers gemessene Häufigkeit
oder Frequenz für
Zeitüber-
und -unterschreitungen einen Grenzwert überschreitet, kann sich die
Smartcard selbst irreversibel deaktivieren und in der Folge auf
Kommandos nicht mehr antworten.
-
Ist
die maximale Ausführungszeit
tmax eines Kommandos ausreichend viel kürzer als die Zeitgrenze tto
des Kommandos, ist im Anschluss an die fehlerfreie Ausführung des
Kommandos immer genügend
Zeit, um einen Hintergrundprozesses zu starten. In diesem wahrscheinlichen
Fall kann die zweite maximale Ausführungszeit tdo gleich der maximalen
Ausführungszeit
tmax gewählt
werden. Falls dies für
alle Kommandos gilt, kann die Spalte mit den zweiten maximalen Ausführungszeiten
tto entfallen.
-
Es
ist ferner aufgrund von Normen oder geforderter QoS zu erwarten,
dass die Zeitgrenze tto für
eine Vielzahl von Kommandos gleich ist. In diesem Fall kann es effizienter
sein, die eine oder wenigen unterschiedlichen Zeitgrenzen tto durch
eine Funktion oder switch-Anweisung anstatt mittels der Tabelle 9 zu
ermitteln.
-
Die
Tabelle 10 ist ganz ähnlich
zu der Tabelle 9 aufgebaut. Diese Tabelle betrifft jedoch
kleinere Einheiten als Smartcard-Kommandos. Eine kleinere Einheit
ist im allgemeinen eine Gruppe von Befehlen an die Recheneinheit 6,
die im folgenden als Aktion bezeichnet wird. In der in 1 dargestellten
Ausführungsform sind
dies Funktionen, die in der mit FKT überschriebenen Spalte durchnummeriert
sind. Es gibt ebenfalls Spalten für eine maximale Ausführungszeit 23 tmax,
eine minimale Ausführungszeit 24 tmin
sowie eine zweite maximale Ausführungszeit 25 tdo.
Eine Spalte für
eine Zeitgrenze tto gibt es nicht, da die Funktionen Smartcard-interne
Einheiten sind, die beispielsweise im Rahmen eines Kommandos abgearbeitet
werden. Somit liefert das entsprechende Kommando die Zeitgrenze
tto.
-
Die
maximale Ausführungszeit 23 tmax
sowie die minimale Ausführungszeit 24 tmin
sichern die Ausführung
der Funktion gegen Angriffe beispielsweise durch Lichtblitze. Wie
oben erwähnt,
zählt ein
Fehlerzähler die
Male, bei denen eine Funktion nicht im Rahmen der vorgesehenen Ausführungszeit
zwi schen tmin und tmax beendet wird und deaktiviert die Smartcard,
falls dies zu oft passiert. Zusätzlich
gibt es eine Spalte mit einer erwarteten Ausführungszeit 26 tplan,
die für
die Priorisierung von Funktionen oder allgemeiner Aktionen in einer
Multithreading unterstützenden
Smartcard verwendet wird. Dies wird im folgenden genauer an Hand von 3 und 4 erläutert.
-
Die
erwartete Ausführungszeit
tplan liegt zwischen der minimalen Ausführungszeit tmin und der maximalen
Ausführungszeit
tmax und hat den Charakter eines Erwartungswerts. Die erwartete
Ausführungszeit hängt von
den Ausführungszeiten
unterschiedlicher Ausführungsäste (branches)
zwischen Verzweigungen innerhalb der Funktion und den Wahrscheinlichkeiten
ab, mit denen diese Ausführungsäste durchlaufen
werden. Dies wiederum hängt
von den Parametern ab, mit denen die Funktion aufgerufen wird und
von Wahrscheinlichkeiten, mit denen die Parameter in gewissen Bereichen
liegen. Da dies alles ziemlich kompliziert zu berechnen ist kann
es praktikabel sein, die erwartete Ausführungszeit tplan experimentell
oder einfach als arithmetisches oder geometrisches Mittel der maximalen
und minimalen Ausführungszeiten
tmax bzw. tmin zu berechnen.
-
2 erläutert beispielhaft
die Abarbeitung von Funktionen in einer (singlethreading) Smartcard,
die kein Multithreading unterstützen
muss. Zumindest für
die Funktion 1 wurde eine minimale, eine maximale sowie eine zweite
maximale Ausführungszeit
festgelegt.
-
Zunächst wird
ein Kommando 40 an die Smartcard übergeben. In Schritt 41 wird
die Funktion 1 gestartet. Dieser Schritt umfasst insbesondere das übliche Herunterziehen
von Funktionsparametern vom Stack und kann das prophylaktische Incrementieren
von Fehlerzählern
umfassen. In Schritt 42 wird die Startzeit t1 gespeichert.
Der Schritt 43 stellt das Abarbeiten der Funktion 1 dar.
Anschließend
wird die Dauer des Abarbeitens td1 der Funktion 1 bestimmt.
In Schritt 44 wird überprüft, ob die
Dauer td1 mindestens die minimale Ausführungszeit tl1 der Funktion
1 dauerte. Falls dies nicht der Fall ist, wird in Schritt 45 der
Fehlerzähler
Fl incrementiert und in Schritt 48 geprüft, ob sich die Smartcard irreversibel
in Schritt 49 sperren soll. Falls eine irreversible Sperrung
noch nicht erfolgen soll wird als Antwort 57 eine Fehlermeldung
an das Terminal zurückgegeben.
-
Falls
die Dauer td1 mindestens die minimale Ausführungszeit tl1 der Funktion
1 dauerte, wird in Schritt 46 überprüft, ob die Dauer td1 die maximale
Ausführungszeit
tu1 der Funktion 1 überschreitet.
Falls dies der Fall ist, wird in Schritt 47 der Fehlerzähler Fu
incrementiert und in Schritt 48 wie oben beschrieben fortgefahren.
-
Falls
die Dauer td1 im vorgesehenen Zeitbereich liegt, wird in Schritt 50 geprüft, ob die
Dauer td1 die zweite maximale Ausführungszeit tw1 der Funktion
1 nicht überschritten
hat. Falls dies der Fall ist, kann in Schritt 51 ein Teil
eines Hintergrundprozesses LOPSa ausgeführt werden. Solche Hintergrundprozesse (LOPS,
large OPerationS), wie das Defragmentieren von Speicher oder eine
Garbage Collection sind im allgemeinen so umfangreich, dass sie
nicht vollständig
zwischen einem Kommando 40 und einer Antwort 57 abgearbeitet
werden können
und deshalb meist in kleinere Einheiten zerlegt werden müssen.
-
Falls
die Dauer td1 die zweite maximale Ausführungszeit tw1 der Funktion
1 überschreitet,
wird in Schritt 52 die Funktion 2 gestartet. Die Ausführung der
Funktion 2 erfolgt in den Schritten 51 bis 55 ganz ähnlich zur
Funktion 1. In dem in 2 dargestellten Beispiel handelt
es sich bei Funktion 2 um eine wenig sicherheitsrelevante Funktion,
für die
keine maximale und minimale Ausführungszeiten
festgelegt sind und auch nicht überprüft werden.
Ein Abschalten der Überprüfung der
maximalen und minimalen Ausführungszeiten kann
fest im Programmcode programmiert sein und/oder durch setzen von
tut und tl2 auf ungültige
Werte wie beispielsweise 0 erfolgen. Ähnlich wie in Schritt 50 wird
in Schritt 54 überprüft, ob die
Dauer td2 des Abarbeitens der Funktion 2 die zweite maximale Ausführungszeit
tw2 der Funktion nicht überschreitet.
Ohne Überschreitung
wird in Schritt 55 ein weiterer Teil eines Hintergrundprozesses
LOPSb erledigen. Bei Überschreitung
wird in Schritt 56 die Funktion 3 abgearbeitet und eine
Antwort 57 zurückgegeben.
-
Es
sei noch einmal darauf hingewiesen, dass im Gegensatz zur Darstellung
in 2 Fehlerzähler
aus Sicherheitsgründen
prophylaktisch incrementiert werden und bei erfolgreicher Ausführung decrementiert
werden.
-
Da
auf Funktionsebene die maximalen Ausführungszeiten tmax auch den
Charakter von Zeitgrenzen tto auf Kommandoebene haben, müssen die
maximalen Ausführungszeiten
tmax und die zweiten maximalen Ausführungszeiten tdo in der Regel
unterschiedlich sein. Werden beide Zeiten tmax und tdo für einzelne
Funktionen gleich gewählt,
so werden unmittelbar nach diesen Funktionen keine Hintergrundprozesse
ausgeführt.
-
Ein
Zweck des Ausführen
des von Teilen von Hintergrundprozessen zwischen Funktionen ist,
den Stromverbrauch der Recheneinheit 6 zu verschleiern
und eine DPA zu erschweren. Deshalb sollen die ausgeführten Teile
von Hintergrundprozessen auch zufällig ausgewählt werden. Außerdem können positive
und negative Zufallszahlen auf die zweiten Zeitgrenzen addiert werden,
so dass die Startzeiten der Funktionen mit Ausnahme der ersten Funktion
auch bei jeweils gleichen Funktionsparametern nicht reproduzierbar
sind.
-
Die
3 und
4 sowie
die Tabelle 1 veranschaulichen anhand eines Beispiels, wie die erwarteten Ausführungszeiten
26 tplan
zur Steuerung der Abarbeitung von Aktionen in einer Smartcard eingesetzt
werden können,
die Multithreading unterstützt.
Dabei wird die vorläufige
Priorität
Pi der Aktion i gemäß der Formel
(1) berechnet:
-
Dabei
ist tzi die erwartete Ausführungszeit
der Aktion i, tai die Rechenzeit, die bereits zur Abarbeitung der
Aktion i aufgewendet wurde, ttK die Zeitgrenze, nach der das Kommando
K, zudem die Aktion i gehört, abgearbeitet
sein muss, t die aktuelle Zeit sowie tK die Startzeit des Kommandos
K. Im Beispiel gibt es insgesamt 6 Aktionen, so dass i die Werte
{1, 2, ... 6} annehmen kann. Im Beispiel gibt es ein Kommando A
sowie einen Hintergrundprozess B, der ebenfalls als eine Art Kommando
angesehen werden kann, so dass die Variable K die Werte A oder B
annehmen kann. Der Term tzi-tai kann als Restausführungszeit
der Aktion i angesehen werden. Der Term ttK-(t-tK) kann als maximale Restausführungszeit
interpretiert werden. Die maximale Restausführungszeit ist für alle Aktionen
eines Kommandos oder eines Hintergrundprozesses gleich.
Tabelle
1
-
Um
das Beispiel leichter nachvollziehbar zu machen, wurde die Startzeit
tc des Kommandos A gleich 0 gewählt
und die Zeitgrenze ttA auf 100% skaliert. Entsprechend umfassen
die 3 und 4 sowie die Tabelle 1 den 5
Zeitbereich zwischen 0% und 100%. Die Restzeit für den Hintergrundprozesses
beträgt
anfangs 1000% was dahingehend interpretiert werden kann, dass innerhalb
der nächsten
10 Kommandos soviel Rechenzeit zur Verfügung stehen sollte, dass neben
der Abarbeitung der Kommandos auch der Hintergrundprozess B abgearbeitet
werden kann. Für
jede Aktion soll ein Thread zur Verfügung stehen.
-
Das
Kommando A 71 umfasst im Beispiel die Aktionen 1 bis 4
(Bezugszeichen 72 bis 75). Im realen Leben ist
es leider so, dass die Aktionen nicht völlig unabhängig voneinander sind, sondern
manche Aktionen die Ergebnisse anderer Aktionen weiterverarbeiten.
Im Beispiel soll die Aktion 4 nach der Aktion 3 abgearbeitet werden,
weil die Aktion 4 auf die Ergebnisse der Aktion 3 angewiesen ist.
Deshalb ist die Priorität
Pi nur dann gleich der vorläufigen
Priorität
Pi', wenn eine Aktion
unabhängig
von anderen Aktionen durchgeführt
werden kann, was für
die Aktionen 1 und 2 zutrifft. Solange die Aktion 3 nicht abgeschlossen
ist, kann die Aktion 4 nicht begonnen werden. Deshalb bleibt die
Priorität
der Aktion 4 P4 = 0 solange die Aktion 3 nicht abgeschlossen ist.
Die Aktion 3 sollte eine höhere
Priorität
als die vorläufige
Priorität
erhalten, weil nach der Aktion 3 ja noch die Aktion 4 durchgeführt werden
muss. Dies wird dadurch bewerkstelligt, dass sich die Priorität einer
bestimmten Aktion als Summe der vorläufigen Priorität der ersten
Aktion plus der Summe aller vorläufigen
Prioritäten der
Aktionen berechnet, die auf die Ergebnisse der bestimmten Aktion
angewiesen sind: Pi = Pi'+ Σ Pj'(j ≠ i, j angewiesen
auf i) (2)
-
Die
Bezugszeichen der Schritte in den 3 und 4 wurden
gerade um 100 größer als
die Zeilenzahl in der Tabelle 1 gewählt. In den ungeraden Zeilen
werden die Prioritäten
Pi neu berechnet. In den geraden Zeilen wird eine Aktion teilweise
oder auch vollständig
abgearbeitet.
-
Für jede Aktion
gibt es in der Tabelle 1 mindestens drei Spalten. In der rechten,
mit CPU überschriebenen
Spalte findet sich in den geraden Zeilen ein Wert um 1, wenn diese
Aktion abgearbeitet wurde. In der mit Rest (%) überschriebenen Spalte findet
sich die erwartete Restausführungszeit
einer Aktion. Anfangs entspricht die erwartete Restausführungszeit
der erwarteten Ausführungszeit 26 tplan.
Nach jedem Ausführungsschritt,
in dem eine Aktion abgearbeitet wurde, wird von der Restausführungszeit
die Zeitdifferenz·(Wert
in der CPU-Spalte) abgezogen. Durch Werte in den CPU-Spalten, die
von 1 abweichen, wird im Beispiel bewirkt, dass die verbrauchte
Rechenzeit nicht exakt der erwarteten Ausführungszeit entspricht.
-
In
den mit Pi, i = {1, 2, ... 6} überschriebenen
Spalten werden die Prioritäten
angegeben, aufgrund derer die Rechenzeit vergeben wird. Es erhält die Aktion
den nächsten
Zeitschlitz, die die höchste
Priorität
aufweist. Da die Aktion 4 von der Aktion 3 abhängt, sind bei den Aktionen
3 und 4 auch die vorläufigen
Prioritäten P3' und P4 in den entsprechend überschriebenen
Spalten angegeben.
-
Bevor
im Schritt 101 zum ersten Mal die Prioritäten Pi berechnet
werden, kann in Schritt 79 geprüft werden, ob die Zeitgrenze
ttB ausreichend groß ist,
damit die Prioritäten
P5 und P6 nicht zu groß werden.
Andernfalls würde
ja zuerst der Hintergrundprozess abgearbeitet. Falls die Zeitgrenze
ttB zu klein, d.h. in 3 < 100% ist, kann die Zeitgrenze ttB
beispielsweise auf 100% erhöht
werden.
-
Da
die Aktion 1 mit 20% erwarteter Ausführungszeit voraussichtlich
am längsten
von den zum Kommando A gehörenden
Aktionen 1 bis 4 dauern wird, weist die Aktion 1 in Zeile 1, Schritt 101 die
höchste
Priorität
auf und bekommt den Zuschlag für
den ersten Zeitschlitz in Zeile 2, Schritt 102 der 10%
Rechenzeit zur Verfügung
stellt. Da die Aktion 1 erwartungsgemäß schnell ausgeführt werden
kann (1 in Spalte CPU), beträgt die
Restausführungszeit
danach in Zeile 3 für
Aktion 1 10%. Die Restausführungszeiten
für die
anderen Aktionen haben sich zwischen Zeile 1 und Zeile 3, Schritt 103 nicht
geändert.
Durch die Abarbeitung ist die Priorität der Aktion 1 von 20 in Zeile
1 auf 11,1 in Zeile 3 gefallen. Für alle anderen Aktionen nehmen
die Prioritäten leicht
zu, weil die Restausführungszeit
gleich geblieben ist, sich aber die maximale Restausführungszeit
um 10% der Gesamtzeit für
Kommando A verkürzt
hat.
-
Die
Länge der
Zeitschlitze wird für
Aktionen eines Kommandos zufällig
zwischen einer maximalen und einer minimalen Zeitschlitzlänge gewählt, um
eine DPA zu erschweren. Im Beispiel betragen die maximale und minimalen
Zeitschlitzlänge
10% bzw. 5% der Zeitgrenze für
Kommando A.
-
In
Zeile 3, Schritt 103 hat die Aktion 3 die höchste Priorität und bekommt
in Zeile 4, Schritt 104 den Zuschlag. Die tatsächliche
Ausführungszeit
liegt über
der erwarteten Ausführungszeit,
was durch 0,9 in der Spalte CPU berücksichtigt wird. Die Länge des
Zeitschlitz des in Zeile 4 liegt zufällig an der Untergrenze der Zeitschlitzlänge.
-
Auch
in Zeile 5, Schritt 105 bekommt die Aktion 3 den Zuschlag
und wird in Zeile 6, Schritt 106 vollständig abgearbeitet. Deshalb
beträgt
die Zeitschlitzlänge
nur 3,5%. Nur beim Beenden einer Aktion kann die Zeitschlitzlänge unter
das vorgesehene Minimum fallen. Da in Zeile 7, Schritt 107 die
Parameter für
die Aktion 4 feststehen, ist ab jetzt die vorläufige Priorität P4' gleich der Priorität P4 für Aktion
4.
-
In
den Zeilen 8, 10, 12, 14 und 16, die den Schritten 108, 110, 112, 114 und 116 entsprechen,
werden die Aktionen 2, 1, 4, wieder 1 und 2 in zufällig gewählten Zeitschlitzlänge sukzessive
gemäß ihrer
Prioritäten abgearbeitet.
-
In
Zeile 17, Schritt 117 stehen noch 52,7% der Zeitgrenze
von Kommando A zur Abarbeitung weiterer Aktionen insbesondere der
Aktionen 5 und 6 (Be zugszeichen 76 bzw. 77) zur
Verfügung.
Die Smartcard wurde im Beispiel zumindest im Hinblick auf Kommando
A vernünftig
programmiert, weil das Kommando A rechtzeitig vor erreichen der
Zeitgrenze für
Kommando A abgearbeitet wurde.
-
Bei
der Abarbeitung des Hintergrundprozesses B können die Zeitschlitze größer gewählt werden. Schließlich muss
für die
Berechnung der Prioritäten
auch Rechenzeit bereitgestellt werden, was bisher vernachlässigt wurde.
Je seltener die Prioritäten
berechnet werden, desto geringer ist der Overhead für die Vergabe
der Rechenzeit an die Aktionen. Dies ist auch der Grund für das Einführen der
Untergrenze für
die Zeitschlitzlänge
bei der Abarbeitung der Aktionen 1 bis 4. Da es sich bei den Hintergrundprozessen
um wenig sicherheitsrelevante Dinge wie Speicherdefragmentierung
oder Garbage Collection handelt, können die Zeitschlitze wie in
Zeilen 20 und 22 gleich groß gewählt werden.
-
In
den Zeilen 18, 20 und 22 werden die Aktionen 5 und 6 gemäß ihrer
Prioritäten
teilweise abgearbeitet. Danach wird in Schritt 78 die Antwort
auf Kommando A rechtzeitig an ein Terminal zurückgegeben. Um eine rechtzeitige
Rückgabe
sicherzustellen, kann die Rückgabe
eher, beispielsweise schon bei 95% oder 99% der Zeitgrenze für Kommando
A erfolgen. Sollten beim nächsten
Kommando auch nur 20% der Zeitgrenze von Kommando A übrig bleiben,
kann der Hintergrundprozess B vollständig abgearbeitet werden.
-
Es
stellt sich nun die Frage, ob es wirklich sinnvoll ist, die Aktionen
5 und 6 gemäß von Prioritäten gemäß Formel
(1) und (2) abzuarbeiten. Um den Overhead für das berechnen von Prioritäten und
das Verwalten von Aktionen zu reduzieren, könnten in einer anderen Ausführungsform
entweder Aktion 5 oder 6 zunächst vollständig abgearbeitet
werden. Anschließend
muss nämlich
nur noch eine Aktion verwaltet werden.
-
Aufgrund
der großen
Restzeit von 1000% in Zeile 1 waren die Prioritäten für die Aktionen 5 und 6 so gering,
dass die Aktionen 1 bis 4 zuerst abgearbeitet wurden. Da ein Hintergrundprozess
in der Regel nicht dringend ist, kann in einer Ausführungsform
jeweils beim Start eines neuen Kommandos die maximale Restausführungszeit
der Hintergrundprozesse so erhöht
werden, dass ihre Prioritäten
klein genug sind, um nach den Aktionen des neuen Kommandos ausgeführt zu werden.
-
In
einer anderen Ausführungsform
können
die Prioritäten
der Aktionen der Hintergrundprozesse während der Ausführung eines
Kommandos auf 0 gesetzt werden.
-
Bisher
wurde stillschweigend angenommen, dass man zu einem beliebigen Punkt
in der Abarbeitung einer Aktion sagen kann, wie lange die verbleibende
Abarbeitung der Aktion noch dauern wird. Tatsächlich kann man eine mehr oder
weniger sorgfältig
bestimmte erwartete Ausführungszeit
tplan für
eine Aktion oder Funktion aus Tabelle 10 lesen und die bisher für die Aktion
verbrauchte Rechenzeit messen. Die erwartete verbleibende Abarbeitungszeit
kann nun aus der Differenz von erwarteter Ausführungszeit minus bisher verbrauchte
Rechenzeit berechnet werden. Die bisher verbrauchte Rechenzeit kann
aber fast bis an die maximale Ausführungszeit heranreichen und
damit größer als
die erwartete Ausführungszeit
sein. Bei dieser Rechenmethode kann die erwartete verbleibende Abarbeitungszeit
und damit die aus Formen (1) bestimmte Priorität negativ werden.
-
Es
ist aber zu erwarten, dass negative Prioritäten nur bei Aktionen auftreten,
die fast vollständig
abgearbeitet sind. Insofern kann man dieses Problem dadurch lösen, daß die erste
Aktion den Zuschlag erhält,
für die
eine negative Priorität
berechnet wird. Nach Abarbeiten aller Aktionen mit negativen Prioritäten funktioniert das
oben beschriebene Verfahren wieder.
-
Ein
weiterer Lösungsweg
um negative Prioritäten
zu vermeiden ist, in Formel (1) die erwartete Ausführungszeit
tzi durch die maximale Ausführungszeit
tui, i = {1, 2, ... 6} zu ersetzen.
-
In
anderen Ausführungsformen
kann man die Formel für
die Priorität
so modifizieren, dass Aktionen mit einer kurzen Ausführungszeit
oder Restausführungszeit
eine höhere
Priorität
als in Formel (1) erhalten. Man kann beispielsweise den Zähler in
Formel (1) gleich 1 setzen oder zusätzlich den Zähler in
den Nenner schreiben. Bei dieser Ausführungsform werden kurze Aktionen
bevorzugt abgearbeitet, so dass sich die Anzahl der Aktionen und
damit der Overhead zur Verwaltung der Aktionen schnell reduziert.
-
Mit
obigem Verfahren können
auch mehrere Kommandos verwaltet werden, die quasi parallel von
der Smartcard bearbeitet werden. So könnte Kommando A kontaktloses
Kommando sein, das schnell beantwortet werden muss und der Hintergrundprozess
B könnte
ein kontaktbehaftetes Kommando sein, für dessen Beantwortung mehr
Zeit zur Verfügung
steht. Natürlich
können
mit obigem Verfahren auch mehr als zwei Kommandos und Hintergrundprozesse
verwaltet werden.
-
Obwohl
die Erfindung vorstehend im Zusammenhang mit Smartcards erläutert wurde,
ist Fachleuten klar, dass die Erfindung auch bei anderen portablen
Datenträgern
wie beispielsweise USB-Tokens, Dongels, MMCs, Mobiltelefonen und
PDAs etc. eingesetzt werdern kann. Als Schnittstelle kommen ferner
USB-Stecker, parallele und serielle Schnittstellen (Centronics,
IEEE1284, RS232), Bluetooth, Infrarot-Schnittstellen, GSM, UMTS
etc. in Frage. Die Erfindung kann ferner bei fest in anderen Geräten eingebauten
Sicherheitsmodulen wie beispielsweise Trusted Platform Moduls (TPM)
verwendet werden. Sicherheitsmodule werden auch als manipulationsgesicherte
Einheiten bezeichnet.
-
Die
Erfindung wurde zuvor anhand von bevorzugten Ausführungsformen
näher erläutert. Für einen Fachmann
ist jedoch offensichtlich, dass verschiedene Abwandlungen und Modifikationen
gemacht werden können,
ohne vom Geist der Erfindung abzuweichen. Deshalb wird der Schutzbereich
durch die nachfolgenden Ansprüche
und ihre Äquivalente
festgelegt.
