DE10051571B4 - Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung - Google Patents

Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung Download PDF

Info

Publication number
DE10051571B4
DE10051571B4 DE10051571A DE10051571A DE10051571B4 DE 10051571 B4 DE10051571 B4 DE 10051571B4 DE 10051571 A DE10051571 A DE 10051571A DE 10051571 A DE10051571 A DE 10051571A DE 10051571 B4 DE10051571 B4 DE 10051571B4
Authority
DE
Germany
Prior art keywords
key
document
encryption
encrypted
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE10051571A
Other languages
English (en)
Other versions
DE10051571A1 (de
Inventor
Mark C. Davis
John R. Hind
Marcia L. Peters
Brad B. Topol
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE10051571A1 publication Critical patent/DE10051571A1/de
Application granted granted Critical
Publication of DE10051571B4 publication Critical patent/DE10051571B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/007—Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments

Abstract

Eine Methode zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung in einer Computerumgebung, folgende Schritte umfassend:
Bereitstellen eines Input-Dokuments;
Bereitstellen eines oder mehrerer Vorgabenunterstützungsobjekte, wobei jedes der genannten Vorgabenunterstützungsobjekte eine Sicherheitsvorgabe angibt, die Null oder mehreren Elementen des genannten Input-Dokuments zugeordnet werden kann;
Bereitstellen einer Document Type Definition (DTD) entsprechend dem genannten Input-Dokument, wobei die genannte DTD mit einem oder mehreren Verweisen auf die ausgewählten gespeicherten Vorgabenunterstützungsobjekte erweitert wurde;
Ausführen eines erweiterten Stylesheet-Prozessors, weiterhin folgende Schritte umfassend:
Laden der genannten DTD;
Auflösen der genannten einen oder mehreren Verweise in der genannten geladenen DTD;
Instantiieren der genannten Vorgabenunterstützungsobjekte, die den genannten aufgelösten Verweisen zugeordnet sind;
Ausführen von ausgewählten der instantiierten Vorgabenunterstützungsobjekte während der Anwendung von einem oder mehreren Stylesheets auf das genannte Input-Dokument, wobei ein Ergebnis der genannten Ausführung der ausgewählten Schritte ein Interims-Dokument ist, das die genannte Ausführung wiedergibt;
Generieren eines...

Description

  • Hintergrund der Erfindung
  • Bereich der Erfindung
  • Die vorliegende Erfindung befasst sich mit einem Computersystem und im Besonderen mit einer Methode, einem System und einem Computerprogramm zur selektiven Verschlüsselung eines oder mehrerer Dokumentelemente unter Verwendung von Stylesheet-Verarbeitung. Bei dem Dokument kann es sich um ein Extensible Markup Language (XML)-Dokument handeln und bei dem Prozessor kann es sich um einen Extensible Stylesheet Language (XSL)-Prozessor handeln.
  • Die Verwendung von XML als universelles Format für den Datenaustausch zwischen heterogenen Computerprogrammen wird z. B. in Widergren et al: XML for Data Exchange, IEEE Power Engineering Society Summer Meeting, July 1999, S. 840–842, beschrieben.
  • Bei der Verschlüsselung handelt es sich um einen Mechanismus zum Schutz von Informationen vor ungewollter Offenlegung, indem diese Informationen in eine Form gebracht werden, die für Menschen und Maschinen unleserlich ist, wenn diese Maschinen nicht darauf ausgerichtet sind, die Transformation rückwärts auszuführen, so dass der Originalinhalt wiederhergestellt wird. Die Verschlüsselung kann bei Daten ausgeführt werden, die elektronisch übertragen werden sollen, wie etwa Elektronische Mail-Narichten oder ein elektronisches Dokument, das von einem Internet-Benutzer angefordert wird. Die Verschlüsselung ist ebenfalls nützlich für Daten, die sicher gespeichert werden müssen, wie etwa Kontendatensätze für die Kunden einer Bank oder eines Kreditinstituts.
  • Der Transformationsprozess, der für die Originaldaten ausgeführt wird, wird als Verschlüsselung bezeichnet. Der Prozess zum Rückgängigmachen der Transformation und zur Wiederherstellung der Originaldaten wird als Entschlüsselung bezeichnet. Die Begriffe chiffrieren und dechiffrieren beschreiben ebenfalls diese beiden Prozesse. Ein Mechanismus, der sowohl chiffrieren als auch dechiffrieren kann, wird zusammenfassend als Chiffriermechanismus bezeichnet.
  • Die Verwendung eines "Schlüssels" während der Prozesse zum Verschlüsseln und Entschlüsseln macht die Verschlüsselung schwieriger zu entschlüsseln. Ein Schlüssel ist eine durch das Zufallsprinizp erstellte Nummer, zerlegt in den Vorgang der Verschlüsselung, so dass das Ergebnis vom Schlüssel abhängig ist. Der für den Schlüssel verwendete Wert "personalisiert" den Algorithmus, so dass der gleiche Algorithmus bei den gleichen eingegebenen Daten für die verschiedenen Schlüsselwerte eine andere Ausgabe erzeugt. Wenn der Wert dieses Schlüssels nicht berechtigten Personen unbekannt ist, sind sie nicht in der Lage, die Verschlüsselung zu duplizieren oder rückgängig zu machen.
  • Eines der ältesten und gängigsten Sicherheitssysteme wird als "Privatschlüssel" oder "symmetrisches" Sicherheitssystem bezeichnet. Privatschlüsselsysteme umfassen zwei Benutzer, die beide über einen geheimen (bzw. privaten) Schlüssel zum Verschlüsseln und Entschlüsseln von Informationen verfügen, die wiederum über ein Netzwerk zwischen diesen beiden Benutzern übertragen werden. Bevor eine Kommunikation stattfinden kann, müssen die beiden Benutzer auf sichere Weise miteinander kommunizieren, um den Privatschlüssel zu bestätigen und sicherzustellen, dass dieser Schlüssel ausschließlich von diesen beiden Benutzern verwendet wird. Ein Beispiel für eine Verschlüsselung zur Verwendung bei der Privatschlüsselsicherheit ist der Data Encryption Algorithm ("DEA"). Dieser Algorithmus wurde von Wissenschaftlern der International Business Machines Corporation ("IBM") entwickelt, und bildet die Basis eines US-amerikanischen Standards, dem Data Encryption Standard ("DES"). Privatschlüsselsysteme weisen jedoch eine Reihe von Nachteilen in einer offenen Netzwerkumgebung wie dem Internet auf, da Benutzer die gesamte Kommunikation über die offene Netzwerkumgebung ausführen und die zusätzlichen Ausgaben für ein separates sicheres Mittel zum Austausch von Schlüsselinformationen vor der Netzwerkkommunikation nicht wünschen oder brauchen.
  • Um die Beschränkungen durch Privatschlüsselsysteme zu umgehen, wurden Systeme entwickelt, die als "Öffentliche Schlüssel" oder asymmetrische Systeme bekannt sind. In einem System mit öffentlichem Schlüssel verfügt ein Benutzer über ein Schlüsselpaar, das aus einem öffentlichen und einem privaten Schlüssel besteht, wobei beide Schlüssel zum Verschlüsseln und Entschlüsseln von Nachrichten verwendet werden. Der private Schlüssel ist keinem anderen Benutzer zugänglich oder wird ausschließlich von diesem Benutzer verwendet. Der öffentliche Schlüssel andererseits ist jedem zugänglich, der diesen benötigt. Ein Beispiel zur Verwendung des Schlüsselpaars zum Verschlüsseln einer Nachricht ist es, wenn der Erzeuger einer Nachricht die Nachricht mit Hilfe des öffentlichen Schlüssels verschlüsselt. Der Algorithmus und der öffentliche Schlüssel zum Verschlüsseln einer Nachricht können zur Verfügung gestellt werden, ohne die Sicherheit der verschlüsselten Nachricht zu gefährden, da nur der Besitzer des damit verbundenen privaten Schlüssels in der Lage ist, die Nachricht erfolgreich zu entschlüsseln. Ein Schlüsselpaar kann ebenfalls verwendet werden, um einen Nachrichtenerzeuger zu berechtigen oder dessen Einheit festzustellen. Um ein Schlüsselpaar zum Zuweisen von Berechtigungen zu verwenden, signiert der Erzeuger seine Nachricht (oder einen Auszug davon) digital unter Verwendung seines eigenen privaten Schlüssels. Der Empfänger entschlüsselt die digitale Signatur unter Verwendung des öffentlichen Schlüssels des Versenders. Ein gängiges Mittel zum Veröffentlichen eines öffentlichen Schlüssels für einen bestimmten Empfänger ist ein X.509 Zertifikat, auch digitaler Fingerabdruck genannt.
  • Die Verschlüsselung öffentlicher Schlüssel ist im allgemeinen ein kostenintensiver Vorgang mit einer großen Anzahl an Potenzierungsoperationen. Sie erfordert auch längeres Schlüsselmaterial als ein symmetrischer Schlüsselalgorithmus für ein entsprechendes Maß an Sicherheit. Sie wird daher seltener genutzt, nur für Verschlüsselungsoperationen, die deren eindeutige Merkmale benötigen. Symmetrische Schlüsselverschlüsselung wird im weiteren Sinne für die massenhafte Verschlüsselung/Entschlüsselung verwendet, da weniger CPU beansprucht wird, unter Verwendung von primär wiederholten Umschalt-, Rotations, exklusiven ODER und Tabellensuch-Operationen.
  • Verschlüsselungsmethoden für öffentliche und symmetrische Schlüssel werden häufig kombiniert. Ein Beispiel für eine solche Kombination ist der Secure Socket Layer (SSL) und dessen Nachfolger, die Transport Layer Security (TLS). Ein weiteres Beispiel ist das Internet Key Exchange (IKE)-Protokoll des IP-Sicherheitsprotokolls, wie es im Dokument RFC 2411: "IP Security Document Roadmap" der Internet Engineering Task Force (IETF) beschrieben wird.
  • Im Allgemeinen führen die SSL- und IKE-Protokolle ähnliche Schritte durch. Zunächst erhalten die Teilnehmer die Berechtigung zum Einsatz der Verschlüsselung öffentlicher Schlüssel, wobei X.509 Zertifikate ausgetauscht und Verschlüsselungsalgorithmen ausgehandelt werden. Dann erstellt der erste Teilnehmer einen symmetrischen Schlüssel und verschlüsselt diesen unter Verwendung des öffentlichen Schlüssels des zweiten Teilnehmers. Der verschlüsselte symmetrische Schlüssel wird an den zweiten Teilnehmer übertragen, der ihn dann mit Hilfe seines privaten Schlüssels entschlüsselt. Der Prozess der Verhandlung und der Schlüsselübertragung wird "Schlüsselvereinbarung" genannt. Eine Schlüsselvereinbarung kann über eine vorbestimmte Gültigkeitsdauer verfügen und das Protokoll kann Mittel für weitere Schlüsselvereinbarungen enthalten. Nach Abschluss einer Schlüsselvereinbarung kann ein symmetrischer Schlüssel verwendet werden, um massenweise Datenverschlüsselung zwischen den Teilnehmern vorzunehmen.
  • Bei den meisten aktuellen Verschlüsselungstechniken wird ein ganzes Dokument zur Übertragung an bekannte Empfänger verschlüsselt. Die Anforderungen aus der Business-to-Business- Sicherheit heutiger komplexer Netzwerkumgebungen wurde dabei wenig beachtet, in dem ein Dokument asynchron eine Reihe von Zwischen-Agents durchlaufen muss, wie etwa Transcoder, Gateways und Firewalls (wobei jeder Agent zwei verschiedene Aspekte der übermittelten Informationen kennen muss) und wobei das Empfängerpublikum nicht genau vorherbestimmt werden kann.
  • Weiterhin ist die Schlüsselverteilung in einer Netzwerkumgebung mit mehreren Teilnehmern eine kritische Angelegenheit. Wenn zwei Teilnehmer wiederholt verschlüsselte Daten mit demselben Schlüssel für nachfolgende Dokumente austauschen (was vorkommen kann, wenn zwei Unternehmen Transaktionsinformationen über einen längeren Zeitraum austauschen), ist es für einen dritten Teilnehmer einfacher, die Verschlüsselung aufzulösen und den Dokumentinhalt aller wiederholten Übertragungen zu lesen. Somit muss eine sichere Methode zum regelmäßigen Verteilen neuer Schlüssel zwischen den teilnehmenden Parteien vorhanden sein. Wenn auf ähnliche Weise Schlüssel ausgetauscht werden und die Schlüssel durch eine einfach berechnete Funktion des grundlegenden gemeinsam genutzten Schlüssels variiert werden, sind die wiederholten Übertragungen leichter zu decodieren als wenn ein durch Zufallsgenerator generierter Schlüssel für jede nachfolgende Übertragung erstellt wird. Es ist deshalb von Vorteil, für jeden nachfolgenden Schlüssel einen zufallsgenerierten Schlüsselwert zu erstellen. Es ist außerdem von Vorteil, für jedes Dokument einen neuen Schlüssel zu erstellen, um die Sicherheit für das Dokument zu erhöhen. Wenn ein zufallsgenerierter Schlüssel für jedes Dokument verwendet wird, muss eine sichere Technik vorhanden sein, um diesen Schlüssel an den Empfänger mit einem Minimum an Systemaufwand zu verteilen.
  • Ein Dokument kann sicher in einem verschlüsselten Dateisystem gespeichert werden, oder eine verschlüsselte Datei kann auf einem Server gespeichert werden, wo sie nur für diejenigen zugänglich ist, die über den Schlüssel zum Entschlüsseln verfügen. Aus den gleichen, oben beschriebenen Gründen sollte jedes Dokument mit einem zufallsgenerierten Schlüssel verschlüsselt werden, und es muss ein Mittel vorhanden sein, diesen Schlüssel an all jene zu verteilen, die das Dokument lesen müssen.
  • Ein Volltextdokument kann während der Übertragung gesichert werden, indem die Transportschicht-Verbindung unter Verwendung von SSL oder TLS verschlüsselt oder indem ein verschlüsselter Data-Link-Layer-Tunnel unter Verwendung von IP Security Protocol (IPSec) oder dem Layer 2 Tunneling Protocol (L2TP) erstellt wird. Solche Schutzmethoden können jedoch nur auf verbindungsorientierte Systeme angewendet werden, in denen eine End-to-End-Sitzung zwischen dem Versender und dem Empfänger zum Zeitpunkt der Übertragung besteht. In beiden Fällen werden Techniken geboten, in denen der Verschlüsselungsschlüssel zum Verstecken der Daten in regelmäßigen Intervallen während der Dauer einer Sitzung geändert wird.
  • Diese Ansätze (Verschlüsseln der Datei, des Dateisystems oder der Sitzung) sind in einigen Situationen nicht sinnvoll. In Situationen mit mehreren Agents (etwa ein Reihe von Zwischenstationen, wie Gateways, Transcoder und/oder Firewalls), die das Dokument nachfolgend bearbeiten müssen, kann es an jeder Zwischenstation nötig werden, Zugriff auf einige der verschlüsselten Datenelemente innerhalb einer Datei oder eines Dokuments zu haben. Dies beinhaltet, dass die Zwischenstationen den Schlüssel zum Entschlüsseln der Datei benötigen, wodurch der Schutz des Schlüssels zu einem logistischen Problem wird. Wenn die Verschlüsselung für das ganze Dokument ausgeführt wird, erhält eine Zwischenstation, die den Schlüssel empfängt, Zugriff auf das ganze Dokument anstatt auf die Elemente, die möglicherweise für diese spezielle Funktion erforderlich sind, womit das Potenzial für nicht berechtigte Agents vergrößert wird, auf schützenswerte Informationen zuzugreifen.
  • Eine andere Problemsituation für vorhandene Techniken (wie etwa eine verschlüsselte Sitzung) ist die Übertragung von Dokumenten über Systeme zum Speichern und Weiterleiten, wie etwa Nachrichtenwarteschlangen (MQ), wobei der Versender und der Empfänger mit einem Server zum Speichern und Weiterleiten zu verschiedenen Zeiten verbunden sind und niemals End-to-End-Verbindungen miteinander erstellen. In einem MQ-System, selbst wenn die Verbindung zwischen dem Versender und dem MQ Server verschlüsselt sowie die Verbindung zwischen dem MQ Server und dem Empfänger verschlüsselt ist, wird das Dokument nichtsdestotrotz als Volltext auf dem MQ Server für einen gewissen Zeitraum gespeichert. Dadurch entsteht offensichtlich eine Sicherheitslücke, bis der Zugriff auf dem MQ Server streng kontrolliert wird. Für den Erzeuger von schützenswerten Informationen ist es nicht sinnvoll, den MQ Server (der möglicherweise mehrere solcher Server in einem Netzwerkpfad umfasst) zu verwenden, um den nötigen Schutz zu bieten, so dass auf das Volltextdokument nicht zugegriffen werden kann.
  • Die vorhandenen, oben beschriebenen Ansätze (Verschlüsseln der Sitzung, Verschlüsseln des Dateisystems oder Verschlüsseln der Datei) sind nicht sinnvoll in einer Situation, in der das Ziel-Client-Gerät über eine begrenzte CPU-Leistung verfügt, so dass die notwendigen Operation für Verschlüsselung und Entschlüsselung nicht oder so langsam ausgeführt werden, dass dieses System keinen Nutzen bringt.
  • Elektronischer Handel (e-commerce) wird in der heutigen Wirtschaft immer wichtiger. E-commerce oder e-business umfasst die sichere Übertragung von unternehmenswichtigen Daten an ausgewählte Empfänger über nicht sichere öffentliche Netzwerke, wie das Internet. Als Grundlage dient hier die Gesamtlebensdauer eines e-business Dokuments. Im allgemeinen Fall passiert das Dokument mehrere Hände oder Agents, die sich hinsichtlich der für sie wichtigen Daten voneinander unterscheiden. Ein Mitarbeiterdatensatz oder Dokument wird von einer Enterprise Resource Planning (ERP) Software erstellt. Dieses Mitarbeiterdokument ist ein Beispiel für ein Einzeldokument, das Elemente enthalten kann, für die unterschiedlicher Zugriffsschutz erforderlich ist. Das Dokument kann öffentliche Informationen enthalten, wie etwa den Namen des Mitarbeiters, die Mitarbeiternummer und das Einstellungsdatum. Diese Informationen müssen in einem Volltext vorhanden sein, weshalb das Dokument in einer Datenbank zur Verfügung gestellt wird. Das Mitarbeiterdokument kann auch Lohninformationen enthalten, die nur den Vorgesetzten zugänglich sein sollen. Oder es sind nur Gehaltsinformationen zu sehen, die der Gehaltsabteilung zugänglich gemacht werden sollen. Es kann sogar medizinische Daten enthalten, die nur dem medizinischen Personal zugänglich sein sollten. Zusätzlich dazu sollte der Mitarbeiter in der Lage sein, den gesamten Inhalt seines eigenen Dokuments anzuzeigen. Neben der Übertragung über das Netzwerk kann ein Dokument Agents passieren, die die Daten speichern und weiterleiten, wie etwa das Repository des Unternehmens, das übertragene und erhaltene Dokumente aus rechtlichen Gründen aufzeichnet und mit einer Zeitmarkierung versieht, ein E-Mail-System, ein E-Mail-Archiv, ein E-Mail-Screening-Programm auf einer Firewall und so weiter. Es ist nicht sinnvoll, allen Zwischenstationen in einem e-commerce-System zu trauen.
  • Weiterhin ist es beim Erstellen des Dokuments nicht möglich festzustellen, wer letztlich die Benutzer (anfordernde Verwender oder Anwendungsprogramme) der Daten sein werden oder welche Zwischen-Agents die Daten bearbeiten können, weshalb die Daten gesichert werden müssen. Es ist nicht sinnvoll, ein benutzerdefiniertes Dokument für jeden potenziellen Konsumenten zu erstellen, oder ein benutzerdefiniertes Dokument bei jeder Anforderung durch einen anderen Konsumenten zu erstellen, in dem das benutzerdefinierte Dokument die Elemente enthalten würde, für die der Konsument über eine Berechtigung verfügt.
  • Die unveröffentlichte US-Patentanmeldung (Seriennummer 09/240,387 vom 29.1.1999) mit dem Titel "Method, System, and Apparatus for Selecting Encryption Levels Based on Policy Profiling" bietet das Markieren von Datenelementen in Extensible Markup Language ("XML")-Dokumenten mit Sicherheitsinformationen auf Feld- oder Datensatzebene. ("XML" ist Warenzeichen des Massachusetts Institute of Technology). Durch Prüfen dieser Sicherheitsinformationen und Konsultieren der Verzeichniseinträge nach der Berechtigung eines Einzelnen zum Zugriff, unterdrückt ein Server, der auf eine Dokumentanfrage antwortet, alle Dokumentelemente, für die der Anforderer keine Berechtigung hat, bestimmt den Verschlüsselungsalgorithmus und die Schlüssellänge, die für das am meisten beschränkte Element benötigt wird (d.h. das verbleibende Element mit den höchsten Sicherheitsanforderungen) und verschlüsselt das gesamte gefilterte Dokument entsprechend. Diese Erfindung löst nicht das Problem verschlüsselter Dokumente mit mehreren berechtigten Empfängern und Agents, alle mit anderen Informationen (d.h. es wird nicht die Möglichkeit bestimmter Einzelpersonen oder Gruppen eingeschränkt, bestimmte Felder eines Dokuments zu lesen) Es wird auch nicht auf das Problem von Client-Geräten mit ungenügender Arbeitsleistung zum Verschlüsseln von empfangenen Dokumenten eingegangen.
  • Mehrere Lösungen zum Verteilen von verschlüsseltem Schlüsselmaterial zusammen mit dem verschlüsselten Dokument, zu dem der Schlüssel gehört, sind nach Stand der Technik bekannt. Der Industriestandard SMIME, definiert durch IETF, wird verwendet, um E-Mail sicher zu übertragen. Dabei wird die Einkapselung von digital signierten Objekten und Verschlüsselungen geboten. (Siehe http://www.ietf.org/htm.charters/smime-charter.html im Internet für weitere Informationen). Die Software Lotus Notes® verwendet eine proprietäre Implementierung zur Schlüsselverteilung. (Siehe http://www.lotus.com im Internet für weitere Informationen. "Lotus Notes" ist eingetragenes Warenzeichen der Lotus Development Corporation). Keiner dieser vorhandenen Ansätze schlägt vor, einzelne Dokumentfelder zu verschlüsseln (und gleichzeitig andere Felder unverschlüsselt zu lassen). Es werden auch keine unterschiedlich berechtigten Anzeigegemeinschaften und die Verwendung mehrerer und/oder unterschiedlicher Verschlüsselungsalgorithmen und/oder Schlüssel für verschiedene Felder in einem Dokument vorgeschlagen, die verschiedene Sicherheitsstufen erfordern (es besteht auch keine Möglichkeit zum Verteilen mehrerer Schlüssel je Dokument).
    •
  • Entsprechend ist eine Technik erforderlich, mit der die Sicherheitsvorgaben effizient in einem verteilten Netzwerk unterstützt werden können, was viele komplexe Faktoren wie oben beschrieben umfasst.
  • Zusammenfassung der Erfindung
  • Ein Gegenstand der vorliegenden Erfindung ist eine Technik zum effizienten Unterstützen der Sicherheitsvorgaben in einer komplexen verteilten Netzwerkumgebung.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist eine Technik, mit der Daten während des gesamten Unternehmensprozesses und während der Übertragung zwischen Agents in einem Netzwerkpfad von einem Dokumentserver zu einem Dokumentempfänger geschützt werden können, wobei schützenswerte Informationen im Dokument nur den Agents angezeigt werden, die über diese Informationen verfügen müssen, während diese Informationen vor einer Offenlegung gegenüber anderen Teilnehmern geschützt werden.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist diese Technik, wobei jedes der verschiedenen Elemente eine andere Sicherheitsvorgabe verwenden kann, einschließlich der Möglichkeit zur Verwendung verschiedener Sicherheitsalgorithmen, Schlüssel und Schlüssellängen von einem Element zum anderen.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist diese Technik, wobei Stylesheets auf Dokumente angewendet werden, die in Markierungssprachen codiert sind, wie etwa die Extensible Markup Language.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist diese Technik, wobei ein anderer Schlüssel für jedes verschlüsselte Dokument oder Dokumentelement verwendet werden kann, wobei jeder verwendete Schlüssel an alle Dokumentempfänger verteilt werden kann, ohne dass eine Sicherheitslücke entsteht.
  • Eine weiterer Gegenstand der vorliegenden Erfindung ist diese Schlüsselverteilungstechnik, die einen Verschlüsselungsschlüssel bietet, der wiederhergestellt werden kann, je nachdem, ob sich das verschlüsselte Dokument in einem Dateisystem oder in einer Warteschlange auf dem Weg zum Zielempfänger befindet.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist eine Technik zur selektiven Datenverschlüsselung, die den Umfang an Daten verringert, die auf einer bestimmten Sicherheitsstufe verschlüsselt werden müssen, wodurch die Sicherheitsleistung für Client-Geräte mit begrenzten Möglichkeiten vergrößert wird.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist eine Technik zur Wiederherstellung der Schlüssel, die zum Verschlüsseln der Dokumentelemente verwendet werden.
  • Ein weiterer Gegenstand der vorliegenden Erfindung ist diese Technik in rückwärtskompatibler Form, damit vorhandene Stylesheets weiterhin einwandfrei funktionieren.
  • Andere Gegenstände und Ziele der vorliegenden Erfindung werden im weiteren durch die Beschreibung und die Zeichnungen offengelegt.
  • Um die weiteren Gegenstände in Übereinstimmung mit dem Ziel der Erfindung zu erzielen, bietet die Erfindung eine Methode, ein System und Computerprogramm zur Unterstützung der Sicherheitsvorgaben unter Verwendung von Stylesheets. In einem bevorzugten Ausführungsbeispiel umfasst diese Technik folgende Verfahren: Bereitstellen eines Input-Dokuments, Bereitstellen eines oder mehrerer gespeicherter Vorgabenunterstützungsobjekte, wobei jedes der gespeicherten Objekte eine Sicherheitsvorgabe bestimmt, die Null oder mehr Elementen des Input-Dokuments zugeordnet werden, Bereitstellen einer Document Type Definition (DTD) entsprechend dem Input- Dokument, wobei die DTD durch einen oder mehrere Verweise auf die ausgewählten gespeicherten Vorgabenunterstützungsobjekte erweitert wurde, Ausführen eines erweiterten Stylesheet-Prozessors, Empfangen eines verschlüsselten Output-Dokuments an einem Client-Gerät unter Erstellung eines Ergebnisdokuments und Zurücksenden des Ergebnisdokuments an das Client-Gerät. Das Ausführen des erweiterten Stylesheet-Prozessors umfasst vorzugsweise die folgenden Verfahren: Laden der DTD, Lösen der einen oder mehreren Verweise in der geladenen DTD; Erstellen der Vorgabenunterstützungsobjekte, die den aufgelösten Verweisen zugeordnet sind, Ausführen einer ausgewählten Zahl an Vorgabenunterstützungobjekten während der Anwendung eines oder mehrerer Stylesheets auf das Input-Dokument, wobei ein Ergebnis der Ausführung der ausgewählten ein Interims-Dokument ist, das die Ausführung wiedergibt; Generieren eines oder mehrerer zufallsgenerierter Verschlüsselungsschlüssel, Verschlüsseln ausgewählter Elemente des Interims-Dokuments, wobei ein bestimmter der erstellten, zufallsgenerierten Verschlüsselungsschlüssel verwendet werden kann, um eines oder mehrere der ausgewählten Elemente zu verschlüsseln, wobei Null oder mehrere Elemente des Interims-Dokuments unverschlüsselt bleiben, Verschlüsseln jedes einzelnen der zufallsgenerierten Verschlüsselungsschlüssel und Erstellen des verschlüsselten Output-Dokuments, wobei das verschlüsselte Output-Dokument die Null oder mehr anderen unverschlüsselten Elemente, die ausgewählten verschlüsselten Elemente sowie die verschlüsselten Verschlüsselungsschlüssel enthält. Das Ausführen des erweiterten Dokument-Prozessors umfasst die Entschlüsselung des empfangenen Output-Dokuments für einen einzelnen Benutzer oder Prozess auf dem Client-Gerät.
  • Alternativ dazu kann die DTD durch ein Schema ersetzt werden.
  • Das Interims-Dokument kann einen oder mehr Verschlüsselungs-Tags umfassen, die mehrere Elemente identifizieren, die verschlüsselt werden müssen. Das Input-Dokument kann in einer Extensible Markup Language (XML)-Schreibweise angegeben werden und das Output-Dokument kann in dieser XML-Schreibweise angegeben werden. Die Stylesheets können in einer Extensible Stylesheet Language (XSL)-Schreibweise angegeben werden.
  • Die gespeicherten Vorgabenunterstützungsobjekte können weiterhin ausführbaren Code zum Überschreiben einer Methode sowie zum Beurteilen der Elemente des Input-Dokuments umfassen, wobei die Ausführung ausgewählter Elemente weiterhin das Überschreiben dieser Methode zum Beurteilen umfasst. Bei dieser Methode kann es sich um eine Wert-von Methode der XSL-Schreibweise handeln und das Überschreiben der Wert-von Methode kann durch Unterklassierung dieser Wert-von Methode erfolgen.
  • Dieses Überschreiben kann weiterhin die Generierung von Verschlüsselungs-Tags und das Einfügen der generierten Verschlüsselungs-Tags in das Interims-Dokument umfassen, für die eine Verschlüsselung festgelegt wurde. Das Verschlüsseln ausgewählter Elemente kann weiterhin das Verschlüsseln derjenigen Elemente umfassen, die von Verschlüsselungs-Tags umgeben sind.
  • Jedes der instantiierten Vorgabenunterstützungsobjekte kann weiterhin folgendes umfassen: eine Spezifikation einer Gemeinschaft, die über eine Berechtigung verfügt, die Elemente anzuzeigen, die der Sicherheitsvorgabe zugeordnet sind und eine Verschlüsselungsanforderung für die Elemente, die der Sicherheitsvorgabe zugeordnet. Diese Verschlüsselungsanforderung kann weiterhin die Spezifikation eines Verschlüsselungsalgorithmus umfassen. Oder die Verschlüsselungsanforderung kann weiterhin die Spezifikation eines Verschlüsselungsalgorithmus-Stärkewerts und/oder eine Spezifikation einer Verschlüsselungsschlüssellänge umfassen. Die Verschlüsselungsanforderung kann über einen Nullwert verfügen, um anzugeben, dass die angegebene Sicherheitsvorgabe keine Verschlüsselung erfordert.
  • Das Verschlüsseln der Verschlüsselungsschlüssel kann weiterhin das Verschlüsseln einer anderen Version jedes Mitglieds der Null oder mehreren Gemeinschaften umfassen, die diesen Verschlüsselungsschlüssel verwendet und wobei jede der verschiedenen Versionen mit einem öffentlichen Schlüssel des Gemeinschaftsmitglieds verschlüsselt ist, für den die andere Version verschlüsselt worden war.
  • Beim Verschlüsseln der ausgewählten Elemente kann ein Verschlüsselungsprozess für die Verschlüsselungsblockverkettung verwendet werden.
  • Diese Technik kann weiterhin folgendes umfassen: Erstellen einer Schlüsselklasse für jede eindeutige Gemeinschaft, wobei die Schlüsselklasse jedem der verschlüsselten Elemente zugeordnet wird, für die die Gemeinschaft die Berechtigung zur Anzeige innehat und wobei die Schlüsselklasse folgendes umfasst: (1) eine stärkste Verschlüsselungsanforderung der zugeordneten verschlüsselten Elemente; (2) einen Identifier für jedes Mitglied der eindeutigen Gemeinschaft und (3) eine der verschiedenen Versionen des verschlüsselten Verschlüsselungsschlüssel für jedes der identifizierten Mitglieder der Gemeinschaft. Das Generieren des einen oder der mehreren zufallsgenerierten Verschlüsselungsschlüssel kann einen bestimmten zufallsgenerierten Verschlüsselungsschlüssel für jede einzelne Schlüsselklasse verwenden, wobei jede der verschiedenen Versionen in einer bestimmten Schlüsselklasse vom generierten Verschlüsselungsschlüssel verschlüsselt ist, der für die Schlüsselklasse generiert wurde. Die Verschlüsselung der ausgewählten Elemente kann diesen einen der bestimmten zufallsgenerierten Verschlüsselungsschlüssel verwenden, die für die Schlüsselklasse generiert wurden, der das ausgewählte Element zugeordnet wurde.
  • Das Entschlüsseln des Output-Dokuments kann weiterhin folgendes umfassen: Bestimmen von Null oder mehr der Gemeinschaften, der einer der einzelnen Benutzer oder Prozesse als Mitglied angehört; Entschlüsseln für jede der ermittelten Gemeinschaften der unterschiedlichen Version des zufallsgenerierten Verschlüsselungsschlüssels, der verschlüsselt wurde unter Verwendung des öffentlichen Schlüssels dieses Mitglieds, wobei die Entschlüsselung einen privaten Schlüssel des einen Mitglieds verwendet, der dem öffentlichen Schlüssel zugeordnet ist, der wiederum zur Verschlüsselung verwendet wurde, und Entschlüsseln der ausgewählten verschlüsselten Elemente im Output-Dokument unter Verwendung der entschlüsselten Schlüssel, wobei die ausgewählten verschlüsselten Elemente diejenigen sind, die für eine der festgelegten Gemeinschaften verschlüsselt wurden. Die Bereitstellung des Output-Dokuments kann weiterhin die Bereitstellung der entschlüsselten ausgewählten sowie der anderen nicht entschlüsselten Elemente umfassen.
  • Oder das Entschlüsseln des Output-Dokuments kann weiterhin folgendes umfassen: Festlegen von Null oder mehreren Schlüsselklassen, die den einzelnen Benutzer oder den Prozess als ein Mitglied identifizieren, Entschlüsseln für jede der festgelegten Schlüsselklassen der unterschiedlichen Version der zufallsgenerierten Verschlüsselungsschlüssel in der Schlüsselklasse, die unter Verwendung des öffentlichen Schlüssels dieses einen Mitglieds verschlüsselt wurde, wobei die Entschlüsselung einen privaten Schlüssel des einen Mitglieds verwendet, der dem öffentlichen Schlüssel zugeordnet, der zur Verschlüsselung verwendet wurde, wobei ein entschlüsselter Schlüssel erstellt und Entschlüsseln der ausgewählten verschlüsselten Elemente im Output-Dokument unter Verwendung der entschlüsselten Schlüssel, wobei die ausgewählten der entschlüsselten Elemente diejenigen sind, die für die Schlüsselklasse entschlüsselt wurden. Die Bereitstellung kann weiterhin die Bereitstellung der entschlüsselten ausgewählten Elemente sowie der anderen nicht entschlüsselten Elemente umfassen.
  • Die Bereitstellung kann weiterhin die Bereitstellung einer Ersatztextnachricht für jede der ausgewählten verschlüsselten Elemente im Output-Dokument umfassen, die nicht durch die Entschlüsselung des Output-Dokuments entschlüsselt werden können.
  • Die eingefügten Verschlüsselungs-Tags können entweder Werte der Elemente oder Werte und Tags der Elemente umfassen.
  • Die vorliegende Erfindung wird nun mit Verweis auf die folgenden Zeichnungen beschrieben, wobei die Referenznummer auf das gleiche Element verweisen.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockdiagramm einer Computer Workstation-Umgebung, in der die vorliegende Erfindung ausgeführt werden kann;
  • 2 ist ein Diagramm einer vernetzten Computerumgebung, in der die vorliegende Erfindung ausgeführt werden kann;
  • 3 zeigt eine Document Type Definition (DTD), die mit Sicherheitsvorgabeninformationen erweitert wurde, entsprechend des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung;
  • 4a–4c zeigen ein Beispiel eines Mitarbeiterdokuments, mit dem die vorliegende Erfindung arbeiten kann, eine Interims-Darstellung des Mitarbeiterdokuments nach Erweiterung durch Sicherheitsinformationen und das gleiche Dokument nach Ausführung der Verschlüsselung;
  • 5a bis 5c zeigen Beispiele für Datensatz- oder Objektformate, die mit den bevorzugten Ausführungsbeispielen der vorliegenden Erfindung verwendet werden können;
  • 6 gibt einen Überblick der Komponenten, die in den bevorzugten Ausführungsbeispielen der vorliegenden Erfindung verwendet werden sowie die allgemeinen Datenflüsse zwischen diesen; und
  • 7 bis 12 zeigen Flussdiagramme mit der Logik, mit der die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung ausgeführt werden können.
    •
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
  • 1 zeugt eine repräsentative Workstation Hardware-Umgebung, in der die vorliegende Erfindung ausgeführt werden kann. Die Umgebung aus 1 umfasst eine repräsentative Einzelbenutzer-Computer Workstation 10, wie etwa einen Personal Computer, einschließlich damit verbundener peripherer Geräte. Die Workstation 10 umfasst einen Mikroprozessor 12 und einen Bus 14 zur Verbindung und Ermöglichung der Kommunikation zwischen dem Mikroprozessor 12 und den Komponenten der Workstation 10 in Übereinstimmung mit bekannten Techniken. Die Workstation 10 umfasst typischerweise einen Benutzerschnittstellen-Adapter 16, der den Mikroprozessor 12 über den Bus 14 mit einem oder mehreren Schnittstellengeräten verbindet, wie etwa einer Tastatur 18, Maus 20 und/oder anderen Schnittstellengeräten 22, bei denen es sich um ein beliebiges Schnittstellengerät handeln kann, wie etwa ein Touchscreen, digitalisiertes Eingabepad usw. Der Bus 14 verbindet ebenfalls ein Anzeigegerät 24, wie etwa einen LCD-Bildschirm oder Monitor mit dem Mikroprozessor 12 über einen Anzeigeadapter 26. Der Bus 14 verbindet ebenfalls den Mikroprozessor 12 mit dem Speicher 28 und einem Langzeitspeicher 30, der eine Festplatte, ein Diskettenlaufwerk, ein Bandlaufwerk usw. umfassen kann.
  • Die Workstation 10 kann mit anderen Computern oder einem Netzwerk aus Computern kommunizieren, beispielsweise über einen Übertragungskanal oder ein Modem 32. Alternativ dazu kann die Workstation 10 unter Verwendung einer drahtlosen Schnittstelle an 32, wie etwa einer CDPD (Cellular Digital Packet Data)-Karte, kommunizieren. Die Workstation 10 kann anderen Computern in einem LAN (Local Area Network) oder in einem WAN (Wide Area Network) zugeordnet werden, oder es kann sich bei der Workstation 10 um einen Client in einer Client/Server-Anordnung mit einem anderen Computer handeln usw. All diese Konfigurationen sowie die entsprechende Kommunikationshardware und Software sind Fachleuten bekannt.
  • 2 zeigt ein Datenverarbeitungsnetzwerk 40, in dem die vorliegende Erfindung ausgeführt werden kann. Das Datenverarbeitungsnetzwerk 40 kann eine Vielzahl an Einzelnetzwerken umfassen, wie etwa ein drahtloses Netzwerk 42 und ein Netzwerk 44, wobei jedes eine Vielzahl an einzelnen Workstations 10 umfassen kann. Zusätzlich dazu können, wie es den Fachleuten bekannt ist, ein oder mehrere LAN inbegriffen sein (nicht gezeigt), wobei ein LAN eine Vielzahl an intelligenten Workstations umfassen kann, die an einen Host-Prozessor gekoppelt sind.
  • 2 zeigt weiterhin, dass die Netzwerk 42 und 44 Großrechner oder Server umfassen können, wie etwa einen Gateway Computer 46 oder einen Anwendungsserver 47 (der auf ein Daten Repository 48 zugreifen kann). Ein Gateway Computer 46 dient als Eingangspunkt für jedes Netzwerk 44. Das Gateway 46 kann vorzugsweise mit einem anderen Netzwerk 42 gekoppelt werden, mittels eines Kommunikations-Links 50a. Das Gateway 46 kann ebenfalls direkt mit einer oder mehreren Workstations 10 gekoppelt werden, unter Verwendung eines Kommuniaktions-Links 50b, 50c. Der Gateway Computer 46 kann implementiert werden, unter Verwendung einer Enterprise Systems Architecture/370, erhältlich bei IBM, eines Enterprise Systems Architecture/390 Computers usw. Je nach Anwendung kann ein Computer mittlerer Größe, wie etwa ein Application System/400 (auch bekannt als AS/400) eingesetzt werden. ("Enterprise Systems Architecture/370" ist Warenzeichen von IBM; "Enterprise Systems Architecture/390", "Application System/400" und "AS/400" sind eingetragene Warenzeichen von IBM).
  • Der Gateway Computer 46 kann ebenfalls ein Speichergerät (wie etwa ein Daten Repository 48) umfassen. Weiterhin kann das Gateway direkt oder indirekt mit einer oder mehreren Workstations 10 gekoppelt werden.
  • Fachleuten dürfte klar sein, dass sich der Gateway Computer 46 in großer geographischer Entfernung vom Netzwerk 42 befinden kann und ebenfalls können sich die Workstations 10 in großer Entfernung von den Netzwerken 42 und 44 befinden.
  • Beispielsweise kann sich das Netzwerk 42 in Kalifornien befinden, während das Gateway in Texas befindlich ist, oder eine oder mehrere Workstations können sich in New York befinden. Die Workstations 10 können mit dem drahtlosen Netzwerk 42 unter Verwendung eines Netzwerkprotokolls, wie etwa einem Transmission Control Protocol/Internet Protocol ("TCP/IP"), über eine Vielzahl an alternativen Verbindungsmedien verbunden sein, wie etwa einem Mobiltelefon, Funknetzwerken, Satellitennetzwerken usw. Das drahtlose Netzwerk 42 ist vorzugsweise mit dem Gateway 46 unter Verwendung einer Netzwerkverbindung 50a verbunden, wie etwa TCP oder UDP (User Datagram Protocol) über IP, X.25, Frame Relay, ISDN (Integrated Services Digital Network), PSTN (Public Switched Telephone Network) usw. Die Workstations 10 können alternativ dazu direkt mit dem Gateway 46 über Einwählverbindung 50b oder 50c verbunden sein. Weiterhin können das drahtlose Netzwerk 42 und 44 mit einem oder mehreren anderen Netzwerken (nicht gezeigt) auf analoge Weise, wie in 2 gezeigt, verbunden sein.
  • Auf Software-Programmierungscode entsprechend der vorliegenden Erfindung wird typischerweise über den Mikroprozessor 12 des Servers 47 oder über ein Zwischenmittel, wie etwa Gateway 46 (im folgenden einfach als Zwischenmittel bezeichnet) – und über Workstation 10 in mehreren Ausführungsbeispielen der vorliegenden Erfindung – zugegriffen, von Langzeitspeichermedien 30 verschiedener Art, wie etwa ein CD-ROM-Laufwerk oder ein Festplattenlaufwerk. Der Software-Programmierungscode kann sich auf jeder bekannten Art von Medium zur Verwendung in einem Datenverarbeitungssystem befinden, wie etwa einer Diskette, einer Festplatte oder CD-ROM. Der Code kann auf solchen Medien verteilt werden oder an Benutzer vom Speicher oder vom Speicher eines Computersystems über ein Netzwerk auf andere Computersysteme verteilt werden, zur Verwendung durch die Benutzer der anderen Computersysteme. Alternativ dazu kann der Programmierungscode im Speicher 28 enthalten sein, auf den der Mikroprozessor 12 unter Verwendung des Busses 14 zugreifen kann. Die Techniken und Methoden zur Eingabe von Software-Programmierungscode in Speicher auf physischen Medien und/oder die Verteilung von Softwarecode über Netzwerke sind den Fachleuten bekannt und werden im folgenden nicht weiter ausgeführt.
  • Ein Benutzer der vorliegenden Erfindung kann seinen Computer mit einem Server unter Verwendung einer Verbindung mit oder ohne Draht verbinden. Verdichtete Verbindungen sind solche, die physische Medien verwenden, wie etwa Kabel und Telefonleitungen, während drahtlose Verbindungen Medien wie Satelliten-Links, Funkwellen und Infrarot verwenden. Viele Verbindungstechniken können mit diesen verschiedenen Medien verwendet werden, beispielsweise: Verwenden des Computermodems zur Erstellung einer Verbindung über eine Telefonleitung, verwenden einer LAN-Karte, wie etwa Token Ring oder Ethernet, Verwenden eines Mobilmodems zur Erstellung einer drahtlosen Verbindung usw. Bei dem Computer des Benutzers kann es sich um jede Art von Computer handeln, einschließlich Laptop, Handgerät oder Mobilcomputer, fest installierte Geräte, Desktop Computer, Großrechner usw., die über Verarbeitungsmöglichkeiten (und optional über Kommunikationsmöglichkeiten) verfügen. Beim entfernten Server und dem Zwischenmittel kann es sich um einen der verschiedenen Computer handeln, die über Verarbeitungs- und Kommunikationsmöglichkeiten verfügen. Diese Techniken sind den Fachleuten bekannt, und die Hardwaregeräte sowie die Software zu deren Einsatz sind bereits erhältlich. Im folgenden wird der Computer des Benutzers als "Workstation", "Gerät" oder "Computer" bezeichnet und die Verwendung einer dieser Begriffe oder des Begriffs "Server" bezieht sich auf jede Art der oben beschriebenen Computergeräte.
  • In den bevorzugten Ausführungsbeispielen wird die Erfindung als ein oder mehrere Computer-Softwareprogramme implementiert. Die Software kann auf einem Server, auf einer Workstation und/oder auf einem Zwischenmittel in einem Netzwerk als ein oder mehrere Module (auch als Code-Subroutinen oder "Objekte" in der objektorientierten Programmierung bezeichnet) ausgeführt werden, die bei Anforderung aufgerufen werden. Der Server oder das Zwischenmittel können Services in einer Internet-Umgebung, in einem firmeneigenen Intranet oder Extranet oder in jeder anderen Netzwerkumgebung bieten.
  • Die vorliegende Erfindung definiert eine neuartige Technik zur selektiven Unterstützung von Sicherheitsvorgaben in einer verteilten Netzwerk-Computer-Umgebung unter Verwendung von Stylesheet-Verarbeitung. Ein vorgabenorientierter, erweiterter Stylesheet-Prozessor wird verwendet, um ein selektiv verschlüsseltes Dokument mit Schlüsselverteilungsmaterial zu erstellen, so dass durch Verwendung eines erweiterten Dokumentprozessors ein Agent ein Document Object Model ("DOM") wiederherstellen kann, das nur die Informationselemente enthält, für die der Agent über eine Berechtigung verfügt. In den bevorzugten Ausführungsbeispielen handelt es sich bei dem erweiterten Stylesheet-Prozessor um einen Extensible Stylesheet Language ("XSL")-Prozessor, das Dokument ist ein XML-Dokument und der erweiterte Dokument-Prozessor ist eine erweiterte XML-Verarbeitungsengine. Auf diese Weise codierte Dokumente unterstützen verbesserte Gruppenarbeitsmodelle, wodurch die Benutzer leichteren Zugang zu Informationen erhalten, für die sie über eine Berechtigung verfügen, während sensible Daten vor Agents ohne Berechtigung geschützt werden. Die vorliegende Erfindung bietet weiterhin einen neuartigen, effizienten Weg zur Wiederherstellung von Daten aus codierten Dokumenten entsprechend den Erfindungstechniken, die hier offengelegt werden.
  • Eine Anzahl von Begriffen, die in dieser Beschreibung verwendet werden, sollen im folgenden definiert werden.
    • • "Gemeinschaft" bezeichnet die Sammlung an Benutzern, auf die eine gegebene Berechtigungsvorgabe Anwendung findet, hinsichtlich einer bestimmten Klasse von Informationen. Bei dem zuvor beschriebenen Beispiel des Mitarbeiterdatensatzes sind "Alle Vorgesetzten" oder "Mitarbeiter plus medizinisches Personal" Beispiele für potenzielle Gemeinschaften. In den bevorzugten Ausführungsbeispielen wird eine Gemeinschaft durch die Distinguished Names (DN) von einer oder mehreren Einzelpersonen und/oder Gruppen in der Gemeinschaft wiedergegeben. Für jeden DN besteht ein entsprechendes X.509 Zertifikat. In den bevorzugten Ausführungsbeispielen der vorliegenden Erfindung wird, sobald eine Gruppe durch ein einzelnes Zertifikat dargestellt werden kann, das Gruppenzertifikat anstelle aller anderen einzelnen Zertifikate der einzelnen Gruppenmitglieder bevorzugt (was mit Verweis auf 7A noch ausführlich beschrieben werden wird).
    • • "Elementsichtbarkeit" ist eine Vorgabe, die definiert, für wen (wobei es sich um Menschen und/oder Anwendungsprogramme oder Prozesse handeln kann) ein durch eine DTD (oder alternativ dazu durch ein Schema) definiertes Element sichtbar gemacht werden soll und unter welchen Bedingungen. Entsprechend der bevorzugten Ausführungsbeispiele definiert eine Sichtbarkeitsvorgabe (1) die erforderliche minimale Verschlüsselungsstärke für das Element und (2) die Gemeinschaft, die über eine Berechtigung zur Ansicht des Elementwerts verfügt. "Minimale Verschlüsselungsstärke" kann in einen bestimmten Verschlüsselungsalgorithmus und eine Schlüssellänge aufgelöst werden (beispielsweise durch Konsultieren eines Verzeichnisses oder einer Suchtabelle usw.). Verschlüsselungen, die stärker als erforderlich sind, können einer Elementsichtbarkeitsvorgabe entsprechen, eine Verschlüsselung, schwächer als erforderlich ist, ist jedoch niemals ausreichend. (Es ist zu beachten, dass die bevorzugten Ausführungsbeispiele die dynamische Bestimmung eines Algorithmus und einer Schlüssellänge beschreiben, um die minimale Verschlüsselungsstärke zu erzielen, die in einem Vorgabenobjekt angegeben wurde. In einem alternativen Ansatz dazu können der Algorithmus-Identifier und die Schlüssellänge direkt im Vorgabenobjekt angegeben werden, ohne dass vom Gegenstand der Erfindung abgewichen wird. In diesem Fall kann eine Bestimmung, aufgrund der mehrere Algorithmen und zugeordnete Schlüssellängen eine stärkere Verschlüsselung erhalten, vorgenommen werden, indem eine Suchtabelle verwendet wird, in der die pertinenten Werte in einer bestimmten Stärkereihenfolge angeordnet werden, durch Codieren der relativen Stärkewerte direkt in einer Implementierung usw. Es sollte den Fachleuten klar sein, auf welche Weise die Beschreibungen der bevorzugten Ausführungsbeispiele zu ändern sind, um diesen alternativen Ansatz zu nutzen.)
    • • "Gruppe" bezeichnet eine Sammlung von einem oder mehreren Einzelpersonen oder Prozessoren (beispielsweise Anwendungseinheiten), die berechtigte Mitglieder einer Gemeinschaft sind. Vorzugsweise wird eine Gruppe durch ein benanntes Objekt in einem LDAP-Verzeichnis dargestellt. (Alternativ dazu können andere Speicher-Repositories verwendet werden). Die gespeicherten Informationen für eine bestimmte Gruppe umfassen folgendes: (1) Das X.509 Zertifikat der Gruppe, (2) einen Zeiger (oder Identifier) zur Identifikation eines Gruppenverwalters oder Verwalters und (3) einen Zeiger für jedes Gruppenmitglied. (Die X.509 Zertifikate für jedes Gruppenmitglied werden dann in den gespeicherten Mitgliederinformationen festgehalten und es wird auf sie verwiesen). Wenn ein Proxy oder Agent über eine Berechtigung verfügt, im Namen der Gruppe oder einzelner Gruppenmitglieder zu handeln, wird der Proxy ebenfalls als Gruppenmitglied identifiziert.
    • • "Gruppenverwalter" bezeichnet einen Prozess, bei dem der private Schlüssel von jedem Mitglied gespeichert wird, damit nicht jedes einzelne Mitglied seinen privaten Schlüssel speichern muss. Der Verwalter wird während der Verschlüsselung von sicherem Dokumentinhalt kontaktiert, der an ein Gruppenmitglied geht, und bietet Informationen zur Verwendung im Verschlüsselungsprozess. Jede Gruppe verfügt über mindestens einen Verwalter. Es können auch mehrere Verwalter für eine einzelne Gruppe identifiziert werden, um Hot Backups und/oder Ladeverteilungen vorzunehmen, wobei jeder dieser Verwalter über die gleichen Verarbeitungsprivilegien für eine bestimmte Gruppe verfügt.
  • US-Patent US 6 585 778 B1 mit dem Titel "Enforcing Data Policy Using Stylesheet Processing" legt eine Technik zur Steuerung des Dokumentinhalts offen, unter Verwendung gespeicherter Vorgabeninformationen. Diese Erfindung, im Folgenden die "Referenz-Erfindung" genannt, wird hier als Referenz angegeben. Die vorliegende Erfindung definiert eine Erweiterung der gespeicherten Vorgabenobjekte, die in dieser Referenz-Erfindung definiert sind, wobei die gespeicherten Vorgabenobjekte weiterhin Attribute umfassen, die die oben beschriebenen Informationen zur Elementsichtbarkeit angeben. Diese Erweiterungen werden detaillierter unter Verweis auf 7A bis 7C beschrieben.
  • Der zuvor beschriebene Mitarbeiterdatensatz wird verwendet, um die Vorteile sowie die Implementierung der vorliegenden Erfindung zu beschreiben. In diesem Beispiel verfügt ein Unternehmen über eine Datenbank (oder ein anderes Repository) mit Informationen zu seinen Mitarbeitern. Weiterhin umfasst der für jeden Mitarbeiter gespeicherte Datensatz den Namen, die Nummer, das Einstellungsdatum, den derzeitigen Lohn sowie sämtliche medizinischen Informationen zu dem Mitarbeiter. 3 zeigt ein Beispiel für eine DTD 300, die zur Beschreibung der Daten im Datensatz für einen Mitarbeiter dieses Unternehmens verwendet werden kann. Wie in Fachkreisen bekannt, ist eine DTD eine Definition der Struktur eines XML-Dokuments und ist in einer Datei codiert, die durch einen XML-Parser verarbeitet werden soll, zusammen mit der Datei, in der sich ein bestimmtes XML-Dokument befindet. Die DTD teilt dem Parser mit, wie das Dokument interpretiert werden soll, das entsprechend der DTD erstellt wurde. (Es ist zu beachten, dass die Erfindung unter Verweis aus Informationen beschrieben wird, die in einer DTD angegeben. Die Informationen können jedoch ebenfalls in anderer geeigneter semantischer Form festgelegt werden. Vor allem die Schemata, die derzeit durch das World Wide Web Consortium standardisiert werden, können anstelle der DTD verwendet werden. Siehe "XML Schema Part 1: Structures", was sich im Internet unter http://www.w3.org/TR/xmlschema-1/ befindet, um weitere Informationen zu erhalten. In diesem Dokument gemachte Verweise auf eine DTD sollen so verstanden werden, dass hier ebenfalls Schemata anwendbar sind.) Diese DTD 300 umfasst Einträge für den Mitarbeiternamen ("empl_name") 350, der Seriennummer ("ser_nbr") 360, "date_of_hire" 370, "curr_salary" 380 und medical_condition" 390.
  • Diese DTD 300 wurde durch Informationen zu Datenvorgaben erweitert, die entsprechend der vorliegenden Erfindung Informationen zur Elementsichtbarkeit enthalten, die wiederum verwendet werden können, um die zugeordneten Dokumentelemente selektiv zu verschlüsseln, womit der Zugriff auf die Werte der Dokumentelemente beschränkt wird. Wie durch die Referenz-Erfindung definiert, können Datenvorgaben (durch die vorliegende Erfindung um die Elementsichtbarkeit erweitert) den Datenstrukturen eines Dokuments zugeordnet werden, indem die DTD für das Dokument zur Angabe der URI (Uniform Resource Indicator) für jede anwendbare Vorgabe geändert wird. Es werden drei verschiedene Datenvorgaben herangezogen, jede mit einer anderen Elementsichtbarkeit, um das Beispiel des Mitarbeiterdatensatzes näher zu erläutern. Jede Vorgabe wird nun zusammen mit den angegebenen Informationen zur Elementsichtbarkeit in den gespeicherten Vorgabenobjekten beschrieben.
  • Die verwendete Vorgabe für Mitarbeitername, Seriennummer und Einstellungsdatum bietet unbeschränkten Zugriff auf diese Datenelemente. Datenvorgabeninformationen zur Unterstützung dieses unbeschränkten Zugriffs (sowie jede andere Vorgabe, die mit dieser Erfindung verwendet wird) wird vorzugsweise in einer Verzeichnisdatenbank gespeichert, wie etwa eine LDAP-Datenbank. Die gespeicherte Vorgabe kann dann durch Senden einer Nachricht an die Datenbank-Engine abgerufen werden, die die URI der gewünschten Informationen enthalten muss, wie im folgenden noch detaillierter beschrieben. Eine Beispiel-URI, wie sie zum Abrufen der "unbeschränkten" Vorgabeninformationen für dieses Beispiel verwendet werden kann, wird in Element 332 gezeigt. Es ist zu beachten, dass XML-Parametereinheiten in dieser Beispiel-DTD 300 ersetzt wurden, wobei die relativ langen URIs 321, 322, 332 als der Wert angegeben werden, der kürzeren Einheitennamen 311, 321, 331 zugeordnet wird. Diese kürzeren Namen werden dann in den Attributlistenerklärungen verwendet, beispielsweise "%unrestricted" 355 in der Erklärung empl_name 350. Dieser Ansatz bietet den Vorteil einer verringerten Zahl an Zeichen in der DTD, wenn eine URI wiederholt verwendet wird und die Attributlistenerklärungen werden intuitiver gestaltet und leichter zu lesen. (Offensichtlich können die URIs alternativ dazu in der DTD repliziert werden, ohne dass vom Gegenstand der vorliegenden Erfindung abgewichen wird). Es ist zu beachten, dass die URIs 312, 322, 332 als Relative Distinguished Names (RDN) für die gespeicherten Datenvorgabeninformationen gezeigt wurden. Diese RDN sind einfach eindeutige Identifier zum Speichern des Objekts in einem Verzeichnis. Alternative Speichertechniken (in Identifikationen davon) können verwendet werden, ohne vom Gegenstand der vorliegenden Erfindung abzuweichen.
  • Da der Zugriff auf den Mitarbeiternamen, die Seriennummer und das Einstellungsdatum unbeschränkt ist, werden die Werte dieser Dokumentelemente nicht im Dokument verschlüsselt, das an einen Dokumentanforderer ausgeben wird. Somit werden die minimale Sicherheitsstärke und Gemeinschaftsattribute des an Speicherort 332 gespeicherten Vorgabenobjekts vorzugsweise auf Null gesetzt (um anzugeben, dass eine Verschlüsselung nicht notwendig ist).
  • Eine weitere Vorgabe, die beim Mitarbeiterdatensatz verwendet wird, dient der Beschränkung des Zuriffs auf den derzeitigen Lohn des Mitarbeiters auf den Mitarbeiter selbst sowie auf die Vorgesetzten im Unternehmen und Mitarbeiter der Personalabteilung des Unternehmens. Die URI für diese Vorgabe erhält den Einheitennamen "empl_mgr_hr" 311 und wird angegeben 385 in der Attributlistenankündigung für curr_salary 380. Das gespeicherte Vorgabenobjekt an der URI 312 gibt die Verschlüsselungsstärke an, die zum Schutz der Lohninformationen dieses Mitarbeiters vor unberechtigtem Zugriff geeignet ist. Das Gemeinschaftsattribut im Vorgabenobjekt umfasst vorzugsweise drei Distinguished Name Werte, einen für den einzelnen Mitarbeiter, einen für die Gruppe der Vorgesetzten und einen für die Gruppe mit allen Mitarbeitern der Personalabteilung. (Alternativ dazu kann ein separater DN-Eintrag für jedes Mitglied der Vorgesetztengruppe und/oder für jedes Mitglied der Personalabteilung angegeben werden, doch wie zuvor erklärt, ist es von Vorteil, alle Mitglieder einer Gruppe durch einen Gruppen-DN darzustellen, wenn der Gruppen-DN zur Verfügung steht.)
  • Die dritte Vorgabe in diesem Beispiel wird für die medizinischen Informationen verwendet. Der Zugriff zu diesen Informationen soll nur auf den Mitarbeiter beschränkt werden, auf den sich diese Informationen beziehen, sowie auf jeden Mitarbeiter in der medizinischen Abteilung. Informationen zur Unterstützung dieser Vorgabe (einschließlich der Beschränkungen der Elementsichtbarkeit) mit dem Einheitennamen "empl_medical" 321 werden an der URI 322 gespeichert. Die Vorgabe wird dem Element medical_condition 390 unter Angabe 395 der URI 322 über den Einheitennamen 321 zugeordnet. Das gespeicherte Vorgabenobjekt an der URI 322 gibt die Verschlüsselungsstärke an, die geeignet ist, um die medizinischen Informationen über den Mitarbeiter ausreichend zu schützen, und das Gemeinschaftsattribut im Vorgabenobjekt umfasst vorzugsweise zwei Distinguished Names Werte, einen für den einzelnen Mitarbeiter und einen für die Gruppe mit allen Mitarbeitern der medizinischen Abteilung. (Wie oben beschrieben, kann alternativ dazu ein separater DN-Eintrag für jedes Mitglied der medizinischen Gruppe angegeben werden, ohne dass vom Gegenstand der Erfindung abgewichen wird.)
  • Die verwendete Lösung in den bevorzugten Ausführungsbeispielen – Angabe einer Datenvorgaben-URI innerhalb einer Attributlistenankündigung eines Datenelements – ermöglicht die Codierung selbst hochkomplexer Anordnungen mit einer unterschiedlichen Vorgabe und unterschiedlicher Elementsichtbarkeit (auch wenn diese Situation tatsächlich sehr selten eintritt). Wie bei der Beispiel-DTD in 3 zu sehen ist, werden für die bevorzugten Ausführungsbeispiele Standard-DTD-Markups mit einer speziellen Konvention verwendet. Auf diese Weise können Prozesse ohne Kenntnis der Vorgabenkonvention dennoch absolut gültige XML-Syntax anzeigen, die alle Standardvalidierungstests besteht, wenn das entsprechende Dokument Vorgaben-Markups enthält. Ein vorteilhafter Nebeneffekt davon ist, dass wenn das durch eine Datenquelle erstellte Dokument eine URI DTD Referenz verwendet (wie etwa Element 405 des Dokuments 400 in 4A, das auf den Speicherort der Beispiel-DTD 300 in 3 verweist), ein firmeneigener Administrator für die Datenvorgaben dafür sorgen kann, dass Beschränkungen der Datenvorgaben und Elementsichtbarkeit auf solche generierten Dokumente verwendet werden, indem einfach die Referenz-DTD geändert wird (um Vorgabendefinitionen und Elementsichtbarkeit hinzuzufügen oder möglicherweise, um die bereits hinzugefügten Vorgabendefinitionen und Elementsichtbarkeit zu ändern). Es muss keine Änderung am Code zur Generierung der XML-Quelldokumente an der Datenquelle vorgenommen werden, damit die geeignete Verschlüsselung sowie Zugriffsbeschränkungen Anwendung finden.
  • Die Konvention gibt vor, dass DTD-Vorgaben-Markup der bevorzugten Ausführungsbeispiele ein festes Attribut (siehe beispielsweise 354 in 3) von einem Vorgabennamensbereich (siehe 352 in 3) verwendet, um die URI der Vorgabe anzugeben, die auf ein XML-Element anzuwenden ist. Wie den Fachleuten bekannt ist, ermöglicht die Verwendung eines Namensbereich-Präfixes die Unterscheidung zwischen Tags, die andernfalls als Duplikate angesehen werden könnten. Durch das Setzen eines festen Wertes wird sichergestellt, dass der Wert dieses Attributs (wie etwa der Wert 355 von Attribut 353) dem XSL-Prozessor zur Verfügung steht, sobald dieser das Element (etwa das Element empl_name 351) verarbeitet.
  • 4A zeigt ein einfaches Quelldokument 400, als Ergebnis eines Abrufens der Informationen im Mitarbeiterdatensatz für einen bestimmten Mitarbeiter (identifiziert durch den Namen bei 402 und durch die Seriennummer bei 404), bevor die Verarbeitung entsprechend der vorliegenden Erfindung stattgefunden hat. Dieses Quelldokument 400 enthält Volltextinformationen für alle Dokumentelemente des Mitarbeiterdatensatzes, einschließlich schützenswerter Elemente wie "curr_salary" 408 und "medical_condition" 410 (die verschlüsselt werden müssen, unter Verwendung der gespeicherten Vorgabenobjekte, angegeben bei 385 und 395 in 3). Die Beispiel-DTD in 3 würde dann durch einen erweiterten XSL-Prozessor verwendet, wie unten beschrieben, um die gewünschten Regeln für die Datenvorgabe und Elementsichtbarkeit anzuwenden, um eine selektiv verschlüsselte Version dieses Dokuments 400 vor Veröffentlichung des verschlüsselten Dokuments oder vor Versendung des verschlüsselten Dokuments zu erstellen. Es ist zu beachten, dass weder Vorgaben-Markup noch Referenzen für die Vorgabe im Dokument 400 bestehen und somit, wie oben beschrieben, kein Bedarf besteht, den XML-Emitter der dokumentgenerierenden Anwendung an der Datenquelle zu ändern.
  • In 4C wird ein repräsentatives Beispiel eines selektiv verschlüsselten Dokuments mit Informationen aus dem Quelldokument 400 an 450 gezeigt. Auf der Grundlage der Beispiele für Vorgabe und Elementsichtbarkeit, beschrieben unter Verweis auf 3, wenn der anfordernde Benutzer der Mitarbeiter 402 ist, ist dieser Benutzer in der Lage, die geschützten Werte für curr_salary 408 und medical_condition 410 in den verschlüsselten Feldern 452, 454 (wobei diese Felder 452, 454 lediglich Werte zur übersichtlichen Darstellung enthalten) des Dokuments 450 wiederherzustellen (das heißt zu entschlüsseln), das als Reaktion auf seine Anforderung ausgegeben wird. Zusätzlich dazu, da entsprechend dieser Erfindung selektiv verschlüsselte Dokumente nicht für einen bestimmten anfordernden Benutzer angepasst werden, jedoch ausreichendes Schlüsselverteilungsmaterial mit sich bringen, um jedem berechtigten Benutzer Zugriff zu gewähren, ist der Mitarbeiter 402 in der Lage, die geschützten Werte 453, 455 der Felder 452, 454 wiederherzustellen, auch wenn er nicht der ursprüngliche Anforderer des verschlüsselten Dokuments ist. Ebenso ist ein Benutzer, der Vorgesetzter in seinem Unternehmen ist oder der in der Personalabteilung arbeitet, in der Lage, den Wert 453 des verschlüsselten Feldes 452 wiederherzustellen, wenn er das Dokument 450 erhält, da diese Benutzer sich in einer Gemeinschaft mit der entsprechenden Berechtigung für das zugehörige Dokumentelement 408 befinden, und ein Benutzer in der medizinischen Abteilung ist in der Lage, den Wert 455 des verschlüsselten Feldes 454 wiederherzustellen. Wenn ein Benutzer, der kein Vorgesetzter und nicht der betroffene Mitarbeiter ist und nicht in der Personalabteilung arbeitet, das verschlüsselte Dokument 450 empfängt, kann dieser Benutzer lediglich die Werte der unbeschränkten Dokumentelemente 402, 404 und 406 anzeigen, auch wenn sich die Werte curr_salary und medical_condition ebenfalls in der Kopie des Dokuments 450 befinden. Die Art, in der ein erweiterter Stylesheet-Prozessor die Regeln zur Datenvorgabe und Sichtbarkeit einsetzt, um diese Ergebnisse entsprechend der vorliegenden Erfindung zu erhalten, werden im folgenden beschrieben. (Stylesheet-Verarbeitung kann zusätzliche Änderungen am Quelldokument 400 beim Prozess des Generierens eines verschlüsselten Dokuments durchführen, wie etwa Formatieren der Informationen aus dem Mitarbeiterdatensatz in ein vordefiniertes Layout oder Ausführen zielspezifischer Transformationen, die nicht mit der Datenvorgabe oder der Elementsichtbarkeit verbunden sind, unter Verwendung von Techniken, die in Fachkreisen bekannt und nicht Teil der vorliegenden Erfindung sind).
  • Entsprechend der bevorzugten Ausführungsbeispiele der vorliegenden Erfindung wird der Prozess der selektiven Verschlüsselung eines Dokuments als zwei logische Phasen implementiert. Die erste Phase wird hier als "Vorverarbeitungs"phase bezeichnet. Die erweiterte DTD 300, beschrieben unter Verweis auf 3, ein Quelldokument, wie etwa Dokument 400 aus 4A und die gespeicherten Vorgabenobjekte sowie deren Sichtbarkeitsregeln (nicht gezeigt) werden als Input in der Vorverarbeitungsphase verwendet. Die zweite Phase wird hier als "Nachbearbeitungs"phase bezeichnet. Das verschlüsselte Dokument 450, einschließlich des verschlüsselten Schlüsselverteilungsmaterials 460 wird als Ergebnis der Nachbearbeitungsphase generiert.
  • Die 5A bis 5C zeigen bevorzugte Ausführungsbeispiele des Formats für Datensätze oder Objekte (im folgenden als "Objekte" bezeichnet), die während der Verarbeitung entsprechend der vorliegenden Erfindung erstellt und verwendet werden, um die hier offengelegte selektive Verschlüsselungstechnik auszuführen und die ebenfalls während der entsprechenden Verschlüsselungstechniken verwendet werden. Der Inhalt und das Format für jedes dieser Objekte wird nun beschrieben. (Die Art, in der die Objekte während der Verarbeitung der bevorzugten Ausführungsbeispiele erstellt und verwendet werden, wird nun detaillierter und unter Verweis auf die Logik in den 7 bis 12 beschrieben.)
  • 5A zeigt das Layout eines Objekts, hier als "Schlüsselobjekt" bezeichnet. Entsprechend den bevorzugten Ausführungsbeispielen wird eine Version 500 dieses Schlüsselobjekts intern von Verschlüsselungsverarbeitung verwendet und eine zweite Version 510 wird zusammen mit dem verschlüsselten Objekt übertragen, mit dem es verwendet wurde. Beide Versionen 500, 510 umfassen einen Distinguished Name (DN) 501. Die Version 500 des Schlüsselobjekts umfasst ein X.509 Zertifikat 502a entsprechend dieses DN, während Version 501 das Zertifikat durch einen "keyIdentifier" 502b (siehe RFC 2459: "Internet X.509 Public Key Infrastructure Certificate and CRL Profile"), ersetzt, der verwendet werden kann, um das Zertifikat 502a in Verbindung mit dem DN in einem Verzeichnis oder einem anderen Repository zu lokalisieren. Zuletzt enthalten beide Versionen 500 und 510 einen verschlüsselten symmetrischen Schlüssel 503. Das X.509 Zertifikat 502a enthält den öffentlichen Schlüssel 505, der zur Erstellung des verschlüsselten symmetrischen Schlüssels 503 verwendet wurde (wie weiter unten noch detailliert beschrieben wird). Die im Feld "Betreff" 504 des Zertifikats genannte Einheit enthält den privaten Schlüssel entsprechend dem öffentlichen Schlüssel 505 und kann diesen privaten Schlüssel verwenden, um den symmetrischen Schlüssel 503 zu entschlüsseln. (Es ist zu beachten, dass sich der Wert des Feldes Betreff des Zertifikats 504 vom Wert des Feldes DN 501 unterscheiden kann.) Der keyIdentifier 502b ist ein kurzer "Fingerabdruck", der zur Identifikation des Zertifikats 502a verwendet werden kann, zu dem er gehört, beispielsweise beim Suchen in den Zertifikaten in einem Schlüsselring oder einer -kette oder beim Suchen in Zertifikaten, die von einer Verzeichnis- oder Datenbanksuche ausgegeben wurden. Wie in Fachkreisen bekannt, sind X.509 Zertifikate recht groß. Unter Verwendung der Kurzmitteilung 502b beim Übertragen eines verschlüsselten Dokuments kann Platz im verschlüsselten Dokument gespart werden, während semantisch äquivalente Informationen weitergegeben werden. Das gesamte Zertifikat 502a kann jedoch alternativ dazu mit dem verschlüsselten Dokument übertragen werden, anstatt die Version 510 des Schlüsselobjekts und seinen keyIdentifier 502b zu verwenden, ohne vom Gegenstand der vorliegenden Erfindung abzuweichen.
  • Wie in Fachkreisen bekannt, erfordern einige sichere Übertragungsprotokolle ein digitales Zertifikat zum Verschlüsseln von Daten sowie ein weiteres zur Verwendung beim Erstellen einer digitalen Signatur. Die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung gehen von der Verwendung einer SSL-Sitzung aus, wobei nur ein einzelnes Zertifikat notwendig ist. Es ist offensichtlich für die Fachleute, wie die Beschreibung der bevorzugten Ausführungsbeispiele zu ändern ist, wenn zwei Zertifikate verwendet werden. In einem solchen Fall von zwei Zertifikaten stellt das Zertifikat 502a das Verschlüsselungszertifikat dar.
  • Die Schlüsselobjekte 500, 510 wurden zunächst während der Vorverarbeitungsphase der vorliegenden Erfindung erstellt. Der verschlüsselte symmetrische Schlüsselwert 503 wird in der Nachbearbeitungsphase erstellt.
  • 5b zeigt das Format eines Objekts, das hier als "Vorverarbeitungsschlüsselklassen"objekt 520 bezeichnet wird. Vorverarbeitungsschlüsselklassenobjekte werden intern von der vorliegenden Erfindung sowohl während der Vorverarbeitungs- als auch während der Nachbearbeitungsphase verwendet. Jedes Vorverarbeitungsschlüsselklassenobjekt 520 umfasst einen Verschlüsselungsstärken-Identifier 521 (der aufgelöst werden kann, um einen bestimmten Verschlüsselungsalgorithmus und eine Schlüssellänge zu identifizieren, beispielsweise durch Konsultieren eines Verzeichnisses oder einer Suchtabelle), eine Schlüsselklasse 522 und einen nicht verschlüsselten symmetrischen Schlüssel 523. Der Wert des symmetrischen Schlüsselfelds 523 wird während der Nachbearbeitungsphase erstellt.
  • 5C zeigt das Format eines Objekts, hier als "Schlüsselklassen"objekt 530 bezeichnet. Eine Schlüsselklasse definiert eine Gemeinschaft, die über eine Berechtigung zum Zugriff auf ein Element verfügt und die Art der Verschlüsselung, die für dieses Element ausgeführt werden soll. Mehr als ein Element kann eine einzelne Schlüsselklasse gemeinsam nutzen, vorausgesetzt, dass die Gemeinschaftsmitglieder zwischen den gemeinsam nutzenden Elementen identisch sind. Jedes Schlüsselklassenobjekt 530 umfasst eine Identifikation der Schlüsselklasse 531, einen Algorithmus-Identifier 532 (zur Identifikation des zu verwendenden Algorithmus für Dokumentelemente, die dieser Schlüsselklasse 531 zugeordnet sind), eine Schlüssellänge 533, ein optionales Feld 534 zur Angabe weiterer Hinweise, die zur Ausführung des Algorithmus erforderlich sein können sowie ein oder mehrere Schlüsselobjekte (allgemein gezeigt in den 5C als 535, 536 bis 539).
  • Schlüsselklassenobjekte 530 entsprechend dem einzelnen Vorverarbeitungsschlüsselklassenobjekt 520 werden während der Nachbearbeitungsphase erstellt und durch die Nachbearbeitungsphase in das DOM-Stammverzeichnis des Dokuments eingefügt, das mit diesen Schlüsselklasseobjekten verschlüsselt wurde.
  • Ein Schlüsselobjekt 535, 536 bis 539 besteht vor allem in einem bestimmten Schlüsselklassenobjekt 530 für jedes Gemeinschaftsmitglied innerhalb der Schlüsselklasse 531. Ein Schlüsselobjekt 500 oder 510 wird für jeden DN 501 erstellt, und ein solches Schlüsselobjekt umfasst einen verschlüsselten symmetrischen Schlüssel 503. Somit umfasst ein Schlüsselklassenobjekt 530 für eine Schlüsselklasse 531 mit 3 Gemeinschaftsmitgliedern 3 Schlüsselobjekte 535, 536, 539 und von daher auch 3 verschiedene verschlüsselte symmetrische Schlüsselwerte 503 (das heißt, ein anderer symmetrischer Schlüsselwert für jede Gemeinschaft). Für das Beispiel des Mitarbeiterdatensatzes, bei dem der Mitarbeiter, die Vorgesetzten und die Mitarbeiter der Personalabteilung die drei Mitglieder der berechtigten Gemeinschaft zur Anzeige der aktuellen Lohninformationen umfassen, umfasst das Schlüsselklassenobjekt 530 Schlüsselobjekte mit unterschiedlichen verschlüsselten Schlüsseln 503 für jedes Mitglied. Diese drei verschiedenen symmetrischen Schlüsselwerte werden aus dem einzelnen, nicht verschlüsselten Schlüsselwert 523 erstellt, der im Vorverarbeitungsschlüsselobjekt 520 gespeichert ist. Der öffentliche Schlüssel 505 vom Schlüsselobjekt für jedes Gemeinschaftsmitglied wird verwendet, um die verschiedenen symmetrischen Schlüsselwerte zu generieren. Um die Informationen curr_salary zu entschlüsseln, lokalisiert der Vorgang für ein Mitglied der Vorgesetztengruppe ("managers") das Vorgesetzenschlüsselobjekt unter den Objekten 535, 536, 539 durch Vergleichen des Vorgesetztengruppe-DN mit den DN-Werten 501, ruft den verschlüsselten symmetrischen Schlüsselwert 503 vom entsprechenden Schlüsselobjekt ab und entschlüsselt diesen symmetrischen Schlüssel unter Verwendung des privaten Schlüssels für die Vorgesetztengruppe. Dieser entschlüsselte Schlüssel kann dann verwendet werden, um die Information curr_salary zu entschlüsseln. Ähnlich ist es, wenn ein Mitglied der Personalabteilung (HR) auf curr_salary zugreifen möchte: Der DN für die Gruppe Personalabteilung wird verglichen mit den DN-Werten in den Objekten 535, 536, 539, um das Schlüsselobjekt für die Gruppe Personalabteilung zu lokalisieren. Der entschlüsselte Schlüsselwert 503 wird dann abgerufen und mit dem privaten Schlüssel des Mitglieds der Gruppe Personalabteilung entschlüsselt. Dieser entschlüsselte private Schlüssel wird dann vom Mitglied der Gruppe Personalabteilung verwendet, um den Wert curr_salary zu entschlüsseln.
  • Auf diese Weise verteilen die über selektive Verschlüsselung erstellten Dokumente entsprechend der vorliegenden Erfindung auf sichere Art Schlüsselmaterial, das zur Entschlüsselung durch einen Empfängerkreis verwendet werden kann, der bei Erstellung der Dokumente noch unbekannt ist.
  • Die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung werden nun detailliert und unter Verweis auf die 6 bis 12 erläutert. 6 gibt einen Überblick über die Software-Komponenten, die in mehreren der bevorzugten Ausführungsbeispiele verwendet werden. Die 7 bis 12 zeigen die Logik, die verwendet werden kann, um die bevorzugten Ausführungsbeispiele zu implementieren.
  • 6 zeigt Backend-Server 605 für e-commerce, eine e-commerce Infrastruktur 625, einen e-commerce Client 655 (dieser wird in einigen Fällen als Server bezeichnet, wenn er als Proxy für einen Browser Client eingesetzt wird), einen standardmäßigen Browser Client 675 und einen Programm-Client 680. Drei Prozesse werden auf dem e-commerce Server 605 gezeigt: ein XSL-Vorprozessor 610 und ein XSL-Nachprozessor 620 entsprechend der vorliegenden Erfindung, sowie ein Transcoding Proxy 615. Der XSL-Vorprozessor 610 führt die Vorverarbeitungsphase des Verschlüsselungsprozesses aus, und der XSL-Nachprozessor (bei dem es sich um die gleiche Software-Komponente handeln kann wie bei dem Vorprozessor 610) führt die Nachbearbeitungsphase aus. Die Prozesse in der e-commerce Infrastruktur 625 umfassen eine Administrator-Anwendung 630, eine Zertifikatsstelle (Certificate Authority = CA) 635, ein LDAP-Verzeichnis 640, verschiedene Web Server 645, eine Nachrichtenwarteschlange oder eine andere Transport-Infrastruktur 650 sowie einen Gruppenverwalter 670. Prozesse im e-commerce Client 655 umfassen einen XML-Vorparser 660 (definiert durch die vorliegende Erfindung zur Entschlüsselung selektiv verschlüsselter Dokumente, wie noch detaillierter beschrieben wird) und einen Gruppen Client 665. In einem Ausführungsbeispiel der vorliegenden Erfindung ist der Programm-Client Teil des e-commerce Clients 655. Alternativ dazu kann der Programm-Client 680 eine unabhängige Einheit analog zum Browser Client 675 sein, unterstützt vom e-commerce Client 655 in seiner Server-Rolle.
  • Es ist zu beachten, dass mehrere Komponenten aus 6 mit dem Begriff e-commerce belegt werden; dies dient Anschauungszwecken und stellt keine Einschränkung dar. Die vorliegenden Erfindung kann vorteilhafterweise mit Dokumenten eingesetzt werden, die über schützenswerte Informationen verfügen, die nicht kommerzieller Art sind.
  • Die Funktion des e-commerce-Backend-Servers 605 besteht in der Erstellung selektiv verschlüsselter Dokumente und im besonderen selektiv verschlüsselter XML-Dokumente. In der Vorverarbeitungsphase fragt der XSL-Vorprozessor 610 das Verzeichnis 640 ab, um die DTD sowie Datenvorgaben und Sichtbarkeitsregeln für verschiedene Dokumentelemente zu erhalten. Während in den bevorzugten Ausführungsbeispielen ein LDAP-Verzeichnis verwendet wird, sollte es den Fachleuten klar sein, dass auch eine andere Art von Verzeichnis oder Daten-Repository verwendet werden könnte, ohne dass vom Gegenstand der Erfindung abgewichen würde. Entsprechend wird ein LDAP-Verzeichnis 640 verwendet, um diese Vorgaben in eine bestimmte Verschlüsselungslänge (beispielsweise ein nummerierter Wert) und eine Gemeinschaft aufzulösen und um die X.509 Zertifikate zu erhalten, die zu den einzelnen Mitgliedern der Gemeinschaft gehören. Am Ende der Vorverarbeitungsphase passiert der Vorprozessor 610 eine Arbeitsdarstellung der Daten, wie etwa eine DOM-Baumdarstellung bis zur nächsten Verarbeitungsstufe, wie etwa ein Transcoding Proxy 615, falls vorhanden für die weitere Verarbeitung, andernfalls geht er direkt zum XSL-Nachprozessor 620 über. Die Zwischenstufe 615 gibt den gesamten Output an den XSL-Nachprozessor 620 weiter, der entsprechend der vorliegenden Erfindung definiert ist. Während der Nachbearbeitungsphase kontaktiert der XSL-Nachprozessor 620 das LDAP-Verzeichnis 640, um die Verschlüsselungsstärke in einen spezifischen Verschlüsselungsalgorithmus und eine Schlüssellänge (falls diese Informationen nicht direkt im Vorgabenobjekt gespeichert wurden) aufzulösen und um einen KeyIdentifier entsprechend einem X.509 Zertifikat zu erhalten. Wenn das selektiv verschlüsselte XML-Dokument vom e-commerce-Server 605 erstellt wurde, wird das Dokument den Benutzern zugänglich gemacht, die es (beispielsweise durch Speichern auf Web Servern) anfordern können, über einen Transportmechanismus, wie etwa Nachrichtenwarteschlangen 650 an andere Speicherorte versendet usw.
  • Der Transport und die Speicherung von Details sind nicht Teil dieser Erfindung, anders als die Beobachtung, dass bei nun entschlüsselten empfindlichen Teilen des Dokuments kein Bedarf für Nachrichtenwarteschlangen oder andere Server oder Agents besteht, die die XML Daten mit spezieller Verschlüsselungsunterstützung bearbeiten, um den Dokumentinhalt zu schützen; die schützenswerten Dokumentelemente sind bereits geschützt. Weiterhin können Agents, die bestimmte Dokumentfelder untersuchen müssen, beispielsweise zum Zwecke des Transaktions-Routings, entweder über eine Berechtigung zum Entschlüsseln nur dieser Felder verfügen, oder diese Felder werden leer gelassen.
  • Eine Administrations-Anwendung 630, definiert entsprechend der vorliegenden Erfindung (detailliert beschrieben unter Verweis auf 12), interagiert mit dem LDAP-Verzeichnis 640, der Zertifikatsstelle (Certificate Authority = CA) 635, dem Browser Client 675, dem Programm-Client 680, dem Gruppenverwalter 670 und dem e-commerce-Client 655 bei der Ausführung ihrer Funktionen. Der Administrator kann eine Gruppe erstellen, ändern oder löschen; eine einzelne Einheit (wie etwa einen Browser Client 675, einen Programm-Client 680, einen e-commerce Client 655 in seiner Funktion als Proxy/Server für einen Browser Client 675 oder einen Gruppenverwalter 670) erstellen, ändern oder löschen, eine Einheit einer Gruppe zuordnen, eine Einheit aus einer Gruppe entfernen, ein Zertifikat für eine Gruppe oder eine einzelne Einheit neu zuordnen, erneuern oder zurückrufen, eine Datenvorgabe erstellen, ändern oder löschen; eine Gemeinschaftsdefinition erstellen, ändern oder löschen, eine Verschlüsselungsstärkedefinition erstellen, ändern oder löschen, Informationen zur Elementsichtbarkeit in einer Datenvorgabe erstellen, ändern oder löschen, eine DTD erstellen, ändern oder löschen, was noch in 12 näher erklärt wird.
  • Der XML-Vorparser 660 versucht eine Entschlüsselung der selektiv verschlüsselten XML-Daten. Für Schlüsselobjekte, die mit Hilfe eines Gruppenschlüssels gesperrt wurden, kontaktiert der Vorparser 660 die Komponente lokaler Gruppen-Client 665. Der Gruppen-Client kontaktiert das LDAP-Verzeichnis 640 zur Lokalisierung des für die Gruppe definierten Verwalters. Dann kontaktiert der Gruppen-Client 665 den Gruppenverwalter 670, um das Schlüsselobjekt zu entschlüsseln. Der Gruppenverwalter 670 kontaktiert das LDAP-Verzeichnis 640, um die X.509 Zertifikate zu ermitteln, die dem Anforderer zugeordnet wurden sowie die Agents (einer oder mehrere der folgenden: e-commerce-Client 655 selbst oder als Proxy, der Browser Client 675 und/oder Programm-Client 680). Der Verwalter 670 fragt ebenfalls das LDAP-Verzeichnis ab, um zu validieren, ob eine gegebene Einheit Mitglied einer gegebenen Gruppe ist. In einem Ausführungsbeispiel der vorliegenden Erfindung werden der Gruppenverwalter 670 und der e-commerce-Client 655 auf der gleichen Hardware-Plattform implementiert.
  • Die Logik, mit der die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung implementiert werden können, wird nun unter Verweis auf die Flussdiagramme in den 7 bis 12 beschrieben. Die 7A bis 7C zeigen den Prozess, mit dem ein Dokument selektiv verschlüsselt werden kann, entsprechend der vorliegenden Erfindung. In einem bevorzugten Ausführungsbeispiel empfängt ein einzelner Benutzer (der ein berechtigtes Mitglied von mindestens einer Gemeinschaft sein kann, für die das Dokument selektiv verschlüsselt wurde) das verschlüsselte Dokument auf seiner Client Workstation und führt einen Verschlüsselungsprozess auf dieser Workstation aus. Dieses Szenario wird in der Logik der 8A und 8B dargestellt. In einem anderen bevorzugten Ausführungsbeispiel kann eine Workstation eines Benutzers über genügend Arbeitsleistung verfügen, um den Verschlüsselungsprozess der vorliegenden Erfindung auszuführen, oder es ist wünschenswert, eine Änderung der Umgebung der Benutzerworkstation zu umgehen, so dass der Code der vorliegenden Erfindung lokal ausgeführt werden kann, so führt ein Client Proxy die Entschlüsselung für den Benutzer aus. Dieses Szenario wird in der Logik der 9A und 9B gezeigt. In noch einem weiteren bevorzugten Ausführungsbeispiel wird das verschlüsselte Dokument von einem Mitglied einer Gruppe empfangen, wobei es sich bei der Gruppe um ein berechtigtes Mitglied einer Gemeinschaft handeln kann, die Zugriff auf mindestens ein Element des selektiv verschlüsselten Dokuments hat. Die Art, in der der Verschlüsselungsprozess für dieses Ausführungsbeispiel ausgeführt wird, wird in den 10A bis 10C gezeigt. In einem anderen bevorzugten Ausführungsbeispiel muss ein berechtigter Benutzer, wie etwa ein Systemadministrator, möglicherweise die Schlüssel wiederherstellen, die verwendet wurden, um ein Dokument zu verschlüsseln, das beispielsweise in einem firmeneigenen Repository gespeichert wurde. Die Art, in der die Schlüsselwiederherstellung vorteilhafterweise und entsprechend der vorliegenden Erfindung ausgeführt wird, wird in den 11A und 11B gezeigt. 12 zeigt die Logik, mit der ein Administrator oder ein Administrationsprozess das sichere Dokumentsystem der vorliegenden Erfindung einrichtet und verwaltet.
  • Verschlüsselung
  • Der selektive Verschlüsselungsprozess der 7A bis 7C arbeitet in logischen Phasen, wie zuvor beschrieben, einer Vorverarbeitungsphase und einer Nachbearbeitungsphase. Während der Vorverarbeitungsphase (7A) werden Datenvorgaben und Beschränkungen der Elementsichtbarkeit von den gespeicherten Vorgabenobjekten geladen und analysiert. Dann wird die standardmäßige Stylesheet-Verarbeitung aufgerufen (7B), um jene Elemente im Quelldokument zu markieren, die eine Verschlüsselung erfordern. (Alternativ dazu kann die Verarbeitung von 7B durch den erweiterten Stylesheet-Prozessor der vorliegenden Erfindung ausgeführt werden, als eine Erweiterung des Codes, der zur Ausführung der Vorverarbeitungsphase geschrieben wurde.) Während der Nachbearbeitungsphase wird die Verschlüsselung auf die markierten Elemente angewendet und das Schlüsselverteilungsmaterial wird in den DOM-Baum zur Verteilung mit dem selektiv verschlüsselten Dokument eingefügt (7C).
  • Die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung führen den Prozess der selektiven Verschlüsselung unter Verwendung eines XSL-Prozessors aus, der erweitert wurde, um Datenvorgaben und Beschränkungen der Elementsichtbarkeit anzuwenden, wie zuvor erläutert. 7A und 7C zeigen Flussdiagramme mit der zusätzlichen Logik, mit der dieser speziell eingerichtete XSL-Prozessor arbeitet. (Die Logik des vorhandenen XSL-Prozessors wird nicht gezeigt. Es sollte den Fachleuten klar sein, wie die Logik der 7A und 7C in die vorhandene XSL-Prozessorlogik einzubauen ist.)
  • Der Zweck der Vorverarbeitungsphase in 7A ist es, die Elemente des Quelldokuments als zu verschlüsselnde Elemente festzulegen und während des Verschlüsselungsprozesses die zu verwendenden Schlüsselklassen zu erstellen. Die Verarbeitung in dieser Phase beginnt bei Block 700 und arbeitet mit einem bestimmten Quelldokument (wie etwa Dokument 400 in 4A). Dieser Prozess kann als Reaktion auf eine Clientanforderung für das Dokument (als Teil des Prozesses zur Rückgabe des angeforderten Dokuments zum Client) gestartet werden oder im Voraus auf eine solche Anforderung (wobei das daraus resultierende Dokument dann gespeichert wird, in Erwartung einer nachfolgenden Clientanforderung). Es ist zu beachten, dass hier gemachte Verweise auf einen anfordernden "Client" ebenfalls den Fall einschließen, in dem die Antwort an einen menschlichen Benutzer oder in dem die Antwort an ein ausführendes Anwendungsprogramm oder einen Prozess auszugeben ist.
  • In Block 700 wird die durch Vorgaben erweiterte DTD für das Quelldokument von einem Verzeichnis oder einem anderen Speicher-Repository abgerufen. In den bevorzugten Ausführungsbeispielen wird davon ausgegangen, dass Datenvorgaben in einem Repository (wie etwa das LDAP-Verzeichnis mit den Verweisen durch die Vorgaben-URIs 312, 322, 332 in 3) gespeichert sind, als ausführbarer Vorgabenobjektcode. Unter Verwendung der Beispiele der 3 und 4 ist das verarbeitete Dokument das Quelldokument 400 der 4A. Die DTD-Referenz 405 wird durch den Block 700 lokalisiert, und diese Referenz 405 wird verwendet, um die DTD 300 abzurufen. Block 705 ruft (unter Verwendung der URIs, wie etwa 312, 322 und 332) das Vorgabenobjekt ab, auf das von der DTD-Elementdefinition verwiesen wird, und instantiiert es.
  • Ein Vorgabenobjekt wird vorzugsweise für jeden spezifischen, zu verarbeitenden Elementtyp geschrieben, unabhängig davon, ob das Element verschlüsselt werden soll oder nicht. Wie in der Referenz-Erfindung beschrieben, arbeitet jedes Vorgabenobjekt vorzugsweise durch Spezifizieren von ausführbarem Code, um vorhandene XSL-Prozessormethoden zu überladen und wird geschrieben, um als "Plug-in" vom XSL-Prozessor ausgeführt zu werden (wobei das Konzept des Plug-in den Fachleuten bekannt ist). Im besonderen überladen die bevorzugten Ausführungsbeispiele die XSL "Wert-von"-Methode. Vorzugsweise wird diese Überladung ausgeführt, indem Unterklassen der vorhandenen Wert-von-Methode gebildet werden (wobei die Technik zur Unterklassierung einer Methode den Fachleuten bekannt ist). Verweise auf Werte werden dann während der Stylesheet-Verarbeitung (7B) abgefangen, und diese abgefangenen Werte passieren dann die in Block 710 instantiierten Vorgaben. Die in der vorliegenden Erfindung definierten Attribute und Techniken zur Verschlüsselung können zusätzlich zu oder anstelle der Attribute und Techniken der Referenz-Erfindung verwendet werden, wobei der Wert eines Elements geändert werden kann (beispielsweise durch Ändern numerischer Werte in Text, Unterdrücken von Elementen und Werten usw.), während der Stylesheet-Verarbeitung. (Es ist zu beachten, dass es wünschenswert sein kann, während dieser Verarbeitung ein Prüfprotokoll zu erstellen, um die erfassten ursprünglichen Daten sowie die Daten aus den Wertänderungen festzuhalten. Techniken zum Erstellen von Prüfprotokollen sind in Fachkreisen bekannt und sind nicht Teil der vorliegenden Erfindung.)
  • Jedes von den bevorzugten Ausführungsbeispielen verwendete Vorgabenobjekt umfasst vorteilhafterweise eine Methode oder ein Attribut zur Angabe der minimalen Sicherheitsstärke, die zum Verschlüsseln der Dokumentelemente erforderlich ist, mit denen dieses Objekt verwendet werden soll, sowie zur Angabe der Mitglieder der Gemeinschaft, die zur Anzeige (d.h. Entschlüsselung) des Wertes berechtigt sind. Der den Vorgabenobjektcode erstellende Programmierer ist zuständig für die Angabe dieser Stärke und der Gemeinschaftsinformationen. Die Gemeinschaft kann statisch angegeben werden, indem eine Liste der DNs ihrer Mitglieder eingefügt wird, die im Voraus bestimmt werden können und/oder es kann ein ausführbarer Code in das Vorgabenobjekt geschrieben werden, um einen oder mehrere DNs von Gemeinschaftsmitgliedern dynamisch zu bestimmen. Wenn eine Gruppe als ein Gemeinschaftsmitglied anzugeben ist, gibt der Programmierer vorzugsweise einen DN der Gruppe (falls vorhanden) an, andernfalls kann der DN für jedes Mitglied (statisch) angegeben werden, obwohl dieser letztere Ansatz eine zeitintensivere Ausführung während der Verschlüsselungs- und Entschlüsselungsprozesse in Anspruch nimmt und nicht auf Zusätze oder Änderungen bei der Gruppenmitgliedschaft eingeht, bis nicht die statisch angegebene Liste im Vorgabenobjekt aktualisiert wird. Es kann auch Code in das Vorgabenobjekt geschrieben werden, um die DN für jedes Mitglied einer bestimmten Gruppe dynamisch zu lokalisieren und auszugeben.
  • Block 715 fragt, ob dieses Vorgabenobjekt die Verschlüsselung der zugehörigen Datenelemente vorsieht. Dies kann ermittelt werden, indem eine Methode aufgerufen wird, die einen Attributwert zur Angabe der erforderlichen minimalen Verschlüsselungsstärke ausgibt, wobei eine Null angibt, dass die Verschlüsselung nicht erforderlich ist und ein Nicht-Nullwert angibt, dass eine Verschlüsselung vorzunehmen ist. Alternativ dazu kann eine Methode aufgerufen werden, die einen Booleschen Attributwert ausgibt, der speziell gesetzt wurde (d.h. unabhängig vom Attribut Verschlüsselungsstärke), um anzugeben, ob eine Verschlüsselung erforderlich ist.
  • Wenn der Test an Block 715 ein negatives Ergebnis mit sich bringt, geht die Steuerung auf Block 720 über, um festzustellen, ob es sich um die letzte Elementdefinition gehandelt hat. Wenn dies der Fall ist, endet die Verarbeitung von 7A und die Steuerung setzt die Verarbeitung in 7B fort. Wenn es sich nicht um die letzte Definition gehandelt hat, kehrt die Steuerung zu Block 705 zurück, um die nächste Elementdefinition zu lesen und mit deren Verarbeitung zu beginnen.
  • Die Steuerung erreicht Block 725, wenn der Test in Block 715 ein positives Ergebnis mit sich bringt. Block 725 ruft die Gemeinschaftsinformationen ab, die mit diesem Vorgabenobjekt verbunden sind, vorzugsweise durch Aufrufen einer Methode, wie etwa "communityMembers", die eine Liste mit Distinguished Names ausgibt. Bei dem Beispiel des Mitarbeiterdatensatzes in den 3 und 4 kann das Vorgabenobjekt für die Vorgabe "empl_mgr_hr" statisch angegebene DNs für die Gruppen Vorgesetzte und Personalabteilung verwenden, muss jedoch ausführbaren Code einfügen, um den DN für den bestimmten Benutzer zu bestimmen, dessen Informationen sich in Dokument 400 befinden. Die statischen DNs können im gespeicherten Vorgabenobjekt beispielsweise in folgendem Format angegeben werden:
    DN="cn=managers,ou=groups,o=acme" für die Gruppe Vorgesetzte (manager), und
    DN="cn=hr,ou=groups,o=acme" für die Gruppe Personalabteilung (HR).
  • Ein DN für einen einzelnen Benutzer (wie etwa den Systemadministrator) kann ebenfalls statisch angegeben werden, beispielsweise unter Verwendung folgender Syntax:
    DN="cn=admin,ou=users,o=acme".
  • Durch Untersuchen der Syntax dieser Beispiele kann erkannt werden, dass die Distinguished Names mit einem Organisationseintrag für Acme Unternehmen ("o=acme") auf der Stufe des Stammverzeichnisses strukturiert sind, wobei die Stammstufe weiterhin unterteilt ist in "users" und "groups" in der Unternehmenseinheit (organisational unit = "ou") und wobei die "groups"-Stufe wiederum weiter unterteilt ist für Einträge für "managers" und "hr" auf der Stufe Gemeinsamer Name (common name = "cn"). Der DN für eine Gruppe, etwa für die Gruppen Vorgesetzter oder Personalabteilung, kann verwendet werden, um den DN für jedes Mitglied der Gruppen abzurufen, unter Verwendung von Techniken, die in Fachkreisen bekannt sind und nicht Teil der vorliegenden Erfindung sind. Unter Verwendung dieses gleichen Formats kann der DN für die medizinische Abteilung, verwendet im Vorgabenobjekt "empl_medical", innerhalb des gespeicherten Vorgabenobjekts angegeben werden als:
    DN="cn=medical,ou=groups,o=acme",
    wobei die Stufe "groups" ebenfalls über einen Eintrag für eine Gruppe namens "medical" verfügt.
  • Ein DN für einen einzelnen Benutzer, der dynamisch abgerufen wird, verfügt über eine ähnliche Syntax wie die, die für die statisch angegebenen DNs verwendet wird. Abhängig von der Art, in der die Registrierung der DNs organisiert ist, kann der Benutzer-DN im Beispiel des Mitarbeiterdatensatzes lokalisiert werden, unter Verwendung seines Namens und seiner Nummer oder möglicherweise nur unter Verwendung seiner Nummer usw. Der ausführbare Code im Vorgabenobjekt muss deshalb das Quelldokument 400 (oder eine andere Informationsquelle, wie etwa den Anforderungskopf, mit dem das Quelldokument angefordert wurde, falls vorhanden) durchsuchen, um den Wert oder die Werte zu lokalisieren, die verwendet werden sollen (wie etwa Suchen nach den Werten der Tags "empl_name" 402 und/oder "ser_nbr" 404).
  • Block 730 vergleicht die Liste der Distinguished Names für alle Mitglieder dieser Gemeinschaft mit der Liste der DNs mit Gemeinschaftsmitgliedern in den vorhandenen Vorverarbeitungsschlüsselklassenobjekten (wobei jeder DN 501 sich in einem Schlüsselobjekt 500 eines Schlüsselklassenobjekts 530 befindet, das in Feld 522 jedes Vorverarbeitungsklassenobjekts 520 dargestellt wird).
  • Wenn ein Vorverarbeitungsschlüsselklassenobjekt 520 nicht gefunden wird, das bereits diese Gemeinschaft (ein Nein-Ergebnis bei Block 735) enthält, wird ein neues Schlüsselklassenobjekt (Block 740) erstellt. Das Feld Verschlüsselungsstärke 521 des Objekts 520 wird auf den Wert des minimalen Stärkeattributs des in Block 710 abgerufenen Vorgabenobjekts gesetzt. Der unverschlüsselte Schlüsselwert 523 wird vorzugsweise auf einen Nullwert gesetzt, um anzugeben, dass er noch nicht initialisiert ist. Ein Schlüsselklassenobjekt 530 wird dann erstellt und verwendet, als Wert des Feldes 522. Der Identifier 531 zur Verwendung für die Schlüsselklasse, wird vorzugsweise als ein sequentiell größer werdender numerischer Wert generiert. Die Felder 532, 533, 534 werden vorzugsweise an diesem Punkt auf Nullwerte gesetzt: die tatsächlichen Werte werden während der Nachbearbeitungsphase bestimmt. Die DN für jedes Gemeinschaftsmitglied wird vorzugsweise verwendet, um bereits erstellte Schlüsselobjekte 500 zu suchen. Wenn eine Übereinstimmung lokalisiert wird, wird das vorhandene Schlüsselobjekt 500 (mit der DN des Gemeinschaftsmitglieds in Feld 501, dem X.509 Zertifikat des Gemeinschaftsmitglieds und einem Nullwert in Feld 503) im Schlüsselklassenobjekt 530 verwendet. Andernfalls, wenn kein übereinstimmendes Schlüsselobjekt besteht, muss eines erstellt werden. Der DN für das Mitglied wird verwendet, um das X.509 Zertifikat des Mitglieds abzurufen. Das neue Schlüsselobjekt 500 wird erstellt, indem das Feld 501 auf den DN des Mitglieds gesetzt wird, Feld 502 auf das abgerufene Zertifikat und Feld 503 auf einen Nullwert.
  • Bei Erreichen von Block 745 wurde entweder eine neue Vorverarbeitungsschlüsselklasse für die Gemeinschaft erstellt oder es wurde eine vorhandene Vorverarbeitungsschlüsselklasse für die Gemeinschaft lokalisiert. Block 745 ordnet dann dieses Vorverarbeitungsschlüsselobjekt 520 dem abgerufenen Vorgabenobjekt in Block 710 zu. Block 750 ersetzt das Feld Verschlüsselungsstärke mit der am meisten eingeschränkten (1) der minimalen erforderlichen Stärke aus dem Vorgabenobjekt und (2) dem vorhandenen Wert des Feldes 521 (in Block 750 als die Elementstärke und die Verschlüsselungsstärke der Klasse). Die Verschlüsselungsstärken können als numerische Werte dargestellt werden, wobei eine höhere Nummer eine größere Verschlüsselungsstärke wiedergibt (siehe US-Patent Nr.: 09/240,387). In diesem Fall wählt der Block 750 die größere der beiden Nummern aus. Das Vorverarbeitungsschlüsselklassenobjekt enthält nun die Verschlüsselungsstärke, die für das Element der Klasse 531 benötigt wird, mit der stärksten Verschlüsselungsanforderung. (Dies kann zu einer Überverschlüsselung einiger Elemente führen, was akzeptabel ist). Die Steuerung geht nun zu Block 720 über, um zu bestimmen, ob noch weitere Elementdefinitionen zu verarbeiten sind.
  • Die Verarbeitung in 7B beginnt bei der Beendigung der Verarbeitung von 7A. Diese Verarbeitung kann als Teil des erweiterten XSL-Prozessors der vorliegenden Erfindung erfolgen oder durch einen Transcoding Proxy nach Stand der Technik erfolgen (siehe die Beschreibung eines Transcoding Proxys 615 in der Erläuterung zu 6 oben). Block 752 wendet eine Stylesheet-Regel auf das Quelldokument 400 an. Wenn das Muster einer Stylesheet-Regel mit einem Element des Quelldokuments übereinstimmt, fragt Block 754, ob diese Vorgabe die vorhandene XSL Wert-von-Methode abruft. Wenn dies nicht der Fall ist, wird die Verarbeitung der Regel nach Stand der Technik fortgesetzt und die Steuerung geht auf Block 759 über. Entsprechend der vorliegenden Erfindung wird die Wert-von-Methode vorzugsweise für jedes Element im Quelldokument abgerufen, um eine selektive Verschlüsselung nötigenfalls für jedes Element auszuführen. Dies kann erfolgen, indem ein Stylesheet eingesetzt wird, das alle Input-Werte in ein zu generierendes Output-Dokument kopiert. Wenn die Wert-von- Methode durch die Vorgaberegel aufgerufen wird, empfängt Block 756 (d.h. erhält einen Zeiger oder einen Verweis) das zuvor instantiierte Datenvorgabenobjekt für das Datenelement, das mit der Vorgaberegel übereinstimmt. Die überschreibende Wert-von-Methode dieses Datenvorgabenobjekts wird bei Block 758 ausgeführt, wobei alle entsprechenden Transformationen ausgeführt werden, die mit dieser Methode codiert wurden. Entsprechend der vorliegenden Erfindung wird der Code der überschriebenen Wert-von-Methode geschrieben, um zu bestimmen, ob das Vorgabenobjekt angibt, ob ein Datenelement verschlüsselt werden soll (wie oben unter Verweis auf Block 715 beschrieben), und wenn dies der Fall ist, die Markierungstags zur Verschlüsselung um das Element herum einzufügen. Die Markierungstags zur Verschlüsselung verwenden vorzugsweise eine Syntax, wie etwa "<encrypt:data class="n""> und "<encrypt:data>" (wie in 4B bei 422 und 424 beschrieben), wobei der Wert "n" auf den Identifier des Schlüsselklassenobjekts gesetzt wird, der diesem Vorgabenobjekt in Block 745 in 7A zugeordnet wird. Dieser Prozess der Anwendung von Stylesheet-Regeln zur Markierung des Quelldokuments 400 wird wiederholt, indem die Blöcke 752 bis 759 wiederholt werden, bis das Quelldokument vollständig verarbeitet wurde (d.h. bis der Test bei Block 759 ein positives Ergebnis aufweist), wonach die Verarbeitung in 7B endet.
  • 7B zeigt ein Beispiel für das Ergebnis der beendeten Verarbeitung von 7B bei Quelldokument 400. Es ist zu beachten, dass der Inhalt 420 von 4B Interims-Informationen darstellt, wie intern erstellt und verwendet werden. Die Informationen werden nie in dieser Form zur Verfügung gestellt. (Siehe 4C für eine Darstellung der Informationen, die extern zur Verfügung gestellt werden). Markierungstags 422 und 424 wurden eingefügt, um die schützenswerten Informationen der Dokumentelemente curr_salary und medical condition einzuklammern. Eine erste Schlüsselklasse wird zur Verschlüsselung des Werts curr_salary verwendet und eine zweite Schlüsselklasse wird für den Wert medical condition verwendet, wie in den Markierungstags bei 423 und 425 entsprechend gezeigt. 4B zeigt weiterhin die Organisation dieser Schlüsselklassenobjekte. Wie bei 430 gezeigt, verfügt die Schlüsselklasse "1" über einen zugeordneten Algorithmus und eine Schlüssellänge und umfasst die Schlüsselobjekte 431, 432, 433 für die drei Mitglieder der zugeordneten Gemeinschaft. Schlüsselklasse "2" ist ähnlich, unter Verwendung eines anderen Algorithmus und einer anderen Schlüssellänge (siehe 440) und unter Angabe von Schlüsselobjekten 441, 442 für zwei Gemeinschaftsmitglieder.
  • Es ist zu beachten, dass die Elemente "tempkey" 434, 444 von 4B Beispiele des unverschlüsselten symmetrischen Schlüssels zeigen, der verwendet wird, um einen anderen verschlüsselten symmetrischen Schlüssel 523 (gezeigt in den 4B und 4C als Werte von "Ekey") für jedes Gemeinschaftsmitglied der zugeordneten Schlüsselklasse zu erstellen. Es ist ebenfalls zu beachten, dass die Werte KeyIdentifier und diese Werte Ekey, gezeigt in den Schlüsselklassen (in den 4B und 4C) nur der bildlichen Darstellung dienen. In einer tatsächlichen Implementierung sind die Informationen vorzugsweise codiert als binäre Werte unter Verwendung von "base 64"-Regeln nach Stand der Technik, so dass das Ergebnis nur druckbare Zeichen enthält, die im Kontext von XML-Attributwerten zulässig sind.
  • 7C zeigt die Nachbearbeitungsphase des Prozesse der selektiven Verschlüsselung. Diese Logik wird bei Beendigung der Verarbeitung aus 7B abgerufen. Ziel der Nachbearbeitungsphase ist das Ersetzen bestimmter DOM-Elemente durch verschlüsselte Elemente und das Einfügen der notwendigen Schlüsselobjekte für die Verschlüsselung in den DOM-Stamm. 4B stellt ohne DOM-Baumstruktur das Format des Interims-Dokuments 420 dar, mit dem die Nachbearbeitungsphase arbeitet.
  • Wie in Block 760 angegeben, wird der DOM-Baum entsprechend des zu verschlüsselnden Dokuments auf eine vordefinierte Weise durchsucht. Entsprechend der bevorzugten Ausführungsbeispiele wird diese Reihenfolge definiert, um die Standardsequenz zum Senden der DOM in einem Output-Strom zu bilden. Eine vorbestimmte Reihenfolge ist für die bevorzugten Ausführungsbeispiele erforderlich, die eine Schlüsselblockverkettung verwenden, in der der Output jeder Blockverschlüsselung als Schlüsselmaterial für die nächste Blockverschlüsselung dient. (Wenn die Reihenfolge zum Durchsuchen des DOM variiert und keine vorbestimmte Reihenfolge eingesetzt wird, ist der Empfänger nicht in der Lage, die Daten zu entschlüsseln, da die Interims-Schlüssel nicht gebildet werden können. Der Modus Schlüsselblockverkettung (Cipher Block Chaining = CBC) wird zur Verwendung in der vorliegenden Erfindung gegenüber eines nicht verketteten Modus bevorzugt, um bestimmte Arten von kryptografischen Angriffen abzuwehren. Ähnlich wird CBC gegenüber einer Stromverschlüsselung bevorzugt, um die Länge der verschlüsselten Felder zu verschleiern, wodurch weitere Arten von krypptografischen Angriffen abgewehrt werden können. Alternative Verschlüsselungsmodi, wie etwa Blockverschlüsselung oder Stromverschlüsselung, elementweise ausgeführt, können eingesetzt werden, ohne dass vom Gegenstand der Erfindung abgewichen wird.
  • Block 765 prüft das Elementtag, das von Block 760 analysiert wurde, um festzustellen, ob dieser Tag (von Block 758 in 7B) als Verschlüsselung erfordernd markiert wurde. Wenn dies nicht der Fall ist, geht die Steuerung zu Block 789 über und umgeht somit die Verschlüsselung durch die Blöcke 770 bis 795. Wenn jedoch das Elementtag angibt, dass das Element verschlüsselt werden soll, geht die Verarbeitung an Block 770 weiter. Block 770 liest die Schlüsselklasse vom Elementtag, wie etwa den Wert "1", angegeben bei 423 im Verschlüsselungstag 422 in 4B. Block 770 prüft anschließend, ob dies das erste zu verarbeitende Element für diese Schlüsselklasse ist. Eine Art, in der die diese Bestimmung vorgenommen werden kann, ist die Untersuchung des symmetrischen Schlüsselwerts 523 des Vorverarbeitungsschlüssels 520, in dem sich der Identifier 531 der aktuellen Klasse befindet (innerhalb von Feld 522). Wenn der symmetrische Schlüsselwert 523 Null ist, wurde diese Schlüsselklasse noch nicht verarbeitet und Block 770 verfügt über ein positives Ergebnis. Es können auch alternative Techniken verwendet werden, wie etwa Erstellen einer Suchtabelle der Schlüsselklassen-Identifier für die Schlüsselklassen, die bereits erfasst wurden.
  • Die Blöcke 775, 780 und 785 führen Setup-Operationen für jede neue auszuführende Schlüsselklasse aus. Diese Initialisierung beginnt mit der Auflösung der erforderlichen Verschlüsselungsstärke 521 vom entsprechenden Vorverarbeitungsschlüsselklassenobjekt 520 in einen spezifischen Algorithmus und eine Schlüssellänge (falls diese Informationen nicht direkt im Vorgabenobjekt angegeben wurden). Vorzugsweise wird diese Auflösung durch Konsultieren des LDAP-Verzeichnisses, wie zuvor beschrieben im US-Patent Nr.: 09/240,387, ausgeführt, doch das exakte Mittel zum Bestimmen eines Algorithmus und einer Schlüssellänge zum Erhalt einer bestimmten Verschlüsselungslänge ist für die vorliegende Erfindung ohne Bedeutung. Der aufgelöste Algorithmus und die Schlüssellänge werden im Schlüsselklassenobjekt bei 532 und 533 gespeichert. Als nächstes wird ein zufallsgenerierter symmetrischer Schlüssel 523 verwendet, um (siehe Block 790) die erste Wiederholung der Verschlüsselungsblockverkettung für diese Schlüsselklasse zu initialisieren, unter Verwendung von Techniken, die den Fachleuten bekannt sind. Dieser Prozess kann ebenfalls das Einfügen einer Folge von zufallsgenerierten Bits umfassen, Intitialisierungsvektoren genannt, bevor das erste Bit der Daten verschlüsselt wird.
  • Block 780 verschlüsselt den generierten symmetrischen Schlüssel 523 separat für jedes Gemeinschaftsmitglied (das heißt, für jeden DN innerhalb der Gemeinschaft), das berechtigt ist, das zugehörige Dokumentelement anzuzeigen. Dies wird ausgeführt durch Zugreifen auf jedes Schlüsselobjekt 510 (wie in den Feldern 535, 536, ... 539 des Schlüsselklassenobjekts 530), definiert für die aktuelle Vorverarbeitungsschlüsselklasse und für jedes Schlüsselobjekt, (1) durch Abrufen des öffentlichen Schlüssels 505 vom X.509 Zertifikat 502a, (2) Verwenden dieses öffentlichen Schlüssels 505 zum Verschlüsseln des symmetrischen Schlüssels 523 unter Verwendung des Verschlüsselungsalgorithmus und der Schlüssellänge, gespeichert bei 532 und 533 und (3) Speichern des daraus resultierenden verschlüsselten Schlüssels in Feld 503 des Schlüsselobjekts. Dies führt zu einer verschlüsselten Kopie des symmetrischen Schlüssels je Gemeinschaftsmitglied mit einem separaten DN 501 und einem X.509 Zertifikat 502a. (Mit anderen Worten, es wird dann eine verschlüsselte Kopie des symmetrischen Volltextschlüssels 523 für die ganze Gruppe generiert und dem DN der Gruppe zugeordnet.) Um Platz zu sparen, wird dann in den bevorzugten Ausführungsbeispielen das X.509 Zertifikat 502a durch den zugehörigen KeyIdentifier 502b ersetzt, der in Kombination mit dem Distinguished Name 501 eine Identifizierung des spezifischen Zertifikats ermöglicht, dass während der Verschlüsselung verwendet wurde.
  • Block 785 fügt dann das Schlüsselklassenobjekt 530 in den DOM-Stamm ein, wie durch die vorhandenen Schlüsselklassenobjekte 461, 462 dargestellt, die sich in dem befinden, was als Stammbereich 460 des Output-Dokuments 450 in 4C bezeichnet werden kann.
  • Bei Block 790 wird der von Block 760 gelesene Elementwert verschlüsselt, unter Verwendung des symmetrischen Volltextschlüssels 523 (d.h. es ist ein ähnlicher Wert wie der für "tempkey" 434 in 4B gezeigt vorhanden), des Verschlüsselungsalgorithmus, durch 523 identifiziert, sowie der Schlüssellänge 533 für die Schlüsselklasse des Elements 531. Wenn es sich um das erste Element handelt, das unter Verwendung einer gegebenen Schlüsselklasse verschlüsselt wird, wird der in Block 775 erstellte Initialisierungsvektor als Input in den Verschlüsselungsalgorithmus verwendet, andernfalls wird Material verwendet, das aus der vorherigen CBC Operation für diese spezielle Schlüsselklasse resultiert.
  • Es ist zu beachten, dass es vorkommen kann, dass ein zu verschlüsselndes Element über andere Elemente verfügt (wie etwa Kinderelemente), die ebenfalls über eine Vorgaben angebende Verschlüsselung verfügen. Um diese Situation zu bewältigen, durchsucht der Nachprozessor vorzugsweise den gesamten, zu verschlüsselnden Unterbaum, um festzustellen, ob solche eingebetteten Elemente vorhanden sind. Wenn dies der Fall ist, bestimmt der Nachprozessor vorzugsweise den am meisten beschränkten Typ der Verschlüsselung, der auf alle Elemente des Unterbaums zutrifft. Die anschließenden Tags des Unterbaums stellen die Unterklasse dar, die dieser höchsten Verschlüsselungsstärke zugeordnet sind, und jegliche Verschlüsselungstags, die um eingebettete Elemente eingefügt wurden, werden entfernt. Der gesamte Unterbaum wird dann unter Verwendung dieses höchststufigen Ansatzes verschlüsselt. Zuständig dafür ist der Systemadministrator, der die Sicherheitsvorgaben definiert, um sicherzustellen, dass diese Art der Verarbeitung nicht zur Verschlüsselung der falschen Gemeinschaft oder zur Verschlüsselung des Unterbaums unter Verwendung des falschen Algorithmus führt. Es ist klar, dass der Systemadministrator die Semantik der zu verarbeitenden Daten kennen muss, um die Elementsichtbarkeit ordnungsgemäß zuordnen zu können.
  • Während das Beispiel für ein selektiv verschlüsseltes Dokument in 4B die Elementtags als unverschlüsselt gelassene Elemente zeigt, kann es in bestimmten Situationen vorkommen, dass die Tags selbst sowie die von den Tags umschlossenen Datenwerte verschlüsselt werden. Um diese Möglichkeit einzuschließen, kann das zugehörige Vorgabenobjekt so geschrieben werden, dass es die Verschlüsselungstags (siehe 422, 424 aus 4B) um die Elementtags herum anstatt um den Elementwert herum platziert.
  • Es ist möglich, dass ein zu verschlüsselndes Element kürzer, gleich oder länger als die in einem CBC-Prozess verwendete Blocklänge ist. Wenn die zu verschlüsselnden Daten die Blocklänge überschreiten, werden in diesem Schritt des Algorithmus mehrere Blöcke erstellt. Wenn die zu verschlüsselnden Daten (plus dem Initialisierungsvektor) kein exaktes Vielfaches der Blockgröße sind, können nicht-signifikante Paddingbits an das Ende des Elements eingefügt werden, wodurch der letzte Block für jedes gegebene Element Null oder mehrere Paddingbits enthält. Normalerweise verfügt ein CBC nur am Ende des letzten Datenblocks über Paddingbits. In der vorliegenden Erfindung jedoch können Paddingbits am Ende jedes letzten Blocks für jedes verschlüsselte Element vorhanden sein. Alternativ dazu können bekannte Methoden, wie Ciphertext Stealing, verwendet werden, um einen letzten Verschlüsselungsblock zu erstellen, der kürzer ist als die Blocklänge.
  • Das verschlüsselte Element wird dann markiert, um anzugeben, dass es verschlüsselt wurde (Block 795), unter Verwendung einer Syntax, wie zuvor beschrieben (siehe 452, 454 von 4C), wobei der Schlüsselklassen-Identifier 531 als ein Attribut des Tags eingefügt wird, zur Verwendung in einem nachfolgenden Entschlüsselungsprozess. Wenn das Element Paddingbits enthält, kann die Anzahl an Paddingbits über ein Attribut auf dem verschlüsselten Element angegeben werden oder indem eine Feldlänge vor die Volltextdaten vor der Verschlüsselung gestellt werden. (Es ist zu beachten, dass diese bestimmte Schlüsselklasse notwendigerweise eine der Schlüsselklassen 461, 462 im DOM-Stamm des Dokuments sein muss, die dort von Block 785 eingefügt wurden). Die Schlüsselklasseninformationen vom DOM-Stamm sind für den Verschlüsselungsprozess erforderlich. Es ist weiterhin zu beachten, dass wenn das generierte Dokument (wie etwa das Dokument 450 in 4C) ein XML-Dokument ist, die neuen Objekte und die dazugehörigen Tags (wie etwa die Schlüsselklassen 461, 462, die verschlüsselten Datentags 452, 454 usw.), die in dieses Dokument entsprechend der vorliegenden Erfindung übertragen werden, als Elemente des Datenvorgabennamensbereichs (beispielsweise durch Verwenden von "encrypt:data" statt einfach "class" für Schlüsselklassenobjekte 461, 462) erscheinen, um eine zweideutige Interpretation oder ein ungewolltes Verarbeiten dieser Objekte und Tags zu verhindern.
  • Block 798 prüft dann, ob das Ende des DOM-Stroms erreicht wurde. Wenn dies der Fall ist, ist der Prozess der selektiven Verschlüsselung beendet und das Output-Dokument 450 ist bereit zum sicheren Speichern oder zur sicheren Übertragung, und 7C ist beendet. Andernfalls kehrt die Steuerung zu Block 760 zurück, um das nächste Element im DOM-Strom zu lesen.
  • Eine Anzahl verschiedener bevorzugter Ausführungsbeispiele wird hier definiert, zur Verschlüsselung des selektiv verschlüsselten Dokuments, erstellt durch die Verarbeitung der 7A bis 7C. Wie bereits erläutert, arbeitet jede Verschlüsselungsoperation vorzugsweise als Teil des erweiterten XML-Prozessors. Jedes bevorzugte Ausführungsbeispiel zur Verschlüsselung wird nun einzeln beschrieben.
  • ERSTES BEVORZUGTES AUSFÜHRUNGSBEISPIEL ZUR VERSCHLÜSSELUNG
  • In einem bevorzugten Ausführungsbeispiel empfängt ein einzelner Benutzer (oder äquivalent dazu ein einzelnes Anwendungsprogramm oder ein Prozess mit eigenem DN) das verschlüsselte Dokument auf der Client Workstation und führt auf dieser Client Workstation einen Verschlüsselungsprozess aus. Die Logik, mit der dieses bevorzugte Ausführungsbeispiel implementiert werden kann, wird in den 8A und 8B gezeigt. (Dieses bevorzugte Ausführungsbeispiel läßt den Fall außer Acht, in dem ein Benutzer ein berechtigtes Gemeinschaftsmitglied aufgrund der Tatsache ist, dass er Mitglied einer Gruppe ist, wobei diese Gruppe als Gemeinschaftsmitglied definiert ist. Die verwendete Logik zur Verarbeitung eines Benutzers als ein Gruppenmitglied wird im folgenden beschrieben, unter Verweis auf die 10A bis 10C. Obwohl dieses Ausführungsbeispiel die Verarbeitung des Dokumentempfangs für einen Benutzer beschreibt, der kein Gruppenmitglied ist, separat von der Logik zur Verarbeitung eines Gruppenmitglieds, sollte es den Fachleuten klar sein, dass die Logik für diese Fälle mit einer bestimmten Implementierung kombiniert werden kann. Im besonderen kann die Logik, wie jene unten beschriebene, an Block 1006 beginnende, einem negativen Ergebnis in Block 825 folgend eingefügt werden, auch unten beschrieben, um zu bestimmen, ob es sich bei dem Benutzer um ein Gruppenmitglied handelt.)
  • Bei Block 800 hat der Benutzer ein Dokument empfangen (wie etwa das Dokument an 450 in 4C), das selektiv verschlüsselt wurde. Dieses Dokument kann aufgrund einer Anforderung durch den Benutzer empfangen worden sein. Oder es wurde an diesen Benutzer durch einen anderen Benutzer oder Prozess weitergeleitet, als Teil einer gruppenweise Zusammenarbeit. Vorausgesetzt, dass der öffentliche Schlüssel des Benutzers verwendet wurde, um mindestens eines der verschlüsselten Elemente des Dokuments zu verschlüsseln, ist der Benutzer in der Lage, auf diese schützenswerten Informationen zuzugreifen, auch wenn das Dokument ursprünglich nicht für diesen Benutzer erstellt wurde. Block 805 liest ein Schlüsselklassenobjekt (wie etwa das Schlüsselklassenobjekt 461 oder 462) vom DOM-Stamm des empfangenen Dokuments (wobei der erweiterte XML-Prozessor eine DOM-Baumdarstellung des empfangenen Dokuments erstellt hat). Wenn keine solchen Schlüsselklassen vorhanden sind, wurde dieses Dokument nicht selektiv unter Verwendung der vorliegenden Erfindung verschlüsselt, und das Dokument kann ausgegeben werden, unter Verwendung von Prozessen, die nicht Gegenstand der vorliegenden Erfindung sind. Block 810 prüft, ob dieser Benutzer-DN in einem der Schlüsselobjekte für diese Schlüsselklasse erscheint. In dem Beispiel des Mitarbeiterdatensatzes, unter der Voraussetzung, dass der DN eines Mitarbeiters seine Seriennummer für den Wert des Feldes CN verwendet, würde der Mitarbeiter namens John Q Smith und mit seiner Seriennummer E135246 (siehe 402, 404 der 4A) seinen DN am Schlüsselobjekt 465 lokalisieren und bei Block 810 entstünde ein positives Ergebnis.
  • Wenn Block 810 über ein positives Ergebnis verfügt, wird die Verarbeitung an Block 815 fortgesetzt, wobei der verschlüsselte symmetrische Schlüssel von diesem Schlüsselobjekt abgerufen wird, das über einen DN verfügt, der mit dem DN des Benutzers übereinstimmt. (In 5A wird der verschlüsselte Schlüssel 503 von einem Objekt abgerufen, das über das in 510 gezeigte Format verfügt.) Der private Schlüssel des Benutzers wird dann verwendet, um diesen verschlüsselten symmetrischen Schlüssel an Block 820 zu entschlüsseln. Der öffentliche Schlüssel des Benutzers wurde verwendet, um diesen Schlüssel an Block 790 in 7C zu verschlüsseln, und wenn dieser Benutzer also der wirkliche Besitzer des Paares privater und öffentlicher Schlüssel ist, verläuft der Entschlüsselungsprozess erfolgreich; andernfalls, wenn der Benutzer an Block 790 nicht über den privaten Schlüssel verfügt, der zum öffentlichen Schlüssel gehört, wird dem Benutzer der Zugriff auf die schützenswerten Elemente innerhalb der verarbeiteten Schlüsselklasse verweigert.
  • Block 825 wird nach Beendigung von Block 820 und gefolgt von einem negativen Ergebnis an Block 810 erreicht. Block 825 prüft, ob sich noch weitere Schlüsselklassenobjekte im DOM-Stamm des empfangenen Dokuments befinden. Der Benutzer kann zur Entschlüsselung von mehr als einer Schlüsselklasse berechtigt sein, wie in dem Fall des Mitarbeiters im Beispiels des Mitarbeiterdatensatzes, wobei der Mitarbeiter Zugriff auf alle verschlüsselten Informationen erhält (und somit als berechtigtes Gemeinschaftsmitglied für jede zur Dokumentverschlüsselung verwendete Schlüsselklasse eingerichtet wird). Wenn Block 825 über ein positives Ergebnis verfügt, kehrt die Steuerung zu Block 805 zurück, um das nächste Schlüsselklassenobjekt zu verarbeiten; andernfalls werden alle Schlüssel, für die dieser Benutzer eine Berechtigung hat, wiederhergestellt und das verschlüsselte Dokument wird nun verarbeitet.
  • Block 830 liest ein Element des DOM, in der gleichen Stromreihenfolge, die für den Verschlüsselungsprozess verwendet wurde, um die Operationen der Verschlüsselungsblockverkettung rückgängig zu machen (d.h. zu entschlüsseln). Block 835 fragt, ob das gerade gelesene Element verschlüsselt ist, wie durch das Vorhandensein eines Verschlüsselungs-Tags festgelegt ist, etwa das Tag in 452 in 4C. Wenn dies nicht der Fall ist, fügt Block 840 das Volltextelement zu einem erstellen Output-Puffer hinzu. Block 845 prüft, ob das Ende des DOM-Stroms erreicht wurde. Wenn dies nicht der Fall ist, kehrt die Steuerung zu Block 830 zurück, um das nächste Dokumentelement zu verarbeiten. Wenn auf der anderen Seite Block 845 über ein positives Ergebnis verfügt (d.h. das Dokument vollständig verarbeitet wurde, einschließlich Entschlüsselung der verschlüsselten Elemente, für die der Benutzer den erforderlichen privaten Schlüssel besaß), wird der Inhalt des Output-Puffers verwendet, um die Dokumentelemente aus dem Output-Puffer (Block 850) zu liefern, unter Verwendung von Techniken, die den Fachleuten bekannt sind. Die Verarbeitung von 8A ist dann beendet.
  • Wenn in Block 835 der Test ein positives Ergebnis aufweist (d.h. das Element verschlüsselt ist), wird ein Versuch unternommen, den Elementwert unter Verwendung der Logik in 8B zu entschlüsseln. Zunächst wird er Schlüsselklassen-Identifier vom Schlüsselklassenattribut (Block 855) empfangen. Dann prüft Block 860, ob dieser Benutzer einen symmetrischen Schlüssel für diese empfangene Schlüsselklasse wiederhergestellt hat. Wenn dies der Fall ist, fragt Block 865, ob dies das erste entschlüsselte Element in dieser Schlüsselklasse ist. Wenn dieser Test ein positives Ergebnis aufweist, gibt Block 870 an, dass der Initialisierungsvektor, der entsprechend der CBC nach Stand der Technik eingefügt wurde, entfernt worden ist. Wenn dieser Test ein negatives Ergebnis aufweist, werden die Ergebnisse der vorigen Entschlüsselung für diese Schlüsselklasse verwendet, um den Entschlüsselungsalgorithmus zu initialisieren. Block 875 verwendet dann den Schlüssel, der an Block 820 für diese Schlüsselklasse entschlüsselt wurde, zusammen mit dem Input der Verschlüsselungsblockverkettung, um das verschlüsselte Element zu entschlüsseln. Die Verarbeitung kehrt zu Block 840 von 8A zurück, wobei der entschlüsselte Wert an den Output-Puffer angehängt wird. Wenn der Benutzer keinen Schlüssel für diese Schlüsselklasse wiederhergestellt hat, gibt Block 880 an, dass ein Ersatzwert verwendet werden kann, wie etwa "Element kann nicht entschlüsselt werden". Die Steuerung kehrt zu Block 840 von 8A zurück, wo dieser Ersatzwert an den Output-Puffer angehängt wird.
  • Dieser Ansatz der Verwendung eines Ersatztextes (siehe Block 880) wird in den bevorzugten Ausführungsbeispielen verwendet, anstatt verzerrte Informationen an den Benutzer oder unverständliche (d.h. noch verschlüsselte) Daten an ein Anwendungsprogramm auszugeben. Andere Techniken zum Bereitstellen von Ersatztext können ebenfalls verwendet werden. Die Verschlüsselungsstärke beispielsweise (beispielsweise "Classified", "Top Secret" usw.), die dem Element zugeordnet wurde, kann anstelle des Wertes angegeben werden, der nicht entschlüsselt werden konnte. Oder es kann visuell eine Angabe gemacht werden, um anzugeben, dass das Element "zensiert" wurde, unter Verwendung einer entsprechenden visuellen Anzeige, oder der verschlüsselte Wert kann einfach weitergegeben werden, für eine mögliche Entschlüsselung durch eine andere Verarbeitungseinheit.
  • Alternativ dazu kann es in einer bestimmten Implementierung wünschenswert sein, einfach alle Verweise auf das Element im Ouput-Dokument zu übergehen. Die Verwendung dieser Lösung mit einem Ersatz oder eine bestimmte Darstellung davon ist ein optionales Merkmal der vorliegenden Erfindung und kann gänzlich entfallen, ohne dass vom Gegenstand der vorliegenden Erfindung abgewichen wird.
  • ZWEITES BEVORZUGTES AUSFÜHRUNGSBEISPIEL ZUR VERSCHLÜSSELUNG
  • Ein weiteres bevorzugtes Ausführungsbeispiel wird für die Situation definiert, in der entweder (1) die Workstation eines Benutzers nicht über die ausreichende Arbeitsleistung verfügt, um den Verschlüsselungsprozess der vorliegenden Erfindung auszuführen, oder (2) es wünschenswert ist, Änderungen im Programmcode auf der Client Workstation zu vermeiden. Somit führt ein Client Proxy den Verschlüsselungsprozess für den Benutzer (oder für eine Anwendung auf der Client Workstation) aus. Die Logik, mit der dieses bevorzugte Ausführungsbeispiel implementiert werden kann, wird in den 9A und 9B gezeigt. Der Benutzer in diesem Szenario verwendet eine standardmäßige Web Browser Client Anwendung (wie etwa den Browser Client 675 in 6) auf seiner Workstation oder einen standardmäßigen Programm-Client (wie etwa den Programm-Client 680) und fordert ein selektiv verschlüsseltes XML-Dokument von einem Proxy (wie etwa dem Client Proxy 655) an, der für den Browser Client agiert. Durch die Verwendung dieses Client Proxys 655 stellt dieses bevorzugte Ausführungsbeispiel selektiv verschlüsselten Dokumentinhalt den Browser Clients 675 oder den Programm-Clients 680 zur Verfügung, ohne dass Programmänderungen oder zusätzliche Software auf dem Client-Gerät notwendig werden.
  • 9A zeigt das bevorzugte Ausführungsbeispiel eines Initialisierungsprozesses, der durch den Client Proxy 655 (auch als Server bezeichnet) ausgeführt wird, um es dem Proxy 655 zu ermöglichen, auf selektiv verschlüsselte Dokumente für einen standardmäßigen Browser Client 675 oder einen Programm-Client 680 zuzugreifen. 9B zeigt dann das bevorzugte Ausführungsbeispiel der Logik, mit der dieser Proxy den Inhalt entschlüsselt (falls die entsprechende Berechtigung dazu vorhanden ist) und der entschlüsselte Inhalt über eine sichere Sitzung (wie etwa eine SSL-Sitzung) diesem Client zur Verfügung gestellt wird. Die Beschreibung der 9A und 9B behandeln den Proxy, der für den Browser Client 675 arbeitet, wenn auch den Fachleuten klar ist, dass diese Logik ebenfalls auf den Programm-Client 680 anwendbar ist. (Die Verarbeitung innerhalb des Clients wird für dieses Ausführungsbeispiel nicht gezeigt, da die Client-Verarbeitung bekannte Techniken verwendet. Die neuartigen Funktionen, bei denen ein selektiv verschlüsseltes Dokument entsprechend der vorliegenden Erfindung zur Verfügung gestellt wird, arbeiten auf dem Client Proxy in diesem Ausführungsbeispiel.)
  • Zunächst versucht der Benutzer des Browsers 675, auf eine spezifische Web Page zuzugreifen. Der Server 655 ermittelt bei Empfang dieser Anforderung bei Block 900 die Möglichkeiten des Browsers 675 (beispielsweise durch Untersuchen der Kopffelder des Anforderers, wie den Fachleuten bekannt ist). Bei Block 902, falls der Browser zu einer entsprechenden Verschlüsselungsstufe in der Lage ist, wird eine verschlüsselte Verbindung mit gegenseitiger Autorisierung (gezeigt in den 9A und 9B als eine SSL Sitzung, obwohl alternative Protokolle, wie TLS ebenfalls verwendet werden können) zwischen dem Browser Client und Proxy erstellt. (Zweck der Erstellung einer sicheren Sitzung zwischen Browser und Proxy ist es, den Proxy in die Lage zu versetzen, die Verschlüsselung von schützenswerten Informationen für den Client auszuführen, wobei die verschlüsselten Informationen vor dem Zugriff durch Dritte geschützt werden.) Andernfalls wird eine Verbindung ohne SSL hergestellt.
  • Block 904 testet, ob eine gegenseitig autorisierte SSL-Sitzung mit Verschlüsselung erstellt wurde. Wenn dies der Fall ist, wird die Verarbeitung an Block 906 fortgesetzt; andernfalls wird die Verarbeitung an Block 922 fortgesetzt. Bei Block 906 untersucht der Proxy 655 das Zertifikat des Clients (das während der Erstellung der SSL-Sitzung nach Stand der Technik bereitgestellt wurde). Eine Reihe von Tests kann für dieses Client-Zertifikat ausgeführt werden, unter Verwendung von Techniken, die den Fachleuten bekannt sind, etwa: Prüfen des Ablaufdatums, Prüfen, ob die Kette zurück zur Stammstelle validiert werden kann usw. Wenn das Zertifikat in Ordnung ist, durchsucht der Server 655 bei Block 908 das LDAP-Verzeichnis 640 (oder ein anderes Repository) nach dem Client Zertifikat, um den dazugehörigen DN zu erhalten. Wenn die an Block 906 durchgeführten Tests Probleme mit dem Zertifikat anzeigen (das Zertifikat ist beispielsweise abgelaufen), kann die Steuerung optional auf Block 920 übergehen, um dort das Problem mit dem Zertifikat zu lösen, wie unten beschrieben. (Alternativ dazu kann der Server 655 einfach die Client-Anforderung zurückweisen, wie etwa durch Ausgabe einer Fehlermeldung, wenn Block 906 ein negatives Ergebnis aufweist, wobei die Verarbeitung bei 9A endet. 9B wird in dieser Situation nicht aufgerufen, da der Client Proxy nicht in der Lage ist, dem anfordernden Benutzer ein sicheres Dokument bereitzustellen.)
  • Block 910 prüft, ob der zugehörige DN gefunden wurde. Wenn dies der Fall ist, kann der Server 655 optional die Verarbeitung an den Blöcken 912 und 914 ausführen. Diese optionale Verarbeitung umfasst zuerst das Testen des Blocks 912, um zu prüfen, ob das Zertifikat bald ablaufen wird ("bald" kann vom Systemadministrator oder durch Installationsvorgaben definiert werden, deren Informationen für Server 655 zugänglich sind, beispielsweise da Vorgabeninformationen in einer Datenbank oder in einem LDAP-Verzeichnis 640 gespeichert sind). Wenn das Zertifikat bald abläuft, wird diese optionale Verarbeitung an Block 914 fortgesetzt, wobei (unter der Voraussetzung, dass das Zertifikat des Benutzers von einer lokalen Zertifikatsstelle ausgegeben wurde und eine Neuautorisierungsanforderung für dieses bald ablaufende Zertifikat noch nicht ausgegeben wurde) setzt der Server 655 eine Neuautorisierungsanforderung (siehe 1270 in 12) in die Warteschlange der Administratoranwendung 630, setzt jedoch die Verarbeitung für den Client 675 fort. Wenn die optionale Verarbeitung der Blöcke 912 und 914 beendet wurde oder wenn diese Verarbeitung unterlassen wurde, speichert der Server 655 (Block 916) den DN des Benutzers mit dem Kontext der SSL-Sitzung zum späteren Verweisen (siehe die Beschreibung von Block 974, unten). Block 917 prüft dann, ob eine URL für ein selektiv verschlüsseltes Dokument bereits verfügbar ist, beispielsweise aus der Client-Anforderung an Block 900. Wenn dies der Fall ist, geht die Steuerung auf Block 942 in 9 über. Andernfalls bildet der Server 655 vorzugsweise eine benutzerdefinierte "http" Web Page (d.h. eine Web Page mit sicherem Hypertext Transport Protocol zur Übermittlung während der sicheren Sitzung) für den Benutzer 675 an Block 918, wie etwa ein Menü mit sicheren Dokumenten, das der Benutzer 675 anfordern kann. Alternativ dazu kann der Server 655 einfach ein Abfragemenü, etwa ein Datenbank-Frontend, dem Benutzer in Block 918 zur Verfügung stellen, wodurch der Benutzer nach bestimmten selektiv verschlüsselten Dokumenten suchen kann, die zur Verfügung stehen. Nach Beendigung der Verarbeitung in Block 918 geht die Steuerung auf Block 940 in 9B über, um dem anfordernden Benutzer eine selektiv verschlüsselte Seite zur Verfügung zu stellen.
  • Wenn in Block 904 keine SSL-Sitzung erstellt wurde (beispielsweise weil der Client 675 kein Zertifikat besitzt), kann eine optionale Prozedur ausgeführt werden, wobei der Server 655 versucht, Information zum Erstellen eines Client-Zertifikats zu sammeln. Diese optionale Prozedur umfasst die Blöcke 922 bis 932 und beginnt mit dem Server, der ein Registrierungsformular anzeigt (Block 922), um den Eintrag der notwendigen Identifikationsdaten durch den Benutzer zu erfassen. Der Benutzer gibt die angeforderten Informationen an Block 924 ein (beispielsweise Name, Unternehmen, Telefonnummer, E-Mail-Adresse, Mitarbeiternummer, Kreditkartennummer), die später unabhängig vom Systemadministrator 630 in dem Prozess geprüft werden können, der unten unter Verweis auf 12 beschrieben wird. (Es sollte den Fachleuten sein, dass die zu erfassenden und zu validierenden spezifischen Registrierungsidentifikationsdaten entsprechend der Anforderungen bestimmter Installationen variieren können. Es können dahingehend unternehmerische Vorgaben unter Verwendung des LDAP-Verzeichnisses 640 erstellt und unterstützt werden). Der Server ordnet dem Benutzer 675 einen Distinguished Name und ein Zertifikat (Block 926) zu. Es ist zu beachten, dass zu diesem Zeitpunkt das neue Zertifikat noch nicht mit Zugriffsprivilegien ausgestattet wurde. Es ermöglicht dem Benutzer 675 lediglich, bei späteren Besuchen eindeutig als dem DN zugeordneter Benutzer identifiziert zu werden, indem seine Beziehung zum Zertifikat nachgewiesen wird, das mit diesem DN verbunden ist, unter Verwendung einer digitalen Signatur. Bei Block 928 speichert der Server 655 (beispielsweise in einem LDAP-Verzeichnis 640) die Benutzerdateneingaben (aus Block 924), den DN und das Zertifikat zur späteren Verwendung.
  • Bei Block 930 erstellt der Server 655 eine "neue Benutzerbestätigungsanforderung" (siehe 1290 in 12), unter Verwendung der erhaltenen Registrierungsinformationen und platziert diese Anforderung in die Arbeitswarteschlange des Systemadministrators (siehe 1200 in 12) zur späteren Verarbeitung. Bei der Beendigung dieser optionalen Verarbeitung kann dem neuen Benutzer eine standardmäßige sichere Web Page angezeigt werden (Block 932), wobei diese standardmäßige Web Page eine Meldung anzeigen kann, wie etwa "Willkommen im sicheren Dokumentserversystem. Sie werden per E-Mail benachrichtigt, wenn Ihnen Zugriffsprivilegien zugewiesen wurden." Die Verarbeitung in 9A (und ebenfalls in 9B, da der Client Proxy noch kein sicheres Dokument für diesen Benutzer entschlüsseln kann) ist dann beendet.
  • Wenn in Block 906 eine sichere Sitzung erstellt wurde, jedoch Probleme mit dem Client-Zertifikat entdeckt wurden, kann eine weitere Funktion dieses bevorzugten Ausführungsbeispiels ausgeführt werden, indem die Steuerung von Block 906 auf Block 920 übergeht. Block 920 prüft, ob bereits Registrierungsdaten für diesen Client bestehen (beispielsweise im LDAP-Verzeichnis). Wenn nicht, kann die zuvor für die Blöcke 922 bis 932 beschriebene optionale Verarbeitung ausgeführt werden (oder aber die Verarbeitung endet einfach). Wenn bereits vorhandene Daten gefunden werden, kann der Server 655 entsprechend dieser optionalen Funktion fortfahren, indem eine Neuautorisierungsanforderung unter Verwendung dieser bestehenden Informationen erstellt wird, und die Steuerung geht auf Block 930 (oben beschrieben) über, um diese Anforderung zur Verarbeitung in die Warteschlange zu stellen.
  • Die gerade beschriebene optionale Funktion unter Verweis auf Block 920 kann ebenfalls (optional) von Block 910 aus aufgerufen werden, wenn die Suche für den DN des Client nicht erfolgreich ausgeführt werden konnte. Wenn Block 910 ein negatives Ergebnis aufweist, ist bekannt, dass der Client über ein gültiges Zertifikat verfügt (Ein Ergebnis "Ja" bei Block 906), jedoch kein DN im LDAP-Verzeichnis 640 oder in einem anderen Repository, durchsucht an Block 908, gefunden wurde, der mit diesem Zertifikat übereinstimmt.
  • Es ist den Fachleuten bekannt, dass die Verbreitung digitaler Zertifikate zu einem Problem wird, da sie unter den Benutzern Verwirrung stiften und möglicherweise zu Problemen in der Skalierbarkeit führen können, aufgrund der Anzahl an Zertifikaten, die zum Speichern, Zugreifen, Erneuern usw. für jeden Client erforderlich sind. Somit kann die optionale Verarbeitung von Block 920 zum Versuch einer Lokalisierung und Verwendung bereits vorhandener Registrierungsinformationen in einer Implementierung des bevorzugten Ausführungsbeispiels eingesetzt werden, mit dem Ziel, dass ein Benutzer mit einem gültigen Zertifikat (oder einem abgelaufenen Zertifikat, das nur erneuert werden muss, wie es der Fall ist, wenn diese Verarbeitung als Reaktion auf ein negatives Ergebnis bei Block 906 aufgerufen wird) zu diesem sicheren Dokumentsystem hinzugefügt werden kann, ohne dem Benutzer notwendigerweise ein neues Zertifikat ausstellen zu müssen. Wenn daher diese optionale Verarbeitung bestehende Registrierungsinformationen lokalisiert (Ein Ergebnis "Ja" in Block 920), werden diese bestehenden Informationen verwendet, um eine Arbeitsanforderung für den Administrator vorzubereiten (wie oben unter Verweis auf Block 930 beschrieben), der die Erstellung einer neuen Einheit anfordert (siehe 1290 in 12).
  • 9B zeigt die Verarbeitung, mit der der Client Proxy 655 ein selektiv verschlüsseltes Dokument entschlüsselt und einem Client 675 bereitstellt, nachdem die Verarbeitung von 9A ausgeführt wurde. Der Benutzer 675 wählt ein selektiv verschlüsseltes Dokument bei Block 940 (etwa von dem in Block 918 gezeigten Menü). Der Server ruft dann dieses angeforderte Dokument (Block 942) ab. (Es ist zu beachten, dass die Steuerung ebenfalls Block 942 erreicht, als Folge eines positiven Ergebnisses bei Block 917 in 9A). Der erweiterte XML-Preparser 660 auf dem Server 655 liest nun die DOM-Darstellung des Dokuments (Block 944) in der Strom-Reihenfolge (um sie mit der Reihenfolge abzugleichen, in der das Dokument während der Verschlüsselung analysiert wurde) für ein Element, das entsprechend der vorliegenden Erfindung verschlüsselt wurde. Wenn das an Block 944 befindliche Element nicht verschlüsselt ist (Ein Ergebnis "Nein" bei Block 946), setzt der Server die Verarbeitung an Block 966 fort, wobei die Volltextdaten an einen Output-Puffer angehängt werden. Wenn andernfalls das Element verschlüsselt ist, (ein "Ja"-Ergebnis bei Block 946) versucht der Proxy 655 eine Entschlüsselung dieses Elements für den Client 675.
  • Der Prozess der Entschlüsselung eines Elements für den Client 675 beginnt bei Block 948, wobei der Proxy 655 die Gruppenmitgliedschaft auf die DNs erweitert, die Gruppen in der Schlüsselklasse dieses Elements darstellen. Im Beispieldokument in 4C umfasst die Verarbeitung von Block 948 das Lokalisieren des Schlüsselklassen-Identifiers 456 beim Verarbeiten des verschlüsselten Elements 452, das Auffinden der DNs von Gruppen 471, 473 von den Schlüsselobjekten innerhalb der Schlüsselklasse 461 mit dem Identifier 453 (siehe 463), der sich im verschlüsselten Element-Tag befindet und anschließend Bestimmen der Mitgliedschaft dieser Gruppen mit dem gemeinsamen Namen "managers" 470 und "hr" 472. Wenn ein LDAP-Verzeichnis zum Speichern von Informationen zur Gruppenmitgliedschaft verwendet wird, wie bereits beschrieben, umfasst das Bestimmen der Mitgliedshaft die Ausgabe eines LDAP-Befehls für jeden DN, der einer Gruppe zugeordnet wurde, wobei dieser Befehl die DNs der einzelnen Gruppenmitglieder abruft. (Es ist klar, wenn ein Daten-Repository anstelle eines Verzeichnisses verwendet wird, um die Informationen zur Gruppenmitgliedschaft zu speichern, wird der Befehl entsprechend diesem Repository verwendet.) Alternativ dazu kann eine Abfrage durchgeführt werden, in der Form "Ist dieser (einzelner DN) ein Mitglied dieser (Gruppen-DN)?".
  • Nach Ausweitung der Gruppen in dieser Schlüsselklasse fragt Block 950, ob der Benutzer, für den der Proxy arbeitet, ein Mitglied einer dieser Gruppen ist. Wenn nicht, geht die Steuerung zu Block 964 über, wo vorzugsweise eine Nachricht generiert wird (anstelle der Verwendung des immer noch verschlüsselten Elements, wie oben unter Verweis auf Block 880 beschrieben) und an einen Output-Puffer angehängt (Block 966), um anzuzeigen, dass das Element nicht entschlüsselt werden kann. Wenn der Benutzer ein Mitglied von mindestens einer autorisierten Gruppe ist, fährt die Steuerung an Block 960 fort.
  • Block 960 lokalisiert den Verwalter für die Gruppe (oder wenn der Benutzer Mitglied mehrerer Gruppen mit Berechtigung für diese Schlüsselklasse ist, den Verwalter für jede der Gruppen), wobei der Verwalter der Besitzer des privaten Schlüssels für die Gruppe ist. Bei der Verwendung des LDAP-Verzeichnisses ist die Abfrage des LDAP-Verzeichnisses vorgesehen, unter Verwendung des Gruppen-DN, der für die Gruppe im Schlüsselobjekt identifiziert ist und den DN für den Gruppenverwalter anfordert. Wenn der Gruppenverwalter gefunden wurde (Block 962), geht die Steuerung zu Block 972 über; andernfalls gibt die Abwesenheit eines Gruppenverwalters vor, dass das Element für ein Gruppenmitglied nicht entschlüsselt werden kann und ein Ersatzelement zu diesem Zweck an den Output-Puffer in den Blöcken 964 und 966 angehängt wird.
  • Bei Block 972 erstellt der Proxy vorzugsweise eine sichere SSL (oder ein anderes gegenseitig autorisiertes Protokoll)-Sitzung für den Gruppenverwalter. Block 973 fordert dann beim Gruppenverwalter die Verschlüsselung des entschlüsselten symmetrischen Schlüssels vom Schlüsselobjekt an, wobei dieser Benutzer als ein autorisiertes Gemeinschaftsmitglied erstellt wird. Diese Anforderung an den Verwalter umfasst die Weiterleitung des Schlüsselobjekts mit dem verschlüsselten symmetrischen Schlüssel, dem Proxy Server-Zertifikat und dem DN des Benutzers. (Es ist zu beachten, dass der Proxy nur einmal für eine bestimmte Schlüsselklasse kontaktiert werden sollte, für die ein symmetrischer Schlüssel während der Verschlüsselung eines Dokuments benötigt wird.) Vorzugsweise werden diese Informationen digital gekennzeichnet, bevor sie vom Proxy zum Verwalter übergehen, wie etwa durch Signieren einer Nachricht mit dem privaten Schlüssel des Benutzers entsprechend dem X.509 Zertifikat des Benutzers. Die Signatur kann vor Angriffen durch Zwischenstationen oder Wiederabspielen schützen. (Verschiedene Methoden zum Signieren sind den Fachleuten bekannt und können verwendet werden, ohne dass vom Gegenstand der vorliegenden Erfindung abgewichen wird.) Wenn eine gegenseitig autorisierte, sichere Sitzung (wie etwa eine SSL- oder TSL-Sitzung) zwischen dem Proxy und dem Verwalter verwendet wird, ist die digitale Signatur der übertragenen Informationen nicht zwingend notwendig, da die verschlüsselte Sitzung äquivalente Datenintegrität bietet. In einem Aspekt dieses bevorzugten Ausführungsbeispiels (weiterhin beschrieben unter Verweis auf Block 982 unten) ist das zu entschlüsselnde Element ebenfalls Teil der signierten Informationen, die an den Verwalter weitergegeben werden. (Der DN des Benutzers wurde ja während der Verarbeitung von Block 916 gesichert.) Gehen wir nun bei Dokument 450 in 4C davon aus, dass der Benutzer als Mitglied der Gruppe "managers" 470, 471 festgelegt wurde. In diesem Fall wird das Schlüsselobjekt 464 durch Block 974 an den Verwalter der Gruppe Vorgesetzte (managers) weitergegeben, wobei der Verwalter angewiesen wird, Schlüssel 475 zu entschlüsseln.
  • Block 976 zeigt die Verarbeitung durch den Gruppenverwalter, wobei der Verwalter prüft, ob der Benutzer und der Proxy Server beide Mitglieder der berechtigten Gruppe sind. (Es ist zu beachten, dass der Proxy Server ein berechtigtes Gruppenmitglied sein soll, da er Zugriff auf die verschlüsselten schützenswerten Informationen hat, wenn der Entschlüsselungsprozess erfolgreich ausgeführt werden kann. Weiterhin kann der Proxy als ein Gruppenmitglied einer Gemeinschaft angegeben werden, unter Verwendung einer Syntax, ähnlich der in 470, 471 von 4C, wobei der Wert "managers" 470 durch einen Wert wie "proxy" oder "proxies" ersetzt wird. Wenn der Verwalter während Block 976 entdeckt, dass diese Gruppensyntax verwendet wurde, um den Proxy anzugeben, muss die Proxygruppe erweitert werden, wie oben für Block 948 beschrieben, um zu sicherzustellen, dass der Proxy tatsächlich ein berechtigtes Gemeinschaftsmitglied ist.) Wenn die an den Verwalter weitergegebenen Informationen digital signiert wurden (während der Verarbeitung von Block 974) umfasst der Überprüfungsprozess in Block 976 durch den Verwalter vorzugsweise auch die Überprüfung der digitalen Signatur (unter Verwendung von Techniken, die den Fachleuten bekannt sind), um sicherzustellen, dass der Anforderer die tatsächliche Quelle der Anforderung ist und dass die Informationen seit der Signatur nicht geändert worden sind, auch wenn diese Überprüfung ausgelassen werden kann, wenn die Informationen bei einer gegenseitig autorisierten, sicheren Sitzung empfangen wurden. Wenn Block 976 ein negatives Ergebnis ausgibt, wird ein Fehlercode oder ein anderer Indikator für einen aufgetretenen Fehler an den Proxy durch den Verwalter ausgegeben, um anzugeben, dass der Verwalter kein Element für diesen Proxy im Namen dieses Benutzers entschlüsseln wird. Die Steuerung geht dann zu Block 964 über, wo eine entsprechende Textnachricht im Output-Puffer platziert wird.
  • Wenn der Test in Block 976 erfolgreich ist, entschlüsselt der Verwalter anschließend (Block 978) den symmetrischen Schlüssel vom Schlüsselobjekt, das er in Block 974 erhalten hat. Der Verwalter besitzt einen privaten Schlüssel für jede Gruppe, für die er eine Verwalterfunktion ausführt. Somit wird der private Schlüssel für die im Schlüsselobjekt angegebene Gruppe für diesen Entschlüsselungsprozess verwendet. Block 980 prüft, ob die Entschlüsselung erfolgreich war. Wenn nicht, wird eine Fehlerbehandlung (wie für ein Ergebnis "Nein" in Block 976 beschrieben) ausgeführt. Wenn die Entschlüsselung erfolgreich war, hat der Verwalter den symmetrischen Schlüssel wiederhergestellt, der zum Entschlüsseln aller Dokumentelemente verwendet wurde, die auf dieses bestimmte Schlüsselobjekt verweisen (d.h. die für diese Gruppe autorisierten Dokumentelemente innerhalb der bestimmten Schlüsselklasse), und die Verarbeitung wird an Block 982 fortgesetzt.
  • In einem ersten Aspekt des bevorzugten Ausführungsbeispiels (wobei das in Block 944 lokalisierte Element nicht an den Verwalter in Block 974 weitergegeben wurde), nachdem der Verwalter den verschlüsselten symmetrischen Schlüssel entschlüsselt hat (Block 978 oben), unter Verwendung des privaten Schlüssels der Gruppe, kann der Verwalter den nun als Volltextschlüssel vorhandenen Schlüssel erneut verschlüsseln, unter Verwendung des öffentlichen Schlüssels des Proxys (der dem Proxy Zertifikat in Block 974 entnommen werden kann). Diese neue Version des symmetrischen Schlüssels wird dann durch den Verwalter digital signiert, unter Verwendung des privaten Schlüssels des Verwalters und an den Proxy (nicht gezeigt) zurückgegeben. Beim Empfangen dieses erneut verschlüsselten, signierten Schlüssels prüft der Proxy die digitale Signatur, um sicherzustellen, dass die Übertragung nicht von einem betrügerischen Verwalter gesendet wurde und dass sie nicht geändert wurde. Bei Block 982 wird dieser entschlüsselte Schlüssel dann vom Proxy verwendet, um das Element zu entschlüsseln, das von Block 944 lokalisiert wurde, und dieses Element wird dann an den Output-Puffer (Block 966) angehängt. In diesem Aspekt wird die Sicherheit der empfindlichen Informationen weiterhin sichergestellt, indem nur ein Prozess (beispielsweise der Proxy) auf den verschlüsselten Elementwert für den Benutzer zugreift, anstelle von zwei Prozessen (beispielsweise Proxy und der Verwalter, wie unten in einem alternativen Aspekt beschrieben). Optional dazu kann der Verwalter auch das Proxy Zertifikat (oder den entsprechenden Schlüssel-Identifier) ausgeben, wenn der erneut verschlüsselte Schlüssel ausgegeben wird, so dass der Proxy den entsprechenden privaten Schlüssel einfach auf seinem lokalen Schlüsselring oder der Schlüsselkette lokalisieren kann (vorausgesetzt, dass der Proxy über mehrere Zertifikate und mehrere private Schlüssel verfügen kann).
  • Es ist zu beachten, dass in diesem ersten Aspekt, da der Verwalter die empfindlichen Informationen entschlüsselt (der erneut verschlüsselte symmetrische Schlüssel zur Verwendung bei der Verschlüsselung des Dokumentelements), und die Informationen an den Proxy zurückgehen, es nicht unbedingt erforderlich ist, über eine gegenseitig autorisierte, sichere Sitzung zwischen diesen Parteien zu verfügen. Der Verwalter kann dann einfach den in Block 978 entschlüsselten Schlüssel an den Proxy über diese sichere Sitzung zurückgeben anstatt den Schlüssel erneut zu verschlüsseln und diese erneut verschlüsselte Version weiterzugeben.
  • In einem alternativen Aspekt dieses bevorzugten Ausführungsbeispiels wurde das zu entschlüsselnde Element an den Verwalter während der Operation von Block 974 weitergegeben. Der Verwalter verwendet den symmetrischen Schlüssel, den er an Block 978 entschlüsselt hat, um dieses Dokumentelement an Block 982 zu entschlüsseln. Das entschlüsselte Element kann dann unverschlüsselt vom Verwalter an den Proxy ausgegeben (nicht gezeigt) werden, vorausgesetzt, dass eine gegenseitig autorisierte, sichere Sitzung zwischen ihnen besteht. (Andernfalls, ähnlich wie die oben beschriebene Technik für den ersten Aspekt dieses Ausführungsbeispiels, wenn eine gegenseitig autorisierte, sichere Sitzung nicht verfügbar ist, muss der Verwalter das entschlüsselte Dokumentelement mit dem öffentlichen Schlüssel des Proxys erneut verschlüsseln, bevor das Element über eine nicht sichere Sitzung an den Proxy zurückgeht. Beim Empfangen dieses erneut verschlüsselten Elements überprüft der Proxy die digitale Signatur des Verwalters, um sicherzustellen, dass die Übertragung nicht von einem betrügerischen Verwalter gesendet und dass sie nicht verändert wurde. Der Proxy verwendet dann seinen eigenen privaten Schlüssel zum Entschlüsseln des erneut verschlüsselten Elements.) Das ausgegebene Element wird dann durch den Proxy an den Output-Puffer (Block 966) angehängt. Diese Art des optimierten Ausführungsbeispiels kann für eine Implementierung geeignet sein, in der die Verwalter- und die Proxyfunktion auf dem gleichen Rechner ausgeführt werden.
  • Nachdem Block 966 ein Element an den Output-Puffer angehängt hat (je nachdem, ob es sich um ein entschlüsseltes Element, eine Volltextversion eines Elements, das keine Verschlüsselung notwendig macht oder um eine Fehlernachricht handelt, die angibt, dass ein Element nicht verschlüsselt werden kann), überprüft Block 986, ob das verarbeitete Dokument weitere Elemente enthält. wenn dies der Fall ist, kehrt die Steuerung zu Block 944 zurück, um das nächste Element abzurufen. Andernfalls gibt Block 970 den nun vollständigen Output-Puffer mit dem Dokumentinhalt zurück an den anfordernden Benutzer in der sicheren Sitzung, für lokale Bereitstellung auf dem Gerät des Benutzers oder durch den Programm-Client und die Verarbeitung wird in 9B beendet. (Alternativ dazu kann die Steuerung nach Beendigung von Block 970 zu Block 940 zurückkehren, um dort auf eine erneute Auswahl durch diesen Benutzer zu warten.)
  • Es sollte klar sein, dass der Proxy 655 ebenfalls das entschlüsselte Dokument in ein oder mehrere andere getagte Formate konvertieren kann, die für einen bestimmten Client geeignet sind, beispielsweise HTML, Wireless Markup Language ("WML"), Standard Generalized Markup Language ("SGML") oder auch das interne Dateiformat, das von einem Wortprozessor oder Drucker verwendet, bevor der Dokumentinhalt bei Block 970 ausgegeben wird.
  • DRITTES BEVORZUGTES AUSFÜHRUNGSBEISPIEL ZUR VERSCHLÜSSELUNG
  • In einem weiteren bevorzugten Ausführungsbeispiel wird das verschlüsselte Dokument von einem Mitglied einer Gruppe angefordert und empfangen, wobei die Gruppe ein berechtigtes Mitglied einer Gemeinschaft sein kann, die Zugriff auf mindestens ein Element des selektiv verschlüsselten Dokuments hat. Das Gruppenmitglied verwendet dann einen Verwalterprozess zur Entschlüsselung des symmetrischen Schlüssels, damit das Gruppenmitglied bestimmte Felder des Dokuments entschlüsseln kann. Die Logik, mit der dieses bevorzugte Ausführungsbeispiel implementiert werden kann, wird in den 10A bis 10C gezeigt.
  • Die Verarbeitung in 10A beginnt mit einem Gruppenmitglied, das ein selektiv verschlüsseltes Dokument von einem Dokument Server bei Block 1000 anfordert (beispielsweise durch Auswahl eines Dokument-Identifiers aus einem Menü, durch Ausgabe einer Datenbankabfrage mit Auswahl und Abruf des Dokuments usw.). Block 1002 zeigt an, dass das Gruppenmitglied (auch als Benutzer für die restliche Beschreibung der 10A bis 10C bezeichnet) das angeforderte Dokument empfängt. Der Entschlüsselungsprozess beginnt. (Es ist zu beachten, dass während die Verarbeitung des Dokumentempfangs für ein Gruppenmitglied und für eine Einzelperson, die kein Gruppenmitglied ist, als separate Logik in den 10A bis 10C sowie in den 8A an 8B gezeigt wird, es den Fachleuten klar ist, dass die Logik für diese Fälle mit einer bestimmten Implementierung kombiniert werden kann. Ähnlich kann die Logik zur Verwendung eines Client Proxy beim Entschlüsseln eines Dokuments für einen Benutzer, wie in den 9A und 9B gezeigt, mit einem oder beiden Ansätzen kombiniert werden. Weiterhin kann die Technik zur Schlüsselwiederherstellung, wie sie unten unter Verweis auf 11 beschrieben wird, mit jeder beliebigen Kombination anderer Funktionen kombiniert werden.)
  • Block 1004 liest eine Schlüsselklasse (wie etwa 461, 462 von 4C) vom Stamm der DOM-Darstellung des abgerufenen Dokuments. Alle DNs in dieser Schlüsselklasse, die Gruppen darstellen, werden an Block 1006 erweitert (beispielsweise durch Ausgabe von LDAP-Abfragen zum Aufrufen der DNs der Gruppenmitglieder oder einer anderen äquivalenten Technik, wenn ein anderes Speicher-Repository verwendet wird). Block 1008 prüft, ob dieser Benutzer ein Mitglied einer dieser erweiterten Gruppen ist. (Alternativ dazu kann der Benutzer lokal gespeicherte Informationen konsultieren, um festzulegen, ob er selbst sich als Mitglied einer der Gruppen sieht. Diese lokal gespeicherten Informationen können aus dem Hinweis stammen, der unter Verweis auf die Blöcke 1240 und 1287 beschrieben wird.) Wenn dies der Fall ist, wird die Schlüsselklasse vorzugsweise zu einer Liste mit Schlüsselklassenobjekten in Block 1010 hinzugefügt, wobei die Liste aller zu entschlüsselnden Schlüsselklassen zur späteren Verarbeitung erstellt werden, entsprechend der Logik der Blöcke 1014 bis 1022, wie es beschrieben wird. Dieser Ansatz reduziert die Anzahl an sicheren Sitzungen und Netzwerkarbeit, wenn ein gegebener Verwalter für mehrere Gruppen zuständig ist. Alternativ dazu kann die Logik der Blöcke 1014 bis 1022 umgehend aufgerufen werden, wenn ein positives Ergebnis in Block 1008 festgestellt wird, mit der Möglichkeit zum Kontaktieren eines bestimmten Verwalters öfter als einmal. (Wenn ein bestimmter Benutzer Mitglied von mehr als einer Gruppe für eine beliebige gegebene Schlüsselklasse ist, kann eine Implementierungs-spezifische Entscheidung getroffen werden, welche Gruppe zu verarbeiten ist, welcher Verwalter zu kontaktieren ist und ob eine Lokalisierung des Verwalters fehlschlägt und die für diese ausgewählte Gruppe erfolgreich entschlüsselten Schlüsselobjekte verfolgt werden sollen, indem die Verarbeitung des Prozesses für jede nachfolgende Gruppe oder alternative Verwalter für die gleiche Gruppe, falls vorhanden, versucht werden.)
  • Die Steuerung erreicht 1012, wenn der Benutzer kein Mitglied einer erweiterten Gruppe ist (ein Ergebnis "Nein" bei Block 1008) und ebenfalls nach der Verarbeitung von Block 1010. Block 1012 prüft, ob mehr als eine Schlüsselklasse im DOM-Stamm besteht. Wenn dies der Fall ist, kehrt die Steuerung zu Block 1004 zurück, um die nächste Schlüsselklasse zu verarbeiten; andernfalls wird die Verarbeitung an Block 1014 fortgeführt.
  • Die in den Blöcken 1014 bis 1024 gezeigte Verarbeitung wird für jeden weiteren Verwalter wiederholt, der für die von Block 1010 erfassten Schlüsselklassen zuständig ist. Block 1014 lokalisiert den für eine Gruppe zuständigen Verwalter. Ein Gruppenverwalter muss kontaktiert werden, um den symmetrischen verschlüsselten Schlüssel einer Gruppe (wie etwa Schlüssel 475 von 4C) zu lokalisieren, da Benutzer, die Gruppenmitglieder sind, keinen lokalen Zugriff zum privaten Schlüssel der Gruppe haben. Stattdessen besitzt der Verwalter diesen privaten Schlüssel. Vorzugsweise wird der Gruppenverwalter lokalisiert, indem auf die Informationen für die Gruppe im LDAP-Verzeichnis (oder in einem anderen Repository) zugegriffen wird, wobei diese Informationen die Identifikation des Verwalters umfassen. Block 1016 fragt, ob der Gruppenverwalter gefunden wurde. Wenn nicht, wird die restliche Logik von 10a für diese Gruppe (oder Gruppen, wenn mehrere Gruppen den gleichen Verwalter verwenden) umgangen und die Verarbeitung wird an Block 1028 von 10B fortgeführt. (Alle verschlüsselten Elemente in Schlüsselklassen, für die dieses Umgehen der Logik erfolgt, können nicht entschlüsselt werden, wie unter Verweis auf 10B beschrieben werden wird.)
  • Nach dem erfolgreichen Lokalisieren eines Gruppenverwalters erstellt Block 1018 vorzugsweise eine SSL- oder eine andere gegenseitig autorisierte, sichere Sitzung zwischen dem Benutzer und dem Verwalter. Vorzugsweise signiert der Benutzer dann digital jedes Schlüsselklassenobjekt, das an den Verwalter (Block 1020) übertragen wird. (Wie zuvor unter Verweis auf Block 974 von 9B beschrieben, ist es nicht zwingend notwendig, die Schlüsselklassenobjekte digital zu signieren, wenn sie bei einer gegenseitig autorisierten, sicheren Sitzung übertragen werden sollen.) Die Schlüsselklassenobjekte und das entsprechende Signaturzertifikat des Benutzers (oder sein entsprechender Schlüssel-Identifier) werden dann an den Verwalter übertragen (Block 1022). (Es ist zu beachten, dass wenn eine gegenseitig autorisierte, sichere Sitzung nicht erstellt wurde, das Zertifikat des Benutzers an den Verwalter übertragen werden muss; andernfalls kann der Schlüssel-Identifier stattdessen übertragen werden.) Die Verarbeitung, die beim Gruppenverwalter erfolgt, in Reaktion auf den Empfang dieser Informationen, wird in 10C gezeigt und im folgenden beschrieben.
  • Bei Block 1060 von 10C hat der Verwalterprozess ein oder mehrere Schlüsselklassenobjekte empfangen, die für den Benutzer entschlüsselt werden müssen, zusammen mit dem Zertifikat des Benutzers (oder äquivalent dazu der DN des Benutzers und der Schlüssel-Identifier). Jedes Schlüsselklassenobjekt wird entsprechend der Logik der Blöcke 1060 bis 1070 verarbeitet. Danach ist der Verwalter fertig und wartet auf die nächste Anforderung. Block 1060 erhält ein Schlüsselklassenobjekt von den weitergegebenen Informationen. Wenn die Informationen digital signiert wurden, überprüft der Verwalter vorzugsweise diese digitale Signatur. (Wie zuvor unter Verweis auf Block 976 von 9B beschrieben, kann die Erstellung digitaler Signaturen und deren Überprüfung umgangen werden, wenn Informationen in einer gegenseitig autorisierten, sicheren Sitzung übertragen werden). Bei Block 1062 prüft der Verwalter, ob der Anforderer ein berechtigtes Mitglied der Gruppe ist, dessen DN im Schlüsselklassenobjekt erscheint, durch Abfrage des Verzeichnisses oder eines anderen Repositories zur Bestimmung der Gruppenmitglieder. Wenn der Anforderer kein berechtigtes Gruppenmitglied ist, geht die Steuerung zu Block 1068 über, ohne weitere Verarbeitung dieses Schlüsselklassenobjekts. Andernfalls, wenn Block 1062 ein positives Ergebnis aufweist, entschlüsselt der Verwalter den symmetrischen verschlüsselten Schlüssel des Schlüsselklassenobjekts unter Verwendung der lokalen Kopie des privaten Schlüssels der Gruppe. (Der öffentliche Schlüssel der Gruppe wurde verwendet, um dieses Feld zu verschlüsseln, entsprechend Block 780 von 7C.) Der Verwalter verschlüsselt dann erneut das Ergebnis (Block 1066), unter Verwendung des öffentlichen Schlüssels des Anforderers, wie vom Zertifikat bestimmt, das mit der Entschlüsselungsanforderung weitergegeben wurde. (Alternativ dazu, wenn ein DN und ein Schlüssel-Identifier mit der Entschlüsselungsanforderung weitergegeben wurden anstelle eines Zertifikats, verwendet der Verwalter den DN, um eine Liste der Zertifikate vom LDAP-Verzeichnis oder einem anderen Repository zu erhalten, die diesem DN entsprechen. Der Verwalter wählt dann ein bestimmtes Zertifikat aus den ausgegebenen Zertifikaten aus, unter Verwendung des weitergegebenen Schlüssel-Identifiers und der öffentliche Schlüssel aus diesem bestimmten Zertifikat wird in Block 1066 verwendet.) Der Verwalter kann alternativ dazu die erneute Verschlüsselung des Ergebnisses in Block 1066 umgehen, vorausgesetzt, dass eine gegenseitig autorisierte, sichere Sitzung während Block 1018 erstellt wurde.
  • Wenn sich mehrere Schlüsselklassenobjekte in dieser Anforderung (Block 1068) befinden, wird der nächste Schlüssel verarbeitet, indem die Steuerung zu Block 1060 zurückkehrt; andernfalls werden die Schlüsselklassenobjekte und die erneut verschlüsselten symmetrischen Schlüssel (oder abhängig von der gerade beschriebenen alternativen Verarbeitung ein oder mehrerer Volltextschlüssel und/oder Volltextdokumentelemente oder erneut verschlüsselte Dokumentelemente) vom Verwalter digital verschlüsselt (wenn die Sitzung zwischen dem Anforderer und dem Verwalter keine gegenseitig autorisierte, sichere Sitzung ist) und an den Anforderer (Block 1070) ausgegeben, wonach die Verarbeitung von 10C endet.
  • In 10A wird in Block 1024 die Verarbeitung des Benutzers fortgeführt, nachdem die Verarbeitung des Verwalters in 10C beendet wurde, durch den Empfang der weitergeleiteten Schlüsselobjekte. Optional kann das weitergegebene Zertifikat (oder der Schlüssel-Identifier) ebenfalls ausgegeben werden, so dass der Anforderer auf einfache Weise den entsprechenden privaten Schlüssel auf seinem privaten Schlüsselring oder Kette lokalisieren kann (vorausgesetzt, ein Anforderer kann mehr als ein Zertifikat und privaten Schlüssel haben). Wenn die ausgegebenen Informationen digital durch den Verwalter signiert wurden, überprüft der Benutzer als erstes die digitale Signatur, um sicherzustellen, dass die Informationen nicht von einem Betrüger erstellt oder geändert wurden. (Wenn die Sitzung zwischen dem Benutzer und dem Verwalter eine gegenseitig autorisierte, sichere Sitzung ist, ist die Signatur durch den Verwalter und die Überprüfung durch den Benutzer nicht erforderlich.) Der Benutzer entschlüsselt dann den symmetrischen Schlüssel aus jedem Schlüsselklassenobjekt, das von einem Gruppenverwalter (Block 1026) ausgegeben wurde, unter Verwendung des privaten Schlüssels des Benutzers. (Oder wenn die Schlüssel unverschlüsselt bei einer gegenseitig autorisierten, sicheren Sitzung ausgegeben wurden, ist diese Entschlüsselung in Block 1026 nicht erforderlich: diese nicht verschlüsselten Schlüssel werden direkt zum Entschlüsseln der Elemente der zugehörigen Klasse verwendet.) Der Benutzer ist nun in der Lage, die Elemente für diese Schlüsselklasse zu entschlüsseln, wie unter Verweis auf 10B beschrieben.
  • Die Elemente des DOM werden in der Stromreihenfolge (Block 928) gelesen, um mit der Reihenfolge übereinzustimmen, in der sie während der Verschlüsselung gelesen und verarbeitet werden. Block 1030 fragt, ob das gerade lokalisierte Element verschlüsselt ist. Wenn nicht, geht die Steuerung zu Block 1038 über, wobei das unverschlüsselte Element an einen zu erstellenden Output-Puffer angehängt wird. Andernfalls, wenn das Element verschlüsselt ist, prüft Block 1032, ob ein entschlüsselter symmetrischer Schlüssel für die Schlüsselklasse besteht, die diesem Element zugeordnet ist. Wenn kein solcher entschlüsselter symmetrischer Schlüssel vorhanden ist (beispielsweise weil der Benutzer kein Mitglied einer berechtigten Gruppe für dieses Element ist oder der Gruppenverwalter nicht lokalisiert werden konnte usw.), dann ist dieser Benutzer nicht berechtigt, das verschlüsselte Element anzuzeigen, und eine entsprechende Nachricht wird anstelle des verschlüsselten Elements an Block 1034 ausgegeben. Wenn der symmetrische Schlüssel für diese Schlüsselklasse erfolgreich entschlüsselt wurde, weist Block 1032 ein positives Ergebnis aus und Block 1036 verwendet diesen entschlüsselten Schlüssel, um das Element zu entschlüsseln. Block 1038 hängt dann das Ergebnis an den Output-Puffer an. Wenn noch weitere zu verarbeitende Elemente vorhanden sind (Ein Ergebnis "Ja" bei Block 1040), kehrt die Verarbeitung zu Block 1028 zurück; andernfalls ist der Output-Puffer vollständig und sein Inhalt wird dem Benutzer an Block 1042 bereitgestellt. Die Verarbeitung des verschlüsselten Dokuments sowie 10B sind nun beendet.
  • VIERTES BEVORZUGTES AUSFÜHRUNGSBEISPIEL ZUR VERSCHLÜSSELUNG
  • Es kann notwendig werden, den gesamten Inhalt des Dokuments wiederherzustellen (beispielsweise dann, wenn ein in einem firmeneigenen Repository gespeichertes verschlüsseltes Dokument Gegenstand eines Interessenkonflikts wird) unabhängig davon, wie das Dokument in verschiedene Schlüsselklassen während des Verschlüsselungsprozesses aufgeteilt wurde. Ein weiteres bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung definiert eine Technik, mit der ein berechtigter Benutzer (wie etwa ein Systemadministrator usw.) alle Schlüssel wiederherstellen kann, die zum Verschlüsseln eines solchen Dokuments verwendet wurden. Die Logik für diese Technik zur Schlüsselwiederherstellung wird in den 11A und 11B gezeigt.
  • Entsprechend einem bevorzugten Ausführungsbeispiel wird die Partei mit der Berechtigung zur Wiederherstellung aller Schlüssel (im folgenden als "Key Recovery Agent" bezeichnet) als ein berechtigtes Gemeinschaftsmitglied für jede Schlüsselklasse jedes Dokuments definiert. Dadurch wird ein Schlüsselobjekt für den Key Recovery Agent im Dokument für jede Schlüsselklasse eingefügt, wobei das Schlüsselobjekt einen symmetrischen Schlüssel umfasst, der mit dem öffentlichen Schlüssel des Key Recovery Agents verschlüsselt wurde. Somit kann der private Schlüssel des Key Recovery Agents verwendet werden, um den symmetrischen Schlüssel zu entschlüsseln, falls dies notwendig wird, und so Zugriff auf die verschlüsselten Elemente der Schlüsselklasse zu gewähren.
  • Es ist zu beachten, dass diese Technik zur Schlüsselwiederherstellung auch in anderen Situationen von Vorteil sein kann, beispielsweise: Der private Schlüssel, der andernfalls zur Entschlüsselung eines Dokumentelements verwendet würde, ginge verloren; ein Benutzer mit einem privaten Schlüssel verläßt das Unternehmen, ohne den privaten Schlüsselwert anzugeben; ein Benutzer mit einem privaten Schlüssel als Gruppenmitglied wird neu zugeordnet und ist nicht länger ein Gruppenmitglied usw.
  • 11A zeigt zusätzlich eine Logik, die in den Logikfluss von 7A oben für den Verschlüsselungsprozess eingefügt werden kann. (Es ist zu beachten, dass diese zusätzliche Logik nicht unbedingt erforderlich ist, wenn sicher festgestellt werden kann, das der Key Recovery Agent in die Gemeinschaft für jedes gespeicherte Vorgabenobjekt eingefügt wurde. Die Verwendung dieser zusätzlichen Logik bietet jedoch eine Technik zur Sicherstellung, dass der Key Recovery Agent Zugriff auf die Elemente in jeder Schlüsselklasse erhält.)
  • Die Logik von 11A ändert den Steuerungsfluss von Block 725 zu Block 730 von 7A und so werden diese Ersatzblöcke in 11A als Blöcke 725' bis 730' dargestellt. Entsprechend der Operation von Block 725' fragt Block 726 ob der Key Recovery Agent ein Mitglied der abgerufenen Gemeinschaft ist. Wenn nicht, fügt Block 727 den DN (oder einen anderen ähnlichen Identifier bei Verwendung eines Speicher-Repositories, das kein LDAP-Verzeichnis ist) für den Key Recovery Agent hinzu. Somit, wenn die verschlüsselten symmetrischen Schlüssel später erstellt werden (siehe Block 780 in 7C), wird der öffentliche Schlüssel des Key Recovery Agents in einem Schlüsselobjekt mit dem DN des Agents verwendet, und der Agent wird nachfolgend in der Lage sein, diesen symmetrischen Schlüssel (und seine zugehörigen Elemente) unter Verwendung seines privaten Schlüssels zu entschlüsseln.
  • 11B zeigt, wie der Logikfluss von 8B optional geändert werden kann, um den Key Recovery Agent einzubeziehen. Die Blöcke 855', 865' und 875' der 11B stellen die gleiche Funktion dar, wie die Blöcke 855, 865, 870 und 875 der 8B. (Eine detaillierte Beschreibung dieser Verarbeitung finden Sie in der Beschreibung von 8B.) Da es sich jedoch beim Key Recovery Agent immer um ein berechtigtes Gemeinschaftsmitglied handelt, weist der vorhandene Test an Block 860 von 8B immer ein positives Ergebnis auf, weshalb dieser Test sowie Block 880 (für die Verarbeitung bei einem negativen Ergebnis) ausgelassen werden können. Es ist klar, dass die in 11B gezeigte Änderung nur gemacht werden sollte, wenn die Implementierung speziell auf den Key Recovery Agent zugeschnitten wird.
  • ADMINISTRATION
  • 12 zeigt das bevorzugte Ausführungsbeispiel der Logik, mit der ein Administrator oder ein Administrationsprozess das sichere Dokumentsystem der vorliegenden Erfindung einrichten und verwalten können. Diese Logik beginnt an der Arbeitsanforderungswarteschlange 1200, wobei einer der Prozessoren 1210, 1220, 1250, 1270 oder 1290 entsprechend der Art von Arbeitsanforderung verteilt wird.
  • In Block 1210 erstellt der Administrator 630 eine neue Gruppe durch 1215, wodurch ein Eintrag für die Gruppe in das LDAP-Verzeichnis 640 gestellt wird. Block 1219 zeigt an, dass keine weitere Verarbeitung für diese Art von Arbeitsanforderung notwendig ist. Es ist zu beachten, dass nach der Erstellung einer Gruppe diese nicht funktional ist, bis mindestens eine Verwalter-Einheit und mindestens Benutzer-Einheit der Gruppe zugeordnet wurden. Eine Gruppe kann über mehr als einen Verwalter verfügen. Sie kann über Null oder mehrere autorisierte Agents (Proxies) verfügen.
  • In Block 1220 fügt der Administrator 630 eine Einheit zu einer Gruppe hinzu. In Block 1225 wird ein Test darüber durchgeführt, ob die Gruppe im LDAP-Verzeichnis 640 bereits vorhanden ist, als Ergebnis einer vorherigen Gruppenerstellung 1210. Wenn nicht, liegt ein Fehler vor (Block 1245). In Block 1230 wird ein Test darüber durchgeführt, ob die hinzuzufügende Einheit im LDAP-Verzeichnis 640 (als Ergebnis einer vorherigen Einheitenerstellung 1290) bereits besteht. Wenn nicht, liegt hier ebenfalls ein Fehler vor (Block 1245). Wenn beide Tests bestanden sind, wird die Einheit in Block 1235 zur Gruppe hinzugefügt. Dann wird die Einheit optional informiert (Block 1240). Dabei kann es sich beispielsweise um eine E-Mail-Nachricht handeln, die den Benutzer auffordert, sich im sicheren Dokumentsystem anzumelden, da nun auf sichere Dokumente zugegriffen werden kann. Block 1249 zeigt an, dass keine weitere Verarbeitung für diese Art von Arbeitsanforderung erforderlich ist. Eine solche Mitteilung kann ebenfalls eine optimierte Implementierung ermöglichen, in der ein Gruppenmitglied lokal entscheidet, dass es einen Kontakt zum Verwalter versuchen sollte, ohne zuvor eine, möglicherweise sehr lange, Liste aller Gruppenmitglieder aus einem LDAP-Verzeichnis abzurufen, um seine eigene Gruppenmitgliedschaft festzustellen.
  • In Block 1250 entfernt der Administrator 630 eine Einheit aus einer Gruppe. In Block 1255 wird ein Test darüber durchgeführt, ob die Gruppe bereits im LDAP-Verzeichnis vorhanden ist. Wenn nicht, liegt ein Fehler vor (Block 1245). In Block 1260 wird ein Test darüber durchgeführt, ob die zu entfernende Einheit im LDAP-Verzeichnis 640 bereits vorhanden ist. Wenn nicht, liegt hier ebenfalls ein Fehler vor (Block 1245). Wenn die Einheit ein Mitglied mehrerer Gruppen ist und die Einheit vollständig aus allen Gruppen entfernt werden soll, wird Block 1265 für jede einzelne Gruppe wiederholt. Wenn das Zertifikat der Einheit nicht im entsprechenden Block 1280 erstellt wurde, wird die Liste der Zertifikatswiederrufe aktualisiert (Block 1267), beispielsweise durch eine Eingabe im LDAP-Verzeichnis 640 und/oder durch Kontaktieren der Zertifikatsstelle (Certificate Authority = CA) 635. Block 1269 gibt an, dass keine weitere Verarbeitung für diese Art von Arbeitsanforderung erforderlich ist.
  • In Block 1270 gibt der Administrator 630 erneut eine Berechtigung für eine Einheit aus, die derzeit Mitglied einer Gruppe ist, wie etwa nach dem Empfang einer Anforderung zur Neuvergabe einer Berechtigung (siehe Block 914 von 9A). In Block 1275 wird ein Test darüber durchgeführt, ob die Zugriffsprivilegien oder das Zertifikat der Einheit zurückgezogen wurden. Wenn dies der Fall ist, wird der Prozess an 1278 weitergeführt, wo eine Arbeitsanforderung zum Rückgängigmachen einer Einheit verarbeitet wird (Block 1250), über den Eingabepunkt 1205. Wenn nicht, untersucht der Administrator 630 in Block 1277 die Registrierungsdaten, die vom Benutzer 675 (in Block 924 von 9A) gegeben wurden. Wenn die Daten zufriedenstellend sind, gibt der Administrator 630 ein aktualisiertes Zertifikat mit einem neuen Fälligkeitsdatum aus (Block 1280), aktualisiert das Verzeichnis (Block 1285) und gibt optional eine Mitteilung an die Einheit (Block 1287) aus. Block 1289 zeigt an, dass keine weitere Verarbeitung für diese Art der Arbeitsanforderung notwendig ist. Wenn die Registrierungsdaten (ein Ergebnis "Nein" in Block 1277) nicht in Ordnung sind, wird die Verarbeitung an Block 1278 weitergeführt, wobei eine Arbeitsanforderung Anforderung rückgängig machen (Block 1250) verarbeitet wird.
  • In Block 1290 verarbeitet der Administrator 630 eine Anforderung zum Erstellen einer neuen Einheit 655, 670, 675 oder 680. Zunächst untersucht der Administrator 630 die Registrierungsdaten (aus Block 924 von 9A) an Block 1292. Wenn die an Block 1294 vorhandenen Daten zufriedenstellend sind, gibt der Administrator 630 ein neues Zertifikat aus, falls notwendig, auf eine Art, ähnlich der Blöcke 1280 bis 1287, andernfalls wird das vorhandene Zertifikat der Einheit verwendet, festgestellt, (Block 1298) welche Gruppen zur Einheit hinzugefügt werden sollen, diese Gruppenzusätze verarbeitet, wie etwa durch Erstellen mehrerer Arbeitsanforderungen (Block 1300) und dieser als Input in Block 1200 in eine Warteschlange gestellt und anschließend mehrmals zum Block 1202 zum Verarbeiten dieser Anforderungen in der Warteschlange verzweigt. Block 1309 zeigt an, dass keine weitere Verarbeitung für diese Art der Arbeitsanforderung erforderlich ist.
  • Somit kann am Ende der Administrationsverarbeitung in Block 1220 bis 1249 und den notwendigen Vorgängern ein Client die Logik der Blöcke 902 bis 918 von 9A durchführen (Erstellen einer SSL-Sitzung auf dem sicheren Dokument Server 655) und die Logik der 9B ausführen, um ein verschlüsseltes Dokument auszufüllen, es zu entschlüsseln und die Elemente des Dokuments anzuzeigen, für die der Benutzer 675 über eine Berechtigung verfügt.
  • Wie gezeigt, bietet das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung einen einfach zu handhabenden Ansatz zur Unterstützung der Sicherheitsvorgaben. Die Informationen der Sicherheitsvorgaben können sich je nach Datenelement unterscheiden und werden spezifiziert, indem der Datenvorgabe-Identifier (d.h. die URI, in der die Vorgabe gespeichert ist) an das Datenelement in der Dokument-DTD gebunden wird. Die vorliegende Erfindung ist rückwärts kompatibel, es können XML-Dokumente mit XSL-Prozessoren verwendet werden, die zur Verwendung der Vorgabeninstrumentierung entsprechend der vorliegenden Erfindung geändert wurden, oder die Dokumente können mit XSL-Prozessoren verwendet werden, die nicht auf diese Art verändert wurden. (Solche unveränderten XSL-Prozessoren führen einfach die Einheitenersetzung der Datenvorgaben-URIs innerhalb der DTD aus, rufen aber die Vorgabenobjekte nicht ab oder verarbeiten sie, auf die durch die URIs verwiesen wird.)
  • Ein weiterer Vorteil der vorliegenden Erfindung ist es, dass keine Änderung im Stylesheet erforderlich ist, das die Transformation steuert. Die Stylesheet-Verweise auf die Wert-von-Methode bleiben unverändert. Die vorliegende Erfindung unterstützt die Sicherheitsvorgaben durch Überschreiben des Codes, der beim Aufrufen einer Wert-von-Methode vom (unveränderten) Stylesheet abgerufen wird. (Es wäre natürlich möglich, einen Stylesheet zu ändern, um die Vorteile des Vorgaben-Markups des XML-Dokuments zu nutzen, falls gewünscht.)
  • Die vorliegende Erfindung ist gegenüber dem Format der Sicherheitsvorgabe selbst neutral. Erforderlich zur Unterstützung einer Sicherheitsvorgabe ist nur, dass auf die Vorgabe durch eine URI zugegriffen werden kann (wie etwa die Verweise auf Vorgabenobjekte in einem LDAP-Verzeichnis, wie in 3 gezeigt) und natürlich, dass die Vorgaben von der Instrumentierung erkannt werden, die die Vorgaben im XSL-Prozessor unterstützen. Dies hat den weiteren Vorteil der Langlebigkeit dieser Lösungsimplementierung, da die Implementierung des bevorzugten Ausführungsbeispiels nicht angepasst werden muss, da neue Anforderungen an die unternehmenseigenen Sicherheitsvorgaben eine Änderung in der Vorgabencodierung und Instrumentierung nach sich ziehen: Die gespeicherten Sicherheitsvorgaben werden dann einfach aktualisiert, um die neuen Sicherheitsanforderungen zu unterstützen und die Verweise auf die gespeicherte Vorgabe können nötigenfalls aktualisiert werden (falls beispielsweise die aktualisierte Vorgabe an einem anderen Speicherort gespeichert wurde).
  • Obwohl das bevorzugte Ausführungsbeispiel unter Verwendung von Stylesheets beschrieben wurde, können auch Stylesheets anderer Mitteilungen als XSL verwendet werden (beispielsweise Dokument Style Semantics und Specification Language oder DSSSL, was internationaler Standard ISO/IEC 10179: 1996 ist), ohne dass vom Gegenstand der vorliegenden Erfindung abgewichen wird. Zusätzlich kann der beschriebene vorgabenorientierte XSL-Prozessor verwendet werden, um verschlüsselte Dokumente in Nicht-XML-Formaten zu generieren, die SGML-abgeleitete Markierungen, wie etwa HTML, verwenden, es muss jedoch für ein solches Format ein Decoder unter Verwendung der hier definierten Logik für den erweiterten XML-Prozessor geändert werden, so dass das Dokument entschlüsselt werden kann. Dieser Prozess jedoch kann kein verwendbares Dokument liefern, wenn der Benutzer zur Anzeige aller Dokumentdaten keine Berechtigung hat, aufgrund vorausgesetzter Beziehungsregeln in den Nicht-XML-Language-Tags.
  • Während das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung beschrieben wurde, sind zusätzliche Varianten und Änderungen an diesem Ausführungsbeispiel denkbar, was den Fachleuten klar sein dürfte. Somit sind die angehängten Ansprüche so angelegt, das bevorzugte Ausführungsbeispiel sowie denkbare Varianten und Änderungen zu umfassen, die Gegenstand der vorliegenden Erfindung sein können.

Claims (24)

  1. Eine Methode zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung in einer Computerumgebung, folgende Schritte umfassend: Bereitstellen eines Input-Dokuments; Bereitstellen eines oder mehrerer Vorgabenunterstützungsobjekte, wobei jedes der genannten Vorgabenunterstützungsobjekte eine Sicherheitsvorgabe angibt, die Null oder mehreren Elementen des genannten Input-Dokuments zugeordnet werden kann; Bereitstellen einer Document Type Definition (DTD) entsprechend dem genannten Input-Dokument, wobei die genannte DTD mit einem oder mehreren Verweisen auf die ausgewählten gespeicherten Vorgabenunterstützungsobjekte erweitert wurde; Ausführen eines erweiterten Stylesheet-Prozessors, weiterhin folgende Schritte umfassend: Laden der genannten DTD; Auflösen der genannten einen oder mehreren Verweise in der genannten geladenen DTD; Instantiieren der genannten Vorgabenunterstützungsobjekte, die den genannten aufgelösten Verweisen zugeordnet sind; Ausführen von ausgewählten der instantiierten Vorgabenunterstützungsobjekte während der Anwendung von einem oder mehreren Stylesheets auf das genannte Input-Dokument, wobei ein Ergebnis der genannten Ausführung der ausgewählten Schritte ein Interims-Dokument ist, das die genannte Ausführung wiedergibt; Generieren eines oder mehrerer zufallsgenerierter Verschlüsselungsschlüssel; Verschlüsseln ausgewählter Elemente des genannten Interims-Dokuments, wobei ein spezieller der genannten erstellten, zufallsgenerierten, verschlüsselten Verschlüsselungsschlüssel verwendet werden kann, um eines oder mehrere der ausgewählten Elemente zu verschlüsseln, während Null oder mehr Elemente des genannten Interims-Dokuments unverschlüsselt bleiben; Verschlüsseln jedes zufallsgenerierten Verschlüsselungsschlüssels; und Erstellen eines verschlüsselten Output-Dokuments mit Null oder mehreren unverschlüsselten Elementen, den genannten ausgewählten verschlüsselten Elementen und den genannten verschlüsselten Verschlüsselungsschlüsseln; Empfang des genannten verschlüsselten Output-Dokuments an einem Client-Gerät; Ausführen eines erweiterten Dokumentprozessors, einschließlich des Schritts zum Entschlüsseln des genannten empfangenen Dokuments für einen einzelnen Benutzer oder Prozess auf dem genannten Client-Gerät, wobei ein Ergebnisdokument erstellt wird; und Bereitstellen des genannten Ergebnisdokuments auf dem genannten Client-Gerät.
  2. Die Methode nach Anspruch 1, wobei das genannte Interims-Dokument einen oder mehrere Verschlüsselungs-Tags umfasst, die die zu verschlüsselnden Elemente angeben.
  3. Die Methode nach Anspruch 1, wobei das genannte Input-Dokument in einer Extensible Markup Language (XML)-Schreibweise angegeben wird.
  4. Die Methode nach Anspruch 3, wobei das genannte Output-Dokument in der genannten XML-Schreibweise angegeben wird.
  5. Die Methode nach Anspruch 1, wobei die genannten gespeicherten Vorgabenunterstützungsobjekte weiterhin einen ausführbaren Code zum Überschreiben einer Methode zur Auswertung der genannten Elemente des genannten Input-Dokuments umfassen, und wobei die Ausführung der genannten ausgewählten Schritte weiterhin das Überschreiben der genannten Methode zur Auswertung umfasst.
  6. Die Methode nach Anspruch 5, wobei die genannten Stylesheets in einer Extensible Markup Language (XSL)-Schreibweise angegeben werden.
  7. Die Methode nach Anspruch 6, wobei die genannte Methode eine Wert-von-Methode der genannten XSL-Schreibweise ist und wobei der genannte Schritt zum Überschreiben der genannten Wert-von-Methode in der Unterklassenbildung der genannten Wert-von-Methode besteht.
  8. Die Methode nach Anspruch 2 oder Anspruch 7, wobei Der genannte Schritt zum Überschreiben weiterhin folgende Schritte umfasst: Generieren von Verschlüsselungs-Tags; und Einfügen der genannten generierten Verschlüsselungs-Tags in das genannte Interims-Dokument, um die Elemente des genannten Interims-Dokument einzukreisen, die als zu verschlüsselnd bestimmt wurden; und Der genannte Schritt zum verschlüsseln ausgewählter Elemente die Elemente verschlüsselt, die von den genannten Verschlüsselungs-Tags umkreist sind.
  9. Die Methode nach Anspruch 1, wobei jedes genannte instantiierte Vorgabenunterstützungsobjekt weiterhin folgendes umfasst: Eine Spezifikation der Gemeinschaft, die zur Anzeige der genannten Elemente berechtigt ist, welche mit der Sicherheitsvorgabe verbunden sind; und Eine Verschlüsselungsanforderung für die genannten Elemente, die mit der genannten Sicherheitsvorgabe verbunden sind.
  10. Die Methode nach Anspruch 9, wobei die genannte Verschlüsselungsanforderung weiterhin die Spezifikation eines Verschlüsselungsalgorithmus umfasst.
  11. Die Methode nach Anspruch 9, wobei die Verschlüsselungsanforderung weiterhin die Spezifikation eines Wertes für die Stärke des Verschlüsselungsalgorithmus umfasst.
  12. Die Methode nach Anspruch 9, wobei: Der genannte Schritt zum Verschlüsseln der genannten Verschlüsselungsschlüssel weiterhin folgenden Schritt umfasst: Verschlüsseln einer anderen Version jedes zufallsgenerierten Verschlüsselungsschlüssels für jedes der Mitglieder jeder der Gemeinschaften, die den genannten Verschlüsselungsschlüssel verwenden und wobei jede der genannten unterschiedlichen Versionen unter Verwendung eines öffentlichen Schlüssels des genannten Gemeinschaftsmitglieds verschlüsselt wird, für den eine unterschiedliche Version verschlüsselt wurde.
  13. Die Methode nach Anspruch 9, wobei die genannte Verschlüsselungsanforderung über einen Nullwert verfügen kann, um anzuzeigen, dass die genannte spezifizierte Sicherheitsvorgabe keine Verschlüsselung erfordert.
  14. Die Methode nach Anspruch 1, wobei der genannte Schritt zum Verschlüsseln ausgewählter Elemente einen Verschlüsselungsprozess im Modus Verschlüsselungsblockverkettung verwendet.
  15. Die Methode nach Anspruch 12, weiterhin folgenden Schritt umfassend: Erstellen einer Schlüsselklasse für jede eindeutige Gemeinschaft, wobei die genannte Schlüsselklasse jedem der genannten verschlüsselten Elemente zugeordnet wird, für das diese eindeutige Gemeinschaft zur Anzeige berechtigt ist und wobei die genannte Schlüsselklasse folgendes umfasst: (1) eine stärkste Verschlüsselungsanforderung der genannten zugeordneten verschlüsselten Elemente; (2) einen Identifier für jedes Mitglied der genannten eindeutigen Gemeinschaft und (3) eine genannte unterschiedliche Version der genannten verschlüsselten Verschlüsselungsschlüssel für jedes der genannten Gemeinschaftsmitglieder; und wobei: Der genannte Schritt zum Generieren der genannten einen oder mehrere zufallsgenerierten Verschlüsselungsschlüssel einen bestimmten der genannten zufallsgenerierten Verschlüsselungsschlüssel für jede der genannten Schlüsselklassen generiert und wobei jede der unterschiedlichen Versionen in einer bestimmten Schlüsselklasse vom genannten generierten Schlüssel für die genannte Schlüsselklasse verschlüsselt wird; und Der genannte Schritt zum Verschlüsseln ausgewählter Elemente den einen bestimmten zufallsgenerierten Verschlüsselungsschlüssel verwendet, der für die genannte Schlüsselklasse generiert wurde, mit der das genannte Element verbunden wurde.
  16. Die Methode nach Anspruch 12, wobei Der genannte Schritt zum Entschlüsseln des genannten Output-Dokuments weiterhin folgende Schritte umfasst: Bestimmen von Null bis mehreren der genannten Gemeinschaften, deren Mitglied der genannte einzelne Benutzer oder Prozess ist; Entschlüsseln für jede der genannten Gemeinschaften die genannte andere Version des genannten zufallsgenerierten Verschlüsselungsschlüssels, der mit Hilfe des öffentlichen Schlüssels des Mitglieds verschlüsselt worden ist, wobei der genannte Schritt zum Entschlüsseln einen privaten Schlüssel des genannten Benutzers verwendet, der dem öffentlichen Schlüssel zugeordnet ist, welcher zum Verschlüsseln eingesetzt wurde, wobei ein entschlüsselter Schlüssel erstellt wird; und Entschlüsseln der ausgewählten genannten verschlüsselten Elemente im genannten Output-Dokument unter Verwendung der genannten entschlüsselten Schlüssel, wobei die genannten ausgewählten entschlüsselten Elemente jene sind, die für eine bestimmte Gemeinschaft verschlüsselt wurden; und Der genannte Schritt zur Bereitstellung weiterhin folgenden Schritt umfasst: Bereitstellen der ausgewählten entschlüsselten und der genannten anderen nicht entschlüsselten Elemente.
  17. Die Methode nach Anspruch 15, wobei: Der genannte Schritt zum Entschlüsseln des genannten Output-Dokuments weiterhin folgende Schritte umfasst: Bestimmen von Null bis mehreren der genannten Schlüsselklassen, die den genannten einzelnen Benutzer oder Prozess als Mitglied identifizieren; Entschlüsseln für jede der genannten Schlüsselklassen die genannte andere Version des genannten zufallsgenerierten Verschlüsselungsschlüssels in der genannten Schlüsselklasse, der mit Hilfe des öffentlichen Schlüssels des Mitglieds verschlüsselt worden ist, wobei der genannte Schritt zum Entschlüsseln einen privaten Schlüssel des genannten Benutzers verwendet, der dem öffentlichen Schlüssel zugeordnet ist, welcher zum Verschlüsseln eingesetzt wurde, wobei ein entschlüsselter Schlüssel erstellt wird; und Entschlüsseln der ausgewählten genannten verschlüsselten Elemente im genannten Output-Dokument unter Verwendung der genannten entschlüsselten Schlüssel, wobei die genannten ausgewählten verschlüsselten Elemente jene sind, die für eine bestimmte Schlüsselklasse verschlüsselt wurden; und Der genannte Schritt zur Bereitstellung weiterhin folgenden Schritt umfasst: Bereitstellen der ausgewählten entschlüsselten und der genannten anderen nicht entschlüsselten Elemente.
  18. Die Methode nach den Ansprüchen 16 oder 17, wobei der genannte Schritt zur Bereitstellung weiterhin folgenden Schritt umfasst: den Schritt zur Bereitstellung einer Ersatztextnachricht für jedes der ausgewählten verschlüsselten Elemente im genannten Output-Dokument, das nicht durch den genannten Schritt zum Entschlüsseln des genannten Output-Dokuments entschlüsselt werden kann.
  19. Die Methode nach Anspruch 1, wobei die genannte DTD durch ein Schema ersetzt wird.
  20. Die Methode nach Anspruch 9, wobei die genannte Verschlüsselungsanforderung weiterhin die Spezifikation einer Verschlüsselungsschlüssellänge umfasst.
  21. Die Methode nach Anspruch 8, wobei die eingefügten Verschlüsselungs-Tags entweder die Werte der genannten Elemente oder die Werte und Tags der genannten Elemente umrunden können.
  22. Ein System zur Unterstützung der Sicherheitsvorgaben unter Verwendung von Stylesheet-Verarbeitung in einer Computerumgebung, wobei das genannte Computersystem Mittel umfasst, um die Schritte der Methode nach einem der vorangegangenen Ansprüche 1 bis 21 auszuführen.
  23. Ein Computerprogramm, das direkt in den internen Speicher eines digitalen Computers geladen werden kann, das Softwarecode-Teile zur Ausführung der Methode nach jedem der vorangegangenen Ansprüche 1 bis 21 umfasst, wenn das genannte Programm auf dem genannten Computer ausgeführt wird.
  24. Ein Computerprogramm, das auf einem computerverwendbaren Medium gespeichert ist und das ein computerlesbares Programm umfasst, das einen Computer dazu veranlasst eine Methode nach jedem der Ansprüche 1 bis 21 auszuführen, wenn das genannte Programm auf dem genannten Computer ausgeführt wird.
DE10051571A 1999-10-21 2000-10-18 Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung Expired - Fee Related DE10051571B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/422,430 1999-10-21
US09/422,430 US6931532B1 (en) 1999-10-21 1999-10-21 Selective data encryption using style sheet processing

Publications (2)

Publication Number Publication Date
DE10051571A1 DE10051571A1 (de) 2001-04-26
DE10051571B4 true DE10051571B4 (de) 2006-06-29

Family

ID=23674848

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10051571A Expired - Fee Related DE10051571B4 (de) 1999-10-21 2000-10-18 Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung

Country Status (2)

Country Link
US (1) US6931532B1 (de)
DE (1) DE10051571B4 (de)

Families Citing this family (181)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7212632B2 (en) 1998-02-13 2007-05-01 Tecsec, Inc. Cryptographic key split combiner
US6694433B1 (en) * 1997-05-08 2004-02-17 Tecsec, Inc. XML encryption scheme
US8077870B2 (en) * 1998-02-13 2011-12-13 Tecsec, Inc. Cryptographic key split binder for use with tagged data elements
US6298446B1 (en) * 1998-06-14 2001-10-02 Alchemedia Ltd. Method and system for copyright protection of digital images transmitted over networks
US20010029582A1 (en) * 1999-05-17 2001-10-11 Goodman Daniel Isaac Method and system for copy protection of data content
US7249318B1 (en) * 1999-11-08 2007-07-24 Adobe Systems Incorporated Style sheet generation
US7590644B2 (en) * 1999-12-21 2009-09-15 International Business Machine Corporation Method and apparatus of streaming data transformation using code generator and translator
US7346848B1 (en) 2000-06-21 2008-03-18 Microsoft Corporation Single window navigation methods and systems
US7155667B1 (en) 2000-06-21 2006-12-26 Microsoft Corporation User interface for integrated spreadsheets and word processing tables
US7000230B1 (en) 2000-06-21 2006-02-14 Microsoft Corporation Network-based software extensions
US6883168B1 (en) 2000-06-21 2005-04-19 Microsoft Corporation Methods, systems, architectures and data structures for delivering software via a network
US7191394B1 (en) 2000-06-21 2007-03-13 Microsoft Corporation Authoring arbitrary XML documents using DHTML and XSLT
US6948135B1 (en) 2000-06-21 2005-09-20 Microsoft Corporation Method and systems of providing information to computer users
US7624356B1 (en) 2000-06-21 2009-11-24 Microsoft Corporation Task-sensitive methods and systems for displaying command sets
US7117435B1 (en) 2000-06-21 2006-10-03 Microsoft Corporation Spreadsheet fields in text
JP4003203B2 (ja) * 2000-08-10 2007-11-07 サイファーゲート株式会社 暗号化プログラムを記録した記録媒体及び復号化プログラムを記録した記録媒体
US7165175B1 (en) * 2000-09-06 2007-01-16 Widevine Technologies, Inc. Apparatus, system and method for selectively encrypting different portions of data sent over a network
US7428583B1 (en) * 2000-10-31 2008-09-23 Intel Corporation Network policy distribution
DE50011222D1 (de) * 2000-12-04 2005-10-27 Siemens Ag Verfahren zum Nutzen einer Datenverarbeitungsanlage abhängig von einer Berechtigung, zugehörige Datenverarbeitungsanlage und zugehöriges Programm
US20020116633A1 (en) * 2001-01-19 2002-08-22 Takuya Kobayashi Data processor
US7240285B2 (en) * 2001-03-01 2007-07-03 Sony Corporation Encoding and distribution of schema for multimedia content descriptions
EP1410293A2 (de) * 2001-06-12 2004-04-21 Research In Motion Limited System und verfahren zum komprimieren sicherer e-mails zum austausch mit einer mobildatenkommunikationseinrichtung
AU2002317062A1 (en) * 2001-06-12 2002-12-23 Research In Motion Limited Method for processing encoded messages for exchange with a mobile data communication device
CA2450584C (en) 2001-06-12 2011-01-04 Research In Motion Limited Certificate management and transfer system and method
US20020187828A1 (en) * 2001-06-12 2002-12-12 Jamal Benbrahim Method and apparatus for securing gaming machine operating data
US20040205248A1 (en) * 2001-07-10 2004-10-14 Herbert A Little System and method for secure message key caching in a mobile communication device
US20030018668A1 (en) * 2001-07-20 2003-01-23 International Business Machines Corporation Enhanced transcoding of structured documents through use of annotation techniques
US8019081B2 (en) * 2001-08-06 2011-09-13 Research In Motion Limited System and method for processing encoded messages
US20030046532A1 (en) * 2001-08-31 2003-03-06 Matthew Gast System and method for accelerating cryptographically secured transactions
WO2003029981A1 (fr) * 2001-09-28 2003-04-10 Sony Corporation Appareil de limitation d'acces, procede de limitation d'acces, programme lisible par ordinateur comprenant un support comportant un programme de limitation d'acces, et programme de limitation d'acces
DE50112767D1 (de) * 2001-10-05 2007-09-06 Stefan Krempl Verfahren und System zur autorisierten Entschlüsselung von verschlüsselten Daten mit mindestens zwei Zertifikaten
JP4045777B2 (ja) * 2001-10-30 2008-02-13 株式会社日立製作所 情報処理装置
US7412720B1 (en) * 2001-11-02 2008-08-12 Bea Systems, Inc. Delegated authentication using a generic application-layer network protocol
US7318238B2 (en) * 2002-01-14 2008-01-08 Microsoft Corporation Security settings for markup language elements
US20050005116A1 (en) * 2002-09-18 2005-01-06 Commerce One Operations, Inc. Dynamic interoperability contract for web services
JP3914861B2 (ja) * 2002-11-29 2007-05-16 Ｎｅｃインフロンティア株式会社 通信システム
US7774831B2 (en) * 2002-12-24 2010-08-10 International Business Machines Corporation Methods and apparatus for processing markup language messages in a network
US7370066B1 (en) 2003-03-24 2008-05-06 Microsoft Corporation System and method for offline editing of data files
US7415672B1 (en) 2003-03-24 2008-08-19 Microsoft Corporation System and method for designing electronic forms
US7913159B2 (en) 2003-03-28 2011-03-22 Microsoft Corporation System and method for real-time validation of structured data files
US7296017B2 (en) 2003-03-28 2007-11-13 Microsoft Corporation Validation of XML data files
US7516145B2 (en) * 2003-03-31 2009-04-07 Microsoft Corporation System and method for incrementally transforming and rendering hierarchical data files
KR100548354B1 (ko) * 2003-06-14 2006-02-02 엘지전자 주식회사 동기화 프로토콜에서의 사용자 인증 방법
JP4504099B2 (ja) * 2003-06-25 2010-07-14 株式会社リコー デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
US7451392B1 (en) 2003-06-30 2008-11-11 Microsoft Corporation Rendering an HTML electronic form by applying XSLT to XML using a solution
US8200775B2 (en) * 2005-02-01 2012-06-12 Newsilike Media Group, Inc Enhanced syndication
US7406660B1 (en) 2003-08-01 2008-07-29 Microsoft Corporation Mapping between structured data and a visual surface
US7334187B1 (en) 2003-08-06 2008-02-19 Microsoft Corporation Electronic form aggregation
US7788485B2 (en) * 2003-08-07 2010-08-31 Connell John M Method and system for secure transfer of electronic information
DE602004024407D1 (de) * 2003-08-12 2010-01-14 Research In Motion Ltd System und verfahren zur anzeige der verschlüsselungsstärke
US7930757B2 (en) * 2003-10-31 2011-04-19 Adobe Systems Incorporated Offline access in a document control system
US8627489B2 (en) 2003-10-31 2014-01-07 Adobe Systems Incorporated Distributed document version control
US7512976B2 (en) * 2003-11-06 2009-03-31 International Business Machines Corporation Method and apparatus for XSL/XML based authorization rules policy implementation
US9489687B2 (en) * 2003-12-04 2016-11-08 Black Duck Software, Inc. Methods and systems for managing software development
US7552093B2 (en) * 2003-12-04 2009-06-23 Black Duck Software, Inc. Resolving license dependencies for aggregations of legally-protectable content
US8700533B2 (en) * 2003-12-04 2014-04-15 Black Duck Software, Inc. Authenticating licenses for legally-protectable content based on license profiles and content identifiers
US7602903B2 (en) * 2004-01-16 2009-10-13 Microsoft Corporation Cryptography correctness detection methods and apparatuses
JP3945708B2 (ja) * 2004-01-23 2007-07-18 インターナショナル・ビジネス・マシーンズ・コーポレーション 情報処理システム、変換処理システム、逆変換処理システム、変換方法、変換プログラム、及び記録媒体
US9461825B2 (en) * 2004-01-30 2016-10-04 Broadcom Corporation Method and system for preventing revocation denial of service attacks
US20050172132A1 (en) 2004-01-30 2005-08-04 Chen Sherman (. Secure key authentication and ladder system
US8819072B1 (en) 2004-02-02 2014-08-26 Microsoft Corporation Promoting data from structured data files
US7640573B2 (en) * 2004-02-16 2009-12-29 Microsoft Corporation Generic security claim processing model
US7716728B2 (en) * 2004-02-16 2010-05-11 Microsoft Corproation Security scopes and profiles
WO2005082102A2 (en) * 2004-02-26 2005-09-09 Datapower Technology, Inc. Method and apparatus of streaming data transformation using code generator and translator
US7873831B2 (en) * 2004-02-26 2011-01-18 Microsoft Corporation Digests to identify elements in a signature process
US7496500B2 (en) * 2004-03-01 2009-02-24 Microsoft Corporation Systems and methods that determine intent of data and respond to the data based on the intent
US20060036551A1 (en) * 2004-03-26 2006-02-16 Microsoft Corporation Protecting elementary stream content
US20060184790A1 (en) * 2004-03-26 2006-08-17 Microsoft Corporation Protecting elementary stream content
KR101043336B1 (ko) * 2004-03-29 2011-06-22 삼성전자주식회사 디바이스와 휴대형 저장장치간의 디지털 권리객체에 관한정보의 획득 및 제거를 위한 방법 및 장치
US7496837B1 (en) 2004-04-29 2009-02-24 Microsoft Corporation Structural editing with schema awareness
US7743425B2 (en) * 2004-04-29 2010-06-22 Microsoft Corporation Security restrictions on binary behaviors
CN1951074B (zh) * 2004-04-30 2012-05-23 捷讯研究有限公司 处理安全消息的系统和方法
US7627757B2 (en) * 2004-04-30 2009-12-01 Research In Motion Limited Message service indication system and method
US7281018B1 (en) 2004-05-26 2007-10-09 Microsoft Corporation Form template data source change
US7774620B1 (en) 2004-05-27 2010-08-10 Microsoft Corporation Executing applications at appropriate trust levels
KR101169021B1 (ko) * 2004-05-31 2012-07-26 삼성전자주식회사 디바이스와 휴대형 저장장치간의 권리객체 정보 전달 방법및 장치
JP4587162B2 (ja) * 2004-06-04 2010-11-24 キヤノン株式会社 情報処理装置、情報処理方法及びそのプログラム
US20060036849A1 (en) * 2004-08-09 2006-02-16 Research In Motion Limited System and method for certificate searching and retrieval
US9094429B2 (en) 2004-08-10 2015-07-28 Blackberry Limited Server verification of secure electronic messages
US7549043B2 (en) * 2004-09-01 2009-06-16 Research In Motion Limited Providing certificate matching in a system and method for searching and retrieving certificates
US7631183B2 (en) 2004-09-01 2009-12-08 Research In Motion Limited System and method for retrieving related certificates
US7640428B2 (en) * 2004-09-02 2009-12-29 Research In Motion Limited System and method for searching and retrieving certificates
GB0419889D0 (en) * 2004-09-08 2004-10-13 Ibm Accessing a data item in a memory of a computer system
JP2006094241A (ja) * 2004-09-24 2006-04-06 Fuji Xerox Co Ltd 暗号化装置、暗号化処理方法及びプログラム、並びに該暗号化装置を用いた情報保護システム
US7692636B2 (en) 2004-09-30 2010-04-06 Microsoft Corporation Systems and methods for handwriting to a screen
US8487879B2 (en) 2004-10-29 2013-07-16 Microsoft Corporation Systems and methods for interacting with a computer through handwriting to a screen
US7712022B2 (en) 2004-11-15 2010-05-04 Microsoft Corporation Mutually exclusive options in electronic forms
US7721190B2 (en) 2004-11-16 2010-05-18 Microsoft Corporation Methods and systems for server side form processing
US7533420B2 (en) * 2004-12-09 2009-05-12 Microsoft Corporation System and method for restricting user access to a network document
US7904801B2 (en) 2004-12-15 2011-03-08 Microsoft Corporation Recursive sections in electronic forms
US7937651B2 (en) 2005-01-14 2011-05-03 Microsoft Corporation Structural editing operations for network forms
US20070050446A1 (en) 2005-02-01 2007-03-01 Moore James F Managing network-accessible resources
US9202084B2 (en) * 2006-02-01 2015-12-01 Newsilike Media Group, Inc. Security facility for maintaining health care data pools
US8700738B2 (en) 2005-02-01 2014-04-15 Newsilike Media Group, Inc. Dynamic feed generation
US8140482B2 (en) 2007-09-19 2012-03-20 Moore James F Using RSS archives
US8347088B2 (en) 2005-02-01 2013-01-01 Newsilike Media Group, Inc Security systems and methods for use with structured and unstructured data
US7725834B2 (en) 2005-03-04 2010-05-25 Microsoft Corporation Designer-created aspect for an electronic form template
US7797245B2 (en) 2005-03-18 2010-09-14 Black Duck Software, Inc. Methods and systems for identifying an area of interest in protectable content
US8010515B2 (en) 2005-04-15 2011-08-30 Microsoft Corporation Query to an electronic form
US8078740B2 (en) 2005-06-03 2011-12-13 Microsoft Corporation Running internet applications with low rights
US20060288207A1 (en) * 2005-06-17 2006-12-21 Research In Motion Limited Encoding messages for use in a communication system based on classificaiton status
US8200975B2 (en) 2005-06-29 2012-06-12 Microsoft Corporation Digital signatures for network forms
US8832047B2 (en) 2005-07-27 2014-09-09 Adobe Systems Incorporated Distributed document version control
JP4596538B2 (ja) * 2005-09-05 2010-12-08 京セラミタ株式会社 情報処理装置、記録媒体、およびプログラム
WO2007030920A2 (en) * 2005-09-12 2007-03-22 Sand Box Technologies Inc. System and method for controlling distribution of electronic information
DE602005020482D1 (en) * 2005-10-14 2010-05-20 Research In Motion Ltd Masterverschlüsselung
US7987509B2 (en) * 2005-11-10 2011-07-26 International Business Machines Corporation Generation of unique significant key from URL get/post content
US7921165B2 (en) * 2005-11-30 2011-04-05 Microsoft Corporation Retaining mail for availability after relay
US8001459B2 (en) 2005-12-05 2011-08-16 Microsoft Corporation Enabling electronic documents for limited-capability computing devices
JP4684872B2 (ja) * 2005-12-05 2011-05-18 キヤノン株式会社 情報処理装置、データ通信装置及びそれらの制御方法、アドレス管理システム、プログラム
DE102005062042A1 (de) * 2005-12-22 2007-06-28 Applied Security Gmbh Datenobjektverarbeitungssystem und Verfahren zur Bearbeitung von elektronischen Datenobjekten
US7810160B2 (en) * 2005-12-28 2010-10-05 Microsoft Corporation Combining communication policies into common rules store
US7734754B2 (en) * 2005-12-28 2010-06-08 Microsoft Corporation Reviewing effectiveness of communication rules system
US20100235924A1 (en) * 2006-01-20 2010-09-16 Bulot Earl J Secure Personal Medical Process
US7779343B2 (en) 2006-01-30 2010-08-17 Microsoft Corporation Opening network-enabled electronic documents
US7292160B1 (en) 2006-04-19 2007-11-06 Microsoft Corporation Context sensitive encoding and decoding
US20070255704A1 (en) * 2006-04-26 2007-11-01 Baek Ock K Method and system of de-identification of a record
CN100507818C (zh) * 2006-04-30 2009-07-01 国际商业机器公司 使用户能够在一个文档中选择多个对象的方法及装置
US8549295B2 (en) * 2006-05-31 2013-10-01 Microsoft Corporation Establishing secure, mutually authenticated communication credentials
US8028026B2 (en) * 2006-05-31 2011-09-27 Microsoft Corporation Perimeter message filtering with extracted user-specific preferences
US8726020B2 (en) * 2006-05-31 2014-05-13 Microsoft Corporation Updating configuration information to a perimeter network
US7814161B2 (en) 2006-06-23 2010-10-12 Research In Motion Limited System and method for handling electronic mail mismatches
US8185737B2 (en) 2006-06-23 2012-05-22 Microsoft Corporation Communication across domains
US7865742B2 (en) * 2006-07-12 2011-01-04 Palo Alto Research Center Incorporated Method, apparatus, and program product for enabling access to flexibly redacted content
US7861096B2 (en) * 2006-07-12 2010-12-28 Palo Alto Research Center Incorporated Method, apparatus, and program product for revealing redacted information
US7873838B2 (en) * 2006-07-12 2011-01-18 Palo Alto Research Center Incorporated Method, apparatus, and program product for flexible redaction of content
US8352999B1 (en) * 2006-07-21 2013-01-08 Cadence Design Systems, Inc. Method for managing data in a shared computing environment
US8166113B2 (en) * 2006-08-02 2012-04-24 Microsoft Corporation Access limited EMM distribution lists
JP4983165B2 (ja) * 2006-09-05 2012-07-25 ソニー株式会社 通信システムおよび通信方法、情報処理装置および方法、デバイス、プログラム、並びに記録媒体
US7934247B2 (en) * 2006-09-07 2011-04-26 International Business Machines Corporation Encryption policy based on data context recognition
US8230235B2 (en) * 2006-09-07 2012-07-24 International Business Machines Corporation Selective encryption of data stored on removable media in an automated data storage library
US7681045B2 (en) * 2006-10-12 2010-03-16 Black Duck Software, Inc. Software algorithm identification
US8010803B2 (en) 2006-10-12 2011-08-30 Black Duck Software, Inc. Methods and apparatus for automated export compliance
US8504846B2 (en) * 2007-05-25 2013-08-06 Samsung Electronics Co., Ltd. Method and apparatus for secure storing of private data on user devices in telecommunications networks
US10019570B2 (en) 2007-06-14 2018-07-10 Microsoft Technology Licensing, Llc Protection and communication abstractions for web browsers
JP5196883B2 (ja) * 2007-06-25 2013-05-15 パナソニック株式会社 情報セキュリティ装置および情報セキュリティシステム
US9237148B2 (en) * 2007-08-20 2016-01-12 Blackberry Limited System and method for displaying a security encoding indicator associated with a message attachment
US8266630B2 (en) * 2007-09-03 2012-09-11 International Business Machines Corporation High-performance XML processing in a common event infrastructure
US8295486B2 (en) * 2007-09-28 2012-10-23 Research In Motion Limited Systems, devices, and methods for outputting alerts to indicate the use of a weak hash function
US7949934B2 (en) * 2007-10-24 2011-05-24 Microsoft Corporation Enabling pseudo-class styles without revealing personal information
US8824684B2 (en) * 2007-12-08 2014-09-02 International Business Machines Corporation Dynamic, selective obfuscation of information for multi-party transmission
US20090216678A1 (en) * 2008-02-25 2009-08-27 Research In Motion Limited System and method for facilitating secure communication of messages associated with a project
US8341141B2 (en) * 2008-12-16 2012-12-25 Krislov Clinton A Method and system for automated document registration
US8589372B2 (en) 2008-12-16 2013-11-19 Clinton A. Krislov Method and system for automated document registration with cloud computing
US8914351B2 (en) 2008-12-16 2014-12-16 Clinton A. Krislov Method and system for secure automated document registration from social media networks
US8751826B2 (en) * 2009-04-01 2014-06-10 Salesforce.Com, Inc. Enhanced system security
US8468345B2 (en) 2009-11-16 2013-06-18 Microsoft Corporation Containerless data for trustworthy computing and data services
US9537650B2 (en) 2009-12-15 2017-01-03 Microsoft Technology Licensing, Llc Verifiable trust for data through wrapper composition
US10348693B2 (en) * 2009-12-15 2019-07-09 Microsoft Technology Licensing, Llc Trustworthy extensible markup language for trustworthy computing and data services
US20110197144A1 (en) * 2010-01-06 2011-08-11 Terry Coatta Method And System Of Providing A Viewing Experience With Respect To A Document Having Read-only Content
US8584213B2 (en) 2010-09-29 2013-11-12 Xerox Corporation Automated encryption and password protection for downloaded documents
US8869259B1 (en) * 2011-05-19 2014-10-21 Zscaler, Inc. Cloud based inspection of secure content avoiding man-in-the-middle attacks
US9251143B2 (en) 2012-01-13 2016-02-02 International Business Machines Corporation Converting data into natural language form
US9350714B2 (en) * 2013-11-19 2016-05-24 Globalfoundries Inc. Data encryption at the client and server level
US9152812B2 (en) * 2013-12-03 2015-10-06 Paypal, Inc. Sensitive data protection during user interface automation testing systems and methods
US9241004B1 (en) * 2014-03-11 2016-01-19 Trend Micro Incorporated Alteration of web documents for protection against web-injection attacks
WO2015143083A1 (en) * 2014-03-18 2015-09-24 SmartSheet.com, Inc. Systems and methods for analyzing electronic communications to dynamically improve efficiency and visualization of collaborative work environments
US10853515B2 (en) 2014-09-15 2020-12-01 Salesforce.Com, Inc. Secure storage and access to sensitive data
US10176153B1 (en) * 2014-09-25 2019-01-08 Amazon Technologies, Inc. Generating custom markup content to deter robots
US20170046531A1 (en) * 2015-08-14 2017-02-16 Strong Bear Llc Data encryption method and system for use with cloud storage
US9654492B2 (en) 2015-09-15 2017-05-16 Mimecast North America, Inc. Malware detection system based on stored data
US10728239B2 (en) 2015-09-15 2020-07-28 Mimecast Services Ltd. Mediated access to resources
US10536449B2 (en) 2015-09-15 2020-01-14 Mimecast Services Ltd. User login credential warning system
US9467435B1 (en) * 2015-09-15 2016-10-11 Mimecast North America, Inc. Electronic message threat protection system for authorized users
US11595417B2 (en) 2015-09-15 2023-02-28 Mimecast Services Ltd. Systems and methods for mediating access to resources
US20170346639A1 (en) * 2016-05-24 2017-11-30 Business Information Exchange System Corp. Public Key Infrastructure based on the Public Certificates Ledger
US10158611B2 (en) 2016-11-17 2018-12-18 Bank Of America Corporation System for multiplexing and demultiplexing blockchain ledgers via a cryptographic hash
US9934138B1 (en) * 2016-12-07 2018-04-03 International Business Machines Corporation Application testing on a blockchain
US10642987B2 (en) 2017-01-19 2020-05-05 Ebay Inc. Cryptography based fraud tracking
US10791196B2 (en) 2017-08-29 2020-09-29 Wickr Inc. Directory lookup for federated messaging with a user from a different secure communication network
US11095662B2 (en) 2017-08-29 2021-08-17 Amazon Technologies, Inc. Federated messaging
US11368442B2 (en) * 2017-08-29 2022-06-21 Amazon Technologies, Inc. Receiving an encrypted communication from a user in a second secure communication network
US11349659B2 (en) * 2017-08-29 2022-05-31 Amazon Technologies, Inc. Transmitting an encrypted communication to a user in a second secure communication network
US20190272538A1 (en) * 2018-03-01 2019-09-05 Matrics2, Inc. Using a nested random number-based security ecosystem for block chains for electronic cash tokens and other embodiments
US11722470B2 (en) * 2018-08-29 2023-08-08 International Business Machines Corporation Encrypted data according to a schema
US20210334406A1 (en) * 2020-03-27 2021-10-28 EMC IP Holding Company LLC Intelligent and reversible data masking of computing environment information shared with external systems
KR102382850B1 (ko) * 2020-04-29 2022-04-05 주식회사 쓰리케이소프트 Xml 웹문서 보안 방법
CN112422494B (zh) * 2020-08-06 2022-09-23 上海幻电信息科技有限公司 数据传输方法、数据安全验证方法及数据传输系统
CN112822255B (zh) * 2020-12-31 2023-02-28 平安科技（深圳）有限公司 基于区块链的邮件处理方法、邮件发送端、接收端及设备
CN112818388B (zh) * 2021-01-25 2023-04-14 北方工业大学 一种基于区块链的云服务隐私保护信誉系统
US11880488B2 (en) * 2021-04-30 2024-01-23 Capital One Services, Llc Fast and flexible remediation of sensitive information using document object model structures

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3982848B2 (ja) * 1995-10-19 2007-09-26 富士通株式会社 セキュリティレベル制御装置及びネットワーク通信システム
US5787175A (en) * 1995-10-23 1998-07-28 Novell, Inc. Method and apparatus for collaborative document control
WO1997025798A1 (en) * 1996-01-11 1997-07-17 Mrj, Inc. System for controlling access and distribution of digital property
US5937066A (en) * 1996-10-02 1999-08-10 International Business Machines Corporation Two-phase cryptographic key recovery system
US6236727B1 (en) * 1997-06-24 2001-05-22 International Business Machines Corporation Apparatus, method and computer program product for protecting copyright data within a computer system
US6154840A (en) * 1998-05-01 2000-11-28 Northern Telecom Limited System and method for transferring encrypted sections of documents across a computer network
US6327574B1 (en) * 1998-07-07 2001-12-04 Encirq Corporation Hierarchical models of consumer attributes for targeting content in a privacy-preserving manner
US6507856B1 (en) * 1999-01-05 2003-01-14 International Business Machines Corporation Dynamic business process automation system using XML documents
US6476833B1 (en) * 1999-03-30 2002-11-05 Koninklijke Philips Electronics N.V. Method and apparatus for controlling browser functionality in the context of an application
US6463440B1 (en) * 1999-04-08 2002-10-08 International Business Machines Corporation Retrieval of style sheets from directories based upon partial characteristic matching
US6330569B1 (en) * 1999-06-30 2001-12-11 Unisys Corp. Method for versioning a UML model in a repository in accordance with an updated XML representation of the UML model
US6446256B1 (en) * 1999-06-30 2002-09-03 Microsoft Corporation Extension of parsable structures
US6585778B1 (en) * 1999-08-30 2003-07-01 International Business Machines Corporation Enforcing data policy using style sheet processing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Widergren, S.: XML for Data Exchange. In: IEEE Power Engineering Society Summer Meeting, July 1999, S. 840-842 *

Also Published As

Publication number Publication date
DE10051571A1 (de) 2001-04-26
US6931532B1 (en) 2005-08-16

Similar Documents

Publication Publication Date Title
DE10051571B4 (de) Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung
DE69921455T2 (de) System und verfahren zur zugriffssteuerung auf gespeicherte dokumente
US6941459B1 (en) Selective data encryption using style sheet processing for decryption by a key recovery agent
DE60218615T2 (de) Verfahren und Architektur zur durchdringenden Absicherung von digitalen Gütern
DE69818008T2 (de) Datenzugriffssteuerung
DE60116903T2 (de) Gesicherte sitzungverwaltung und authentifizierung für websites
DE10084964B3 (de) Verfahren zum sicheren Speichern, Übertragen und Wiedergewinnen inhaltsadresssierbarer Informationen
DE60315914T2 (de) Ad hoc Sicherheitszugriff auf Dokumente und Dienste
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE69735486T2 (de) Werkzeug zur sicherheit und zum austauch von persönlichen daten
DE60304744T2 (de) Verfahren,vorrichtung und computerprogramme zur erzeugung und/oder verwendungkonditionaler elektronischer signaturen zur meldung von statusänderungen
DE60218069T2 (de) Bereitstellung von gekoppelten diensten in einer verteilten rechnerumgebung
DE60130037T2 (de) Verfahren und system zur web-basierten cross-domain berechtigung mit einmaliger anmeldung
DE60221451T2 (de) System und Verfahren für Erstellung des transparenten Zugangs auf WebDAV Dateien inklusive verschlüsselte Dateien
EP1108308B1 (de) System und verfahren zur ablaufkontrolle bei netzwerk-anwendungen
DE60200451T2 (de) Herstellung einer gesicherten Verbindung mit einem privaten Unternehmensnetz über ein öffentliches Netz
DE60308692T2 (de) Verfahren und system für benutzerbestimmte authentifizierung und einmalige anmeldung in einer föderalisierten umgebung
DE602004012870T2 (de) Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung
DE60200093T2 (de) Sichere Benutzerauthenifizierung über ein Kommunikationsnetzwerk
CN104767834B (zh) 用于加速计算环境到远程用户的传送的系统和方法
DE19960977B4 (de) System für ein elektronisches Datenarchiv mit Erzwingung einer Zugriffskontrolle beim Datenabruf
EP1628184A1 (de) Verfahren und Computersystem zur Durchführung eines netzwerkgestützten Geschäftsprozesses
DE10212620A1 (de) Sichere Benutzer- und Datenauthentisierung über ein Kommunikationsnetzwerk
DE10224743A1 (de) Verwendung von Auftragsetiketten, um einen Ressourcenzugriff zu sichern
DE102011077218B4 (de) Zugriff auf in einer Cloud gespeicherte Daten

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)
8328 Change in the person/name/address of the agent

Representative=s name: DUSCHER, R., DIPL.-PHYS. DR.RER.NAT., PAT.-ANW., 7

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee