DE69816986T2

DE69816986T2 - Verfahren und vorrichtung zur versiegelung und unterschrift von objekten

Info

Publication number: DE69816986T2
Application number: DE69816986T
Authority: DE
Inventors: Li Gong
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1997-05-29
Filing date: 1998-05-15
Publication date: 2004-07-22
Anticipated expiration: 2018-05-16
Also published as: IL133024A0; EP0983541A1; ATE246820T1; EP0983541B1; IL133024A; WO1998054633A1; US7093134B1; CN1122213C; DE69816986D1; JP2002502524A; CN1258359A

Description

Hintergrund der Erfindung
1. Gebiet der Erfindung
Diese Erfindung betrifft das Signieren und Versiegeln von Objekten.
2. Stand der Technik
Eine objektorientierte Laufzeitumgebung umfasst Objekte, die das Verhalten und den Zustand enthalten. Der Zustand eines Objekts bei Laufzeit entwickelt sich in der Laufzeitumgebung. Da sich ein Laufzeitobjekt entwickelt, wird es als „live" angesehen. Es kann notwendig werden, ein Laufzeitobjekt über systemische Grenzen zu verteilen. In einer sicheren Umgebung wird es möglicherweise gewünscht, ein verteiltes Laufzeitobjekt zu überprüfen, bevor es verwendet wird. Es wird ein Mechanismus zur Überprüfung von „Live"-Objekten benötigt. Außerdem wird ein Mechanismus zum Sichern oder Versiegeln eines Laufzeitobjekts benötigt.
Überprüfung (Authentifizierung) ist ein Prozess, der in sicheren Systemen zum Verifizieren statischer Informationen dient. Die Überprüfung wird beispielsweise zum Verifizieren der Herkunft der überprüften Informationen verwendet. Wenn die Informationen als von einer zuverlässigen Quelle stammend identifiziert werden, werden sie als gültig angesehen.
Die Überprüfung erfolgt normalerweise durch Erzeugen einer Signatur, die an die Informationen angehängt wird. Ein Empfänger verwendet die Signatur, um die Informationen zu verifizieren. Normalerweise verwendet der Absender der Informationen einen privaten Schlüssel (ein Schlüssel, den nur der Absender der Informationen kennt, und die Signatur), um eine digitale Signatur, die an die Informationen angehängt wird, zu erzeugen. Der Empfänger der Informationen verwendet die angehängte Signatur und einen öffentlichen Schlüssel (ein unter Verwendung des privaten Schlüssels erzeugter Schlüssel, der an die Öffentlichkeit verteilt wird), um die Signatur und dadurch die Informationen zu verifizieren.
Es gibt zahlreiche Algorithmen zum Signieren von Informationen. Das National Institute of Standards and Technology (MIST; Staatliches Institut für Normen und Technik) hat den Digital Signature Standard (DSS, Digitale Signaturnorm) vorgeschlagen, die den Digital Signature Algorithm (DSA, Digitaler Signaturalgorithmus) verwendet. Nach DSS und DSA besteht eine Signatur aus zwei Teilen r und s, die unter Verwendung einer Gruppe von Transformationen erzeugt werden, die mit einem privaten Schlüssel, einer Zufallszahl, dem Hash der Nachricht und drei öffentlich bekannten Parametern funktionieren. Die Komponenten der Signatur r und s werden an einen Empfänger gesendet. Um die Signatur zu verifizieren oder zu überprüfen, erzeugt der Empfänger einen Wert für r mittels eines öffentlichen Schlüssels (der aus dem privaten Schlüssel erzeugt wird). Die Gruppe der von dem Absender durchgeführten Transformationen funktioniert mittels s, des öffentlichen Schlüssels, des Hashs der Nachricht und den öffentlich bekannten Parametern. Wenn der Wert r, der mit dem öffentlichen Schlüssel erzeugt wird, gleich dem Wert r ist, der mit dem privaten Schlüssel erzeugt wird, wird die Signatur verifiziert.
Es werden folgende Variablen im DSA verwendet:

p: 512- bis 1024-Bit-Primzahl

q: 160-Bit-Primfaktor von p – 1

h: ein Wert, der kleiner als p – 1 ist und bei dem h^(p-1)/q mod p > 1 ist

g: h^(p-1)/q mod p

y: g^x mod p

