-
Die
vorliegende Erfindung betrifft das Gebiet der Mobilnetze, die auch
Zellularnetze genannt werden. Sie betrifft insbesondere das Sicherheitsmanagement
von Anwendungen, das mit einem Sicherheitsmodul umgesetzt wird,
der einem mobilen Endgerät
der Mobiltelefonie zugeordnet ist.
-
Der
Sicherheitsmodul eines Mobil- oder tragbaren Telefons ist unter
dem Namen einer „SIM-Karte" (Subscriber Identity
Module: Teilnehmer-Identitätsmodul)
bekannt, die das zentrale Sicherheitselement dieser Telefone bildet.
Bei der Fertigung und/oder während
einer Phase der Personalisierung führt der Telefoniebetreiber
eine Nummer ein, die IMSI (International Mobile Subscriber Identity:
Internationale Mobilteilnehmer-ID) genannt wird und dazu dient,
in sicherer und eindeutiger Weise jeden Teilnehmer zu identifizieren,
der an ein Mobilnetz angeschlossen werden möchte. Jedes Mobiltelefon, hiernach
als mobiles Endgerät
bezeichnet, wird physisch durch eine Nummer identifiziert, die in
einem nicht flüchtigen
Speicher des mobilen Endgeräts
gespeichert ist. Diese Nummer, die IMEI (International Mobile Equipment
Identity: Internationale ID für
mobile Endgeräte)
genannt wird, enthält
eine Typen-Identifikation des mobilen Endgeräts und eine Seriennummer, die
dazu dienen, ein gegebenes mobiles Endgerät in Netzen vom Typ eines GSM
(Global System for Mobile Communications: globales System für mobile Kommunikation),
GPRS (General Packet Radio System: allgemeiner paket-orientierter
Funkdienst) oder UMTS (Universal Mobile Telecommunications System:
Universalsystem für
mobile Telekommunikation) eindeutig zu identifizieren. Ausserdem
wird ein mobiles Endgerät
durch eine Softwareversion SVN (Software Version Number: Software-Versionsnummer) gekennzeichnet,
die den Stand der Aktualisierung der Basissoftware anzeigt, die
im mobilen Endgerät installiert
ist. Die Kombination aus Typen-ID und Seriennummer des mobilen Endgeräts und der
Softwareversion (SVN) ergibt eine neue ID, die IMEISV (International
Mobile Equipment Identity and Software Version Number) genannt wird.
Das gleiche Konzept einer Identifizierung wird auch auf WLAN (Wireless
LAN: drahtloses LAN) oder das bidirektionale Kabelfernsehen angewendet.
Die physische Kennung oder ID kann eine MAC-(Media Access Control: Medienzugriffskontrolle)
Adresse sein, die der eindeutigen Adresse entspricht, die die Konfiguration der
Hardware eines Benutzers in einem IP- (Internet Protocol) Netz identifiziert,
während
die Softwareversion durch Protokolle einer höheren Schicht, die auf dem
IP basieren, übermittelt
werden kann.
-
In
den Normen von ETSI (European Telecommunications Standards Institute:
Europärisches Institut
für Telekommunikationsnormen)
wird eine Mobilstation (MS, mobile station) als aus einem mobilen
Endgerät
(ME, mobile equipment) und einem Teilnehmermodul (SIM, subscriber
identity module) zusammengesetzt definiert. Dieser Teilnehmermodul ist
allgemein abnehmbar, d. h. kann entweder ausgebaut oder von einem
mobilen Endgerät
auf ein anderes übertragen
werden.
-
Bei
Inbetriebsetzung eines mobilen Endgeräts oder genauer bei seinem
Anschluss an das Netz eines Betreibers werden zwischen dem mobilen
Endgerät
und dem Verwaltungszentrum des Betreibers, das seine Verwendung
autorisiert oder nicht autorisiert, Informationen ausgetauscht,
die die Identifizierungsdaten umfassen. Heute bietet ein mobiles
Endgerät
seinem Benutzer zusätzlich
zu seiner gewöhnlichen
Funktion des Aufbaus von Telefongesprächen über Zugriff auf ein Mobilnetz
die Nutzung zahlreicher anderer, ergänzender Dienste mit zusätzlichem
Wert wie die Abfrage unterschiedlicher Daten, Telebanking-Operationen,
E-Kommerz, Zugriff
auf Multimedia-Inhalte usw. Diese weiter entwickelten Dienste machen
ein immer höheres
Sicherheitsniveau erforderlich, um die Benutzer vor möglichem
Betrug seitens Dritter zu schützen,
die die Sicherheitslücken auszunutzen
suchen, die in den mobilen Endgeräten auftreten können.
-
Eine
Verifizierung wird daher auf zumindest zwei Ebenen erforderlich,
einerseits auf der Ebene des mobilen Endgeräts selbst and andererseits
auf der Ebene der Softwareanwendungen, die das Funktionieren der
verschiedenen, vom Betreiber oder Dritten angebotenen Dienste ermöglichen.
Diese Anwendungen werden im allgemeinen vom Server eines Anwendungs-Dienstleisters
ferngeladen, was bedingt, dass dieses Fernladen verifiziert werden muss.
Es handelt sich also darum zu garantieren, dass der Teilnehmermodul
Informationen nur an autorisierte Anwendungen liefert, nachdem er
durch den Kontrollserver als ein Modul erkannt worden ist, der mit
dem mobilen Endgerät
funktionieren kann, in das er eingesetzt ist.
-
Der
Teilnehmermodul kann vertrauliche Informationen wie die Nummer eines
Bankkontos oder ein Passwort enthalten. Eine am mobilen Endgerät funktionierende
Anwendung wird die Aufgabe haben, diese persönlichen Daten zu verwenden,
um die erwartete Dienstleistung zu erbringen. Jedoch könnte eine
Anwendung diese persönlichen
Daten für
andere Zwecke als den Dialog mit dem betreffenden Anwendungs-Dienstleister
missbrauchen. Daraus kann dem Eigentümer des Teilnehmermoduls ein
bedeutender Schaden erwachsen.
-
Diese
im mobilen Endgerät
ablaufenden Anwendungen nutzen im Teilnehmermodul verfügbare Ressourcen.
Unter Ressourcen versteht man verschiedenartige Funktionen und Daten,
die für
ein gutes Funktionieren einer Anwendung erforderlich sind. Bestimmte
dieser Ressourcen können
mehreren Anwendungen gemein sein, so insbesondere die mit der Sicherheit
verbundenen Funktionen. So kann der Teilnehmermodul die Funktion
bestimmter Anwendungen blockieren oder ändern, wenn für diese
Anwendungen die Sicherheitsbedingungen, die durch den Betreiber
und/oder die Anwendungs-Dienstleister aufgestellt worden sind, in
dem fraglichen mobilen Endgerät
nicht erfüllt
sind oder wenn die Rechte des Benutzers des mobilen Endgeräts nicht
genügen.
-
Im
Dokument
FR 2 831 362 wird
ein Verfahren gesicherter Transaktionen zwischen einem mit einer
SIM-Karte versehenen Mobiltelefon und einem Anwendungsserver beschrieben.
Dieses Verfahren bezweckt, Rechte zu schützen, die mit der Benutzung
von Anwendungen verbunden sind, die mittels der SIM-Karte vom Server
ferngeladen worden sind.
-
Diesem
Verfahren zufolge wird zuerst durch den gesicherten Austausch öffentlicher
Schlüssel
ein Vertrauens-Link zwischen dem Server und der SIM-Karte aufgebaut,
dann erfolgt der Kauf einer Anwendung durch die Übermittlung einer Anfragedatei vom
mobilen Endgerät
an den Server. Dieser verschlüsselt
die Anwendung ganz oder teilweise und übermittelt an das mobile Endgerät ein Kryptogramm,
das aus dem Verschlüsselungsschlüssel und einem
Befehl besteht und als Ganzes mit einem öffentlichen Schlüssel verschlüsselt ist,
der der SIM-Karte bekannt ist. Bei Empfang durch das mobile Endgerät wird dieses
Kryptogramm entschlüsselt, der
Schlüssel
wird in der SIM-Karte gespeichert. Die Ausführung des Befehls führt zum
Fernladen der durch den Server ganz oder teilweise verschlüsselten
Anwendung in das mobile Endgerät.
Die geladene Anwendung wird durch den in der SIM-Karte gespeicherten
Schlüssel
entschlüsselt
und dann im mobilen Endgerät
installiert.
-
Diesem
Verfahren zufolge sind die Rechte für die Nutzung der Anwendung
im mobilen Endgerät durch
das Vertrauens-Link geschützt,
das anfänglich zwischen
dem Endgerät
und dem Server aufgebaut worden war und der Transaktion vorausging.
Die Rolle des Servers ist hier mehr auf das Management der Rechte
bzw. das DRM (Digital Rights Management: digitale Rechteverwaltung)
der Benutzer einer Anwendung in einem mobilen Endgerät konzentriert. Die
hierunter entwickelte Lösung
zielt eher auf das Management der Risiken (Risk Management) ab,
die bezüglich
einer Anwendung durch den Betreiber, den Anwendungs-Dienstleister
oder den Benutzer berücksichtigt
werden.
-
Das
Ziel der vorliegenden Erfindung besteht darin, ein Verfahren zur
Authentifizierung einer Anwendung bzw. von Anwendungen in einem
mobilen Endgerät
vorzuschlagen, und zwar sowohl bei ihrem Fernladen als auch bei
ihrem Ablauf. Es geht darum, die Risiken zu begrenzen, die damit
zusammenhängen,
dass ein Teilnehmermodul entweder unsachgemäss genutzt wird oder aber mit
Anwendungen, die bestimmte Sicherheitskriterien nicht erfüllen, oder schliesslich
mit mobilen Endgeräten,
die bestimmte, im Voraus aufgestellte Sicherheitskriterien nicht
erfüllen,
genutzt wird.
-
Ein
weiteres Ziel besteht darin, den Benutzer mobiler Endgeräte wie auch
die betroffenen Anwendungs-Dienstleister gegen den Missbrauch zu
schützen,
der sich aus der Nutzung nicht autorisierter Anwendungen ergibt.
-
Diese
Ziele werden durch ein Verfahren zur Authentifizierung zumindest
einer Anwendung erreicht, die in einem Endgerät abläuft, das über ein Netz an einen Kontrollserver
angeschlossen ist, wobei das Endgerät lokal mit einem Sicherheitsmodul verbunden
ist, die Anwendung mittels einer Anwendungs-Ablaufumgebung des Endgeräts geladen und/oder
ausgeführt
wird und Ressourcen nutzt, die im Sicherheitsmodul gespeichert sind,
das Verfahren die folgenden vorausgehenden Schritte umfasst:
- – Empfang
von Daten, die zumindest die Kennung des Endgeräts und die Kennung des Sicherheitsmoduls
umfassen, über
das Netz durch den Kontrollserver,
- – Analyse
und Verifizierung der Daten durch den Kontrollserver,
- – Erzeugung
eines Kryptogramms, das einen Fingerprint der Anwendung, das Endgerät und den Sicherheitsmodul
identifizierende Daten sowie für den
Modul bestimmte Anweisungen umfasst,
- – Übermittlung
des Kryptogramms über
das Netz und das Endgerät
an den Sicherheitsmodul,
- – Verifizierung
der Anwendung durch Vergleich des aus dem empfangenen Kryptogramm
herausgezogenen Fingerprints mit einem durch den Sicherheitsmodul
ermittelten Fingerprint,
und dadurch gekennzeichnet ist,
dass bei der Initialisierung und/oder Aktivierung der Anwendung
der Sicherheitsmodul die aus dem Kryptogramm herausgezogenen Anweisungen
ausführt
und je nach dem Ergebnis der zuvor ausgeführten, auf diese Anwendung
zutreffenden Verifizierung den Zugriff auf bestimmte Ressourcen
des Sicherheitsmoduls freigibt bzw. blockiert.
-
Die
Ressourcen des Sicherheitsmoduls werden gezielt blockiert bzw. freigegeben,
und zwar mit dem Ziel, bestimmte Anwendungen nutzbar oder nicht
nutzbar zu machen. Anwendungen des mobilen Endgeräts werden
nicht direkt blockiert oder freigegeben, sondern indirekt beeinflusst,
was bedeutet, dass die Blockade- oder Freigabewirkung nur dann zutage
tritt, wenn das mobile Endgerät
versucht, diese Anwendungen ablaufen zu lassen.
-
Dieses
Verfahren wird bevorzugt im Mobilnetz angewendet. Folglich ist das
Endgerät
z. B. ein Mobiltelefonie-Endgerät,
und der Sicherheitsmodul ist ein Teilnehmermodul oder eine SIM-Karte.
Diese Gruppe wird an ein Mobilnetz vom Typ eines GSM (Global System
for Mobil Communications), GPRS (General Packet Radio Service),
UMTS (Universal Mobile Telecommunications System) oder sonstigem angeschlossen,
das durch einen Kontrollserver eines Betreibers verwaltet wird.
Softwareanwendungen werden so im mobilen Endgerät installiert und konfiguriert,
dass sie Ressourcen (Daten oder Funktionen) nutzen, die im Teilnehmermodul
vorhanden sind. Sie können
daher in ihrer Gesamtheit nur genutzt werden, wenn die Sicherheitsbedingungen nach
den im Voraus durch den Betreiber und/oder den Anwendungs-Dienstleister
aufgestellten Kriterien erfüllt
sind. Diese Verifizierung der Kriterien obliegt dem Kontrollserver.
Den durch den Kontrollserver übersandten
Anweisungen zufolge obliegt schliesslich die Anwendung dem Sicherheitsmodul, der
den Zugriff auf die Ressourcen, die für das ordnungsgemässe Funktionieren
einer im mobilen Endgerät
installierten Anwendung erforderlich sind, freigeben oder blockieren
kann.
-
Die
Daten dieser Ressourcen können
Informationen wie Kontonummern, Programme (in Gestalt von Code,
der im mobilen Endgerät
installiert werden kann), Ver- und Entschlüsselungsschlüssel, Rechte
des Zugriffs auf Inhalte usw. umfassen.
-
Die
Funktionen dieser Ressourcen können kryptographische
Algorithmen, Verifizierungsprozesse, Prozesse der Erzeugung digitaler
Signaturen, Verschlüsselungsprozesse,
Authentifizierungsprozesse, Datenvalidierungsprozesse, Zugriffskontrollprozesse,
Datensicherungsprozesse, Zahlungsprozesse usw. umfassen.
-
Das
erfindungsgemässe
Verfahren beruht auf der Tatsache, dass einer Anwendung ein Kryptogramm
zugeordnet wird, das die Bedingungen für die Nutzung der Anwendung
in einem an ein Netz angeschlossenen mobilen Endgerät vorgibt.
-
Zum
Unterschied von dem im Dokument
FR 2
831 362 beschriebenen Verfahren ist eine teilweise oder
vollständige
Verschlüsselung
der Anwendung vor dem Fernladen in das mobile Endgerät nicht
erforderlich. Dem Verfahren der Erfindung zufolge dient nämlich die
Verbindung zwischen dem Server und dem Sicherheitsmodul (oder Teilnehmermodul)
dazu, seine Ressourcen optimal zu kontrollieren und über ihre
Inbetriebnahme oder Nichtinbetriebnahme mit Bezug auf die im mobilen
Endgerät
ablaufenden Anwendungen zu entscheiden. Im Verfahren des zitierten
Dokuments erlaubt der vom Server empfangene Befehl eine Kontrolle
der Nutzung der im mobilen Endgerät installierten Anwendung,
während
er im vorliegenden Verfahren die Aktivierung oder Desaktivierung
der Ressourcen des Sicherheitsmoduls erlaubt.
-
Wenn
Ressourcen desaktiviert sind, funktioniert die Anwendung z. B. in
einer „minimalen" Weise und lässt dem
Benutzer nur eine reduzierte Anzahl von Möglichkeiten. In einem Ausführungsbeispiel kann
diese Reduktion den für
den Kauf von Diensten autorisierten Höchstbetrag betreffen, darüber hinaus könnten diese
Dienste nur an einem gegebenen Ort erlangt werden (einem Einkaufszentrum,
einem Stadion, einem Bahnhof oder Flughafen usw.).
-
In
einer ersten Ausführungsform
wird das Kryptogramm während
des Ladens der Anwendung an den Teilnehmermodul übermittelt. In einer zweiten Ausführungsform
sucht sich die Anwendung während
ihrer ersten Nutzung das Kryptogramm auf dem Kontrollserver.
-
Das
erfindungsgemässe
Authentifizierungsverfahren wird auch während des Ablaufs einer Anwendung
im mobilen Endgerät
angewendet, wodurch man sich mit Hilfe des Teilnehmermoduls vergewissern
kann, dass diese Anwendung autorisiert ist, auf bestimmte Ressourcen
(Daten oder Funktionen) zuzugreifen, die im Teilnehmermodul vorhanden
sind. Insbesondere kann der Teilnehmermodul regelmässig während des
Ablaufs der Anwendung das an die Anwendung angehängte Kryptogramm verifizieren.
-
Zum
Beispiel hat das Einsetzen des Teilnehmermoduls eines Benutzers
in ein anderes mobiles Endgerät
Einfluss auf die Funktion bestimmter Anwendungen, ohne aber den
Aufbau klassischer Telefonverbindungen zu verhindern. Diese Barriere
wirkt gewissermassen als ein Filter, das nicht autorisierte mobile
Endgeräte
oder auch Anwendungen aus durch den Betreiber oder einen Anwendungs-Dienstleister als
Partner nicht zugelassenen Quellen ausschliessen soll.
-
Eine
Modifizierung der Anwendung durch Dritte wird ebenfalls durch den
Teilnehmermodul erkannt, der dann ablehnt, bestimmte empfangene
Befehle auszuführen,
was dann eine Blockade oder Ablaufeinschränkungen der Anwendung zur Folge
hat.
-
Der
Kontrollserver spielt also eine wesentliche Rolle, indem er die
Elemente der Vertraulichkeit oder Sicherheit verwaltet, die mit
der Gruppe aus mobilem Endgerät
und Teilnehmermodul verbunden sind. Er interpretiert die Daten,
die vom mobilen Endgerät
an ihn übermittelt
werden, um über
die Ressourcen (Daten oder Funktionen), die im Teilnehmermodul gespeichert
sind, die Nutzung von Anwendungen zu kontrollieren oder zu beschränken.
-
Der
Server, der die ID-Daten eines mobilen Endgeräts und seines Teilnehmermoduls
empfängt, die
die Kennungen IMEISV und IMSI umfassen, entscheidet nach bestimmten
Kriterien, ob eine neue Anweisung an den Teilnehmermodul geschickt
werden muss, um ein neues Schutzprofil zu definieren, das die Ressourcen
des Teilnehmermoduls vorgibt, die durch die im mobilen Endgerät ablaufenden
Anwendungen genutzt werden dürfen.
Die Kriterien können
zum Beispiel mit der Aktualisierung der im mobilen Endgerät installierten
Softwareversion, mit der Fernladung neuer Anwendungen in das mobile Endgerät, mit der
Aktualisierungsperiode des Schutzprofils, mit der Anzahl von Netzanschlüssen, mit
der für
den Zugriff aufs Netz verwendeten Technologie, mit der Identität des benutzten
Zugriffsnetzes verbunden sein. Sie sind ferner mit unterschiedlichen
Risiken verbunden, die der benutzten Hard- oder Software anhaften
und die der Betreiber und/oder der Anwendungs-Dienstleister und/oder
der Benutzer des mobilen Endgeräts
berücksichtigen möchten.
-
Die
Verifizierung des Kryptogramms kann während des ersten Starts oder
während
der ersten Nutzung einer Anwendung oder bei jedem Start der Anwendung
erfolgen. Einer Variante zufolge kann sie periodisch in einem Rhythmus
erfolgen, der durch die vom Kontrollserver kommenden Anweisungen
vorgegeben wird.
-
Beim
Laden einer Anwendung in ein mobiles Endgerät umfasst das die Anwendung
begleitende, angehängte
Kryptogramm allgemein einen Fingerprint der Anwendung selbst, d.
h. einen Datenblock, der mit Hilfe einer nur in einer Richtung wirkenden, mathematischen
Hash-Funktion aus dem Code der Anwendung berechnet wird.
-
Während der
Teilnehmermodul die Gültigkeit des
Kryptogramms verifiziert, identifiziert er zugleich indirekt das
mobile Endgerät
und vergewissert sich, dass die Daten tatsächlich vom Kontrollserver kommen.
In anderen Worten vergewissert durch dieses Kryptogramm der Kontrollserver
implizit den Teilnehmermodul, dass der Typ und die Version der Software
des mobilen Endgeräts
berücksichtigt
worden sind, dass das Laden der Anwendung kontrolliert worden ist
und dass die Anwendung authentisch ist. Im Voraus empfangenen Anweisungen
zufolge kann der Teilnehmermodul über die Autorisierung oder
Ablehnung von Forderungen oder Befehlen entscheiden, die von der
Anwendung kommen.
-
Das
mobile Endgerät
wirkt in diesem Schritt der Verifizierung als eine Schaltstelle,
die einen fast direkten Dialog zwischen dem Teilnehmermodul und dem
Kontrollserver aufbaut. Somit wird die Sicherheit der zwischen dem
Kontrollserver und dem Teilnehmermodul über die Ablaufumgebung der
Anwendungen des mobilen Endgeräts
ausgetauschten Nachrichten von A bis Z gewährleistet. Das Endgerät kann daher
die Daten gegenüber
dem Teilnehmermodul nicht „schieben" oder umwandeln.
-
Die
vorliegende Erfindung betrifft ebenfalls einen Sicherheitsmodul
mit Ressourcen, die dazu bestimmt sind, lokalen Zugriff von zumindest
einer Anwendung zu erfahren, die in einem an ein Netz angeschlossenen
Endgerät
installiert ist, wobei das Endgerät Mittel für das Auslesen und Übermitteln
von Daten umfasst, die zumindest die Kennung des Endgeräts und die
Kennung des Sicherheitsmoduls beinhalten, wobei dieser Modul dadurch
gekennzeichnet ist, dass er Mittel für den Empfang, die Speicherung und
die Analyse eines Kryptogramms umfasst, das unter anderen Daten
einen Fingerprint der gegebenen Anwendung sowie Anweisungen enthält, wobei die
Mittel zur Verifizierung der Anwendung und die Mittel zur Extraktion
und Ausführung
der Anweisungen, die im Kryptogramm enthalten sind, je nach dem Ergebnis
der Verifizierung der Anwendung bestimmte Ressourcen freigeben oder
blockieren.
-
Dieser
Sicherheitsmodul wird zum Beispiel als Teilnehmermodul oder SIM-Karte
verwendet, die mit einem mobilen Endgerät verbunden sind.
-
Die
Erfindung wird sich besser dank der eingehenden Beschreibung verstehen
lassen, die folgt und die auf die beigefügten Figuren Bezug nimmt, die als
keineswegs einschränkendes
Beispiel gegeben werden, nämlich:
-
1a veranschaulicht
ein Blockschema, das den Prozess der Installierung einer Anwendung gemäss einer
ersten Ausführungsform
zeigt, wo das Kryptogramm über
die Ablaufumgebung der Anwendungen geliefert wird.
-
1b veranschaulicht
den Prozess der Verifizierung des Kryptogramms gemäss der Ausführungsform
von 1a.
-
1c veranschaulicht
den Prozess des Ablaufs der Anwendung unter Nutzung der Ressourcen des
Teilnehmermoduls gemäss
der Ausführungsform von 1a.
-
2a veranschaulicht
ein Blockschema, das den Prozess der Installierung einer Anwendung gemäss einer
zweiten Ausführungsform
zeigt, wo nur die Anwendung ferngeladen wird.
-
2b veranschaulicht
den Prozess der Verifizierung gemäss der Ausführungsform von 2a, wo
die Anwendung ein Kryptogramm vom Kontrollserver abruft.
-
2c veranschaulicht
den Prozess des Ablaufs der Anwendung unter Nutzung der Ressourcen des
Teilnehmermoduls gemäss
der Ausführungsform von 2a.
-
3a veranschaulicht
ein Blockschema, das den Prozess der Installierung einer Anwendung gemäss einer
dritten Ausführungsform
zeigt, wo nur die Anwendung ferngeladen wird.
-
3b veranschaulicht
den Prozess der Verifizierung gemäss der Ausführungsform von 3a, wo
die Anwendung ein Kryptogramm und einen Fingerprint der Anwendung
vom Kontrollserver abruft.
-
3c veranschaulicht
den Prozess des Ablaufs der Anwendung unter Nutzung der Ressourcen des
Teilnehmermoduls gemäss
der Ausführungsform von 3a.
-
4 veranschaulicht
den Aufbau eines Beispiel-Kryptogramms.
-
Die
Blockschemata der 1a, 1b, 1c, 2a, 2b, 2c, 3a, 3b und 3c zeigen
eine Gruppe aus mobilem Endgerät
(CB) und Teilnehmermodul (SIM) mit Ressourcen (RES), die über ein
Mobilnetz (NET) mit einem Kontrollserver (CSE) verbunden ist, der
durch einen Betreiber verwaltet wird. Dieser Server (CSE) ist mit
einem oder mehreren Anwendungs-Dienstleistern (FA) verbunden.
-
Das
mobile Endgerät
(CB) enthält
eine oder mehrere Softwareanwendungen (APP), die in einer Ablaufumgebung
(AEE) funktionieren. Diese Anwendungen (APP) kommen entweder vom
Anwendungs-Dienstleister (FA), der mit dem Kontrollserver (CSE)
des Betreibers assoziiert ist, oder sie können original durch den Hersteller
des mobilen Endgeräts (CB)
programmiert worden sein. In letzterem Falle ist es manchmal erforderlich,
Aktualisierungen fernzuladen, die ebenfalls durch den Teilnehmermodul
(SIM) verifiziert werden.
-
Der
in den 1a, 1b und 1c veranschaulichten
ersten Ausführungsform
zufolge wird das Kryptogramm (CRY) einer Anwendung (APP) beim Prozess
der Installierung der Anwendung (APP) über die Ablaufumgebung der
Anwendungen (AEE) an den Teilnehmermodul (SIM) geliefert.
-
1a veranschaulicht
den Prozess der Installierung, wo das mobile Endgerät (CB) zuerst
Daten übermittelt,
die der Identifizierung (ID) des Teilnehmermoduls (SIM) dienen und
die der Kontrollserver (CSE) verifiziert. Diese Identifizierung
(ID) erfolgt auf Grund der Kennung (IMSI) des Teilnehmermoduls (SIM)
und der eindeutigen Kennung (IMEISV) des mobilen Endgeräts (CB).
Eine Anwendung (APP) wird dann zusammen mit einem Kryptogramm (CRY),
das zur Verifizierung über
die Ablaufumgebung (AEE) zum Teilnehmermodul (SIM) geschickt wird,
vom Server (CSE) aus ferngeladen, wie in 1b veranschaulicht.
-
Es
sei bemerkt, dass der Dienstleister (FA) durch den Betreiber als
vertrauenswürdig
betrachtet wird, was heisst, dass die Anwendungen (APP) homologisiert
sind und funktionieren, ohne dem Benutzer und/oder Betreiber irgendwelchen
Schaden zu verursachen.
-
Das
erfindungsgemässe
Verfahren lässt
sich auf mehrere Formen von Anwendungen (APP) anwenden, die in unterschiedlichen
Typen von Ablaufumgebungen (AEE) ablaufen. Zum Beispiel besitzen zahlreiche
Mobiltelefone aus Java-Anwendungen hervorgegangene Funktionen, die über eine
virtuelle Java-Maschine
(VM) ablaufen, die als Prozessor und Umgebung dient. Die nachfolgende
Beschreibung gründet
sich auf das Beispiel von Java-Anwendungen. Es versteht sich, dass
andere Umgebungen oder Betriebssysteme wie Symbian OS, Windows, Palm
OS, Linux usw. als Anwendungssupport benutzt werden können.
-
Bei
seinem Ablauf, siehe 1c, beansprucht eine Java-Anwendung
den Teilnehmermodul (SIM), sie informiert die Ablaufumgebung (AEE)
davon, indem sie Anforderungen oder Befehle (CMD) an sie richtet.
Die Ablaufumgebung (AEE) berechnet den Fingerprint (FIN2) der Anwendung
(APP) und schickt ihn an den Teilnehmermodul (SIM). Das Kryptogramm
(CRY), das durch den Kontrollserver (CSE) erzeugt und dann zusammen
mit der Anwendung (APP) (oder separat) in das mobile Endgerät (CB) geladen
worden ist, wird im Teilnehmermodul (SIM) gespeichert. Dieser prüft zuerst,
ob er tatsächlich
die nötigen
Daten besitzt, die es ihm gestatten zu entscheiden, ob er auf Anforderungen
oder Befehle (CMD) der Anwendung (APP) antworten soll. Diese Daten,
die als Rechte wirken, die beim Laden der Anwendung (APP) durch
den Kontrollserver (CSE) geladen worden sind, ermöglichen
eine Kontrolle des Funktionierens der Anwendung (APP). Falls diese Rechte
nicht vorliegen, kann die Anwendung (APP) die Ressourcen (RES) (Daten
oder Funktionen) des Teilnehmermoduls (SIM) nicht nutzen.
-
Falls
diese Rechte vorliegen, verifiziert der Teilnehmermodul (SIM) den
Fingerprint (FIN1), der aus dem gespeicherten Kryptogramm (CRY)
hervorgegangen ist, indem er ihn mit dem Fingerprint (FIN2) vergleicht,
der mit der Anwendung (APP) assoziiert und durch die Anwendungsumgebung
(AEE) geliefert worden ist. Dieses Kryptogramm (CRY) kann aus einem
Block bestehen, der mit einem privaten Schlüssel vom RSA-Typ (Rivest, Shamir,
Adelman) verschlüsselt
worden ist. Dieser in 4 dargestellte Block enthält unter
anderen Daten z. B. die Kennung IMSI (ID_SIM) des Teilnehmermoduls
(SIM), die Kennung IMEISV (ID_CB) des mobilen Endgeräts (CB), eine
Kennung (ID_APP) der Anwendung, den Fingerprint (FIN1) der Anwendung
(APP), SIM-Kennungen (RES_ID) der Ressourcen (RES) und Anweisungen (INS_RES)
für die
Blockade bzw. Freigabe der SIM-Ressourcen. Dieser private Schlüssel ist
nur dem Kontrollserver (CSE) bekannt, während sein öffentlicher Teil dem Teilnehmermodul
(SIM) bekannt ist. Der Vorteil einer Benutzung asymmetrischer Schlüssel besteht
darin, dass der Schlüssel,
der dazu dient, Kryptogramme zu erzeugen, ausserhalb des Kontrollservers
(CSE) nicht vorhanden ist.
-
Es
versteht sich, dass andere Algorithmen mit asymmetrischen Schlüsseln, z.
B. DSA (Digital Signature Algorithm) und ECC (Elliptic Curve Cryptography)
Alternativen zu RSA darstellen können.
-
Aus
Gründen
der Einfachheit, der raschen Verifizierungen oder der geringeren
Herstellungs- und Umsetzungskosten kann die Verwendung von Algorithmen
mit symmetrischen Schlüsseln
bevorzugt werden. In diesem Fall ist der Schlüssel dem Server (CSE) und dem
Teilnehmermodul (SIM) bekannt; zum Beispiel könnte ein Algorithmus IDEA (International
Data Encryption Algorithm) verwendet werden, um den Block (IMSI,
IMEISV, Kennung der Anwendung, Fingerprint der Anwendung, Kennungen
der SIM-Ressourcen, Anweisungen für eine Blockade bzw. Freigabe
der SIM-Ressourcen) zu signieren. Als eine Alternative zum IDEA-Algorithmus
können
auch Algorithmen wie z. B. TDES (Triple Data Encryption Standard)
und AES (Advanced Encryption Standard) verwendet werden.
-
In
diesen beiden Varianten mit asymmetrischen und symmetrischen Schlüsseln überprüft der Teilnehmermodul
(SIM) die Übereinstimmung
der verschiedenen Felder, die im Kryptogramm (CRY) erscheinen, und
kontrolliert insbesondere die Kennungen der Anwendungen (ID_APP)
und die Fingerprints der Anwendungen (FIN1), die autorisiert oder nicht
autorisiert sind, seine Ressourcen (RES) (Daten oder Funktionen)
zu benutzen.
-
In
einer Variante kann das Kryptogramm (CRY) einen Zähler enthalten,
der dazu dient zu verhindern, dass das gleiche, an den Teilnehmermodul (SIM)
gerichtete Kryptogramm doppelt benutzt wird (replay attack, Replay-Angriff).
Zwei Anwendungen des gleichen Typs können tatsächlich die gleiche ID tragen
und den gleichen Fingerprint (FIN1) besitzen. In diesem Fall kontrolliert
der Teilnehmermodul (SIM) dann auch den Wert dieses Zählers im
Vergleich zu dem eines Bezugszählers,
der gespeichert und regelmässig
aktualisiert wird.
-
Eine
Variante zum Zähler
besteht darin, eine Zufallszahl zu benutzen, die durch den Teilnehmermodul
(SIM) erzeugt wird. Diese Zufallszahl wird zusammen mit den an den
Kontrollserver (CSE) geschickten Daten übermittelt. Dieser schickt
diese Zufallszahl in der Antwortnachricht zurück, und der Teilnehmermodul
(SIM) kann überprüfen, dass
es sich wirklich um eine neue Nachricht handelt. Um jede Gefahr der
Verwendung eines alten Kryptogramms (CRY) zu vermeiden, umfasst
letzteres allgemeiner eine Variable, die durch den Teilnehmermodul
(SIM) vorhersagbar ist, nämlich
einen Zähler
oder eine Zufallszahl.
-
In
einer weiteren Variante kann das mit Hilfe eines Schlüssels vom
Typ RSA oder IDEA erzeugte Kryptogramm (CRY) durch einen Block ersetzt
werden, der ausgehend von der Gruppe (IMSI, IMEISV, Kennung der
Anwendung, Fingerprint der Anwendung, Kennungen der SIM-Ressourcen,
Anweisungen für
Blockade bzw. Freigabe der SIM-Ressourcen) mit einem gemeinsam genutzten
Schlüssel HMAC
(Keyed-Hashing for Message Authentication) erzeugt wird. HMAC ist
ein Mechanismus für
die Authentifizierung von Nachrichten unter Benutzung von kryptographischen
Hash-Funktionen wie MD5 (Message Digest) oder SHA-1 (Secure Hash
Algorithm) in Kombination mit einem gemeinsam genutzten Schlüssel.
-
Dieser
Schlüssel,
der zugleich im Kontrollserver (CSE) und im Teilnehmermodul (SIM)
vorliegt, kann während
der Personalisierung des Teilnehmermoduls (SIM) oder während der
Installierung bestimmter Ressourcen (RES) im Teilnehmermodul (SIM)
geladen werden. Je nach den Optionen kann jeder Ressource (RES)
oder Gruppe von Ressourcen des Teilnehmermoduls (SIM) ein anderer
Schlüssel
beigeordnet werden oder aber kann der Schlüssel dem ganzen Satz von Ressourcen
(RES) gemein, aber für
einen gegebenen Teilnehmermodul (SIM) einzigartig sein.
-
Durch
das Kryptogramm (CRY) wird es somit dem Teilnehmermodul (SIM) möglich gemacht,
die Ressource oder Ressourcen (RES) zu kennen, die für das entsprechende
mobile Endgerät
(CB) im Teilnehmermodul (SIM) freigegeben oder blockiert werden
können.
-
Die
beiden verwendeten Fingerprints (FIN1 bzw. FIN2) sind bestimmende
Elemente, da sie ein Mittel für
eine kryptographische Kontrolle der Anwendung (APP) durch das mobile
Endgerät
(CB) und durch den Teilnehmermodul (SIM) darstellen. Eine solche
Kontrolle ist erforderlich, um zu verhindern, dass sich eine Drittanwendung
mit einem gegebenen Kryptogramm (CRY) identifiziert. Wenn nämlich das Kryptogramm
A die Anwendung A beim Teilnehmermodul A in einem mobilen Endgerät A authentifiziert, muss
vermieden werden, dass sich eine andere Anwendung B ungerechtfertigt
mit dem gleichen Kryptogramm A beim Teilnehmermodul A im mobilen
Endgerät
A authentifiziert.
-
Einer
Variante gemäss
bleibt der Fingerprint (FIN1) der Anwendung, der im Kryptogramm
(CY) enthalten ist, zwischen dem Kontrollserver (CSE) und dem Teilnehmermodul
(SIM) von Anfang bis Ende vertraulich. Um dies zu tun, wird der
Fingerprint (FIN1) durch den Kontrollserver (CSE) verschlüsselt und
durch den Teilnehmermodul (SIM) entschlüsselt. Ausserdem kann die Anwendung
(APP) für
ein gegebenes Laden so personalisiert werden, dass der im Kryptogramm
(CRY) enthaltene Fingerprint (FIN1) und der Fingerprint (FIN2) der
Anwendung (APP), der durch die Ablaufumgebung (AEE) berechnet wurde,
identisch bleiben, aber von der Identität des mobilen Endgeräts (CB)
abhängen.
Eine solche Massnahme ist erforderlich, wenn man zu verhindern wünscht, dass
sich eine Drittanwendung mit einem gegebenen Fingerprint in einer
anderen Anwendungs-Ablaufumgebung (AEE) authentifiziert, deren Schnittstelle
mit dem Teilnehmermodul (SIM) dann gefährdet wäre. Wenn nämlich der Fingerprint A die Anwendung
A beim Teilnehmermodul A in einem mobilen Endgerät A authentifiziert, muss vermieden werden,
dass sich eine andere Anwendung B ungerechtfertigt mit dem gleichen
Fingerprint A beim Teilnehmermodul B im mobilen Endgerät B authentifiziert.
-
Einer
weiteren Variante zufolge wird jede Anwendung (vom Java-Typ) von
zwei Kryptogrammen begleitet, einem Java-Kryptogramm für die virtuelle Maschine
(VM) und einem Kryptogramm (CRY) für den Teilnehmermodul (SIM).
Diese beiden Kryptogramme umfassen u. a. den gleichen Anwendungs-Fingerprint
(hier FIN2 genannt), der derjenige des Java-Anwendungscodes ist.
Während
der Teilnehmermodul (SIM) das Kryptogramm (CRY) einer Anwendung überprüfen muss,
erwartet er somit den mit der fraglichen Anwendung (APP) assoziierten Fingerprint
(FIN2) von der virtuellen Maschine (VM), den diese notwendigerweise
vorher berechnet hat. Der Fingerprint der Anwendung wird durch das
mobile Endgerät
(CB) an den Teilnehmermodul (SIM) übermittelt. Dieser Fingerprint
kommt nicht vom Kontrollserver, sondern wird nach Fernladen der
Anwendung (APP) durch die Anwendungs-Ablaufumgebung (AEE) des mobilen
Endgeräts
(CB) berechnet. Hingegen übermittelt
das mobile Endgerät
(CB) das im Voraus zusätzlich
zur Anwendung vom Kontrollserver geladene Kryptogramm (CRY) an den Teilnehmermodul.
Dieser kann somit durch Vergleich den empfangenen Fingerprint überprüfen. Das
mobile Endgerät
(CB) kann nicht mogeln, insofern es den vom Teilnehmermodul (SIM)
erwarteten Fingerprint nicht kennt; gegebenenfalls müsste dann
die Funktion für
die Berechnung des Fingerprints, gewöhnlich eine Hash-Funktion, reversibel
gemacht werden, oder ein anderer Fingerprint müsste gefunden werden, der das
gleiche Kryptogramm (CRY) liefert, was beinahe unmöglich ist.
-
1b zeigt
den Prozess der Verifizierung des Kryptogramms (CRY), was entweder
regelmässig,
z. B. vor jedem Abruf der betreffenden Anwendung (APP) oder bevorzugt
ein einziges Mal vor ihrer Installierung oder vor ihrer ersten Verwendung
erfolgen kann. Wenn das Kryptogramm (CRY) gültig ist, übermittelt der Teilnehmermodul
(SIM) eine Annahmenachricht (OK) an die Ablaufumgebung (AEE). Die
Anwendung (APP) kann dann ihre Anforderungen oder Befehle (CMD) über die
Ablaufumgebung (AEE) an den Teilnehmermodul (SIM) richten und die Ressourcen
(RES) des Teilnehmermoduls (SIM) nutzen. Letzterer akzeptiert die
Befehle (CMD), indem er über
die Ablaufumgebung (AEE) hinlängliche
Antworten (RSP) an die Anwendung (APP) übermittelt, siehe 1c.
-
Im
Falle eines ungültigen
Kryptogramms (CRY) übermittelt
der Teilnehmermodul (SIM) eine ablehnende Nachricht (NOK) an die
Ablaufumgebung (AEE). In einem solchen Falle kann die Ablaufumgebung
(AEE) entweder den Prozess der Installierung der Anwendung (APP)
annullieren, oder die Anwendung (APP) wird installiert, aber ihre über die
Ablaufumgebung (AEE) an den Teilnehmermodul (SIM) gerichteten Anforderungen
oder Befehle (CMD) bleiben ohne Antwort (RSP), und die Ressourcen
(RES) des Teilnehmermoduls (SIM) können nicht verwendet werden.
-
In
beiden Fällen,
der Annahme und der Ablehnung (OK und NOK), kann die Anwendungs-Ablaufumgebung
(AEE) die Anwort an den Kontrollserver (CSE) weiterleiten. Der Teilnehmermodul
kann somit indirekt eine Bestätigung
(CF) für
den Empfang des Kryptogramms (CRY) an den Kontrollserver (CB) senden
und eine Kontrolle der Operation von Anfang bis Ende erlauben, siehe 1b.
Die Bestätigung (CF)
umfasst zumindest einen Erfolgs- oder Fehlercode für die Operation
sowie einen Zähler,
der dem Schutz gegen Wiederholungsangriffe dient. Diese Nachricht
ermöglicht
es auch dem Kontrollserver (CSE), den dem Teilnehmermodul (SIM)
beigesellten Zähler
aktualisiert zu halten.
-
Der
in den 2a, 2b und 2c veranschaulichten
zweiten Ausführungsform
zufolge wird die Anwendung (APP) allein ferngeladen, d. h. ohne
Kryptogramm (CRY), nachdem das mobile Endgerät (CB) identifiziert (ID) worden
ist, siehe 2a.
-
Im
Prozess der Verifizierung, 2b, verlangt
die Anwendung (APP) bei ihrem Start durch den Benutzer ein Kryptogramm
(CRY), das die Rechte für die
Nutzung von Ressourcen (RES) für
diese Anwendung umfasst. Dieses Kryptogramm (CRY) wird vom Kontrollserver
(CSE) direkt durch die Anwendung (APP) ferngeladen, und die Anwendung übermittelt es über die
Ablaufumgebung (AEE) an den Teilnehmermodul (SIM). Der Teilnehmermodul
(SIM) übermittelt
eine Bestätigung
(CF) für
den Empfang des Kryptogramms (CRY) an den Server (CSE), aber nicht über die
Ablaufumgebung (AEE) wie im Falle der ersten Ausführungsform,
sondern über
die Anwendung (APP). In dieser Ausführungsform wirkt die Ablaufumgebung
(AEE) nur als eine Schaltstelle zwischen der Anwendung (APP) und
dem Teilnehmermodul (SIM).
-
Der
Prozess des Ablaufs der Anwendung (APP) nach Verifizierung des Kryptogramms
(CRY), siehe 2c, läuft in der gleichen Weise wie
in der durch 1c veranschaulichten und weiter
oben beschriebenen ersten Ausführungsform
ab.
-
3a, 3b und 3c zeigen
eine dritte Variante, wo die Anwendung APP nach Identifizierung
(ID) des mobilen Endgeräts
(CB) vom Kontrollserver (CSE) oder von einem Zwischenserver für das Fernladen
von Anwendungen (APP) allein ferngeladen wird, siehe 3a.
Beim Prozess der Verifizierung (3b) lädt die Anwendung
das Kryptogramm (CRY) und den Fingerprint (FIN2) direkt vom Server (CSE)
oder von einem Zwischenserver für
das Fernladen von Anwendungen (APP). In diesem Falle berechnet zum
Unterschied von den beiden vorausgehenden Ausführungsformen die Anwendungsumgebung
(AEE) nicht mehr den Fingerprint (FIN2), der vielmehr von einer
externen Einheit berechnet wird, nämlich entweder durch den Kontrollserver
CSE oder durch einen Zwischenserver für das Fernladen von Anwendungen
(APP).
-
Der
Prozess des Ablaufs der Anwendung (APP) nach Verifizierung des Kryptogramms
(CRY), siehe 3c, läuft in der gleichen Weise wie
in den beiden vorangehenden, durch 1c und 2c veranschaulichten
Ausführungsformen
ab.
-
Diese
dritte Ausführungsform
kann bevorzugt werden, da ihr Vorteil darin besteht, dass sie keinerlei
Modifizierung der Ablaufumgebung (AEE) verlangt, wie sie derzeit
für die
in den Mobiltelefonen installierten Java-Anwendungen definiert ist,
d. h. eine Modifizierung existierender Normen ist nicht erforderlich.
-
Ausserdem
entfällt
der Zwang der ersten Variante, wonach die beiden Kryptogramme den
gleichen Fingerprint verwenden, da die Verifizierung des Kryptogramms
(CRY) und die Installierung der Anwendung völlig unabhängige Prozesse sind.
-
Um
die von den Anwendungen berechneten Fingerprints zu personalisieren,
gibt es die eine Möglichkeit,
dem Anwendungscode vor seinem Laden in das mobile Endgerät ein Datenelement
hinzuzufügen,
das für
jedes mobile Endgerät
ein anderes ist. Somit ist bei Berechnung des Fingerprints durch
die Anwendungsumgebung des mobilen Endgeräts dieser Fingerabdruck einzigartig
und kann keinem anderen mobilen Endgerät dienen. Das Kryptogramm wird natürlich auf
der Grundlage der ursprünglichen
Anwendungsdaten und dieses einzigartigen Datenelements durch den
Kontrollserver berechnet.
-
In
einer Variante der Erfindung kann das mobile Endgerät durch
ein nicht mobiles Endgerät
wie einen Gebührenfernsehdekodierer
oder einen Computer ersetzt werden. Anwendungen können von
einem Server über
ein Telekommunikationsnetz in das Endgerät ferngeladen werden. Ein mit
der Anwendung assoziiertes Kryptogramm wird im Sicherheitsmodul
gespeichert und bei Inbetriebnahme oder bei jedem Start einer Anwendung überprüft. Das
Resultat dieser Überprüfung liefert
die Bedingungen für das
Funktionieren der Anwendung, indem Ressourcen im Sicherheitsmodul
freigegeben oder blockiert werden.