EP2936729A1 - Verfahren zum betreiben eines sicherheitsmoduls sowie ein solches sicherheitsmodul - Google Patents

Abstract

Es wird ein Verfahren zum Betreiben eines Sicherheitsmoduls mit einer Prozessoreinheit, einer Speichereinheit und einer IO-Schnittstelle (12) zur Kommunikation mit einer Terminaleinrichtung bereitgestellt, wobei ein Teil der Speichereinheit als IO-Buffer (19) verwendet wird. Dabei umfasst das Verfahren die folgenden Schritte: das Verschlüsseln der Daten, die für eine Übersendung an die Terminaleinrichtung vorgesehen sind, beim Einschreiben in den IO-Buffer (19) mit einer Verschlüsselungsoperation; und das Entschlüsseln der Daten bei der Übergabe an die IO-Schnittstelle (12) mit einer zu der Verschlüsselungsoperation inversen Entschlüsselungsoperation. Ferner wird ein entsprechend ausgestaltetes Sicherheitsmodul, vorzugsweise in Form einer Chipkarte oder eines Chipkartenmoduls, bereitgestellt.

Description

Verfahren zum Betreiben eines Sicherheitsmoduls

sowie ein solches Sicherheitsmodul Die Erfindung betrifft ein Verfahren zum Betreiben eines Sicherheitsmoduls sowie ein solches Sicherheitsmodul. Insbesondere betrifft die Erfindung ein Verfahren zum Betreiben eines Sicherheitsmoduls in Form einer Chipkarte oder eines Chipmoduls sowie eine solche Chipkarte oder ein solches Chipmodul.

Sicherheitsmodule in Form von Chipkarten mit einer Prozessoreinheit, auch Mikroprozessor-Chipkarten oder Prozessorkarten genannt, werden in vielen sicherheitskritischen Bereichen eingesetzt, beispielsweise als Ausweisdokumente, zum Nachweis der Zugangsberechtigung eines Teilnehmers z.B. zu einem Mobilfunknetz oder zur Durchführung von Zahlungsverkehrstransaktionen. Der Einsatz der Chipkarte erfolgt dabei häufig im Zusammenspiel mit einem für die jeweilige Anwendung vorgesehenen Terminaleinrichtung mit einer Leseeinheit, die dazu ausgestaltet ist, nach einer vorhergehenden Authentisierung sicherheitskritische Daten aus einer solchen Chipkarte aus- zulesen.

Bei der Durchführung von sicherheitskritischen Anwendungen durch ein Sicherheitsmodul, beispielsweise eine Chipkarte, ist ein Schutz des Sicherheitsmoduls und der darin hinterlegten sicherheitskritischen Daten, wie bei- spielsweise kryptographische Schlüssel, vor Angriffen und unberechtigten Manipulationen notwendig.

Ein Beispiel einer unberechtigten Manipulation ist die Störung der Strom- und Taktversorgung des Mikroprozessors einer Chipkarte durch Span- nungsspitzen bzw. Lichtblitze. Ein weithin aus dem Stand der Technik bekannter Angriff ist dabei die sogenannte differentielle Fehleranalyse (DFA = Differential Fault Analysis), mit der sich der geheime Schlüssel einer mittels eines Mikroprozessors durchgeführten kryptographischen Berechnung auf einer Chipkarte ermitteln lässt. Bei einem DFA- Angriff werden in dem Mikroprozessor, der eine kryptographische Berechnung durchführt, Berech- nungsfehler ausgelöst, was durch die vorstehend erwähnten Spannungsspitzen bzw. Lichtblitze erreicht werden kann. Aus den erzeugten Fehlern kann dann mittels mathematischer Methoden der für die kryptographische Berechnung verwendete geheime Schlüssel ermittelt werden. Bei kombinierten Spähangriffen wird über Seitenkanäle wie z.B. dem Stromverbrauch oder die elektromagnetische Abstrahlung der Chipkarte ein geeigneter Zeitpunkt für eine gezielte Störung ermittelt und zu diesem Zeitpunkt die Störung durchgeführt. Beispielsweise können signifikante Merkmale im Stromverbrauch wie z.B. Peaks des Stromverlaufs auf geeignete Zeitpunkte zum Einbringen einer Störung hinweisen.

