DE102020001883A1

DE102020001883A1 - Verfahren zum Schützen von Secure Elements durch Fernüberwachung ihrer Stromverbrauchsprofile

Info

Publication number: DE102020001883A1
Application number: DE102020001883.1A
Authority: DE
Inventors: Santosh Kumar Mishra; Raghavendran Rangarajan
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: Giesecke and Devrient Mobile Security GmbH
Priority date: 2020-03-23
Filing date: 2020-03-23
Publication date: 2021-01-28

Abstract

Hierin offenbart ist ein hardwareunabhängiges Verfahren zum Testen von absichtlich oder auf andere Weise verursachtem Stromverlust in einer chipintern ausgeführten Anwendung durch Vergleichen von deren tatsächlichem und geschätztem Stromverbrauchsprofil. Die Schätzung des Stromverbrauchsprofils ist mittels eines auf einem Secure Element installierten Profilerstellungsapplets möglich, während der tatsächliche Stromverbrauch mittels Steckern/Anschlüssen bestimmt wird. Jedwede Nichtübereinstimmung in einem derartigen Vergleich wird mit anomalem Stromverbrauch gleichgesetzt und im Sinne einer weiteren Diagnose oder von Gegenmaßnahmen, um die Sicherheit des Secure Elements zu wahren, gemeldet.

Description

Gebiet der Erfindung
Diese Erfindung betrifft allgemein Technologien zur Gewährleistung der Sicherheit vernetzter Vorrichtungen, insbesondere darin installierter/empfangener Secure Elements, in IdD-Anwendungen. Genauer gesagt betrifft die vorliegende Erfindung ein Verfahren zum Erreichen der genannten Absicht durch Fernüberwachung und derart durch das Identifizieren jedweder Anomalie betreffend Stromverbrauchsprofile der Secure Elements.
Definitionen und Auslegungen
Vor Beginn der folgenden Beschreibung kann es vorteilhaft sein, Definitionen gewisser Wörter oder Ausdrücke darzulegen, die in diesem gesamten Patentdokument verwendet werden: Die Begriffe „einschließen“ und „umfassen“ sowie Beugungsformen davon stehen für einen Einschluss ohne Einschränkung; der Begriff „oder“ ist einschließlich und steht für „und/oder“; die Ausdrücke „verbunden mit“ und „damit verbunden“ sowie Beugungsformen davon können für „einschließen“, „eingeschlossen sein in“, „miteinander verbinden“, „mit“, „enthalten“, „enthalten sein in“, „koppeln an oder mit“, „kommunizierbar mit“, „zusammenwirken mit“, „verflechten“, „gegenüberstellen“, „nahe liegen an“, „gebunden sein an oder verbunden sein mit“, „aufweisen“, „eine Eigenschaft aufweisen“ oder dergleichen stehen; und der Begriff „UICC“ bezeichnet eine Universal Integrated Circuit Card; „IdD“ bezeichnet das Internet der Dinge; „Secure Element“ bezeichnet eine UICC oder einen eigenständigen Sicherheitschip, der in einem IdD-Anschluss empfangen oder installiert wurde, und kann in weiterer Folge eine Chipkarte bezeichnen; „API“ bezeichnet die Anwendungsprogrammierschnittstelle („Application Programming Interface“), „SIM“ bezeichnet ein Teilnehmeridentifikationsmodul („subscriber identification module“); „SoC“ bezeichnet ein chipinternes System („system on chip“); „ROM“ bezeichnet einen Nur-Lese-Speicher („read-only memory“); „RAM“ bezeichnet einen Direktzugriffsspeicher („random access memory“); „M2M“ bedeutet von Maschine zu Maschine („machine to machine“); „MG“ bezeichnet ein Mobilgerät, das in der Lage ist, ein oder mehrere Secure Elements für die registrierte Teilnahme an einem Kommunikationsnetzwerk zu empfangen oder vorinstalliert aufzuweisen.
Hintergrund der Erfindung und Beschreibung des einschlägigen Fachgebiets
Die Sicherheit elektronischer Informationen ist in hohem Maße erstrebenswert. Bei kommunikationsfähigen Vorrichtungen, bei denen die Bedrohung unbefugter Verbreitung von Informationen allgegenwärtig ist, liegt diese Notwendigkeit in zugespitztem Maße vor. Neben der unbefugten Verbreitung von Informationen von einer Kommunikationsvorrichtung ist es auch wichtig, die genannte Kommunikationsvorrichtung selbst vor böswilligen Versuchen zu schützen, die Funktionsfähigkeit der Kommunikationsvorrichtung oder innerhalb der genannten Kommunikationsvorrichtung aufbewahrte oder verarbeitete Informationsinhalte oder beides zu erhalten, abzuleiten, zu verderben, zu deaktivieren oder zu stören.
Das Konzept der UICC-basierten Kommunikationsfähigkeit entfaltet ein großes Potenzial bei vernetzten Anwendungen wie IdD-Systemen. Typischerweise schließt ein IdD-System eine Vielzahl von Anschlüssen ein, die alle mindestens eines von einem Prozessor, einer Batterie (oder Stromquelle) und einem Speicher einschließen. Die Fähigkeit zur registrierten Teilnahme an und gegebenenfalls zur Ausführung angestrebter Funktionen innerhalb der vernetzten Anwendungen wird typischerweise mittels Installierens oder Empfangens eines Secure Elements in dem genannten IdD-Anschluss aktiviert. Es versteht sich, dass die registrierte Teilnahme an eine SIM-Karte innerhalb des genannten Secure Elements delegiert wird, während die Ausübung der angestrebten Funktionen eine Folge dessen ist, dass entsprechende API oder Applets auf den genannten Secure Elements vorab angeordnet oder drahtlos heruntergeladen wurden.
Der Tradition zuwiderlaufend verfügt die Konzeption von Secure Elements und SoC heute über bessere Mikrocontroller, ROM und RAM und bieten daher eine erhöhte Kapazität zum Speichern und/oder Verarbeiten einer erheblich größeren Datenmenge und zum Ausüben unzähliger Funktionen. Diese Kapazitäten haben neue Möglichkeiten zur Vernetzung von UICC-basierten interaktiven Anschlüssen für eine sinnvolle Verwendung eröffnet, erhöhen jedoch gleichermaßen die Gefahren für die Sicherheit der Daten und Vorgänge darin. Daher wäre es erstrebenswert, über einige Mittel zum Schützen UICC-basierter interaktiver Anschlüsse vor Sicherheitslücken und daraus resultierenden Gefahren zu schützen, mit einem oder allen der folgenden Folgen:

