-
Gebiet der Erfindung
-
Die Erfindung betrifft das Installieren eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul, nämlich einer sicheren Prozessoreinrichtung mit beschränkten Rechenressourcen, sowie das Aktualisieren eines installierten Betriebssystems.
-
Stand der Technik
-
Sicherheitsmodule, nämlich sichere Prozessoreinrichtungen mit beschränkten Rechenressourcen, in Form von Chipkarten-Produkten sind seit langer Zeit bekannt. Als derartige Chipkarten-Produkte sind im Telekommunikationsbereich SIM-Karten oder UICCs (UICC = Universal Integrated Circuit Card), im Zahlungsverkehrsbereich Zahlungsverkehrschipkarten, im Gesundheitsbereich Gesundheitskarten-Chipkarten und Heilberufsausweis-Chipkarten, sowie im Identitätenbereich elektronische Personalausweise mit Chip und elektronische Reisepässe mit Chip als Sicherheitsmodule bekannt. Als Sicherheitsmodule sind weiter mit Chip und Schnittstelle (kontaktbehaftet oder/und kontaktlos) Inlays für elektronische Reisepässe und Chipkarten weitere Vorprodukte für Chipkarten bekannt. Zum Betrieb eines Chipkarten-Produktes ist ein Chipkarten-Produkt-Leser erforderlich, mit dem das Chipkarten-Produkt in entfernbarer Weise kontaktbehaftet oder kontaktlos gekoppelt werden kann.
-
Zunehmend fassen Sicherheitsmodule (sichere Prozessoreinrichtungen mit beschränkten Rechenressourcen) Fuß, die funktionell den obenstehend aufgelisteten und weiteren Chipkarten-Produkten entsprechen, ohne einen Chipkarten-Produkt-Körper zu haben, und die in einen Chip eines mobilfunkfähigen Endgeräts (mobilen Endgeräts) eingebettet oder eingelötet sind, oder als gesicherte Software innerhalb eines mobilfunkfähigen Endgeräts (mobilen Endgeräts) verwirklicht sind. Derartige Sicherheitsmodule sind fest mit dem mobilfunkfähigen Endgerät (mobilen Endgerät) gekoppelt und nicht oder nicht ohne Weiteres aus diesem entfernbar. Beispiele für Sicherheitsmodule, die den Chipkarten-Produkten funktionell gleichgestellt sind, ohne Chipkarten zu sein, sind im Telekommunikationsbereich embedded UICCs, eUICCs, und in einen Chip eines mobilen Endgeräts integrierte integrated UICCs, iUICCs, sowie in Software nachgebildete SIM-Karten, genannt eSIMs. Im Zahlungsverkehrsbereich gibt es als Sicherheitsmodule ohne Chipkartenkörper, beispielsweise, in einem Secure Element innerhalb eines mobilen Endgeräts oder in einem eUICC oder in einem iUICC vorgehaltene Zahlungsverkehrslösungen. Im Identitätenbereich gibt es als Sicherheitsmodule ohne Chipkartenkörper oder vergleichbaren physischen Körper, beispielsweise, in einem Secure Element innerhalb eines mobilen Endgeräts vorgesehene virtuelle elektronische Personalausweise und virtuelle elektronische Reisepässe.
-
Jedes operationsfähige Sicherheitsmodul (sichere Prozessoreinrichtung mit beschränkten Rechenressourcen) besitzt ein Betriebssystem, das grundlegende Funktionalitäten des Sicherheitsmoduls zur Verfügung stellt. Zu den grundlegenden Funktionalitäten zählen operative Funktionalitäten wie beispielsweise Speicherverwaltung einschließlich Schreiben von Daten in Speicher und Auslesen von Daten aus Speichern des Sicherheitsmoduls. Zu den grundlegenden Funktionalitäten zählen weiter Funktionalitäten zum Datenaustausch mit externen Einheiten, beispielsweise mit einem mobilfunkfähigen Endgerät, in welchem das Sicherheitsmodul betrieben wird, oder mit einem lokalen oder entfernten Server. Zu den Funktionalitäten zum Datenaustausch zählen beispielsweise Implementierungen von Übertragungsprotokollen für den Datenaustausch. Zu den grundlegenden Funktionalitäten zählen weiter Funktionalitäten zur Absicherung anderer Funktionalitäten, beispielsweise kryptographische Algorithmen, beispielsweise kryptographische Algorithmen zur Verschlüsselung oder/und Entschlüsselung von Daten jeder Art, oder kryptographische Algorithmen zur Erzeugung oder/und Verifizierung kryptographischer Signaturen.
-
Betriebssysteme für Sicherheitsmodule sind in Java Card Code sowie in nativem Code bekannt.
-
Herkömmlicherweise wird, um ein Sicherheitsmodul mit einem Betriebssystem auszustatten, das Betriebssystem als Ganzes in das Sicherheitsmodul geladen und im Sicherheitsmodul installiert. Hierzu wird außerhalb des Sicherheitsmodul das vollständige Betriebssystem in einer geeigneten Form bereitgestellt, so dass das Betriebssystem als Ganzes in das Sicherheitsmodul geladen und dort installiert werden kann, beispielsweise in Form eines Installationspakets für das vollständige Betriebssystem.
-
Ein Teil des Erstellens des Betriebssystems von Sicherheitsmodulen ist der Einbau kryptographischer Algorithmen in das Betriebssystem. Hierzu werden ein Betriebssystem-Grundgerüst und ein oder mehrere kryptographische Algorithmen separat als Source Code erstellt, und anschließend die Source Codes der ein oder mehreren kryptographischen Algorithmen in den Source Code des Betriebssystem-Grundgerüsts eingebaut. Ähnlich können Bibliotheken (Libraries) getrennt vom Betriebssystem-Grundgerüst erstellt werden und anschließend in das Betriebssystem-Grundgerüst eingebaut werden.
-
Werden später Änderungen, beispielweise Aktualisierungen oder/und Fehlerbehebungen, am Betriebssystem durchgeführt, so wird außerhalb des Sicherheitsmoduls eine vollständige geänderte Version des Betriebssystems erstellt, in welcher die Änderungen, beispielweise Aktualisierungen oder/und Code-Patches zur Umsetzung von Fehlerbehebungen, verwirklicht sind, und das geänderte Betriebssystem als Ganzes in das Sicherheitsmodul geladen und dort installiert, in ähnlicher Weise wie das ursprüngliche Betriebssystem geladen und installiert worden ist.
-
Bei Änderungen am Betriebssystem für das Sicherheitsmodul sind unter Umständen nur geringe Anteile des Betriebssystems durch die Änderungen betroffen, und andere Anteile des Betriebssystems bleiben gegenüber der im Sicherheitsmodul bereits vorhandenen Version des Betriebssystems unverändert. Dennoch muss das gesamte Betriebssystem neu geladen und installiert werden. Hierdurch kann der Aufwand an zu ladender und zu installierender Datenmenge sehr groß sein im Vergleich zu den durchgeführten Änderungen. Das Durchführen der Änderungen am Betriebssystem ist dadurch ineffizient und langsam.
-
Als Änderungen am Betriebssystem können beispielweise Aktualisierungen oder Fehlerbehebungen oder Anpassungen an geänderte Anwendungsfälle vorgesehen sein. Ein geänderter Anwendungsfall kann beispielsweise auch darauf zurückzuführen sein, dass ein für einen ersten Kunden erstelltes Betriebssystem auch für einen zweiten Kunden verwendet werden soll, der zwar vom Grundsatz her den gleichen Anwendungsfall wie der erste Kunde nutzt, jedoch unterschiedliche Detaillösungen für Teilaspekte des Betriebssystems wünscht. Hierdurch kann das für den ersten Kunden erstellte Betriebssystems zwar wiederverwendet werden, allerdings mit geringen Änderungen oder Anpassungen.
-
Verbreitet besteht für Betriebssysteme für Sicherheitsmodule die Notwendigkeit, das Betriebssystem zu zertifizieren. Damit das Betriebssystem die Zertifizierung erlangt, muss das Betriebssystem durch eine zugelassene Zertifizierungseinrichtung systematischen Tests unterzogen werden und die Tests bestehen. Werden Änderungen am Betriebssystem vorgenommen, ist in der Regel eine erneute Zertifizierung des gesamten Betriebssystems erforderlich. Selbst wenn ein Betriebssystem für zwei in derselben Branche aktive Kunden verwendet werden soll, mit nur geringfügigen Variationen zwischen den Betriebssystem-Versionen für die beiden Kunden, kann es sein, dass beide Betriebssystem-Versionen nebeneinander und unabhängig voneinander vollständig zertifiziert werden müssen.
-
Ein spezielles Szenario einer Änderung des Betriebssystems ist er Austausch einer im Betriebssystem integrierten Implementierung eines kryptographischen Algorithmus, beispielsweise durch eine aktualisierte oder fehlerbereinigte Implementierung desselben Algorithmus, oder durch einen anderen, z.B. aktuelleren, Algorithmus. Beispielsweise könnte eine Implementierung des Advanced Encryption Standard AES, bei der Schwächen entdeckt wurden, durch eine abgeänderte Implementierung des AES ersetzt werden. Gemäß einem anderen Beispiel könnte der Data Encryption Standard DES durch den neueren AES ersetzt werden. Herkömmlicherweise wird hierzu außerhalb des Sicherheitsmoduls der Source Code des neuen oder geänderten kryptographischen Algorithmus in den Source Code des Betriebssystem-Grundgerüsts eingebaut, um den zuvor vorhandenen Source Code des kryptographischen Algorithmus zu ersetzen. Anschließend wird das geänderte Betriebssystem, d.h. der Source-Code des gesamten geänderten Betriebssystems, umfassend den Source Code des neuen oder geänderten kryptographischen Algorithmus und den Source Code des Betriebssystem-Grundgerüsts, neu zertifiziert und in das Sicherheitsmodul geladen und im Sicherheitsmodul installiert.
-
Wünschenswert wäre eine effizientere und flexiblere Lösung zur Installierung und Änderung, insbesondere Aktualisierung, eines Betriebssystems in einem Sicherheitsmodul, die es erlaubt, die Installation und Änderung, speziell eine spätere Aktualisierung, des Betriebssystems schneller und mit weniger Ressourcenaufwand zu erreichen.
-
Das Dokument
US8522234B2 aus dem Stand der Technik offenbart ein computerimplementiertes Verfahren zum Maßschneidern der Installation eines modularen Betriebssystems in ein Computersystem. Das modulare Betriebssystem umfasst ein Basismodul und eine Mehrzahl von installierbaren Merkmalsmodulen. Basierend auf gewünschten Performanz-Eigenschaften des Betriebssystems und vorbestimmter Betriebskapazität sowie verfügbarer Speicherkapazität des Computersystems werden Teile des modularen Betriebssystems selektiv installiert, um die gewünschten Performanz-Eigenschaften bei Beibehaltung der Betriebskapazität und verfügbaren Speicherkapazität bestmöglich zu erreichen. Um dies zu erreichen, werden nur die erforderlichen, bzw. angesichts der beizubehaltenden Betriebskapazität und frei zu bleibenden Speicherkapazität zulässigen, Module durch einen Betriebssystem-Maßschneider („tailorer“) zusammengesetzt und das so erzeugte Betriebssystem installiert.
-
Das Dokument
US6292941B1 aus dem Stand der Technik offenbart ein Verfahren zum Installieren und Anpassen eines Betriebssystems auf einem lokalen Computer, wobei ein angepasstes Betriebssystem auf dem lokalen Computer eingerichtet wird, indem ein lokal in einem entfernbaren Speicher des lokalen Computers bereitgestelltes Standard-Betriebssystem aus der Ferne angepasst wird, mit einem Anpassungsmodell, das von einem entfernten Verwaltungscomputer bereitgestellt wird.
-
Zusammenfassung der Erfindung
-
Der Erfindung liegt die Aufgabe zu Grunde, eine effizientere und flexiblere Lösung zur Installierung und Änderung, insbesondere Aktualisierung, eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul, zu schaffen, die es erlaubt, die Installation und Änderung, speziell eine spätere Aktualisierung, des Betriebssystems schneller und mit weniger Ressourcenaufwand zu erreichen.
-
Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
-
Der Kerngedanke der Erfindung besteht darin, durch eine modulare Installationslösung eine durchzuführende Installation zielgerichtet auf gewünschte Teile des Betriebssystems zu reduzieren, und andere Teile des Betriebssystems bei der Installation wegzulassen oder für andere Installationsschritte vorzusehen.
-
Das erfindungsgemäße Verfahren nach Anspruch 1 ist im Detail zum Installieren eines Betriebssystems, oder von Teilen eines Betriebssystems, in einer Prozessoreinrichtung vorgesehen. Das Betriebssystem umfasst eine Mehrzahl von zwei oder mehr Betriebssystem-Funktionalitäten.
-
Das Verfahren umfasst Schritte: - Laden des Betriebssystems, oder der Teile des Betriebssystems, in die Prozessoreinrichtung; - Installieren des geladenen Betriebssystems, oder der geladenen Teile des Betriebssystems, in der Prozessoreinrichtung. Das Verfahren ist dadurch gekennzeichnet, dass
- a) das Laden des Betriebssystems, oder der Teile des Betriebssystems, als Laden zumindest eines oder mehrerer voneinander getrennter Betriebssystem-Module erfolgt,
wobei das oder das jeweilige Betriebssystem-Modul: - b) Code enthält, der dazu eingerichtet ist, eine dem Betriebssystem-Modul entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren; und
- c) ein getrenntes Installieren nur der dem jeweiligen Betriebssystem-Modul entsprechenden Betriebssystem-Funktionalität ermöglicht, insbesondere ohne dass weitere Betriebssystem-Funktionalitäten installiert werden.
-
Das Vorsehen der voneinander getrennten Betriebssystem-Module, die jeweils Code enthalten, der dazu eingerichtet ist, eine dem Betriebssystem-Modul entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren, ermöglicht es, maßgeschneidert und gezielt nur ausgewählte Funktionalitäten des Betriebssystems zur Installation bereitzustellen, und anschließend zu installieren. Andere Betriebssystem-Funktionalitäten, die gerade nicht zu installieren sind, beispielsweise weil sie nicht benötigt werden oder unverändert bleiben, werden nicht bereitgestellt. Entsprechend lässt sich durch die modulare Gestaltung des Codes zur Installation des Betriebssystems, oder der Teile des Betriebssystems, das zu installierende Datenvolumen stark reduzieren. Das reduzierte Datenvolumen führt zu einer Reduktion von Zeit und Rechenressourcen, die zur Installation erforderlich sind. Dies gilt gleichermaßen, unabhängig davon, ob die Installation auf eine Erstinstallation eines Betriebssystems oder von Teilen davon gerichtet ist, oder auf eine Änderung, oder Aktualisierung eines bereits installierten Betriebssystems, oder von Teilen eines solchen Betriebssystems, oder auf eine Änderung eines Betriebssystems in Form einer Änderung bereits installierter Teile eines Betriebssystems, oder auf eine Änderung in Form einer Erweiterung eines installierten Betriebssystems um noch nicht vorhandene Betriebssystemteile.
-
Daher ist gemäß Anspruch 1 ein Verfahren geschaffen, bei dem die Installation und Änderung, speziell eine spätere Aktualisierung, des Betriebssystems schneller und mit weniger Ressourcenaufwand erreichbar ist.
-
Ein weiterer Vorteil der Erfindung besteht darin, dass aufgrund des geringeren zu installierenden Datenvolumens das Risiko von Datenfehlern, Datenübertragungsfehlern bei der Übertragung des Codes in die Prozessoreinrichtung und Installationsfehlern bei der Installation des Codes in der Prozessoreinrichtung reduziert werden kann.
-
Ein weiterer Vorteil der Erfindung besteht darin, dass auf Grund der Möglichkeit, einzelne voneinander getrennte Betriebssystem-Module und damit Betriebssystem-Funktionalitäten, isoliert voneinander zu laden und zu installieren, die Möglichkeit eröffnet ist, die einzelnen voneinander getrennten Betriebssystem-Module und damit Betriebssystem-Funktionalitäten getrennt voneinander zu evaluieren und durch zugelassene Zertifizierungseinrichtungen, beispielsweise akkreditierte Prüflabore, zertifizieren zu lassen. Wird nur ein bestimmtes Betriebssystem-Modul und die damit verbundene Betriebssystem-Funktionalität verändert, so kann durch eine geeignete Trennung oder Isolierung der Betriebssystem-Module voneinander erreicht werden, dass nur dieses Betriebssystem-Modul und die damit verbundene Betriebssystem-Funktionalität neu zertifiziert werden muss. Die Zertifizierung der unverändert bleibenden Betriebssystem-Module und damit Betriebssystem-Funktionalitäten bleibt unberührt.
-
Zur Trennung oder Isolierung von unterschiedlichen ausführbaren Programmcodes sind unterschiedliche Maßnahmen bekannt, die auch auf die erfindungsgemäßen Betriebssystem-Module, als ausführbaren Programmcodes, anwendbar sein können. Beispielhafte Maßnahmen zur Trennung von Codes sind Kontexte, Sicherheitsdomänen und Sandbox-Mechanismen.
-
Wahlweise sind unterschiedliche Betriebssystem-Module in unterschiedlichen Sicherheitsdomänen, insbesondere Global Platform Sicherheitsdomänen, angeordnet und werden in den unterschiedlichen Sicherheitsdomänen ausgeführt.
-
Wahlweise ist das - oder das jeweilige - Betriebssystem-Modul weiter d) von anderen Betriebssystem-Modulen isoliert, so dass ein Zugriff zwischen dem Betriebssystem-Modul - oder dem jeweiligen Betriebssystem-Modul - und anderen Betriebssystem-Modulen verhindert ist, oder nur höchstens mittels kontrollierter Schnittstellenmechanismen möglich ist. Im Fall dass die Prozessoreinrichtung Java oder Java Card basiert ist, kann als kontrollierter Schnittstellenmechanismus beispielsweise ein Shareable Interface Object oder Entry Point Object vorgesehen sein.
-
Das Installieren des Betriebssystems oder der Teile des Betriebssystems erfolgt wahlweise als getrenntes Installieren der geladenen getrennten Betriebssystem-Module. Alternativ erfolgt das Installieren des Betriebssystems oder der Teile des Betriebssystems als gemeinsames Installieren der geladenen getrennten Betriebssystem-Module. Wahlweise erfolgt das Installieren für manche Betriebssystem-Module als getrenntes Installieren der geladenen getrennten Betriebssystem-Module, und für manche Betriebssystem-Module als gemeinsames Installieren der geladenen getrennten Betriebssystem-Module.
-
Unterschiedliche Szenarien zur Installation eines Betriebssystems oder von Teilen eines Betriebssystems können ein unterschiedliche Anzahlen von Betriebssystem-Modulen, und/oder unterschiedlich große Anteile am Betriebssystem umfassen, im Maximalfall das gesamte Betriebssystem. Wird eine Anzahl von mehreren Betriebssystem-Modulen auf einmal zur Installation geladen, kann die Installation der mehreren Betriebssystem-Module wahlweise einzeln erfolgen, oder alternativ im Block, wobei also in Bezug auf den Vorgang der Installation die Modularität nicht mehr wirkt. Welche Vorgehensweise bei der Installation im Einzelfall vorteilhaft ist, kann von unterschiedlichen Rahmenbedingungen abhängig sein.
-
Wahlweise sind als voneinander getrennte Betriebssystem-Module vorgesehen:
- - zumindest ein Trusted Loader, der dazu eingerichtet ist, weitere Betriebssystem-Module in die Prozessoreinrichtung zu laden, und zu veranlassen, die weiteren Betriebssystem-Module in der Prozessoreinrichtung zu installieren; und
- - zusätzlich ein oder mehrere funktionelle Betriebssystem-Module.
-
Der Trusted Loader ist gemäß der hier beschriebenen Ausführungsform wahlweise das erste Betriebssystem-Modul, das in der Prozessoreinrichtung installiert wird, und ermöglicht nachfolgend das Laden und die Installation weiterer Betriebssystem-Module in der Prozessoreinrichtung durch den Trusted Loader.
-
Der Trusted Loader ist wahlweise selbst kein funktionelles Betriebssystem-Modul, sondern exklusiv dazu eingerichtet ist, weitere Betriebssystem-Module in die Prozessoreinrichtung zu laden, und zu veranlassen, die weiteren Betriebssystem-Module in der Prozessoreinrichtung zu installieren.
-
Wahlweise umfasst der Trusted Loader, zusätzlich zur Funktionalität weiter Betriebssystem-Module zu laden, bereits Module für Basis-Funktionalitäten des Betriebssystems, wie: - Speicherverwaltung von Speichereinheiten der Prozessoreinrichtung; - Lesen oder/und Schreiben von Daten, einschließlich Programmen, in Speichereinheiten der Prozessoreinrichtung; - Bearbeiten vom Befehlen in der Prozessoreinrichtung, einschließlich Empfangen von Befehlen, Ausführen von Befehlen, Erstellen von Befehlen und Ausgeben von Befehlen. Alternativ werden diese Basis-Funktionalitäten durch gesonderte Betriebssystem-Module bereitgestellt.
-
Wahlweise sind als funktionelle Betriebssystem-Module ein oder mehrere der folgenden vorgesehen:
- - ein Basis-Funktionalitäten-Modul, durch dessen Installation ein oder mehrere Basis-Funktionalitäten des Betriebssystems in der Prozessoreinrichtung installiert werden;
- - ein kryptographischer-Algorithmus-Modul, durch dessen Installation eine Implementierung eines kryptographischen Algorithmus in der Prozessoreinrichtung installiert wird;
- - ein Library-Module, durch dessen Installation eine Library in der Prozessoreinrichtung installiert wird;
- - ein Protokoll-Modul, durch dessen Installation eine Implementierung eines Protokolls zur Kommunikation der Prozessoreinrichtung mit außerhalb der Prozessoreinrichtung angeordneter Einheiten installiert wird;
- - eine aktualisierte Version eines der vorangehenden funktionellen Betriebssystem-Module, die als Ersatz oder Ergänzung für eine bereits in der Prozessoreinrichtung installierte Version desselben funktionellen Betriebssystem-Moduls in die Prozessoreinrichtung geladen und in der Prozessoreinrichtung installiert wird.
-
Als kryptographischer Algorithmus kann beispielsweise ein symmetrischer oder asymmetrischer Algorithmus vorgesehen sein, wie DES, AES, 3DES, RSA, oder ein anderer Algorithmus.
-
Als Protokoll kann wahlweise ein Übertragungsprotokoll für Chipkarten oder ähnliche chipbasierte Produkte vorgesehen sein, wie ISO/IEC 7816 T=0 oder T=1, ISO/IEC 14443, near field communication NFC, single wire protocol SWP oder Password Authenticated Connection Establishment PACE für maschinenlesbare Reisedokumente. Als Protokoll kann außerdem wahlweise ein Übertragungsprotokoll für Zahlungsverkehrs- oder Telekommunikations- oder Identitäten/Reisepassanwendungen vorgesehen sein.
-
Wahlweise ist oder sind als Basis-Funktionalität eine oder mehrere der folgenden vorgesehen oder:
- - Speicherverwaltung von Speichereinheiten der Prozessoreinrichtung;
- - Lesen oder/und Schreiben von Daten, einschließlich Programmen, in Speichereinheiten der Prozessoreinrichtung;
- - Bearbeiten vom Befehlen in der Prozessoreinrichtung, einschließlich Empfangen von Befehlen, Ausführen von Befehlen, Erstellen von Befehlen und Ausgeben von Befehlen.
-
Wahlweise ist das Betriebssystem-Modul als Java Card Cap-File gemäß der Java Card Spezifikation gestaltet.
-
Wahlweise ist in dem Betriebssystem-Modul Java Card Code oder nativer Code oder sowohl Java Card Code als auch nativer Code enthalten. Insbesondere kann in einem Java Card Cap-File neben Java Code zusätzlich nativer Code enthalten sein.
-
Wahlweise erfolgt das Laden eines Betriebssystem-Moduls, indem ein Service, in dem das Betriebssystem-Modul integriert ist, in die Prozessoreinrichtung geladen wird. Hierbei ist unter einem Service für ein Betriebssystem-Modul für eine Betriebssystem-Funktionalität eine Instanz, insbesondere ein Programmcode, zu verstehen, der dazu eingerichtet, dass der Service, also z.B. der Programmcode, ausgeführt wird. Durch die Ausführung des in die Prozessoreinrichtung geladenen Service (z.B. Programmcode) wird die im Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert.
-
Wahlweise ist das Betriebssystem zumindest teilweise oder ganz als Java Card basiertes Betriebssystem gestaltet. Hierbei ist der Service als ein Java Card Applet gestaltet, und das Betriebssystem-Modul als Java Card Cap-File gestaltet. Der Service wird ausgeführt, indem das Java Card Applet aufgerufen und zur Ausführung gebracht wird. Hierdurch wird die dem Java Card Cap-File entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert. Auch bei dieser Ausführungsform kann in dem Java Card Cap-File neben Java Code zusätzlich nativer Code enthalten sein.
-
Wahlweise ist das Java Card Applet, durch welches der Service verwirklicht ist, als modifiziertes Java Card Applet gestaltet, welches dahingehend modifiziert ist, dass das modifizierte Java Card Applet durch die Befehle process() und select(), mit denen ein standardgemäßes Java Card Applet aufrufbar ist, nicht aufrufbar ist, sondern nur über ein kontrolliertes Schnittstellenobjekt, insbesondere ein Shareable Interface Object oder Entry Point Object, verfügt und aufrufbar ist.
-
Wahlweise ist bei Ausführungsformen, die ein Java Card Applet einsetzen, dem Java Card Applet ein Applikations-Identifikator, AID, zugeordnet, wobei in der Prozessoreinrichtung eine Registry eingerichtet ist, in welche der Applikations-Identifikator, AID, des Java Card Applet beim Laden des Applet in die Prozessoreinrichtung eingetragen wird. Das Java Card Applet wird in diesem Fall anhand des in der Registry eingetragenen Applikations-Identifikator, AID, aufgerufen und zur Ausführung gebracht. Wahlweise erfolgt der Aufruf des Java Card Applet weiter unter Verwendung eines auf den Service weisenden Unified Ressource Identifier Strings, URI-Strings. Wird der URI-String aufgerufen, so wird die dem Java Card Cap-File entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert.
-
Wahlweise werden unterschiedliche Services für unterschiedliche Betriebssystem-Module in unterschiedlichen Kontexten ausgeführt, die voneinander isoliert sind.
-
Die Kontexte sind wahlweise insbesondere mittels Einwirkens einer Mikroprozessoreinrichtung MPU oder/und einer Speicherverwaltung MPU isoliert. Wahlweise ist eine Wechselwirkung oder Kommunikation zwischen unterschiedlichen Services nur über einen kontrollierten Schnittstellenmechanismus möglich, insbesondere ein Shareable Interface Object oder/und ein Entry Point Object.
-
Die Isolation der Kontexte ist vor allem in Zusammenhang der Zertifizierung der Prozessoreinrichtung vorteilhaft. Die Isolation der Kontexte kann insbesondere dazu beitragen, den Aufwand der Neu-Zertifizierung bei Änderungen am Betriebssystem zu verringern.
-
Wahlweise ist die Isolation der Kontexte derart gestaltet, dass sie entsprechend anzuwendender Zertifizierungsvorschriften für die Prozessoreinrichtung ausreichend ist, dass bei Änderungen an einem Betriebssystem-Modul in einem ersten Kontext, die bestehenden Zertifizierungen anderer Betriebssystem-Module in anderen Kontexten, die vom ersten Kontext isoliert sind, durch die Änderung unberührt bleiben. Hierdurch wird erreicht, dass nur das geänderte Betriebssystem-Modul und die damit verbundene Betriebssystem-Funktional neu zertifiziert werden muss.
-
Wahlweise ist jedes Betriebssystem-Modul getrennt zertifiziert. Hierdurch kann in einem vollständig zertifizierten Betriebssystem, in welchem nur ein einzelnes Betriebssystem-Modul, oder eine Gruppe von einzelnen Betriebssystem-Modulen, und die damit verbundene(n) Betriebssystem-Funktionalität(en) verändert wird (werden), die bestehende Zertifizierung für die unverändert gebliebenen Bestandteile des Betriebssystems erhalten bleiben, und nur die geänderten Betriebssystemteile (Modul(e), Funktionalität(en)) müssen neu zertifiziert werden.
-
In der Zertifizierung sind unterschiedliche hierarchisch gestufte Level von Zertifizierung vorgesehen. Je höher das Level der Zertifizierung, umso strenger sind die Prüfvorgaben. Hat eine Prozessoreinrichtung ein gewisses Level der Zertifizierung bestanden, so gilt sie gemäß diesem Level und aller darunter liegenden niedrigeren Levels als zertifiziert. Höhere Levels gelten als nicht erreicht, und die Prozessoreinrichtung als für die höheren Levels nicht zertifiziert.
-
Je höher das Level der Zertifizierung, umso höher ist in der Regel das Spektrum an Einsatzmöglichkeiten einer zertifizierten Prozessoreinrichtung. Daher ist ein möglichst hohes Level von Zertifizierung erstrebenswert. Ein hohes Level von Zertifizierung bedeutet andererseits einen hohen Aufwand an Maßnahmen, insbesondere Sicherheitsmaßnahmen, die in der Prozessoreinrichtung vorgesehen werden müssen, um die Zertifizierungstest zu bestehen. Als Maßnahmen können beispielsweise Programmroutinen zur Abwehr von Seitenkanalangriffen, Hackerangriffen und Ähnliches vorgesehen sein, wie Maskierung, Verschlüsselung, Verschleierung, Redundanzen und weitere. Um die Prozessoreinrichtung entsprechend auszustatten sind zeit- und kostenaufwändige Entwicklungsarbeiten erforderlich. Zudem steigt mit den Maßnahmen die Komplexität des Produkts, was bei unsorgfältiger Implementierung wieder Fehlerrisiken nach sich ziehen kann. Zudem sind die Tests für höhere Zertifizierungslevels zeitaufwändiger und kostspieliger als Tests für niedrigere Zertifizierungslevels. Entsprechend wird nicht stets das höchste Level von Zertifizierung angestrebt, sondern typischerweise nur ein für den konkreten Anwendungszweck ausreichendes Zertifizierungslevel.
-
Durch den Trusted Loader werden andere Betriebssystem-Module in die Prozessoreinrichtung geladen. Somit nimmt der Trusted Loader Einfluss auf jedes durch ihn geladene Betriebssystem-Modul. Entsprechend kann ein durch den Trusted Loader geladenes Betriebssystem-Modul maximal das Level an Zertifizierung haben, welches der Trusted Loader erlangt (bestanden) hat, selbst wenn das Betriebssystem-Modul außerhalb der Prozessoreinrichtung eine Zertifizierung auf einem höheren Level erlangt (bestanden) hat.
-
Wahlweise hat im Fall, dass ein Trusted Loader vorgesehen ist, der Trusted Loader relativ zu anderen Betriebssystem-Modulen das höchste oder zumindest kein schlechteres Level von Zertifizierung. Hierdurch wird das Level der anderen Betriebssystem-Module, die durch den Trusted Loader nachgeladen werden können, stets erhalten und niemals verschlechtert.
-
Auf analoge Weise wie die Betriebssystem-Module können in die Prozessoreinrichtung zusätzlich Applikations-Module zur Installation von Applikationen geladen werden. Wahlweise können in manchen Betriebssystem-Modulen Applikations-Module enthalten sein, und mit einem solchen Betriebssystem-Modul auch darin enthaltene Applikations-Module in die Prozessoreinrichtung geladen und dort installiert werden.
-
Wahlweise ist als Prozessoreinrichtung ein Sicherheitsmodul vorgesehen, also eine sichere Prozessoreinrichtungen mit beschränkten Rechenressourcen, insbesondere eine Chipkarte oder ein entsprechendes Prozessormodul ohne ein kartenförmigen Körper.
-
Wahlweise umfasst die Prozessoreinrichtung:
- - mindestens eine Prozessoreinheit zur Verarbeitung von Daten einschließlich Programmen,
- - mindestens eine Speichereinheit, umfassend ein oder mehrere Speicher, zum Speichern von Daten einschließlich Programmen,
- - mindestens eine Schnittstelleneinheit zum Austausch von Daten einschließlich Programmen mit außerhalb der Prozessoreinrichtung angeordneten Einheiten.
-
Kurze Beschreibung der Zeichnungen
-
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
- 1 eine schematische Darstellung einer modulweisen Installation und modularen Erweiterung eines Betriebssystems durch sequentielle Installation mehrerer Betriebssystem-Module, gemäß Ausführungsformen der Erfindung;
- 2 eine schematische Darstellung einer Anordnung von mehreren Java-basierten, in voneinander isolierten Kontexten auszuführenden Betriebssystem-Modulen, gemäß Ausführungsformen der Erfindung;
- 3 ein als Service gestaltetes Betriebssystem-Modul, gemäß Ausführungsformen der Erfindung.
-
Detaillierte Beschreibung von Ausführungsbeispielen
-
1 zeigt eine schematische Darstellung einer modulweisen Installation und modularen Erweiterung eines Betriebssystems durch sequentielle Installation mehrerer Betriebssystem-Module in einer Prozessoreinrichtung, gemäß Ausführungsformen der Erfindung.
-
Teil-1-1 von 1 zeigt die Prozessoreinrichtung in einem ersten Zustand der Installation 1-1, in welchem nur ein Trusted Loader TL in der Prozessoreinrichtung installiert ist. Der Trusted Loader TL umfasst in diesem Fall bereits erste Basis-Funktionalitäten BOS des Betriebssystems. Alternativ könnten die Basis-Funktionalitäten BOS des Betriebssystems auch erst durch den Trusted Loader TL in die Prozessoreinrichtung geladen werden.
-
Teil-1-2 von 1 zeigt die Prozessoreinrichtung in einem zweiten Zustand der Installation 1-2, in welchem in der Prozessoreinrichtung, zusätzlich zum Trusted Loader TL mit den die Basis-Funktionalitäten BOS des Betriebssystems gemäß 1-1, aus zwei (oder mehr) Betriebssystem-Modulen OSM1, (...) OSMn diverse Betriebssystem-Funktionalitäten und aus einem Library-Modul LIBM1 (Bibliotheken-Modul) eine Library installiert sind. Hierzu sind die zwei Betriebssystem-Module OSM1, OSMn und das Library-Modul LIBM1 in die Prozessoreinrichtung geladen worden, die Module OSM1, OSMn, LIB2 in der Prozessoreinrichtung zur Ausführung gebracht worden, und dadurch die diverse Betriebssystem-Funktionalitäten und die Library in der Prozessoreinrichtung installiert worden.
-
Teil-1-3 von 1 zeigt die Prozessoreinrichtung in einem dritten Zustand der Installation 1-3, in welchem in der Prozessoreinrichtung, zusätzlich zu den in 1-2 gezeigten Modulen und Funktionalitäten, eine weitere Library aus einem weiteren Library-Modul LIB2 und zwei Applikationen aus zwei Applikations-Modulen APM1, APM2 installiert worden sind. Zusätzlich sind Betriebssystem-Funktionalitäten, die aus dem ersten Betriebssystem-Modul OS1 installiert worden waren, deinstalliert oder/und gelöscht worden.
-
2 zeigt eine schematische Darstellung einer Prozessoreinrichtung, in der eine Anordnung von mehreren Java-basierten (genauer Java Card spezifischen), in voneinander isolierten Kontexten auszuführenden Betriebssystem-Modulen enthalten ist, gemäß Ausführungsformen der Erfindung. In der Prozessoreinrichtung ist ein Trusted Loader TL enthalten. Der Trusted Loader enthält Basisfunktionalitäten des Betriebssystems Base OS bereits selbst, oder er hat die Basisfunktionalitäten durch Laden von ein oder mehreren Basis-Funktionalitäten-Modulen geladen und in der Prozessoreinrichtung installiert. Die Prozessoreinrichtung enthält drei Services BOS Service, Service 1 und Service 2. Jeder der drei Services enthält ausführbaren Programmcode, durch dessen Ausführung der Nutzdateninhalt des Service in der Prozessoreinrichtung installiert wird. Jeder der drei Services ist von den anderen beiden Services durch eine Kontextgrenze L isoliert, so dass jeder Service, wenn er ausgeführt wird, in seinem eigenen isolierten Kontext ausgeführt wird.
-
Jeder Service enthält als Nutzdateninhalt ein Cap-File gemäß der Java Card Spezifikation, in welchem der zu installierende Code enthalten ist. Das Cap-File enthält in der in 2 gezeigten Ausführungsform sowohl Java Code als auch nativen Code.
-
Ein erster der drei Services BOS Service ist ein Betriebssystem-Modul zur Installation von weiteren Basis-Funktionalitäten des Betriebssystems.
-
Ein zweiter der drei Services Service 1 ist ein Betriebssystem-Modul zur Installation eines kryptographischen Algorithmus in der Prozessoreinrichtung.
-
Ein dritter der drei Services Service 2 ist ein Betriebssystem-Modul zur Installation eines integrierten Teilnehmeridentitätsmoduls iUICC in der Prozessoreinrichtung.
-
Weitere ähnliche Services können in die Prozessoreinrichtung geladen und darin zur Ausführung gebracht werden, beispielsweise um eine Zahlungsverkehrsapplikation oder eine Wallet-Applikation in der Prozessoreinrichtung zu installieren.
-
3 zeigt ein als Service gestaltetes Betriebssystem-Modul umfassend ein Java Card Cap File in Detailansicht, gemäß Ausführungsformen der Erfindung. Der Service enthält ein Java Card Cap-File, das Java Code gemäß der Java Card Spezifikation enthält. Der Java Code ist in ein oder mehreren Files (Dateien), den Java Source Files (Dateien), mit der Java-(Card-)spezifischen Namensendung *.java enthalten. Das in 3 gezeigte beispielhafte Cap File enthält weiter eine Static Ressource Komponente, mittels welcher nativer Code und Ressourcen zum Java Card Cap-File hinzugefügt werden kann. Der native Code kann in ein oder mehreren Files (Dateien), vorgesehen sein. Nativer Code kann beispielsweise im *.bin oder *.hex Format vorliegen. Native Ressourcen können beispielsweise im *.txt oder *.html Format vorliegen. Das Cap-File bzw. der Java Code ist in Java-Card-typischer Weise strukturiert und enthält beispielsweise Datenelemente wie Header, Directory, ein oder mehrere Applets, Import-Informationen, einen Constant-Pool (Konstanten-Pool), Classes (Klassen), und dergleichen. Nativer Code und Ressourcen können mittels des Static Ressource Elements als statische Ressourcen zum Cap-File hinzugefügt werden.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 8522234 B2 [0014]
- US 6292941 B1 [0015]