x: < q
Die Variable x ist der private Schlüssel und y ist der öffentliche Schlüssel. Wie anhand der Definitionen der Variablen zu erkennen ist, wird der private Schlüssel x verwendet, um den öffentlichen Schlüssel y zu erzeugen. Um eine Signatur zu erzeugen, wird eine Zufallszahl k bestimmt, die kleiner als q ist. Die Signatur besteht aus r und s, die wie folgt erzeugt werden: r = (gk mod p) mod q s = (k–1(H(m) + xr)) mod q
Beim Berechnen von s werden die Informationen, für die die Signatur erzeugt wird, in eine Hash-Funktion (z. B. unter Verwendung einer Einweg-Hash-Funktion) eingegeben, um H(m) zu erzeugen. So werden die Informationen verwendet, um die Signatur zu erzeugen. Die Si gnatur wird zusammen mit den Informationen oder der Nachricht an den Empfänger gesendet. Der Empfänger verifiziert die Signatur durch Berechnen eines Werts für r, v. Wenn v gleich r ist, wird die Signatur verifiziert. Der Empfänger berechnet v wie folgt: w = s–1 mod q u1 = (H(m)*w) mod q u2 = (rw) mod q v = ((gu1*yu2) mod p) mod q
Der Empfänger verwendet den öffentlichen Schlüssel y, um die Signatur zu verifizieren. Wenn die berechnete Signatur v gleich der Signatur r ist, werden die Signatur und dadurch die Informationen verifiziert. Auf diese Weise werden die Informationen durch Überprüfen einer an die Informationen angehängten Signatur überprüft.
Ein weiterer Sicherheitsaspekt besteht darin, dass gewährleistet wird, dass die Informationen selbst nur von berechtigten Personen gelesen werden. Der Zugriff auf Informationen, die für vertraulich gehalten werden, wird dadurch beschränkt, dass die Informationen so codiert werden, dass nur eine berechtigte Person die Informationen decodieren kann. Ein System zur Codierung und Decodierung wird als Verschlüsselungssystem bezeichnet.
Ein Verschlüsselungssystem ist ein System zum Senden einer Nachricht von einem Absender an einen Empfänger über ein Medium so, dass die Nachricht „sicher" ist, das heißt, so, dass nur der gewünschte Empfänger die Nachricht wiederherstellen kann. Ein Verschlüsselungssystem wandelt eine Nachricht, die als „Klartext" bezeichnet wird, in ein verschlüsseltes Format um, das als „chiffrierter Text" bekannt ist. Die Verschlüsselung wird durch Manipulieren oder Transformieren der Nachricht mit einem oder mehreren „Chiffrierschlüsseln" erreicht. Der Empfänger „entschlüsselt" die Nachricht, das heißt, er wandelt sie von chiffriertem Text in Klartext um, indem er den Manipulations- oder Transformationsprozess mit dem oder den Chiffrierschlüssel(n) umkehrt. Solange nur der Absender und der Empfänger den Chiffrierschlüssel kennen, ist eine solche verschlüsselte Übertragung sicher.
Ein „klassisches" Verschlüsselungssystem ist ein Verschlüsselungssystem, bei dem die Chiffrier-Informationen zum Bestimmen der Dechiffrier-Informationen verwendet werden können. Um Sicherheit zu bieten, muss bei einem klassischen Verschlüsselungssystem der Chiffrierschlüssel geheimgehalten und den Benutzern des Systems über sichere Kanäle zur Verfü gung gestellt werden. Sichere Kanäle, wie sichere Kuriere, sichere Fernsprechübertragungsleitungen usw., sind oft unpraktisch und teuer.
Ein System, das die Schwierigkeiten des Austauschens eines sicheren Chiffrierschlüssels beseitigt, ist als „Verschlüsselung mit öffentlichen Schlüsseln" bekannt. Definitionsgemäß hat ein Verschlüsselungssystem mit öffentlichen Schlüsseln die Eigenschaft, dass jemand, der nur weiß, wie eine Nachricht zu verschlüsseln ist, ohne übermäßig lange Berechnung den Dechiffrierschlüssel nicht mit dem Chiffrierschlüssel finden kann. Eine Chiffrierfunktion wird so gewählt, dass wenn ein Chiffrierschlüssel bekannt ist, die Chiffrierfunktion relativ einfach zu berechnen ist. Die Umkehrung der Verschlüsselungstransformationsfunktion ist jedoch schwierig oder gar nicht zu berechnen. Eine solche Funktion wird als „Einwegfunktion" oder „Falltürfunktion" bezeichnet. In einem Verschlüsselungssystem mit öffentlichen Schlüsseln sind bestimmte Informationen zu den Schlüsseln öffentlich. Diese Informationen können und werden häufig auch auf nichtsichere Weise veröffentlicht oder übertragen. Außerdem sind bestimmte Informationen zu den Schlüsseln privat. Diese Informationen können über einen sicheren Kanal verteilt werden, um ihre Privatheit zu schützen (oder sie können von einem lokalen Benutzer erzeugt werden, um die Privatheit zu schützen).
Ein Beispiel für ein Verschlüsselungs-/Entschlüsselungsschema ist der Data Encryption Algorithm (DEA; Datenverschlüsselungsalgorithmus), der in ANSI X3.92 definiert ist und auch als Data Encryption Standard (DES; Datenverschlüsselungsnorm ) bezeichnet wird. Der DEA verwendet arithmetische und logische Operationen auf Binärdarstellungen des Schlüssels und die Informationen, um die Transformation durchzuführen. In einem binären Zahlensystem werden Zahlen als Reihe von Binärziffern oder Bits dargestellt. Ein Bit kann einen Wert von Null oder Eins haben. Ein Schlüssel und die zu transformierenden Informationen werden also als Reihe von Nullen und Einsen dargestellt.
Der DEA führt während der Transformation mehrere Iterationen oder Rundungen an einem Block von Bits aus. Ein Block von Informationen oder Daten mit einer Länge von 64 Bits wird auf einmal verarbeitet. Er wird in der Hälfte geteilt und an der rechten Hälfte wird eine Permutation durchgeführt, um seine 32 Bits auf 48 Bits zu erweitern. Eine 48-Bit-Darstellung des Schlüssels wird zur Verwendung bei der Transformation gewählt. Nachstehend sind Beispiele für die resultierenden 48-Bit-Schlüssel- und -Daten-Abschnitte angegeben:
Die Schlüssel- und Daten-Abschnitte werden unter Verwendung einer logischen Antivalenzoperation (XOR-Operation) kombiniert. Eine XOR-Operation ergibt den Wert Eins, wenn und nur wenn einer ihrer Operanden gleich Eins ist. Wenn beispielsweise die ersten Bits im Schlüssel und in den Daten einer XOR-Operation unterzogen werden, wäre das Ergebnis Eins. Wenn die achtundvierzigsten Bits einer XOR-Operation unterzogen werden, wäre das Ergebnis Null. Die XOR-Operation ergibt ein 48-Bit-Ergebnis, wobei jedes Bit das Ergebnis einer XOR-Operation zwischen zwei Bits aus dem Schlüssel und den Daten ist. An dem XOR-Ergebnis wird eine Reihe von Substitutionen durchgeführt, sodass zweiunddreißig neue Bits entstehen, und an den neuen Bits wird eine Permutation durchgeführt. Das Ergebnis wird einer XOR-Operation mit der linken Hälfte des 64-Bit-Blocks unterzogen. Es wird auf die linke und rechte Hälfte umgeschaltet, und es beginnt eine weitere Iteration oder Rundung. Eine detailliertere Erläuterung des DEA wird in der Schrift Applied Cryptography: Protocols, Algorithms, and Source Code in C (Angewandte Verschlüsselung: Protokolle, Algorithmen und Quellcode bei C), Schneier, B., John Wiler & Sons, Inc. (1996), gegeben, deren Inhalt hiermit im Rahmen dieser Anmeldung vollumfänglich als geoffenbart gilt.
Der aktuell verfügbare Überprüfungsmechanismus überprüft statische Informationen. Ein Laufzeitobjekt ist aber nicht statisch. Ebenso werden aktuelle Verschlüsselungsmechanismen verwendet, um statische Informationen zu verschlüsseln. Es wird daher ein Mechanismus zum Signieren und/oder Versiegeln eines „Live"-Objekts, wie etwa eines „Live"-Objekts, das in einer Laufzeitumgebung vorliegt, benötigt.
EP 0.638.860-A2 beschreibt ein Verfahren zum Erzeugen einer Objektzelle, die eine Datenstruktur bildet, die eine Sammlung von Objektinstanzen widerspiegelt, deren Ausführung zeitweilig eingestellt worden ist, wobei bestimmte Teile dieser Datenstruktur digital signiert werden. Diese Objektzelle kann auf eine andere Plattform übertragen werden, wo die Objektinstanz ausgeführt werden kann.
Kurze Darstellung der Erfindung
Ausführungsformen der Erfindung werden verwendet, um signierte Objekte und versiegelte Objekte zu erzeugen. Ein signiertes Objekt ist ein Objekt, das eine zugehörige digitale Signatur hat, die verwendet werden kann, um das Objekt zu überprüfen. Ein versiegeltes Objekt ist ein Objekt, das verschlüsselt ist, um den Zugriff nur auf befugte Personen zu begrenzen.
Es wird eine signedObject-Klasse definiert, die ein „Live"-Objekt darstellt. Ein „Live"-Objekt kann Änderungen widerspiegeln, die an dem Laufzeitzustand vorgenommen werden, der in dem „Live"-Objekt gespeichert ist. Ein „Live"-Objekt ist ein dynamisches Objekt insofern, als sein Zustand (z. B. Werte, die zu den Instanz-Variablen des Objekts gehören) geändert werden kann. Es wird ein Schnappschuss des „Live"-Objekts erzeugt und in dem signedObject gespeichert. Das signedObject speichert außerdem eine Signatur, die mit dem Schnappschuss des „Live"-Objekts assoziiert ist. Die Signatur kann beispielsweise mit dem DSA erzeugt werden. Ein signed-Flag in der signedObject-Klasse zeigt den Status des signedObject an. Wenn signed „richtig" („wahr") ist, ist die im signedObject gespeicherte Signatur eine gültige digitale Signatur des Schnappschusses des „Live"-Objekts.
Die Member-Felder von signedObject sind privat, und auf sie kann mit öffentlichen Methoden zugegriffen werden. Die Member-Felder eines signedObject können nicht über die Methoden des signedObject hinaus manipuliert werden. Wenn das „Live"-Objekt signiert ist, kann es nicht modifiziert werden, ohne dass die Signatur ungültig wird. Wenn beispielsweise der Schnappschuss modifiziert wird, wird das signed-Flag auf „falsch" zurückgesetzt, um anzuzeigen, dass die digitale Signatur nicht mehr gültig ist. Wenn ein Schnappschuss des „Live"-Objekts aufgenommen ist, haben weitere Modifikationen des Objekts keinen Einfluss auf den gespeicherten Inhalt in dem signedObject.
Um ein „Live"-Objekt zu überprüfen, wird das signed-Flag dahingehend geprüft, ob das signedObject eine gültige digitale Signatur enthält. Eine digitale Signatur wird aus dem signedObject abgerufen. Die digitale Signatur wird dahingehend geprüft, ob sie echt ist. Wenn die digitale Signatur echt ist, wird der Schnappschuss des „Live"-Objekts aus dem signedObject abgerufen und zum Wiederherstellen des „Live"-Objekts verwendet.
Eine sealedObject-Klasse wird verwendet, um ein „Live"-Objekt zu verschlüsseln. Es wird ein Schnappschuss des „Live"-Objekts erzeugt und in dem sealedObject gespeichert. Der Schnappschuss wird mit einem öffentlichen Schlüssel verschlüsselt. Der verschlüsselte Schnappschuss wird im sealedObject gespeichert. Wenn der Schnappschuss verschlüsselt ist, wird die Klartext-Variante des Schnappschusses aus dem sealedObject gelöscht. Um das verschlüsselte Objekt abzurufen, wird der verschlüsselte Schnappschuss aus dem sealedObject abgerufen. Mit einem privaten Schlüssel wird der verschlüsselte Schnappschuss entschlüsselt. Der entschlüsselte Schnappschuss wird verwendet, um das „Live"-Objekt wiederherzustellen. Wie bei der signedObject-Klasse sind die Member-Felder oder -Variablen des sealedObject über Member-Methoden öffentlich zugänglich.
Unter Verwendung von Ausführungsformen der Erfindung ist eine Kombination aus Signierung und Versiegelung eines Objekts möglich. Beispielsweise wird der Schnappschuss eines „Live"-Objekts durch Speichern des Schnappschusses und der Signatur in einer sealedObject-Instanz versiegelt. Der Schnappschuss wird verschlüsselt, und die Klartext-Variante des Schnappschusses wird aus dem sealedObject gelöscht. Bevor mit dem Schnappschuss das „Live"-Objekt wiederhergestellt wird, wird die Signatur für die Überprüfung verwendet. Um das Objekt zu überprüfen, wird der Schnappschuss entschlüsselt, sodass der Klartext entsteht. Der Klartext wird beispielsweise mittels DSS und DSA überprüft. Wenn er authentisch ist, wird der Klartext verwendet, um das „Live"-Objekt wiederherzustellen.
Unterklassen können so definiert werden, dass sie mehrere Signierungs-Levels ermöglichen. Es können beispielsweise mehrere Signaturen auf den gleichen Schnappschuss gelegt werden. In diesem Fall sind vorhandene Methodenaufrufe in der Grundklasse semantisch völlig kompatibel. Beispielsweise sendet eine Methode, die eine Signatur holen soll, eine einzige Signatur zurück, wenn es nur eine Signatur gibt, oder sie sendet eine Signatur aus einer Gruppe von Signaturen zurück, wenn es mehr als eine Signatur gibt.
Kurze Beschreibung der Zeichnungen
1 gibt ein Beispiel für einen Universalrechner, der in einer Ausführungsform der Erfindung verwendet werden kann.
2 ist ein Überblick über eine signedObject-Klasse nach einer Ausführungsform der Erfindung.
3 ist ein Überblick über eine sealedObject-Klasse nach einer Ausführungsform der Erfindung.
4 gibt ein Beispiel für eine Zustandsmaschine für ein Objekt nach einer Ausführungsform der Erfindung.
5 gibt ein Beispiel für einen Objekt-Signierungs-Prozessablauf nach einer Ausführungsform der Erfindung.
6 gibt ein Beispiel für einen Objekt-Entsignierungs-Prozessablauf nach einer Ausführungsform der Erfindung.
7 gibt ein Beispiel für einen Zugriffsanforderungsverwaltungs-Prozessablauf nach einer Ausführungsform der Erfindung.
8 gibt ein Beispiel für einen Objektversiegelungs-Prozessablauf nach einer Ausführungsform der Erfindung.
9 gibt ein Beispiel für einen Objekt-Entsiegelungs-Prozessablauf nach einer Ausführungsform der Erfindung.
10 gibt ein Beispiel für einen Prozessablauf zum Entsignieren und Entsiegeln eines Objekts nach einer Ausführungsform der Erfindung.
Detaillierte Beschreibung der Erfindung
Es werden ein Verfahren und eine Vorrichtung zum Signieren und Versiegeln von Objekten beschrieben. In der nachstehenden Beschreibung werden zahlreiche spezielle Einzelheiten angegeben, um eine genauere Beschreibung der vorliegenden Erfindung zu geben. Ein Fachmann dürfte jedoch erkennen, dass die vorliegende Erfindung auch ohne diese speziellen Ein zelheiten genutzt werden kann. In anderen Fällen sind bekannte Merkmale nicht näher beschrieben worden, damit die Erfindung nicht schwer verständlich wird.
Ausführungsformen der Erfindung können auf einem Universalrechner, wie er in 1 gezeigt ist, implementiert werden. Eine Tastatur 110 und eine Maus 111 sind mit einem Zweiweg-Systembus 118 verbunden. Die Tastatur und die Maus dienen dazu, die Benutzereingabe dem Computersystem zuzuführen und diese Benutzereingabe an die CPU 113 zu senden. Das Computersystem von 1 weist auch einen Bildschirmspeicher 114, einen Hauptspeicher 115 und einen Massenspeicher 112 auf, die alle zusammen mit der Tastatur 110, der Maus 111 und der CPU 113 mit dem Zweiweg-Systembus 118 verbunden sind. Der Massenspeicher 112 kann feste und herausnehmbare Medien, wie magnetische, optische oder magnetisch-optische Speichersysteme oder eine andere verfügbare Massenspeichertechnik, aufweisen. Der Bus 118 kann beispielsweise 32 Adressenleitungen zum Adressieren des Bildschirmspeichers 114 oder Hauptspeichers 115 enthalten. Der Systembus 118 weist beispielsweise auch einen 32-Bit-DATA-Bus zum Übertragen von DATA zwischen und unter den Komponenten, wie der CPU 113, dem Hauptspeicher 115, dem Bildschirmspeicher 114 und dem Massenspeicher 112, auf. Alternativ können Multiplex-DATA-/Adressenleitungen anstelle getrennter DATA- und Adressenleitungen verwendet werden.
Bei einer Ausführungsform dieser Erfindung ist die CPU 113 ein von Motorola hergestellter 32-Bit-Mikroprozessor, wie der 680X0- oder Power-PC-Prozessor, oder ein von Intel hergestellter Mikroprozessor, wie der 80X86- oder Pentium-Prozessor. Es kann jedoch auch jeder andere geeignete Mikroprozessor oder Mikrorechner verwendet werden. Der Hauptspeicher 115 besteht aus einem Speicher mit periodischem Wiedereinlesen der Daten (dynamic random access memory; DRAM). Der Bildschirmspeicher 114 ist ein Doppel-Port-RAM-Speicher zur Erhöhung der Leistung von Grafikkarten (video random access memory; VRAM). Ein Port des Bildschirmspeichers 114 ist mit einem Video-Verstärker 116 verbunden. Der Video-Verstärker 116 dient zum Ansteuern des Katodenstrahlröhren(CRT)-Rastermonitors 117. Der Video-Verstärker 116 ist auf dem Fachgebiet bekannt und kann mit einem geeigneten Mittel implementiert werden. Diese Schaltungen wandeln im Bildschirmspeicher 114 gespeicherte Pixel-DATA in ein Rastersignal um, das zur Verwendung durch den Monitor 117 geeignet ist. Der Monitor 117 ist ein Monitortyp, der zum Anzeigen von grafischen Bildern geeignet ist.
Das vorstehend beschriebene Computersystem dient nur als Beispiel. Die Erfindung kann in jeder Art von Computersystem oder Programmierungs- oder Verarbeitungsumgebung implementiert werden.
Eine Ausführungsform der Erfindung wird verwendet, um ein Objekt so zu signieren, dass es überprüft werden kann. Ausführungsformen der Erfindung können außerdem zum Verschlüsseln eines Objekts verwendet werden, um den Zugriff auf das Objekt zu beschränken. Die Versiegelungs- und Signierungsmechanismen der Erfindung können so kombiniert werden, dass ein signiertes, versiegeltes Objekt entsteht.
Die Objekt-Signierung ist ein Mechanismus zum Erzeugen einer digital signierten Variante eines Objekts, die fälschungssicher ist. Ein signiertes Objekt kann dann beispielsweise innerhalb von oder zwischen Laufzeitsystemen (z. B. ein Java-Laufzeitsystem) als verifizierbares authentisches Token oder Objekt übertragen werden. Weitere Anwendungsmöglichkeiten sind die Verwendung des signedObject Laufzeitumgebungs-intern als fälschungssicheres Zugriffsberechtigungs-Token, das ohne Angst davor übertragen werden kann, dass das Token böswillig modifiziert werden kann, ohne dass das entdeckt wird. Ein signedObject kann außerhalb der Laufzeit gespeichert werden, um beispielsweise kritische Zugriffssteuerdaten auf Platte zu speichern. Unter Verwendung von Ausführungsformen der Erfindung ist eine Schachtelung möglich, um eine logische Folge von Signaturen zu erzeugen, um beispielsweise eine Zugriffsberechtigungs- und Delegationskette herzustellen.
Es wird eine signedObject-Klasse definiert, um ein Objekt zu signieren. 2 gibt einen Überblick über eine signedObject-Klasse nach einer Ausführungsform der Erfindung. Die signedObject-Klasse 202 wird verwendet, um ein Objekt 204 zu signieren, das in einer Laufzeitumgebung instanziiert ist. Ein Schnappschuss des Objekts 204 wird erzeugt und in einem Array 214 gespeichert. Der Schnappschuss beinhaltet den Zustand des Objekts 204. Das heißt beispielsweise, dass der Schnappschuss die Klasse des Objekts 204, die Klassensignatur und die Werte aller nichttransienten und nichtstatischen Felder des Objekts 204 beinhaltet. Eine Signatur wird von einem Signaturgenerator 206 erzeugt und wird in einem Array 216 des signedObject 202 gespeichert.
Die Arrays 214 und 216 sind über Methoden des signedObject 202 öffentlich zugänglich. Beispielsweise kann das signedObject 202 den Zugriff so beschränken, dass eine Anforderung zum Modifizieren des Arrays 214 nicht zugelassen wird, wenn eine gültige Signatur im Array 216 vorliegt. Alternativ kann eine Anforderung zum Modifizieren des Arrays 214 zugelassen werden, wodurch jedoch die gültige Signatur im Array 216 ungültig wird. Eine weitere Methode des signedObject 202 ermöglicht es, den Status des Arrays 216 zu prüfen (d. h., ob das Array 216 eine gültige Signatur enthält). Die Inhalte der Arrays 214 und 216 können mit Methoden des signedObject 202 abgerufen werden. Beispiele für die Variablen und Methoden der signedObject-Klasse sind im Abschnitt „SignedObject-Klasse" gegeben.
Der im Array 214 gespeicherte Schnappschuss des Objekts 204 kann verwendet werden, um das Objekt 204 wiederherzustellen. Die im Array 216 enthaltene Signatur wird geprüft, um die Authentizität (d. h., dass das Objekt aus einer zuverlässigen Quelle stammt) zu verifizieren. Wenn die Signatur authentisch ist, wird mit dem Inhalt des Arrays 214 das Objekt 204 wiederhergestellt. Beispielsweise kann der Inhalt des Arrays 214 den Zustand des Objekts 204 enthalten, der verwendet wird, um die Felder einer Instanz des Objekts 204 zu besetzen. Alternativ kann das Array 214 sowohl den Zustand als auch das Verhalten des Objekts 204 beinhalten.
Unter Verwendung von Ausführungsformen der Erfindung kann ein Objekt zusätzlich oder alternativ zum Signieren eines Objekts versiegelt werden. 3 gibt einen Überblick über eine sealedObject-Klasse nach einer Ausführungsform der Erfindung. Bei der bevorzugten Ausführungsform der Erfindung ist die sealedObject-Klasse eine Unterklasse der signedObject-Klasse. Auf diese Weise erbt die sealedObject-Klasse die Member-Felder und -Methoden der signedObject-Klasse. Ein sealedObject 202 wird verwendet, um das Objekt 204 durch Verschlüsseln des Inhalts des Objekts 204 zu versiegeln. Ein Schnappschuss des Objekts 204 wird erzeugt und im Array 214 gespeichert. Der Schnappschuss beinhaltet den Zustand des Objekts 204. Das heißt, der Schnappschuss beinhaltet beispielsweise die Klasse des Objekts 204, die Klassensignatur und die Werte aller nichttransienten und nichtstatischen Felder des Objekts 204. Eine Signatur wird vom Signaturgenerator 206 erzeugt und wird im Array 216 des signedObject 202 gespeichert.
Die Arrays 214 und 216 sind über Methoden des signedObject 202 zugänglich. Als Unterklasse des signedObject 202 beinhaltet das sealedObject 302 die Methoden des signedObject 202 zum Modifizieren des Arrays 214, zum Prüfen des Status des Arrays 216 (d. h., ob das Array 216 eine gültige Signatur enthält), zum Abrufen der Inhalte der Arrays 214 und 216 usw. Eine Instanz des sealedObject 302 beinhaltet außerdem Methoden zum Verschlüsseln und Entschlüsseln eines Schnappschusses des Objekts 204. Weitere Methoden des sealedObject 302 ermöglichen es, den Status des sealedObject 302 zu bestimmen und den Inhalt des Arrays 318 abzurufen. Beispiele für die Variablen und Methoden der sealedObject-Klasse sind im Abschnitt „SealedObject-Klasse" gegeben.
Das Array 318 enthält eine verschlüsselte Variante, d. h. chiffrierten Text, für den Schnappschuss des Objekts 204. Um das Objekt 204 zu verschlüsseln, wird ein Schnappschuss des Objekts 204 erzeugt und im Array 214 gespeichert. Ein Verschlüssler 308 wird verwendet, um den Inhalt des Arrays 214 mit einem Verschlüsselungsschlüssel zu verschlüsseln. Bei der bevorzugten Ausführungsform wird ein öffentliches Schlüsselsystem verwendet, um ein Objekt zu signieren oder zu versiegeln. Beispielsweise wird mit DSA ein Objekt signiert und mit DES wird ein Objekt versiegelt. Einem Fachmann dürfte jedoch klar sein, dass weitere Systeme mit der Erfindung verwendet werden können. Der verschlüsselte Schnappschuss wird im Array 318 gespeichert. Der Inhalt des Arrays 214 wird dann so gelöscht, dass die Klartext-Variante des Schnappschusses nicht mehr im sealedObject 302 gespeichert ist. Das heißt, wenn eine Chiffriertext-Variante des Objekts 204 erzeugt wird, wird die Klartext-Variante des Objekts 204 aus dem sealedObject 302 gelöscht.
Vorzugsweise werden verschiedene öffentlich-private Schlüsselpaare verwendet, um ein Objekt zu signieren und zu versiegeln. Wenn nur ein öffentlich-privates Schlüsselpaar verwendet wird, müssen die Parteien den öffentlichen und den privaten Schlüssel kennen. Das heißt, eine Partei A benutzt einen privaten Schlüssel, um eine Signatur zu erzeugen, während eine Partei B einen zugehörigen öffentlichen Schlüssel benutzt, um die Signatur zu verifizieren. Um ein Objekt zu versiegeln, verwendet die Partei A den öffentlichen Schlüssel, um das Objekt zu verschlüsseln, das die Partei B mit dem privaten Schlüssel entschlüsselt. Daher müssen, wenn das gleiche öffentlich-private Schlüsselpaar zum Signieren und Versiegeln verwendet wird, die Partei A und die Partei B beide Schlüssel in dem öffentlich-privaten Schlüsselpaar kennen. Alternativ kann das Versiegeln unter Verwendung eines klassischen Verschlüsselungssystems erfolgen.
Ein Objekt kann signiert oder versiegelt werden, oder es kann signiert und versiegelt werden. Beispielsweise kann das Objekt 204 signiert und versiegelt werden. 4 zeigt ein Beispiel für eine Zustandsmaschine für ein Objekt nach einer Ausführungsform der Erfindung. In ei nem Zustand 402 wird das Objekt 204 weder signiert noch versiegelt. Wenn das Objekt 204 einer Umwandlung 424 unterzogen wird, ist es in einem Zustand 404 signiert und entsiegelt. Über eine Umwandlung 422 kehrt das Objekt 204 in den Zustand 402 zurück, in dem es entsigniert und entsiegelt ist. Ebenso wechselt das Objekt 204 über eine Umwandlung 432 vom Zustand 402 (entsigniert und entsiegelt) in einen Zustand 406, wo das Objekt 204 versiegelt und entsigniert ist. Das Objekt 204 kehrt über eine Umwandlung 434 zum Zustand 402 (d. h. entsiegelt und entsigniert) zurück.
Im Zustand 404 ist das Objekt 204 signiert und entsiegelt. Ein Zustand 408 wird über eine Umwandlung 426 erreicht, um das Objekt 204 zu signieren und zu versiegeln. Vom Zustand 408 kann das Objekt 204 über eine Umwandlung 428 entsiegelt werden (Eingangszustand 404) oder kann über eine Umwandlung 430 entsigniert werden (Eingangszustand 406). Bei der bevorzugten Ausführungsform kann jedoch ein entsigniertes, versiegeltes Objekt nicht signiert werden. Wie bereits dargelegt, wird eine Signatur aus den zu signierenden Informationen erzeugt. Wenn die Informationen verschlüsselt sind, sind sie nicht mehr verfügbar, um eine Signatur zu erzeugen. Wie in 4 gezeigt, erfolgt somit keine Umwandlung von einem entsignierten, versiegelten Zustand (z. B. Zustand 406) in einen signierten und versiegelten Zustand (z. B. Zustand 408).
Eine Umwandlung von einem entsignierten, versiegelten Zustand (Zustand 406) in einen signierten, entsiegelten Zustand (Zustand 404) wird beispielsweise über die Umwandlungen 434 und 424 und den Zustand 402 erreicht. Eine Umwandlung von einem signierten, entsiegelten Zustand (Zustand 404) in einen entsignierten, versiegelten Zustand (Zustand 406) ist über die Zustände 402 (z. B. über die Umwandlungen 422 und 432) oder 408 (z. B. über die Umwandlungen 426 und 430) möglich.
Serialisierung
Um ein Objekt zu signieren oder zu versiegeln, wird ein Schnappschuss des Objekts mit einem als Serialisierung bezeichneten Verfahren gemacht. Während der Serialisierung wird der Inhalt eines Objekts aus dem Objekt abgerufen und beispielsweise in einer Datei, einem Byte-Array usw. gespeichert. Durch Deserialisierung wird der Inhalt eines Objekts wiederhergestellt. Bei der bevorzugten Ausführungsform wird ein Objekt durch Streaming serialisiert (z. B. sein Inhalt gespeichert) und deserialisiert (z. B. sein Inhalt wiederhergestellt).
Ein Datenstrom ist ein linearer, sequentieller Strom von Daten, der verwendet wird, um eine Unabhängigkeit von dem benutzten tatsächlichen physischen E/A-Gerät zu erzielen. Beispielsweise kann der Datenstrom eine Datei (z. B. zur Dauerspeicherung eines Objekts) oder ein Netzsockel (z. B. zum Wiederherstellen eines Objekts auf einem anderen Host oder in einem anderen Prozess) sein. Ein Eingangsdatenstrom ist ein Datenstrom, der mittels Lese-Operationen nach innen fließt. Ein Ausgangsdatenstrom fließt aufgrund von Schreib-Operationen nach außen.
Die Serialisierung wird vorzugsweise in einer Anwendungsprogrammierungs-Schnittstelle (Application Programming Interface; API) implementiert. In diesem Fall kann ein Objekt dadurch serialisiert werden, dass es als serialisierbar deklariert wird (z. B. die Serialisierungs-Schnittstelle implementiert). Der Serialisierungsmechanismus für ein Objekt schreibt die Klasse des Objekts, die Klassensignatur und die Werte aller nichtttransienten und nichtstatischen Felder in einen Ausgangsdatenstrom. Wenn beispielsweise ein Objekt serialisiert wird, wird der Zustand des Objekts dadurch gespeichert, dass die einzelnen Felder mit einer write-Object-Methode in einen Ausgangsdatenstrom (z. B. einen ObjectOutputStream) geschrieben werden. Der Deserialisierungsmechanismus für ein Objekt liest die in den Ausgangsdatenstrom geschriebenen Informationen. Ein Beispiel für eine serialisierbare Schnittstelle wird in der Java-Development-Kit-Version 1.1 gegeben, die von Sun Microsystems, Inc. erhältlich ist. Ein Objekt wird deserialisiert, indem die Felder mit einer readObject-Methode aus dem Ausgangsdatenstrom in das Objekt gelesen werden. Die Informationen im Datenstrom werden verwendet, um das Feld des in dem Datenstrom gespeicherten Objekts dem entsprechend benannten Feld im aktuellen Objekt zuzuweisen.
SignedObject-Klasse
Die signedObject-Klasse ist eine Klasse, die ein signiertes Dokument darstellt. Das signierte Dokument ist ein anderes Objekt (z. B. ein Java-Laufzeitobjekt), das unter Verwendung einer Ausführungsform der Erfindung signiert wird. Mit einer Constructor-Methode wird eine Instanz des signedObject aus einem „Inhalts"-Objekt (z. B. einem „Live"- oder dynamischen Objekt) erzeugt. Das „Inhalts"-Objekt wird serialisiert, und das Ergebnis wird in der signedObject-Instanz gespeichert. Ein Signaturfeld enthält eine digitale Signatur, die mit dem In halt assoziiert ist. Ein signed-Flag zeigt an, ob das Signaturfeld einer signedObject-Instanz eine digitale Signatur des Inhalts des Objekts enthält.
Alle Member-Felder oder -Variablen sind privat und sind über öffentliche Methoden zugänglich. Somit ist das Innere eines signedObject nicht direkt von außen manipulierbar. Sobald also der Inhalt signiert ist, kann er nicht weiter modifiziert werden, ohne dass der Status entsigniert wird. Und sobald das ursprüngliche Objekt serialisiert ist (z. B. ein Schnappschuss des „Inhalts"-Objekts gemacht ist) und es im signedObject gespeichert ist, hat eine weitere Manipulation an dem ursprünglichen Objekt keinen Einfluss auf den gespeicherten Inhalt. Bei der bevorzugten Ausführungsform sind die „Signierungs"- und „Verifizierungs"methoden endgültig und können nicht mit Unterklassen modifiziert werden. Dadurch wird die Möglichkeit verringert, dass betrügerische Software erzeugt wird, die die Signierungs- und Verifizierungsaufgaben nicht richtig oder ehrlich ausführt.
Die signedObject-Klasse beinhaltet ein Signaturbyte-Array, ein Inhaltsbyte-Array und ein signed-Flag. Das Signaturbyte-Array bewahrt den Wert der Signatur auf, die mit einem Schnappschuss eines „Inhalts"-Objekts assoziiert ist. Das Inhaltsbyte-Array speichert den Inhalt des „Inhalts"-Objekts. Das signed-Flag dient zum Angeben, ob das Signaturbyte-Array eine gültige Signatur für den Inhalt enthält.
Nachstehend werden Beispiele für Methoden der signedObject-Klasse gegeben:
Objektsignierung
Während der Objekt-Serialisierung wird ein Objekt in einer Instanz der signedObject-Klasse gespeichert. Eine Signatur, die mit dem serialisierten Objekt assoziiert ist, wird in der signedObject-Instanz gespeichert, um das Objekt zu signieren. 5 zeigt ein Beispiel für einen Objekt-Signierungs-Prozessablauf nach einer Ausführungsform der Erfindung.
Im Schritt 502 wird ein Schnappschuss des Objekts gemacht. Der Schnappschuss wird im Schritt 504 im Inhaltsbyte-Array einer signedObject-Instanz gespeichert. Der Schnappschuss wird in der signedObject-Instanz beispielsweise mit einem Streaming-Verfahren erzeugt und gespeichert. Mit einem Streaming-Verfahren wird der Inhalt des Objekts an einen Datenstrom ausgegeben, der zum Inhaltsbyte-Array der signedObject-Instanz gelenkt wird (z. B. unter Verwendung der writeObject-Serialisierungsmethode).
Im Schritt 506 wird eine Signatur für den Schnappschuss beispielsweise mit dem DSA-Verfahren erzeugt. Die Signatur wird im Schritt 508 im Signaturbyte-Array der signedObject-Instanz gespeichert. Das signed-Flag in der signedObject-Instanz wird im Schritt 510 auf „richtig" gesetzt. Im Schritt 512 endet die Verarbeitung.
Durch den Prozessablauf von 5 wird eine digitale Signatur an ein „Inhalts"-Objekt angehängt.
Objekt-Entsignierung
Während der Deserialisierung wird eine Signatur, die mit dem serialisierten Objekt assoziiert ist, aus der signedObject-Instanz abgerufen, um das serialisierte Objekt zu überprüfen. Wenn die Überprüfung erfolgreich ist, wird das serialisierte Objekt aus der signedObject-Klasse abgerufen, um das serialisierte Objekt wiederherzustellen. 6 gibt ein Beispiel für einen Objekt-Entsignierungs-Prozessablauf nach einer Ausführungsform der Erfindung.
Im Schritt 602 wird die Signatur eines Objekts aus der signedObject-Instanz des Objekts abgerufen. Die Signatur wird im Schritt 604 beispielsweise mittels DSA verifiziert. Im Schritt 604 (d. h. „Gültige Signatur?") wird festgestellt, ob die Signatur authentisch ist. Wenn nicht, wird das Objekt als nicht authentisch angesehen. Das Objekt braucht daher nicht abgerufen zu werden, und die Verarbeitung endet im Schritt 612.
Wenn im Schritt 606 festgestellt wird, dass die Signatur authentisch ist, wird angenommen, dass das Objekt authentisch ist. Der Schnappschuss des Objekts wird im Schritt 608 aus dem Inhalts-Array des signedObject abgerufen. Im Schritt 610 wird mit dem Schnappschuss das Objekt wiederhergestellt. Beim Abrufen und Verwenden des Schnappschusses des Objekts zur Wiederherstellung des Objekts wird vorzugsweise ein Streaming-Verfahren angewendet. Mit einem Streaming-Verfahren wird das Inhaltsbyte-Array an einen Datenstrom ausgegeben, der zur Instanz des Objekts gelenkt wird. Die Verarbeitung endet im Schritt 612.
Zugriff auf ein serialisiertes Objekt
Der Inhalt und die Signatur eines Objekts werden in der signedObject-Instanz in Member-Feldern oder -Variablen aufbewahrt, die über Methoden des signedObject-Instanz öffentlich zugänglich sind. Zugriffsanforderungen werden von der signedObject-Instanz verarbeitet. 7 gibt ein Beispiel für einen Zugriffsanforderungsverwaltungs-Prozessablauf nach einer Ausführungsform der Erfindung.
Die signedObject-Instanz verarbeitet Dienst-Anforderungen. Im Schritt 702 (d. h. „Anforderung erhalten?") wird festgestellt, ob eine Anforderung erhalten worden ist. Wenn nicht, geht die Verarbeitung im Schritt 702 weiter. Wenn die signedObject-Instanz eine Anforderung erhält, geht die Verarbeitung im Schritt 704 (d. h. „Anforderungsart?") weiter, um die Art der Anforderung zu bestimmen.
Die Anforderung „Inhalt zurücksetzen" ist eine Anforderung zum Modifizieren der im Inhalts-Array des signedObject gespeicherten Informationen. Das heißt, es ist eine Anforderung zum Modifizieren des „Inhalts"-Objekts. Wenn eine Anforderung „Inhalt zurücksetzen" empfangen wird, geht die Verarbeitung im Schritt 710 weiter, um das signed-Flag auf „falsch" zu setzen. Eine Änderung des Inhalts macht die Signatur ungültig. Daher wird das signed-Flag auf „falsch" gesetzt, um anzuzeigen, dass der Inhalt nicht mehr signiert ist. Im Schritt 712 wird der Inhalt mittels des neuen enthaltenen Inhalts modifiziert. Die Verarbeitung geht im Schritt 702 weiter, um alle nachfolgenden Anforderungen zu verarbeiten.
Wenn eine Anforderung „Signieren" empfangen wird, wird eine Modifikation der im Signatur-Array gespeicherten Informationen angefordert. Eine Anforderung „Signieren" wird verwendet, um das „Inhalts"-Objekt zu signieren, oder sie kann verwendet werden, um nach einer Anforderung „Inhalt zurücksetzen" beispielsweise den modifizierten Inhalt eines Objekts zu signieren. Die Verarbeitung geht im Schritt 720 weiter, um das signed-Flag auf „falsch" zu setzen. Im Schritt 722 wird beispielsweise unter Verwendung der im Inhalts-Array gespeicherten Informationen und DAS eine neue Signatur erzeugt. Im Schritt 724 wird die neue Signatur im Signatur-Array des signedObject gespeichert. Das signed-Flag wird auf „richtig" gesetzt. Die Verarbeitung geht im Schritt 702 weiter, um alle nachfolgenden Anforderungen zu verarbeiten.
Mit einer Anforderung „Signatur erhalten" werden die im Signatur-Array des signedObject gespeicherten Informationen abgerufen. Eine Anforderung „Signatur erhalten" wird verwendet, um die Signatur beispielsweise in Erwartung der Verifizierung des Signatur- und Objektinhalts abzurufen. Die Verarbeitung der Anforderung „Signatur erhalten" wird im Schritt 730 (d. h. „Signiert = ,richtig'?") fortgesetzt, um festzustellen, ob das signed-Flag auf „richtig" gesetzt ist. Wenn nicht, gibt es keine zurückzusendende Signatur, und die Verarbeitung geht im Schritt 734 weiter, um einen Nullwert zurückzusenden. Wenn das signed-Flag „richtig" ist, wird die im Signatur-Array enthaltene Signatur im Schritt 732 zurückgesendet. Die Verarbeitung wird im Schritt 702 fortgesetzt, um alle nachfolgenden Anforderungen zu verarbeiten.
Definition der sealedObject-Klasse
Die sealedObject-Klasse ist eine Klasse, die ein versiegeltes Dokument darstellt. Das versiegelte Dokument ist das Laufzeitobjekt (z. B. ein Java-Laufzeitobjekt). Ein Constructor erzeugt eine Instanz des sealedObject aus dem Laufzeit- oder „Inhalts"-Objekt. Die sealedObject-Klasse ist eine Unterklasse der signedObject-Klasse und erbt die Member-Variablen und -Methoden der signedObject-Klasse. Wie bei der signedObject-Klasse sind Variablen der sealedObject-Klasse alle privat und sind mittels Member-Methoden öffentlich zugänglich.
Die sealedObject-Klasse beinhaltet ein Signaturbyte-Array, ein Inhaltsbyte-Array und ein verschlüsseltes Inhalts-Array. Das Signaturbyte-Array bewahrt den Wert der Signatur auf, die mit einem Schnappschuss eines „Inhalts"-Objekts assoziiert ist. Das Inhaltsbyte-Array speichert den Inhalt des „Inhalts"-Objekts. Das verschlüsselte Inhalts-Array enthält die Chiffrier text-Variante des Objekts. Variablen werden als Flags verwendet, um den signierten Status und den versiegelten Status des „Inhalts"-Objekts zu identifizieren. Ein signed-Flag wird verwendet, um anzugeben, ob das Signaturbyte-Array eine gültige Signatur für den Inhalt enthält. Ein sealed-Flag wird verwendet, um anzugeben, ob eine Chiffriertext-Variante des Objekts in der sealedObject-Instanz gespeichert ist.
Wie bei der signedObject-Klasse ist das Innere eines sealedObject nicht direkt von außen manipulierbar. Nachstehend werden Beispiele für Methoden der sealedObject-Klasse gegeben:
Objektversiegelung
Um ein Objekt zu versiegeln, wird das Objekt serialisiert und die Serialisierung des Objekts in einer Instanz der sealedObject-Klasse gespeichert. Die Serialisierung wird verschlüsselt, um chiffrierten Text zu erzeugen. Der chiffrierte Text wird anstelle der Serialisierung des Objekts in der sealedObject-Instanz gespeichert. 8 gibt ein Beispiel für einen Objekt-Versiegelungs-Prozessablauf nach einer Ausführungsform der Erfindung.
Im Schritt 802 wird ein Objekt-Schnappschuss von dem Objekt gemacht. Der Schnappschuss wird im Schritt 804 im Inhalts-Array einer Instanz der sealedObject-Klasse gespeichert. Im Schritt 806 wird der Schnappschuss verschlüsselt, um eine Chiffriertext-Variante des Objekts zu erzeugen. Der chiffrierte Text wird im Schritt 808 im verschlüsselten Inhalts-Array gespeichert. Im Schritt 810 wird die Klartext-Variante des Schnappschusses aus dem Inhalts-Array des sealedObject gelöscht. Im Schritt 812 wird das sealed-Flag auf „richtig" gesetzt. Die Verarbeitung endet im Schritt 814.
Objekt-Entsiegelung
Um ein Objekt zu entsiegeln, wird die Chiffriertext-Variante eines serialisierten Objekts entschlüsselt, um die Klartext-Serialisierung zu erreichen. Die Klartext-Serialisierung dient zum Wiederherstellen des verschlüsselten Objekts. 9 gibt ein Beispiel für einen Objekt-Entsiegelungs-Prozessablauf nach einer Ausführungsform der Erfindung.
Im Schritt 902 (d. h. „Versiegelt?") wird festgestellt, ob das sealedObject eine verschlüsselte Variante des Schnappschusses des Objekts enthält. Das heißt, das sealed-Flag wird geprüft, um den Status der sealedObject-Instanz zu bestimmen. Wenn das sealed-Flag anzeigt, dass die sealedObject-Instanz keinen chiffrierten Text enthält, endet die Verarbeitung im Schritt 910. Wenn das sealed-Flag „richtig" ist, geht die Verarbeitung im Schritt 904 weiter, um den chiffrierten Text zu entschlüsseln, um die Klartext-Variante des Objekts beispielsweise mittels DES zu erhalten. Im Schritt 906 wird der Klartext abgerufen.
Im Schritt 908 wird mit der Klartext-Variante des Objekts das Objekt wiederhergestellt. Beispielsweise wird das Streaming-Verfahren verwendet, um den Klartext aus der sealedObject-Instanz an das wiederhergestellte Objekt auszugeben. Die Verarbeitung endet im Schritt 910.
Signieren und Versiegeln eines Objekts
Ein Objekt kann unter Verwendung von Ausführungsformen der Erfindung sowohl signiert als auch versiegelt werden. 5 gibt ein Beispiel für einen Prozessablauf zur Serialisierung und Signierung eines „Live"-Objekts. Mit dem Verfahren von 8 kann ein Objekt versiegelt werden. Ein signiertes, versiegeltes Objekt wird vor der Verwendung entsigniert und ent siegelt. 10 gibt ein Beispiel für einen Prozessablauf zum Entsignieren und Entsiegeln eines signierten, versiegelten Objekts nach einer Ausführungsform der Erfindung.
Ein signiertes, versiegeltes Objekt wird entsiegelt, und mit dem Klartext wird das Objekt entsigniert. Alternativ kann ein signiertes, versiegeltes Objekt entsiegelt und anschließend entsigniert werden. Im Schritt 1002 (d. h. „Versiegelt?") wird festgestellt, ob das sealed-Flag anzeigt, dass das Objekt versiegelt ist. Wenn nicht, geht die Verarbeitung im Schritt 1008 weiter, um das Objekt zu entsignieren. Wenn ja, geht die Verarbeitung in den Schritten 1004 und 1006 weiter, um den chiffrierten Text des Objekts zu entschlüsseln und den Klartext in der sealedObject-Instanz zu speichern.
Im Schritt 1008 wird die mit dem Objekt assoziierte Signatur abgerufen. Die Signatur wird im Schritt 1010 verifiziert. Im Schritt 1012 (d. h. „Gültige Signatur?") wird festgestellt, ob die Signatur authentisch ist. Wenn nicht, endet die Verarbeitung im Schritt 1018. Wenn die Signatur authentisch ist, geht die Verarbeitung im Schritt 1014 weiter, um die Klartext-Variante des Objekts abzurufen, mit der dann im Schritt 1016 das Objekt wiederhergestellt wird.
Es sind also ein Verfahren und eine Vorrichtung zum Signieren und Versiegeln von Objekten in Verbindung mit einer oder mehreren speziellen Ausführungsformen bereitgestellt worden. Die Erfindung wird von den Ansprüchen und deren vollem Schutzumfang der Äquivalente definiert.

Claims

Verfahren zum Signieren eines Live-Objekts, welches umfaßt: – Instantiieren eines Live-Objekts in einer Laufzeitumgebung, – Aufnehmen eines Schnappschusses des Live-Objekts, wobei das Aufnehmen des Schnappschusses durch Serialisieren eines Zustands des Live-Objekts erfolgt, – Zuordnen einer Signatur zu dem Schnappschuß und – Aufrechterhalten der Zuordnung zwischen dem Schnappschuß und der Signatur.
Verfahren nach Anspruch 1, welches weiterhin umfaßt: – Verifizieren der Signatur und – Erstellen eines neuen Objekts mit Hilfe des Schnappschusses, wenn die Signatur verifiziert wird.
Verfahren nach Anspruch 1, welches umfaßt: – Speichern des Schnappschusses in einem anderen Objekt und – Speichern der Signatur in dem anderen Objekt.
Verfahren nach Anspruch 1, welches weiterhin umfaßt: – Überwachen eines Zustands des Schnappschusses und – Ungültigmachen der Signatur, wenn der Zustand des Schnappschusses sich ändert.
Verfahren nach Anspruch 1, welches weiterhin umfaßt: – Erzeugen der Signatur unter Verwendung des Schnappschusses.
Verfahren nach Anspruch 5, welches weiterhin umfaßt: – Zuordnen einer zweiten Signatur zu dem Schnappschuß.
Verfahren nach Anspruch 6, welches weiterhin umfaßt: – Verifizieren der zweiten Signatur und – Erstellen eines neuen Objekts mit Hilfe des Schnappschusses, wenn die zweite Signatur verifiziert wird.
Verfahren nach Anspruch 1, welches weiterhin umfaßt: – Erzeugen eines Chiffrierschlüssels, – Erzeugen eines verschlüsselten Schnappschusses aus dem besagten Schnappschuß, – Löschen des besagten Schnappschusses und – Zuordnen der Signatur zu dem verschlüsselten Schnappschuß, wobei die Signatur vorher dem besagten Schnappschuß zugeordnet ist.
Verfahren nach Anspruch 8, welches weiterhin umfaßt: – Aufrechterhalten der Zuordnung zwischen dem verschlüsselten Schnappschuß und der dem verschlüsselten Schnappschuß zugeordneten Signatur.
Verfahren nach Anspruch 9, welches weiterhin umfaßt: – Verifizieren der dem verschlüsselten Schnappschuß zugeordneten Signatur und – Erstellen eines neuen Objekts unter Verwendung des verschlüsselten Schnappschusses, wenn die dem verschlüsselten Schnappschuß zugeordnete Signatur verifiziert wird.
Computerprogrammprodukt zum Signieren eines Live-Objekts, welches ein computerlesbares Medium umfaßt, auf dem aufgezeichnet ist: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, ein Live-Objekt in einer Laufzeitumgebung zu instantiieren, – ein Computerprogrammcodemittel zum Veranlassen eines Computers, einen Schnappschuß des Live-Objekts durch Serialisieren eines Zustands des Live-Objekts aufzunehmen, – ein Computerprogrammcodemittel zum Veranlassen eines Computers, eine Signatur dem Schnappschuß zuzuordnen und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Zuordnung zwischen dem Schnappschuß und der Signatur aufrechtzuerhalten.
Computerprogrammprodukt nach Anspruch 11, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die besagte Signatur zu verifizieren und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, ein neues Objekt unter Verwendung des Schnappschusses zu erstellen, wenn die Signatur verifiziert wird.
Computerprogrammprodukt nach Anspruch 11, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, den Schnappschuß in einem anderen Objekt zu speichern und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Signatur in dem anderen Objekt zu speichern.
Computerprogrammprodukt nach Anspruch 11, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, einen Zustand des besagten Schnappschusses zu überwachen, und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Signatur ungültig zu machen, wenn der Zustand des Schnappschusses sich ändert.
Computerprogrammprodukt nach Anspruch 11, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Signatur unter Verwendung des Schnappschusses zu erzeugen.
Computerprogrammprodukt nach Anspruch 11, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, eine zweite Signatur dem Schnappschuß zuzuordnen.
Computerprogrammprodukt nach Anspruch 16, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die zweite Signatur zu verifizieren, und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, ein neues Objekt unter Verwendung des Schnappschusses zu erstellen, wenn die zweite Signatur verifiziert wird.
Computerprogrammprodukt nach Anspruch 11, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, einen Chiffrierschlüssel zu erzeugen, – ein Computerprogrammcodemittel zum Veranlassen eines Computers, den besagten Schnappschuß zu verschlüssen, – ein Computerprogrammcodemittel zum Veranlassen eines Computers, den besagten Schnappschuß zu löschen, und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Signatur dem verschlüsselten Schnappschuß zuzuordnen, wobei die Signatur vorher dem besagten Schnappschuß zugeordnet ist.
Computerprogrammprodukt nach Anspruch 18, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, den verschlüsselten Schnappschuß zu entschlüsseln.
Computerprogrammprodukt nach Anspruch 18, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Zuordnung zwischen dem verschlüsselten Schnappschuß und der dem verschlüsselten Schnappschuß zugeordneten Signatur aufrechtzuerhalten.
Computerprogrammprodukt nach Anspruch 20, welches weiterhin umfaßt: – ein Computerprogrammcodemittel zum Veranlassen eines Computers, die Signatur, welche dem verschlüsselten Schnappschuß zugeordnet ist, zu verifizieren, und – ein Computerprogrammcodemittel zum Veranlassen eines Computers, ein neues Objekt unter Verwendung des verschlüsselten Schnappschusses zu erstellen, wenn die dem verschlüsselten Schnappschuß zugeordnete Signatur verifiziert wird.
System, welches für das Signieren eines Live-Objekts, welches in einer Laufzeitumgebung existiert, konfiguriert ist und welches umfaßt: – ein erstes Programmcodemodul, welches auf einem Computer ausgeführt wird, so konfiguriert, daß ein Schnappschuß eines Live-Objekts aufgenommen wird, wobei der Schnappschuß eine Serialisierung eines Zustands des Live-Objekts ist, und – ein zweites Programmcodemodul, welches auf dem Computer ausgeführt wird, so konfiguriert, daß eine Signatur unter Verwendung des Schnappschusses erzeugt wird, wobei das erste Modul so konfiguriert ist, daß es einen Zustand des Schnappschusses überwacht und die Signatur ungültig macht, wenn der Schnappschuß geändert wird.
System nach Anspruch 22, bei welchem das erste und zweite Modul als ein zweites Objekt implementiert sind.
System nach Anspruch 23, bei welchem der Schnappschuß und die Signatur in dem zweiten Objekt gespeichert werden, wobei das zweite Objekt den Zugriff auf den Schnappschuß durch eine oder mehrere Methoden des zweiten Objekts beschränkt.
System nach Anspruch 24, bei welchem die Methode bzw. Methoden des zweiten Objekts die Signatur ungültig machen, wenn der Zugriff den Schnappschuß modifiziert.
System nach Anspruch 23, welches weiterhin ein Versiegelungsmodul umfaßt, welches umfaßt: – ein Schlüsselerzeugungsmodul, welches so konfiguriert ist, daß ein Chiffrierschlüssel generiert wird, – ein Verschlüsselungsmodul, welches so konfiguriert, daß es einen verschlüsselten Schnappschuß aus dem besagten Schnappschuß erzeugt, und – ein Löschmodul, welches so konfiguriert ist, daß es den besagten Schnappschuß löscht.
System nach Anspruch 26, bei welchem das zweite Objekt so konfiguriert ist, daß es das Schlüsselerzeugungsmodul, das Verschlüsselungsmodul und das Löschmodul aufruft.
System nach Anspruch 27, bei welchem das zweite Objekt so konfiguriert ist, daß es die Signatur verifiziert und ein neues Objekt unter Verwendung des verschlüsselten Schnappschusses erstellt, wenn die Signatur verifiziert wird.