a) Verletzung von Geheimhaltungspflichten
b) Beeinträchtigung/Erschleichung von Dienstleistungen
c) Verlust/Beeinträchtigung der Datenintegrität (Beschädigung von Daten)
d) Erzwungene Ablehnung oder anomale Bereitstellung von Dienstleistungssituationen

Es versteht sich, dass Secure Elements in IdD-Anschlüssen Sicherheitslücken unterliegen, wenn sie innerhalb der genannten IdD-Anschlüsse installiert oder empfangen werden. Deutlicher ausgedrückt liegen die Schwachstellen zusätzlich zu den Vorgängen des IdD-Anschlusses im Normalbetrieb in der internen Kommunikationsfähigkeit zwischen dem IdD-Anschluss und dem Secure Element. Beispielsweise

a) können auf dem Secure Element installierte Anwendungen von sich aus fehlerhaft sein oder in böswilliger Absicht (infolge eines Angriffs) zur Ausführung gebracht werden, obwohl sie nicht benötigt werden, oder sich endlos wiederholen, wodurch sich die Batterie/Stromversorgung des IdD-Anschlusses entlädt; oder
b) können auf dem IdD-Anschluss installierte Anwendungen von sich aus fehlerhaft sein oder in böswilliger Absicht (infolge eines Angriffs) zur Ausführung gebracht werden, obwohl sie nicht benötigt werden, oder sich endlos wiederholen, wodurch sich die Batterie/Stromversorgung des IdD-Anschlusses entlädt; oder
c) kann der IdD-Anschlusss von sich aus fehlerhaft sein oder in böswilliger Absicht (infolge eines Angriffs) zum Meiden eines falschen Batteriezustands gebracht werden und sich dadurch überladen, was die Gefahr einer Explosion oder eines Brandes des IdD-Anschlusses mit sich bringt, oder zu wenig laden, was die Gefahr eines verfrühten/suboptimalen Dienstzyklus vor dem nächsten Wiederaufladen mit sich bringt; oder
d) kann infolge der vorstehend unter den Punkten a) bis c) aufgeführten Vorfälle ein abrupter Funktionsverlust eintreten.