Besonders anfällige Ziele für die vorstehend beschriebenen Lichtangriffe sind in der Regel auch die IO-Schnittstelle der Chipkarte zur Kommunikation mit einer Terminaleinrichtung sowie ein üblicherweise als Teil des Betriebssystems der Chipkarte implementierter IO-Manager, der den Daten- verkehr in die Chipkarte hinein und aus diesem heraus verwaltet. Es ist vorstellbar, dass es durch einen geeigneten Lichtangriff zu einer Fehlfunktion der Chipkarte kommt, bei der Daten über die IO-Schnittstelle ausgegeben werden, die nicht ausgegeben werden, d.h. geheim bleiben sollten. Der Erfindung liegt somit die Aufgabe zugrunde, ein Sicherheitsmodul mit einer Prozessoreinheit und einer Speichereinheit resistenter insbesondere gegenüber den vorstehend beschriebenen Angriffen zu machen, indem eine weitere Gegenmaßnahme gegen derartige Angriffe bereitgestellt wird, die insbesondere vor Fehlfunktionen des Sicherheitsmoduls bei der Datenausgabe schützt.

Diese Aufgabe wird durch ein Verfahren zum Betreiben eines Sicherheits- moduls mit einer Prozessoreinheit, einer Speichereinheit und einer IO-

Schnittstelle zur Kommunikation mit einer Terminaleinrichtung gemäß Anspruch 1 sowie durch ein solches Sicherheitsmodul gemäß dem unabhängigen Vorrichtungsanspruch gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen angegeben.

Die Erfindung basiert auf dem Grundgedanken, auf die Daten, die von der Prozessoreinheit des Sicherheitsmoduls dafür vorgesehen sind, über eine IO- Schnittstelle des Sicherheitsmoduls ausgegeben zu werden, und hierzu in einen IO-Buffer der Speichereinheit des Sicherheitsmoduls eingeschrieben werden, beim Einschreiben in den IO-Buffer eine erste Verschlüsselungsoperation anzuwenden. Bei der Übergabe dieser Daten aus dem IO-Buffer an die IO-Schnittstelle wird auf diese Daten eine zweite, zu der ersten Verschlüsselungsoperation inverse Verschlüsselungsoperation angewendet. Mittels der Erfindung kann somit sichergestellt werden, dass nur die zum Senden bereitgestellten Daten, die einer Verschlüsselung und einer Entschlüsselung unterzogen werden, unverschlüsselt ausgesendet werden. Alle anderen Daten, die möglicherweise mit Hilfe von Lichtangriffen aus dem Sicherheitsmodul ausgelesen werden könnten, sind verschlüsselt, da diese nur einer einmaligen Verschlüsselung unterzogen werden.

Auf der Basis des vorstehend beschriebenen Grundgedankens wird gemäß einem ersten Aspekt der Erfindung ein Verfahren zum Betreiben eines Sicherheitsmoduls mit einer Prozessoreinheit, einer Speichereinheit und einer IO-Schnittstelle zur Kommunikation mit einer Terminaleinrichtung bereitgestellt, wobei ein Teil der Speichereinheit von der Prozessoreinheit als IO- Buffer verwendet wird. Dabei umfasst das Verfahren die folgenden Schritte: das Verschlüsseln der Daten, die für eine Übersendung an die Terminalein- richtung vorgesehen sind, beim Einschreiben in den IO-Buffer mit einer Verschlüsselungsoperation; und das Entschlüsseln der Daten bei der Übergabe an die IO-Schnittstelle mit einer zu der Verschlüsselungsoperation inversen Entschlüsselungsoperation.

