DE602004001704T2

DE602004001704T2 - Kommunikationsgerät und Programm

Info

Publication number: DE602004001704T2
Application number: DE602004001704T
Authority: DE
Inventors: Naoki Naruse; Yuichi Ichikawa; Tatsuro Oi; Nobuyuki Watanabe; Yasunori Hattori; Masato Takeshita; Masakazu Nishida; Mao Asai; Masayuki Tsuda; Atsuki Tomioka; Kazuhiro Yamada; Satoshi Washio; Dai Kamiya; Naoki Yamane; Keiichi Murakami
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2003-03-31
Filing date: 2004-03-30
Publication date: 2007-10-04
Anticipated expiration: 2024-03-31
Also published as: US7558963B2; EP1465383B1; ES2268524T3; CN1272953C; DE602004001704D1; TW200425695A; EP1465383A1; JP2004302973A; US20050005099A1; ATE335344T1; CN1535059A; JP4176533B2; TWI265708B; EP1465383B8

Description

Technisches Gebiet
Die vorliegende Erfindung bezieht sich auf eine Technologie zum Bestimmen der Authentizität von heruntergeladenen Daten.
Stand der Technik
Üblicherweise wird Software über Kommunikationsnetzwerke wie etwa dem Internet auf Kommunikationsvorrichtungen heruntergeladen und wird auf solchen Kommunikationsvorrichtungen verwendet. Jedoch führt ein solches Herunterladen und die Verwendung von Software zu einem Risiko von Daten-Hackangriffen, die zu unautorisierten Zugriffen auf Daten führen können. Falls ein solcher unautorisierter Zugriff erzielt wird, kann bösartige Software auf die Kommunikationsvorrichtung heruntergeladen werden.
Um diesem Problem zu begegnen, sind eine Vielzahl von Technologien zum Bestimmen der Authentizität von heruntergeladener Software entwickelt worden. Beispielsweise ist ein Verfahren vorgeschlagen worden, bei dem vor dem Herunterladen der Software ein Anwender mit einer integrierten Schaltungskarte (die nachfolgend als "IC"-Karte bezeichnet wird) von einem Provider der Software beliefert wird, wobei die IC-Karte einen Hash-Wert enthält, der einem Anwender gestattet, die Software zu authentifizieren. (Man vgl. beispielsweise die Japanische Offenlegungsschrift Nr. 11-205767). Durch dieses Verfahren, wenn ein Anwender eine Kommunikationsvorrichtung anweist, Software herunterzuladen, nachdem die IC-Karte in die Kommunikationsvorrichtung geladen worden ist, lädt die Kommunikationsvorrichtung die Software herunter und berechnet einen Hash-Wert der Software unter Verwendung einer Hash-Funktion. Dann vergleicht die Kommunikationsvorrichtung den berechneten Hash-Wert und den in der IC-Karte gespeicherten Hash-Wert, um so zu bestimmen, ob die Werte zueinander passen und damit, ob die empfangene Software für ein Herunterladen auf die Vorrichtung autorisiert ist.
Relevant für das oben beschriebene Verfahren ist die Popularität mobiler Stationen, die in der Lage sind, Java (Schutzmarke) Applikations-Software (die nachfolgend als 'Java-AP-Software' bezeichnet wird) herunterzuladen und ein in der heruntergeladenen Java-AP-Software enthaltenes Applikationsprogramm auszuführen (das Applikationsprogramm wird nachfolgend als Java-APP bezeichnet werden.
Wenn Java-AP-Software auf eine solche Mobilstation heruntergeladen wird, wird zuerst eine Applikationsbeschreibungsdatei (nachfolgend als ADF bezeichnet) von einer Server-Einrichtung, die im World Wide Web (nachfolgend als 'WWW' bezeichnet) enthalten ist, auf die Mobilstation heruntergelade und dann wird eine Java-Archivdatei (die nachfolgend als 'JAR-Datei' bezeichnet wird), welche ein Java-APP enthält, auf die Mobilstation heruntergeladen.
Es sollte angemerkt werden, dass in dieser Beschreibung der Ausdruck 'Java-AP-Software' sich auf eine Kombination einer ADF- und einer JAR-Datei bezieht. Ein Problem, das Dateien betrifft, die Java-AP-Software zum Herunterladen auf eine Mobilstation umfassen, ist, dass sie einem bösartigen Angriff unterliegen können. Dementsprechend ist es notwendig, vorab die Authentizität von herunterzuladender Software zu bestätigen.
Eine ADF ist eine Datei, die Informationsdaten über eine zugehörige JAR-Datei enthält. Solch eine Information beinhaltet beispielsweise ein Datum, zu dem die JAR-Datei aktualisiert wurde. Um somit Parität aufrechtzuerhalten, wenn die JAR-Datei aktualisiert ist, muss die entsprechende ADF ebenfalls aktualisiert werden. Auf diese Weise ist es durch Sicherstellen einer korrekten Korrespondenz der relevanten JRR-Datei und der ADF möglich, die Authentizität von Java-AP-Software zu bestätigen.
Ein Verfahren, das im Hinblick auf dieses Ziel vorgeschlagen worden ist, ist wie folgt. Zuerst werden eine ADF- und eine JAR-Datei mit einer gültigen Entsprechung in eine einzelne Datei integriert. Dann wird ein Hash-Wert der integrierten Datei berechnet. Der Hash-Wert wird verwendet, um zu bestimmen, ob eine heruntergeladene ADF- und eine JAR-Datei eine gültige Entsprechung aufweisen. Ein zu diesem ähnliches Verfahren wird in dem oben erwähnten Patentdokument (Japanische Offenlegungsschrift Nr. 11-205767) vorgeschlagen.
Ein in einer JAR-Datei enthaltenes Java-APP ist gemeinsam einer Vielzahl von Modifikationen unterworfen, die von einem Provider implementiert werden, um Fehler im Programm zu beseitigen oder es zu aktualisieren. Jedoch wird sich jedes Mal, wenn das Java-APP modifiziert ist, der Hash-Wert der Java-AP-Software ändern. Als Ergebnis wird es für den Provider des Java-APP, nämlich einen Inhalte-Provider (der nachfolgend als 'CP' (Content Provider) bezeichnet wird) notwendig, IC-Karten, die einen neuen Hash-Wert enthalten, an Mobilstationen zu verteilen, in denen das Java-APP modifiziert oder aktualisiert worden ist. Die Bereitstellung und Distribution solcher Karten bei jeder Modifikation und Aktualisierung eines Programms würde jedoch offensichtlich zu unakzeptablen Kosten und logistischen Problemen führen und ist daher unrealistisch.
Die Europäische Patentanmeldung EP 1 289 326 A1 offenbart ein Systemverfahren zum Bestätigen der Authentizität von heruntergeladener Software. Ein Urheber überträgt Software und einen zugewiesenen Hash-Wert der Software an einen Empfänger. Der Empfänger überprüft die Signatur am Hash-Wert durch Entschlüsseln des signierten Hash-Werts unter Verwendung eines öffentlichen Schlüssels des Urhebers. Der Empfänger berechnet auch einen Hash-Wert der empfangenen Software. Schließlich verifiziert der Empfänger, dass der unsignierte Hash-Wert und der berechnete Hash-Wert die Authentizität der Software bestätigen.
Die Europäische Patentanmeldung EP 1 033 652 A2 offenbarte ebenfalls ein System und Verfahren zum Bestätigen der Authentizität von heruntergeladener Software. Ein Server überträgt eine Software und einen signierten Check-Summenwert der Software an ein Endgerät. Das Endgerät überprüft dann die Signatur am Check-Zeichenwert durch Entschlüsseln des signierten Hash-Werts unter Verwendung eines öffentlichen Schlüssels des Servers. Das Endgerät berechnet auch einen Check-Summenwert der empfangenen Software. Das Endgerät verifiziert dann den unsignierten Check-Summenwert und einen kalkulierten Check-Signierwert, um die Authentizität der Software zu bestätigen.
Im Hinblick auf diese Situation zielt die vorliegende Erfindung auf die Bereitstellung eines Mittels zum Bestätigen der Authentizität und der gültigen Entsprechung mehrerer Dateien ab.
Offenbarung der Erfindung
Um das oben beschriebene Problem zu lösen, stellt die vorliegende Erfindung eine Kommunikationsvorrichtung bereit, die umfasst: ein Empfangsmittel zum Empfangen (a) einer ersten Datei, die Daten enthält, die einen gewissen Wert anzeigen, der auf Basis von Daten einer gewissen, in einer anderen Datei enthaltenen Art berechnet wird, und (b) eine zweite Datei, die Daten einer gewissen Art enthält; ein Berechnungsmittel zum Berechnen eines Wertes, der zum Zuweisen der Daten einer gewissen, in der zweiten Datei enthaltenen Art zu einer Einwege-Funktion erhalten wird; ein Vergleichsmittel zum Vergleichen des Wertes, der durch das Berechnungsmittel berechnet wird, und des gewissen Wertes, der von den in der ersten Datei enthaltenen Daten angezeigt wird; und ein Bestimmungsmittel zum Bestimmen der Gültigkeit der Entsprechung der ersten Datei und der zweiten Datei gemäß einem Ergebnis des von dem Vergleichsmittel durchgeführten Vergleichs.
Die vorliegende Erfindung stellt weiterhin ein Programm zum Instruieren eines Computers bereit, um auszuführen: einen Empfangsschritt zum Empfangen von (a) einer ersten Datei, die Daten enthält, die einen gewissen Wert anzeigen, der auf Basis von, in einer anderen Datei enthaltenen Daten einer gewissen Art berechnet wird, und (b) einer zweiten Datei, die Daten einer gewissen Art enthält; einen Berechnungsschritt zum Berechnen eines Wertes, der für das Zuweisen der in der zweiten Datei enthaltenen Daten der gewissen Art zu einer Einwege-Funktion erhalten wird; einen Vergleichsschritt zum Vergleichen des Wertes, der im Berechnungsschritt berechnet wird, und des von der in der ersten Datei enthaltenen Daten angezeigten gewissen Wert; und einen Bestimmungsschritt zum Bestimmen der Validität der Entsprechung der ersten Datei und der zweiten Datei gemäß dem Ergebnis des im Vergleichsschritt durchgeführten Vergleichs.
Gemäß der vorliegenden Erfindung werden in der zweiten Datei enthaltene Daten einer gewissen Art, die vom Empfangsmittel empfangen werden, einer Einwege-Funktion zugewiesen und ein aus der Einwege-Funktion erhaltener Wert wird mit einem Wert verglichen, der von in der ersten Datei enthaltenen Daten angezeigt wird, die auch vom Empfangsmittel empfangen werden. Dann wird die Authentizität einer Kombination der ersten Datei und der zweiten Datei auf Basis eines Ergebnisses des Vergleichs bestimmt. Somit kann gemäß der vorliegenden Erfindung die Gültigkeit der Entsprechung von mehreren Dateien, die sich aufeinander beziehen, wie etwa einer Reihe von Software umfassenden Dateien, bestätigt werden.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm, das Konfigurationen eines Zufuhrsystems gemäß einer Ausführungsform der vorliegenden Erfindung illustriert.
2 ist eine konzeptionelle Zeichnung, die eine typische Datenstruktur einer im System verwendeten ADF illustriert.
3 ist eine Konzeptzeichnung, die eine Datenstruktur der in einer vertrauenswürdigen Servervorrichtung des Systems gespeicherten SDF illustriert.
4 ist Blockdiagramm, das Konfigurationen einer im System enthaltenen Mobilstation illustriert.
5 ist eine Konzeptzeichnung, die eine funktionelle Struktur der Mobilstation illustriert.
6 ist ein Sequenzdiagramm, das Datenflüsse in der Ausführungsform der vorliegenden Erfindung illustriert.
7 ist ein Flussdiagramm, das Verfahren zum Bestimmen der Authentizität von heruntergeladenen, in der Mobilstation ausgeführten Dateien illustriert.
Bester Modus zum Ausführen der Erfindung
In der folgenden Beschreibung wird ein Liefersystem, das durch Implementieren einer Ausführungsform der vorliegenden Erfindung realisiert wird, unter Bezugnahme auf die Zeichnungen erläutert. In den Zeichnungen werden gleiche Elemente durch gleiche Bezugszeichen bezeichnet.
Gemäß dem Liefersystem ist ein Anwender einer Mobilstation in der Lage, die Mobilstation (sicher) anzuweisen, gewünschte Java-AP-Software herunterzuladen, ein in der heruntergeladenen Java-AP-Software enthaltenes Java-APP zu installieren und das Java-APP ablaufen zu lassen.
Java-AP-Software wird auf eine Mobilstation im Liefersystem wie folgt heruntergeladen. Zuerst zeigt die Mobilstation eine einführende Erläuterung der Java-AP-Software für den Anwender an. Wenn der Anwender die Mobilstation anweist, die Java-AP-Software herunterzuladen, empfängt die Mobilstation zuerst eine ADF der Java-AP-Software. Dann empfängt die Mobilstation eine Datei, die eine Sicherheitsbeschreibungsdatei (nachfolgend als 'SDF' bezeichnet) genannt wird, entsprechend der Java-AP-Software. Zuletzt empfängt die Mobilstation eine JAR-Datei der Java-AP-Software. Die SDF-Dateien enthalten Daten, die Verhaltensbeschränkungen anzeigen, die auf entsprechende, in einer Mobilstation existierende Java-APPs anwendbar sind. Somit, wenn eine Mobilstation ein Java-APP laufen lässt, steuert die Mobilstation auf Basis der in der entsprechenden SDF angezeigten Bedingungen das Verhalten einer von dem Java-APP bereitgestellten Applikation.
In dieser Spezifikation bedeutet der Ausdruck 'Applikation' eine Gruppe von Funktionen, die von einer CPU bereitgestellt werden, wenn die CPU ein Programm laufen lässt. In der nachfolgenden Erläuterung, um eine Situation zu beschreiben, bei der eine CPU ein Java-APP laufen lässt, um eine Gruppe von Funktionen bereitzustellen, nämlich eine Java-AP, wird der Ausdruck 'eine Java-AP wird realisiert' verwendet. Eine Applikation, die von einem Java-APP realisiert wird, wird nachfolgend eine Java-AP genannt.
Eine SDF wird vom oben erwähnten Träger bei Abschluss eines Kontraktes, der zwischen dem Träger und einer CP gemacht ist, vorbereitet, welche die Java-AP-Software bereitstellt. Im Liefersystem der vorliegenden Ausführungsform haben einige Java-APPs entsprechende SDFs, aber andere Java-APPs haben keine entsprechenden SDFs. Das Verhalten einer durch ein Java-APP realisierten Java-AP, die eine entsprechende SDF aufweist, ist auf Basis der SDF beschränkt. Solche Java-AP und Java-APP werden in dieser Spezifikation 'vertrauenswürdige Java-AP' und 'vertrauenswürdige Java-APP' genannt, da die Zuverlässigkeit vom Träger gemäß einem zwischen dem Träger und einem CP, der das Java-APP bereitstellt, gemachten Vertrag garantiert wird.
In der nachfolgenden Erläuterung der vorliegenden Ausführungsform kann Java-AP-Software eine Kombination einer ADF, einer SDF und einer JAR-Datei bedeuten, wenn das in der JAR-Datei enthaltende Java-APP ein vertrauenswürdiges Java-APP ist, oder kann eine Kombination einer ADF und einer JAR-Datei bedeuten, wenn das in der JAR-Datei enthaltene Java-APP kein vertrauenswürdiges Java-APP ist. In dieser Spezifikation wird ein Java-APP, das kein vertrauenswürdiges Java-APP ist, ein unvertrautes Java-APP genannt und eine Applikation, die von dem unvertrauten Java-APP realisiert wird, wird ein unvertrautes Java-AP genannt. Auf dieselbe Weise wird in dieser Spezifikation Java-AP-Software, die ein vertrauenswürdiges Java-APP enthält, ein 'vertrauenswürdige Java-AP-Software' genannt, und eine Java-AP, die ein nicht-vertrauenswürdiges Java-APP enthält, wird 'unvertraute Java-AP-Software' genannt.
(1: Konfiguration)
Wie in 1 gezeigt, umfasst das Liefersystem: eine mit dem Internet 11 verbundene CP-Servervorrichtung 12; ein Mobil-Paket-Kommunikationsnetzwerk 15, durch welches der Träger Mobil-Paket-Kommunikationsdienste für Mobilstationen bereitstellt; eine Mobilstation 16, die Datenpakete mit anderen Kommunikationsvorrichtungen über das Mobil-Paket-Kommunikationsnetzwerk 15 austauscht; Gateway-Servervorrichtungen 17, die das Internet 11 und Mobi1-Paket- Kommunikationsnetzwerk 15 verbindet; und eine vertrauenswürdige Servervorrichtung 18, die mit der Gateway-Servervorrichtung 17 verbunden ist. Obwohl in der Praxis das Liefersystem mehrere mobile Stationen umfassen kann, wird aus Gründen der Einfachheit nur eine Mobilstation 16 in 1 gezeigt. Dementsprechend wird nur eine CP-Servervorrichtung 12 in 1 gezeigt.
Im Nachfolgenden werden Details der Komponente des Liefersystems erläutert.
(1:1: CP-Servervorrichtung)
Die CP-Servervorrichtung 12 weist Hardware-Komponenten und Merkmale einer allgemeinen WWW-Servervorrichtung auf. Die CP-Servervorrichtung 12 umfasst eine Festplattenvorrichtung 12a. Die CP-Servervorrichtung 12 ist in der Lage, eine dem Übertragungs-Kontrollprotokoll (nachfolgend als 'TCP', Transmission Control Protocol bezeichnet) folgende Verbindung zwischen der CP-Servervorrichtung 12 und einer Kommunikationsvorrichtung zu etablieren. Wenn die CP-Servervorrichtung 12 eine Anforderungsnachricht empfängt, die einer GET-Methode des Hypertext-Transfer-Programmes (nachfolgend als 'HTTP' bezeichnet) unter Verwendung der TCP-Verbindung folgt, liest die CP-Servervorrichtung 12 eine vom Uniform Resource Locator (nachfolgend als 'URL' bezeichnet) identifizierte Datei, die der GET-Methode zugewiesen ist, aus der Festplattenvorrichtung 12a, überträgt eine Antwortnachricht aus HTTP, welche die Datei enthält, an die Kommunikationsvorrichtung und trennt die TCP-Verbindung.
Die Festplattenvorrichtung 12A speichert JAR-Dateien, die in der Java-Programmsprache geschriebene Programme enthalten, und ADFs, die Daten enthalten, welche Informationen über ihre entsprechenden JAR-Dateien anzeigen.
In der CP-Servervorrichtung 12 gespeicherte ADFs werden in ADFs, die vertrauenswürdigen Java-APPs entsprechen und ADFs, die nicht-vertrauenswürdigen Java-APPs entsprechen, kategorisiert. Beide Arten von ADFs enthalten Daten, die in einer normalen ADF des Standes der Technik enthalten sind, wie etwa Daten, die einen Namen der Java-AP-Software, eine JAR-Speicher-URL, welche Daten sind, die einen Speicherort einer JAR-Datei im WWW anzeigen, Daten, die eine Größe der JAR-Datei anzeigen, Daten, die ein Datum der letzten Aktualisierung der JAR-Datei anzeigen usw. Jede der ADFs, die vertrauenswürdiger Java-AP-Software entspricht, enthält, wie in 2 gezeigt: Eine vertrauenswürdige APID, die ein Identifizierer ist, der jeder vertrauenswürdigen Java-AP-Software zugewiesen ist; Daten, die eine vertrauenswürdige Server-Domain anzeigen, die einen Speicherort einer entsprechenden SDF im WWW spezifizieren, Zertifikatdaten, die von einer Zertifikat-Einrichtung (nachfolgend als 'CA' bezeichnet) einer CP, die eine CP-Servervorrichtung 12 betreibt, bereitgestellt werden, und einen JAR-Hash-Wert, der einen Hash-Wert einer entsprechenden JAR-Datei anzeigt, zusätzlich zu den oben erwähnten Daten.
Ein Hash-Wert ist ein Wert fester Länge, der als Ausgabe einer Hash-Funktion erhalten wird, wenn willkürliche Daten in die Hash-Funktion eingegeben werden. Eine Hash-Funktion ist ein Beispiel einer Einwege-Funktion. Eine 'Einwege-Funktion' ist eine Funktion in der Form von 'y = f(x)', wobei y rasch kalkuliert wird, wenn x gegeben ist, aber wo es praktisch unmöglich ist, x zu berechnen, wenn y gegeben ist, da die Funktion keine inverse Funktion hat, und es sollte daher einen regellosen Betrag an Zeit erfordern, x zu berechnen.
Die CP-Servervorrichtung 12 hat eine Funktion zum Erzeugen und Aktualisieren von Daten, die in den oben erwähnten Daten enthalten sind, in Übereinstimmung mit Instruktionen der CP. Die Festplattenvorrichtung 12A speichert auch Zertifikatdaten, die von einer CA erteilt werden, und Zertifikate, so dass die CP durch die CA autorisiert ist. Die CP-Servervorrichtung 12 speichert weiterhin ein Programm zum Berechnen von Hash-Werten von JAR-Dateien und Zertifikatdaten gemäß dem sicheren Hash-Algorithmus 1 (nachfolgend als 'SHA-1' bezeichnet).
(1-2: Gateway-Servervorrichtung)
Die Gateway-Servervorrichtung 17 wird vom oben erwähnten Träger verwaltet und hat Hardware-Komponenten und Merkmale einer allgemeinen WWW-Servervorrichtung, welche Vorrichtung Kommunikationsnetzwerke verbindet. Die Gateway-Servervorrichtung 17 verteilt Daten zwischen dem Mobil-Paket-Kommunikationsnetzwerk 15 und dem Internet 11.
(1-3: Vertrauenswürdige Servervorrichtung)
Die vertrauenswürdige Servervorrichtung 18 wird vom oben erwähnten Träger verwaltet und weist Hardware-Komponenten und Merkmale einer allgemeinen WWW-Servervorrichtung auf. Die vertrauenswürdige Servervorrichtung 18 umfasst Festplattenvorrichtung 18A und nach einer Herstellung einer TCP-Verbindung mit einer Kommunikationsvorrichtung, wenn die vertrauenswürdige Servervorrichtung 18 eine Anforderungsnachricht gemäß einem GET-Verfahren aus HTTP unter Verwendung der TCP-Verbindung empfängt, liest die vertrauenswürdige Servervorrichtung 18 eine von einer URL identifizierte Datei, die dem GET-Verfahren zugewiesen ist, aus der Festplattenvorrichtung 18A aus, überträgt eine Antwortnachricht aus HTTP, welche die Datei enthält, an die Kommunikationsvorrichtung und trennt die TCP-Verbindung.
Die Festplattenvorrichtung 18a speichert SDFs, die alle jedem der vertrauenswürdigen Java-APPs entsprechen.
Eine SDF ist eine Datei, die von einem Träger für ein vertrauenswürdiges Java-APP hergestellt wird. Wie in 3 gezeigt, enthält eine SDF: eine JAR-Speicher-URL, die eine URL eines Speicherortes einer JAR-Datei anzeigt, die die vertrauenswürdige Java-AP enthält; ein ADF-Zertifikat-Datenflag, das anzeigt, ob eine entsprechende ADF Zertifikat-Daten enthält; einen Zertifikat-Hash-Wert, der einen Hash-Wert, berechnet in Übereinstimmung mit den in der ADF enthaltenen Zertifikat-Daten, anzeigt und Gestattungsdaten, die Applikations-Programmier-Schnittstellen (nachfolgend als 'APIs' bezeichnet) oder URLs anzeigt, die eine vom vertrauenswürdigen Java-APP realisierte Java-AP verwenden darf oder auf sie zuzugreifen darf.
Gestattungsdaten beinhalten Gestattungsdaten zum Zugriff auf „persönliche Daten", die anzeigen, ob es für die vertrauenswürdige Java-AP gestattet ist, APIs für den Zugriff auf Telefonverzeichnisdaten, ungelesene E-mail-Daten und ausgehende/eingehende E-mail-Verlaufsdaten zu verwenden, 'Gestattungsdaten für Einstellungsänderungen', was anzeigt, ob es für die vertrauenswürdige Java-AP gestattet ist, APIs zum Ändern der Einstellungen einer Melodie oder eines Bildes zum Notifizieren von E-mail-Eingängen/Übertragungen und eines Bildes für einen Nicht-Bereitmeldungs-Bildschirm zu verwenden, und 'Gestattungsdaten für URLs', die URLs anzeigen, auf die die Java-AP zugreifen darf.
(1-4: Mobilstation)
Wie in 4 gezeigt, umfasst die Mobilstation 16: ein Betriebssystem (OS)-Programm; ein Java-AP-Umgebungsprogramm zum Einrichten einer Umgebung, um Java-APs betreibbar zu machen; ROM 16A zum Speichern verschiedener Arten von Programmen, wie etwa nativer Applikationsprogramme; CPU 16B zum Laufenlassen von im ROM 16A gespeicherten Programmen; Anzeigeeinheit 16C; nicht-flüchtigen Speicher 16D; RAM 16E; Kommunikationseinheit 16F; und Betriebseinheit 16G. Diese Komponenten der Mobilstation 16 sind miteinander mittels eines Datenbusses verbunden.
Die Anzeigeeinheit 16C umfasst beispielsweise einen Flüssigkristall-Anzeigenpaneel und eine Paneel-Treiberschaltung und zeigt aus Daten, die von der CPU 16B bereitgestellt sind, konstruierte Bilder an.
Nicht-flüchtiger Speicher 16D ist beispielsweise ein statischer wahlfreier Zugriffsspeicher (SRAM) oder ein elektrisch löschbarer und programmierbarer Nur-Lese-Speicher (EEPROM). Java-AP-Software, die aus Servervorrichtungen heruntergeladen wird, die im WWW enthalten sind, wird im nicht-flüchtigen Speicher 16D gespeichert. Der nicht-flüchtige Speicher 16D speichert auch ein Programm zum Berechnen von Hash-Werten gemäß SHA-1.
Die Kommunikationseinheit 16F umfasst eine Antenne und eine Drahtlos-Kommunikationseinheit; kommuniziert Drahtlos-Datenpakete mit dem Mobil-Paket-Kommunikationsnetzwerk 15 und verteilt Datenpakete zwischen der CPU 16B und dem Mobil-Paket-Kommunikationsnetzwerk 15. Die Kommunikationseinheit 16F umfasst einen CODEC, ein Mikrofon und einen Lautsprecher für Sprachkommunikation und ermöglicht es der Mobilstation 16, Sprachkommunikation über ein Mobiltelefonnetzwerk (nicht gezeigt) zu führen, das ein Vermittlungssystem aufweist.
Die Betriebseinheit 16G umfasst Hardware wie etwa eine Tastatur, mit der ein Anwender Vorgänge eingeben kann und stellt die CPU 16B mit gewissen Signalen gemäß den von einem Anwender ausgeführten Operationen bereit.
(2. Betrieb)
In der nachfolgenden Beschreibung werden beispielhafte Vorgänge des oben erwähnten Liefersystems erläutert.
Wenn eine Stromversorgung (nicht gezeigt) der Mobilstation 16 eingeschaltet wird, liest die CPU 16B das im ROM 16A gespeicherte OS-Programm und lässt das OS-Programm unter Verwendung von RAM 16E als Arbeitsbereich ablaufen. Gemäß Instruktionen des OS-Programms ist die CPU 16B zum Bereitstellen verschiedener grundlegender Funktionen wie etwa der Steuerung der Benutzerschnittstelle (UI) in der Lage. 5 zeigt eine Struktur eines OS, das in der Mobilstation 16 vom OS-Programm realisiert wird. Das OS spezifiziert Instruktionen, die von dem Anwender auf Basis von aus der Betriebseinheit 16G anhand von Operationen des Anwenders empfangenen Signalen bereitgestellt werden und führt gewisse Prozesse anhand dieser Instruktionen aus.
Wenn beispielsweise der Anwender das Herunterladen von Java-AP-Software anfordert, überträgt ein Web-Browser im OS die Anforderung an einen Java-Applikationsmanager (der nachfolgend als ein 'JAM' bezeichnet wird).
Wenn der Anwender das Laufenlassen eines JAM-Programms anfordert, das ein natives Applikationsprogramm für die Mobilstation 16 ist, startet das OS das JAM-Programm und realisiert einen JAM in der Mobilstation 16. Der JAM zeigt eine Liste von auf der Mobilstation 16 installierten Java-APPs an, und wenn der Anwender eines der gelisteten Java-APPs auswählt, startet der JAM das ausgewählte Java-APP. Konkreter, wenn die Mobilstation 16 vom Anwender eine Anweisung empfängt, ein gewisses Java-APP zu starten, wird das Java-AP-Umgebungsprogramm durch die CPU 16B gestartet und eine Java-AP-Umgebung wird in der Mobilstation 16 etabliert. Dann wird das Java-APP durch die CPU 16B unter Verwendung der Java-AP-Umgebung gestartet und es werden Funktionen einer Java-AP bereitgestellt. Eine Java-AP-Umgebung enthält beispielsweise die K-virtuelle Maschine (KVM) die eine leichtgewichtige Java-virtuelle Maschine ist, vorbereitet für eine Mobilstation, wie etwa die Mobilstation 16 und APIs, die verschiedene Funktionen für Java-APs bereitstellen. APIs, die für Java-APs vorbereitet sind, werden in vertrauenswürdige APIs, die nur vertrauenswürdige Java-APs verwenden dürfen, nachfolgend Gestattungsdaten die in SDFs enthalten sind, und vertrauensunwürdige Java-APIs, die alle Java-APs verwenden dürfen, kategorisiert.
Erläuterungen des Betriebs zum Etablieren und Trennen von TCP-Verbindungen werden in dieser Spezifikation weggelassen, da die Vorgänge den wohlbekannten Verfahren von HTTP folgen. In der nachfolgenden Erläuterung werden Vorgänge, die von der CPU 16B aufgrund von Instruktionen der oben erwähnten Programme ausgeführt werden, wie etwa dem OS-Programm, einem Web-Browser-Programm, einem JAM-Programm, einem Java-APP und einem nativen Applikationsprogramm als „Operationen, die von der Mobilstation 16 ausgeführt werden", beschrieben, um die Beschreibung zu vereinfachen.
(2-1: Vorbereitung vertrauenswürdiger Java-AP-Software)
Nachfolgend werden Vorgänge für die CP-Servervorrichtung 12, die von einem CP verwaltet wird, um ein vertrauenswürdiges Java-APP vorzubereiten, unter Bezugnahme auf 6 erläutert.
Der Träger stellt den CP vorab ein Programm zur Berechnung von Hash-Werten von JAR-Dateien und Zertifizierungsdaten gemäß SHA-1 bereit. Das Programm wird nachfolgend als 'Tool' bezeichnet. Die Festplattenvorrichtung 12A der CP-Servervorrichtung 12 speichert das Tool wie auch die vom CA empfangenen Zertifizierungsdaten.
Der CP bereitet ein Java-APP zum Realisieren einer Java-AP vor, die in der Lage ist, Melodien zum Mitteilen von E-mail-Eingängen in Übereinstimmung mit Telefonnummern von Sendern von E-mails zu ändern. Das Java-APP wird 'Melody by Telno Appli' genannt. Der CP instruiert die CP-Servervorrichtung 12, eine JAR-Datei zu erzeugen, die ein 'Melody by Telno Appli' enthält und die JAR-Datei in einem Speicherort zu speichern, der von einer Speicher-URL 'http://www.b.co.jp/melody.jar' identifiziert wird.
Andererseits gibt der CP in einer ADF beinhaltete Daten, wie etwa Daten, die den Namen des Java-APP 'Melody by Telno Appli' und die JAR-Speicher-URL anzeigen, an der CP-Servervorrichtung 12 ein. Dann instruiert der CP die CP-Servervorrichtung 12, das Tool laufen zu lassen.
Folgend der Instruktion des CP liest die CPU der CP-Servervorrichtung 12 das auf der Festplattenvorrichtung 12A gespeicherte Tool aus und folgende Instruktionen des Tools berechnet einen Hash-Wert der JAR-Datei (was nachfolgend als ein 'JAR-Hash-Wert' bezeichnet wird) und einen Hash-Wert der Zertifikatdaten (was nachfolgend als ein 'Zertifikat-Hash-Wert' bezeichnet wird). Dann erzeugt die CPU der CP-Servervorrichtung 12 eine ADF, die Daten enthält, welche den JAR-Hash-Wert anzeigen, die Zertifikatdaten, die den Namen des Java-APP 'Melody by Telno Appli' anzeigen und Daten, die die JAR-Speicher-URL 'http://www.b.co.jp/melody.jar' anzeigen.
Dann überträgt die CP-Servervorrichtung 12 die ADF und die JAR-Datei zusammen mit dem Zertifikat-Hash-Wert anzeigenden Daten an die vertrauenswürdige Servervorrichtung 18 (Schritt S1).
Wenn der Träger, der die vertrauenswürdige Servervorrichtung 18 verwaltet, die oben erwähnten Dateien und Daten von der CP-Servervorrichtung 12 empfängt, bestimmt der Träger, ob der CP autorisiert ist.
Genauer gesagt, überprüft der Träger, ob die in der ADF enthaltenen Zertifikatdaten von einer CA erteilt wurden, auf die der Träger vertraut, oder ob die Zertifikatdaten von mehreren CAs erteilt sind, mit einer validen Zertifikatkette und die mehreren CAs von einem CA eines höheren Levels verwaltet werden, dem der Träger vertraut.
Nach Abschluss der Authentizitätsprüfung bestimmt der Träger die Authentizität des vom CP bereitgestellten Java-APP. Konkreter inspiziert der Träger Beschreibungen des in der JAR-Datei enthaltenen Java-APP, um zu prüfen, ob die vom Java-APP realisierte Java-AP nicht persönliche Daten, die in der Mobilstation 16 gespeichert sind, zerstört, keine persönlichen Daten an eine externe Vorrichtung auslecken lässt usw.
Nach Inspektion des Programms bestimmt der Träger APIs, die der Java-AP gestattet sind, zu verwenden und URLs, auf welche die Java-AP zugreifen darf, in Übereinstimmung mit einem Ergebnis der Inspektion. Der Träger gibt dann Daten, welche die APIs und URLs anzeigen, an die vertrauenswürdige Servervorrichtung 18 ein.
In Reaktion auf die Eingabe erzeugt die CPU der vertrauenswürdigen Servervorrichtung 18 eine SDF, die der ADF und der JAR-Datei entspricht, die von der CP-Servervorrichtung 12 empfangen worden sind. Die von der CPU erzeugte SDF enthält Daten, welche die JAR-Speicher-URL 'http://www.b.co.jp/melody.jar', die in der ADF enthalten ist, anzeigen, ein ADF-Zertifikat-Datenflag 'JA', Daten, die den von der CP-Servervorrichtung 12 empfangenen Zertifikat-Hash-Wert anzeigen und Gestattungs- bzw. Erlaubnisdaten, welche die vom Träger eingegebene APIs und URLs anzeigen.
Nach Erzeugen der ADF fügt die CPU der vertrauenswürdigen Servervorrichtung 18 Daten, die eine vertrauenswürdige APID '0001' anzeigen, welche das vertrauenswürdige Java-APP identifiziert, und Daten, die eine vertrauenswürdige Serverdomain 'http://www.a.co.jp/melody.sdf' anzeigen, die einen Speicherort der SDF in der vertrauenswürdigen Servervorrichtung 18 identifiziert, hinzu. Dann überträgt die CPU die ADF, welche die oben erwähnten Daten enthält, an die CP-Servervorrichtung 12 (Schritt S2).
Die CPU der CP-Servervorrichtung 12 empfängt die ADF und speichert die ADF auf der Festplattenvorrichtung 12A. Nach Speicherung der ADF in der CP-Servervorrichtung 12 ist die das Java-APP enthaltende JAR-Datei fertig zum Herunterladen auf die Mobilstation 16.
(2-2: Herunterladen von Java-AP-Software auf die Mobilstation 16)
Nachfolgend werden Vorgänge, die im Liefersystem ausgeführt werden, wenn der Anwender die Mobilstation 16 anweist, Java-AP-Software herunterzuladen, unter Bezugnahme auf 6 erläutert.
In der nachfolgenden Erläuterung wird angenommen, dass die ADF und die JAR-Datei der Java-AP-Software, die herunterzuladen ist, nicht modifiziert werden, nachdem die Java-AP-Software vorbereitet ist, wie in Abschnitt 2-1 erläutert.
Der Anwender instruiert die Mobilstation 16, das vertrauenswürdige Java-APP 'Melody by Telno Appli' von der CP-Servervorrichtung 12 auf die Mobilstation 16 unter Verwendung der Betriebseinheit 16G herunterzuladen.
Wenn die CPU 16B die vom Anwender zum Herunterladen der vertrauenswürdigen Java-AP-Software durch den Web-Browser vorgenommene Instruktion empfängt, führt die CPU 16B eine Reihe von Prozessen zum Herunterladen des vertrauenswürdigen Java-APP auf die Mobilstation 16 wie folgt aus.
Als erstes empfängt die CPU 16B die dem Java-APP entsprechende ADF von der CP-Servervorrichtung 12. Konkreter etabliert die CPU 16B eine TCP-Verbindung zur CP-Servervorrichtung 12, erzeugt eine Anforderungsnachricht zur Übertragung der ADF und überträgt die Anforderungsnachricht an die CP-Servervorrichtung 12 (Schritt S3). Die CPU 16B empfängt eine Antwortnachricht, die die ADF enthält, in Reaktion auf die Anforderungsnachricht (Schritt S4) und trennt die TCP-Verbindung. Nach Empfangen der Antwortnachricht speichert die CPU 16B die in der Antwortnachricht enthaltene ADF im nicht-flüchtigen Speicher 16D.
Dann bestimmt die CPU 16B, ob das herunterzuladende Java-APP ein vertrauenswürdiges Java-APP ist. Konkreter überprüft die CPU 16B, ob die ADF Daten enthält, die eine vertrauenswürdige APID anzeigen und wenn die ADF die Daten enthält, stellt die CPU 16B fest, dass das Java-AP ein vertrauenswürdiges Java-APP ist, da die Daten anzeigen, dass es eine SDF entsprechend dem Java-APP gibt. Wenn andererseits die ADF die Daten nicht enthält, stellt die CPU 16B fest, dass das Java-APP ein nicht-vertrauenswürdiges Java-APP ist.
Im Fall, dass das herunterzuladende Java-APP ein nicht-vertrauenswürdiges Java-APP ist, lädt die Mobilstation 16 die JAR-Datei aus der Speicherlokation herunter, die durch die, die JAR-Speicher-URL, die in der ADF enthalten ist, anzeigenden Daten identifiziert ist, folgend denselben Prozeduren wie in einem normalen Liefersystem im Stand der Technik ausgeführt.
Im Beispielfall stellt die CPU 16B, da die ADF Daten enthält, die die vertrauenswürdige APID '0001' anzeigen, fest, dass das Java-APP, das herunterzuladen ist, ein vertrauenswürdiges Java-APP ist. Dementsprechend empfängt die CPU 16B die ADF, die dem Java-APP entspricht, aus der von den Daten, welche die vertrauenswürdige Server-Domain 'http://www.a.co.jp/melody.sdf' anzeigen, identifizierten Speicherlokation. Konkreter etabliert die CPU 16B eine TCP-Verbindung zur vertrauenswürdigen Servervorrichtung 18, erzeugt eine Anforderungsnachricht zum Übertragen der SDF, die durch die vertrauenswürdige Server-Domain 'http://www.a.co.jp/melody.sdf' identifiziert ist, die von den in der ADF enthaltenen Daten angezeigt ist, und überträgt die Anforderungsnachricht unter Verwendung der TCP-Verbindung (Schritt S5). Die CPU 16B empfängt eine Antwortnachricht, welche die SDF enthält, in Reaktion auf die Anforderungsnachricht (Schritt S6) und trennt die TCP-Verbindung.
Nachfolgend wird der Betrieb zur Feststellung der Authentizität der vertrauenswürdigen Java-AP-Software nach Herunterladen der vertrauenswürdigen Java-AP-Software unter Bezugnahme auf 7 erläutert.
Die CPU 16B bestimmt, ob die ADF Zertifikatdaten enthält (Schritt S101). Konkreter überprüft die CPU 16B, ob die ADF ein ADF-Zertifikat-Datenflag enthält, das 'JA' anzeigt. Wenn die CPU 16B feststellt, dass die ADF keine Zertifikatdaten enthält (Schritt S101; Nein), überspringt die CPU 16B die Prozesse zum Inspizieren von Zertifikatdaten und bewegt sich zu Prozessen zum Herunterladen der JAR-Datei (Schritt S104).
Im Beispielfall, da die ADF ADF-Zertifikat-Flagdaten enthält, die 'JA' anzeigen, stellt die CPU 16B fest, dass die ADF Zertifikatdaten enthält (Schritt S101; Ja) und berechnet einen Hash-Wert der in der ADF enthaltenem Zertifikatdaten (Schritt S102).
Nach Berechnen des Hash-Wertes vergleicht die CPU 16B den berechneten Hash-Wert und den in der SDF enthaltenen Hash-Wert, um zu bestimmen, ob sie zueinander identisch sind (Schritt S103). Falls die Hash-Werte zueinander nicht identisch sind (Schritt S103; Nein) besteht die Möglichkeit, dass die in der ADF enthaltenen Zertifikatdaten durch jemanden modifiziert worden sind, nachdem der Träger die SDF präpariert hat. Daher notifiziert die CPU 16B dem Anwender ein Herunterlade-Versagen, löscht die ADF, stellt die Software-Konfigurationen in der Mobilstation 16A auf den Zustand wieder her, bevor die ADF heruntergeladen worden war (Schritt S107), und beendet die Prozesse zum Herunterladen der Java-AP-Software.
In diesem Beispielfall werden die Hash-Werte als zueinander identisch bestimmt (Schritt S103; Ja) und die CPU 16B lädt die JAR-Datei auf die Mobilstation 16 herunter (Schritt S104). Konkreter etabliert die CPU 16B eine TCP-Verbindung zur CP-Servervorrichtung 12 unter Verwendung der JAR-Speicher-URL 'http://www.b.co.jp/melody.jar', die in der ADF enthalten ist und zeigt einen Speicherort in der CP-Servervorrichtung 12 an, wo die JAR-Datei gespeichert wird, erzeugt eine Anforderungsnachricht zum Übertragen der JAR-Datei und überträgt die Anforderungsnachricht an die CP-Servervorrichtung 12 (Schritt S7 in 6). Die CPU 16B empfängt eine Antwortnachricht, welche die JAR-Datei enthält, von der CP-Servervorrichtung 12 in Reaktion auf die Anforderungsnachricht (Schritt S8 in 6) und trennt die TCP-Verbindung.
Nach Empfang der Antwortnachricht berechnet die CPU 16B einen Hash-Wert der in der Antwortnachricht enthaltenen JAR-Datei (Schritt S105). Die CPU 16B vergleicht den berechneten Hash-Wert und den in der ADF enthaltenen JAR-Hash-Wert, um zu bestimmen, ob sie zueinander identisch sind (Schritt S106). Wenn die Hash-Werte zueinander nicht identisch sind (Schritt S106; Nein) besteht die Möglichkeit, dass die JAR-Datei gefälscht oder modifiziert worden ist, nachdem die JAR-Datei vorbereitet worden ist. Daher gibt die CPU 16B dem Anwender ein Herunterlade-Versagen bekannt, löscht die ADF und die JAR-Datei, stellt die Software-Konfigurationen in der Mobilstation 16 zu dem Zustand wieder her, bevor die ADF heruntergeladen worden war (Schritt S108), und terminiert die Prozesse zum Herunterladen der Java-AP-Software.
In diesem Beispielfall sind die Hash-Werte zueinander identisch (Schritt S106; Ja). Dementsprechend notifiziert die CPU 16B den Anwender davon, dass die Java-AP-Software erfolgreich heruntergeladen worden ist, speichert die empfangene JAR-Datei und die empfangene SDF im nicht-flüchtigen Speicher 16D (Schritt S109) und schließt die Prozesse zum Herunterladen der Java-AP-Software ab.
Nach Abschließen der Herunterlade-Prozesse für die vertrauenswürdige Java-AP-Software überwacht die CPU 16B das Verhalten einer vertrauenswürdigen Java-AP, die von der in der JAR-Datei enthaltenen Java-APP realisiert wird und gestattet oder beschränkt Verwendung der Java-AP von APIs zum Zugriff auf persönliche Daten wie etwa Telefonverzeichnis-Daten und zum Ändern von Einstellungen der Mobilstation 16 und Zugriff auf URLs gemäß den Gestattungsdaten für Zugriff auf persönliche Daten, den Gestattungsdaten für Einstellungsänderungen bzw. den Gestattungsdaten für URLs, die in der SDF enthalten sind.
Wie oben erläutert, ist es gemäß der vorliegenden Ausführungsform möglich, festzustellen, ob Zertifikatdaten, die in einer ADF enthalten sind, modifiziert worden sind, oder nachdem der Träger die Authentizität von Zertifikatdaten bestimmt hat, durch Verifizieren, dass ein Hash-Wert, der unter Verwendung der in der ADF enthaltenen Zertifikatdaten berechnet wird und ein Hash-Wert, der vorab unter Verwendung der Zertifikatdaten berechnet worden ist und in der entsprechenden SDF enthalten ist, zueinander identisch sind. Kurz gesagt, wird gemäß der vorliegenden Ausführungsform die Authentizität einer Kombination einer SDF und einer ADF bestimmt.
Wenn die Zertifikatdaten in der ADF mit den selben Zertifikatdaten, wie in der SDF enthalten, überschrieben werden, werden die Hash-Werte beider Zertifikatdaten identisch und die Kombination der SDF und der ADF wird als authentifiziert bestimmt, auch wenn die ADF modifiziert wird, nachdem die SDF vorbereitet worden ist. Falls entsprechend der CP die ADF modifizieren muss, um die JAR-Datei für den Zweck von beispielsweise dem Beseitigen von Fehlern in der JAR-Datei zu modifizieren, nachdem der Träger die Authentizität der Zertifikatdaten feststellt, ist der CP in der Lage, die Authentizität einer Kombination zwischen der SDF und der ADF auf Basis derselben Zertifikatdaten in der modifizierten ADF, wie in der Original-ADF verwendet, aufrechtzuerhalten. Daher muss der Träger nicht Vorgänge zum Bestimmen der Authentizität der Zertifikatdaten wiederholen, wenn die ADF vom CP modifiziert wird.
Darüber hinaus ist es gemäß der vorliegenden Ausführungsform möglich, festzustellen, ob eine JAR-Datei, die von einem CP heruntergeladen wird, modifiziert oder gefälscht worden ist, nachdem der Träger die Authentizität der JAR-Datei bestimmt, indem verifiziert wird, dass ein Hash-Wert, der unter Verwendung der heruntergeladenen JAR-Datei berechnet wird und ein Hash-Wert, der vorab unter Verwendung der JAR-Datei berechnet und in einer entsprechenden ADF enthalten ist, zueinander identisch sind. Kurz gesagt wird gemäß der vorliegenden Ausführungsform die Authentizität einer Kombination einer JAR-Datei und einer ADF bestimmt. Dementsprechend kann die Verwendung einer gefälschten JAR-Datei in der Mobilstation 16 verhindert werden.
Darüber hinaus gibt es gemäß der vorliegenden Ausführungsform keine Notwendigkeit, vorab an jede Mobilstation ein Aufzeichnungsmedium wie eine IC-Karte zu distributieren, die einen Hash-Wert enthält.
Entsprechend kann im Liefersystem gemäß der vorliegenden Ausführungsform die Authentizität von Kombinationen von ADFs, SDFs und JAR-Dateien einfach bestimmt werden.
Da Prozesse zum Berechnen eines Hash-Wertes weit weniger Berechnungs-Ressourcen erfordern als jene zur Berechnung eines in konventionellen Authentifizierungs-Systemen verwendeten öffentlichen Schlüsseln, kann die vorliegende Ausführungsform zur Verwendung mit einer Vorrichtung ausgelegt werden, deren Berechnungs-Ressourcen beschränkt sind, wie etwa eine Mobilstation.
(3: Modifikation)
Die vorliegende Erfindung ist nicht auf die oben beschriebene Ausführungsform beschränkt und kann innerhalb des technischen Schutzumfangs der vorliegenden Erfindung modifiziert werden. Nachfolgend werden Beispiele solcher Modifikationen gegeben.

(1) In der obigen Ausführungsform enthält die SDF einen Hash-Wert von Zertifikatdaten, der in einer ADF enthalten ist, die der SDF entspricht, und die Mobilstation 16 bestimmt die Authentizität einer Kombination der SDF und der ADF durch Vergleiche eines unter Verwendung der in der ADF enthaltenen Zertifikatdaten berechneten Hash-Werts und des in der SDF enthaltenen Hash-Werts. Ein im Liefersystem verwendeter Hash-Wert ist nicht auf einen Hash-Wert von Zertifikatdaten beschränkt und ein Hash-Wert einer anderen Art von in einer ADF enthaltenen Daten oder ein Hash-Wert der gesamten ADF kann ebenfalls für dieselben Zwecke verwendet werden.

Darüber hinaus enthält in der obigen Ausführungsform eine ADF einen Hash-Wert einer entsprechenden JAR-Datei und die Mobilstation 16 bestimmt die Authentizität einer Kombination der ADF und der JAR-Datei durch Vergleichen eines unter Verwendung der JAR-Datei berechneten Hash-Werts und des in der ADF enthaltenen Hash-Werts. Ein im Liefersystem verwendeter Hash-Wert ist nicht auf einen Hash-Wert der gesamten JAR-Datei beschränkt und ein Hash-Wert eines Teils der JAR-Datei kann ebenfalls für denselben Zweck verwendet werden.

(2) In der obigen Ausführungsform werden Hash-Funktionen unter Verwendung von SHA-1 zur Berechnung von Hash-Werten zum Bestimmen der Authentizität von Kombinationen von Dateien verwendet. Jedoch können andere Arten von Hash-Funktionen ebenfalls im Liefersystem verwendet werden. Beispielsweise sind auch Hash-Funktionen, die Message Digest 5 (MD5) einsetzen, an das Liefersystem der vorliegenden Erfindung angepasst. Darüber hinaus können alle anderen Arten von Einwege-Funktionen im Liefersystem anstelle der Hash-Funktionen verwendet werden.
(3) In der obigen Ausführungsform sind Programme zum Bestimmen der Authentizität von Dateien in einem ROM einer Mobilstation gespeichert. Die Programme können auf anderen Arten von Speichervorrichtungen gespeichert werden, wie etwa einem EEPROM einer Mobilstation. Wenn die Programme in einer wiederbeschreibbaren Speichervorrichtung wie etwa einem EEPROM gespeichert sind, können die Programme von einer externen Vorrichtung durch das mobile Kommunikationsnetzwerk auf die Mobilstation heruntergeladen und in der wiederbeschreibbaren Speichervorrichtung gespeichert werden. Wenn die Mobilstation eine Schnittstelle zur Kommunikation mit einer externen Speichervorrichtung aufweist, können die Programme der Mobilstation durch Verbinden einer externen Speichervorrichtung, wie etwa einer Speicherkarte, die die Programme enthält, mit der Mobilstation, der Mobilstation bereitgestellt werden. In diesem Fall kann die Mobilstation das Programm direkt aus der externen Speichervorrichtung auslesen und sie ausführen.
(4) In der oben erläuterten Ausführungsform enthält eine ADF Daten, die eine vertrauenswürdige Server-Domain anzeigen und eine SDF, die zu einem vertrauenswürdigen Java-APP, das auf eine Mobilstation herunterzuladen ist, gehört, wird auf Basis der Daten identifiziert. Eine SDF kann auf andere Weise identifiziert werden. Beispielsweise kann die Mobilstation 16 Daten erhalten, die vorab eine URL zum Identifizieren einer vertrauenswürdigen Servervorrichtung 18 erhalten, und wenn die Mobilstation 16 eine Anforderungsnachricht zur Übertragung der SDF von der vertrauenswürdigen Servervorrichtung 18 zur Mobilstation 16 erzeugt, kann die Mobilstation 16 der Anforderungsnachricht die die vertrauenswürdige Servervorrichtung 18 identifizierende URL und Daten, die eine vertrauenswürdige APID zur Identifizierung der SDF entsprechend der herunterzuladenden, vertrauenswürdigen Java-AP-Software anzeigen, hinzufügen.

Claims

Kommunikationsvorrichtung, umfassend: ein Empfangsmittel (16F) zum Empfangen einer Anwendungsdeskriptordatei (ADD) von einem ersten Knoten (12), wobei die Anwendungsdeskriptordatei (ADD) Daten zum Beweisen der Authentizität (Zertifizierungsdaten) und einen Speicherort (12) einer Anwendungsdatei (Jar) anzeigende Daten (URL) enthält, und zum Empfangen einer Sicherheitsbeschreibungsdatei (SBD) von einem zweiten Knoten (18), der ein anderer Knoten (12) als der erste ist, wobei die Sicherheitsbeschreibungsdatei (SBD) einen Ausgabewert einer Einwegfunktion (Hash-Wert) enthält, die mit Daten zum Überprüfen der Authentizität (Zertifizierungsdaten) arbeitet; ein Berechnungsmittel (16B) zum Berechnen eines Ausgabewertes der Einwegfunktion (Hash-Wert), die mit Daten zum Beweisen der Authentizität (Zertifizierungsdaten) arbeitet, die in der Anwendungsdeskriptordatei (ADD) enthalten sind; und ein Vergleichsmittel (16B) zum Vergleichen des Ausgabewertes (Hash-Wert) der Daten zum Beweisen der Authentizität (Zertifizierungsdaten), die in der Sicherheitsbeschreibungsdatei (SBD) enthalten sind, mit dem Ausgabewert (Hash-Wert) der vom Berechnungsmittel berechneten Daten zum Beweisen der Authentizität (Zertifizierungsdaten); gekennzeichnet dadurch, dass das Empfangsmittel die Anwendungsdatei (Jar) von einem Speicherort (12) empfängt, der durch die, den Speicherort (12) der Anwendungsdatei (Jar) anzeigenden Daten angezeigt wird, die in der Anwendungsdeskriptordatei (ADD) enthalten sind, wenn das Vergleichsmittel feststellt, dass die Ausgabewerte (Hash-Werte) der Daten zum Beweisen der Authentizität (Zertifizierungsdaten) zueinander identisch sind.
Kommunikationsvorrichtung gemäß Anspruch 1, weiterhin umfassend ein Steuermittel (16B) zum Ausführen von Prozessen anhand von in der Anwendungsdatei (Jar) beschriebenen Anweisungen, wobei: die Anwendungsdeskriptordatei (ADD) einen Ausgabewert einer Einwegfunktion (Hash-Wert) enthält, die mit der gesamten oder einen gewissen Teil einer Anwendungsdatei (Jar) arbeitet, das Berechnungsmittel einen Ausgabewert der Einwegfunktion (Hash-Wert) berechnet, die an der gesamten oder einem gewissen Teil der Anwendungsdatei (Jar) arbeitet, die vom Empfangsmittel empfangen ist, das Vergleichsmittel den Ausgabewert (Hash-Wert) der Applikationsdatei (Jar), der in der Applikationsbeschreibungsdatei (ADD) enthalten ist, mit dem vom Berechnungsmittel berechneten Ausgabewert (Hash-Wert) der Applikationsdatei (Jar) vergleicht, und das Steuermittel Prozesse anhand von in der Anwendungsdatei (Jar), die vom Empfangsmittel empfangen werden, beschriebenen Anweisungen ausführt, wenn das Vergleichsmittel feststellt, dass die Ausgabewerte (Hash-Werte) der Applikationsdatei (Jar) zueinander identisch sind.
Kommunikationsvorrichtung gemäß Anspruch 1, wobei: die Anwendungsdeskriptordatei (ADD) Daten (URL) enthält, die einen Speicherort (18) der Sicherheitsbeschreibungsdatei (SBD) anzeigen, und das Empfangsmittel die Sicherheitsbeschreibungsdatei (SBD) von dem zweiten Knoten (18) empfängt, der von den, den Speicherort (18) der Sicherheitsbeschreibungsdatei (SBD) anzeigenden Daten angezeigt wird, die in der Anwendungsdeskriptordatei (ADD) enthalten sind.
Kommunikationsvorrichtung gemäß Anspruch 1, wobei: die Daten zum Beweisen der Authentizität von einem dritten Knoten (CA) erhaltene Zertifizierungsdaten sind, der ein anderer ist als der erste und der zweite Knoten.
Kommunikationsvorrichtung gemäß Anspruch 1, weiterhin umfassend ein Steuermittel (16B) zum Ausführen von Prozessen anhand von in einer Anwendungsdatei (Jar) beschriebenen Anweisungen, wobei: die Sicherheitsbeschreibungsdatei (SBD) Daten (Berechtigungsdaten) zum Anzeigen von Berechtigungen für anhand von in der vom Empfangsmittel empfangenen Anwendungsdatei (Jar) beschriebenen Anweisungen auszuführenden Prozesse, und das Steuermittel Prozesse anhand von Instruktionen ausführt, die von den Daten zur Anzeige von Berechtigungen (Berechtigungsdaten) als zu gestattende angezeigt sind.
Computerlesbares Aufzeichnungsmedium, das ein Programm aufzeichnet, das einen Computer veranlasst, auszuführen: Empfangen einer Anwendungsdeskriptordatei (ADD) von einem ersten Knoten (12), wobei die Anwendungsdeskriptordatei (ADD) Daten zum Beweisen der Authentizität (Zertifizierungsdaten) und einen Speicherort (12) einer Anwendungsdatei (Jar) anzeigende Daten (URL) enthält, Empfangen einer Sicherheitsbeschreibungsdatei (SBD) von einem zweiten Knoten (18), der ein anderer Knoten (12) als der erste ist, wobei die Sicherheitsbeschreibungsdatei (SBD) einen Ausgabewert einer Einwegfunktion (Hash-Wert) enthält, die mit Daten zum Überprüfen der Authentizität (Zertifizierungsdaten) arbeitet; Berechnen eines Ausgabewertes der Einwegfunktion (Hash-Wert), die mit Daten zum Beweisen der Authentizität (Zertifizierungsdaten) arbeitet, die in der Anwendungsdeskriptordatei (ADD) enthalten sind; und Vergleichen des Ausgabewertes (Hash-Wert) der Daten zum Beweisen der Authentizität (Zertifizierungsdaten), die in der Sicherheitsbeschreibungsdatei (SBD) enthalten sind, mit dem Ausgabewert (Hash-Wert) der vom Berechnungsmittel berechneten Daten zum Beweisen der Authentizität (Zertifizierungsdaten); gekennzeichnet durch Empfangen die Anwendungsdatei (Jar) von einem Speicherort (12), der durch die, den Speicherort (12) der Anwendungsdatei (Jar) anzeigenden Daten angezeigt wird, die in der Anwendungsdeskriptordatei (ADD) enthalten sind, wenn das Vergleichsmittel feststellt, dass die Ausgabewerte (Hash-Werte) der Daten zum Beweisen der Authentizität (Zertifizierungsdaten) zueinander identisch sind.