Das Erstellen von Stromverbrauchsprofilen ist ein logischer Weg, um die vorstehend genannten Schwachstellen zu identifizieren und damit auszubessern. Die Profilerstellung kann für den Stromverbrauch, der bei Ausführungszyklen der installierten Anwendungen anfällt, oder für die Energieumwandlung oder das Energy Harvesting bei Sendern, Mobilfunkantennen, Bewegung und anderen in den IdD-Anschluss eingebauten Quellen durchgeführt werden. Da eine solche Profilerstellung auch Strom verbraucht, ist es insbesondere dann unerwünscht/nicht möglich, sie durchzuführen, wenn der Batteriezustand einen vorbestimmten Schwellenwert unterschreitet. Andererseits ist das Messen des Verbrauchs an den Spannungsstiften des Secure Elements nicht ausfallsicher oder genau, da das Betriebssystem über einen eigenen Energiebedarf verfügt, der beim alleinigen Abmessen der Verbrauchsprofile von Applets stört/Rauschen verursachen kann. Daher ist es erforderlich, dass die Erstellung der Energieverbrauchsprofile chipintern durchgeführt wird, d. h. auf dem Secure Element selbst.
Daher führt der Stand der Technik in dem untersuchten Umfang keine einzige wirksame Lösung an, die sämtliche vorstehend erwähnten Überlegungen abdeckt, wodurch eine akute Erfindungsnotwendigkeit auf dem entsprechenden Fachgebiet erhalten bleibt. Die Erfinder der vorliegenden Erfindung haben durch gezielte Forschung eine neuartige Lösung gefunden, um zumindest einen Großteil dieser Bedürfnisse ein für alle Mal zu stillen. Arbeiten der genannten Erfinder, die speziell gegen die vorstehend genannten technischen Probleme gerichtet sind und derzeit zum Gemeingut gehören, einschließlich früher eingereichter Patentanmeldungen, werden weder ausdrücklich noch stillschweigend als Stand der Technik gegen die vorliegenden Offenbarungen anerkannt, die als völlig neu und erfinderisch gelten.
Ein besseres Verständnis der Ziele, Vorteile, Merkmale, Eigenschaften und Beziehungen der vorliegenden Erfindung erschließt sich aus der folgenden ausführlichen Beschreibung, die eine veranschaulichende, jedoch bevorzugte Ausführungsform darlegt.
Ziele der vorliegenden Erfindung
Die vorliegende Erfindung identifiziert sich dadurch, dass sie mindestens die im vorhergehenden Abschnitt erörterten Hauptmängel des Standes der Technik alle durch ein Verfolgen der folgenden, nachstehend aufgeführten Ziele behebt:

Ein vorrangiges Ziel besteht darin, ein Verfahren zur Gewährleistung der Sicherheit von Secure Elements durch Fernüberwachung ihrer Stromverbrauchsprofile bereitzustellen.
Ein anderes Ziel neben dem bzw. den vorstehend genannten Ziel(en) besteht darin, dass bei dem genannten Verfahren charakteristische Kennwerte/Signaturen, die auf anomales Verhalten hinweisen, auf ausfallsichere Weise genau identifiziert werden.
Ein anderes Ziel neben dem bzw. den vorstehend genannten Ziel(en) besteht darin, dass die genannte Profilerstellungsanwendung die Bestimmung von Energieverbrauchsprofilen von chipintern ausgeführten Applets im Bytecode-Format ermöglicht, anstatt über Hardware-Anschlüsse/-Punkte des Secure Elements zu messen.
Ein anderes Ziel neben dem bzw. den vorstehend genannten Ziel(en) besteht darin, dass die genannte Profilerstellungsanwendung in der Lage ist, Energieverbrauchsprofile von chipintern ausgeführten Applets zu messen.
Ein anderes Ziel neben dem bzw. den vorstehend genannten Ziel(en) besteht darin, das genannte Verfahren mittels einer Profilerstellungsanwendung zu implementieren, die so ausgeführt ist, dass sie sich auf dem Secure Element selbst befindet.
Ein anderes Ziel neben dem bzw. den vorstehend genannten Ziel(en) besteht darin, dass die Implementierung des genannten Verfahrens ohne oder höchstens mit minimalen Änderungen des Aufbaus bereits vorhandener Secure Elements möglich ist.
Ein anderes Ziel neben dem bzw. den vorstehend genannten Ziel(en) besteht darin, dass die Implementierung des genannten Verfahrens keine speziellen Kenntnisse oder Fähigkeiten seitens des Endbenutzers oder des IdD-Anschlusses erfordert.
Die Art und Weise, in der die vorstehenden Ziele erreicht werden, sowie andere Ziele und Vorteile, die sich später zeigen werden, liegen in der ausführlichen Beschreibung, die nachstehend unter Bezugnahme auf die beigefügten Zeichnungen dargelegt und darüber hinaus im Hauptanspruch 1 konkret umrissen ist. Andere vorteilhafte Ausführungsformen der Erfindung sind in den Nebenansprüchen angegeben.

Kurzfassung
Die vorliegende Erfindung versucht, die Mängel des Standes der Technik zu beheben, indem sie die vorstehend angegebenen Ziele erreicht. Insbesondere wird ein Verfahren bereitgestellt, bei dem eine auf einem Secure Element bereitgestellte chipinterne Profilerstellungsanwendung angeordnet ist, Stromverbrauchsprofile von Applets vorherzusagen, die das genannte Secure Element ausführt.
Figurenliste
Die vorliegende Erfindung wird hier unter Bezugnahme auf die folgenden Zeichnungen erläutert, wobei:

1 ein Flussbild ist, das die der vorliegenden Erfindung zugrunde liegende Logik erläutert.