Ferner wird gemäß einem zweiten Aspekt der Erfindung ein Sicherheitsmodul mit einer Prozessoreinheit, einer Speichereinheit und einer IO- Schnittstelle zur Kommunikation mit einer Terminaleinrichtung bereitgestellt, wobei ein Teil der Speichereinheit von der Prozessoreinheit als IO- Buffer verwendet wird und das Sicherheitsmodul dazu ausgestaltet ist, Daten, die für eine Übersendung an die Terminaleinrichtung vorgesehen sind, beim Einschreiben in den IO-Buffer mit einer Verschlüsselungsoperation zu verschlüsseln, und Daten bei der Übergabe an die IO-Schnittstelle mit einer zu der Verschlüsselungsoperation inversen Entschlüsselungsoperation zu entschlüsseln.

Vorzugsweise wird der IO-Buffer von einem IO-Manager verwaltet, der Teil eines Betriebssystems des Sicherheitsmoduls ist.

Gemäß bevorzugter Ausführungsformen der Erfindung handelt es sich bei der Verschlüsselungsoperation und bei der Entschlüsselungsoperation um eine XOR-Operation. Alternativ handelt es sich bei der Verschlüsselungsoperation um eine symmetrische Verschlüsselungs- und Entschlüsselungsoperation, vorzugsweise AES, DES, 3DES oder IDEA, oder eine asymmetrische Verschlüsselungs- und Entschlüsselungsoperation, vorzugsweise RSA. Bei der Verschlüsselungsoperation und der Entschlüsselungsoperation können kommandospezifische, sessionspezifische oder kartenspezifische Schlüssel zum Einsatz kommen. Vorzugsweise handelt es sich bei dem Sicherheitsmodul um eine Chipkarte oder ein Chipkartenmodul. Ferner kann es sich bei dem Sicherheitsmodul auch um eine SIM-Karte, ein M2 -Modul eine eUICC (embedded integrated circuit card) handeln. Die Erfindung weist insbesondere die folgenden Vorteile auf. Bei einem Lichtangriff könnte der Fall eintreten, dass Daten aus dem IO-Buffer unter Überspringung der Entschlüsselung bei der Übergabe an die IO-Schnittstelle ausgegeben werden. Da diese Daten beim Einschreiben in den IO-Buffer jedoch verschlüsselt worden sind, kann der Angreifer mit diesen verschlüssel- ten Daten nichts anfangen. Bei einem weiteren denkbaren Fall, bewirkt der Lichtangriff, dass andere Bereiche der Speichereinheit fälschlicherweise als IO-Buffer interpretiert werden und die dort hinterlegten Daten an die Terminaleinrichtung übermittelt werden. Da die in diesen fälschlicherweise als IO-Buffer interpretierten Bereichen der Speichereinheit vorliegenden Daten bei der Übergabe an die IO-Schnittstelle mit einer zu der Verschlüsselungsoperation inversen Entschlüsselungsoperation entschlüsselt werden, was einer einmaligen Verschlüsselung entspricht, kann auch in diesem Fall der Angreifer mit den verschlüsselten Daten nichts anfangen. Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden detaillierten Beschreibung mehrerer Ausführungsbeispiele und Ausführungsalternativen hervor. Es wird auf die Zeichnungen verwiesen, in denen zeigen: Fig. 1 eine schematische Darstellung einer bevorzugten Ausführungsform eines erfindungsgemäßen Sicherheitsmoduls in Form einer Chipkarte in Kommunikation mit einer Terminaleinrichtung, und

Fig. 2 eine schematische Darstellung der Architektur eines Betriebssystems zum Betreiben des Sicherheitsmoduls von Figur 1 und dessen Wechselwirkung mit einem IO-Buffer gemäß einer bevorzugten Ausführungsform der Erfindung.

