DE69634684T2

DE69634684T2 - Vorrichtung und Verfahren zur Ausführung nachprüfbarer Programme mit Möglichkeit zur Nutzung von nicht-nachprüfbaren Programmen aus vertrauten Quellen

Info

Publication number: DE69634684T2
Application number: DE69634684T
Authority: DE
Inventors: Charles E. Sunnyvale McManis
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-12-08
Filing date: 1996-11-27
Publication date: 2006-01-19
Anticipated expiration: 2016-11-28
Also published as: CN1156286A; US5692047A; JPH1011281A; KR100433319B1; HK1000846A1; US6070239A; TW355768B; CN1097771C; EP0778520A2; CA2190556A1; DE69634684D1; EP0778520B1; AU7185696A; KR970049730A; EP0778520A3; AU717615B2; SG75108A1; JP4112033B2

Description

Die vorliegende Erfindung bezieht sich allgemein auf verteilte Computersysteme, und insbesondere auf ein System und ein Verfahren, in welchem ein Programminterpreter für Programme, deren Integrität prüfbar ist, eine Einrichtung für die Verwendung nichtprüfbarer Programme von vertrauenswürdigen Quellen und zum Zurückweisen ausgeführter anderer nichtprüfbarer Programme enthält.
HINTERGRUND DER ERFINDUNG
Der Ausdruck "Architektur" ist für die Zwecke dieses Dokuments so definiert, dass er die Betriebseigenschaften einer Familie von Computermodellen bezeichnet. Beispiele von verschiedenen Architekturen sind: Macintosh-Computer, IBM-PC-kompatible Computer, die DOS oder Windows-Betriebssysteme verwenden, Sun-Microsystems-Computer, auf denen das Solaris-Betriebssystem läuft, und Computersysteme, die das Unix-Betriebssystem verwenden.
Der Ausdruck "architekturneutral" ist für die Zwecke dieses Dokuments so definiert, dass er sich auf die Fähigkeit bestimmter Programme bezieht, wie z. B. Programme, die in der Sprache Java (eine Handelsmarke von Sun Microsystems, Inc.) geschrieben sind, auf einer Vielfalt von Computerplattformen unter Verwendung mehrerer unterschiedlicher Computerarchitekturen ausgeführt zu werden.
Der Ausdruck "architekturspezifisch" ist für die Zwecke für dieses Dokuments so definiert, dass er sich auf die Forderung bezieht, das bestimmte Pro gramme nur auf Computerplattformen auszuführen sind, die eine einzige Computerarchitektur verwenden. Zum Beispiel können Objektcodeprogramme, die in der 80486-Assembler-Sprache geschrieben sind, nur auf Computern ausgeführt werden, die die IBM-PC-kompatible Computerarchitektur verwenden (sowie auf anderen Computern, die IBM-PC-kompatible Computeremulatoren enthalten).
Wichtige Merkmale von architekturneutralen Programmen (ANProgrammen) umfassen die Architekturunabhängigkeit von Programmen, die in der architekturneutralen Sprache (ANSprache) geschrieben sind. Zum Beispiel können Java-Bytecode-Programme auf einer beliebigen Computerplattform ausgeführt werden, die einen Java-Bytecode-Interpreter aufweist. Ein zusätzliches wichtiges Merkmal von Java-Bytecode-Programmen ist, dass ihre Integrität vor der Ausführung von einer Java-Bytecode-Prüfeinrichtung direkt überprüft werden kann. Eine Java-Bytecode-Prüfeinrichtung bestimmt, ob das Programm vordefinierte Integritätskriterien erfüllt. Solche Kriterien umfassen Operandenstapel- und Datentypnutzungsbeschränkungen, die sicherstellen, dass Java-Bytecode-Programme den Operandenstapel des ausführenden Computers nicht zum Überlaufen oder Unterlaufen bringen können, und dass alle Programmbefehle nur Daten von bekannten Datentypen verwenden. Als Ergebnis können Java-Bytecode-Programme keine Objektzeiger erzeugen und können im Allgemeinen nicht auf andere Systembetriebsmittel zugreifen als auf diejenigen, die der Benutzer explizit zur Verwendung freigegeben hat.
Ungünstigerweise bewirkt das Verteilen ausführbarer Programme in einer ANSprache, dass das ANProgramm weniger effizient läuft, als es laufen würde, wenn es Nutzen von architekturspezifischen Merkmalen ziehen könnte. Zum Beispiel laufen Java-Bytecode-Programme, die von einem Java-Bytecode-Interpreter ausgeführt werden, typischerweise 2,5 bis 5 Mal langsamer als äquivalente architekturspezifische Programme (ASProgramme), die in entsprechende architekturspezifische Sprachen (ASSprachen) compiliert sind. Obwohl ein Faktor einer fünffachen Geschwindigkeitsreduktion derzeit als ungewöhnlich gut für eine ANProgramm-Ausführungseinrichtung (wie z. B. einen Interpreter) betrachtet wird, ist es ein ausreichender Effizienzverlust, der einige Nutzer nötigt oder veranlasst, äquivalen te Programme zu nutzen, die in eine ASSprache compiliert sind.
Compiler, die ein ANProgramm in ein äquivalentes ASProgramm compilieren können, können geschrieben werden. Diese können jedoch für den Endbenutzer unerreichbar teuer sein. Außerdem kann die Integrität des äquivalenten compilierten ASProgramms nicht direkt anhand des compilierten ASProgrammcodes von einer ANProgramm-Integritätsprüfeinrichtung geprüft werden. Somit führt im Fall von Java-Bytecode-Programmen die Verwendung von ANProgrammen, die in äquivalente ASProgramme compiliert worden sind, möglicherweise zu einem Verlust von einem der wertvollsten Merkmale einer ANSprache.
EP 0 555 715 offenbart ein System, in welchem ein Benutzer eine Funktion unter Verwendung von vordefinierten Befehlen von einem kryptographischen Modul definieren kann, ohne die Sicherheit des Moduls zu beeinträchtigen.
Der Artikel "Java and Interpret programming" (Dr. Dobb's Journal, August 1995, USA, Bd. 20, Nr. 8, S. 56, 58, 60–61, 101–102) beschreibt eine Java-Umgebung mit einer Bytecode-Prüfeinrichtung, in der Teile des Codes in Maschinenbefehle konvertiert werden, um die Leistungsfähigkeit des Programms zu verbessern.
Es gibt jedoch einige legitime (oder legale) Kleinprogramme (Aufgaben), die von in der Integrität nicht prüfbaren ASProgrammen ausgeführt werden können, die jedoch nicht von in der Integrität prüfbaren ANProgrammen ausgeführt werden können. Diese umfassen Kleinprogramme, die ansonsten die Operandenstapel- und Datentypnutzungsbeschränkungen verletzen würden, die den in der Integrität prüfbaren ANProgrammen auferlegt sind. Außerdem können solche ASProgramme viel schneller ausgeführt werden als ANProgramme. Als Ergebnis gibt es eine Vielzahl von Gründen, warum es wünschenswert ist, ein Computersystem zu haben, das dafür ausgelegt ist, hauptsächlich in der Integrität prüfbare ANProgramme auszuführen, jedoch auch die Fähigkeit hat, in der Integrität nicht prüfbare ASProgramme auszuführen.
Obwohl die Compilierung von ANProgrammen durch eine dritte Partei möglich ist, erfordern solche Compilierungen, dass die dritte Partei authentifiziert wird. Das heißt, es muss möglich sein, anhand der Informationen im compilierten ASProgramm zu prüfen, dass es von einer spezifischen vertrauenswürdigen dritten Partei compiliert worden ist. Noch besser sollte es auch möglich sein, sicherzustellen, dass das compilierte ASProgramm von einem spezifischen vertrauenswürdigen Compiler erzeugt wurde. Da ferner die Integrität des compilierten ASProgramms bezüglich der vordefinierten Integritätskriterien nicht direkt überprüft werden kann, sollte das compilierte ASProgramm Informationen enthalten, die in einer prüfbaren Weise das entsprechende ANProgramm, aus dem es compiliert wurde, sowie die ASSprache identifizieren, in die es compiliert wurde.
Die Ausführungsformen der vorliegenden Erfindung schaffen einen ANProgramm-Compiler und ein Compilierungsverfahren, das den Benutzer eines aus einem entsprechenden ANProgramm compilierten ASProgramms ermöglicht, die Identität desjenigen, der das ANProgramm compiliert hat, sowie die Identität des entsprechenden ANProgramms und der ASSprache nachzuweisen, in die das ASProgramm compiliert wurde.
Die Ausführungsformen der vorliegenden Erfindung schaffen ferner eine ANProgramm-Ausführungseinrichtung und ein Ausführungsverfahren, das in der Integrität prüfbaren ANProgrammen ermöglicht, ausgeführt zu werden, um in der Integrität nicht prüfbare ASProgramme aufzurufen, die vertrauenswürdig sind oder prüfbare Quellen und Compilierungsinformationen aufweisen, so dass im Wesentlichen alle legitimen Kleinprogramme ausgeführt werden können, während der Aufruf von ASProgrammen verhindert wird, deren Quellen, Compilierungsinformationen und Integrität nicht geprüft werden kann.
ÜBERBLICK ÜBER DIE ERFINDUNG
Die Erfindung schafft einen Computer, wie in Anspruch 1 ausgeführt ist, ein Verfahren zum Betreiben eines Computersystems, wie in Anspruch 6 ausgeführt ist, und computerlesbare Medien, wie in Anspruch 11 ausgeführt ist.
Zusammengefasst schaffen die Ausführungsformen der Erfindung eine Programmausführungseinrichtung, die prüfbare architekturneutrale Programme ausführt, und eine Klassenladeeinrichtung, die das Laden und Ausführen von nichtprüfbaren Programmen verhindert, sofern nicht (A) das nichtprüfbare Programm in einer vertrauenswürdigen Ablage solcher Programme enthalten ist, oder (B) das nichtprüfbare Programm mittels einer digitalen Signatur für das nichtprüfbare Programm, die beweist, dass das Programm von einer vertrauenswürdigen Quelle erzeugt wurde, indirekt prüfbar ist.
In der bevorzugten Ausführungsform ist jedes prüfbares Programm ein architekturneutrales Programm, das in einer Objektklasse ausgebildet ist und eine digitale Signatur aufweist, die eine Nachrichtenkurzfassung enthält, die diesem Programm eindeutig zugeordnet ist.
Nichtprüfbare Programme sind in Objektklassen ausgebildet, die ein Schlüsselwort enthalten, das anzeigt, dass das Programm (als Verfahren bezeichnet) kein prüfbares Programm ist. In der bevorzugten Ausführungsform sind die nichtprüfbaren Programme im Allgemeinen architekturspezifische compilierte Programme, die mit Unterstützung eines Compilers erzeugt werden. Eine jede solche Objektklasse enthält:

– den compilierten architekturspezifischen Code;
– wenn ein entsprechendes architekturneutrales Programm vorhanden ist (was manchmal nicht der Fall ist), Informationen, die das entsprechende architekturneutrale Programm identifizieren, einschließlich einer Kopie der Nachrichtenkurzfassung des entsprechenden architekturneutralen Programms;
– eine digitale Signatur von der vertrauenswürdigen "Compilierungspartei", die die Objektklasse erzeugt hat (z. B. durch Ausführen einer Compilierung eines Quellprogramms), die unter Verwendung des privaten Verschlüsselungsschlüssels der Compilierungspartei signiert worden ist; und
– wenn der Code in der Objektklasse von einem Compiler erzeugt wurde, eine digitale Signatur vom Compiler selbst, die unter Verwendung des privaten Verschlüsselungsschlüssels des Compilers signiert worden ist.

Eine im Allgemeinen verfügbare, vertrauenswürdige Ablage von öffentlichen Verschlüsselungsschlüsseln, die manchmal als Namensdienst bezeichnet wird, hält die öffentlichen Schlüssel für den Compiler und die vertrauenswürdige Compilierungspartei. Unter Verwendung dieser öffentlichen Verschlüsselungsschlüssel können alle Empfänger der Objektklassen, die nicht überprüfbare Programme aufweisen, die digitalen Signaturen in der Objektklasse entschlüsseln, um zu prüfen, ob die Objektklasse von einer vertrauenswürdigen Partei erzeugt wurde, um zu prüfen, dass der nicht prüfbare Programmcode in der Objektklasse vom angegebenen Compiler (falls zutreffend) erzeugt worden ist, und um ferner die Identität des entsprechenden architekturneutralen Programms (falls zutreffend) zu prüfen. Wenn der nichtprüfbare Programmcode in der Objektklasse ein entsprechendes prüfbares Programm aufweist, kann optional der potenzielle Benutzer der Objektklasse die Programmprüfeinrichtung verwenden, um die korrekte Operation des entsprechenden prüfbaren Programms vor der Ausführung des nichtprüfbaren Programmcodes in der Objektklasse zu prüfen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Im Folgenden werden Beispiele der Erfindung mit Bezug auf die Zeichnungen beschrieben, in welchen:
1 ein Blockdiagramm eines verteilten Computersystems ist, das eine bevorzugte Ausführungsform der vorliegenden Erfindung enthält;
2 die Struktur eines architekturneutralen Programms gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt;
3 die Struktur eines compilierten architekturspezifischen Programms, das gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung erzeugt worden ist, zeigt; und
4 ein Objekt und eine zugehörige Objektklasse gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
In 1 ist ein Computernetzwerk 100 mit vielen Client-Computern 102, einem Servercomputer 104 und einer vertrauenswürdigen Schlüsselablage 106 gezeigt. Die Client-Computer 102 sind untereinander und mit dem Server-Computer 104 und der Vertrauensschlüsselablage 106 über eine Netzkommunikationsverbindung 108 verbunden. Die Netzkommunikationsverbindung kann ein lokales Netzwerk oder ein Weitbereichsnetzwerk, das Internet, eine Kombination solcher Netzwerke oder ein bestimmter anderer Typ von Netzwerkkommunikationsverbindung sein.
Obwohl die meisten Client-Computer 102 Tischcomputer sind, wie z. B. Sun-Arbeitsstationen, IBM-kompatible Computer und Macintosh-Computer, kann nahezu jeder Typ von Computer ein Client-Computer sein. Jeder dieser Client-Computer enthält eine CPU 110, eine Benutzerschnittstelle 112, einen Speicher 114 und eine Netzwerkkommunikationsschnittstelle 116. Die Netzwerkkommunikationsschnittstelle ermöglicht den Client-Computern, miteinander, mit dem Server-Computer 104 und mit der vertrauenswürdigen Schlüsselablage 108 über die Netzwerkkommunikationsverbindung 106 zu kommunizieren.
Der Speicher 114 jedes Client-Computers 102 speichert ein Betriebssystem 118, einen Netzwerkkommunikationsmanager 120, eine ANProgramm-(Architekturneutrales-Programm)-Ausführungseinrichtung 122, eine ASProgramm-(Architekturspezifisches-Programm)-Ausführungseinrichtung 124, sowie eine ANProgramm-Integritätsprüfeinrichtung 126, eine ANProgramm-Compilierungsvorbereitungseinrichtung 128, einen Signaturgenerator 130, eine Signaturprüfeinrichtung 132, eine Compilierungsinformations-(Complnfo)-Prüfeinrichtung 134, eine Objektklassenladeeinrichtung 136, einen Benutzeradressraum 138, eine Ablage für vertrauenswürdige Objektklassen 140, eine Ablage für nichtvertrauenswürdige Objektklassen 142 und Listen 144 von bekannten, vertrauenswürdigen Compilierungsparteien und vertrauenswürdigen Compilern. Das Betriebssystem läuft auf der CPU 110 und kontrolliert und koordiniert den Lauf der Programme 120–136 auf der CPU in Reaktion auf Befehle, die von einem Benutzer mittels der Benutzerschnittstelle 112 erteilt werden.
Die ANProgramm-Ausführungseinrichtung 122 jedes Client-Computers 102 führt ANProgramme in den Objektklassen aus, die in den Ablagen 140 und 142 für vertrauenswürdige und nichtvertrauenswürdige Objektklassen gespeichert sind. Außerdem sind die ANProgramme in einer ANSprache geschrieben, für die der Benutzer vordefinierte Integritätskriterien einrichten kann, wie z. B. Stapel- und Datennutzungsbeschränkungen, so dass die ANProgramme keine illegalen Kleinprogramme ausführen. Somit kann die Integrität der ANProgramme von der ANProgramm-Integritätsprüfeinrichtung 126 vor der Ausführung direkt geprüft werden, indem ermittelt wird, ob das Programm die vordefinierten Integritätskriterien erfüllt. Diese ANProgramme werden daher als in der Integrität prüfbare ANProgramme betrachtet.
In der bevorzugten Ausführungsform sind die in der Integrität prüfbaren ANProgramme in der Java-Bytecode-Sprache geschrieben. Außerdem sind die ANProgramm-Ausführungseinrichtung 122 und die ANProgramm-Prüfeinrichtung 124 jeweils ein Java-Bytecode-Programminterpreter und eine Java-Bytecode-Programmprüfeinrichtung, die jeweils die Java-Bytecode-Programme ausführen und prüfen. Die Java-Bytecode-Prüfeinrichtung und der Interpreter sind Produkte von Sun Microsystems, Inc.
Jeder Client-Computer 102 weist jedoch eine zugehörige spezifische Architektur auf, "für die Programme in einer entsprechenden ASSprache geschrieben sein können und von der ASProgramm-Ausführungseinrichtung 122 ausgeführt werden. Die ASSprache erfordert nicht, dass in der ASSprache geschrieben ANProgramme die vordefinierten Integritätskriterien der AN-Sprache erfüllen. Als Ergebnis können die ASProgramme Kleinprogramme ausführen, die von den ANProgrammen nicht ausgeführt werden können, da sie nicht durch die Beschränkungen belastet sind, die durch die vordefinierten Integritätskriterien der ANSprache auferlegt werden. Ungünstigerweise bedeutet dies jedoch auch, dass ihre Integrität von der ANProgramm-Integritätsprüfeinrichtung 126 nicht direkt geprüft werden kann und sie somit als in der Integrität nicht prüfbar betrachtet werden.
Wie vorher erwähnt worden ist, läuft trotzdem ein ANProgramm weniger effizient als das gleiche in eine ASSprache compilierte Programm. Der Benutzer eines Client-Computers 102 kann daher wünschen, ein ANProgramm zu haben, das vom Server-Computer 104 für die ASSprache compiliert worden ist, die dem Client-Computer des Benutzers zugeordnet ist, so dass das compilierte ASProgramm dort mittels der ASProgramm-Ausführungseinrichtung 124 ausgeführt werden kann. Oder der Benutzer kann wünschen, das ANProgramm zu haben, das für die ASSprache compiliert worden ist, die anderen Client-Computern zugeordnet ist, wenn die compilierten ASProgramme zu den ASProgramm-Ausführungseinrichtungen 124 anderer Client-Computer verteilt und von diesem ausgeführt werden sollen.
Vorbereitung eines architekturneutralen Programms für die Compilierung
Wenn, wie in den 1 und 2 gezeigt ist, eine Ursprungspartei (OrigParty) wünscht, ein vom Server-Computer 104 compiliertes ANProgramm 200 zu haben, gibt die Ursprungspartei einen Befehl mittels der Benutzerschnittstelle 112 aus, um die ANProgramm-Compilierungsvorbereitungseinrichtung 128 aufzurufen, und weist diese an, das ANProgramm für die Compilierung vorzubereiten. Das ANProgramm kann sich in einer Objektklasse befinden, die in einer der Ablagen 140 oder 142 für vertrauenswürdige oder nichtvertrauenswürdige Objektklasse enthalten ist. Tabelle 1 enthält eine Pseudocodedarstellung der Prozedur, die von der ANProgramm-Compilierungsvorbereitungseinrichtung 128 verwendet wird, um das ANProgramm für die Compilierung durch den Server-Computer 104 vorzubereiten. Der in den Tabellen 1–3 verwendete Pseudocode verwendet universelle Computersprachenkonventionen. Obwohl der hier verwendete Pseudocode nur für die Zwecke dieser Beschreibung erfunden worden ist, ist er so gestaltet, dass er von jedem erfahrenen Computerprogrammierer verstanden werden kann.
Wie in den 1 und 2 und in Tabelle 1 gezeigt ist, ruft eine ANProgramm-Compilierungsvorbereitungseinrichtung 128 zuerst die ANProgramm-Integritätsprüfeinrichtung 126 auf und weist diese an, die Integrität des ANProgrammcodes 202 des ANProgramms 200 zu prüfen. Dies wird durchgeführt, um sicherzustellen, dass der ANProgrammcode die vordefinierten Integritätskriterien der ANSprache erfüllt, bevor er zum Server-Computer 104 zur Compilierung gesendet wird. Wenn der ANProgrammcode die vordefinierten Integritätskriterien nicht erfüllt, sendet die ANProgramm-Integritätsprüfeinrichtung ein Fehlerergebnis an die ANProgramm-Compilierungsvorbereitungseinrichtung. In Reaktion hierauf bricht die ANProgramm-Compilierungsvorbereitungseinrichtung die Compilierungsvorbereitungsprozedur ab und erzeugt eine geeignete Nachricht, die dies anzeigt.
Wenn jedoch der ANProgrammcode 202 die vordefinierten Integritätskriterien erfüllt, sendet die ANProgramm-Integritätsprüfeinrichtung 126 ein Genehmigt-Ergebnis an die ANProgramm-Compilierungsvorbereitungseinrichtung 128. Die ANProgramm-Compilierungsvorbereitungseinrichtung ruft anschließend den Signaturgenerator 130 auf und weist diesen an, die digitale Signatur der Ursprungspartei (DigitalSignatur_OP) 210 zu erzeugen, die überprüft werden kann, um sicherzustellen, dass das ANProgramm 200 von der vertrauenswürdigen Ursprungspartei erzeugt worden ist. Der Signaturgenerator erzeugt die DigitalSignatur_OP, indem er zuerst eine Nachrichtenkurzfassung (MD_OP) 212 des ANProgrammcodes 202 erzeugt. Er tut dies durch Berechnen einer Hash-Funktion, HashFunction_OP, für die Datenbits des ANProgrammcodes. Die verwendete Hash-Funktion kann entweder eine vorgegebene Hash-Funktion oder eine von der Ursprungspartei ausgewählte Hash-Funktion sein. Für die Zwecke dieses Dokuments entspricht Hash-Function_OP der Ursprungspartei, da sie für die DigitalSignatur_OP der Ursprungspartei verwendet wurde.
Der Signaturgenerator 130 verschlüsselt anschließend die erzeugte Nachrichtenkurzfassung (MD_OP) 212 und die ID der HashFunktion_OP (HashFunktion_OP-ID) 214 mit dem privaten Verschlüsselungsschlüssel der Ursprungspartei (OrigParty's PrivateKey). Der Signaturgenerator fügt anschließend die ID der Ursprungspartei 216 im Klartext am Ende der verschlüsselten Elemente 212 und 214 an, um die DigitalSignatur_OP zu bilden. Der Privatschlüssel der Ursprungspartei und die ID werden von der Ursprungspartei mit der Benutzerschnittstelle 112 bereitgestellt.
Nachdem die DigitalSignatur_OP 210 erzeugt worden ist, hängt die ANProgramm-Compilierungsvorbereitungseinrichtung 128 diese an den ANProgrammcode 202 an. Anschließend erzeugt die ANProgramm-Compilierungsvorbereitungseinrichtung eine Nachricht, dass das ANProgramm 200 für die Compilierung durch den Server-Computer 104 vorbereitet worden ist.
Die Ursprungspartei gibt anschließend mittels der Benutzerschnittstelle 112 einen Befehl an den Netzwerkkommunikationsmanager 120 aus, das ANProgramm 200 zum Server-Computer 104 zu senden, zusammen mit Argumenten, die die architekturspezifische Sprache spezifizieren, in die das Programm zu compilieren ist (ASSprache-ID), und dem Compiler, der zu verwenden ist (Compiler-ID). Der Netzwerkkommunikationsmanager empfängt das ANProgramm von der Ablage 140 oder 142 für vertrauenswürdige bzw. nichtvertrauenswürdige Objektklassen, in der es sich befindet, und liefert es an die Netzwerkkommunikationsschnittstelle 116. Der Netzwerkkommunikationsmanager weist anschließend die Netzwerkkommunikationsschnittstelle an, das ANProgramm zusammen mit den spezifischen Argumenten zum Server-Computer zu senden.
Compilieren eines architekturneutralen Programms
Das gesendete ANProgramm 200 wird anschließend am Server-Computer 104 empfangen. Der Server-Computer enthält eine CPU 150, eine Benutzerschnittstelle 152, einen Speicher 154 und eine Netzwerkkommunikationsschnittstelle 156. Die Netzwerkkommunikationsschnittstelle ermöglicht dem Server-Computer mit den Client-Computern 102 und der Ablage 106 für vertrauenswürdige Schlüssel über die Netzwerkkommunikationsverbindung 108 zu kommunizieren.
Der Speicher 154 des Server-Computers 104 speichert ein Betriebssystem 158, einen Netzwerkkommunikationsmanager 160, einen ANProgramm-Compiler 162, eine Signaturprüfeinrichtung 164, eine ANProgramm-Integritätsprüfeinrichtung 166, einen Signaturgenerator 168, eine ANProgramm-Ablage 170 und eine ANProgramm-Ablage 172. Das Betriebssystem läuft auf der CPU 150 und kontrolliert und koordiniert den Lauf der Programme 160–168 auf der CPU in Reaktion auf Befehle, die von einer Compilie rungspartei (CompParty) mittels der Benutzerschnittstelle 152 erteilt werden.
Die Netzwerkkommunikationsschnittstelle 156 empfängt das ANProgramm 200 und teilt dem Netzwerkkommunikationsmanager 160 mit, dass dies geschehen ist. In Reaktion hierauf platziert der Netzwerkkommunikationsmanager das empfangene ANProgramm in der ANProgramm-Ablage 170. Wenn der Server 104 als automatischer Compilerdienst eingerichtet ist, wird dies vom Netzwerkkommunikationsmanager 160 automatisch durchgeführt. Ansonsten wird das ANProgramm vom Netzwerkkommunikationsmanager in die Ablage 170 bewegt, wenn die Compilierungspartei einen Befehl mittels der Benutzerschnittstelle erteilt.
Anschließend wird entweder automatisch oder bei der Ausgabe eines Befehls von der Compilierungspartei mittels der Benutzerschnittstelle 252 der ANProgramm-Compiler 162 aufgerufen, um das ANProgramm 200 zu compilieren. Tabelle 2 enthält eine Pseudocodedarstellung der Compilierungsprozedur, die vom ANProgramm-Compiler verwendet wird, um das ANProgramm zu compilieren.
Wie in den 1–2 und Tabelle 2 gezeigt ist, ruft der ANProgramm-Compiler 162 zuerst die Signaturprüfeinrichtung 164 auf, um die DigitalSignatur_OP 210 im empfangenen ANProgramm 200 zu prüfen, um somit zu bestätigen, dass die DigitalSignatur_OP 210 wirklich die Signatur der Ursprungspartei für das ANProgramm ist (im Gegensatz z. B. zu einer gefälschten Signatur oder der Ursprungsparteisignatur für eine bestimmte andere Version des ANProgramms). Genauer verwendet die Signaturprüfeinrichtung die Klartext-Ursprungspartei-ID 216 im empfangenen ANProgramm, um den öffentlichen Schlüssel der Ursprungspartei von der Ablage 106 für vertrauenswürdige Schlüssel zu erhalten. Anschließend entschlüsselt die Signaturprüfeinrichtung die verschlüsselte MD_OP 212 und die HashFunktion_OP-ID 214 in der DigitalSignatur_OP unter Verwendung des öffentlichen Verschlüsselungsschlüssels der Ursprungspartei (OrigParty's PublicKey).
Als Nächstes erzeugt die Signaturprüfeinrichtung 164 eine Testnachrichtkurzfassung (TestMD_OP), die mit der entschlüsselten MD_OP 212 übereinstimmen sollte, durch Berechnen der entsprechenden HashFunktion_OP für den ANProgrammcode 202 des empfangenen ANProgramms 200. Die HashFunktion_OP-ID 214 in der entschlüsselten DigitalSignatur_OP wird verwendet, um die geeignete HashFunktion_OP zu identifizieren, die zu verwenden ist. Die entschlüsselte MD_OP und die erzeugte TestMD_OP werden anschließend verglichen, um die DigitalSignatur_OP 210 zu prüfen.
Wenn die MD_OP 212 und die TestMD_OP nicht übereinstimmen, sendet die Signaturprüfeinrichtung 162 ein Fehler-Ergebnis zum ANProgramm-Compiler 162 zurück. In Reaktion hierauf bricht der ANProgramm-Compiler die Compilierungsprozedur ab und erzeugt eine geeignete Nachricht.
Wenn andererseits die MD_OP und die TestMD_OP übereinstimmen, sendet die Signaturprüfeinrichtung 162 ein Genehmigt-Ergebnis zum ANProgramm-Compiler 162 zurück und der ANProgramm-Compiler ruft die ANProgramm-Integritätsprüfeinrichtung 166 auf. Er weist die ANProgramm-Integritätsprüfeinrichtung an, die Integrität des ANProgrammcodes 202 des empfangenen ANProgramms 200 zu prüfen. Dies wird in der gleichen Weise und für den gleichen Zweck durchgeführt, wie vorher in dem Abschnitt beschrieben worden ist, der die Vorbereitung des ANProgramms für die Compilierung beschrieben hat. Wenn somit der ANProgrammcode die vordefinierten Integritätskriterien nicht erfüllt, sendet die ANProgramm-Integritätsprüfeinrichtung ein Fehler-Ergebnis zum ANProgramm-Compiler zurück. In Reaktion hierauf bricht der ANProgramm-Compiler die Compilierungsprozedur ab und erzeugt eine entsprechende Nachricht, die dies anzeigt.
Wenn jedoch der ANProgrammcode 202 des empfangenen ANProgramms 200 die vordefinierten Integritätskriterien erfüllt, sendet die ANProgramm-Integritätsprüfeinrichtung 166 ein Genehmigt-Ergebnis zum ANProgramm-Compiler 162 zurück. Der ANProgramm-Compiler compiliert anschließend den ANProgrammcode in die ASSprache, die von der ASSprache-ID identifiziert wird, welche von der Ursprungspartei spezifiziert worden ist. Wie in den 1–3 und Tabelle 2 gezeigt ist, platziert der Compiler den ANProgrammcode 202, die DigitalSignatur_OP 210 und den compilierten ANProgrammcode 302 in einem ANProgramm 300, das in der ANProgramm-Ablage 102 gespeichert wird.
Der ANProgramm-Compiler 162 ruft anschließend den Signaturgenerator 168 auf und weist diesen an, die ANProgramm-Compilerdigitalsignatur (DigitalSignatur_C) 320 zu erzeugen, die überprüft werden kann, um sicherzustellen, dass das ANProgramm 300 mit dem vertrauenswürdigen ANProgramm-Compiler compiliert worden ist. Dies wird in einer Weise ähnlich derjenigen bewerkstelligt, die vorher für die Erzeugung der Digital-Signatur_OP beschrieben worden ist. In diesem Fall ist jedoch der Satz der signierten Informationen der ASProgrammcode und die DigitalSignatur_OP. Eine weitere vorgegebene HashFunktion mit einer entsprechenden Hash-Funktion_C-ID 324 kann verwendet werden, um die Nachrichtenkurzfassung MD_C 322 des mittels der DigitalSignatur_C zu signierenden Informationssatzes zu erzeugen, wobei der private Verschlüsselungsschlüssel des ANProgramm-Compilers (Compiler's PrivateKey) verwendet wird, um die MD_C und die HashFunktion_C-ID zu verschlüsseln, wobei der Identifizierer des ANProgramm-Compilers (Compiler-ID) im Klartext am Ende der verschlüsselten MD_C und der HashFunktion_C angefügt wird. Der Privatschlüssel und die ID des Compilers werden vom ANProgramm-Compiler zur Verfügung gestellt.
Der ANProgramm-Compiler 192 ruft den Signaturgenerator 168 ein zweites Mal auf, um die Digitalsignatur der Compilierungspartei (DigitalSignatur_CP) 312 zu erzeugen, die von den Endbenutzern überprüft werden kann, um sicherzustellen, dass das ANProgramm 300 von der vertrauenswürdigen Compilierungspartei erzeugt wurde. Dies wird in ähnlicher Weise bewerkstelligt, wie vorher für die Erzeugung der DigitalSignatur_OP beschrieben worden ist (in dem Abschnitt, der die Vorbereitung eines ANProgramms für die Compilierung beschrieben hat). Hierbei wird jedoch die Nachrichtenkurzfassung (MD_CP) 314, die für die DigitalSignatur_CP erzeugt wird, durch Berechnen einer vorgegebenen oder ausgewählten HashFunktion (HashFunktion_CP) für die Datenbits des ASProgrammcodes, der DigitalSignatur_OP und der DigitalSignatur_C berechnet. Ähnlich der HashFunktion_OP entspricht für die Zwecke dieser Offenbarung die HashFunktion_CP der Compilierungspartei, da sie für die DigitalSignatur_CP der Compilierungspartei verwendet wurde.
Der Signaturgenerator 168 verschlüsselt anschließend die MD_CP 314 und die ID der HashFunktion_CP (HashFunktion_CP-ID) 316 mit dem privaten Ver schlüsselungsschlüssel der Compilierungspartei (CompParty's PrivateKey). Der Signaturgenerator fügt anschließend den Identifizierer der Compilierungspartei (CompParty's ID) 318 im Klartext am Ende der verschlüsselten Elemente 314 und 316 an, um die DigitalSignatur_CP 312 zu bilden. Der Privatschlüssel der Compilierungspartei und die ID werden von der Compilierungspartei mittels der Benutzerschnittstelle 152 bereitgestellt.
Nachdem die DigitalSignatur_C 320 und die DigitalSignatur_CP 312 erzeugt worden sind, hängt der ANProgramm-Compiler 162 diese an den ASProgrammcode 302 an, so dass die resultierende compilierte ASProgramm-Datei oder das Objekt die folgenden Komponenten enthält:
ANProgrammcode,
DigitalSignatur_OP,
ASProgrammcode,
DigitalSignatur_C, und
DigitalSignatur_CP.
Anschließend erzeugt der ANProgramm-Compiler eine Nachricht, dass das ANProgramm 200 compiliert worden ist, um das ASProgramm 300 zu bilden, und bereit ist, zur Ursprungspartei gesendet zu werden.
Die Compilierungspartei verwendet anschließend den Netzwerkkommunikationsmanager 160, um das ASProgramm 300 zum Ursprungspartei-Client-Computer 102 zu übermitteln. Der Netzwerkkommunikationsmanager bewerkstelligt dies durch Empfangen des ASProgramms von der ASProgramm-Ablage 172, in der es sich befindet, und stellt es der Netzwerkkommunikationsschnittstelle 156 zur Verfügung. Der Netzwerkkommunikationsmanager weist anschließend die Netzwerkkommunikationsschnittstelle an, das ASProgramm zum Ursprungspartei-Client-Computer zu senden.
Objekt- und Objektklassenerzeugung und Verteilung
Das gesendete ASProgramm 300 wird anschließend von der Kommunikationsschnittstelle 116 des Ursprungspartei-Client-Computers empfangen und teilt dem Netzwerkkommunikationsmanager 120 mit, dass dies geschehen ist. In Reaktion hierauf gibt die Ursprungspartei einen Befehl mittels der Benutzerschnittstelle 252 aus, um den Netzwerkkommunikationsmanager anzuweisen, das empfangene ASProgramm von der Netzwerkkommunikationsschnittstelle zu holen, was den Netzwerkkommunikationsmanager veranlasst, das empfangene ASProgramm in der Ablage 142 für nichtvertrauenswürdige Objektklassen des Ursprungspartei-Client-Computers zu platzieren. Sobald dies bewerkstelligt ist, kann die Ursprungspartei das empfangene ASProgramm als neue Objektklasse mit nur einem Verfahren behandeln (d. h. den compilierten Programmcode), oder sie kann eine Objektklasse erzeugen, die das ASProgramm 300 sowie andere ANProgramme und ASProgramme enthält.
4 zeigt eine typische Objektklasse 400 gemäß der vorliegenden Erfindung. Die Objektklasse kann ein oder mehrere ASProgramme 402 und/oder ein oder mehrere ANProgramme 404 sowie eine virtuelle Funktionstabelle 410 enthalten. Für jedes ASProgramm enthält die virtuelle Funktionstabelle einen entsprechenden Identifizierer (native_ASProgramm-ID) 412, der anzeigt, dass dies ein ASProgramm (d. h. ein natives Programm) ist, das nicht in der ANSprache geschrieben ist, sowie einen entsprechenden Zeiger (Ptr) 414 auf das native Programm. In ähnlicher Weise enthält die virtuelle Funktionstabelle für jedes ANProgramm einen entsprechenden Identifizierer (ANProgramm-ID) 416 und einen entsprechenden Zeiger 418 auf das ANProgramm. Jedes Objekt 420 dieser Objektklasse enthält einen Objektkopf 422, der auf die Objektklasse 400 zeigt.
Somit kann die Ursprungspartei ein Objekt 420 und eine Objektklasse 400 mit dem ASProgramm 300 erzeugen, das vom Server-Computer 104 als eines der ASProgramme 402 in der Objektklasse empfangen wurde.
Wenn die Ursprungspartei wünscht, ein Objekt und eine Objektklasse, die das ASProgramm 300 und ein ANProgramm enthalten, an verschiedene Ausführungsparteien zu verteilen, gibt die Ursprungspartei einen Befehl mittels der Benutzerschnittstelle 112 aus, um den Netzwerkkommunikationsmanager anzuweisen, diese Elemente zu den Client-Computern 102 der Ausführungsparteien zu senden. Der Netzwerkkommunikationsmanager bewerkstelligt dies durch Empfangen derselben von der Ablage 142 für die nichtvertrauenswürdigen Objektklassen, in der diese angeordnet sind, und liefert diese an die Netzwerkkommunikationsschnittstelle 116 mit geeigneten Sendebefehlen. Alternativ kann der Netzwerkkommunikationsmanager der Ursprungspartei auf eine Anforderung antworten, die von einer Ausführungspartei nach einer Kopie einer spezifizierten Objektklasse 400 gestellt worden ist.
Ausführung archtitekturneutraler Programme und architekturspezifischer Programme in einer Objektklasse
Die Netzwerkkommunikationsschnittstelle 156 des Client-Computers 102 empfängt das gesendete Objekt und die Objektklasse und teilt dem Netzwerkkommunikationsmanager 160 mit, dass dies geschehen ist. In Reaktion hierauf gibt die Ausführungspartei einen Befehl mittels der Benutzerschnittstelle 112 aus, um den Netzwerkkommunikationsmanager anzuweisen, das empfangene Objekt und die Objektklasse von der Netzwerkkommunikationsschnittstelle zu holen. Der Netzwerkkommunikationsmanager speichert anschließend das empfangene Objekt und die Objektklasse in der Ablage 142 für nicht vertrauenswürdige Objektklassen.
Die Ablage 142 für nicht vertrauenswürdige Objektklassen jedes Client-Computers 102 enthält die Objekte und deren zugehörige Objektklassen, die nicht vertrauenswürdig sind. Diese Objektklassen sind nicht vertrauenswürdig, da irgendwelche ANProgramme, die sie enthalten, noch nicht bezüglich ihrer Integrität geprüft worden sind, und irgendwelche ASProgramme, die sie enthalten, weder hinsichtlich ihrer Quelle geprüft worden sind noch geprüft wurden, als sie aus dem geeigneten ANProgramm compiliert wurden.
Die Ablage 140 für vertrauenswürdige Objektklassen jedes Client-Computers enthält die Objekte und deren Objektklassen, die vertrauenswürdig sind. Diese Objektklassen sind vertrauenswürdig, da irgendwelche ANProgramme, die sie enthalten, bereits hinsichtlich ihrer Integrität von der ANProgramm-Integritätsprüfeinrichtung 136 geprüft worden sind, sowie irgendwelche ASProgramme, die sie enthalten, als vertrauenswürdig bestätigt worden sind. Tatsächlich brauchen einige oder alle Objektklassen in der Ablage 140 für vertrauenswürdige Objektklassen keine Digitalsignaturen aufweisen, da diese Objektklassen vertrauenswürdig sind, weshalb kein Grund besteht, Integritätsprüfungen für die Verfahren in diesen Objektklassen durchzuführen.
Es ist wünschenswert, eine Objektklasse zu haben, die hauptsächlich ANProgramme enthält, jedoch auch ASProgramme enthalten kann, so dass im Wesentlichen alle legitimen Kleinprogramme mit der Objektklasse ausgeführt werden können, wie vorher vorgeschlagen worden ist. Die ANProgramm-Ausführungseinrichtung 122 ist daher fähig, in der Integrität prüfbare ANProgramme auszuführen und die ASProgramm-Ausführungseinrichtung aufzurufen, um in der Integrität nicht prüfbare ASProgramme auszuführen, die entweder (1) sich in vertrauenswürdigen Objektklassen in der Ablage 140 für vertrauenswürdige Objektklassen befinden, oder (2) sich in nichtvertrauenswürdigen Objektklassen in der Ablage 142 für nichtvertrauenswürdige Objektklassen befinden und überprüfbare Informationen der DigitalSignatur_OP, der DigitalSignatur_CP und der DigitalSignatur_C aufweisen, so dass im Wesentlichen alle legitimen Kleinprogramme ausgeführt werden können. Auf diese Weise werden ASProgramme nichtvertrauenswürdiger Objektklassen, die keine Informationen der DigitalSignatur_OP, der Digital-Signatur_CP und der DigitalSignatur_C aufweisen, oder deren Digitalsignaturen nicht geprüft werden können, an einer Ausführung gehindert. Tabelle 3 enthält eine Pseudocodedarstellung der Ausführungsprozedur, die von der ANProgramm-Ausführungseinrichtung verwendet wird.
Wie in den 1–4 und in Tabelle 3 gezeigt ist, kann beim Client-Computer 102 einer Ausführungspartei (z. B. der Ursprungspartei oder einer weiteren Partei) die ANProgramm-Ausführungseinrichtung 124 ein ANProgramm ausführen, das versucht, ein Verfahren in einer spezifizierten Objektklasse aufzurufen. Der Verfahrensaufruf wird anfangs von der Objektklassenladeeinrichtung 136 gehandhabt, die bestimmt, ob die Objektklasse bereits geladen worden ist. Wenn die Objektklasse bereits in den Benutzeradressraum 138 der Ausführungspartei geladen worden ist, führt die ANProgramm-Ausführungseinrichtung 122 das aufgerufene Verfahren aus, wenn das aufgerufene Verfahren ein ANProgramm ist, während die ASProgramm-Ausführungseinrichtung 124 das aufgerufene Verfahren ausführt, wenn das aufgerufene Verfahren ein ASProgramm ist.
Wenn jedoch die Objektklasse noch nicht in den Adressraum 138 der Ausführungspartei geladen worden ist, lädt die Objektklassenladeeinrichtung 136 die Objektklasse in den Adressraum der Ausführungspartei und bestimmt, ob die Ausführung des aufgerufenen Verfahrens zulässig ist. Wenn z. B. die Objektklasse aus der Ablage 140 für vertrauenswürdige Objektklassen geladen worden ist, wird die Ausführung des aufgerufenen Verfahrens erlaubt und die Ausführungsprozedur wird aufgerufen. Die Ausführungsprozedur (siehe Tabelle 3) ruft die ANProgramm-Ausfühungseinrichtung auf, wenn das aufgerufene Verfahren ein ANProgramm ist, und ruft ansonsten die ASProgramm-Ausführungseinrichtung 124 auf, um das aufgerufene Verfahren auszuführen.
Wenn jedoch die Objektklasse aus der Ablage 142 für nichtvertrauenswürdige Objektklassen geladen wurde, untersucht die Klassenladeeinrichtung 136 den Objektkopf des Objekts, um zu bestimmen, ob es eine Objektklasse ist, die irgendwelche ASProgramme enthält. Dies bewerkstelligt sie, indem sie ermittelt, ob irgendwelche native_ASProgramm-IDs in der virtuellen Funktionstabelle des Objekts vorhanden sind.
Wenn keine ANProgramme in der Objektklasse vorhanden sind, ruft die Klassenladeeinrichtung 136 die ANProgramm-Integritätsprüfeinrichtung 136 auf, um die Integrität der ANProgramme in der Objektklasse zu prüfen. Dies wird in der gleichen Weise und für die gleichen Zwecke bewerkstelligt, wie vorher für die Überprüfung der Integrität des ANProgramms 200 beschrieben wurde (in dem Abschnitt, in dem die Compilierung eines ANProgramms beschrieben worden ist). Wenn daher die Integrität irgendeines der ANProgramme nicht verifiziert wird, gibt die ANProgramm-Integritätsprüfeinrichtung an die Klassenladeeinrichtung ein Fehler-Ergebnis zurück, wobei die Klassenladeeinrichtung die Klassenladeprozedur abbricht und eine geeignete Nachricht erzeugt, die dies anzeigt. Wenn jedoch die ANProgramm-Integritätsprüfeinrichtung ein Genehmigt-Ergebnis zurücksendet, das anzeigt, dass alle ANProgramme der Objektklasse überprüft worden sind, ermöglicht die Klassenladeeinrichtung die Ausführung des aufgerufenen Verfahrens.
Wenn es irgendwelche ANProgramme in der Objektklasse gibt, ruft die Klassenladeeinrichtung 136 die Signaturprüfeinrichtung 132 auf, um die Compilersignatur DigitalSignatur_C und die Kompilierungsparteisignatur DigitalSignatur_CP zu prüfen. Wenn irgendeines der ASProgramme nicht eine DigitalSignatur_CP und eine DigitalSignatur_C enthält, kann die Integrität der Äsprogrammquelle nicht überprüft werden, weshalb die Signaturprüfeinrichtung ein Fehlerergebnis an die ANProgramm-Ausführungseinrichtung zurücksendet. In Reaktion hierauf bricht die Klassenladeeinrichtung die Objektklassenladeprozedur ab und erzeugt eine geeignete Nachricht, dass dies aufgetreten ist.
Wenn ferner alle ASProgramme in der Objektklasse eine DigitalSignatur_CP und eine DigitalSignatur_C enthalten, werden die Identitäten der Compilierungspartei und des Compilers, wie in diesen zwei digitalen Signaturen angegeben, mit den Listen 144 (siehe 1) von bekannten, vertrauenswürdigen Compilerparteien und vertrauenswürdigen Compilern verglichen. Wenn irgendeines der ASProgramme in der Objektklasse von einer Compilierungspartei oder einen Compiler compiliert wurde, die nicht in dem Satz der bekannten, vertrauenswürdigen Compilerparteien und vertrauenswürdigen Compiler enthalten ist, wird die Klassenladeprozedur abgebrochen und die Ausführung des aufgerufenen Verfahrens wird somit blockiert. Wenn in ähnlicher Weise die in irgendeinem der ASProgramme identifizierte ASSprache nicht mit der ASSprache übereinstimmt, die von der ASProgramm-Ausführungseinrichtung 124 verwendet wird, wird die Klassenladeprozedur abgebrochen.
Wenn jedoch alle ASProgramme in der Objektklasse eine DigitalSignatur_CP und eine DigitalSignatur_C enthalten und die identifizierte Compilierungspartei und der Compiler für alle ASProgramme vertrauenswürdige Compilerparteien und Compiler sind, und die von allen ASProgrammen verwendete ASSprache eine solche ist, die von der ASProgramm-Ausführungseinrichtung verwendet wird, überprüft die Signaturprüfeinrichtung diese Signaturen in ähnlicher Weise, wie vorher für die Überprüfung der DigitalSignatur_OP beschrieben worden ist (in dem Abschnitt, in dem die Compilierung des ANProgramms 200 beschrieben wurde). In diesem Fall werden jedoch die öffentlichen Schlüssel des Compilers und der Compilierungspartei von der Ablage 106 für vertrauenswürdige Schlüssel geholt und dementsprechend verwendet, um die MD_C und die HashFunktion_C-ID in der DigitalSignatur_C und die MD_CP und die HashFunktion_CP-ID in der DigitalSignatur_CP zu entschlüsseln. Ferner werden die Prüfnachrichtenkurzfassungen (TestMD_C und TestMD_CP), die der entschlüsselten MD_CP und der MD_C entsprechen, erzeugt durch Berechnen der Hash-Codes für die Datenbits des ASProgrammcodes plus der DigitalSignatur_OP für die TestMD_C und für die gleichen Datenbits plus der DigitalSignatur_C für die TestMD_CP, gemäß jeweils der HashFunktion_C und der HashFunktion_CP, die durch die entschlüsselte HashFunktion_C-ID und die HashFunktion_CP-ID identifiziert worden sind.
Wenn die DigitalSignatur_C und/oder die DigitalSignatur_CP nicht für jedes ASProgramm verifiziert wird (d. h. MD_C ≠ TestMD_C und/oder MD_CP ≠ TestMD_CP), sendet die Signaturprüfeinrichtung 136 an die Klassenladeeinrichtung 136 ein Fehler-Ergebnis zurück. In Reaktion hierauf bricht die Klassenladeeinrichtung die Klassenladeprozedur ab und erzeugt eine geeignete Nachricht, dass dies aufgetreten ist.
Wenn jedoch sowohl die DigitalSignatur_C als auch die DigitalSignatur_CP für jedes ASProgramm verifiziert worden sind (d. h. MD_C = TestMD_C und MD_CP = TestMD_CP), ruft die ANProgramm-Ausführungseinrichtung 124 erneut die Signaturprüfeinrichtung 132 auf, um die Ursprungsparteisignaturen (DigitalSignatur_OP) für die ANProgramme zu prüfen, aus denen die ASProgramme compiliert wurden. Um die Ursprungspartei-Digitalsignaturen zu prüfen, wird die jeweilige DigitalSignatur_OP in der gleichen Weise geprüft, wie vorher in dem Abschnitt beschrieben worden ist, der sich auf die Compilierung des ANProgramms 200 bezieht.
Wenn die DigitalSignatur_OP jedes der ANProgramme, aus dem die ASProgramme compiliert wurden, geprüft wird, ruft die Klassenladeeinrichtung die ANProgramm-Integritätsprüfeinrichtung auf, um die Integrität jedes ANProgramms in der Objektklasse und der ANProgramme, aus denen die ASProgramme compiliert wurden, zu prüfen. Dies wird in der gleichen Weise bewerkstelligt, wie vorher beschrieben worden ist. Wenn die Integrität irgendeines dieser ANProgramme nicht verifiziert wird, sendet die ANProgramm-Integritätsprüfeinrichtung an die Klassenladeeinrichtung ein Fehler-Ergebnis zurück, welche die Klassenladeprozedur abbricht und eine geeignete Nachricht erzeugt.
Wenn jedoch die Integrität aller ANProgramme verifiziert worden ist, sendet die ANProgramm-Integritätsprüfeinrichtung 126 ein Genehmigt-Ergebnis an die Klassenladeeinrichtung 136 zurück. In Reaktion hierauf ruft die Klassenladeeinrichtung die ANProgramm-Ausführungseinrichtung oder die ASProgramm-Ausführungseinrichtung auf, um das aufgerufene Verfahren entsprechend auszuführen.
Im Hinblick auf das Vorangehende ist die Ausführungspartei überzeugt, dass nur diejenigen nichtvertrauenswürdigen Objektklassen in der nichtvertrauenswürdigen Ablage 142, die in der Integrität prüfbarer ANProgramme oder ANProgramme, deren Digitalsignaturen geprüft werden können, aufweisen, geladen werden und deren Programme ausgeführt werden.
Alternative Ausführungsformen
Einige der Merkmale der obenbeschriebenen Erfindung sind optional. Fachleute werden daher erkennen, dass alternative Ausführungsformen existieren, die diese Merkmale nicht aufweisen.
Zum Beispiel wurde der ANProgramm-Compiler so beschrieben, dass er sowohl eine DigitalSignatur_CP als auch eine DigitalSignatur_C jeweils für die Compilierungspartei und den ANProgramm-Compiler erzeugt. Der ANProgramm-Compiler kann jedoch einfach so konstruiert sein, dass er nur eine dieser digitalen Signaturen erzeugt, um die Überprüfung entweder des zum Compilieren des ANProgramms verwendeten Compilers oder der Compilierungspartei zu ermöglichen.
In ähnlicher Weise wurde die Programmausführungseinrichtung so beschrieben, dass sie die Überprüfung sowohl der DigitalSignatur_CP als auch der DigitalSignatur_C erfordert. Die Programmausführungseinrichtung kann jedoch so konstruiert sein, dass sie die Überprüfung nur einer dieser digitalen Signaturen erfordert und optional die andere Digitalsignatur überprüft, wenn das überprüfte ASProgramm diese enthält. Ferner kann die Programmausführungseinrichtung so konstruiert sein, dass sie den Schritt der Prüfung der Integrität des ANProgramms, das jedem ASProgramm entspricht, auf der Grundlage der Annahme auslässt, dass die Compilierungspartei vertrauenswürdig ist und dass es die Pflicht der Compilierungspartei ist, die Integrität jedes ANProgramms zu prüfen, das in ein ASProgramm compiliert wird, bevor die Compilierung durchgeführt wird.
Wenn die Ausführungspartei die Ursprungspartei ist, weiß die Ausführungspartei, dass sie aktuell das ANProgramm 200 zum Compilierungspartei-Server-Computer zur Compilierung in das ASProgramm 300 gesendet hat. In diesem Fall kann die Klassenladeeinrichtung 136 so konstruiert sein, dass sie die Signaturprüfeinrichtung nicht aufruft, um die DigitalSignatur_OP im ANProgramm zu prüfen. Vielmehr kann die Ausführungspartei einfach die DigitalSignatur_OP in der lokalen Kopie des ANProgramms mit der Digital-Signatur_OP im compilierten ASProgramm vergleichen. Außerdem kann die Klassenladeeinrichtung so konstruiert sein, dass sie nicht die ANProgramm-Integritätsprüfeinrichtung 126 aufruft, um die Integrität des ANProgramms zu prüfen, das einem aufgerufenen ASProgramm entspricht, da die Integrität des ANProgramms während der Vorbereitung für die Compilierungsprozedur vor dem Senden zum compilierenden Server-Computer geprüft worden ist. Alternativ kann die ANProgramm-Compilierungsvorbereitungseinrichtung 128 so konstruiert sein, dass sie die ANProgramm-Integritätsprüfeinrichtung während der Vorbereitung für die Compilierungsprozedur nicht aufruft, da die Integrität sowohl vom Compiler geprüft würde, als auch dann, wenn die Klassenladeeinrichtung die ANProgramm-Integritätsprüfeinrichtung von der Ausführung des entsprechenden ASProgramms aufruft.
TABELLE 1 Pseudocode-Darstellung des Verfahrens zur Vorbereitung architekturneutraler Programme für die Compilierung
TABELLE 2 Pseudocode-Darstellung des Verfahrens zur Compilierung eines ANProgramms und Erzeugung eines ASProgramms
TABELLE 3 Pseudocode-Darstellung des Verfahrens zur Ausführung architekturspezifischer Programme

Claims

Computer, umfassend: eine Vertrauensobjektklassen-Ablage (140), die vertrauenswürdige Objektklassen speichert; eine architekturspezifische Programmausführungseinrichtung (124); einen Benutzeradressraum (138); und eine Klassenladeeinrichtung (136), die eine spezifizierte der Objektklassen zur Ausführung in den Benutzeradressraum lädt, wenn die Ausführung irgendeines Programms in der einen Objektklasse angefordert wird; eine Programmintegrität-Prüfeinrichtung (126), die dafür konfiguriert ist, zu prüfen, ob in einer architekturneutralen Sprache geschriebene Programme vordefinierte Programmintegritätskriterien erfüllen; eine architekturneutrale Programmausführungseinrichtung (122); gekennzeichnet durch: eine Digitalsignatur-Prüfeinrichtung (132), die dafür ausgelegt ist, digitale Signaturen (210) der Ursprungsparteien von Programmen zu prüfen, die in den Programmen enthalten sind; und eine Nichtvertrauensobjektklassen-Ablage (142), die nichtvertrauenswürdige Objektklassen speichert; wobei die Objektklassen jeweils wenigstens ein Programm enthalten, wobei jedes Programm ein Programm umfasst, das aus einer Gruppe ausgewählt ist, die aus (A) architekturneutralen Programmen (200), die in einer architekturneutralen Sprache geschrieben sind, und (B) architekturspezifischen Programmen (300), die in einer architekturspezifischen Sprache geschrieben sind, besteht; die Klassenladeeinrichtung (136) eine Programmsicherheitslogik enthält, die dafür konfiguriert ist, das Laden irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage (140), welche wenigstens ein architekturspezifisches Programm enthält, zu verhindern, solange nicht jedes architekturspezifische Programm in der angeforderten Objektklasse eine digitale Signatur (210) enthält und die digitale Signatur von der Digitalsignatur-Prüfeinrichtung (132) erfolgreich geprüft worden ist.
Computer nach Anspruch 1, wobei die Klassenladeeinrichtung (136) eine Prüfeinrichtungslogik enthält, die dafür konfiguriert ist, die Programmintegritäts-Prüfeinrichtung aufzurufen, um die Integrität jedes architekturneutralen Programms in der angeforderten Objektklasse zu prüfen, wenn die angeforderte Objektklasse nicht in der Vertrauensobjektklassen-Ablage (140) gespeichert ist und wenigstens ein architekturneutrales Programm enthält; und die Programmsicherheitslogik ferner dafür konfiguriert ist, das Laden irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage (140) zu verhindern, wenn die angeforderte Objektklasse wenigstens ein architekturneutrales Programm (200) enthält, dessen Integrität von der Programmintegritäts-Prüfeinrichtung (126) nicht geprüft worden ist.
Computer nach Anspruch 1 oder 2, wobei jede digitale Signatur (210), die einem der architekturspezifischen Programme zugeordnet ist, einen Zeichnungsparteiidentifizierer und eine verschlüsselte Mitteilung enthält, wobei die verschlüsselte Mitteilung eine Mitteilungskurzfassung des architekturspezifischen Programms enthält, die unter Verwendung einer Mitteilungskurzfassungsfunktion erzeugt worden ist, bei der die verschlüsselte Mitteilung unter Verwendung eines privaten Verschlüsselungsschlüssels verschlüsselt worden ist, der der identifizierten Zeichnungspartei zugeordnet ist; und die Digitalsignatur-Prüfeinrichtung (132) eine Logik zum Verarbeiten einer spezifizierten digitalen Signatur (210) enthält, durch Erhalten eines öffentlichen Schlüssels, der der durch den Zeichnungsparteiidentifizierer identifizierten Zeichnungspartei zugeordnet ist, Entschlüsseln der verschlüsselten Mitteilung der digitalen Signatur (210) mit dem öffentlichen Schlüssel, um somit eine entschlüsselte Mitteilungskurzfassung zu erzeugen, Erzeugen einer Testmitteilungskurzfassung durch Ausführen der Mitteilungskurzfassungsfunktion für das architekturspezifische Programm (300), das der digitalen Signatur zugeordnet ist, Vergleichen der Testmitteilungskurzfassung mit der entschlüsselten Mitteilungskurzfassung, und Ausgeben eines Fehlersignals, wenn die entschlüsselte Mitteilungskurzfassung und die Testmitteilungskurzfassung nicht übereinstimmen.
Computer nach Anspruch 1, wobei die Programmsicherheitslogik ferner dafür konfiguriert ist, das Laden irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage (140), welche wenigstens ein architekturspezifisches Programm (300) enthält, zu verhindern, solange nicht jedes architekturspezifische Programm (300) in der angeforderten Objektklasse zwei digitale Signaturen (320, 312) enthält und beide digitale Signaturen von der Digitalsignatur-Prüfeinrichtung (132) erfolgreich geprüft worden sind; jede digitale Signatur (320, 312), die einem der architekturspezifischen Programme (300) zugeordnet ist, einen Zeichnungsparteiidentifizierer (326, 318) und eine verschlüsselte Mitteilung enthält, wobei die verschlüsselte Mitteilung eine mit einer vordefinierten Prozedur erzeugte Mitteilung enthält, wobei die verschlüsselte Mitteilung unter Verwendung eines privaten Verschlüsselungsschlüssels verschlüsselt worden ist, der der identifizierten Zeichnungspartei zugeordnet ist; und die Digitalsignatur-Prüfeinrichtung (132) eine Logik enthält, die dafür konfiguriert ist, eine spezifizierte Digitalsignatur zu verarbeiten, durch Erhalten eines öffentlichen Schlüssels, der der durch den Zeichnungsparteiidentifizierer identifizierten Zeichnungspartei zugeordnet ist, Entschlüsseln der verschlüsselten Mitteilung der digitalen Signatur mit dem öffentlichen Schlüssel, um somit eine entschlüsselte Mitteilung zu erzeugen, Erzeugen einer Testmitteilung durch Ausführen der vordefinierten Prozedur für das architekturspezifische Programm, das der digitalen Signatur zugeordnet ist, Vergleichen der Testmitteilung mit der entschlüsselten Mitteilung, und Ausgeben eines Fehlersignals, wenn die entschlüsselte Mitteilungskurzfassung und die Testmitteilungskurzfassung nicht übereinstimmen; wobei die zwei digitalen Signaturen, die in jedem architekturspezifischen Programm in der angeforderten Objektklasse enthalten sein müssen, eine erste digitale Signatur, für die die Zeichnungspartei ein Mitglied einer ersten Gruppe von vertrauenswürdigen Parteien ist, und eine zweite digitale Signatur enthalten, für die die Zeichnungspartei ein Mitglied einer zweiten Gruppe vertrauenswürdiger Parteien ist.
Computer nach Anspruch 1, wobei die Programmsicherheitslogik dafür konfiguriert ist, das Laden der angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage zu verhindern, solange nicht jedes architekturspezifische Programm (300) in der angeforderten Objektklasse eine Mitteilungskurzfassung für ein zugeordnetes architekturneutrales Programm enthält und die Mitteilungskurzfassung mit einer Testmitteilungskurzfassung übereinstimmt, die von der Programmsicherheitslogik erzeugt wird, indem sie eine vordefinierte Mitteilungskurzfassungsprozedur für das zugeordnete architekturneutrale Programm (200) ausführt.
Verfahren zum Betreiben eines Computersystems, das die Schritte umfasst: Speichern vertrauenswürdiger Objektklassen in einer Vertrauensobjektklassen-Ablage (140); wenn die Ausführung irgendeines Programms in der einen Objektklasse angefordert wird, Laden der angeforderten Objektklasse zur Ausführung in einen Benutzeradressraum (138); gekennzeichnet durch: Speichern nicht-vertrauenswürdiger Objektklassen in einer Nichtvertrauensobjektklassen-Ablage (142); wobei die Objektklassen jeweils wenigstens ein Programm enthalten und jedes Programm ein Programm umfasst, das aus der Gruppe ausgewählt wird, die aus (A) architekturneutralen Programmen (200), die in einer architekturneutralen Sprache geschrieben sind, und (B) architekturspezifischen Programmen (300), die in einer architekturspezifischen Sprache geschrieben sind, besteht; Ausführen des Ladeschritts, solange nicht das Laden der angeforderten Objektklasse durch einen Sicherheitsverstoß verhindert wird, einschließlich der Verhinderung des Ladens irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage, die wenigstens ein architekturspezifisches Programm enthält, solange nicht je des architekturspezifische Programm in der angeforderten Objektklasse eine digitale Signatur enthält und die digitale Signatur durch eine Digitalsignatur-Prüfeinrichtung (132) erfolgreich geprüft worden ist.
Verfahren nach Anspruch 6, wobei der Objektklassenladeschritt enthält: (A) Prüfen der Integrität jedes architekturneutralen Programms (200) in der angeforderten Objektklasse, wenn die angeforderte Objektklasse nicht in der Vertrauensobjektklassen-Ablage (140) gespeichert ist und wenigstens ein architekturneutrales Programm enthält, und (B) Verhindern des Ladens der angeforderten Objektklasse, solange sich die angeforderte Objektklasse nicht in der Vertrauensobjektklassen-Ablage befindet, wenn die angeforderte Objektklasse wenigstens ein architekturneutrales Programm enthält, dessen Integrität nicht geprüft ist.
Verfahren nach Anspruch 6 oder 7, wobei jede digitale Signatur (210), die einem der architekturspezifischen Programme (300) zugeordnet ist, einen Zeichnungsparteiidentifizierer (216) und eine verschlüsselte Mitteilung enthält, wobei die verschlüsselte Mitteilung eine Mitteilungskurzfassung (212) des architekturspezifischen Programms enthält, die unter Verwendung einer Mitteilungskurzfassungsfunktion erzeugt worden ist, in der die verschlüsselte Mitteilung unter Verwendung eines privaten Verschlüsselungsschlüssels verschlüsselt worden ist, der der identifizierten Zeichnungspartei zugeordnet ist; und der Objektklassenladeschritt die Verarbeitung einer spezifizierten digitalen Signatur enthält, durch Erhalten eines öffentlichen Schlüssels, der der durch den Zeichnungsparteiidentifizierer identifizierten Zeichnungspartei zugeordnet ist, Entschlüsseln der verschlüsselten Mitteilung der digitalen Signatur mit dem öffentlichen Schlüssel, um somit eine entschlüsselte Mitteilungskurzfassung zu erzeugen, Erzeugen einer Testmitteilungskurzfassung durch Ausführen der Mitteilungskurzfassungsfunktion für das architekturspezifische Programm, das der digitalen Signatur zugeordnet ist, Vergleichen der Testmitteilungskurzfassung mit der entschlüsselten Mitteilungskurzfassung, und Ausgeben eines Fehlersignals, wenn die entschlüsselte Mitteilungskurzfassung und die Testmitteilungskurzfassung nicht übereinstimmen.
Verfahren nach Anspruch 6, wobei der Objektklassenladeschritt das Verhindern des Ladens irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage, welche wenigstens ein architekturspezifisches Programm enthält, umfasst, solange nicht jedes architekturspezifische Programm in der angeforderten Objektklasse zwei digitale Signaturen (320, 312) enthält und beide digitale Signaturen von der Digitalsignatur-Prüfeinrichtung erfolgreich geprüft worden sind; jede digitale Signatur (320, 312), die einem der architekturspezifischen Programme (300) zugeordnet ist, einen Zeichnungsparteiidentifizierer und eine verschlüsselte Mitteilung enthält, wobei die verschlüsselte Mitteilung eine Mitteilung enthält, die von einer vordefinierten Prozedur erzeugt worden ist, in der die verschlüsselte Mitteilung unter Verwendung eines privaten Verschlüsselungsschlüssels verschlüsselt worden ist, der der identifizierten Zeichnungspartei zugeordnet ist; der Objektklassenladeschritt die Verarbeitung einer spezifizierten digitalen Signatur enthält, durch Erhalten eines öffentlichen Schlüssels, der der durch den Zeichnungsparteiidentifizierer identifizierten Zeichnungspartei zugewiesen ist, Entschlüsseln der verschlüsselten Mitteilung der digitalen Signatur mit dem öffentlichen Schlüssel, um somit eine entschlüsselte Mitteilung zu erzeugen, Erzeugen einer Testmitteilung durch Ausführen der vordefinierten Prozedur für das architekturspezifische Programm, das der digitalen Signatur zugeordnet ist, Vergleichen der Testmitteilung mit der entschlüsselten Mitteilung, und Ausgeben eines Fehlersignals, wenn die entschlüsselte Mitteilungskurzfassung und die Testmitteilungskurzfassung nicht übereinstimmen; wobei die zwei digitalen Signaturen, die in jedem architekturspezifischen Programm in der angeforderten Objektklasse enthalten sein müssen, eine erste digitale Signatur, für die die Zeichnungspartei ein Mitglied einer ersten Gruppe vertrauenswürdiger Parteien ist, und eine zweite digitale Signatur enthalten, für die die Zeichnungspartei ein Mitglied einer zweiten Gruppe vertrauenswürdiger Parteien ist.
Verfahren nach Anspruch 6, wobei der Objektklassenladeschritt das Verhindern des Ladens der angeforderten Objektklasse außer den Objektklassen in der Vertrauensob jektklassen-Ablage enthält, solange nicht jedes architekturspezifische Programm in der angeforderten Objektklasse eine Mitteilungskurzfassung für ein zugeordnetes architekturneutrales Programm enthält und die Mitteilungskurzfassung mit einer Testmitteilungskurzfassung übereinstimmt, die von der Programmsicherheitslogik durch Ausführen einer vordefinierten Mitteilungskurzfassungsprozedur für das zugeordnete architekturneutrale Programm erzeugt worden ist.
Computerlesbares Medium zum Speichern von Datenprogrammen, die auf einem Datenverarbeitungssystem ausgeführt werden, wobei das computerlesbare Medium umfasst: eine Vertrauensobjektklassen-Ablage (140), die vertrauenswürdige Objektklassen speichert; eine architekturspezifische Programmausführungseinrichtung (124); eine Klassenladeeinrichtung (136), die eine spezifizierte der Objektklassen zur Ausführung in einen Benutzeradressraum (138) lädt, wenn die Ausführung irgendeines Programms in der einen Objektklasse angefordert wird; eine Programmintegrität-Prüfeinrichtung (126), die prüft, ob in einer architekturneutralen Sprache geschriebene Programme vordefinierte Programmintegritätskriterien erfüllen; gekennzeichnet durch: eine Digitalsignatur-Prüfeinrichtung (132), die digitale Signaturen (210) der Ursprungsparteien von Programmen prüft, die in den Programmen enthalten sind; eine architekturneutrale Programmausführungseinrichtung (122); und eine Nichtvertrauensobjektklassen-Ablage (142), die nichtvertrauenswürdige Objektklassen speichert; wobei die Objektklassen jeweils wenigstens ein Programm enthalten, wobei jedes Programm ein Programm umfasst, das aus einer Gruppe ausgewählt ist, die aus (A) architekturneutralen Programmen (200), die in einer architekturneutralen Sprache geschrieben sind, und (B) architekturspezifischen Programmen (300), die in einer architekturspezifischen Sprache geschrieben sind, besteht; die Klassenladeeinrichtung (136) Programmsicherheitsanweisungen enthält, die das Laden irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage, welche wenigstens ein architekturspezifisches Programm enthält, verhindern, solange nicht jedes architekturspezifische Programm in der angeforderten Objektklasse eine digitale Signatur enthält und die digitale Signatur von der Digitalsignatur-Prüfeinrichtung (132) erfolgreich geprüft worden ist.
Computerlesbares Medium nach Anspruch 11, wobei die Klassenladeeinrichtung (136) Prüfeinrichtungsanweisungen enthält, um die Programmintegrität-Prüfeinrichtung aufzurufen, um die Integrität jedes architekturneutralen Programms in der angeforderten Objektklasse zu prüfen, wenn die angeforderte Objektklasse nicht in der Vertrauensobjektklassen-Ablage (140) gespeichert ist und wenigstens ein architekturneutrales Programm (200) enthält; und die Programmsicherheitsanweisungen ferner das Laden irgendeiner angeforderten Objektklasse außer den Objektklassen in der Vertrauensobjektklassen-Ablage (140) verhindern, wenn die angeforderte Objektklasse wenigstens ein architekturneutrales Programm (200) enthält, dessen Integrität nicht von der Programmintegrität-Prüfeinrichtung (126) geprüft worden ist.