-
HINTERGRUND
-
1. GEBIET DER ERFINDUNG
-
Diese
Erfindung betrifft im Allgemeinen den Bereich von Sicherheitsprotokollen
für Softwareanwendungen.
Insbesondere sieht die Erfindung ein Code-signierendes System und ein Verfahren
vor, die insbesondere gut geeignet sind für JavaTM-Anwendungen
für mobile
Kommunikationsvorrichtungen, wie PDAs (Personal Digital Assistants),
zellulare Telefone und drahtlose Zweiweg-Kommunikationsvorrichtungen (insgesamt
hier als „mobile
Vorrichtungen” oder
einfach „Vorrichtungen” bezeichnet).
-
2. BESCHREIBUNG DES STANDES
DER TECHNIK
-
Sicherheitsprotokolle,
die Software-Code-Signierschemen umfassen, sind bekannt. Typischerweise
werden derartige Sicherheitsprotokolle verwendet, um die Zuverlässigkeit
von Softwareanwendungen sicherzustellen, die aus dem Internet heruntergeladen
werden. In einem typischen Software-Code-Signierschema wird eine
digitale Signatur an die Softwareanwendung angehängt, welche den Software-Entwickler
identifiziert. Sobald die Software von einem Benutzer heruntergeladen
ist, muss der Benutzer typischerweise sein oder ihr Urteilsvermögen benutzen,
um zu bestimmen, ob die Softwareanwendung zuverlässig ist, basierend einzig
auf seiner oder ihrer Kenntnis des Rufs des Software-Entwicklers. Dieser Typ
von Code-signierendem Schema stellt nicht sicher, dass eine von
einer dritten Partei für
eine mobile Vorrichtung geschriebene Softwareanwendung mit den ursprünglichen
Anwendungen und anderen Ressourcen der Vorrichtung richtig zusammenarbeiten
wird. Da typische Code-Signierprotokolle nicht sicher sind und nur
von dem Urteilsvermögen des
Benutzers abhängen,
gibt es ein ernsthaftes Risiko, dass zerstörerische Softwareanwendungen
des Typs „Trojanisches
Pferd” heruntergeladen
und in einer mobilen Vorrichtung installiert werden können.
-
Die
Veröffentlichung
US 5,978,484 zeigt ein System
zur Verteilung von digital signierten ausführbaren Objekten unter Verwendung
eines RSA-verschlüsselten
SHA-Hashwerts.
-
Es
bleibt auch ein Bedarf für
Netzbetreiber, ein System und ein Verfahren zu besitzen, um eine Steuerung
darüber
zu haben, welche Softwareanwendungen auf mobilen Vorrichtungen aktiviert
werden.
-
Es
verbleibt ein weiterer Bedarf in 2.5G- und 3G-Netzen, wo Unternehmen
oder Netzbetreiber die Typen von Software auf den Vorrichtungen,
die an die Angestellten ausgegeben werden, zu steuern wünschen.
-
ZUSAMMENFASSUNG
-
Ein
Code-signierendes System und ein Verfahren sind vorgesehen. Das
Code-signierende
System arbeitet in Verbindung mit einer Softwareanwendung, die eine
digitale Signatur hat, und umfasst eine Anwendungsplattform, eine
Schnittstelle für
das Anwendungsprogramm (API – application
programming interface) und eine virtuelle Maschine. Die API ist konfiguriert,
die Softwareanwendung mit der Anwendungsplattform zu verbinden.
Die virtuelle Maschine verifiziert die Au thentizität der digitalen
Signatur, um einen Zugang zu der API für die Softwareanwendung zu
steuern.
-
Ein
Code-signierendes System zum Betrieb in Verbindung mit einer Softwareanwendung,
die eine digitale Signatur hat, weist gemäß einem weiteren Ausführungsbeispiel
der Erfindung eine Anwendungsplattform, eine Vielzahl von APIs,
von denen jede konfiguriert ist, die Softwareanwendung mit einer
Ressource auf der Anwendungsplattform zu verbinden, und eine virtuelle
Maschine auf, welche die Authentizität der digitalen Signatur verifiziert,
um einen Zugang zu der API für
die Softwareanwendung zu steuern, wobei die virtuelle Maschine die
Authentizität
der digitalen Signatur verifiziert, um einen Zugang zu der Vielzahl
von APIs für
die Softwareanwendung zu steuern.
-
Gemäß einem
weiteren Ausführungsbeispiel der
Erfindung weist ein Verfahren zum Steuern eines Zugangs zu sensiblen
bzw. sensitiven Schnittstellen für
das Anwendungsprogramm auf einer mobilen Vorrichtung die Schritte
auf eines Ladens einer Softwareanwendung in der mobilen Vorrichtung,
die einen Zugang zu einer sensitiven API erfordert, eines Bestimmens,
ob die Softwareanwendung eine digitale Signatur umfasst, die zu
der sensitiven API gehört, oder
nicht, und, wenn die Softwareanwendung keine zu der sensitiven API
gehörende
digitale Signatur umfasst, dann Verweigern der Softwareanwendung den
Zugang zu der sensitiven API.
-
In
einem weiteren Ausführungsbeispiel
der Erfindung weist ein Verfahren zum Steuern eines Zugangs zu einer
Anwendungsprogrammschnittstelle (API) in einer mobilen Vorrichtung
durch eine von einem Software-Entwickler erzeugte Softwareanwendung
die Schritte auf eines Empfangens der Softwareanwendung von dem
Software-Entwickler, eines Überprüfens der
Softwareanwendung, um zu bestimmen, ob sie auf die API zugreifen
kann, dann eines Anhängens
einer digita len Signatur an die Softwareanwendung, eines Verifizierens
der Authentizität
einer an die Softwareanwendung angehängten digitalen Signatur und
eines Gewährens
eines Zugangs zu der API für
Softwareanwendungen, für
welche die angehängte
digitale Signatur authentisch ist.
-
Ein
Verfahren zum Einschränken
eine Zugangs zu einer sensitiven API in einer mobilen Vorrichtung
weist gemäß einem
weiteren Ausführungsbeispiel
der Erfindung die Schritte auf eines Registrierens eines Software-Entwicklers
oder mehrerer Software-Entwickler, der/die vertrauenswürdig ist/sind,
zum Gestalten von Softwareanwendungen, die auf die sensitive API
zugreifen, eines Empfangens eines Hash-Werts einer Softwareanwendung, eines
Bestimmens, ob die Softwareanwendung von einem der registrierten
Software-Entwickler gestaltet wurde, und wenn die Softwareanwendung
von einem der registrierten Software-Entwickler gestaltet wurde, dann
eines Erzeugens einer digitalen Signatur unter Verwendung des Hash-Werts
der Softwareanwendung, wobei die digitale Signatur an die Softwareanwendung
angehängt
werden kann, und dann verifiziert die mobile Vorrichtung die Authentizität der digitalen
Signatur, um einen Zugang zu der sensitiven API durch die Softwareanwendung
zu steuern.
-
In
einem weiteren Ausführungsbeispiel
weist ein Verfahren zum Beschränken
eines Zugangs zu Schnittstellen für Anwendungsprogramme in einer mobilen
Vorrichtung die Schritte auf eines Ladens einer Softwareanwendung
in die mobile Vorrichtung, die einen Zugang zu einer oder mehreren
API(s) erfordert, eines Bestimmens, ob die Softwareanwendung eine
zu der mobilen Vorrichtung gehörende
digitale Signatur umfasst oder nicht, und wenn die Softwareanwendung
keine zu der mobilen Vorrichtung gehörende digitale Signatur umfasst,
dann eines Verweigerns der Softwareanwendung eines Zugangs zu der
einen oder den mehreren API(s).
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
1 ist
ein Diagramm, das ein Code-signierendes Protokoll gemäß einem
Ausführungsbeispiel
der Erfindung zeigt;
-
2 ist
ein Flussdiagramm des oben unter Bezugnahme auf 1 beschriebenen
Code-signierenden Protokolls;
-
3 ist
eine Blockdarstellung eines Code-signierenden Systems in einer mobilen
Vorrichtung;
-
3A ist
eine Blockdarstellung eines Code-signierenden Systems in einer Vielzahl
von mobilen Vorrichtungen;
-
4 ist
ein Flussdiagramm, das den Betrieb des oben unter Bezugnahme auf 3 und 3A beschriebenen
Code-signierenden Systems darstellt;
-
5 ist
ein Flussdiagramm, das die Verwaltung der unter Bezugnahme auf 3A beschriebenen
Code-signierenden Autoritäten
darstellt; und
-
6 ist
eine Blockdarstellung einer mobilen Kommunikationsvorrichtung, in
der ein Code-signierendes System und Verfahren implementiert werden können.
-
DETAILLIERTE BESCHREIBUNG
-
Unter
Bezugnahme nun auf die Zeichnungen ist 1 ein Diagramm,
das ein Code-signierendes Protokoll gemäß einem Ausführungsbeispiel
der Erfindung zeigt. Ein Anwendungsentwickler 12 erzeugt eine
Softwareanwendung 14 (Anwendung Y) für eine mobile Vorrichtung,
die einen Zugang zu einer oder mehreren sensitiven API(s) in der
mobilen Vorrichtung erfordert. Die Softwareanwendung Y 14 kann zum
Beispiel eine Java-Anwendung sein, die auf einer in der mobilen
Vorrichtung installierten virtuellen Java-Maschine arbeitet. Eine
API ermöglicht
der Softwareanwendung Y, sich mit einer Anwendungsplattform zu verbinden,
die zum Beispiel Ressourcen aufweisen kann, wie die Hardware der
Vorrichtung, das Betriebssystem und Kern-Software und Datenmodelle.
Um Funktionsanrufe zu tätigen
oder anderweitig mit derartigen Ressourcen zu interagieren, muss
eine Softwareanwendung Y auf eine oder mehrere API(s) zugreifen.
APIs können
somit gewissermaßen
eine Softwareanwendung und zugehörige Vorrichtungsressourcen
miteinander verbinden. In dieser Beschreibung und den angehängten Ansprüchen sollten
Referenzen auf einen API-Zugang interpretiert werden als einen Zugang
zu einer API aufweisend derart, um einer Softwareanwendung Y zu ermöglichen,
mit einer oder mehreren entsprechenden Vorrichtungsressource(n)
zu interagieren. Ein Vorsehen eines Zugangs zu einer API ermöglicht somit
einer Softwareanwendung Y, mit zugehörigen Vorrichtungsressourcen
zu interagieren, wohingegen ein Verweigern eines Zugangs zu einer
API, die Softwareanwendung Y daran hindert, mit den zugehörigen Ressourcen
zu interagieren. Zum Beispiel kann eine Datenbank-API mit einem
Datei- oder Datenspeichersystem einer Vorrichtung kommunizieren und
ein Zugang zu der Datenbank-API würde eine Interaktion zwischen
der Softwareanwendung Y und dem Datei- oder Datenspeichersystem
vorsehen. Eine Benutzerschnittstelle(UI – user interface)-API würde mit
Steuereinrichtungen und/oder Steuerungssoftware für derartige
Vorrichtungskomponenten, wie ein Bildschirm, eine Tastatur und andere
Vorrichtungskomponenten, die eine Ausgabe an einen Benutzer liefern
oder eine Eingabe von einem Benutzer akzeptieren, kommunizieren.
In einer mobilen Vorrichtung kann auch eine Funk-API als eine Schnittstelle
zu drahtlosen Kommunikationsressourcen vorgesehen werden, wie ein
Sender und Empfänger. Ähnlich kann
eine kryptographi sche API vorgesehen werden, um mit einem Verschlüsselungs(crypto)-Modul
zu interagieren, das Verschlüsselungsalgorithmen
in einer Vorrichtung implementiert. Dies sind nur veranschaulichende
Beispiele von APIs, die auf einer Vorrichtung vorgesehen werden
können.
Eine Vorrichtung kann beliebige dieser Beispiels-APIs umfassen oder
andere APIs statt oder zusätzlich
zu den oben beschriebenen.
-
Vorzugsweise
kann eine API als sensitiv bzw. sensibel klassifiziert werden von
einem Hersteller einer mobilen Vorrichtung oder möglicherweise von
einem API-Autor,
einem Betreiber eines drahtlosen Netzes, einem Besitzer oder Betreiber
einer Vorrichtung oder einer anderen Einheit, die von einem Virus
oder bösartigen
Code in einer Softwareanwendung für die Vorrichtung betroffen
sein kann. Zum Beispiel kann ein Hersteller einer mobilen Vorrichtung
diejenigen APIs als sensitiv klassifizieren, die eine Schnittstelle
haben mit kryptographischen Routinen, Funktionen drahtloser Kommunikation
oder proprietären
Datenmodellen, wie Adressbuch- oder Kalendereinträge. Um gegen
einen unbefugten Zugang zu diesen sensitiven APIs zu schützen, muss der
Anwendungsentwickler 12 eine oder mehrere digitale Signaturen
von dem Hersteller der mobilen Vorrichtung oder einer anderen Einheit,
die APIs als sensitiv klassifiziert, oder von einer Code-signierenden Autorität 16,
die im Namen des Herstellers oder der anderen Einheit mit einem
Interesse am Schutz des Zugangs zu sensitiven APIs von Vorrichtungen handelt,
besorgen und die Signatur(en) an die Softwareanwendung Y 14 anhängen.
-
In
einem Ausführungsbeispiel
wird eine digitale Signatur besorgt für jede sensitive API oder Bibliothek,
die eine sensitive API umfasst, auf welche die Softwareanwendung
einen Zugang erfordert. In einigen Fällen sind mehrere Signaturen
wünschenswert. Dies
würde es
einem Diensteanbieter, einem Unternehmen oder einem Netzbetreiber
ermöglichen,
einige oder alle Softwareanwendungen zu beschränken, die in einen bestimmten
Satz von mobilen Vorrichtungen geladen oder aktualisiert werden.
In diesem Szenario mit mehreren Signaturen werden alle APIs beschränkt und
gesperrt, bis eine „globale” Signatur
für eine
Softwareanwendung verifiziert wird. Zum Beispiel kann ein Unternehmen
zu verhindern wünschen,
dass seine Angestellten Softwareanwendungen in ihren Vorrichtungen
ausführen,
ohne zuerst eine Erlaubnis von einer Abteilung für Informationstechnologie (IT)
oder Computerdienste des Unternehmens einzuholen. Alle derartigen
firmeneigenen mobilen Vorrichtungen können dann konfiguriert werden,
eine Verifizierung von zumindest einer globalen Signatur zu erfordern,
bevor eine Softwareanwendung ausgeführt werden kann. Zugang zu
sensitiven Vorrichtungs-APIs
und Bibliotheken, falls vorhanden, kann dann abhängig von einer Verifizierung von
jeweiligen entsprechenden digitalen Signaturen weiter eingeschränkt werden.
-
Die
binär ausführbare Darstellung
der Softwareanwendung Y 14 kann unabhängig von dem bestimmten Typ
der mobilen Vorrichtung oder dem Modell einer mobilen Vorrichtung
sein. Die Softwareanwendung Y 14 kann zum Beispiel in einem „schreibe einmal,
laufe überall” (write-once-run-anywhere)
binären
Format sein, wie es der Fall bei Java-Softwareanwendungen ist. Es
kann jedoch wünschenswert sein,
eine digitale Signatur für
jeden Typ oder Modell einer mobilen Vorrichtung oder alternativ
für jede Plattform
oder jeden Hersteller einer mobilen Vorrichtung zu haben. Deshalb
kann die Softwareanwendung Y 14 an mehrere Code-signierende Autoritäten eingereicht
werden, wenn die Softwareanwendung Y 14 mehrere mobile
Vorrichtungen zum Ziel hat.
-
Die
Softwareanwendung Y 14 wird von dem Anwendungsentwickler 12 an
die Code-signierende Autorität 16 gesendet.
In dem in 1 gezeigten Ausführungsbeispiel überprüft die Code-signierende Autorität 16 die
Softwareanwendung Y 14, obwohl, wie detaillierter im Folgenden
beschrieben wird, in Erwägung
gezogen werden kann, dass die Code-signierende Autorität 16 zusätzlich oder
stattdessen die Identität
des Anwendungsentwicklers 12 berücksichtigen kann, um zu bestimmen,
ob die Softwareanwendung Y 14 signiert werden soll oder
nicht. Die Code-signierende Autorität 16 ist vorzugsweise
ein Repräsentant
oder mehrere Repräsentanten
des Herstellers der mobilen Vorrichtung, der Autoren von jeglichen
sensitiven APIs oder möglicherweise
Anderer, die Kenntnis des Betriebs der sensitiven APIs haben, für welche
die Softwareanwendung Y 14 einen Zugang erfordert.
-
Wenn
die Code-signierende Autorität 16 bestimmt,
dass die Softwareanwendung Y 14 auf die sensitive API zugreifen
kann und folglich signiert werden sollte, dann wird eine Signatur
(nicht gezeigt) von der Code-signierende Autorität 16 für die Softwareanwendung
Y 14 erzeugt und an die Softwareanwendung Y 14 angehängt. Die
signierte Softwareanwendung Y 22, welche die Softwareanwendung
Y 14 und die digitale Signatur aufweist, wird dann an den
Anwendungsentwickler 12 zurückgesendet. Die digitale Signatur
ist vorzugsweise eine Kennzeichnung (tag), die unter Verwendung
eines privaten Signaturschlüssels 18 erzeugt
wird, der nur von der Code-signierenden Autorität 16 geführt wird.
Zum Beispiel kann gemäß einem
Signaturschema ein Hash-Wert der Softwareanwendung Y 14 erzeugt
werden unter Verwendung eines Hash-Algorithmus', wie dem sicheren Hash-Algorithmus
SHA1 (Secure Hash Algorithm), und dann wird der private Signaturschlüssel 18 verwendet,
um die digitale Signatur zu erzeugen. In einigen Signaturschemen
wird der private Signaturschlüssel
verwendet, um einen Hash-Wert
von zu signierender Information zu verschlüsseln, wie die Softwareanwendung
Y 14, wohingegen in anderen Schemen der private Schlüssel auf
andere Weise verwendet werden kann, um eine Signatur aus der zu signierenden
Information oder einer transformierten Version der Information zu
erzeugen.
-
Die
signierte Softwareanwendung Y 22 kann dann an eine mobile
Vorrichtung 28 gesendet werden oder von der mobilen Vorrichtung 28 über ein
drahtloses Netzwerk 24 heruntergeladen werden. Es sollte jedoch
angemerkt werden, dass ein Code-signierendes Protokoll gemäß der vorliegenden
Erfindung nicht auf Soft wareanwendung beschränkt ist, die über ein
drahtloses Netzwerk heruntergeladen werden. Zum Beispiel kann in
alternativen Ausführungsbeispielen
die signierte Softwareanwendung Y 22 über ein Computernetzwerk auf
einen Personalcomputer heruntergeladen werden und über eine
serielle Verbindung auf die mobile Vorrichtung geladen werden oder
von dem Anwendungsentwickler 12 auf eine andere Weise erlangt
und auf die mobile Vorrichtung geladen werden. Sobald die signierte
Softwareanwendung Y 22 auf die mobile Vorrichtung 28 geladen
ist, wird jede digitale Signatur vorzugsweise mit einem öffentlichen
Signaturschlüssel 20 verifiziert,
bevor der Softwareanwendung Y 14 ein Zugang zu einer „sensitive
APIs”-Bibliothek gewährt wird.
Obwohl die signierte Softwareanwendung Y 22 auf eine Vorrichtung
geladen wird, sollte angemerkt werden, dass die Softwareanwendung,
die schließlich
auf der Vorrichtung ausgeführt
wird, die Softwareanwendung Y 14 ist. Wie oben beschrieben
umfasst die signierte Softwareanwendung Y 22 die Softwareanwendung
Y 14 und eine oder mehrere angehängte digitale Signatur(en)
(nicht gezeigt). Wenn die Signaturen verifiziert sind, kann die
Softwareanwendung Y 14 auf der Vorrichtung ausgeführt werden
und auf alle APIs zugreifen, für
die entsprechende Signaturen verifiziert wurden.
-
Der öffentliche
Signaturschlüssel 20 korrespondiert
dem privaten Signaturschlüssel 18,
der von der Code-signierenden Autorität 16 geführt wird,
und ist vorzugsweise auf der mobilen Vorrichtung zusammen mit der
sensitiven API installiert. Jedoch kann der öffentliche Schlüssel 10 stattdessen
von einem Aufbewahrungsort (nicht gezeigt) für öffentliche Schlüssel unter
Verwendung der Vorrichtung 28 oder möglicherweise eines Personalcomputersystems
erlangt werden und wie erforderlich auf der Vorrichtung 28 installiert
werden. Gemäß einem
Ausführungsbeispiel
eines Signaturschemas berechnet die mobile Vorrichtung 28 einen
Hash-Wert der Softwareanwendung
Y 14 in der signierten Softwareanwendung Y 22 unter
Verwendung desselben Hashing-Algorithmus wie die Code-signierende
Autorität 16 und
verwendet die digitale Signatur und den öffentlichen Signaturschlüssel 20,
um den von der signierenden Autorität 16 berechneten Hash-Wert wiederherzustellen.
Der resultierende lokal berechnete Hash-Wert und der aus der digitalen
Signatur wiederhergestellte Hash-Wert werden dann verglichen, und
wenn die Hash-Werte übereinstimmen,
ist die Signatur verifiziert. Die Softwareanwendung Y 14 kann
dann auf der Vorrichtung 28 ausgeführt werden und auf alle sensitiven
APIs zugreifen, für
welche die entsprechende(n) Signatur(en) verifiziert wurde(n). Wie
oben beschrieben ist die Erfindung in keinster Weise auf dieses
bestimmte erläuternde
Beispielssignaturschema beschränkt.
Andere Signaturschemen, einschließlich weitere öffentliche
Schlüssel-Signaturschemen,
können
ebenfalls in Verbindung mit den hier beschriebenen Code-signierenden
Verfahren und Systemen verwendet werden.
-
2 ist
ein Flussdiagramm 30 des oben unter Bezugnahme auf 1 beschriebenen
Code-signierenden Protokolls. Das Protokoll beginnt in Schritt 32.
In Schritt 34 schreibt ein Softwareentwickler die Softwareanwendung
Y für eine
mobile Vorrichtung, die einen Zugang zu einer sensitiven API oder
Bibliothek, die eine sensitive API freilegt (API-Bibliothek A), erfordert.
Wie oben diskutiert können
einige oder alle APIs auf einer mobilen Vorrichtung als sensitiv
klassifiziert werden, folglich erfordern sie eine Verifizierung
einer digitalen Signatur zum Zugang durch jede Softwareanwendung,
wie die Softwareanwendung Y. In Schritt 36 wird die Anwendung
Y von dem Softwareentwickler vorzugsweise unter Verwendung eines
Vorrichtungssimulators getestet, in dem die Verifizierungsfunktion
für die
digitale Signatur deaktiviert wurde. Auf diese Weise kann der Softwareentwickler in
der Softwareanwendung Y Fehler suchen und beseitigen (debuggen),
bevor die digitale Signatur von der Code-signierenden Autorität erlangt
wird. Sobald die Softwareanwendung Y geschrieben und debuggt wurde,
wird sie in Schritt 38 an die Code-signierende Autorität weitergeleitet.
-
In
den Schritten 40 und 42 prüft die Code-signierende Autorität die Softwareanwendung
Y, um zu bestimmen, ob ihr Zugang zu der sensitiven API gewährt werden
soll oder nicht, und akzeptiert die Softwareanwendung oder weist
sie zurück.
-
Die
Code-signierende Autorität
kann eine Anzahl von Kriterien anwenden, um zu bestimmen, ob der
Softwareanwendung Zugang zu der sensitiven API gewährt werden
soll oder nicht, einschließlich
zum Beispiel die Größe der Softwareanwendung, die
Vorrichtungsressourcen, auf die von der API zugegriffen werden,
die wahrgenommene Brauchbarkeit der Softwareanwendung, die Interaktion
mit anderen Softwareanwendungen, der Einschluss eines Virus oder
anderen bösartigen
Codes und ob der Entwickler eine vertragliche Bindung oder eine
andere Geschäftsvereinbarung
mit dem Hersteller der mobilen Vorrichtung hat oder nicht. Weitere
Details zur Verwaltung von Code-signierenden Autoritäten und Entwicklern
werden im Folgenden unter Bezugnahme auf 5 beschrieben.
-
Wenn
die Code-signierende Autorität
die Softwareanwendung Y akzeptiert, dann werden eine digitale Signatur
und vorzugsweise eine Signaturidentifizierung an die Softwareanwendung
Y in Schritt 46 angehängt.
Wie oben beschrieben, kann die digitale Signatur durch Verwendung
eines Hash-Werts der Softwareanwendung Y und eines privaten Signaturschlüssels 18 erzeugt
werden. Die Signaturidentifizierung wird im Folgenden unter Bezugnahme
auf die 3 und 4 beschrieben.
Sobald die digitale Signatur und die Signaturidentifizierung an
die Softwareanwendung Y angehängt
sind, um eine signierte Softwareanwendung zu erzeugen, wird die
signierte Softwareanwendung Y in Schritt 48 an den Softwareentwickler
zurückgesendet.
Der Softwareentwickler kann dann die signierte Softwareanwendung
Y zum Laden auf eine mobile Vorrichtung lizensieren (Schritt 50).
Wenn jedoch die Code-signierende Autorität die Softwareanwendung Y zurückweist,
dann wird vorzugsweise eine Ablehnungsbenachrichtigung an den Softwareentwickler
gesendet (Schritt 44) und die Softwareanwendung Y kann
nicht auf zu der Signatur gehörende
API(s) zugreifen.
-
In
einem alternativen Ausführungsbeispiel kann
der Softwareentwickler der Code-signierenden Autorität nur einen
Hash-Wert der Softwareanwendung Y liefern oder die Softwareanwendung
Y in einem Typ eines gekürzten
Formats liefern.
-
Wenn
die Softwareanwendung Y eine Java-Anwendung ist, dann können die
Vorrichtungs-unabhängigen
binären
*.Klasse-Dateien in der Hashing-Operation verwendet werden, obwohl
Vorrichtungs-abhängige
Dateien, wie von der Anmelderen der vorliegenden Anmeldung verwendete
*.cod-Dateien, stattdessen in Hashing- oder anderen „digitale Signatur”-Operationen
verwendet werden können, wenn
Softwareanwendungen zum Betrieb auf bestimmten Vorrichtungen oder
Vorrichtungstypen vorgesehen sind. Durch Vorsehen nur eines Hash-Werts oder
einer gekürzten
Version der Softwareanwendung Y kann der Softwareentwickler die
Softwareanwendung Y signiert bekommen, ohne der Code-signierenden Autorität einen
proprietären
Code zu offenbaren. Der Hash-Wert der Softwareanwendung Y zusammen
mit dem privaten Schlüssel 18 kann
dann von der Code-signierenden Autorität verwendet werden, um die
digitale Signatur zu erzeugen. Wenn eine ansonsten gekürzte Version
der Softwareanwendung Y an die Code-signierenden Autorität gesendet
wird, dann kann die gekürzte
Version ähnlich
verwendet werden, um die digitale Signatur zu erzeugen, vorausgesetzt,
dass das verkürzende
Schema oder der Algorithmus, wie ein Hash-Algorithmus, unterschiedliche
Ausgaben für
unterschiedliche Eingaben erzeugt. Dies stellt sicher, dass jede
Softwareanwendung eine andere gekürzte Version hat, und somit kann
eine andere Signatur nur verifiziert werden, wenn sie an die bestimmte
entsprechende Softwareanwendung angehängt ist, aus der die gekürzte Version
erzeugt wurde. Da dieses Ausführungsbeispiel der
Code-signierenden Autorität
nicht ermöglicht,
die Softwareanwendung auf Viren und anderen bösartigen Code zu überprüfen, kann
jedoch auch ein Registrierungsprozess zwischen dem Softwareentwickler
und der Code-signierenden Autorität erforderlich sein. Zum Beispiel
kann die Code-signierende Autorität im Voraus zustimmen, einem
vertrauenswürdigen
Softwareentwickler Zugang zu einem begrenzten Satz von sensitiven
APIs zu gewähren.
-
In
einem weiteren alternativen Ausführungsbeispiel
kann eine Softwareanwendung Y an mehr als eine signierende Autorität eingereicht
werden. Jede signieren de Autorität
kann zum Beispiel verantwortlich sein für ein Signieren von Softwareanwendungen
für bestimmte
sensitive APIs oder für
APIs auf einem bestimmten Modell einer mobilen Vorrichtung oder
einem Satz von mobilen Vorrichtungen, der die von einer Softwareanwendung
erforderlichen sensitiven APIs unterstützt. Ein Hersteller, ein Netzbetreiber
für mobile
Kommunikation, ein Diensteanbieter oder ein Unternehmenskunde zum
Beispiel kann somit eine signierende Autorität haben über die Verwendung von sensitiven
APIs für
sein bestimmtes Modell/seine bestimmten Modelle einer mobilen Vorrichtung
oder für
die mobilen Vorrichtungen, die auf einem bestimmten Netzwerk arbeiten,
die einen oder mehrere bestimmte Dienste abonnieren, oder die an die
Angestellten des Unternehmen verteilt werden. Eine signierte Softwareanwendung
kann somit eine Softwareanwendung und zumindest eine angehängte digitale
Signatur, die von einer der signierenden Autoritäten angehängt wird, umfassen. Obwohl
die signierenden Autoritäten
in diesem Beispiel eine Signatur für dieselbe Softwareanwendung
erzeugen würden,
können
den unterschiedlichen signierenden Autoritäten verschiedene Signier- und
Signatur-Verifizierungsschemen zugeordnet werden.
-
3 ist
eine Blockdarstellung eines Code-signierenden Systems 60 für eine mobile
Vorrichtung 62. Das System 60 umfasst eine virtuelle
Maschine 64, eine Vielzahl von Softwareanwendungen 66–70,
eine Vielzahl von API-Bibliotheken 72–78 und eine Anwendungsplattform 80.
Die Anwendungsplattform 80 umfasst vorzugsweise alle Ressourcen in
der mobilen Vorrichtung 62, auf die von den Softwareanwendungen 66–70 zugegriffen
werden können.
Zum Beispiel kann die Anwendungsplattform eine Vorrichtungs-Hardware 82,
das Betriebssystem 84 der mobilen Vorrichtung oder Kern-Software-
und Datenmodelle 86 aufweisen. Jede API-Bibliothek 72–78 umfasst
vorzugsweise eine Vielzahl von APIs, die mit einer in der Anwendungsplattform
verfügbaren
Ressource verbunden sind. Zum Beispiel kann eine API-Bibliothek
alle APIs umfassen, die mit einem Kalenderprogramm und Kalendereintragdatenmodellen
verbunden sind. Eine andere API-Bibliothek kann alle APIs umfassen,
die mit den Übertragungsschaltungen und
-funktionen der mobilen Vorrichtung 62 verbunden sind.
Eine weitere API-Bibliothek
kann alle APIs umfassen, die zu einer Verbindung mit untergeordneten
Diensten fähig
sind, die von dem Betriebssystem 84 der mobilen Vorrichtung durchgeführt werden.
Zusätzlich
kann die Vielzahl von API-Bibliotheken 72–78 sowohl
Bibliotheken umfassen, die eine sensitive API freilegen, 74 und 78, wie
eine Schnittstelle zu einer Verschlüsselungsfunktion, als auch
Bibliotheken 72 und 76, auf die ohne eine Freilegung
von sensitiven APIs zugegriffen werden kann. Ähnlich kann die Vielzahl von
Softwareanwendungen 66–70 sowohl
signierte Softwareanwendungen 66 und 70, die einen
Zugang zu einer oder mehreren sensitiven API(s) erfordern, als auch
nichtsignierte Softwareanwendungen, wie 68, umfassen. Die
virtuelle Maschine 64 ist vorzugsweise eine objektorientierte
Laufzeitumgebung, wie J2METE (Java 2 Platform,
Micro Edition) von Sun Micro Systems, welche die Ausführung aller
auf der mobilen Vorrichtung 62 arbeitenden Softwareanwendungen 66–70 verwaltet
und die Softwareanwendungen 66–70 mit den verschiedenen
API-Bibliotheken 72–78 verbindet.
-
Die
Softwareanwendung Y 70 ist ein Beispiel einer signierten
Softwareanwendung. Jede signierte Softwareanwendung umfasst vorzugsweise
eine tatsächliche
Softwareanwendung, wie die Softwareanwendung Y, die zum Beispiel
einen Softwarecode aufweist, der auf der Anwendungsplattform 80 ausgeführt werden
kann, eine oder mehrere Signaturidentifizierung(en) 94 und
eine oder mehrere digitale Signatur(en) 96. Vorzugsweise
entspricht jede digitale Signatur 96 und zugehörige Signaturidentifizierung 94 in
einer signierten Softwareanwendung 66 oder 70 einer „sensitive
APIs”-Bibliothek 74 oder 78,
für welche
die Softwareanwendung X oder die Softwareanwendung Y einen Zugang
erfordert. Die „sensitive APIs”-Bibliothek 74 oder 78 kann
eine oder mehrere sensitive API(s) umfassen. In einem alternativen Ausführungsbeispiel
können
die signierten Softwareanwendung 66 oder 70 eine
digitale Signatur 96 für jede
sensitive API in einer API-Bibliothek 74 oder 78 umfassen.
Die Signaturidentifizierungen 94 können eindeutige Ganzzahlen
oder andere Mittel sein, um eine digitale Signatur 96 mit einer
bestimmten API-Bibliothek 74 oder 78, einer API,
der Anwendungsplattform 80 oder einem Modell einer mobilen
Vorrichtung 62 in Beziehung zu setzen.
-
Die
API-Bibliothek A 78 ist ein Beispiel einer API-Bibliothek,
die eine sensitive API freilegt. Jede API-Bibliothek 74 und 78,
die eine sensitive API umfasst, sollte vorzugsweise umfassen eine
Beschreibungszeichenfolge 88, einen öffentlichen Signaturschlüssel 20 und
eine Signaturkennung 92. Die Signaturkennung 92 korrespondiert
vorzugsweise zu einer Signaturidentifizierung 94 in einer
signierten Softwareanwendung 66 oder 70 und ermöglicht der
virtuellen Maschine 64, eine digitale Signatur 96 schnell mit
einer API-Bibliothek 74 oder 78 abzugleichen. Der öffentliche
Signaturschlüssel 20 korrespondiert zu
dem privaten Signaturschlüssel 18,
der von der Code-signierenden Autorität geführt wird, und wird verwendet,
um die Authentizität
einer digitalen Signatur 96 zu verifizieren. Die Beschreibungszeichenfolge 88 kann
zum Beispiel eine Textmeldung sein, die auf der mobilen Vorrichtung
angezeigt wird, wenn eine signierte Softwareanwendung 66 oder 70 geladen
ist oder alternativ, wenn eine Softwareanwendung X oder Y auf eine
sensitive API zuzugreifen versucht.
-
In
Betrieb, wenn eine signierte Softwareanwendung 68–70,
die jeweils eine Softwareanwendung X, Z oder Y umfasst, die eine
Zugang zu einer „sensitive
API”-Bibliothek 74 oder 78 fordert,
auf eine mobile Vorrichtung geladen wird, durchsucht die virtuelle
Maschine 64 die signierte Softwareanwendung nach einer
angehängten
digitalen Signatur 96, die zu der API-Bibliothek 74 oder 78 gehört. Vorzugsweise wird
die passende digitale Signatur 96 von der virtuellen Maschine 64 gefunden
durch Vergleichen der Signaturkennung 92 in der API-Bibliothek 74 oder 78 mit
einer Signaturidentifizierung 94 in der signierten Softwareanwendung.
Wenn die signierte Softwareanwendung die passende digitale Signatur 96 umfasst,
dann verifiziert die virtuelle Maschine 64 ihre Authentizität unter
Verwendung des öffentlichen
Signaturschlüssels 20.
Sobald die passende digitale Signatur 96 gefunden und verifiziert
wurde, wird die Beschreibungszeichenfolge 88 vorzugsweise
auf der mobilen Vorrichtung angezeigt, bevor die Softwareanwendung
X oder Y ausgeführt
wird und auf die sensitive API zugreift. Zum Beispiel kann die Beschreibungszeichenfolge 88 eine
Meldung anzeigen, die besagt, dass „Anwendung Y versucht auf
API-Bibliothek A zuzugreifen”,
und somit dem Benutzer der mobilen Vorrichtung die letzte Kontrolle
geben, einen Zugang zu der sensitiven API zu gewähren oder zu verweigern.
-
3A ist
eine Blockdarstellung eines Code-signierenden Systems 61 in
einer Vielzahl von mobilen Vorrichtungen 62E, 62F und 62G.
Das System 61 umfasst eine Vielzahl von mobilen Vorrichtungen,
von denen nur drei dargestellt sind, die mobilen Vorrichtungen 62E, 62F und 62G.
Ebenso wird eine signierte Softwareanwendung 70 gezeigt,
einschließlich
einer Softwareanwendung Y, an die zwei digitale Signaturen 96E und 96F mit
entsprechenden Signaturidentifizierungen 94E und 94F angehängt wurden. In
dem Beispielsystem 61 entspricht jedes aus einer digitalen
Signatur und einer Identifizierung bestehende Paar, 94E/96E und 94F/96F,
einem Modell einer mobilen Vorrichtung 62, API-Bibliothek 78 oder
zugehörigen
Plattform 80. Wenn die Signaturidentifizierungen 94E und 94F unterschiedlichen
Modellen der mobilen Vorrichtung 62 entsprechen, dann durchsucht,
wenn eine signierte Softwareanwendung 70, die eine Softwareanwendung
Y umfasst, die einen Zugang zu einer „sensitive API”-Bibliothek 78 erfordert,
auf die mobile Vorrichtung 62E geladen wird, die virtuelle
Maschine 64 die signierte Softwareanwendung 70 nach
einer digitalen Signatur 96E, die zu der API-Bibliothek 78 gehört, durch
Vergleichen des Identifikators 94E mit der Signaturkennung 92. Ähnlich durchsucht,
wenn eine signierte Softwareanwendung 70, mit einer Softwareanwendung
Y, die einen Zugang zu einer „sensitive
API”-Bibliothek 78 erfordert,
auf eine mobile Vorrichtung 62F geladen wird, die virtuelle
Maschine 64 in der Vorrichtung 62F die signierte
Softwareanwendung 70 nach einer digitalen Signatur 96F,
die zu der API-Bibliothek 78 gehört. Wenn jedoch eine Softwareanwendung
Y in einer signierten Softwareanwendung 70, die einen Zugang zu
einer „sensitive
API”-Bibliothek 78 erfordert,
auf ein Modell einer mobilen Vorrichtung geladen wird, für das der
Anwendungsentwickler keine digitale Signatur erhalten hat, die Vorrichtung 62G in
dem Beispiel von 3A, findet die virtuelle Maschine 64 in der
Vorrichtung 64G keine an die Softwareanwendung Y angehängte digitale
Signatur und folglich wird ein Zugang zu der API-Bibliothek 78 auf
der Vorrichtung 62G verweigert. Es sollte aus der vorangehenden
Beschreibung angemerkt werden, dass eine Softwareanwendung, wie
die Softwareanwendung Y, mehrere Vorrichtungs-spezifische, Bibliotheks-spezifische oder
API-spezifische Signaturen oder eine Kombination derartiger Signaturen
angehängt
haben kann. Ähnlich
können
unterschiedliche Anforderungen zur Signaturverifikation für die unterschiedlichen Vorrichtungen
konfiguriert werden. Zum Beispiel kann die Vorrichtung 62E eine
Verifikation sowohl einer globalen Signatur als auch von zusätzlichen
Signaturen für
jede sensitive API erfordern, für
die eine Softwareanwendung einen Zugang erfordert, damit die Softwareanwendung
ausgeführt
werden kann, wohingegen die Vorrichtung 62F eine Verifikation
nur der globalen Signatur erfordern kann und die Vorrichtung 62G eine
Verifikation von Signaturen nur für ihre sensitiven APIs erfordern
kann. Es sollte ebenso offensichtlich sein, dass ein Kommunikationssystem Vorrichtungen
(nicht gezeigt) umfassen kann, auf denen eine Softwareanwendung
Y, die als Teil einer signierten Softwareanwendung, wie 70,
empfangen wird, ohne eine Signaturverifikation ablaufen kann. Obwohl
eine signierte Softwareanwendung eine oder mehrere Signaturen angehängt hat,
kann die Softwareanwendung Y möglicherweise
auf einigen Vorrichtungen ausgeführt
werden, ohne dass zuerst ihre Signatur(en) verifiziert werden. Ein
Signieren einer Softwareanwendung hat vorzugsweise keine Auswirkungen
auf ihre Ausführung
auf Vorrichtungen, auf denen eine Verifikation von digitalen Signaturen
nicht implementiert ist.
-
4 ist
ein Flussdiagramm 100, das den Betrieb des oben unter Bezugnahme
auf 3 und 3A beschriebenen
Code-signierenden Systems darstellt. In Schritt 102 wird
eine Softwareanwendung in eine mobile Vorrichtung geladen. Sobald
die Softwareanwendung geladen ist, bestimmt die Vorrichtung vorzugsweise
un ter Verwendung einer virtuellen Maschine, ob die Softwareanwendung
einen Zugang zu API-Bibliotheken erfordert, die eine sensitive API freilegen,
oder nicht (Schritt 104). Wenn nicht, wird die Softwareanwendung
mit allen erforderlichen API-Bibliotheken verbunden und ausgeführt (Schritt 118).
Wenn die Softwareanwendung jedoch einen Zugang zu einer sensitiven
API erfordert, verifiziert die virtuelle Maschine in den Schritten 106–116,
dass die Softwareanwendung eine gültige digitale Signatur aufweist,
die zu den sensitiven APIs gehört,
für die ein
Zugang erforderlich ist.
-
In
Schritt 106 ruft die virtuelle Maschine den öffentlichen
Signaturschlüssel 20 und
die Signaturkennung 92 aus der „sensitive API”-Bibliothek
ab. Die Signaturkennung 92 wird dann in Schritt 108 von
der virtuellen Maschine verwendet, um zu bestimmen, ob die Softwareanwendung
eine angehängte
digitale Signatur 96 mit einer entsprechenden Signaturidentifizierung 94 aufweist
oder nicht. Wenn nicht, wurde die Softwareanwendung für einen
Zugang zu der sensitiven API von einer Code-signierenden Autorität nicht freigegeben
und die Ausführung
der Softwareanwendung wird vorzugsweise in Schritt 116 verhindert.
In alternativen Ausführungsbeispielen
kann eine Softwareanwendung ohne eine gültige digitale Signatur 96 aus
der mobilen Vorrichtung gelöscht
werden oder ihr wird der Zugang zu der API-Bibliothek verwehrt, welche
die sensitive API freilegt, aber sie wird zu dem Umfang ausgeführt, der
ohne einen Zugang zu der API-Bibliothek möglich ist. Es wird auch in
Betracht gezogen, einen Benutzer zu einer Eingabe aufzufordern,
wenn eine Verifikation einer Signatur fehlschlägt, wodurch dem Benutzer eine
Kontrolle solcher nachfolgender Operationen, wie ein Löschen der
Softwareanwendung von der Vorrichtung, gegeben wird.
-
Wenn
eine der „sensitive
API”-Bibliothek
entsprechende digitale Signatur 96 an die Softwareanwendung
angehängt
ist und von der virtuellen Maschine gefunden wird, dann verwendet
die virtuelle Maschine den öffentlichen
Schlüssel 20,
um die Authentizität
der digitalen Signatur 96 in Schritt 110 zu verifizieren.
Dieser Schritt kann ausgeführt
werden zum Beispiel durch Verwendung des oben beschriebenen Signaturverifizierungsschemas
oder andere alternative Signaturschemen. Wenn die digitale Signatur 96 nicht
authentisch ist, dann wird die Softwareanwendung vorzugsweise entweder
nicht ausgeführt,
gelöscht
oder gehindert, auf die sensitive API zuzugreifen, wie oben unter
Bezugnahme auf Schritt 116 beschrieben wurde. Wenn jedoch
die digitale Signatur 96 authentisch ist, dann wird vorzugsweise
die Beschreibungszeichenfolge 88 in Schritt 112 angezeigt,
die den Benutzer der mobilen Vorrichtung warnt, dass die Softwareanwendung
einen Zugang zu einer sensitiven API erfordert, und den Benutzer möglicherweise
zu einer Autorisierung auffordert, die Softwareanwendung auszuführen oder
zu laden (Schritt 114). Wenn mehr als eine Signatur für eine Softwareanwendung
zu verifizieren ist, werden die Schritte 104–110 vorzugsweise
für jede
Signatur wiederholt, bevor der Benutzer in Schritt 112 aufgefordert
wird. Wenn der Benutzer der mobilen Vorrichtung in Schritt 114 die
Softwareanwendung autorisiert, kann sie ausgeführt und mit der „sensitive API”-Bibliothek
in Schritt 118 verbunden werden.
-
5 ist
ein Flussdiagramm 200, das die Verwaltung der unter Bezugnahme
auf 3A beschriebenen Code-signierenden Autoritäten darstellt. In
Schritt 210 hat ein Anwendungsentwickler eine neue Softwareanwendung
entwickelt, die auf einem oder mehreren Modellen) oder Typ(en) von
Zielvorrichtung ausführbar
sein soll. Die Zielvorrichtungen können Sätze von Vorrichtungen von unterschiedlichen
Herstellern, Sätze
von Vorrichtungsmodellen oder -typen von demselben Hersteller oder
allgemein Sätze
von Vorrichtungen mit bestimmten Signatur- und Verifikationsanforderungen
umfassen. Der Begriff „Zielvorrichtung” betrifft
jeden derartigen Satz von Vorrichtungen mit einer gemeinsamen Signaturanforderung.
Zum Beispiel kann ein Satz von Vorrichtungen, der eine Verifikation
einer Vorrichtungs-spezifischen globalen Signatur zur Ausführung aller
Softwareanwendungen erfordert, eine Zielvorrichtung aufweisen und
Vorrichtungen, die sowohl eine globale Signatur als auch weitere
Signaturen für sensitive
APIs erfordern, können
Teil von mehr als einem Zielvorrichtungssatz sein. Die Softwareanwendung
kann auf eine Vorrichtungs-unabhängige
Weise unter Verwendung von zumindest einer bekannten API geschrieben
werden, unterstützt
auf zumindest einer Zielvorrichtung mit einer API-Bibliothek. Vorzugsweise
soll die entwickelte Softwareanwendung auf mehreren Zielvorrichtungen
ausführbar
sein, von denen jede ihre eigene zumindest eine API-Bibliothek aufweist.
-
In
Schritt 220 empfangt eine Code-signierende Autorität für eine Zielvorrichtung
eine Ziel-signierende Anforderung von dem Entwickler. Die Ziel-signierende
Anforderung umfasst die Softwareanwendung oder einen Hash-Wert der
Softwareanwendung, einen Entwickler-Identifikator sowie zumindest einen
Zielvorrichtungsidentifikator, der die Zielvorrichtung identifiziert,
für die
eine Signatur angefordert wird. In Schritt 230 konsultiert
die signierende Autorität
eine Entwickler-Datenbank 235 oder andere Aufzeichnungen,
um zu bestimmen, ob ein Entwickler 220 vertrauenswürdig ist
oder nicht. Diese Bestimmung kann gemäß mehreren oben diskutierten
Kriterien durchgeführt
werden, wie zum Beispiel ob der Entwickler eine vertragliche Bindung
oder einen anderen Typ von Geschäftsvereinbarung
mit einem Hersteller der Vorrichtung, einem Netzbetreiber, einem
Diensteanbieter oder einem Hersteller der Vorrichtung hat oder nicht.
Wenn der Entwickler vertrauenswürdig
ist, geht das Verfahren zu Schritt 240. Wenn jedoch der
Entwickler nicht vertrauenswürdig ist,
dann wird die Softwareanwendung zurückgewiesen (250) und
von der signierenden Autorität
nicht signiert. Angenommen, der Entwickler ist vertrauenswürdig, stellt
in Schritt 240 die signierende Autorität fest, ob sie den privaten
Zielschlüssel
hat, der dem eingereichten Zielidentifikator entspricht, durch Konsultieren
eines Privatschlüsselspeichers,
wie eine Datenbank 245 für private Zielschlüssel. Wenn
der private Zielschlüssel
gefunden ist, dann wird in Schritt 260 eine digitale Signatur
für die
Softwareanwendung erzeugt und die digitale Signatur oder eine signierte
Softwareanwendung mit der an die Softwareanwendung angehängten digitalen
Signatur wird an den Entwickler in Schritt 280 zurückgesendet. Wenn
jedoch in Schritt 240 der private Zielschlüssel nicht
gefunden wird, dann wird die Softwareanwendung in Schritt 270 zurückgewiesen
und es wird keine digitale Signatur für die Softwareanwendung erzeugt.
-
Vorteilhafterweise
kann, wenn Ziel-signierende Autoritäten kompatiblen Ausführungsbeispielen
des in 5 dargestellten Verfahrens folgen, ein Netzwerk
von Ziel-Signierautoritäten
aufgebaut werden, um Code-signierende Autoritäten und einen Entwicklergemeinschafts-Code-signierenden
Prozess sinnvoll zu verwalten, was zu signierten Softwareanwendungen
für mehrere
Ziele mit einer geringen Wahrscheinlichkeit von zerstörerischem
Code führt.
-
Sollte
ein zerstörerischer
oder anderweitig problematischer Code in Softwareanwendungen gefunden
oder vermutet werden aufgrund von gezeigtem Verhalten, wenn eine
Softwareanwendung auf einer Vorrichtung ausgeführt wird, kann/können die Registrierung
oder die Privilegien des entsprechenden Anwendungsentwicklers bei
einigen oder allen signierenden Autoritäten ebenso ausgesetzt oder
zurückgenommen
werden, da die digitale Signatur einen Prüfpfad vorsieht, durch den der
Entwickler einer problematischen Softwareanwendung identifiziert werden
kann. In einem derartigen Fall können
Vorrichtungen von dem Rückruf
informiert werden, indem sie konfiguriert sind, zum Beispiel regelmäßig Signaturrückrufverzeichnisse
herunterzuladen. Wenn Softwareanwendungen, für welche die entsprechenden
digitalen Signaturen zurückgerufen wurden,
auf einer Vorrichtung laufen, kann die Vorrichtung dann die Ausführung einer
derartigen Softwareanwendung anhalten und möglicherweise die Softwareanwendung
aus ihrem lokalen Speicher löschen.
Wenn bevorzugt, können
Vorrichtungen auch konfiguriert werden, Verifikationen von digitaler
Signatur erneut auszuführen,
zum Beispiel regelmäßig oder
wenn ein neues Rückrufverzeichnis
heruntergeladen wird.
-
Obwohl
eine von einer signierenden Autorität erzeugte digitale Signatur
abhängig
von einer Authentisierung des Anwendungsentwicklers und einer Bestätigung ist,
dass der Anwendungsentwickler ordnungsgemäß registriert ist, wird die
digitale Signatur vorzugsweise aus einem Hash-Wert oder einer anderweitig
transformierten Version der Softwareanwendung erzeugt und ist somit
Anwendungs-spezifisch.
Dies steht im Kontrast zu bekannten Code-signierenden Schemen, in
denen ein API-Zugang allen Softwareanwendungen erteilt wird, die
von vertrauenswürdigen
Anwendungsentwicklern oder -autoren eintreffen. In den hier beschriebenen
Code-signierenden Systemen und Verfahren wird ein API-Zugang auf
einer Anwendung-per-Anwendungs-Basis erteilt und kann somit genauer
gesteuert oder reguliert werden.
-
6 ist
eine Blockdarstellung einer mobilen Kommunikationsvorrichtung, in
der ein Code-signierendes System und Verfahren implementiert werden können. Die
mobile Kommunikationsvorrichtung 610 ist vorzugsweise eine
Zweiweg-Kommunikationsvorrichtung
mit zumindest Sprach- und Datenkommunikationsfähigkeiten. Die Vorrichtung
weist vorzugsweise die Fähigkeit
auf, mit anderen Computersystemen auf dem Internet zu kommunizieren.
Abhängig von
der von der Vorrichtung vorgesehenen Funktionalität kann die
Vorrichtung als eine Datenmeldungs(messaging)-Vorrichtung, ein Zweiweg-Pager, ein
zellulares Telefon mit Datenmeldungsfähigkeiten, ein drahtloses Internetgerät oder eine
Datenkommunikationsvorrichtung (mit oder ohne Telefonfähigkeiten)
bezeichnet werden.
-
Wenn
die Vorrichtung 610 für
Zweiweg-Kommunikationen eingerichtet ist, weist die Vorrichtung ein
Kommunikations-Teilsystem 611 auf, einschließlich einem
Empfänger 612,
einem Sender 614 und zugehörigen Komponenten, wie ein
oder mehrere vorzugsweise integrierte oder interne Antennenelement(e) 616 und 618,
lokale Oszillatoren (LOs – local oscillators) 613 und
ein Verarbeitungsmodul, wie ein digitaler Signalprozessor (DSP – digital
signal processor) 620. Wie für Fachleute auf dem Gebiet
von Kommunikationen offensichtlich sein dürfte, ist die spe zielle Gestaltung
des Kommunikations-Teilsystems 611 abhängig von dem Kommunikationsnetz,
in dem die Vorrichtung arbeiten soll. Zum Beispiel kann eine für einen
nordamerikanischen Markt bestimmte Vorrichtung 610 ein
Kommunikations-Teilsystem 611 aufweisen, das zum Betrieb
in dem mobilen MobitexTM-Kommunikationssystem
oder dem mobilen DataTACTM-Kommunikationssystem
vorgesehen ist, wohingegen eine zur Verwendung in Europa vorgesehene
Vorrichtung 610 ein GPRS(General Packet Radio Service)-Kommunikations-Teilsystem 611 enthalten
kann.
-
Netzwerkzugangsanforderungen
variieren auch abhängig
von dem Typ des Netzwerks 919. Zum Beispiel werden in den
Mobitex- und DataTAC-Netzen mobile Vorrichtungen, wie 610,
in dem Netz unter Verwendung einer eindeutigen zu jeder Vorrichtung
gehörenden
Identifizierungsnummer registriert. In GPRS-Netzwerken gehört ein Netzzugang zu einem
Teilnehmer oder Benutzer einer Vorrichtung 610. Eine GPRS-Vorrichtung
erfordert somit ein Teilnehmeridentitätsmodul (nicht gezeigt), das
allgemein als eine SIM-Karte bezeichnet wird, um auf einem GPRS-Netzwerk
zu funktionieren. Ohne eine SIM-Karte ist eine GPRS-Vorrichtung
nicht voll funktionsfähig.
Lokale oder nicht-netzabhängige
Kommunikationsfunktionen (wenn vorhanden) können betriebsfähig sein,
aber die Vorrichtung 610 kann keine Funktionen ausführen, die
Kommunikationen über das
Netzwerk 919 beinhalten, außer gesetzlich erforderliche
Operationen, wie der „911”-Notruf.
-
Wenn
erforderliche Vorgehen zur Netzregistrierung oder -aktivierung abgeschlossen
sind, kann eine Vorrichtung 610 Kommunikationssignale über das
Netzwerk 919 senden und empfangen. Von der Antenne 616 durch
ein Kommunikationsnetzwerk 619 empfangene Signale werden
in den Empfänger 612 eingegeben,
der so allgemeine Empfängerfunktionen
durchführen
kann wie Signalverstärkung,
Frequenzabwärtswandlung,
Filtern, Kanalauswahl und Ähnliches
und in dem in 6 gezeigten Beispielssystem
eine Analog-Digital-Wandlung. Eine Analog-Digital-Wandlung eines
empfangenen Signals ermöglicht,
dass komplexere Kommunikationsfunktionen, wie eine Demodulation
und Decodierung, in dem DSP 620 durchgeführt werden.
Auf ähnliche Weise
werden zu übertragende
Signale von dem DSP 620 verarbeitet, einschließlich zum
Beispiel eine Modulation und Codierung, und in den Sender 614 eingegeben
zur Digital-Analog-Wandlung, Frequenzaufwärtswandlung, Filterung, Verstärkung und Übertragung über das
Kommunikationsnetz 619 über die
Antenne 618.
-
Der
DSP 620 verarbeitet nicht nur Kommunikationssignale, sondern
sieht auch eine Empfänger- und
Sendersteuerung vor. Zum Beispiel können die Verstärkungen,
die in dem Empfänger 612 und
dem Sender 614 auf Kommunikationssignale angelegt werden,
durch in dem DSP 620 implementierte automatische Verstärkungssteuerungs-Algorithmen
adaptiv gesteuert werden.
-
Die
Vorrichtung 610 umfasst vorzugsweise einen Mikroprozessor 638,
der den Gesamtbetrieb der Vorrichtung steuert. Kommunikationsfunktionen, einschließlich von
zumindest Daten- und Sprachkommunikationen, werden durch das Kommunikations-Teilsystem 611 durchgeführt. Der
Mikroprozessor 638 interagiert auch mit weiteren Teilsystemen oder
Ressourcen der Vorrichtung, wie der Anzeige 622, einem
Flash-Speicher 624, dem Arbeitsspeicher (RAM – random
access memory) 626, Hilfs-Ein-Ausgabe(I/O – input/Output)-Teilsystemen 628,
einem seriellen Anschluss 630, einer Tastatur 632,
einem Lautsprecher 634, einem Mikrofon 636, einem
Nahbereichs-Kommunikations-Teilsystem 640 und jedem anderen
Vorrichtungs-Teilsystem, im Allgemeinen als 642 bezeichnet.
APIs, einschließlich
sensitive APIs, die eine Verifikation von einer oder mehreren digitalen
Signaturen erfordern, bevor ein Zugang gewährt wird, können in der Vorrichtung 610 vorgesehen
sein, um eine Schnittstelle zwischen Softwareanwendungen und den
in 6 gezeigten Ressourcen zu bilden.
-
Einige
der in 6 gezeigten Teilsysteme führen Kommunikations-bezogene
Funktionen durch, während
andere Teilsysteme „residente” Funktionen
oder Funktionen in der Vorrichtung vorsehen. Besonders können einige
Teilsysteme, wie zum Beispiel die Tastatur 632 und die
Anzeige 622, sowohl für
Kommunikations-bezogene Funktionen, wie Eingabe einer Textmeldung
zur Übertragung über ein Kommunikationsnetzwerk,
als auch Vorrichtungs-residente Funktionen, wie eine Rechenmaschine
oder ein Aufgabenverzeichnis, verwendet werden.
-
Betriebssystemsoftware,
die von dem Mikroprozessor 638 verwendet wird und möglicherweise von
den APIs, auf die von Softwareanwendungen zugegriffen wird, wird
vorzugsweise in einem dauerhaften Speicher gespeichert, wie dem
Flash-Speicher 624, der auch ein Festwertspeicher (ROM – read only memory)
oder ein ähnliches
Speicherelement sein kann (nicht gezeigt). Für Fachleute ist offensichtlich, dass
das Betriebssystem, bestimmte Softwareanwendungen der Vorrichtung
oder Teile davon temporär
in einen flüchtigen
Speicher, wie den RAM 626, geladen werden können. Es
wird in Betracht gezogen, dass empfangene und gesendete Kommunikationssignale
ebenfalls in dem RAM 626 gespeichert werden können.
-
Der
Mikroprozessor 638 ermöglicht
zusätzlich
zu seinen Betriebssystemfunktionen vorzugsweise eine Ausführung von
Softwareanwendungen auf der Vorrichtung. Ein vorgegebener Satz von
Anwendungen, der grundlegende Operationen der Vorrichtung steuert,
einschließlich
zum Beispiel zumindest von Daten- und Sprachkommunikation, wird
normalerweise in der Vorrichtung 610 während der Herstellung installiert.
Eine bevorzugte Anwendung, die auf die Vorrichtung geladen werden
kann, kann eine PIM(Personal Information Manager)-Anwendung sein
mit der Fähigkeit,
den Benutzer der Vorrichtung betreffende Datenelemente, wie E-Mail,
Kalenderereignisse, Voice-Mail, Termine und Aufgabenelemente, aber
nicht darauf beschränkt,
zu organisieren und zu verwalten. Selbstverständlich sind ein oder mehrere
Speicher in der Vorrichtung verfügbar,
um eine Speiche rung von PIM-Datenelementen in der Vorrichtung zu
speichern. Eine derartige PIM-Anwendung hätte vorzugsweise die Fähigkeit,
Datenelemente über
das drahtlose Netzwerk zu senden und zu empfangen. In einem bevorzugten
Ausführungsbeispiel
werden die PIM-Datenelemente nahtlos integriert, synchronisiert
und über
das drahtlose Netzwerk aktualisiert mit den entsprechenden Datenelementen
des Benutzers der Vorrichtung, die in einem Hostcomputersystem gespeichert
sind oder dazu gehören,
wodurch ein gespiegelter Hostcomputer in der mobilen Vorrichtung
zumindest bezüglich
der Datenelemente erzeugt wird. Dies wäre insbesondere vorteilhaft
in dem Fall, in dem das Hostcomputersystem das Bürocomputersystem des Benutzers
der mobilen Vorrichtung ist. Weitere Anwendungen, einschließlich signierter
Softwareanwendungen wie oben beschrieben, können ebenfalls über das
Netzwerk 619, ein Hilfs-Ein-Ausgabe-Teilsystem 628,
einen seriellen Anschluss 630, ein Nahbereichs-Kommunikations-Teilsystem 640 und
jedes andere geeignete Teilsystem 642 in die Vorrichtung 610 geladen
werden. Der Mikroprozessor 638 der Vorrichtung kann dann alle
globale Signaturen verifizieren, möglicherweise sowohl „globale” Vorrichtungssignaturen
als auch API-spezifische Signaturen umfassend, die an eine derartige
Softwareanwendung angehängt
sind, bevor die Softwareanwendung von dem Mikroprozessor 638 ausgeführt werden
kann und/oder auf zugehörige
sensitive APIs zugreifen kann. Eine derartige Flexibilität bei der
Anwendungsinstallierung erhöht
die Funktionalität
der Vorrichtung und kann verbesserte Funktionen in der Vorrichtung,
Kommunikations-bezogene Funktionen oder beides liefern. Zum Beispiel können sichere
Kommunikationsanwendungen ermöglichen,
dass Funktionen des elektronischen Handels und andere derartige
finanzielle Transaktionen unter Verwendung der Vorrichtung 610 über eine
Verschlüsselungs-API
und ein Verschlüsselungs-Modul, das Verschlüsselungsalgorithmen
in der Vorrichtung implementiert (nicht gezeigt), durchgeführt werden.
-
In
einem Datenkommunikationsmodus wird ein empfangenes Signal, wie
eine Textmeldung oder eine heruntergeladene Webseite, von dem Kommunikations- Teilsystem 611 verarbeitet
und in den Mikroprozessor 638 eingegeben, der vorzugsweise
das empfangene Signal zur Ausgabe an die Anzeige 622 oder
alternativ an eine Hilfs-Ein-Ausgabe-Vorrichtung 628 weiter
verarbeitet. Ein Benutzer der Vorrichtung 610 kann auch
Datenelemente verfassen, wie zum Beispiel E-Mail-Meldungen unter Verwendung der Tastatur 632,
die vorzugsweise eine vollständige alphanumerische
Tastatur oder eine Telefon-typische Tastatur ist, in Verbindung
mit der Anzeige 622 und möglicherweise einer Hilfs-Ein-Ausgabe-Vorrichtung 628.
Derartige verfasste Elemente können
dann über ein
Kommunikationsnetz durch das Kommunikations-Teilsystem 611 übertragen
werden.
-
Für Sprachkommunikationen
ist der Gesamtbetrieb der Vorrichtung 610 im Wesentlichen
gleich, außer
dass empfangene Signale vorzugsweise an einen Lautsprecher 634 ausgegeben
werden und Signale zur Übertragung
von einem Mikrofon 636 erzeugt werden. Alternative Sprach-
oder Audio-Ein-Ausgabe-Teilsysteme,
wie ein Voice-Messaging-Aufzeichnungsteilsystem, können ebenfalls
in die Vorrichtung 610 implementiert werden. Obwohl eine
Sprach- oder Audio-Signalausgabe vorzugsweise im Wesentlichen durch
den Lautsprecher 634 erzielt wird, kann auch die Anzeige 622 verwendet
werden, um zum Beispiel eine Anzeige der Identität einer anrufenden Partei,
der Dauer eines Sprachanrufs oder andere Sprachanruf-bezogene Information
zu liefern.
-
Der
serielle Anschluss 630 in 6 wird normalerweise
in einer PDA(personal digital assistant)-artigen Kommunikationsvorrichtung
implementiert, für
die eine Synchronisierung mit einem Desktop-Computer (nicht gezeigt)
des Benutzers wünschenswert
sein kann, aber sie ist eine optionale Vorrichtungskomponente. Ein
derartiger Anschluss 630 würde es einem Benutzer ermöglichen,
Präferenzen durch
eine externe Vorrichtung oder Softwareanwendung zu setzen, und würde die
Fähigkeiten
der Vorrichtung durch Liefern von Information oder Softwaredownloads
an die Vorrichtung 610 außer über ein drahtloses Kommunikationsnetz
erweitern. Der alternative Pfad zum Herunterladen kann zum Beispiel
verwendet werden, um einen Verschlüsselungsschlüssel über eine
direkte und somit zuverlässige und
vertrauenswürdige
Verbindung in die Vorrichtung zu laden, um dadurch eine sichere
Vorrichtungskommunikation zu ermöglichen.
-
Ein
Nahbereichs-Kommunikations-Teilsystem 640 ist eine weitere
optionale Komponente, die eine Kommunikation zwischen der Vorrichtung 624 und
unterschiedlichen Systemen oder Vorrichtungen, die nicht notwendigerweise
gleiche Vorrichtungen sein müssen,
vorsehen kann. Zum Beispiel kann das Teilsystem 640 eine
Infrarot-Vorrichtung und zugehörige
Schaltungen und Komponenten oder ein BluetoothTM-Kommunikationsmodul
umfassen, um eine Kommunikation mit ähnlich aktivierten Systemen oder
Vorrichtungen vorzusehen.
-
Die
hier beschriebenen Ausführungsbeispiel sind
Beispiele von Strukturen, Systemen oder Verfahren mit Elementen,
die den Elementen der in den Ansprüchen rezitierten Erfindung
entsprechen. Diese schriftliche Beschreibung kann Fachleuten ermöglichen,
Ausführungsbeispiele
mit alternativen Elementen, die genauso den Elementen der in den
Ansprüchen
rezitierten Erfindung entsprechen, herzustellen und zu verwenden.
Der beabsichtige Umfang der Erfindung umfasst somit andere Strukturen,
Systeme oder Verfahren, die sich nicht von der wörtlichen Sprache der Ansprüche unterscheiden,
und umfasst weiter andere Strukturen, Systeme oder Verfahren mit
unwesentlichen Unterschieden von der wörtlichen Sprache der Ansprüche.
-
Wenn
zum Beispiel in Schritt 250 in dem in 5 gezeigten
Verfahren eine Softwareanwendung zurückgewiesen wird, kann die signierende
Autorität fordern,
dass der Entwickler einen Vertrag unterzeichnet oder eine Geschäftsbeziehung
mit einem Hersteller von Vorrichtungen oder einer anderen Entität eingeht,
in dessen Namen die signierende Autorität arbeitet. Ähnlich kann,
wenn in Schritt 270 eine Softwareanwendung zurückgewiesen
wird, die Autorität
zum Signieren der Softwareanwendung an eine andere signierende Autorität übertragen
werden. Das Signieren einer Softwareanwendung nachfolgend auf eine Übertragung
des Signierens der Softwareanwendung an die unterschiedliche Autorität kann im Wesentlichen
wie in 5 gezeigt ablaufen, wobei die Ziel-Signierautorität, welche
die ursprüngliche Anforderung
von dem vertrauenswürdigen
Entwickler in Schritt 220 empfangen hat, fordert, dass
die Softwareanwendung von der anderen signierenden Autorität im Namen
des vertrauenswürdigen
Entwicklers von der Ziel-Signierautorität signiert wird. Sobald eine
vertrauenswürdige
Beziehung zwischen den Code-signierenden Autoritäten hergestellt wurde, können private
Ziel-Code-signierende
Schlüssel
zwischen den Code-signierenden Autoritäten gemeinsam verwendet werden,
um eine Leistung des Verfahrens in Schritt 240 zu verbessern,
oder eine Vorrichtung kann konfiguriert werden, digitale Signaturen
von jeder der vertrauenswürdigen
Code-signierenden Autoritäten
zu validieren.
-
Zusätzlich können, obwohl
sie vorrangig in Zusammenhang mit Softwareanwendungen beschrieben
wurden, Code-signierende Systeme und Verfahren gemäß der vorliegenden
Erfindung ebenso auf andere Vorrichtungs-bezogene Komponenten angewendet
werden, einschließlich,
aber in keinster Weise darauf beschränkt, Anweisungen und zugehörige Anweisungsargumente
und Bibliotheken, die konfiguriert sind, mit Vorrichtungsressourcen
eine Schnittstelle zu bilden. Derartige Anweisungen und Bibliotheken
können
an die mobilen Vorrichtungen durch Hersteller von Vorrichtungen,
Besitzern von Vorrichtungen, Netzbetreibern, Diensteanbieter, Entwicklern
von Softwareanwendungen und Ähnlichen gesendet
werden. Es wäre
wünschenswert,
die Ausführung
jeder Anweisung, die den Betrieb der Vorrichtung betrifft, wie zum
Beispiel eine Anweisung zur Änderung
eines Vorrichtungsidentifikationscodes oder einer Adresse eines
drahtlosen Kommunikationsnetzes, zu steuern, indem eine Verifikation
einer oder mehrerer digitaler Signaturen gefordert wird, bevor eine
Anweisung auf einer Vorrichtung ausgeführt werden kann, gemäß den Code-signierenden
Systemen und Verfahren, die hier beschrieben und beansprucht werden.