Figur 1 zeigt eine schematische Darstellung einer bevorzugten Ausführungsform eines erfindungsgemäßen Sicherheitsmoduls in Form einer Chipkarte 10. Die Chipkarte 10 ist dazu ausgestaltet mit einer externen Instanz in Form einer Terminaleinrichtung 20 Daten auszutauschen. Als ein Austausch von Daten wird hier eine Signalübertragung, eine wechselseitige Steuerung und in einfachen Fällen auch eine Verbindung zwischen der Chipkarte 10 und der Terminaleinrichtung 20 verstanden. Im Allgemeinen kann ein Datenaustausch durch das aus der Informationstheorie bekannte Sender-Empfänger- Modell beschrieben werden: Daten bzw. Informationen werden in Zeichen kodiert und dann von einem Sender über einen Übertragungskanal an einen Empfänger übertragen. Dabei ist entscheidend, dass der Sender und der Empfänger dieselbe Kodierung verwenden, damit der Empfänger die Nachricht verstehen kann, d.h. die empfangenen Daten dekodieren kann. Zur Datenübertragung bzw. Kommunikation zwischen der Chipkarte 10 und der Terminaleinrichtung 20 weisen sowohl die Chipkarte 10 als auch die Terminaleinrichtung 20 geeignete Kommunikations- bzw. IO-Schnittstellen 12 und 22 auf. Die IO-Schnittstellen 12 und 22 können beispielsweise so ausgestaltet sein, dass die Kommunikation zwischen diesen bzw. zwischen der Chipkarte 10 und der Terminaleinrichtung 20 kontaktlos, d.h. über die Luftschnittstelle, erfolgt, wie dies in Figur 1 angedeutet ist. Alternativ kann die Chipkarte 10 über die IO-Schnittstelle 12 galvanisch, d.h. kontaktbehaftet, mit der IO-Schnittstelle 22 der Terminaleinrichtung 20 in Verbindung stehen. In diesem Fall umfasst die IO-Schnittstelle 12 in der Regel ein auf der Chipkarte 10 angeordnetes Kontaktfeld mit mehreren Kontaktflächen zum Datenaustausch mit der Terminaleinrichtung 20. Selbstverständlich werden von der vorliegenden Erfindung auch portable Datenträger umfasst, bei denen die IO-Schnittstelle 12 sowohl zur kontaktbehafteten als auch zur kontaktlo- sen Kommunikation mit einer Terminaleinrichtung ausgebildet ist und die dem Fachmann im Zusammenhang mit Chipkarten als Dual-Interface- Chipkarten bekannt sind.

Neben der IO-Schnittstelle 12 zur Kommunikation mit der Terminaleinrich- tung 20 umfasst das Sicherheitsmodul 10 in Form einer Chipkarte eine zentrale Prozessoreinheit ("central processing unit"; CPU) 14. Bekanntermaßen gehören zu den hauptsächlichen Aufgaben der Prozessoreinheit 14 das Ausführen von arithmetischen und logischen Funktionen und das Lesen und Schreiben von Daten, wie dies durch ein auf der Prozessoreinheit 14 ablau- fendes Computerprogramm in Form von Maschinenbefehlen definiert wird.

Die Chipkarte 10 umfasst ferner eine Speichereinheit ("memory unit") 16 mit einem flüchtigen Arbeitsspeicher (RAM) beispielsweise zur Aufnahme der Maschinenbefehle eines von der Prozessoreinheit 14 auszuführenden Com- puterprogramms. Ferner umfasst die Speichereinheit 16 einen nichtflüchtigen, vorzugsweise wieder beschreibbaren Speicher. Vorzugsweise handelt es sich bei dem nichtflüchtigen Speicher um einen Flash-Speicher (Flash- EEPROM). Dabei kann es sich beispielsweise um einen Flash-Speicher mit einer NAND- oder einer NOR- Architektur handeln. Selbstverständlich kann die Speichereinheit 16 auch einen Festwertspeicher ("read only memory"; ROM) umfassen.

Wie dies dem Fachmann bekannt ist, kann die Kommunikation zwischen der Prozessoreinheit 14, der Speichereinheit 16, der IO-Schnittstelle 12 und ggf. weiteren Komponenten des Sicherheitsmoduls 10 in Form einer Chipkarte vorzugsweise über einen oder mehrere Daten-, Adress- und/ oder Steuerbusse erfolgen, wie dies in Figur 1 durch Pfeile schematisch angedeutet ist. Der Fachmann wird ferner erkennen, dass ein erfindungsgemäßes Sicher- heitsmodul 10 noch weitere als die in Figur 1 dargestellten elektronischen Bauelemente aufweisen kann. So könnte das Sicherheitsmodul 10 beispielsweise ferner eine mit der Prozessoreinheit 14 interagierende Speicherverwaltungseinheit (MMU; "memory management unit") zur Verwaltung der Speichereinheit 16 oder einen Coprozessor zur Durchführung kryptographischer Berechnungen aufweisen. Ferner könnte das Sicherheitsmodul 10 einen

UART (universal asynchronous receiver transmitter) umfassen, der auch Teil der IO-Schnittstelle 12 des Sicherheitsmoduls 10 sein könnte. Wie dies dem Fachmann bekannt ist, handelt es sich bei einem UART um ein unabhängig von der Prozessoreinheit 14 asynchron arbeitendes elektronisches Bauele- ment zum Senden und Empfangen von Daten. Mit einem UART ist es nicht mehr notwendig, die Kommunikation auf Bit- und Byteebene von der Prozessoreinheit 14 erledigen zu lassen. Dies führt zu einer Vereinfachung der Kommunikationsprotokolle und kann auch zur Realisierung höherer Datenübertragungsgeschwindigkeiten als bei einer reinen Softwarelösung durch die Prozessoreinheit 14 benutzt werden.

Im nichtflüchtigen Speicher der Speichereinheit 16 ist ein Betriebssystem 17 hinterlegt, dass im Betrieb der Chipkarte 10 von der Prozessoreinheit 14 ausgeführt wird und von Zeit zu Zeit auf die Speichereinheit 16 zugreift, wie dies in Figur 1 schematisch dargestellt ist. Das Betriebssystem 17 ist insbesondere dazu ausgestaltet, von der Terminaleinrichtung 20 eingehende Kommandos, die vorzugsweise die Form von Kommando- APD Us (com- mand APDUs) haben, zu verarbeiten sowie eine entsprechende Antwort zu erstellen und diese, vorzugsweise in Form einer Antwort- APDU (response APDU), wieder an die Terminaleinrichtung 20 zu übermitteln. Für weitere Details hinsichtlich des Aufbaus von APDUs wird auf Abschnitt 8.3 des Buches "Handbuch der Chipkarten" von Wolfgang Rankl und Wolfgang Effing, 5. Auflage verwiesen, auf das hiermit vollumfänglich Bezug genommen wird.

Figur 2 zeigt eine schematische Darstellung einer bevorzugten Architektur des auf der Speichereinheit 16 hinterlegten und von der Prozessoreinheit 14 ausgeführten Betriebssystems 17 zur Abarbeitung eines eingehenden Kom- mandos, z.B. eines Kommandos zum Auslesen einer in der Speichereinheit 16 hinterlegten Datei. Dabei läuft die Kommandobearbeitung innerhalb des Betriebssystems 17 der Chipkarte 10 vorzugsweise wie folgt ab.

Alle Kommandos an die Chipkarte 10 empfängt diese über die IO- Schnittstelle 12. Ein IO-Manager 18, der Teil des Betriebssystems 17 ist, sorgt für die Abwicklung der Datenübertragung von und zu der Terminaleinrichtung 20. Insbesondere verwaltet der IO-Manager 18 einen IO-Buffer bzw. IO- Puffer 19, der ein Bereich der Speichereinheit 16 ist und als Sende- und Empfangspuffer dient.

Vorzugsweise kann der IO-Manager 18 ferner dazu ausgestaltet sein, völlig unabhängig von den in Figur 2 dargestellten übrigen darauf aufbauenden Schichten des Betriebssystems 17 bei Bedarf Fehlererkennungs- und Fehler- korrekturmechanismen durchzuführen, um Fehler bei der Datenübertragung von der Terminaleinrichtung 20 zu erkennen oder zu korrigieren.

Nachdem der IO-Manager 18 festgestellt hat, dass ein Kommando vollstän- dig und fehlerfrei empfangen wurde, dient ein Secure Messaging Manager (SM-Manager) 30 auf eine dem Fachmann bekannte Art und Weise dazu, das empfangene Kommando gegebenenfalls zu entschlüsseln oder auf Integrität zu prüfen. Findet keine gesicherte Datenübertragung mittels Secure Messaging statt, ist der SM-Manager 30 sowohl für Kommando als auch Antwort völlig transparent.

Nach dieser Bearbeitung durch den IO-Manager 18 und gegebenenfalls den Secure Messaging Manager 30 versucht die darüber liegende Schicht des Betriebssystems 17 in Form eines Kommandointerpreters 32, das Kommando zu dekodieren. Ist dies nicht möglich, folgt ein Aufruf des Returncode- Managers 34, welcher einen entsprechenden Fehler-Returncode generiert und über den IO-Manager 18 an das Terminal 20 zurücksendet. Falls das Kommando vom Kommandointerpreter 32 dekodiert werden kann, wird das dekodierte Kommando an darüber liegende Schichten des Betriebssystems weitergeleitet, und zwar vorzugsweise als nächstes an einen Logical Channel Manager, der den angewählten Kanal ermittelt, auf dessen Zustände umschaltet und dann im Gutfall einen Zustandsautomaten aufruft, von dem überprüft wird, ob das dekodierte Kommando an die Chipkarte 10 mit den gesetzten Parametern im aktuellen Zustand überhaupt erlaubt ist. Wenn dies der Fall ist, wird das Kommando ausgeführt. Nach der Abarbeitung des Kommandos übernimmt der Returncode-Manager 34 die Erzeugung eines entsprechenden Returncodes. Der Übersichtlichkeit halber sind die vorzugsweise oberhalb des Kommandointerpreters 32 bzw. des Returncode- Managers 34 liegenden weiteren Schichten des Betriebssystems 17 in Figur 2 als gestrichelte Kästchen zusammengefasst worden, da deren Details für die vorliegenden Erfindung nicht relevant sind und dem Fachmann beispielsweise aus Abschnitt 13.2 des Buches "Handbuch der Chipkarten" von Wolfgang Rankl und Wolf gang Effing, 5. Auflage bekannt sind, auf das hiermit vollumfänglich Bezug genommen wird.

Erfindungsgemäß ist nun vorgesehen, dass die vom Returncode-Manager 34 kommenden Daten in Form eines Returncodes (beispielsweise im Fall eines ursprünglich von der Terminaleinrichtung 20 eingehenden Lesekommandos der Inhalt der mit dem Lesekommando identifizierten, auf der Speichereinheit 16 hinterlegten Datei), die gegebenenfalls durch den Secure Messaging Manager 30 auf eine dem Fachmann bekannte Art und Weise noch weiter verarbeitet werden (Verschlüsselung und/ oder Berechnung eines MAC), bei der Ablage in dem vom IO-Manager 18 verwalteten IO-Buffer 19 einer XOR- Operation oder einer anderen kryptographischen Operation unterzogen werden. Der Fachmann wird somit erkennen, dass unabhängig davon, ob die Daten bereits vom Secure Messaging Manger 30 verschlüsselt worden sind oder nicht, erfindungsgemäß die Daten aufgrund der XOR-Operation oder einer anderen kryptographischen Operation im IO-Buffer 19 verschlüs- seit vorliegen.

Erfindungsgemäß ist nun weiter vorgesehen, dass die im IO-Buffer 19 verschlüsselt vorliegenden Daten bei der Übergabe an die IO-Schnittstelle 12 zur Übertragung an die Terminaleinrichtung 20 einer weiteren XOR- Operation unterzogen werden, und zwar mit demselben Schlüssel, mit dem die Daten beim Einschreiben in den IO-Buffer 19 der XOR-Operation unterzogen worden sind. Wie dies dem Fachmann bekannt ist, entspricht eine zweimalige XOR-Operation mit ein und demselben Schlüssel der Identitätsabbildung, so dass die vom IO-Manager 18 an die IO-Schnittstelle 12 überge- benen Daten wieder in der Form vorliegen, wie der IO-Manager 18 diese von den darüber liegenden Schichten des Betriebssystems 17 erhalten hat.

Wie vorstehend bereits erwähnt, können erfindungsgemäß statt einer zwei- maligen XOR-Operation auch andere Verschlüsselungs- und Entschlüsselungsoperationen verwendet werden, um die Daten beim Einschreiben in den IO-Buffer 19 zu verschlüsseln und bei der Übergabe an die IO- Schnittstelle 12 wieder zu entschlüsseln. Beispielsweise können erfindungsgemäß auch symmetrische Verschlüsselungs- und Entschlüsselungsoperati- onen eingesetzt werden, wie beispielsweise DES, 3DES, AES, IDEA oder dergleichen, oder auch asymmetrische Verschlüsselungs- und Entschlüsselungsoperationen, wie RSA. Die entsprechenden symmetrischen oder asymmetrischen Schlüssel hierfür können in der Speichereinheit 16 der Chipkarte 10 sicher hinterlegt sein. Wesentlich für die Erfindung ist ledig- lieh, dass die Anwendung der Verschlüsselungsoperation auf die Daten und die anschließende Anwendung der Entschlüsselungsoperation auf das Ergebnis der ersten Verschlüsselung wieder auf die ursprünglichen Daten zurückführt. Der Fachmann wird erkennen, dass bei Ausführungsformen, bei denen zur Verschlüsselung eine blockweise verschlüsselnde Verschlüsselungsoperation verwendet wird, kann es vorteilhaft sein, geeignete Padding- Verfahren zu verwenden. Für den Fall, dass auf der Chipkarte 10 ein eigenständiger Kryp- tocoprozessor vorgesehen ist, können die Verschlüsselungs- und Entschlüs- selungsoperationen vorzugsweise von diesem Kryptocoprozessor durchgeführt werden.

Beim Einsatz einer XOR-Operation zur Verschlüsselung und Entschlüsselung der Daten wird der hierzu verwendete Schlüssel vorzugsweise nur einmal, d.h. bei der Abarbeitung von nur einem Kommando, zum Verschlüsseln und Entschlüsseln eingesetzt. Bei der Abarbeitung weiterer Kommandos werden vorzugsweise entsprechende weitere Schlüssel für die Durchführung der XOR-Operationen verwendet. Insbesondere bei symmetrischen 5 oder asymmetrischen Verschlüsselungs- und Entschlüsselungsoperation sind auch Realisierungen mit sessionspezifischen Sitzungsschlüsseln oder kartenindividuelle Schlüssel realisierbar. Wie dies dem Fachmann bekannt ist, können derartige Schlüssel für die erfindungsgemäße Durchführung der XOR-Operationen, der symmetrischen oder asymmetrischen Verschlüsselt) lungs- und Entschlüsselungsoperation beispielsweise mittels eines in Software und/ oder Hardware implementierten Zufallszahlengenerators erzeugt werden.

Claims

P a t e n t a n s p r ü c h e