Die vorstehend genannten Zeichnungen veranschaulichen bestimmte Beispiele für die vorliegende Erfindung, sollen jedoch deren Umfang nicht einschränken. Die Zeichnungen sind nicht maßstabsgetreu (sofern dies nicht angegeben ist) und sind nur zur Verwendung in Verbindung mit deren Erläuterungen in der folgenden ausführlichen Beschreibung vorgesehen. In den vorstehend genannten Zeichnungen wurden, sofern möglich, gleiche Bezüge und Symbole zur Bezeichnung gleicher oder ähnlicher Teile verwendet. Wenngleich eine Nummerierung eingeführt wurde, um die Bezugnahme auf bestimmte Komponenten in Bezug auf derartige Verweise abzugrenzen, die in verschiedenen Abschnitten dieser Beschreibung vorgenommen werden, sind nicht alle Komponenten in jeder Zeichnung dargestellt oder aufgezählt, um eine Verunklarung der vorgeschlagenen Erfindung zu vermeiden.
Es wird nun gebeten, die folgende ausführliche Beschreibung zu beachten, die eine bevorzugte Ausführungsform der vorliegenden Erfindung und derartige andern Arten schildert, wie Prinzipien der Erfindung angewendet werden können, ohne sich vom Wesen der hier beanspruchten Erfindung zu entfernen.
Ausführliche Beschreibung
Grundsätzlich besteht der allgemeine Zweck der vorliegenden Erfindung darin, Behinderungen und Mängel bekannter Systeme, die den Stand der Technik umfassen, zu bewerten und neue Systeme zu entwickeln, die alle verfügbaren Vorteile und keinen der Nachteile des Standes der Technik beinhalten. Unter konkreter Bezugnahme auf die Zeichnungen im Detail sei nun betont, dass die dargestellten Einzelheiten als Beispiele und lediglich zur Erörterung der bevorzugten Ausführungsformen der vorliegenden Erfindung dienen und dass sie aus dem Grund vorgebracht werden, die als die vermeintlich nützlichste und am leichtesten verständliche Beschreibung der Prinzipien und konzeptionellen Aspekte der Erfindung bereitzustellen. In dieser Hinsicht wird nicht versucht, strukturelle Details der Erfindung ausführlicher darzustellen, als dies für ein grundlegendes Verständnis der Erfindung erforderlich ist. Die mit den Zeichnungen vorgenommene Beschreibung verdeutlicht dem Fachmann, wie die verschiedenen Formen der Erfindung in der Praxis ausgeführt werden können.
Dementsprechend betreffen die Offenbarungen hierin ein hardwareunabhängiges Verfahren zur Gewährleistung der Sicherheit von Secure Elements in IdD-Umgebungen, insbesondere durch das Vergleichen tatsächlicher und vorhergesagter Stromverbrauchsprofile/-muster der genannten Secure Elements, wie im Falle von chipintern ausgeführten Applets. Jedwede Bestimmung von nicht übereinstimmenden Profilen/Werten in einem derartigen Vergleich wird als potenzielle Beeinträchtigung der Sicherheit des genannten Secure Elements aufgrund von Ereignissen einschließlich von Stromverlust identifiziert und kann entweder in einer Ausführungsform nur gemeldet werden/eine Rückmeldung darstellen, während in anderen Ausführungsformen ein Kartenblock (dauerhaft oder vorübergehend) ausgelöst wird.
Unter Bezugnahme auf die beigefügte 1 ist ersichtlich, dass die Implementierung der vorliegenden Erfindung in Schritt (01) bei vorausgesetztem Vorhandensein einer Profilerstellungsanwendung auf dem Secure Element beginnt. Alternativ dazu kann die genannte Profilerstellungsanwendung mittels eines Vorinstallationsschritts (02) oder eines Installationsschritts (03), der zur Laufzeit ausgeführt wird, innerhalb des genannten Secure Elements bereitgestellt werden. Dementsprechend wird die Profilerstellungsanwendung entweder im Rahmen/während des Herstellungsprozesses des genannten Secure Elements installiert, falls das genannte Secure Element zur Verwendung in Verbindung mit dem MG frisch ausgegeben wird, oder sonst als drahtlose Aktualisierung von dem Server des Mobilfunknetzbetreibers, falls die genannte Profilerstellungsanwendung zuvor in dem MG eingesetzt wurde, um den von dem Remote-Server über das Mobilfunknetz erhältlichen Dienst zu nutzen. Die genannte Profilerstellungsanwendung ist dadurch gekennzeichnet, dass sie eine Reihe von programmierten Befehlen aufweist, den Stromverbrauch eines oder mehrerer Applets, die auf dem Secure Element ausgeführt werden, abzurufen, zu schätzen und zu melden.
Unter weiterer Bezugnahme auf die beigefügte 1 ist ersichtlich, dass die genannte Profilerstellungsanwendung in Schritt (04) den Stromverbrauch eines oder mehrerer Zielapplets schätzt, die auf dem genannten Secure Element ausgeführt werden, sobald ein derartiges Secure Element mit der Profilerstellungsanwendung in einem MG empfangen oder installiert wird. Diese Schätzung basiert auf Vorkenntnissen des Bytecodesatzes auf Anweisungsebene, der dem oder den Applet/s entspricht (Chipstandard, vom Chiphersteller vorgegeben). Es versteht sich, dass die genannte Profilerstellungsanwendung spezielle Handhabungen zum Lesen von Inhalten anderer Applets aufweist, die auf dem genannten Secure Element liegen/ausgeführt werden. Ähnlich einem Flussbild, das mehreren Pfaden folgt, ist die Profilerstellungsanwendung derart programmiert, dass eine Zuordnungstabelle des Stromverbrauchs erstellt wird, die der Ausführung möglicher Anweisungen in dem genannten Zielapplet entspricht.
Gemäß einem anderen Aspekt der vorliegenden Erfindung ist die Auswahl, von welchem Applet ein Profil erstellt und welches verfolgt werden soll, durch den Dienstanbieter konfigurierbar. Die Profilerstellungsanwendung kann bei Bedarf auch von mehreren Applets Profile erstellen und sie verfolgen, indem sie eine entsprechende Vielzahl von Vergleichen und daraus folgende Entscheidungsverläufe einbezieht. Im Idealfall werden zwar nur von frisch installierten Applets Profile erstellt, doch muss dies keine Einschränkung darstellen, und die Profilerstellung/Nachverfolgung zuvor installierter Applets kann mittels der gleichen Implementierung wie vorstehend vorgeschlagen vorgenommen werden.
Unter weiterer Bezugnahme auf die beigefügte 1 ist ersichtlich, dass der tatsächliche Stromverbrauch des oder der Applets, die auf dem Secure Element ausgeführt werden, anschließend in Schritt (05) mittels Messung über dessen Anschlüsse bestimmt wird. Dieser tatsächliche Stromverbrauchswert wird dann in Schritt (06) durch Voraussetzung von Faktoren einschließlich der angenommenen Ausführungshäufigkeit und Ausführungszeit von Anweisungen, die das Applet umfassen, mit dem geschätzten Verbrauch verglichen, um derart in Schritt (07) eine Bestimmung dessen zu erreichen, ob der tatsächliche Stromverbrauch und der geschätzte Verbrauch gleich sind oder nicht. Diese Daten (das Ergebnis der genannten Bestimmung) können in alternativen Ausführungsformen hiervon entweder intern in der Speichereinheit des Secure Elements gespeichert oder mittels sicherer drahtloser Kommunikation an einen Remote-Server gesendet werden. Der Remote-Server ist im Idealfall der Mobilfunknetzbetreiber, dem das Secure Element tatsächlich gehört. Es versteht sich ferner, dass Parameter zum Vergleich des Stromverbrauchs implementierungsspezifisch sind und je nach Verwendung variieren können. Unabhängig von dem in 1 beschriebenen Beispiel kann der geschätzte Stromverbrauch aus einem der Folgenden abgeleitet werden: einem Applet von einem anderen Applet-Anbieters als einem Anbieter des Applets, für das der tatsächliche Stromverbrauch abgeleitet (gemessen) wird; einem Applet in einer anderen Version als einer Version des Applets, für das der tatsächliche Stromverbrauch abgeleitet (gemessen) wird.
Es wird erwartet, dass bei einem Vergleich unter nicht anomalen Bedingungen der tatsächliche Stromverbrauch und der geschätzte Verbrauch notwendigerweise gleich sein sollten. Daher ist das hierin vorgeschlagene System so programmiert, dass es in Schritt (08) einen inaktiven Zustand annimmt, sollten der tatsächliche Stromverbrauch und der geschätzte Stromverbrauch des Applets gleich sein. Im Falle einer negativen Bestimmung, d. h. wenn der tatsächliche Stromverbrauch nicht mit dem geschätzten Verbrauch des Applets übereinstimmt, ist das System so programmiert, dass es in Schritt (09) bestimmt, ob ein Batterie-/Stromverlust vorliegt oder nicht, insbesondere wenn er die benutzerdefinierten zulässigen Toleranzwerte überschreitet (was dazu beiträgt, die Gewissheit darüber zu erhöhen, dass, wie in Schritt (10) bestimmt wird, endgültig ein Fall eines durch das Applet verursachten anomaler Stromlecks/-verlusts vorliegt). Falls der tatsächliche Stromverbrauch und der geschätzte Verbrauch innerhalb der benutzerdefinierten zulässigen Toleranzwerte voneinander abweichen, wird dieses Ereignis mittels Entscheidungslogik als Schlussfolgerung aus der in Schritt (09) erreichten Bestimmung ausgelegt, wonach keine Batterieentladung/kein Stromverlust vorliegt, was dazu führt, dass das hierin vorgeschlagene System im vorstehend erwähnten Schritt (08) einen inaktiven Zustand angenommen hat. Die Bestimmung eines durch das überwachte Applet verursachten Stromlecks/-verlusts in Schritt (10) kann dann entweder Gegenstand einer bloßen Meldung sein (Protokollbericht über das SE oder drahtlose Nachricht an den Server des Mobilfunknetzbetreibers) oder Gegenmaßnahmen auslösen, wie sie im nachfolgenden Teil dieser Offenbarung beschrieben werden, und dadurch in Schritt (11) die Prozessimplementierung zu Ende bringen. Es versteht sich, dass der Server des Mobilfunknetzbetreibers diesen (und weitere Fälle) dieses Berichts nach Belieben wiederherstellen kann. Es kann auch ein so genanntes Fail-Late-Prinzip angewendet werden, eine verzögerte Warnung, wobei das System nicht sofort das Ausgeben einer Warnung bezüglich der Erkennung eines Stromlecks auslöst, sondern zu einem späteren Zeitpunkt, der innerhalb des Systems programmiert ist.
Gemäß einem anderen Aspekt der vorliegenden Erfindung kann die vorstehend erwähnte Diagnose improvisiert werden, um:

a) Taktzyklen vorherzusagen, was wiederum Leistungszahlen ergibt. Dies folgt der Überlegung, dass jede Anweisung grundsätzlich eine bestimmte feste Zahl von Taktzyklen verbraucht, die vorbekannt ist, da SE-Hersteller sie in ihren Handbüchern dokumentieren. Daher muss im Zuge der Anweisung auf Chipebene ein Profil des Codes erstellt werden.
b) den Anwendungsentwicklern Rückmeldung zu geben, sodass diese ihren Code zur Reduzierung des Energieverbrauchs optimieren, wodurch der Netzbetreiber die Möglichkeit bekommt, Daten an Appletentwickler zurückzuverkaufen. Hier wird der Vergleich zwischen erwarteten und beobachteten Daten zum Stromverbrauch als Werkzeug verwendet, um eine suboptimale Programmierung aufzuspüren.
c) gehackte Anwendungen oder Fehler wie Endlosschleifen zu erkennen und derartige Malware durch Setzen auf eine schwarze Liste aus dem Umlauf zu entfernen sowie Gegenmaßnahmen auszulösen. Dies folgt der Überlegung, dass sich zwar das Applet, von dem ein Profil erstellt wurde, im Feld befindet, in jedweder Abweichung aber ein Sicherheitsangriff durch Hacken des Codes vermutet werden kann. Derart können Korrekturmaßnahmen wie das Blockieren der Karte oder ein Verhindern der Fortführung des Applets implementiert werden. Die Profilerstellungsanwendung kann die Entscheidung wie das Herunterfahren treffen, oder alternativ dazu kann der Server des Mobilfunknetzbetreibers, wenn die Informationen über den Server geteilt werden, auf der Grundlage eines anwendungsfallbasierten Szenarios entscheiden und einen konkreten Befehl für eine oder mehrere zu implementierende Gegenmaßnahmen ausgeben.
d) eine Änderung der Anschlussfähigkeit zu erkennen, etwa der Batterie, der SIM-Karte oder des Anschlusses. Die Änderung wird mit der eindeutigen Kennung erkannt, etwa einer Änderung der IMEI oder einer Änderung der Anschlussfähigkeiten. Es versteht sich, dass die Erkennung von SIM-Änderungen ein Standardverfahren (ICCID) ist, wohingegen eine Batterieänderung nicht auf SIM-Ebene, sondern nur über den Anschluss erkennbar ist.

Die vorliegende Erfindung wurde in die Praxis umgesetzt und hat in von den Erfindern der vorliegenden Erfindung durchgeführten Versuchsläufen im Sinne der im vorhergehenden Abschnitt dieser Beschreibung angegebenen Ziele effizient funktioniert. Dementsprechend identifiziert sich die vorliegende Erfindung durch die folgenden hervorstechenden Merkmale:

a) Mögliche Schätzung des dynamischen Stromverbrauchs auf der Ebene des anweisungsbezogenen Strombedarfs, d. h. höhere Auflösung als bei Verfahren nach dem Stand der Technik.
b) Genauer Vergleich zwischen tatsächlichem und vorhergesagtem Stromverbrauch eines chipintern ausgeführten Applets
c) Genaue Bestimmung von Szenarien, die die Batterie eines MG entladen
d) Keine Anforderung von Applets von Drittanbietern zur Erstellung von Stromverbrauchsprofilen auf dem Secure Element
e) Kein Rauschen aufgrund der Stromverbrauchssignatur des Betriebssystems
f) Mögliche Fernüberwachung und Betätigung von Korrekturmaßnahmen.

Zwar wurden das System und das Verfahren in Bezug auf derzeit als speziell erachtete Aspekte beschrieben, dennoch muss sich die Offenbarung nicht genau auf die offenbarten Aspekte beschränken. Es ist beabsichtigt, verschiedene Modifikationen und ähnliche Anordnungen abzudecken, die in den Geist und den Schutzumfang der Ansprüche fallen, deren Schutzumfang möglichst weit auszulegen ist, um alle derartigen Modifikationen und ähnlichen Strukturen zu erfassen. In der vorliegenden Offenbarung sind die Aspekte der beigefügten Ansprüche einzeln und in ihrer Gesamtheit eingeschlossen.

Claims

Verfahren zum Schützen eines Secure Elements, insbesondere einer Chipkarte, vor der Gefahr eines Stromlecks, das auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen ist, wobei das Verfahren Folgendes umfasst: a) Bereitstellen einer Profilerstellungsanwendung auf dem genannten Secure Element, insbesondere der Chipkarte, wobei die genannte Profilerstellungsanwendung dadurch gekennzeichnet ist, dass sie Folgendes aufweist: i. einen Befehlssatz, der dazu programmiert ist, den Stromverbrauch des mindestens einen Zielapplets abzurufen und zu melden; und ii. Stromverbrauchsdaten, die einen Bytecodesatz auf Anweisungsebene angeben, der dem mindestens einen Zielapplet entspricht, wobei die genannten Daten dazu geeignet sind, mehreren Pfaden zu folgen, um es der Profilerstellungsanwendung derart zu ermöglichen, eine Schätzung des Stromverbrauchs zu ermitteln, der einer möglichen Ausführung von Anweisungen in dem genannten Zielapplet entspricht; b) Aufbauen einer Anwendungsumgebung, in der ein Mobilgerät registriert ist, durch Installieren und alternativ Empfangen des Secure Elements, insbesondere der Chipkarte, worauf die Profilierungsanwendung bereitgestellt ist, um derart einen Dienst zu nutzen, der von einem Remote-Server erhältlich ist, der in der Lage ist, mittels eines Mobilfunknetzes drahtlos mit dem genannten Mobilgerät zu kommunizieren; c) durch Ausführen der Profilerstellungsanwendung: Ermitteln einer Schätzung des Stromverbrauchs, der der Ausführung des Zielapplets entspricht, auf der Grundlage von Stromverbrauchsdaten, die mit der genannten Profilerstellungsanwendung erlangt wurden, und Speichern des Schätzwerts in der Speichereinheit des Secure Elements, insbesondere der Chipkarte, für die weitere Verwendung; d) durch Ausführen der Profilerstellungsanwendung: Ermitteln einer tatsächlichen Bestimmung des Stromverbrauchs, der der Ausführung des Zielapplets entspricht, wobei die genannte Bestimmung durch Messen über Anschlüsse des genannten Secure Elements, insbesondere der Chipkarte, und Speichern des bestimmten Werts in der Speichereinheit des Secure Elements, insbesondere der Chipkarte, für die weitere Verwendung vorgenommen wird; e) Vergleichen der Werte des geschätzten und des tatsächlichen Stromverbrauchs, die bestimmt wurden, um derart mittels Entscheidungslogik zu der Schlussfolgerung zu gelangen: i. dass eine Anomalie, insbesondere ein Stromleck, vorliegt, falls der geschätzte Stromverbrauch geringer ist als der tatsächliche Stromverbrauch; und ii. dass keine Anomalie, insbesondere kein Stromleck, vorliegt, falls der geschätzte Stromverbrauch mit dem tatsächlichen Stromverbrauch übereinstimmt; f) Auslösen einer Reaktion nach dem Erreichen der Schlussfolgerung, um derart das Secure Element, insbesondere die Chipkarte, vor der Gefahr eines Stromlecks zu schützen, das auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen ist.
Verfahren nach Anspruch 1, wobei das mindestens eine Zielapplet, das zur Ausführung auf dem Secure Element, insbesondere der Chipkarte, in der Lage ist, als eines ausgewählt ist, das frisch auf dem Secure Element, insbesondere der Chipkarte, installiert ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das mindestens eine Zielapplet, das zur Ausführung auf dem Secure Element, insbesondere der Chipkarte, in der Lage ist, als eines ausgewählt ist, das bereits zuvor auf dem Secure Element, insbesondere der Chipkarte, installiert war.
Verfahren zum Schützen eines Secure Elements, insbesondere einer Chipkarte, vor der Gefahr eines Stromlecks, das auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen ist, nach einem der vorhergehenden Ansprüche und einem der Ansprüche 2 und 3, wobei die Profilerstellungsanwendung dazu programmiert ist, den Stromverbrauch mehr als eines Applets, das zur Ausführung auf dem Secure Element, insbesondere der Chipkarte, in der Lage ist, abzurufen und zu melden und dabei eine entsprechende Vielzahl von Vergleichen und daraus resultierenden Entscheidungen einzubeziehen, um zu einer Bestimmung dessen zu gelangen, ob ein Stromleck während der Ausführung jedes der genannten mehreren Applets vorliegt oder nicht.
Verfahren zum Schützen eines Secure Elements, insbesondere einer Chipkarte, vor der Gefahr eines Stromlecks, das auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen ist, nach einem der vorhergehenden Ansprüche, wobei die Bestimmung keiner Anomalie, insbesondere keines Stromlecks, falls der geschätzte Stromverbrauch mit dem tatsächlichen Stromverbrauch übereinstimmt, bezeichnet, dass der geschätzte Stromverbrauch und der tatsächliche Stromverbrauch gleich sind.
Verfahren zum Schützen eines Secure Elements, insbesondere einer Chipkarte, vor der Gefahr eines Stromlecks, das auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen ist, nach einem der vorhergehenden Ansprüche, wobei die Bestimmung keiner Anomalie, insbesondere keines Stromlecks, falls der geschätzte Stromverbrauch mit dem tatsächlichen Stromverbrauch übereinstimmt, bezeichnet, dass der geschätzte Stromverbrauch innerhalb benutzerdefinierter Toleranzgrenzen des tatsächlichen Stromverbrauchs liegt.
Verfahren zum Schützen eines Secure Elements, insbesondere einer Chipkarte, vor der Gefahr eines Stromlecks, das auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen ist, nach einem der vorhergehenden Ansprüche, wobei die Schätzung des Stromverbrauchs, der der Ausführung des Zielapplets entspricht, durch die Voraussetzung von Faktoren einschließlich der angenommenen Ausführungshäufigkeit und Ausführungszeit von Anweisungen ermittelt wird, die das genannte mindestens eine Applet umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Profilerstellungsanwendung durch Installation während des Produktionsprozesses der Chipkarte bereitgestellt wird, falls die genannte Chipkarte zur Verwendung in Verbindung mit dem Mobilgerät frisch ausgegeben wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Profilerstellungsanwendung als drahtlose Aktualisierung von dem Server des Mobilfunknetzbetreibers bereitgestellt wird, falls die genannte Profilerstellungsanwendung eine zuvor in dem Mobilgerät eingesetzte Anwendung zum Nutzen des von dem Remote-Server erhältlichen Dienstes mittels des Mobilfunknetzes ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei angenommen wird, dass die anomale Ausführung mindestens eines Zielapplets mindestens auf einen der Fälle Batterieänderung, schlechte Programmierung und Hackerangriff hinweist.
Verfahren nach einem der vorhergehenden Ansprüche und einem der Ansprüche 8 und 9, wobei die Entscheidungslogik mit der Profilerstellungsanwendung selbst bereitgestellt wird, um derart einen autonomen Implementierungsmodus für das genannte Verfahren zum Schützen des Secure Elements, insbesondere der Chipkarte, vor Gefahren, die auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen sind, zu implizieren.
Verfahren nach einem der vorhergehenden Ansprüche und einem der Ansprüche 8 und 9, wobei die Entscheidungslogik mit dem Remote-Server bereitgestellt wird, um derart einen delegierten Implementierungsmodus für das genannte Verfahren zum Schützen des Secure Elements, insbesondere der Chipkarte, vor Gefahren, die auf eine anomale Ausführung mindestens eines darauf befindlichen Zielapplets zurückzuführen sind, zu implizieren, wobei die vorzunehmende Reaktion charakteristischerweise drahtlos von dem Remote-Server an das Mobilgerät kommuniziert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei als die Reaktion mindestens eine der Folgenden gewählt wird: a) kein Ergreifen von Maßnahmen, falls die Schlussfolgerung in der Bestimmung keiner Anomalie besteht; b) Auslösen eines Befehls zum Erstellen eines Berichts zur Speicherung in der internen Speichereinheit des Secure Elements, insbesondere der Chipkarte, falls die Schlussfolgerung in der Bestimmung einer Anomalie besteht; c) Auslösen eines Befehls zum Erstellen eines Berichts zur drahtlosen Übermittlung von dem Secure Element, insbesondere der Chipkarte, an den Remote-Server, falls die Schlussfolgerung in der Bestimmung einer Anomalie besteht; d) Auslösen eines Befehls zum vorübergehenden Blockieren des Secure Elements, insbesondere der Chipkarte, falls die Schlussfolgerung in der Bestimmung einer Anomalie besteht; und e) Auslösen eines Befehls zum dauerhaften Blockieren des Secure Elements, insbesondere der Chipkarte, falls die Schlussfolgerung in der Bestimmung einer Anomalie besteht.