1. Verfahren zum Betreiben eines Sicherheitsmoduls (10) mit einer Prozessoreinheit (14), einer Speichereinheit (16) und einer IO-Schnittstelle (12) zur Kommunikation mit einer Terminaleinrichtung (20), wobei ein Teil der Speichereinheit (16) als IO-Buffer (19) verwendet wird, wobei das Verfahren die folgenden Schritte umf asst: das Verschlüsseln der Daten, die für eine Übersendung an die Terminaleinrichtung (20) vorgesehen sind, beim Einschreiben in den IO-Buffer (19) mit einer Verschlüsselungsoperation; und das Entschlüsseln der Daten bei der Übergabe an die IO-Schnittstelle (12) mit einer zu der Verschlüsselungsoperation inversen Entschlüsselungsoperation.

2. Verfahren nach Anspruch 1, wobei der IO-Buffer (19) von einem IO- Manager (18) verwaltet wird, der Teil eines Betriebssystems (17) des portablen Datenträgers (10) ist.

3. Verfahren nach Anspruch 1 oder 2, wobei es sich bei der Verschlüsse- lungsoperation und bei der Entschlüsselungsoperation um eine XOR-

Operation handelt.

4. Verfahren nach Anspruch 1, wobei es sich bei der Verschlüsselungsoperation um eine symmetrische Verschlüsselungsoperation handelt, vorzugsweise AES, DES, 3DES oder IDEA, oder eine asymmetrische Verschlüsselungsoperation handelt, vorzugsweise RSA.

5. Verfahren nach Anspruch 1, wobei bei der Verschlüsselungsoperation und der Entschlüsselungsoperation kommandospezifische, sessionspezifi- sehe oder kartenspezifische Schlüssel verwendet werden.

6. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem Sicherheitsmodul (10) um eine Chipkarte, ein Chipkartenmodul, eine SIM-Karte, ein M2M-Modul oder eine eUICC handelt.

7. Sicherheitsmodul (10) mit einer Prozessoreinheit (14), einer Speichereinheit (16) und einer IO-Schnittstelle (12) zur Kommunikation mit einer Terminaleinrichtung (20), wobei ein Teil der Speichereinheit (16) als IO- Buffer (19) verwendet wird und das Sicherheitsmodul (10) dazu ausgestaltet ist, Daten, die für eine Übersendung an die Terminaleinrichtung (20) vorge- sehen sind, beim Einschreiben in den IO-Buffer (19) mit einer Verschlüsselungsoperation zu verschlüsseln, und Daten bei der Übergabe an die IO- Schnittstelle (12) mit einer zu der Verschlüsselungsoperation inversen Entschlüsselungsoperation zu entschlüsseln.

8. Sicherheitsmodul (10) nach Anspruch 7, wobei der IO-Buffer (19) von einem IO-Manager (18) verwaltet wird, der Teil eines Betriebssystems (17) des portablen Datenträgers (10) ist.

9. Sicherheitsmodul (10) nach Anspruch 7 oder Anspruch 8, wobei es sich bei der Verschlüsselungsoperation und bei der Entschlüsselungsoperation um eine XOR-Operation handelt.

10. Sicherheitsmodul (10) nach Anspruch 7 oder Anspruch 8, wobei es sich bei der Verschlüsselungsoperation um eine symmetrische Verschlüsse- lungsoperation handelt, vorzugsweise AES, DES, 3DES oder IDEA, oder eine asymmetrische Verschlüsselungsoperation handelt, vorzugsweise RSA.

11. Sicherheitsmodul (10) nach Anspruch 7 oder Anspruch 8, wobei bei der Verschlüsselungsoperation und der Entschlüsselungsoperation kom- mandospezifische, sessionspezifische oder kartenspezifische Schlüssel verwendet werden.

12. Sicherheitsmodul (10) nach einem der Ansprüche 7 bis 11, wobei es sich bei dem portablen Datenträger (10) um eine Chipkarte, ein Chipkartenmodul, eine SIM-Karte, ein M2M-Modul oder eine eUICC handelt.