DE69534490T2

DE69534490T2 - Verfahren zur sicheren anwendung digitaler unterschriften in einem kommerziellen verschlüsselungssystem

Info

Publication number: DE69534490T2
Application number: DE69534490T
Authority: DE
Inventors: W. Frank SUDIA; Brian Siritzky
Original assignee: Certco LLC
Current assignee: Certco LLC
Priority date: 1994-07-19
Filing date: 1995-07-19
Publication date: 2006-06-29
Anticipated expiration: 2015-07-20
Also published as: TR199600585A2; NO970084L; ATE305682T1; EP0771499B1; NO970084D0; EP0771499A2; AU3715695A; CZ11597A3; CA2194475A1; US5659616A; WO1996002993A3; RU2144269C1; JPH10504150A; AU698454B2; WO1996002993A2; DE69534490D1

Description

Hintergrund der Erfindung
Die vorliegende Erfindung bezieht sich auf digitale Signaturen und insbesondere auf die Verwendung von digitalen Signaturen und Zertifikaten für digitale Signaturen in einem kommerziellen kryptographischen System zum Durchsetzen von grundsätzlichen Sicherheitsverfahrensweisen und Beglaubigungserfordernissen in einer die Gefahren für die Benutzer verringernden Art und Weise.
Kryptographie mit öffentlichem Schlüssel ist eine moderne Computersicherheitstechnik, die die Erzeugung von papierlosen elektronischen Dokumentensystemen unterstützen kann, vorausgesetzt dass die digitale Signatur des Benutzers auf einem elektronischen Dokument, d.h. die elektronische Authentifizierung und Nachprüfung, ausreichend praktisch ist und im Sinne des Gesetzes liegt. Solche papierlosen elektronischen Dokumentensysteme oder „Dokumentenarchitekturen„ schließen nicht nur Handelspartner ein, die nach bilateralen Standardverträgen arbeiten, sondern auch globale multilaterale Systeme, in welcher jede Betrachtungseinheit theoretisch mit jeder anderen Betrachtungseinheit in einer legal nachweisbaren Art und Weise unter der Voraussetzung korrespondieren kann, dass durchgehend korrekte Sicherheitskontrollen durchgeführt werden.
Diese Systeme weisen eine enorme kommerzielle Bedeutung auf, weil in vielen Fällen Kostenverringerungen in der Größenordnung von 10 zu 1 gegenüber den derzeitigen Papiertransaktionsprozeduren erzielt werden können. Diese Verbesserung ist hinreichend gravierend, dass viele Organisationen sich aus ökonomischen und Wettbewerbsgründen gezwungen sehen würden, sie anzuwenden, nachdem ihre praktische Durchführbarkeit aufgezeigt worden ist.
Niemand streitet ab, dass in der elektronischen Welt Papier ein lästiger Anachronismus ist oder dass die Nachprüfung von Papier- und Tinte-Unterschriften kostspielig und fehleranfällig ist. Jedoch liegen bei Papier zumindest die grundlegenden „ kontextualen Kontrollen„ der Dokumentenvorbereitung und die körperliche Auslieferung beim Benutzer. Auf einem digital signierten elektronischen Dokument kontrolliert ein Unterzeichner nur die verschlüsselte Signatur. Alle Prüfungen hinsichtlich Zeit, Ort und Art und Weise fehlen und nichts unterscheidet eine gültige Benutzersignatur von einer betrügerisch von einem anderen Benutzer, der irgendwie Zugriff auf die Original-Smartcard und die PIN des Benutzers erhalten hat, erzeugten Signatur. Das würde auch nicht zu Verlusten von vielen Millionen oder Milliarden Dollar führen, die alle die Einsparungen, die durch diese „neuartige„ Büroautomatisierungstechnik hervorgerufen werden, aufheben würden. Daher ist anzunehmen, dass digitale Signaturen in naher Zukunft nur in der „elektronischen Geldbörse„ des Verbrauchers, bei der die Offenlegung geringfügig ist, und bei Finanztransfers im Großhandel zur Anwendung kommen, bei denen äußerst strenge Sicherheitsprozeduren bereits die Norm sind. Diese Anwendungen haben jedoch allgemein wenig kommerzielle Bedeutung.
Bisher haben größere Körperschaften und Banken es abgelehnt, in diese Techniken zu investieren, weil es an gut definierten Gefahrenmodellen und Prüfungsstandards mangelt und weil es Unbestimmtheiten hinsichtlich rechtlicher und Veranwortlichkeitsfragen gibt. Ernsthafte Investitionen zur Kommerzialisierung digitaler Signaturen werden erst getätigt werden, nachdem führende nationale Prüfungs- und Rechtsexperten entschieden haben, dass diese Systeme ausreichende Sicherheitskontrollen enthalten, die Zuverlässigkeit für Geschäftstransaktionen, normalerweise in der Größenordnung von 10 000 bis 10 Millionen Dollar, innerhalb von und zwischen großen Körperschaften garantieren. Um dieses Ziel zu erreichen, müssen Sicherheitskontrollen formuliert werden, um die Gefahren von Beteiligten an Dokumentensystemen mit digitaler Signatur auf das absolut niedrigste, technisch erreichbare Niveau abzusenken.
Es gibt zwei Arten von kryptographischen Systemen, in denen digitale Signaturen Verwendung gefunden haben. Die 1(a) und 1(b) stellen die Anwendung symmetrischer und asymmetrischer Verschlüsselungsalgorithmen dar. In der symmetrischen (herkömmlichen) Kryptographie, wie sie in 1(a) dargestellt ist, teilen sich Absender und Empfänger einer Kommunikation einen geheimen Schlüssel 11. Dieser Schlüssel wird von dem Absender, welcher der Urheber einer Kommunikation ist, verwendet, um die Nachricht 12 zu verschlüsseln, und er wird von dem Empfänger der Kommunikation verwendet, um die Nachricht 13 zu entschlüsseln. Er kann auch von dem Empfänger verwendet werden, um eine Nachricht zu beglaubigen, für die der Absender den geheimen Schlüssel verwendet hat, um eine bestimmte Funktion, beispielsweise einen Nachrichten-Beglaubi-gungs-Code (MAC) basierend auf der Nachricht zu berechnen. Der Empfänger kann sich somit von der Identität des Urhebers überzeugen, weil nur der Absender und der Empfänger den geheimen Schlüssel kennen, der verwendet wird, um den MAC zu berechnen. DES ist ein Beispiel eines symmetrischen kryptographischen Systems.
In der asymmetrischen Kryptographie (mit öffentlichem Schlüssel), dargestellt in 1(b), werden unterschiedliche Schlüssel verwendet, um eine Nachricht zu verschlüsseln und zu entschlüsseln. Jedem Benutzer ist ein Paar von Schlüsseln zugeordnet. Ein Schlüssel 15 (der öffentliche Schlüssel) ist öffentlich bekannt und wird verwendet, um Nachrichten 17 zu verschlüsseln, die für einen Benutzer bestimmt sind und der andere Schlüssel 16 (der private Schlüssel) ist nur dem einen Benutzer bekannt und wird verwendet, um eingehende Nachrichten 18 zu entschlüsseln. Da der öffentliche Schlüssel nicht mehr geheim gehalten werden muss, ist es nicht mehr erforderlich, einen zwischen den Kommunikationspartnern geteilten Schlüssel für das Entschlüsseln vor dem Austauschen vertraulicher Geschäftsverkehrs- oder Beglaubigungsnachrichten zu übertragen. RSA ist der bekannteste asymmetrische Algorithmus.
Eine digitale Signatur ist jedoch ein an eine Nachrichtendateneinheit angehängter Block von Daten und erlaubt es dem Empfänger, den Ursprung der Nachrichtendateneinheit zu prüfen und sie gegen Fälschung zu schützen. Einige asymmetrische Algorithmen (zum Beispiel RSA) können auch eine Beglaubigung und Nicht-Zurückweisung durch Verwendung von digitalen Signaturen gewährleisten. Um Daten zu signieren, verschlüsselt der Absender die Daten unter seinem privaten Schlüssel. Um die Daten zu validieren, entschlüsselt der Empfänger sie mit dem öffentlichen Schlüssel des Absenders. Wenn die Nachricht unter Verwendung des öffentlichen Schlüssels des Absenders erfolgreich entschlüsselt worden ist, muss sie ursprünglich durch den Absender verschlüsselt worden sein, weil der Absender die einzige Betrachtungseinheit ist, die den entsprechenden privaten Schlüssel kennt. Unter Verwendung dieser Methode des Signierens von Dokumenten wird die verschlüsselte Nachricht mit der Signatur verknüpft, weil der Empfänger die Nachricht nicht lesen kann, ohne den Signaturdatenblock zu entschlüsseln. Die mit der Signatur verschlüsselte Nachricht kann dann verschlüsselt unter Verwendung des öffentlichen Schlüssels des Empfängers wie üblich an den Empfänger übertragen werden.
Digitale Signaturen können auch unter Verwendung von asymmetrischen Verschlüsselungsalgorithmen gebildet werden, wie es nachfolgend beschrieben wird und in 2 dargestellt ist. Um eine Nachricht zu signieren, muss die Nachricht 20 zuerst unter Verwendung einer Ein-Weg-Hash-Funktion zu einem einzigen Block 22 verarbeitet werden (Hash-Code-Anwendung). Eine Ein-Weg-Hash-Funktion hat die Eigenschaft, dass sie bei vorgegebener Verarbeitung rechnerisch nicht in der Lage ist, irgendeine Nachricht aufzubauen, die mit Hilfe der Hash-Codierung auf diesen Wert gebracht ist oder zwei Nachrichten zu finden, die durch Hash-Codierung auf den gleichen Verarbeitungswert gebracht sind. Der Verarbeitungswert 22 wird dann mit dem privaten Schlüssel des Benutzers 23 verschlüsselt und das Ergebnis 24 wird als ihre Signatur an die verschlüsselte oder unverschlüsselte Nachricht 25 angehängt. Der Empfänger verwendet den öffentlichen Schlüssel des Absenders 26, um die Signatur 25 in dem Hash-Verarbeitungswert 22 zu entschlüsseln. Der Empfänger verarbeitet ebenfalls die Nachricht 20 (führt eine Hash-Coderung durch), die entweder unverschlüsselt oder verschlüsselt empfangen wurde und darauf vom Empfänger entschlüsselt wurde, zu einem Block 27 unter Verwendung der gleichen Ein-Weg-Hash-Funktion 21, die auch vom Absender verwendet wurde. Der Empfänger prüft dann unter 28 die Signatur des Absenders durch Überprüfen, ob der entschlüsselte Hash-Verarbei-tungswert 22 der gleiche ist, wie der Hash-codierte Nachrichtenverarbeitungswert.
Das Trennen der Signatur von der Nachricht auf diese Weise, d.h., dass es nicht erforderlich ist, dass Absender und Empfänger die gesamte Nachricht verschlüsseln und entschlüsseln müssen, um die Signatur nachzuprüfen, verringert die Menge der zu verschlüsselnden Daten in hohem Maße. Das ist wichtig, weil die Algorithmen des öffentlichen Schlüssels allgemein wesentlich langsamer sind, als die herkömmlichen Algorithmen und das Verarbeiten der gesamten Nachricht zum Nachprüfen einer Signatur einen bedeutenden Zeitaufwand erfordern würde. Der Signaturprozess führt weiterhin Redundanz in die Nachricht ein, die es, weil die Nachricht durch Hash-Codierung auf den spezifizierten Verarbeitungswert gebracht werden muss, dem Empfänger erlaubt, unbefugte Veränderungen der Nachricht zu erkennen.
Eine digitale Signatur bietet den Sicherheitsdiensten a) Integrität, weil jede Modifizierung der signierten Daten zu einem anderen Verarbeitungswert und somit zu einer anderen Signatur führt, (b) Ursprungsauthentifikation, weil nur der Inhaber des privaten Schlüssels, der dem öffentlichen Schlüssel entspricht, der für die Validierung der Signatur verwendet wurde, die Nachricht signiert haben konnte und c) Nicht-Zurückweisung, als unwiderruflicher Beweis für eine dritte Partei, dass nur der Unterzeichner und nicht der Empfänger oder seine Angestellten, die Signatur erstellt haben konnte. Ein symmetrischer Geheimschlüsselauthentifikator, zum Beispiel X9.9 MAC, bietet diese Dienste nicht, da jede der beiden Parteien den Authentifikator unter Verwendung ihres aufgeteilten Schlüssels erzeugen kann.
Mehrere der hierin behandelten Mechanismen weisen die Fähigkeit auf, Mehrfachsignaturen oder Kosignaturen an ein Dokument anzuhängen. Ein nützliches Format für diesen Zweck ist, wie im Fachgebiet gut bekannt ist, in „PKCS Nr. 7: Cryptographic Message Syntax (Syntax einer kryptographischen Nachricht)„ RSA Data Security, Inc. 1993 definiert und wird hierdurch durch Verweis einbezogen. Jede Signaturstruktur auf einem Dokument enthält eine Anzeige des Zertifikats, das benötigt wird, um die Signatur zusammen mit einer Bitfolge, welche die aktuelle Signatur enthält, zu validieren. Zusätzlich können andere, für den speziellen Unterzeichner relevante Informationen in eine individuelle Signaturberechnung eingeschlossen werden. Diese Informationen durch den Unterzeichner können als „Signaturattribute„ in die Signaturberechnung einbezogen werden.
Damit ein Benutzer einen anderen Benutzer um Übertragen einer Nachricht in einer Weise identifizieren kann, die sichert, dass der zweite Benutzer im Besitz eines privaten Schlüssels ist, muss der erste Benutzer in der Lage sein, den öffentlichen Schlüssel des anderen Benutzers von einer vertrauenswürdigen Quelle zu erhalten. Wie im Fachgebiet gut bekannt ist, wurde ein Rahmenwerk für die Verwendung von Zertifikaten für öffentliche Schlüssel in „X.509: The Directory: Authentication Framework,„ CCITT, April 1993 („X.509") definiert, das hierin durch Verweis einbezogen wird. Diese Basiszertifikate für öffentliche Schlüssel verknüpfen den Namen eines Benutzers mit einem öffentlichen Schlüssel und werden von einem vertrauenswürdigen Herausgeber unterzeichnet, der als Zertifizierungsautorität (CA) bezeichnet wird. Neben dem Namen des Benutzers und dem öffentlichen Schlüssel enthält das Zertifikat weiterhin den Namen der CA, die das Zertifikat ausgibt, eine Seriennummer und einen Gültigkeitszeitraum.
Obwohl X.509 keine spezielle Struktur für die CAs vorschreibt, finden es viele Realisierungen zweckmäßig, eine hierarchische Struktur vorzugeben, in welcher jede CA (im Allgemeinen) nur die Betrachtungseinheiten zertifiziert, die ihr unterstellt sind. Somit können wir eine CA-Hierarchie aufbauen, wie sie in 3 dargestellt ist, wobei die höhere Ebene CAs 31 (möglicherweise Banken) die Zertifikate 34 der CAs 32 darunter (zum Beispiel Gesellschaften) unterzeichnet und die niedrigste Ebene der CAs 32 die die Zertifikate 35 der Benutzer 33 unterzeichnet. An der Spitze dieser Hierarchie (nicht dargestellt) befinden sich relativ wenige andere Kopf-CAs, möglicherweise eine pro Land, die jeden der anderen öffentlichen Schlüssel (Kopfschlüssel) „quer zertifizieren„ darf.
Verschiedene Sicherheitsarchitekturen definieren Mechanismen zum Aufbau eines Zertifikationsweges durch die Hierarchie, um ein vorgegebenes Benutzerzertifikat und alle CA-Zertifikate zu erhalten, die erforderlich sind, um es zu validieren. Diese Architek turen haben die gemeinsame Charakteristik, dass ein Benutzer nur einem anderen öffentlichen Schlüssel vertrauen muss, um alle andere Zertifikate zu erhalten und zu validieren. Der vertrauenswürdige Schlüssel kann der Schlüssel einer CA in der obersten Ebene sein (in einem zentralisierten Verantwortungsmodell oder der Schlüssel einer lokalen CA, welche das Benutzerzertifikat herausgibt (in einem dezentralisierten Modell).
Die Zertifikate enthalten ferner ein Ablaufdatum. Wenn es erforderlich ist, ein Zertifikat vor seinem Ablaufdatum zu löschen, beispielsweise wenn der Name der Vereinigung ungültig wird oder der entsprechende private Schlüssel verloren geht oder kompromittiert ist, kann das Zertifikat der Zertifikatswiderrufliste der CAs (CRL) oder der „heißen Liste„ hinzugefügt werden. Diese Liste wird von der CA unterzeichnet und umfassend verteilt, möglichweise als Bestandteil des Adressenverzeichnis-Eintrags der CAs. Das Zertifikat verbleibt bis zu seinem Ablaufdatum auf der CRL.
Oft ist es erforderlich, dass bestimmte Informationen über eine Betrachtungseinheit oder eine CA in vertraulicher Art und Weise zur Verfügung zu stellen sind. In einem sicheren X.500 Adressenverzeichnis würden diese Informationen über Standard-Adressenverzeichnisoperationen aufgefunden werden und das Ergebnis würde durch das Adressenverzeichnis signiert werden. Bei Fehlen einer solchen sicheren X.500-Implementation werden diese Informationen in einem Attributzertifikat platziert, das durch eine CA in derselben Art und Weise signiert ist, wie das Zertifikat für den öffentlichen Schlüssel. Die Attributzertifikate würden bei Vorlegen der korrekten Beglaubigungsunterlagen durch den Benutzer erzeugt werden. So würde als eine Form der Identifizierung zum Beispiel der Benutzer sein Zertifikat für den öffentlichen Schlüssel vorlegen und nachweisen, dass er den entsprechenden privaten Schlüssel besitzt. Attributzertifikate sind mit dem Basiszertifikat des Benutzers für den öffentlichen Schlüssel durch Bezugnahme auf die Seriennummer der Basiszertifikate ver knüpft und sie werden durch einen identischen, parallelen CRL-Mechanismus widerrufen. Attributzertifikate werden weiterhin in „X9.30 Teil 3: Certificate Management for DSA (Zertifikatmanagement für DSA,„), ANSI X9F1, Juni 1994 und in den US-Patenten Nr. 4,868,877, 5,005,200 und 5,214,702 behandelt, die im Fachgebiet alle gut bekannt sind.
Ein Attributzertifikat ist eine Struktur, die von einem Zertifikat für einen öffentlichen Schlüssel getrennt ist, weil eine korrekte Trennung von Pflichten oft erfordert, dass die CA, die das Attributzertifikat ausgibt, eine andere ist, als die CA, die das Zertifikat für den öffentlichen Schlüssel ausgibt. Eine zentrale CA würde selten die erforderliche Sicherheit oder Autorität besitzen, alle Autorisierungen eines Benutzers zu signieren. Wenn man separate CAs hat, die verschiedene Arten von Attributzertifikaten erzeugen, verteilt das die Risiken entsprechend. Weiterhin könnten die definierten Attribute nicht für alle Domänen, Netzwerke oder Anwendungen erforderlich sein. Der Bedarf für diese Attribute und für zusätzliche Attribute, die für die Domäne spezifisch sind, wird durch jede Domäne festgelegt.
Das Basiszertifikat des Benutzers für den öffentlichen Schlüssel bleibt für X.509 kompatibel und erlaubt seine Verwendung mit anderen Anwendungen und die Verwendung von kommerziellen Produkten für die Zertifikaterzeugung.
Das US-Patent Nr. 5.164.988 offenbart eine Vorrichtung A in einem kryptographischen Netzwerk mit öffentlichem Schlüssel, die lange nachdem der öffentliche Schlüssel der Vorrichtung A PUMa zertifiziert ist, zwangsläufig und zuverlässig eine Sicherheitsverfahrensweise durchsetzt, die von einem Netzwerkzertifizierungszentrum diktiert wird. Wenn die Vorrichtung A ihren Betrieb aus den Einschränkungen heraus, die in ihrem Konfigurationsvektor verschlüsselt sind, verändert, zum Beispiel durch Laden eines neuen Konfigurationsvektors, verweigert die Vorrichtung A die Partizi pation in dem Netzwerk. Um diese Zwangs-Netzwerksicherheitsverfahrensweise, die durch das Zertifizierungszentrum diktiert wird, durchzusetzen, ist es für das Zertifizierungszentrum erforderlich, zu der Zeit, zu welcher die Vorrichtung A die Zertifizierung ihres öffentlichen Schlüssels PUMa anfordert, nachzuprüfen, dass die Vorrichtung A mit dem derzeitig autorisierten Konfigurationsvektor konfiguriert ist. Die Vorrichtung A ist aufgefordert, eine Kopie des derzeitigen Konfigurationsvektors in einer Revisionsaufzeichnung an das Zertifizierungszentrum zu übertragen. Das Zertifizierungszentrum vergleicht dann die Kopie des Konfigurationsvektors der Vorrichtung A mit dem autorisierten Konfigurationsvektor für die Vorrichtung A, der beim Zertifizierungszentrum gespeichert ist. Wenn der Vergleich zufriedenstellend ist, gibt das Zertifizierungszentrum das angeforderte Zertifikat aus und erzeugt eine digitale Signatur dSigPRC auf einer Darstellung des öffentlichen Schlüssels PUMa der Vorrichtung A unter Verwendung des privaten Zertifizierungsschlüssels PRC des Zertifizierungszentrums. Danach wird, wenn die Vorrichtung A versucht, ihren Konfigurationsvektor zu verändern, der private Schlüssel PRMa der Vorrichtung A, der dem zertifizierten öffentlichen Schlüssel PUMa entspricht, automatisch für die Verwendung bei der Kommunikation im Netzwerk unverfügbar.
Es ist vorteilhaft, dass man in der Lage ist, eine vertrauenswürdige Organisation aufzubauen, die die Mechanismen der digitalen Signatur und der Zertifizierung verwendet, um eine Sicherheitsverfahrensweise durchzusetzen, die durch Regeln in dieser Organisationsstruktur definiert sind.
Es ist weiterhin vorteilhaft, Mechanismen der digitalen Signatur und der Zertifizierung zu verwenden, um eine industrieweite Sicherheitsverfahrensweise und Autorisierungsinformationen in die Signaturen und Zertifikate zu verschlüsseln, um dem Prüfer einer Signatur die Entscheidung zu gestatten, ob er die Signatur oder das Zertifikat als gültig annehmen kann und somit kommerzielle Geschäftstransaktionen realisieren und erleichtern kann.
Es ist weiterhin vorteilhaft, die Gefahren, die mit Systemen der digitalen Signatur im Zusammenhang stehen, zu verringern, insbesondere durch Endbenutzer-Smartcards, indem auf dieser Basis die Verwendung von Zertifikaten für den öffentlichen Schlüssel und von Attributzertifikaten aufgebaut wird.
Es ist ferner vorteilhaft, die Verwendung eines solchen Systems der digitalen Signatur durch jede Partei zu verhindern, die vorgeben könnte, eine Transaktion entgegen den zutreffenden Autorisierungszertifikaten zu „akzeptieren„, wenn diese Partei nicht die zutreffende „Systemregel„-Vereinbarung unterzeichnet hat, die zu diesem Kommunikationssystem der Unterzeichnerautorisierung gehört.
Zusammenfassung der Erfindung
Die Aufgabe der vorliegenden Erfindung ist, ein Verfahren zur Verfügung zu stellen, das Mechanismen der digitalen Signatur und der Zertifizierung verwenden kann, um Sicherheitsverfahrensweisen und/oder Autorisierungsinformationen in die Signaturen und/oder Zertifikate zu verschlüsseln, um dem Nachprüfer einer Signatur die Entscheidung zu gestatten, ob er eine Transaktion, die mit der Signatur und/oder mit dem Zertifikat eines Absenders im Zusammenhang steht, akzeptieren und somit kommerzielle Geschäftstransaktionen realisieren und erleichtern kann.
Diese Aufgabe wird einerseits durch das Verfahren, wie es in Anspruch 1 beansprucht ist und andererseits durch das Verfahren, wie es in Anspruch 19 beansprucht ist, gelöst.
Diese und andere Aufgaben der Erfindung werden gemäß den Prinzipien der Erfindung gelöst, indem ein System für das sichere Verwenden von digitalen Signaturen in einem kommerziellen kryptographischen System zur Verfügung gestellt wird, das es erlaubt, eine industrieweite Sicherheitsverfahrensweise und Autorisierungsinformationen in die Signaturen und Zertifikate zu verschlüsseln, indem Attributzertifikate verwendet werden, um die Erfordernisse der Verfahrensweise und der Autorisierung durchzusetzen. Zusätzlich zu Wertbegrenzungen, Kosignaturanforderungen und Beschränkungen des Dokumententyps, die den Transaktionen auferlegt werden können, kann eine Organisation für jede Transaktion geografische und zeitliche Kontrollen, Begrenzungen hinsichtlich des Alters der Signatur, Beschränkungen auf langbewährte Partner und Beglaubigung der Forderungen durch Verwendung von Attributzertifikaten für den die Transaktion ausführenden Benutzer erzwingen. Es können Begrenzungen hinsichtlich der Verteilung der Zertifikate unter Verwendung von Attributzertifikaten festgelegt werden. Zertifikate können auch verwendet werden, um die Schlüsselbeschränkung und die Forderungen an das Nicht-Entschlüsseln von Smartcards in diesem System zu sichern.
Kurzbeschreibung der Zeichnungen
Die vorher angeführten und andere Aufgaben und Vorteile der Erfindung sind aus der nachfolgenden ausführlichen Beschreibung im Zusammenhang mit den beigefügten Zeichnungen zu erkennen, in denen gleiche Bezugszeichen gleiche Teile bezeichnen und die zeigen in
1(a) und 1(b) die dem Stand der Technik entsprechende Verwendung von symmetrischen und asymmetrischen Algorithmen für die Verschlüsselung;
2 ein Flussdiagramm, das den dem Stand der Technik entsprechenden Prozess einer digitalen Signatur unter Verwendung eines asymmetrischen Verschlüsselungsalgorithmus darstellt;
3 eine Hierarchie von Signaturzertifizierungsautoritäten;
4 den Informationsbaum eines Adressenverzeichnisses (DIT);
5 ein Beispiel eines Autorisierungszertifikates;
6 ein Flussdiagramm, das den dem Stand der Technik entsprechenden Prozess des Durchsetzens einer Transaktion hinsichtlich der Geldwertbeschränkung durch den Nachprüfer darstellt;
7 ein Flussdiagramm, das den dem Stand der Technik entsprechenden Prozess des Durchsetzens einer Transaktion hinsichtlich der Kosignaturerfordernisse durch den Nachprüfer darstellt;
8 ein Flussdiagramm, das den Prozess des Durchsetzens einer Transaktion hinsichtlich der Dokumententypbeschränkung durch den Nachprüfer darstellt;
9 ein Flussdiagramm, das den Prozess des Durchsetzens einer Transaktion hinsichtlich der geografischen und zeitlichen Kontrollen durch den Nachprüfer darstellt;
10 ein Flussdiagramm, das den Prozess des Durchsetzens einer Transaktion hinsichtlich der Begrenzung des maximalen Alters der Signatur des Absenders durch den Nachprüfer darstellt;
11 ein Flussdiagramm, das den Prozess des Durchsetzens einer Transaktion hinsichtlich der Beschränkungen langbewährter Partner durch den Nachprüfer darstellt;
12 ein Flussdiagramm, das den Prozess des Durchsetzens einer Transaktion hinsichtlich der Bestätigungserfordernisse durch den Nachprüfer darstellt;
13 ein Flussdiagramm, das den Prozess einer Vorrichtungszertifizierung hinsichtlich der Schlüsselbeschränkung und der Nicht-Entschlüsselung darstellt;
14 ein Flussdiagramm, das den Prozess des Geheimhaltens von öffentlichen Schlüsseln und das Durchsetzen der Signierung von Systemregeln darstellt; und
15 ein Flussdiagramm, das den Prozess des Verifizierens von Benutzerregeln einer Transaktion darstellt.
Ausführliche Beschreibung der Erfindung
Die nachfolgenden allgemeinen Prinzipien und Philosophien werden in dem in der vorliegenden Erfindung definierten Signaturverifizierungsmodell wiedergegeben. Erstens können CA- und Benutzerzertifikate Attribute enthalten, welche die Bedingungen und Annahmen enthalten, unter denen sie erzeugt wurden. Nachprüfer können einfach alle Zertifikate und Transaktionen zurückweisen, die nicht ihren Mindeststandards entsprechen.
Weiterhin können Attributzertifikate durch einen „Sponsor„ des Benutzers signiert werden, um anzukündigen, dass die Signatur des Sponsors für das offizielle Geschäft berechtigt ist, wenn die Transaktion, die Anforderungen erfüllt, die durch die Attribute auferlegt werden. Obwohl normalerweise der Sponsor des Benutzers der Arbeitsgeber des Benutzers ist, kann das Modell erweitert werden, um die Bank des Benutzers, den Kreditkartenherausgeber des Benutzers, das Wahlbüro des Benutzers, das Video-Ausleihgeschäft des Benutzers, die öffentliche Bibliothek des Benutzers oder jede andere Betrachtungseinheit einzuschließen, die die Signatur des Benutzers akzeptieren möchte. Dieses Sponsorzertifikat (Autorisierungszertifikat) ist somit das elektronische Äquivalent „der eidesstattlichen Versicherung der Legalität„, wie sie im Zusammenhang mit einem herkömmlichen Signaturstempel verwendet wird. Siehe Robert Jueneman „Einschränkung der Haftung von CAs und Personen in Bezug auf die Verwendung von digitalen Signaturen„, vorgestellt der ABA Section of Science and Technology Certification Authority Work Group (ABA-Sektion der Arbeitsgruppe der Zertifizierungsautorität für Wissenschaft und Technik) am 2. Juli, 1993.
Ferner können die Industrien Übersichten über die „Industriepolitik„ entwickeln, die die Mindesterfordernisse an die Signaturverifizierung festlegen. Alle Teilnehmer würden diese multilateralen Vereinbarungen signieren, um zu sichern, dass alle Partner durch die verschlüsselten Einschränkungen gebunden sind. Normalerweise sollten Sponsorzertifikate in allen Fällen erforderlich sein und digitale Signaturen sollten bei ihrem Fehlen Null und nichtig sein. Industrieweite Verfahrensweisen würden auch (1) die relevanten Dokumententypen und Dokumentenklassen, (2) die Funktionsbezeichnungen und die Titel des Unterzeichners und (3) die codierten Symbole zum Einbeziehen von Vertragsbedingungen und Vertragskonditionen durch Verweis einbeziehen.
Darüber hinaus muss streng an dem Prinzip festgehalten werden, dass alle Einschränkungen in einer vollkommen automatisierten Art und Weise durchzusetzen sind (d.h. Verifikation „auf Sicht„) ohne Bezugnahme auf schriftliche Vereinbarungen oder Interpretationen durch den Menschen, manchmal auch als „durchgehende, vollständig maschinenfähige Verarbeitung„ bezeichnet. In komplexen und/oder Umgebungen mit umfangreichen Inhalten ist das erforderlich, damit diese Sicherheitskontrollen in den Augen von Prüf- und Rechtsexperten glaubwürdig sind. Bezugnahmen auf vertrauenswürdige dritte Parteien sollten ebenfalls minimiert werden, um die Verifikationslatenzzeiten zu verringern.
Wenn auch diese Einschränkungen kompliziert zu sein scheinen, spiegeln sie nur explizit die gewöhnlichen Geschäftsprozeduren für Zwecke der maschinellen Verifikation wider. Früher wurden solche Kontrollen innerhalb der Computersysteme des Sponsors vor dem Absenden der Transaktion durchgeführt. Mit dem Erscheinen von multilateral verteilten Transaktionen befindet sich jedoch der verifizierende Benutzer normalerweise offline vom Absendersystem des Sponsors und daher muss der Nachprüfer das Autorisierungsmodell des Sponsors ausführen, wie es sich in den Attributzertifikaten widerspiegelt. Nach dem Spezifizieren dieser Methodik werden Bürosoftwareverkäufer Menü-gesteuerte Systeme entwickeln, um Benutzerattribute zu erzeugen und zu verwalten und die Kosten für die Benutzerorganisationen werden relativ gering sein.
Organisationsstruktur in Zertifikaten
Die Zertifikate selbst können die Struktur einer Sponsororganisation widerspiegeln. Weil viele Autorisierungsentscheidungen auf der Stellung des Benutzers in einer Organisation basieren, können die Organisationsstruktur und die Stellung des Benutzers darin als Teil eines Benutzernamens spezifiziert werden. Namen in Zertifikaten werden in Ausdrücken des X.500-Directory-Modells wie folgt angegeben.
Die Struktur des X.500 Directory ist hierarchisch. Die sich ergebende verteilte Datenbank umfasst den Directory Information Tree (DIT) (Informationsbaum des Directory), wie er in 4 dargestellt ist. Jeder Eintrag 41 ist ein Eintrag einer spezifischen Objektklasse und besteht aus einem Satz von Eigenschaften, die als Attribute 42 bezeichnet werden. Ein Attribut 42 besteht aus einem Typ 43 und aus einem Wert oder mehreren Werten 44. Somit ist in einem Eintrag der Klassenorganisation ein Attribut der Organisationsname. In einem Eintrag der Klassenorganisation Person können die Attribute den Titel und die Telephonnummer sein.
Jeder Eintrag weist auch einen speziellen Attributwert oder mehrere spezielle Attributwerte auf, die verwendet werden, um den Objektnamen aufzubauen. Dieser Attributwert ist der relative Unterscheidungsname (RDN) des Eintrags. Ein Unterscheidungsname (DN) 45 eines Objekts, der durch Verketten der relativen Unterscheidungsnamen 46 aller Einträge von dem DIT-Ursprung bis zum Eintrag erzeugt wird, identifiziert das Objekt in dem globalen DIT eindeutig.
Mehrere der in X.500 definierten Attribute können nutzbringend in das Benutzerzertifikat einbezogen werden. So kann zum Beispiel die Objektklasse verwendet werden, um zwischen Betrachtungseinheiten (zum Beispiel Benutzer und Funktionen), deren Unterscheidungsnamen die gleiche Form aufweisen, zu unterscheiden. Auch der Titel kann beim Treffen von Autorisierungsentscheidungen verwendet werden.
Zusätzlich zur Verwendung des DIT zum Gruppieren von Betrachtungseinheiten entlang den Organisationslinien, definiert X.500 mehrere Objektklassen, die verwendet werden können, um beliebige Gruppen von Betrachtungseinheiten aufzubauen. Diese Objektklassen schließen die Organisationsfunktion, deren „Funktionsbesetzer„-Attribut die Namen der Benutzer auflistet, welche die Funktion ausüben, und die Gruppen von Namen ein, deren „Mitglieds„-Attribut die Namen der Gruppenmitglieder auflistet. Um diese Informationen in vertraulicher Weise zu übertragen, könnte man Funktions- und Gruppenzertifikate definieren, welche die Namen der Funktionsbesetzer bzw. der Gruppenmitglieder übertragen und die durch eine CA signiert sind, um so die Verwendung dieses Merkmals außerhalb des Kontextes eine X.500 Directory-Systems zu ermöglichen.
Gruppen und Funktionszertifikate können in Verbindung mit einem Kosignaturmechanismus verwendet werden, um die Konstruktion von Kosignaturerfordernissen zu vereinfachen. So könnte zum Beispiel eine Transaktion die Signaturen von drei Besetzern der „Einkaufsbeauftragten„-Funktion erfordern. Ein Benutzer kann auch die von ihm ausgeübte Funktion angeben, indem die Funktion in die Signaturberechnung als (per-Unterzeichner)-Signaturattribut eingeschlossen wird. Die geltend gemachte Funktion kann dann während der Verifizierung mit einem Funktionszertifikat (oder dem Attributzertifikat des Benutzers) abgeglichen werden.
Informationen über die Verfahrensweise in den Zertifikaten
Eine andere Ausführung der vorliegenden Erfindung ist das Verschlüsseln von Informationen über die Sicherheitsverfahrensweise einer CA in den Attributzertifikaten der CA und ihrer Abonnenten, so dass der Prüfer einer Signatur die Informationen bei der Bestimmung, ob eine Signatur als gültig anzunehmen ist, verwenden kann. Im Allgemeinen übermittelt das CA-Zertifikat die Regeln, die eine CA verwendet, wenn sie Zertifizierungsentscheidungen trifft, während das Benutzerzertifikat die Informationen übermittelt, die von der CA verwendet werden, wenn sie diese Regeln anwendet.
Attribute in CA-Zertifikaten können die Sicherheitsverfahrensweise und Versicherungsinformationen für eine spezielle CA angeben. Diese Informationen über die Verfahrensweise können auch von untergeordneten CAs verwendet werden, wodurch ein einfacher Aufbau von Sicherheitsdomänen mit gemeinsamer Verfahrensweise erlaubt wird. Die Verfahrensweise-Attribute in einem CA-Attribut könnten unter anderen einschließen:

(1) Begrenzungen der Verantwortlichkeit: Der Umfang, in dem eine CA im Fall verschiedener Probleme (z.B. Gefährdung eines CA-Schlüssels durch Bekanntwerden, fehlerhafte Verknüpfung) verantwortlich ist. Das könnte keine Verantwortlichkeit, vollständige Verantwortlichkeit oder ein spezifischer Geldbetrag sein.
(2) Spezifizierung der Verantwortlichkeit: Eine Beschreibung, für welche Benutzer und CAs eine gegebene CA zertifizieren darf, ausgedrückt relativ zu der CA selbst (zum Beispiel „alle untergeordneten„) oder relativ zu dem DIT allgemein (zum Beispiel „ der Baumteil unter der Organisation ABC„) oder relativ zu anderen Aspekten.
(3) Erforderliche Attribute: Eine Liste der Attribute in den Attributszertifikaten der Benutzer, die in Bezug auf eine Transaktion und/oder ihren Kontext zu verifizieren sind, um die zu behandelnde Transaktion zu autorisieren. Diese Attribute würden in dem (den) Sponsorzertifikat(en) zu finden sein und es erlauben, dass ein einziges Autorisierungszertifikat die Autorisierungsattribute für eine Mehrfachanwendung enthält. Einige empfohlene Benutzer-Autorisierungsattribute werden später definiert.
(4) Zulässige Formen von Namen: Eine Spezifikation der zulässigen Namensformen, welche die CA zertifizieren kann. Diese Information liegt vor als (a) ein Satz von Namensverknüpfungen, welcher die Attribute definiert, die für Namenseinträge einer vorgegebenen Objektklasse (d.h. die zulässigen RDN-Formate für die Einträge dieser Klasse) verwendet werden können, und (b) ein Satz von Strukturregeln, der definiert, welche Objektklassen in dem DIT einander benachbart (d.h. über- oder untergeordnet) angeordnet sein dürfen, d.h. die Ordnung in welcher die Objektklassen miteinander verketten werden können, um einen kompletten DN zu bilden. Dieses Verfahrensweise-Attribut kann verwendet werden, um den Typ der Betrachtungseinheiten zu begrenzen, welche Trans aktionen signieren dürfen. So wäre es zum Beispiel für Anwendungen mit Drahtübertragung vorteilhaft, die Signaturfähigkeit auf die Organisation zu beschränken und nicht auf die Benutzer innerhalb der Organisation, da das den gegenwärtigen Betriebsmodus unter Verwendung von DES MACs gleicht.
(5) Querzertifikate: Vom Standpunkt der Effektivität kann es vorteilhaft sein, es Zertifizierungseinheiten und den Organisationen zu erlauben, gegenseitig Zertifizierungen auszuführen, um die Länge der Zertifizierungswege einzuschränken. Andererseits ist es nicht vorteilhaft, Zertifizierungswege zu erlauben, um eine willkürliche Anzahl von Quer-Zertifikaten zu erhalten, da es schwierig ist, den Verantwortungsgrad in der Betrachtungseinheit am anderen Ende zu bestimmen. Viele Zertifizierungsarchitekturen beschränken die Zertifizierungswege, um nur ein Querzertifikat zu erhalten. Um einen weiteren Bereich von Verfahrensweisen einzuschließen, kann ein Attribut dem Attributzertifikat hinzugefügt werden, das mit dem Quer-Zertifikat im Zusammenhang steht und anzeigt, dass der Quer-Zertifizierende ausdrücklich die Verwendung der Quer-Zertifikate erlaubt, die von der CA ausgegeben werden, die quer-zertifiziert.

Attribute in einem Benutzerattribut- oder Betrachtungseinheit-Attribut-Zertifikat können die Informationen darstellen, die durch die CA bei der Erzeugung des Zertifikats für die Betrachtungseinheit verifiziert werden. Verfahrensweise-Attribute in einem Benutzerzertifikat können unter anderem sein:

(1) Verknüpfungsinformationen: Die Kriterien, die verwendet werden, um den öffentlichen Schlüssel mit der Identität der Betrachtungseinheit, die zertifiziert wird, zu verknüpfen. Das schließt ein: (a) das Verfahren der Lieferung, beispielsweise in Person, durch einen autorisierten Vertreter, durch die Post oder durch ein anderes Verfahren, (b) das Verfahren der Identifizierung, beispielsweise durch angemessene kommerzielle Praktiken, verifiziert durch eine vertrauenswürdige dritte Partei, Doppelkontrolle, Überprüfung durch Fingerabdruck, vollständige Hintergrunduntersuchung oder durch eine andere Methode, (c) das Identifizieren von Dokumenten, die der CA vorgelegt werden und (d) der Typ der Subjekt-Betrachtungseinheit, d.h. Einzelperson, Gesellschaft, Vorrichtung o.a.
(2) Vertrauenswürdige dritte Parteien: Die Namen jeder vertrauenswürdigen dritten Parteien oder Vertreter, die in den Verknüpfungsprozess einbezogen sind.
(3) Funktionen: Für Autorisierungszwecke kann es nützlich sein, anzugeben, welche Funktionen (sowohl innerhalb als auch außerhalb der Organisation) ein Benutzer ausüben kann. Das steht im Gegensatz zu einem Funktionszertifikat, das für die Funktion ausgegeben wird und das die Namen aller Besetzer enthält.
(4) Relative Identität: Eine CA kann den Wunsch haben, nur einen Teil des DN einer Einzelperson zu zertifizieren. Insbesondere könnte die CA die Verantwortlichkeit für die Korrektheit des Personennamens ablehnen, da nach den rechtlichen Vertretungsprinzipien die Signatur der Einzelperson in jedem Fall mit ihrem Organisationssponsor verknüpft ist. Betrachtet wird der Name: C = US; O = Bankers Trust; OU = Global Electronic Commerce; C = Frank Sudia, TI = VP Die CA könnte nur die Gültigkeit der Organisation, die Organisationseinheit, und die Titelteile des Unterscheidungsnamens der Person zertifizieren, von denen alle leicht zu verifizieren sind, während der Personenname nur „angemessen glaubhaft genau„ sein würde. Wegen der relativen Einfachheit, Papiere mit falscher Identität zu erhalten, vermeidet das die Notwendigkeit verbietend teure Hintergrunduntersuchungen durchzuführen. Eine solche Identifizierung kann auf einem gewöhnlichen, kommerziellen Hinter grund basieren, jedoch nicht auf einem Prozess, der zum Beispiel ein Testament oder eine Erbschaft betrifft.
(5) Absolute Identität: Wir definieren relative Identität als die Identität des Benutzers „relativ„ zu seinem Organisationssponsor. Einen anderen Weg betrachtend, zertifizieren wir alle Elemente der „Geschäftskartenidentität„ des Benutzers, außer seinem Personennamen. Als ein Spezialfall könnten einige CAs die absolute Identität von ausgewählten Benutzern zertifizieren, beispielsweise von Kindern reicher Kunden, Diplomaten oder von für die nationale Sicherheit tätigen Personen, was fast sicher mit biometrischen Techniken unterstützt werden kann. Das würde selten auftreten und wird hier nur zur Vollständigkeit angeführt, um das Konzept der „relativen Identität„ abzurunden.

Autorisierungsinformationen in Zertifikaten
Attribute können Beschränkungen übermitteln, welche die Bedingungen kontrollieren, unter denen eine Signatur gültig ist. Ohne solche Beschränkungen, würde die Fälschungsgefahr übermäßig groß sein, da eine elektronische Signatur fast jedem digitalen Dokument durch irgendjemanden beigefügt werden kann, der die Smartcard des Benutzers und die persönliche Identifizierungsnummer (PIN) besitzt. In der elektronischen Umgebung sind die normalen Kontext-Kontrollen der Dokumentenerzeugung und der körperlichen Auslieferung entweder nur in geringem Maße oder überhaupt nicht vorhanden.
Selbst authentische Benutzer sind kaum vertrauenswürdig, um formfreie Offline-Börsengeschäfte durchzuführen und Organisationen begrüßen daher die Fähigkeit, den Geltungsumfang der schnellen Signaturautorisierung definitiv zu begrenzen. Solche Autorisierungsattribute könnten, zusätzlich zu den Standard- X.500-Attri-buten, Transaktionsbeschränkungen, Kosignaturerfordernisse, Dokumententypen, Gegenstandsbeschränkungen, autorisierte Signaturen, geografische und zeitliche Kontrollen, Alter der Signatur, langbewährte Partner, Delegierungskontrollen und Bestätigungsforderungen enthalten. Diese Attribute können in einem Autorisierungszertifikat oder in mehreren Autorisierungszertifikaten verschlüsselt werden, die durch die Unterzeichner der Sponsororganisation oder durch eine externe CA, die im Auftrag der Organisation arbeitet, signiert werden. Ein Beispiel eines Autorisierungszertifikats und eine zugehörige Transaktion sind in 5 dargestellt.
Wenn ein empfangender Benutzer (Verifizierer) eine Transaktion 51 von einem absendenden Benutzer empfängt, verwendet der Empfänger zuerst das Basisschlüsselzertifikat des Absenders 55, um die Signatur 52 des Absenders an der Transaktion 51 zu verifizieren. Wie es ausführlicher noch nachfolgend beschrieben wird, kann der Empfänger auch das Autorisierungszertifikat des Absenders 56, das von dem Sponsor des Absenders 59 signiert ist, verwenden, um die Kosignaturen 53 und die notariell beglaubigten Zeitmarken 54 zu verifizieren und zu verifizieren, dass die Attributwerte 57 der Transaktion 51 in den autorisierten Attributwerte 58 fallen, wie sie in dem Autorisierungszertifikat 56 spezifiziert sind.
Der Benutzer kann abhängig von der Transaktion die Kontrolle des Wertes von Transaktionen oder anderen Dokumenten, die der Benutzer erzeugen kann, einschränken. Die Benutzersignatur wird nur auf Transaktionen, die entweder bis zu einer bestimmten geldlichen Beschränkung oder zwischen zwei Geldwertbegrenzungen erzeugt worden sind, gültig. Somit sendet, wie in 6 dargestellt ist, der absendende Benutzer eine Transaktion 601, die durch den Absender signiert ist (siehe 603) (tatsächlich durch die Smartcard 600 des Benutzers, die seinen privaten Schlüssel enthält) ab und hängt ein Autorisierungszertifikat 604 daran an. Der Verifizierer verwendet das Autorisierungszertifikat 604 um die Benutzersignatur 603 zu verifizieren (Schritt 607) und um zu verifizieren, dass der Geldwert 602 der Transaktion in den Transaktionsbegrenzungs-Attributwert 605 in dem Autorisierungszertifikat 604 fällt. Der Verifizierer verifiziert (Schritt 609) die Sponsorsignatur 606 auf dem Autorisierungszertifikat 604 unter Verwendung des öffentlichen Schlüssels des Sponsors 610. Wenn die Richtigkeit einer dieser Signaturen und Attributswerte nicht nachgewiesen wird, wird die Transaktion zurückgewiesen (Schritt 611). Wenn die Rihtigkeit vollständig nachgewiesen wird, wird die Transaktion akzeptiert (Schritt 612).
Hinsichtlich der Kosignaturerfordernisse können zusätzliche Signaturen erforderlich sein, damit eine gegebene Signatur als gültig betrachtet werden kann. Beschluss- und Wichtungsmechanismen können verwendet werden, um ziemlich sorgfältige Prüfungen und Bilanzen aufzubauen, um explizit das Vertrauensniveau bei jedem Benutzer zu bestimmen. Die spezielle Reihenfolge oder Ordnung der erforderlichen Signaturen kann ebenfalls spezifiziert werden. Bezug auf 7 nehmend, sendet der absendende Benutzer A eine Transaktion 702, die durch seine eigene Smartcard 700 signiert ist, (Schritt 703) und, wenn die Signatur eines Benutzers B für die Transaktion 702 erforderlich ist, signiert durch die Smartcard des Benutzers B 701 (Schritt 704) ab. Der absendende Benutzer A hängt weiterhin sein eigenes Autorisierungszertifikat 705 an die Transaktion 702 an. Der Verifizierer verwendet das Autorisierungszertifikat 705 um die Signatur des Benutzers A zu verifizieren (Schritt 703) und verwendet den öffentlichen Schlüssel des Sponsors 713, um die Signatur 707 auf dem Autorisierungszertifikat 705 zu verifizieren (Schritt 712). Wenn die Richtigkeit einer Signatur nicht nachgewiesen wird, wird die Transaktion zurückgewiesen (Schritt 720). Wenn ein Kosignaturwert 706 durch das Autorisierungszertifikat 705 gefordert wird (Schritt 714), setzt der Empfänger die Forderung durch Verifizieren der Kosignersignatur des Benutzers B für die Transaktion 702 durch (Schritt 715) und überprüft darauf das Zertifikat für den öffentlichen Schlüssel des Benutzers B 708 durch Verifizieren der Signatur 709 des Zertifikatherausgebers (Schritt 716) unter Verwendung des öffentlichen Schlüssels 717. Wenn die Richtigkeit der Signatur entweder des Benutzers B oder seines Zertifikatherausgebers nicht nachgewiesen wird, wird die Transaktion zurückgewiesen (Schritt 722).
Die Verwendung der Kosignaturen erlaubt es einer Organisation effektiv Überprüfungen und Bilanzen zu definieren und explizit das Vertrauensniveau jedes Benutzers bestimmen. Die Verwendung von Kosignaturen verringert in hohem Maße die Gefahren, die aus dem unbeabsichtigten Bekanntwerden eines privaten Schlüssels durch Diebstahl, Missbrauch oder falsches Aufbewahren einer Smartcard oder PIN entstehen. Insbesondere wird angenommen, dass die Möglichkeit der Forderung von Kosignaturen, Wertbeschränkungen und von diesbezüglichen Kontrollen es den Organisationen ermöglichen wird, alle Signaturautorisierungen sorgfältig zu verwalten und fein abzustimmen, und dass ihnen dadurch alle Werkzeuge zur Verfügung stehen, die erforderlich sind, um ihre Gefahren zu verwalten und einzuschränken. Die Verwendung von Kosignaturen erlaubt weiterhin die Verteilung der Autorisierungsfunktion auf viele Lokationen und Hardware-Plattformen mit der sich daraus ergebenden Minimierung von Gefahren, die sich aus Zugriffskontrollenfehlern an einer dieser Plattformen ergeben. Siehe US-Patente Nr. 4,868,877; 5,005,200 und 5,214,702.
Autorisierungssignaturen, die die im Zertifikat des Unterzeichners spezifizierten Beschränkungen erfüllen müssen, können auch von anderen Kosignaturen unterschieden werden, indem ein Signaturzweck als ein Signaturattribut einbezogen wird und indem gefordert wird, dass eine Angabe des Signaturzwecks in den Daten, die signiert werden, einzuschließen ist. Dieses Signaturzweck-Attribut könnte die folgende Werte erfordern: (a) eine Autorisierungssignatur entsprechend dem Dokument, (b) eine Autorisierungskosignatur entsprechend dem Dokument, wobei das Zertifikat des Kosignierenden ausreichende Autorität aufweist, um das Dokument zu autorisieren, und (c) eine Bestätigungs-Kosignatur, wenn das Zertifikat des Kosignierenden nicht selbst ausreichende Autorität aufweist, um das Dokument zu autorisieren. Signaturzweckverschlüsselungen werden in dem ANSI-Standardentwurf X12.58, Version 2 (Anhang), herausgegeben von der Data Interchange Standards Association (DISA), behandelt, der im Fachgebiet gut bekannt ist und durch Verweis hierin einbezogen wird.
Der Benutzer kann auch darauf eingeschränkt werden, nur spezielle Dokumententypen zu signieren, beispielsweise gewöhnlichen Schriftverkehr, Kaufaufträge, spezifizierte Transaktionstypen von elektronischer Dateninformation, Geschäftsverträge, spezifizierte Finanzinstrumente usw., wie sie durch die industrieweiten Verfahrensweisen definiert sind. Es kann auch aus Effektivitätsgründen erwünscht sein, bestimmte große Klassen von Transaktionen und Dokumenten auszuschließen. Bezug auf 8 nehmend, setzt der Empfänger die Dokumententypbeschränkung in der Transaktion des Absenders 801 durch, indem er zuerst die Signatur des Absenders 803 für die Transaktion verifiziert (Schritt 807) und darauf den Dokumententypattributwert 802 in der Transaktion 801 verifiziert, um die Dokumententypbeschränkung 805 in dem Autorisierungszertifikat des Absenders 804 durchzusetzen (Schritt 808). Der Empfänger verifiziert dann das Autorisierungszertifikat 804 unter Verwendung des öffentlichen Schlüssels des Sponsors 811, um die Signatur des Sponsors 806 zu verifizieren (Schritt 809). Wenn entweder die Richtigkeit einer Signatur oder der Attributbeschränkung nicht nachgewiesen wird, wird die Transaktion zurückgewiesen (Schritt 810).
Es ist auch vorteilhaft, positive oder negative Beschränkungen hinzuzufügen, welche den Transaktionsgegenstand oder die Kontextklasse betreffen. So kann zum Beispiel ein Vertreter darauf beschränkt werden, Kaufaufträge nur für eine Klasse von Waren (beispielsweise Waren für den Bürobedarf) zu signieren oder es wird ihm die Autorität verweigert, beispielsweise wenn einem Vertreter die Möglichkeit verweigert wird, pornografische Materialien zu kaufen. Gegenstandsbeschränkungen werden durch den Empfänger der Transaktion in der gleichen Weise durchgesetzt, wie bei den Beschränkungen für den Dokumententyp und sie können für viele Dokumenttypen gelten und noch dazu eine separate Spezifikation für allgemeinere Dokumententypen erfordern.
Eine Organisation kann angeben, dass sie spezifisch autorisierte Signaturberechtigte hat, d.h. nur bestimmte Personen können für die Organisation „signieren„, ähnlich einem „Standard-Körperschaftsbeschluss„ für diesen Zweck. Das könnte das Dokumententyp-Konzept als eine zusätzliche Kontrolle des Signierens von „körperschaftlichen„ Dokumententypen ergänzen. Diese Beschränkung kann implementiert werden, indem vorgeschrieben wird, dass eine Kosignatur erforderlich ist, in welcher der Titel des Kosignierenden (in seinem Unterscheidungsnamen) gleich einem Titel auf einer spezifizierten Liste ist, die in dem Autorisierungszertifikat enthalten ist. Das ersetzt eine Auflistung der Namen von einem oder mehreren geforderten Kosignierenden.
Geografische und zeitliche Kontrollen schließen Lokationen und Zeitspannen ein, an oder in denen Transaktionen als gültig angesehen werden können. Die Einschaltung eines lokalen, vertrauenswürdigen Notars für das Einbringen einer „Zeitmarke„ wird vorausgesetzt. Ein solcher Notar würde eine vertrauenswürdige Zeitmarke an die Signatur des Erzeugers auf einem Dokument anhängen und dann das Ergebnis signieren. Somit würden Beschränkungen der Tageszeit und des Wochentages normalerweise mit der Arbeitswoche und dem Benutzerort übereinstimmen. Außerdem würde die Lokationsinformation mit der Notarinformation verbunden werden, um so den Zugang zu einem spezifischen Netzwerksegment, das normalerweise dem Arbeitsbereich des Benutzers zugeordnet ist, zu beschränken. Der „Detailliertheitsgrad„ der Lokationskontrollen würde von der Netzwerkarchitektur abhängen. Der Signierende oder das Computersystem des Signierenden muss eine zertifizierte Zeitmarke von einem festgelegten örtlichen Server an die Transaktion anbringen. Ansonsten kann der Verifizierer die Transaktion nicht akzeptieren und der Sponsor des Signierenden ist nicht daran gebunden. Wie in 9 dargestellt, bringt der absendende Benutzer, wie üblich, ein Autorisierungszertifikat 902, eine autorisierte Zeitmarke 903 und ein Zeitserverzertifikat 904 an der Transaktion 901 an. Der Empfänger verifiziert die Signatur des Absenders 905 an der Transaktion 901 (Schritt 921) und verifiziert die Signatur des Sponsors 908 an dem Autorisierungszertifikat 902 (Schritt 922). Der Empfänger verifiziert dann, (1) in Schritt 923, dass die Hash-Codierung des Textes der Zeitmarkentransaktion mit dem Ergebnis des Textes der Transaktion 901 übereinstimmt, die mit Hilfe einer bekannten Hash-Funktion codiert wurde, (2) verifiziert in Schritt 924 dass die Zeit und das Datum 910 auf der Transaktionszeitmarke 903 in die Attributwerte für die autorisierte Zeit und das Datum 906 fallen, wie sie in dem Autorisierungszertifikat 902 festgelegt sind, (3) verifiziert in Schritt 925 die Zeitserversignatur 911 an der Zeitmarke 903 und (4) verifiziert in Schritt 926 die Signatur des Sponsors 912 auf dem Zeitserverzertifikat. Wenn alle diese Bedingungen erfüllt sind, wird die Transaktion akzeptiert (Schritt 931), wenn nicht, wird sie zurückgewiesen (Schritt 930).
Weiterhin kann ein Dokument nicht gültig sein, wenn die Signatur nicht in einer bestimmten festgelegten Zeit verifiziert ist. Für hochwertige Transaktionen würde dieses Attribut für das Alter der Signatur sehr kurz sein, während für normalere Transaktionen, insbesondere für solche, die über Speicher- und Terminsysteme abgesendet werden, beispielsweise über X.400, ein längerer Zeitraum (beispielsweise zwei Tage) angemessen sein würde. 10 stellt das Durchsetzen des Attributwertes für das Alter der Signatur durch einen Empfänger dar. Die Verifizierungszeit würde unter Verwendung einer Empfangsbestätigung 103 angegeben werden, die durch einen vertrauenswürdigen Zeitmarkenservice 104 signiert ist und die mindestens den Namen des Empfängers und die Signatur der ursprünglichen Transaktion enthält. Der Verifizierer muss eine mit der Zeitmarke versehene Kopie der Originalsignatur vorlegen, die unverzüglich nach der Zeit und dem Datum der Originaltransaktion datiert ist, oder der Sponsor weist die Transaktion zurück. Wie in 10 dargestellt ist, verifiziert der Empfänger (Verifizierer) 121 die Signatur des Absenders 107 an der Transaktion 101 und verifiziert die Signatur des Sponsors 115 an dem Autorisierungszertifikat 102. Der Empfänger verifiziert dann im Schritt 122, dass die Differenz zwischen dem Datum 105 und der Zeit 106 an der Transaktion 101 und dem Datum 111 und der Zeit 112 an der Zeitmarke 103 sich innerhalb der Attributsbeschränkung für das Alter der Signatur 108 in dem Autorisierungszertifikat 102 befindet. Der Empfänger verifiziert in Schritt 123 weiter, dass die Hash-Codierung 110 der Transaktion 101 in der vertrauenswürdigen Zeitmarke 103 mit dem Text der Transaktion 101 übereinstimmt. Wenn alle diese Bedingungen erfüllt sind, wird die Transaktion in Schritt 130 akzeptiert, wenn nicht, wird sie in Schritt 131 zurückgewiesen.
Ein ähnliches Konzept ist das Konzept eines Mindestalters der Signatur. In diesem Fall würde die Signatur bis zu einer bestimmten Zeit nach der Signierung nicht gültig sein. Das erlaubt es, eine Smartcard als verloren gegangen zu melden und eine Widerrufnachricht an den Empfänger zu übermitteln. Das Kontrollattribut kann ein maximales oder ein Mindestalter für die Signatur festlegen.
Ein Attributwert für „langbewährte Partner„ beschränkt eine Betrachtungseinheit darauf, sich nur mit einer festlegten Gruppe von bekannten, vertrauenswürdigen Partnern zu befassen. Das ist eine allgemeine Forderung in über ein öffentliches Telefonnetz betriebenen Systemen des elektronischen Bankverkehrs, die normalerweise fordern, dass alle autorisierten Zahlungsempfänger im Voraus festgelegt sind. Ein anderer Weg, um das zu erreichen, ist das Verbot von „formlosen Übertragungen„. Sponsoren sind sich darüber im Klaren, dass im Fall eines Fehlers, sie eine bessere Chance der erfolgreichen Stornierung des Fehlers haben, wenn sie sich mit einem großen, zahlungsfähigen und kreditwürdigen Partner befassen, als beim Befassen mit einem kleinen, unbekannten und nicht autorisierten Partner. Es können getrennte Zertifikate für jeden Partner ausgegeben werden, um zu verhindern, dass (außer ihm selbst) ein Wettbewerber die Kundenliste des Benutzers in einem einzigen Zertifikat erhält. Der zugelassene Partner kann entweder als allgemeiner Name, Unterscheidungsname, Zertifikatnummer oder als ein Hash-codierter Wert entweder des Unterscheidungsnamens oder des öffentlichen Schlüssels des Partners codiert werden. Um den Nutzen aus der Transaktion zu beanspruchen, muss der Verifizierer ein Zertifikat vorlegen, das mit dem verschlüsselten Wert des Partners übereinstimmt.
11 zeigt die Verifizierung der Benutzertransaktion durch den Sponsor des Benutzers nach dem Empfang durch einen Empfänger. Der Empfänger (Partner) verifiziert in Schritt 1110 die Signatur des Benutzers 1103 an der Transaktion 1101 und in Schritt 1111 die Signatur des Sponsors 1105 auf dem Autorisierungszertifikat des Benutzers 1102. Wenn die Richtigkeit einer dieser Signaturen nicht nachgewiesen wird, wird die Transaktion 1101 im Schritt 1112 zurückgewiesen. Wenn die Richtigkeit der Signaturen nachgewiesen wird und die Transaktion durch den Empfänger in Schritt 1113 akzeptiert wird, heißt der Empfänger die Transaktion 1101 gut, indem er seine verifizierte Transaktion 1114 in Schritt 1116 mit dem Text 1106 der Originalbenutzertransaktion 1101 und mit der Signatur des absendenden Benutzers 1103 gegenzeichnet, wobei das Zertifikat 1115 des Empfängers angebracht wird. Beim Durchsetzen der Beschränkung hinsichtlich langbewährter Partner in dem Autorisierungszertifikat des absendenden Benutzers 1102 verifiziert dann der Sponsor des absendenden Benutzers in Schritt 1121 die Signatur des absendenden Benutzers 1103, wie sie in der verifizierten Transaktion des Empfängers 1114 enthalten ist und verifiziert in Schritt 1122 die Signatur des Empfängers 1116 daran. Wenn diese Signaturen verifiziert sind, verifiziert der Sponsor als Nächstes in Schritt 1123 den Hash-Codierungswert des öffentlichen Schlüssels des Partners durch Hash-Codierung des öffentlichen Schlüssels des Empfängers 1117 und Überprüfung des Ergebnisses gegenüber einem der Hash-Codierungswerte des öffentlichen Schlüssels des autorisierten Partners 1104, wie er in dem Autorisierungszertifikat des Benutzers 1102 spezifiziert ist (der öffentliche Schlüssel des Empfängers 1117, den der Sponsor zur Verifizierung mit der Hash-Funktion in Schritt 1124 codiert, wird verifiziert, wenn der Sponsor das Zertifikat des Empfängers verifiziert). Wenn diese Bedingungen erfüllt sind, wird die Transaktion in Schritt 1125 akzeptiert.
Die Attributwerte der Delegierungskontrollen können die Typen und Wertbereiche von Autorisierungen beschränken, die eine CA bei der Ausgabe eines Attributzertifikats spezifiziert. Sie können auch dazu dienen, den Bereich und die Tiefe zu begrenzen, auf die ein Benutzer seine Signierungsautorität an andere delegieren darf. So könnte zum Beispiel eine Haupt-CA eine Organisations-CA darauf beschränken, Autorisierungen zu erteilen, die es ihren Endbenutzern nur erlauben, Dokumente zu signieren, deren Dokumententyp in einen Bereich von Dokumenten fällt, der Bezug auf die Steueradministration des Staates hat, oder eine CA könnte einem Benutzer eine bestimmte Autorität gewähren mit der Festlegung, dass sie nur an eine andere Person delegiert werden darf, die den Rang eines Gehilfen des Leiters der Finanzabteilung oder einen höheren Rang besitzt und dass die Delegierungszeit dreißig Tage nicht überschreiten darf und dass keine weitere Delegierung nach unten erfolgen darf.
Ein anderes Autorisierungsattribut, das als „Bestätigung auf Anforderung„-Wert bezeichnet wird, verhindert, dass das Signieren gültig wird, außer wenn der Verifizierer eine Kopie der verifizierten Transaktion an eine dritte Partei, normalerweise an die Sponsororganisation oder an eine Arbeitsaufsichtsperson an eine festgelegte Mail- oder Netzwerkadresse sendet und entweder (a) eine Akzeptierungs-/Zurückweisungsnachricht erhält, oder (b) eine festgelegte Zeit abgelaufen ist. Diese Forderung gleicht einer Kosignatur, wird jedoch erhoben, nachdem die Transaktion abgesendet ist, und nicht bevor sie abgesendet ist. Eine solche Bestätigung nach dem Ereignis könnte in Situationen mit geringerem Risiko akzeptabel sein, in denen wenige Transaktionen zurückgewiesen würden und in denen die Kosignatur der dritten Partei im Voraus ungebührlich aufwändig wäre, oder sie könnte in Fällen mit hohem Wert bevorzugt werden, in denen eine absolut sichere Online-Prüfung gefordert ist. In diesem Fall kehrt sich das Ablaufmuster zu einem Online-System anstatt eines Offline-Systems um. Wie in 12 dargestellt, verifiziert der Empfänger zuerst, wie üblich, in Schritt 1211 die Signatur des Absenders 1203 an der Transaktion 1201 und verifiziert in Schritt 1212 die Signatur des Sponsors 1205 auf dem Autorisierungszertifikat des Benutzers 1202. Wenn die Richtigkeit einer dieser Signaturen nicht nachgewiesen wird, wird die Transaktion 1201 in Schritt 1213 zurückgewiesen. Wenn die Signaturen verifiziert sind, sendet der Empfänger in Schritt 1214 eine Bestätigungsnachricht, die aus der Originaltransaktion 1201 (dem Transaktionstext 1202 und der Signatur des absendenden Benutzers 1203) besteht, an den Sponsor 1215 des Benutzers 1215, wie es in Schritt 1204 in dem Autorisierungszertifikat des Absenders 1202 festgelegt ist. Der Empfänger sollte von dem Sponsor 1215 dieselbe Nachricht als Bestätigung 1216 zurück erhalten, jedoch in Schritt 1205 durch den Sponsor signiert. Der Empfänger verifiziert dann in Schritt 1217 die Signatur des Sponsors 1220 und die Bestätigungsnachricht 1216 und akzeptiert in Schritt 1219 die Transaktion 1201.
Um komplexe Kombinationen von Beschränkungen zu erzeugen, kann ein Filterausdruck, der ein Boolescher- oder ein logischer Ausdruck sein kann, der ein Attribut oder mehrere Attribute enthält, eine Konstruktion von Beschränkungen erlauben, die Mehrfachattribute einschließen. Die Attributaussagen werden mit den üblichen Booleschen Verknüpfungen „und„, „oder„ und „nicht„ verknüpft. So könnte zum Beispiel der Sponsor einen Benutzer darauf beschränken, eine Transaktion eines Typs vorzulegen, der einem „Kaufauftrag„ gleicht und einen Wert von weniger als 100 000 US-Dollar hat. Die Aussagen können weiterhin entweder einen einzelnen Attributswert (gleich, kleiner als, größer als usw.), Mehrfachwerte eines Attributs (Untermenge, Übermenge usw.) oder das Vorliegen oder das Fehlen eines Attributs in dem Dokument einschließen. Es ist natürlich zu erkennen, dass jede der beschriebenen Beschränkungen, sowie auch andere, in Wirklichkeit zur gleichen Zeit in demselben Dokument oder in derselben Transaktion vorliegen können. Diese Beschränkungen sind aus Gründen der deutlichen Darstellung getrennt behandelt und dargestellt.
Die Verwendung von Autorisierungsattributen erlaubt es einem Empfänger sowohl die Autorisierung als auch die Authentifizierung zu verifizieren. In einem solchen Szenario würden die Zertifikate des Sponsors, gebündelt durch das Zertifikat der Sponsororganisation, als Autorisierung der Transaktion, auf die sie angewendet werden, „auf Sicht„ interpretiert werden, wobei vorausgesetzt wird, dass alle festgelegten Beschränkungen eingehalten werden.
Ein Satz von Basisverfahrensweisen muss für die Verwendung in der Finanzdienstindustrie und in anderen Industrien definiert werden, um ein gut definiertes, prognostizierbares Niveau des Dienstes für den Verifizierungsprozess zur Verfügung zu stellen. Diese Verfahrensweisen könnten auf einer multilateralen Basis durch jede teilnehmende Firma abgestimmt werden, und es könnte vereinbart werden, dass bestimmte der im vorliegenden Abschnitt behandelten Beschränkungen und Autorisierungen immer zur Wirkung kommen, wenn es nicht ausdrücklich anders vorgesehen ist. Eines der wichtigsten Elemente dieser Industrievereinbarungen würde die Definition und das Codieren von Dokumententypen sein. Das müsste auf einer der Industrie vorgelagerten Basis erfolgen, da die Regeln offensichtlich zum Beispiel für Zollinspektoren, Flugzeu ginspektoren, Buchprüfer, Steuerbeamte, usw. sehr unterschiedlich sind.
Bestimmte Autorisierungsattribute können zu dem spezifischen Inhalt des Dokuments selbst gehören. Das kann Probleme für die automatisierte maschinelle Verifizierung aufwerfen, da der Computer des Verifizierers nicht immer in der Lage sein kann, die Werte solcher Attribute für ein gegebenes Dokument oder für eine gegebene Transaktion zu bestimmen. Beispiele dafür sind Kennsätze für Geldtransaktionslimite, Dokumententypen und Sicherheits- oder Vertrauenswürdigkeit. Es ist daher erwünscht, vorzugsweise am Anfang des Dokuments oder der Transaktion, einen Standard-Datenblock zur Verfügung zu stellen, der klar die Attribute verschlüsselt, zum Beispiel den festgelegten Geldtransaktionswert, den Dokumententyp oder den Kennsatz für die Sicherheit und die Sensibilität. Diese Dokumentenmarkierung wird durch den Computer des Signierenden zur Erleichterung für den Verifizierer und als Hilfsmittel für den Verifizierungsprozess angehängt. Im Fall eines Konfliktes zwischen der Markierung und dem tatsächlichen Inhalt des Dokuments, würde jedoch die Sprache des Dokuments entscheidend sein. Bei strukturierten Transaktionen, beispielsweise Transaktionen zum Austausch elektronischer Daten (EDI), bei denen Dokumententypen und Geldwerte bereits vollständig maschinenlesbar sind, würden die Markierungen jedoch nicht benötigt werden.
Als mögliche Erleichterung bei der Verarbeitung von einfachen Autorisierungen, insbesondere, wenn ein gegebener Benutzer viele gleiche Transaktionen signiert, ist es oft nützlich, den öffentlichen Schlüssel des Benutzers aus seinem Basisauthentifizierungszertikat heraus zu kopieren und ihn als ein anderes Attribut in ein Autorisierungszertifikat einzubeziehen. Das gestattet, dass das Autorisierungszertifikat beiden Zwecken dient (Authentifizierung und Autorisierung) und erlaubt es dem Absender das Basisauthentifizierungszertifikat aus jeder Transaktion wegzulas sen. Weiterhin kann es dort, wo man einer Vorrichtung vertraut, dass eine vorgegebene Bedingung erfüllt wird, gleichermaßen vorteilhaft sein, den öffentlichen Schlüssel der Benutzervorrichtung in das Authentifizierungs- oder Autorisierungszertifikat zu kopieren. Dadurch wird weiterhin die Notwendigkeit eliminiert, das Vorrichtungszertifikat mit jeder Transaktion abzusenden.
Wechselbeziehungen mit dritten Parteien
Zusätzliche nützliche Merkmale von digitalen Signaturen über die hinausgehend, die unter Verwendung von Attributzertifikaten zur Verfügung gestellt werden können, schließen eine Wechselbeziehung zwischen einem Signierenden und dritten Parteien verschiedener Typen ein.
Eine solche Anwendung für digitale Signaturen ist die elektronische notarielle Beglaubigung. Wie vorher erläutert, besteht die Notwendigkeit, Dokumente unter Einschaltung einer dritten vertrauenswürdigen Partei mit einer Kosignatur zu versehen, um eine genaue Zeitmarken- und/oder Lokationsinformation zur Verfügung zu stellen. Einfach auf die Erzeuger der Signatur zu vertrauen, um diese Information in einer genauen Art und Weise bereitzustellen, führt zu Signaturen die gegenüber betrügerischen Handlungen verwundbar sind, zum Beispiel zum Vor- oder Nachdatieren von Dokumenten. Ein elektronischer „Notar„ würde durch seine CA-Verfahrensweisen vertrauenswürdig sein, diese Informationen korrekt zur Verfügung zu stellen. Die Mehrfachsignaturmöglichkeiten, die bereits vorausgesetzt sind, können erweitert werden, um für diese Dienstleistung ein Rahmenwerk zur Verfügung zu stellen.
Für notarielle Beglaubigungszwecke werden Zeitmarken- und Lokationsinformationen als Signaturattribute einbezogen. Einzelne Signaturstrukturen können entweder abgesondert und gespeichert werden, oder, wenn es gewünscht wird, separat aus dem Dokument herausgenommen werden.
Mehrfachsignaturen oder gemeinschaftliche Signaturen auf dem Dokument selbst können auch von „Gegensignaturen„ unterschieden werden, die Signaturen auf der Signaturstruktur sind, in denen sie gefunden werden und nicht auf dem Dokument selbst. Eine Gegensignatur stellt somit einen Nachweis der Ordnung zur Verfügung, in der die Signaturen angewendet werden. Weil eine Gegensignatur selbst eine Signaturstruktur ist, kann sie auch selbst Gegensignaturen enthalten. Das erlaubt den Aufbau von willkürlich langen Ketten von Gegensignaturen. Die elektronische notarielle Beglaubigung würde dann aus dem Gegenzeichnen der Erzeugersignatur bestehen und eine Zeitmarke in der Information enthalten, die signiert ist. Für Anwendungen mit sehr hohem Risiko kann es auch erwünscht sein, Mehrfachsignaturen auf jedem Zertifikat von einer CA oder mehreren CA zu fordern, wobei die Signaturen in unabhängigen kryptographischen Einrichtungen und mit verschiedenen privaten Schlüsseln ausgeführt werden.
Für notarielle Beglaubigungen auf der Ebene der Datenverifizierung, die vor dem Signieren durchgeführt wird (die von der reinen Existenz des Dokuments, in der die notarielle Beglaubigung vollkommen automatisch durchgeführt wird, bis zur Verifizierung des Dokumenteninhalts durch den Menschen reichen) und basierend auf Datenzurückbehaltungs- und Rechnungsprüfungsmöglichkeiten, können verschiedene Dienstleistungsstufen definiert werden.
Eine andere Anwendung für digitale Signaturen sind Delegierungs- oder „Anwaltsvollmacht„-Zertifikate. Weil Benutzer oft dazu geneigt sind, ihre Vorrichtungen oder Smartcards anderen anzuvertrauen, zum Beispiel Sekretären oder Mitarbeitern, wenn die Benutzer in Urlaub gehen, tritt häufig die Situation ein, in der ein Benutzer die Smartcard und die PIN eines anderen Benutzers erhält, wodurch die Smartcard der Gefahr eines möglichen Miss brauchs ausgesetzt wird. Das System erleichtert daher das Erteilen von Anwaltsvollmachtzertifikaten, die es einem Bevollmächtigten erlauben, die Signatur seiner eigenen Smartcard mit der Autorität des die Vollmacht erteilenden Benutzers zu verbinden. Das Anwaltvollmachtzertifikat würde mindestens den Namen des die Vollmacht Erteilenden, die Identifizierung des Zertifikates des Öffentlichen Schlüssels des Bevollmächtigten und einen kurzen Gültigkeitszeitraum enthalten und würde durch den die Vollmacht Erteilenden signiert sein. Eine andere Möglichkeit ist, dass der Bevollmächtigte ein neues Schlüsselpaar erzeugt, das ausschließlich für die Verwendung mit der Signatur des die Vollmacht Erteilenden bestimmt ist, wobei der neue öffentliche Schlüssel in das Anwaltsvollmachtzertifikat einbezogen ist. Das würde jede mögliche Unklarheit bei der Verwendung des privaten Schlüssels des Bevollmächtigten im Namen des die Vollmacht Erteilenden und in seinem eigenen Namen eliminieren.
Das Problem der Aushändigung von Smartcards kann in hohem Maße durch Bereitstellen arbeitsfähiger Alternativen verringert werden, die das Prinzip der Eigenverantwortung beibehalten. Die umfassende Implementierung dieses Merkmals macht die Nichtanerkennung von Smartcardausleihen praktisch durchführbar und das ist ein höchst erwünschtes Ziel.
Die vorher erläuterte Verwendung von Vollmachtzertifikaten bringt mit sich, dass der Benutzer als eine CA agiert. In einigen Fällen, insbesondere in solchen, in denen die Transaktionen Organisationsgrenzen überschreiten, kann es von Interesse sein, dass der Grad der Kontrollen und Rechnungsprüfungen, der in der kryptographischen Vorrichtung des einzelnen Benutzers (zum Beispiel eine Smartcard) zur Verfügung steht, nicht ausreichend ist. In solchen Fällen könnten auf Anforderung eines eine Vollmacht Erteilenden durch eine CA Vollmachtzertifikate als normale Autorisierungszertifikate ausgegeben werden. Das erlaubt weiterhin, dass unter Verwendung des Standard-CRL-Mechanismus (CRL = Zerti fikatwiderrufliste) Vollmachtzertifikate widerrufen werden können. Benutzerzertifikate könnten dann eine Liste möglicher Bevollmächtigter angeben und das Vollmachtzertifikat selbst würde ein Attribut enthalten, das den Namen des die Vollmacht Erteilenden angibt. In Ausübung der Anwaltsvollmacht kann ein Benutzer angeben, dass er für einen anderen Benutzer signiert, indem ein „Signieren-für„ -Signaturattribut in das Dokument oder in die Transaktion einbezogen wird, d.h. der Name des Benutzers für den signiert wird. Es muss ein gültiges Vollmachtzertifikat vorliegen, das den Signierenden autorisiert, für den Benutzer zu handeln, für den er signiert. Die Vollmacht ist auch in Verbindung mit einem kryptographischen Modul in einem Personalcomputer des Benutzers nützlich. Hash-Codieren und Signieren eines Dokuments sollten idealerweise eine einzige Operation sein, um das Substituieren eines falschen Hash-Codes über Softwarehacking zu verhindern. Der normalen Smartcard mangelt es jedoch an Computerleistung, um ein sehr langes Dokument mit der Hash-Codierung zu versehen. Eine Lösung ist, dass die Smartcard diese Funktion unter Verwendung eines sehr kurzlebigen Vollmachtzertifikates, das nur für wenige Minuten gültig ist, auf den kryptographischen Modul delegiert. Dieses Zertifikat ist durch die Smartcard des Benutzers signiert und zeigt an, dass der Benutzer der Smartcard die Delegierung erlaubt hat. Siehe zum Beispiel: Gasser, M., A. Goldstein, C. Kaufman und B. Lampson, „Die Sicherheitsarchitektur des verteilten digitalen Systems„, Proceedings der 12. National Computer Security Conference (Nationale Computersicherheits-Konfe-renz) 1989; Gasser, M und McDermott, E., „Eine Architektur für die praktische Delegierung in einem verteilten System„, Proceedings des IEEE Symposium on Security and Privacy (Symposium über Sicherheit und Geheimhaltung) 1990.
Nichtöffentlicher öffentlicher Schlüssel
Ein grundlegenderes Problem ist jedoch, zu sichern, dass alle möglichen Empfänger tatsächlich die vorher beschriebenen Zertifikat- und Attributsverifikationsmethoden verwenden. Obwohl diese Methoden es den Sponsororganisationen erlauben, sich selbst, ihre Benutzer und diejenigen, mit denen sie Geschäfte abwickeln, vor der Haftung zu schützen, die sich aus gefälschten Transaktionen ergibt, indem sie es ihnen erlaubt, die Identität und die Berechtigung derer, mit denen sie Geschäfte abwickeln, und die Kenndaten der Transaktion vor dem Durchführen der Transaktion zu verifizieren, gibt es keine Garantie, dass alle Empfänger tatsächlich in dieser Weise verifizieren. Wenn ein Empfänger bei einer Transaktion nicht zuerst die Attribute sowohl des Absenders als auch der Transaktion verifiziert und wenn sich später herausstellt, dass der Absender eine betrügerische oder nicht autorisierte Transaktion abgesendet hat, könnte der Empfänger den Absender oder seinen Sponsor haftbar machen, indem er beansprucht, dass er sich nicht bewusst war, dass eine Forderung zur Autorisierungsverifizierung der Basissignatur des Benutzers besteht. Ein Weg, um zu sichern, dass Sponsoren und andere Betrachtungseinheiten gegen eine Haftung in einer solchen Situation geschützt sind, ist die Forderung, dass der Signierende den Hash-Codierungswert jeder seiner Identitäts- und Autoritätszertifikate als Attribute in seine Signatur einbezieht. Das kann verhindern, dass ein Verifizierer beansprucht, dass er von solchen Zertifikaten und von den Beschränkungen, die sie auferlegen, nichts gewusst hat. Der Signierende könnte das jedoch (absichtlich oder unabsichtlich) unterlassen. Ein anderer, mehr Nachdruck verleihender, Weg zur Sicherung der Erfüllung durch den Verifizierer ist, zu verhindern, dass der Hauptschlüssel, der öffentliche Schlüssel der ultimativen Autorität, d.h. der Zertifizierungsautorität der höchsten Ebene, den die Verifizierer benötigen würden, um irgendeinen Teil der Transaktion zu verifizieren, an einen Benutzer (oder an eine Vorrichtung oder Smartcard des Benutzers) verteilt wird, es sei denn, dass der Benutzer einen Vertrag mit dem kryp tographischen System besitzt und vereinbart ist, dass er alle Parteien und alle Transaktionen gemäß den vorher festgelegten Regeln verifiziert. Auf diese Weise sind die Benutzer nicht technisch gezwungen, alle Teile ihrer Transaktionen zu verifizieren. Das vollständige Nicht-Verifizieren ihrer Transaktionen würde jedoch den Vertrag zwischen den Benutzern und dem kryptographischen System verletzen und dadurch alle anderen Parteien des kryptographischen Systems, zum Beispiel einen Sponsor, dessen Arbeitsnehmer ohne Autorität handelt, von der Haftung entbinden. Der nicht verifizierende Empfänger würde dann alle Risiken einer solchen unverifizierten Transaktion selbst tragen. Weiterhin kann, weil der Hauptschlüssel der Systemautorität als ein Geschäftsgeheimnis angesehen wird, jemand, der nicht die Systemregelvereinbarung unterzeichnet hat, nicht eine Kopie davon besitzen und niemand könnte beanspruchen, einen Teil der Transaktion verifiziert zu haben. Das würde es für einen „außenstehenden„ Verifizierer weit schwieriger machen, zu beanspruchen, dass er einen Verlust durch „angemessenes Verlassen„ auf die Transaktion erlitten hat, selbst wenn diese tatsächlich gültig war. Diese Art des Behandelns des Systemhauptschlüssels als Geschäftsgeheimnis verleiht allen hierin beschriebenen Beschränkungs- und Autorisierungsmethoden besondere Kraft und Effektivität. Es wird angenommen, dass die Möglichkeit des Aufsichnehmens der möglicherweise hohen Haftung für wertvolle Transaktionen den Benutzer davon überzeugt, die Methoden der Attributverifizierung der vorliegenden Erfindung anzuwenden.
Beschränkungen der Zertifikatverteilung
Benutzer und Organisationen müssen in der Lage sein, die Verteilung aller Typen von Zertifikaten aus einer Anzahl von Gründen zu beschränken. Erstens enthalten die Zertifikate oft vertrauliche Geschäftsinformationen, die der Benutzer oder die Organisation nicht gern mit anderen teilen möchte, er sie aber trotzdem mit dem Verifizierer über das Zertifikat teilt, wenn auch nur für den begrenzten Zweck der Signaturverifizierung. Es können auch Basis-Persönlichkeitsrechte verletzt werden, wenn ihre öffentlichen Schlüssel und Netzwerkadressen veröffentlicht werden. So können sie zum Beispiel mit unverlangten Geschäftsvorschlägen und Anzeigen überschüttet werden, nachdem ihre öffentlichen Schlüssel verbreitet worden sind. Weiterhin kann die Organisation allgemein gegen das Vergeben von Identifizierungsnummern und öffentlichen Schlüsseln sein, weil diese als Ausgangspunkte für verschiedene Arten von Angriffen gegen die Sicherheit verwendet werden können.
Diese Funktionalität kann als ein Attribut in dem Benutzerzertifikat enthalten sein. Wenn das „Verteilungs-Beschränkungs„-Attribut WAHR ist, gewährt der Benutzer/Herausgeber die Erlaubnis, das Zertifikat (das ein Autoritätszertifikat oder ein Zertifikat für den öffentlichen Schlüssel sein kann) nur für die Signaturverifizierung zu verwenden. Eine Verteilung oder weitere Veröffentlichung ist untersagt. Andere Wege zum Spezifizieren dieser Beschränkung könnten das Anordnen des Attributs in dem Organisationszertifikat, die Veröffentlichung der Beschränkung als Teil der industriespezifischen Verfahrensweise, oder (in einer echten X.500-Implementierung) die Verwendung des X.500-Zugangskontrolllistenmechanismus zum Beschränken des Zugriffs auf das Zertifikat sein. Obwohl eine gewisse existierende, allgemeine rechtliche Basis für das Durchsetzen dieser Beschränkung im Urheberrecht gefunden werden könnte, d.h. wenn das Zertifikat als eine unveröffentlichte Arbeit erklärt wird, für die eine Lizenz nur dem namentlich genannten Verifizierer erteilt wird, ist eine festere rechtliche Basis noch erwünscht.
Smartcard-Erfordernisse
Es gibt einige zusätzliche Forderungen an Smartcards, wenn sie mit kommerziellen digitalen Signatursystemen verwendet werden.
Die erste Forderung ist die Privatschlüsselbeschränkung und die Selbstzertifizierung. Das bedeutet, dass der private Signaturschlüssel des Benutzers niemals die Smartcard verlassen darf. Nur auf diesem Weg kann gesichert werden, dass ein Diebstahl des Schlüssels nicht durch rein elektronische Mittel ohne das Zurücklassen eines Beweises durchgeführt werden kann. Dieses Einschränkungsprinzip für den privaten Schlüssel ist für das Konzept der Nicht-Zurückweisung lebenswichtig.
Somit muss, wie in 13 dargestellt, beim Bereitstellen eines öffentlichen Schlüssels, der zu zertifizieren ist, die Karte 1301 beglaubigen, dass sie fälschungssicher ist und eine den Schlüssel einschränkende Ausgestaltung aufweist. Der Nachweis kann über ein „Vorrichtungszertifikat„ 1302 zur Verfügung gestellt werden, das aussagt, dass die Karte von dem spezifischen Hersteller oder der spezifischen Produktlinie stammt. Der öffentliche Schlüssel 1308 der Vorrichtung 1301 muss dann durch den Hersteller oder durch einen durch den Hersteller benannte CA zertifiziert werden. Ein wahrscheinliches Verfahren zum Erzeugen dieses Vorrichtungszertifikats würde sein, das Schlüsselpaar der Vorrichtung während der Herstellung der Smartcard zu erzeugen, so dass das entsprechende Vorrichtungszertifikat 1302 auch auf der Karte eingeschlossen sein könnte. Das Vorrichtungszertifikat 1302 zertifiziert die Eigenschaften 1304 der Karte und die Karte erzeugt ein Schlüsselpaar 1303, 1309, das durch den Benutzer der Karte zu verwenden ist und das der Benutzer der Karte durch jede geeignete, gewünschte CA als sein eigenes zertifizieren lassen kann. Dann würde bei Vorlegen eines neu erzeugten öffentlichen Schlüssels 1303 zur Zertifizierung der private Signaturschlüssel der Vorrichtung 1303 verwendet werden, um die Anforderungsdaten des Zertifikates 1307, das bereits durch den neu erzeugten privaten Schlüssel des Benutzers 1309 signiert ist, im Schritt 1306 gegenzusignieren.
Auch in einem Fall, in dem die Leitung fordert, dass alle Entschlüsselungsschlüssel bei einem Dritten(Treuhänder) als Vertragsurkunde zu hinterlegen sind, sollte die Karte in der Lage sein zu zertifizieren, dass sie nicht entschlüsselt werden kann. Diese „Nur-Signatur„-Zertifizierung kann durch denselben, vorher angeführten Mechanismus erfolgen und es somit dem Signaturschlüssel des Benutzers erlauben, von Hinterlegungsforderungen bei einem Dritten ausgenommen zu bleiben. Weil es zweifelhaft ist, ob ein bei einem Dritten hinterlegter Schlüssel irgendeinen Wert für Nicht-Anerkennungs-Dienste enthält, ist diese Zertifizierung lebenswichtig, um zu verhüten, dass die Signaturschlüssel durch eine mögliche Falschbehandlung während des Hinterlegungsprozesses bei einem Dritten offenkundig werden.
Es sollte auch gefordert sein, Smartcards gegen unautorisierte Verwendung der persönlichen Identifizierungsnummern (PINs) zu schützen. Normalerweise ist eine Smartcard gegen unautorisierte Verwendung durch eine PIN, dem Äquivalent für ein Passwort, geschützt. Normalerweise ist eine PIN nur durch den Benutzer austauschbar und sie muss eine festgelegte Länge aufweisen. Normalerweise hindert jedoch nichts einen Benutzer daran, die PIN auf eine Trivialnummer, zum Beispiel alles Einsen oder 121212, festzulegen. Smartcardverkäufer sollten aufgefordert werden, PIN-Austausch-Routinen, die nicht-triviale PINS, ohne dass sich Zeichen oder offensichtliche Muster wiederholen, zu implementieren. Die PIN relativ lang (zumindest 6 Zeichen) und nicht-trivial zu gestalten, verringert die Chance, dass die Karte durch jemanden benutzt werden kann, der sie findet oder sie stiehlt. Hilfe in Bezug auf eine Forderung nach einer aus sechs Zeichen bestehenden PIN ist zu finden in: X9.26 Financial Institution Sign-on Authentication for Wholesale Financial Transaction (X9.26 Die Signierungs-Authentifizierung einer Finanzinstitution für finanzielle Transaktionen im Großhandel)„, ANSI, 1990, die im Fachgebiet gut bekannt ist und durch Verweis hierin einbezogen ist und die den 1:1.000.000-Standard beschreibt, der beinhaltet, dass ein Log-in-Mechanismus (Anmeldungsmechanismus) unter anderem als sicher zu betrachten ist, wenn ein Angreifer die Chance von nicht größer als 1:1.000.000 besitzt, um das korrekte Passwort zu erraten und wenn das System eine Ausweichhandlung ausführt, um ein wiederholtes Erraten zu verhindern. Ferner sollte gefordert werden, dass Smartcards „Ausweichhandlungen„ ausführen, zum Beispiel das zeitweise Abschalten oder sogar das Löschen von privaten Schlüsseln, wenn zuviele falsche PINS durch einen unautorisierten Benutzer eingegeben werden.
Es sollte weiterhin die Forderung erhoben werden, dass Smartcard-Hersteller biometrische Methoden als sicherere Methoden der Identifizierung verwenden. Gegenwärtig werden umfangreiche Arbeiten auf den Gebieten der Stimmabdruck- und Fingerabdruck-Identifizierung als Ergänzung zu den PINs durchgeführt. Jedoch liegt, wenn auch die Fälschungsraten positiv und negativ noch verringert werden müssen, das Hauptproblem in der Sicherung der biometrischen Eingabevorrichtung und ihres Datenkanals, so dass sie immun gegen ein Auffangen und Wiedergeben der biometrischen Daten sind. Das ist kein Problem, wenn die biometrische Vorrichtung in eine Betonwand, zum Beispiel in ein ATM- oder Türenzutrittssystem eingebettet ist, bleibt jedoch ein ernsthaftes Problem bei normalen kommerziellen Büroausstattungen. Idealerweise sind die Karte und die biometrische Eingabevorrichtung jeweils fälschungssichere kryptographische Module, die sich selbst zertifizieren und sichere Kanäle zueinander aufweisen.
Smartcards sollten auch in der Lage sein, einen „Nachprüfungsweg„ oder ein internes Protokoll der laufenden Aktionen aufzuweisen, zumindest eine Zeitmarke, eine Transaktionsmenge, einen Typencode und einen Nachrichtenüberblick enthaltend. Diese Informationen können in etwa 40 Bytes komprimiert werden, so dass ein Umlaufprotokoll mit 400 Aufzeichnungen etwa 16 Kbytes erfordern würde. Dieses Protokoll würde nur nach dem Empfang einer signierten Anforderung von dem Kartenherausgeber über einen Sicherheitskanal hochgeladen werden. Weiterhin würde die Karte nicht das alte Protokoll löschen, ehe sie nicht eine signierte Bestätigung von dem Herausgeber empfangen hat, die feststellt, dass das hochgeladene Protokoll empfangen worden ist. Dieser Kontrollmechanismus würde von Fälschungen abschrecken, den Schaden verringern, der durch einen Fälscher verursacht werden kann und würde es erlauben, unautorisierte oder fragliche Transaktionen schneller und bequemer zu untersuchen. Da die meisten oder alle Transaktionen offline von dem Herausgeber ablaufen, ist die Karte der beste Beweis seiner eigenen Aktionen.
Kontrolle des Zugriffs auf den öffentlichen Schlüssel der Zertifizierungsautorität der höchsten Ebene (Hauptschlüssel) und Kostenerstattung
Wie in 3 dargestellt, kann in einem speziellen kryptographischen System eine Hierarchie der Zertifizierungsautoritäten (31 bis 33), die Zertifikate 34, 35 ausgeben, vorhanden sein. In einem größeren System würden die Anzahl der Zertifizierungsautoritäten und die Tiefe der Hierarchie viel größer sein. In der in 3 dargestellten Struktur ist die Zertifizierungsautorität A (31) die Zertifizierungsautorität der höchsten Ebene (Hauptzertifizierungsautorität) und alle anderen Zertifizierungsautoritäten sind ihr untergeordnet. Wie in der Beschreibung von 3 angeführt, ist der öffentliche Schlüssel der Zertifizierungsautorität A gut bekannt. In einem System, in dem die Zertifizierungsautorität A die Haftung für alle Transaktionen in dem System übernimmt, die auf Informationen in den von A ausgegebenen Zertifikaten basieren, würde es für die Zertifizierungsautorität A (die Hauptzertifizierungsautorität) nützlich und erwünscht sein, den Zu-griff auf ihren öffentlichen Schlüssel zu kontrollieren. Wenn sie das durchführt, könnte die Zertifizierungsautorität A Regeln für das System durchsetzen, die sichern würden, dass die Struktur des Systems gut funktioniert. Verschiedene Methoden für den Zugriff auf den öffentlichen Schlüssel einer Zertifizierungsautorität werden nun beschrieben.
Bezug auf 14 nehmend, gibt in einem kryptographischen System eine Zertifizierungsautorität (CA) 1402 Benutzeridentitätszertifikate 1404 an Benutzer (zum Beispiel Benutzer 1438) des kryptographischen Systems heraus. Die Zertifizierungsautorität 1402 hat einen privaten Schlüssel 1406 und einen öffentlichen Schlüssel 1408. Der private Schlüssel 1406 wird verwendet, um die Zertifikate 1404 mit der digitalen Signatur 1410 der Zertifizierungsautorität 1402 digital zu signieren. Die Zertifizierungsautorität 1402 kann jede Zertifizierungsautorität in einer Hierarchie von Zertifizierungsautoritäten sein, beispielsweise, eine von den in 3 dargestellten.
Die Zertifizierungsautorität 1402 bestimmt die Informationen über die Benutzer des Systems und gibt auf der Basis dieser Informationen die Zertifikate 1404 an diese Benutzer aus. Ein Zertifikat 1404, ausgegeben durch die Zertifizierungsautorität 1402 an einen Benutzer 1438, enthält die Benutzerinformation 1410, die den öffentlichen Schlüssel des Benutzers 1412 und die Information über die Verfahrensweise der Zertifizierungsautorität 1414 in Bezug auf den Benutzer einschließt. Damit die in den Zertifikaten 1404 enthaltene Information durch andere Benutzer des Systems verifiziert werden kann, müssen diese anderen Benutzer Zugriff zu dem öffentlichen Schlüssel 1408 der Zertifizierungsautorität 1402 haben.
Effektiv werden die Zertifikate 1404, die durch die Zertifizierungsautoritäten ausgegeben werden, durch die Benutzer des Systems verwendet, um sich selbst gegenüber anderen Benutzern des Systems zu identifizieren, um die Transaktionen in dem System zu erleichtern. Ein Empfänger (ein Systembenutzer), der eine Transaktion 1440 von einem anderen Systembenutzer 1438 empfängt, wobei die Transaktion von einem durch die Zertifizierungsautorität 1402 ausgegebenen Zertifikat 1404 begleitet ist, kann sich auf die Information in dem Zertifikat 1404 im Wesentlichen verlassen, weil die Zertifizierungsautorität 1402, die das Zertifikat 1404 ausgegeben hat, für die Information in dem Zertifikat bürgt und die Haftung für bestimmte Transaktionen übernimmt, die auf Informationen in dem Zertifikat basieren. Wenn das Zertifikat 1404 Informationen über die Verfahrensweise 1414 der Zertifizierungsautorität einschließt, wird diese Haftung durch die Zertifizierungsautorität 1402 akzeptiert, wenn der Empfänger eine gültige Kopie des öffentlichen Schlüssels der Zertifizierungsautorität 1406 besitzt und wenn der Empfänger der Verfahrensweise gefolgt ist, die in dem Zertifikat 1404 beschrieben ist.
Nehmen wir zum Beispiel an, dass nach ihrer zufriedenstellenden Identifizierung des Benutzers A 1438, die Zertifizierungsautorität 1402 ein Zertifikat an den Benutzer A 1438 ausgibt. Das Zertifikat schließt den öffentlichen Schlüssel 1416 des Benutzers A 1438, eine Verfahrensweise 1414 der Zertifizierungsautorität 1402 in Bezug auf den Benutzer A ein und ist digital durch die Zertifizierungsautorität 1402 signiert. Nehmen wir zum Beispiel an, dass die Verfahrensweise 1414 in dem Zertifikat festlegt, dass der Benutzer A nur an Wochentagen von neun Uhr vormittags bis fünf Uhr nachmittags Eintragungen in Transaktionen ausführen darf. Ein Empfänger 1424 einer Transaktion 1440 des Benutzers A 1438 und des Zertifikats 1404 darf die Transaktion mit der Kenntnis ausführen, dass die Zertifizierungsautorität 1402 die Haftung für Transaktion übernehmen würde, wenn (a) der Empfänger durch die Verfahrensweise 1414 für die Transaktion verifiziert ist, d.h., wenn der Empfänger verifiziert, dass die Transaktion innerhalb der zulässigen zeitlichen Grenzen erfolgt, und (b) der Empfänger eine gültige Kopie des öffentlichen Schlüssels 1408 der Zertifizierungsautorität 1402 in seinem Besitz hatte. Mit anderen Worten, wenn der Empfänger die Transaktion nicht in Bezug auf die Verfahrensweise überprüft, ist die Transaktion ungültig. Weiterhin ist sogar dann, wenn ein Empfänger die Transaktion von dem Benutzer A überprüft und die Transaktion durch die Verfahrensweise der Zertifizierungsautorität in Bezug auf den Benutzer A erlaubt ist (wie sie in dem Zertifikat spezifiziert ist), die Zertifizierungsautorität 1402 nicht für die Transaktion haftbar ist, wenn der Empfänger nicht in Besitz einer gültigen Kopie des öffentlichen Schlüssels der Zertifizierungsautorität 1408 war.
Das kryptographische System kann auch verschiedene Sponsoren 1418 einbeziehen, die ebenfalls Zertifikate an Benutzer ausgeben. Diese von Sponsoren ausgegebenen Zertifikate sind auch als Autorisierungszertifikate 1420 bekannt. Diese Zertifikate 1420 dienen, unter anderem, dazu, die Regeln oder Verfahrensweisen des sie ausgebenden Sponsors festzulegen. Diese Autorisierungszertifikate 1420 können getrennt von den von den Zertifizierungsautoritäten ausgegebenen Identitätszertifikaten 1404 sein und können sich von diesen unterscheiden (obwohl die Identitätszertifikate Verfahrensweiseforderungen der Zertifizierungsautoritäten enthalten können). Ein Benutzer kann nur ein durch eine Zertifizierungsautorität ausgegebenes Identitätszertifikat 1404 haben. Ein Benutzer kann jedoch zahlreiche Autorisierungszertifikate 1420 haben, die von einem Sponsor oder von mehreren Sponsoren 1418 ausgegeben sind.
Wenn ein Empfänger eine Transaktion von einem anderen Benutzer des Systems empfängt, sollte er auch alle Sponsorverfahrensweisen des Sponsors verifizieren, die in den Autorisierungszertifikaten in der Transaktion dieses Benutzers eingeschlossen sind. Somit werden in diesem kryptographischen System die Benutzer aufgefordert, die Regeln (Verfahrensweisen) der Zertifizierungsautoritäten und Sponsoren in dem System durchzusetzen.
Wie vorher angeführt, müssen, um die Informationen zu erhalten, die in den verschiedenen, von den Benutzern des Systems zu verifizierenden Zertifikaten enthalten sind, diese Benutzer Zugriff zu dem öffentlichen Schlüssel 1408 der Zertifizierungsautorität 1402 oder des Sponsors 1418, der die verschiedenen Zertifikate ausgegeben hat, haben. Um die Regeln jeder Zertifizierungsautorität und jedes Sponsors in dem System durchzusetzen, ist es erforderlich, den Zugriff auf den öffentlichen Schlüssel 1408 einiger der Zertifizierungsautoritäten zu beschränken. Insbesondere ist es erforderlich, den Zugriff auf den öffentlichen Schlüssel der Zertifizierungsautorität der höchsten Ebene 1402 (Hauptautorität) zu beschränken.
Daher behandelt die Hauptzertifizierungsautorität 1402 ihren öffentlichen Schlüssel als Geschäftsgeheimnis, und um den öffentlichen Schlüssel der Zertifizierungsautoritäten 1402 zu erhalten, muss ein Benutzer (ein möglicher Empfänger) 1424, der Transaktionen in dem System ausführen möchte, die Regeln der Zertifizierungsautorität 1426 erhalten, die durch die Hauptzertifizierungsautorität herausgegeben werden. Der Empfänger 1424 muss diese Regeln nach der Hash-Funktion kodieren, um eine Hash-kodierte Form der Regeln 1428 zu erzeugen, die er dann digital signieren muss, um eine signierte Kopie der Hash-kodierten Regeln 1430 zu erzeugen. Diese digital signierte Kopie der Hash-kodierten Regeln muss zu der Hauptzertifizierungsautorität 1402 zurückgesendet werden. Durch diese Handlungen erklärt sich der Empfänger 1424 damit einverstanden, sich an die Regeln der Zertifizierungsautorität 1402 zu halten, die er gerade signiert hat. Die Hauptzertifizierungsautorität 1402 kann weiterhin fordern, dass der Empfänger 1424 auch Regeln von anderen Zertifizierungsautoritäten in dem System sowie von Sponsoren in dem System erhalten, signieren und zurücksenden muss. Es kann zum Beispiel auch gefordert werden, dass der Empfänger 1424 Regeln des Sponsors 1432 von dem Sponsor 1418 erhalten und eine signierte Kopie dieser Regeln 1434 an den Sponsor 1418 zurückzusenden hat.
Nachdem die Hauptzertifizierungsautorität 1402 anerkannt hat, dass sie eine gültige Kopie der durch den Empfänger signierten Systemregeln erhalten hat, gibt sie den öffentlichen Schlüssel 1408 an den Empfänger 1424 aus.
Der öffentliche Schlüssel der Hauptzertifizierungsautorität 1408 kann auf verschiedenen Wegen an einen Empfänger gegeben werden. In bevorzugten Ausführungen erhält der Empfänger eine Sicherheitsvorrichtung 1436, beispielsweise eine Smartcard. In einer bevorzugten Ausführung steht der öffentliche Schlüssel der Hauptzertifizierungsautorität 1408 direkt in der Sicherheitsvorrichtung zur Verfügung, so dass, nachdem der Empfänger 1424 die Vorrichtung erhalten hat, er auch den öffentlichen Schlüssel der Hauptzertifizierungsautorität 1408 besitzt. In einer anderen bevorzugten Ausführung befindet sich der öffentliche Schlüssel der Zertifizierungsautorität 1408 in einer gesperrten Form in der Vorrichtung 1436 und die Hauptzertifizierungsautorität 1402 gibt den Schlüssel 1408 in der Vorrichtung nach Empfang und Verifizierung der signierten Regeln 1430 frei.
In einigen Fällen ist es für den öffentlichen Schlüssel der Hauptzertifizierungsautorität 1408 in der Vorrichtung 1436 nützlich, dass er nach einer bestimmten Zeitspanne abläuft oder auf ihn kein Zugriff mehr besteht. In diesen Fällen muß der Empfänger 1424 erneut die Regeln der Hauptzertifizierungsautorität 1402 erhalten, signieren und zurücksenden, damit die Hauptzertifizierungsautorität den Schlüssel 1408 reaktiviert. Diese Regeln müssen sich von den früher signierten Regeln unterscheiden.
Die verschiedenen Zertifizierungsautoritäten, einschließlich der Hauptzertifizierungsautorität, können auch fordern, dass andere Bedingungen durch mögliche Empfänger eingehalten werden, um ihnen Zugriff auf die öffentlichen Schlüssel dieser Zertifizierungsautoritäten zu geben. Jedoch sind die in das System eingeschlossenen Regeln eine Einverständniserklärung eines die Regeln Signierenden, dass er sie geheim hält.
Kostenerstattung
Die Regeln können auch eine Vereinbarung enthalten, die Benutzung des Systems zu bezahlen. Somit können, wenn ein Benutzer einen gültigen Schlüssel erhält (durch Vereinbaren sich an die Regeln der Haupt-CA des Systems zu halten), diese Regeln eine Vereinbarung durchsetzen, mit dem Bezahlungsschema des Systems einverstanden zu sein.
Ein kryptographisches System kann den Betrieb des Systems mit einer zugehörigen Bezahlung durch die Benutzer des Systems für die Transaktionen, die sie ausführen und akzeptieren, verbinden. Die Bezahlung für eine Transaktion erfolgt zum Beispiel in Form eines Vorauszahlungs-Kontos, einer Vereinbarung über die Rechnungsstellung oder in Form einer gleichzeitigen digitalen Barzahlung an verschiedene Parteien in dem System. So kann zum Beispiel eine spezielle Operation, beispielsweise das digitale Signieren einer Transaktion, den Benutzer einen bestimmten, an die Zertifizierungsautorität, welche das Zertifikat ausgegeben hat, das die Benutzeridentität garantiert, zu zahlenden Betrag kosten.
Einige digitale Zahlungsfunktionen können in die Vorrichtungen eingebaut werden, welche die öffentlichen Schlüssel enthalten. Da die privaten Schlüssel der Benutzer normalerweise in den Sicherheitsvorrichtungen (beispielsweise Smartcards) enthalten sind, können die Sicherheitsvorrichtungen verwendet werden, um eine laufende digitale Bilanz für jeden Benutzer aufzustellen. Diese digitale Bilanz kann ein Belastungs- oder ein Kreditbetrag sein. Jedes Mal, wenn ein Benutzer eine Transaktion unter Verwendung seiner Sicherheitsvorrichtung digital signiert, wird ein bestimmter Betrag von dieser digitalen Bilanz des Benutzers abgezogen. Wenn die Sicherheitsvorrichtung eine das Konto belastende Vorrichtung ist, würde, wenn die digitale Bilanz des Benutzers Null erreicht, die Vorrichtung gesperrt werden und nicht mehr länger in der Lage sein, für den Benutzer zu signieren. Der Benutzer müsste dann einen weiteren digitalen Kredit von der Zertifizierungsautorität oder von einem anderen Sponsor in dem System erhalten. Wenn andererseits die Sicherheitsvorrichtung eine Kreditvorrichtung ist, würde der Benutzer dann aufgefordert werden, in bestimmten, regelmäßigen Abständen, zum Beispiel täglich, wöchentlich oder monatlich, eine Zahlungstransaktion an die Zertifizierungsautorität auszuführen. Da der digitale Kreditbetrag von der Sicherheitsvorrichtung zur Verfügung steht, könnte die Zertifizierungsautorität sicher sein, dass die Transaktion für den korrekten Betrag ausgeführt wird. Ein Benutzer, der die geforderte Zahlungstransaktion nicht ausführt, würde in der CRL (Zertifikatwiderrufliste) als ausgesetzt oder widerrufen angeführt werden und würde nicht mehr in der Lage sein, Transaktionen in dem System auszuführen.
Die digitale Zahlung auf einer Basis der Bezahlung pro Transaktion wird ebenfalls unter Verwendung einer Bestätigungstransaktion erreicht. Das Autorisierungszertifikat des Benutzers würde die Bestätigungsadresse des Zahlungsempfängers aufführen. Wenn die Transaktion vor sich geht, wird der Bezahlungsempfänger benachrichtigt und kann die Zahlung von dem Konto des Benutzers abziehen.
Preisinformation
Da ein Benutzer sein Einverständnis erklärt hat, Gebühren und Lizenzgebühren, die dem System zugehörig sind, zu zahlen, kann er auch flexible Preis- und Rechnungsinformationen erhalten.
Benutzerspezifische Preisgestaltungen können unter Verwendung der Zertifikate vorgenommen werden. Von Sponsoren und Zertifizierungsautoritäten ausgegebene Zertifikate können die Zahlungs- und Preisbildungsgestaltung für bestimmte Benutzer einschließen. So könnte zum Beispiel ein Zertifikat eine Preisliste für bestimmte Transaktion einschließen (einschließlich beispielsweise des Signierens unter Verwendung eines Privatschlüssels, Verifizieren unter Verwendung eines speziellen öffentlichen Schlüssels oder Prüfen des Widerrufstatus eines speziellen Zertifikats), einen Rabattsatz für spezielle Benutzer, einen Rabattsatz für Transaktionen mit bestimmten Empfängern und Rabattsätzen für umfangreiche Transaktionen. Einige Rechnungslegungen werden durch die Sicherheitsvorrichtungen der Benutzer ausgeführt, während andere in Rechnung zu stellende Ereignisse sich aus Aktionen ergeben können, die durch Empfänger von Transaktionen durchgeführt werden.
Um bestimmte Preisgestaltungen implementieren zu können, kann ein Zertifikat verschiedene digitale Felder enthalten. Für einige Gestaltungen beinhalten diese Felder eine Widerruf-Serviceadresse, eine Widerruf-Servicegebühr und eine Transaktion-Bestätigungsgebühr. Die Widerruf-Serviceadresse gleicht der Bestätigungsadresse, wird jedoch nur verwendet, um die Gültigkeit der Zertifikate zu bestätigen. Das bedeutet, dass Widerruf-Servicefilter für versuchte Transaktionen vorhanden sind, die auf zurückgezogenen Zertifikaten basieren. Die Widerruf-Servicegebühr ist die für diesen Service erhobene Gebühr.
Beispiele dieser Felder sind:

(a) Signiergebühr für den privaten Schlüssel = 0,50 $
(b) Verifizierungsgebühr für den öffentlichen Schlüssel = 0,50 $
(c) Widerruf-Serviceadresse = rev-check @btec.com
(d) Widerruf-Servicegebühr = 0,50 $
(e) Bestätigungs-Servicegebühr = 0,50 $

Alle Gebühren können als Pauschalgebühren oder als eine Gebühr für eine bestimmte Basistransaktionsmenge festgelegt sein. So kann zum Beispiel eine Gebühr als „0,50 $„ oder als „0,50 $ pro 1000 $ Basistransformationsmenge„ spezifiziert sein.
Die vorher angeführten Beispiele annehmend, könnte ein Empfänger, der eine Transaktion empfängt, die zugehörigen Zertifikate an die Widerruf-Serviceadresse senden und ihm würde ein Betrag in Höhe der festgelegten Servicegebühr in Rechnung gestellt werden.
Um eine Bestätigungstransaktion zu berechnen, kann ein Zertifikat auch eine Transaktions-Bestätigungsgebühr enthalten, zum Beispiel
Transaktionsbestätigungsgebühr = (0,50 $ für eine Transaktionsmenge von 1000 $)
In diesem Fall würde jede bestätigte Transaktion den Empfänger die entsprechende Gebühr kosten.
In einigen Fällen kann ein Empfänger eine Transaktion empfangen, die zu teuer ist und die er daher ablehnen möchte. Daher ist auch ein digitales Feld vorhanden, das die Erlaubnis für die Rechnungsstellung an den Absender erteilt, wobei das Feld durch den Absender signiert wird. Dieses Feld könnte die Kontonummer des Absenders und andere Informationen enthalten, einschließlich eines annehmbaren Satzes für die Rechnungsstellung. Dieses „Rechnung-Absender„-Feld würde als ein Attribut in dem Signaturblock des Absenders erscheinen.
Lizensierung des geistigen Eigentums
Die Regeln können auch eine Vereinbarung enthalten, für das gesamte durch einen Benutzer genutzte geistige Eigentum zu zahlen. So kann zum Beispiel ein System einem Benutzer patentierte Transaktionen, Serviceleistungen oder Algorithmen, urheberrechtlich geschützte Materialien u.ä. anbieten. Damit ein Benutzer einen öffentlichen Schlüssel erhalten kann, der den Zugriff auf dieses geistige Eigentum ermöglichen würde, muss der Benutzer die Benutzerregeln signieren, die die Vereinbarung enthalten, für die Nutzung dieses Eigentums zu zahlen.
So enthält zum Beispiel in einer Ausführung die Sicherheitsvorrichtung viele nicht aktivierte Dienstleistungen (für die eine Bezahlung gefordert wird). Jede Nutzung einer dieser Dienstleistungen erfordert eine Bezahlung, beispielsweise in Form digitaler Barzahlung, entweder durch eine interne Transaktion in der Vorrichtung oder durch eine Transaktion mit einem anderen Benutzer des Systems. Um die Vorrichtung zu erhalten, muss der Benutzer digital einen Satz von Regeln signieren (unter Verwendung eines privaten Schlüssels in der Vorrichtung, der für die Vorrichtung und somit für den Benutzer eindeutig ist). Durch Signieren dieser Regeln gibt der Nutzer sein Einverständnis, die Zahlungen, wie gefordert, zu leisten.
Vom Signierenden auferlegte Verfahrensweisen und Regeln
Ein Benutzer eines kryptographischen Systems kann ein Identifizierungszertifikat (von einer CA ausgegeben) und ein Autorisierungszertifikat oder mehrere Autorisierungszertifikate (ausgegeben von CAs oder Sponsoren dieses Benutzers) haben. Jedes dieser Zertifikate enthält Verfahrensweisen der ausgebenden Partei und von einem Empfänger einer Transaktion, die irgendeines dieser Zertifikate einschließt, wird erwartet, dass er verifiziert, dass die Transaktion allen Regeln Folge leistet, die in den Zertifikaten spezifiziert sind. Es kann jedoch der Fall sein, dass für eine spezielle Transaktion ein Benutzer es wünscht, dass mehr einschränkende Regeln zur Anwendung kommen, als die in den Zertifikaten zugelassenen. So kann es zum Beispiel der Fall sein, dass ein Benutzer alle Transaktionen von 1 Million $ oder weniger zugelassen haben möchte, es jedoch wünscht, eine bestimmte Transaktion nur zuzulassen, wenn ihr Wert weniger als 1000 $ beträgt.
Alternativ kann es einem Benutzer erlaubt sein, bestimmte Transaktionen allein zu genehmigen, es jedoch wünschen, für eine spezifische Transaktion, einen oder mehrere Kosignierende zu fordern. Zur Unterstützung dieses Merkmals stellt das kryptographische System der vorliegenden Erfindung den Benutzern die Möglichkeit zur Verfügung, den Transaktionen Benutzerregeln, Attribute und Beschränkungen hinzuzufügen.
Die Benutzerregeln dürfen keine Transaktionen genehmigen, die ansonsten nicht erlaubt sind. Daher muss ein Empfänger immer die restriktivsten Regeln für jede Transaktion anwenden. Wenn zum Beispiel ein Benutzerzertifikat Transaktionen bis zu 1000 $ erlaubt und die Benutzerregeln Transaktionswerte von bis zu 1 Million $ spezifizieren, ist klar, dass die Grenze von 1000 $ gelten sollte. Das kann zum Beispiel erreicht werden, wenn der Empfänger zuerst alle Regeln der Zertifikate anwendet und dann, wenn die Transaktion noch gültig ist, alle Benutzerregeln anwendet. Die Anwendung der Benutzerregeln zuerst und darauf der Zertifikatregeln erzeugt ebenfalls ein korrektes Resultat. Da jedoch Boolesche Kombinationen der Regeln und der Beschränkungen unterstützt werden, kann ein Verschachteln der Benutzerregeln und der Zertifikatregeln ein unkorrektes Resultat liefern, wenn es nicht sorgfältig durchgeführt wird.
15 zeigt das Verifizieren einer Benutzertransaktion, die vom Benutzer gelieferte Regeln einschließt. Eine Benutzertransaktion 1502 enthält den Transaktionstext 1506, der die durch einen Empfänger durchzuführende Transaktion beschreibt. Der Benutzer hängt an den Transaktionstext 1506 einen Satz vom Benutzer gelieferter Regeln 1504 an, die der Benutzer von jedem Empfänger der Transaktion 1502 zu verifizieren wünscht. Darauf signiert der Benutzer digital die Kombination des Transaktionstextes 1506 und der Regeln 1504, um die Transaktion 1502 zu bilden, welche die Benutzersignatur 1510 bildet, die an die Transaktion angehängt ist.
Die Transaktion 1506 wird dann zusammen mit allen erforderlichen Sponsor- und/oder CA-Zertifikaten, zum Beispiel mit dem CA-Zertifikat 1508 und dem Sponsorzertifikat 1509, an einen Empfänger abgesendet, der dann die Transaktion verifizieren muss. Um das durchzuführen, verifiziert im Schritt 1512 der Empfänger die Benutzersignatur 1510 unter Verwendung des öffentlichen Schlüssels des Benutzers 1514 aus dem CA-Zertifikat 1508. Wenn die Benutzersignatur akzeptiert wird, wird die Verifizierung fortgesetzt. Wenn nicht, wird die Transaktion in Schritt 1514 zurückgewiesen. Wenn die Verifizierung fortgesetzt wird, verifiziert der Empfänger in Schritt 1516 die CA-Signatur 1518 unter Verwendung des öffentlichen Schlüssels der CA 1520. Wenn die CA-Signatur akzeptiert wird, wird die Verifizierung in Schritt 1522 durch Überprüfung der Regeln in allen Zertifikaten und der durch den Benutzer gelieferten Regeln, einschließlich des Sponsorzertifikats 1509, fortgesetzt. Wenn nicht, wird die Transaktion in Schritt 1514 zurückgewiesen. Wenn die Verifizierung fortgesetzt wird, verifiziert der Empfänger in Schritt 1522 die Transaktion gegenüber den Regeln in dem CA-Zertifikat 1508, dem Sponsorzertifikat 1509 (und in allen anderen Zertifikaten, die dieser Transaktion zugehörig sind). Wenn irgendeine dieser Regeln nicht eingehalten ist, wird die Transaktion in Schritt 1514 zurückgewiesen. Wenn die Regeln eingehalten sind, wird die Verifizierung der Transaktion mit ihrer Verifizierung in Bezug auf die durch den Benutzer gelieferten Regeln 1504 fortgesetzt. Nur wenn die Transaktion den von dem Benutzer gelieferten Regeln 1504 genügt, wird sie in Schritt 1526 akzeptiert, wenn nicht, wird sie in Schritt 1514 zurückgewiesen.
Die von dem Benutzer gelieferten Regeln 1504 können alle Kombinationen der dem System bekannten Regeln sein, einschließlich, jedoch nicht darauf beschränkt, Kosignaturerfordernisse, zeitliche Begrenzungen, Transaktionswertbeschränkungen und Ähnliches.
In einigen Umgebungen dürfen Benutzer Sätze von Regeln oder Sonderregeln für sich selbst für die Verwendung bei bestimmten Arten von Benutzern oder Transaktionen erzeugen. Diese Sätze von Regeln oder Sonderregeln können automatisch an allen Transaktionen von diesen Benutzerarten oder Transaktionen angebracht werden. So kann zum Beispiel ein Benutzer, der ein Bankmanager ist, festlegen (aus Erfahrung), dass für alle Transaktionen, die von neuen Bankkassierern durchgeführt werden und die er gegenzeichnet, restriktivere Regeln gelten, als die Bank sie fordert. Die Bank würde diese Regeln dann in ihrem System als Sonderregeln für die Arten von Transaktionen, die er signiert oder kosigniert, speichern.
Fachleute werden erkennen, dass die vorliegende Erfindung normalerweise unter Verwendung elektronischer Vorrichtungen, beispielsweise von elektronischen Computern und Ähnlichem, praktiziert wird, und dass die Zertifikate, Transaktionen, Nachrichten, Signaturen und Ähnliches digitale elektronische Signale sind, die durch die elektronischen Vorrichtungen erzeugt und zwischen den elektronischen Vorrichtungen übertragen werden.
Somit wird ein Verfahren für die sichere Verwendung digitaler Signaturen in einem kommerziellen kryptographischen System zur Verfügung gestellt. Fachleute werden erkennen, dass die vorliegende Erfindung durch andere als die beschriebenen Ausführungen, die zum Zweck der Erläuterung und nicht der Einschränkung vorgestellt sind, praktiziert werden kann, und dass die vorliegende Erfindung nur durch die nachfolgenden Ansprüche beschränkt ist.

Claims

Verfahren zum Durchsetzen einer Politik in einem kryptographischen Kommunikationssystem welches umfasst das Erzeugen einer digitalen Nachricht (20) durch einen Benutzer, das Erstellen einer digitalen Benutzersignatur (25) basierend auf der digitalen Nachricht und einem privaten Schlüssel (23) des Benutzers, und das Kombinieren der digitalen Nachricht und der digitalen Benutzersignatur, um eine digitale Benutzertransaktion (51) zu bilden, gekennzeichnet durch: Kombinieren der digitalen Benutzertransaktion mit einem digitalen Identifizierungszertifikat (55, 56), das durch eine Zertifizierungsautorität (31, 32) ausgegeben wird, wobei das Identifizierungszertifikat eine Anzahl von digitalen Feldern besitzt, von denen mindestens eines der Felder den Benutzer identifiziert; und Kombinieren der digitalen Benutzertransaktion mit mindestens einer Benutzerregel (58), wobei die mindestens eine Benutzerregel Bedingungen festlegt, unter denen die digitale Benutzertransaktion gültig ist, und Spezifizieren von mindestens einem von: (a) einem erlaubten Dokumententyp der Transaktion (805), (b) einer erlaubten Lokation, an der die Transaktion gemacht werden kann (906), (c) einer erlaubten Zeit, zu der die Transaktion gebildet werden kann (906), (d) einer Zeitspanne, in der die Signatur gültig ist (108), (e) einer Rolle, die der Benutzer ausüben kann, (f) einen Empfänger der Transaktion, der als Sponsor für den Benutzer akzeptabel ist oder für die Zertifizierungsautorität (1121, 1123), (g) ein Sponsor für den Benutzer muss über die Transaktion benachrichtigt werden und sie genehmigen (1204), und (h) jemand oder etwas muss über die Transaktion benachrichtigt werden.
Verfahren nach Anspruch 1, wobei mindestens eines der Felder mindestens eine Benutzerregel (58) umfasst, die eine Bedingung festlegt, unter der die digitale Benutzertransaktion (51) gemäß der Zertifizierungsautorität (31, 32) gültig ist, wobei die mindestens eine Benutzerregel, die anzulegen ist, dazu dient, zu bestimmen ob die digitale Benutzertransaktion gültig ist.
Verfahren nach Anspruch 1 oder 2, ferner gekennzeichnet: Kombinieren der digitalen Benutzertransaktion (51) mit einem digitalen Autorisierungszertifikat (56), das von dem Identifizierungszertifikat (55) getrennt ist und durch einen Sponsor des Benutzers zur Autorisierung von Transaktionen durch den Benutzer ausgegeben wird.
Verfahren nach Anspruch 3, wobei das digitale Autorisierungszertifikat (56) zumindest eine Benutzerregel (58) umfasst, die Bedingungen angibt, unter denen die digitale Benutzertransaktion gültig ist, um an die digitale Nachricht angelegt zu werden, um zu bestimmen, ob die digitale Benutzertransaktion (51) gültig ist.
Verfahren nach Anspruch 3, wobei die digitale Benutzertransaktion (51) zugeordnete Daten (57) umfasst und wobei das digitale Autorisierungszertifikat (56) die mindestens eine Benutzerregel (58) aufweist, welche Bedingungen angibt, unter denen die digitale Benutzertransaktion gültig ist, um an die zugeordneten Daten angelegt zu werden und um zu bestimmen, ob die digitale Benutzertransaktion gültig ist.
Verfahren nach einem der Ansprüche 3 bis 5, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel angibt, dass der Sponsor darüber informiert werden muss und dass er die digitale Benutzertransaktion (1204) gutheißen muss; und die digitale Benutzertransaktion ungültig ist, solange nicht der Sponsor von der digitalen Benutzertransaktion (1214) benachrichtigt ist.
Verfahren nach Anspruch 6, wobei die digitale Benutzertransaktion ungültig ist, sofern nicht auf Benachrichtigung über die digitale Benutzertransaktion der Sponsor die digitale Benutzertransaktion (1216) gutheißt.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion eine Zeitmarke (903) umfasst, die angibt, wann die digitale Benutzertransaktion gebildet worden ist; die mindestens eine Benutzerregel eine oder mehrere erlaubte Zeiten angibt, zu denen die Transaktionen gemacht werden könnten (906); und die digitale Benutzertransaktion ungültig ist, falls die Zeitmarke nicht eine der angegebenen erlaubten Zeiten (924) anzeigt.
Verfahren nach Anspruch 1, wobei die eine oder mehreren erlaubten Zeiten einen oder mehrere bestimmte Tage der Woche einschließen und wobei die digitale Benutzertransaktion ungültig ist, wenn die Zeitmarke anzeigt, dass die digitale Benutzertransaktion nicht an einem der bestimmten Tage der Woche (924) gemacht worden ist.
Verfahren nach Anspruch 8 oder 9, wobei die eine oder mehreren zulässigen Zeiten ein oder mehrere bestimmte Zeiten des Tages umfassen und wobei die digitale Benutzertransaktion ungültig ist, wenn die Zeitmarke anzeigt, dass die digitale Benutzertransaktion nicht zu einer der bestimmten Zeiten des Tages (924) gemacht wurde.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion (51) Daten über eine oder mehrere Rollen umfasst, die der Benutzer ausübt, indem die digitale Benutzertransaktion durchgeführt wird; die mindestens eine Benutzerregel eine oder mehrere zulässige Rollen angibt, die der Benutzer ausüben kann; und die digitale Benutzertransaktion ungültig ist, wenn die eine oder mehreren Rollen, die der Benutzer ausübt, nicht eine der angegebenen erlaubten Rollen ist.
Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion einen Dokumententyp der Nachricht (802) umfasst; die mindestens eine Benutzerregel eine oder mehrere erlaubten Dokumententypen für die Nachricht (805) angibt; und die digitale Benutzertransaktion ungültig ist, wenn der Dokumententyp nicht einer der festgelegten erlaubten Dokumententypen (808) ist.
Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion (51) Daten über eine Lokation umfasst, an der die digitale Benutzertransaktion gebildet wurde; die mindestens eine Benutzerregel eine oder mehrere zulässige Lokationen angibt, an denen Transaktionen gebildet werden, können; und die digitale Benutzertransaktion ungültig ist, wenn die Lokation nicht eine der bezeichneten erlaubten Lokationen ist.
Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion eine Zeitmarke (103) umfasst, die angibt, wann die digitale Benutzertransaktion gebildet wurde; die zumindest eine Benutzerregel eine Zeitspanne festlegt, in der die Signatur gültig ist (108); und die digitale Benutzertransaktion ungültig ist, wenn die Signatur nicht innerhalb der festgelegten Zeitspanne (123) verifiziert worden ist.
Verfahren nach Anspruch 14, wobei die festgelegte Zeitspanne ein maximal zulässiges Alter der Signatur (108) definiert und die digitale Benutzertransaktion ungültig ist, wenn die Signatur nicht verifiziert worden ist, bevor die Signatur ihr erlaubtes zulässiges maximales Alter (123) erreicht hat.
Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel festlegt, dass eine bestimmte Größe über die digitale Benutzertransaktion (1214) benachrichtigt werden muss; und die digitale Benutzertransaktion ungültig ist, sofern nicht die bezeichnete Größe davon benachrichtigt wurde und die digitale Benutzertransaktion (1216) gutgeheißen hat.
Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel (58) mindestens einen Empfänger für die digitale Benutzertransaktion (51) fest legt, der durch die Zertifizierungsautorität (31, 32) als akzeptabel angesehen wird; und die digitale Benutzertransaktion ungültig ist, wenn sie von einem Empfänger bearbeitet wird, der nicht der bezeichnete mindestens eine Empfänger ist.
Verfahren nach Anspruch 1, gekennzeichnet durch: Kombinieren der mindestens einen Benutzerregel (1504) mit der digitalen Nachricht (1506); Erstellen der digitalen Benutzersignatur (1510) basierend auf der digitalen Nachricht, der mindestens einen Benutzerregel und dem privaten Schlüssel des Benutzers; und Kombinieren der digitalen Nachricht, der mindestens einen Benutzerregel und der digitalen Benutzersignatur, um die digitale Benutzertransaktion (1506) zu machen.
Verfahren zum Durchsetzen einer Politik in einem kryptographischen Kommunikationssystem durch Aufnehmen einer digitalen Benutzertransaktion (51) einschließend eine digitale Nachricht (20) und eine digitale Benutzersignatur (25) basierend auf der digitalen Nachricht und auf einem privaten Schlüssel (23) eines Benutzers, gekennzeichnet durch: Empfangen von mindestens einer Benutzerregel (58), die Bedingungen festlegt, unter denen die Transaktion gültig ist und die spezifiziert mindestens eines von: (a) einem erlaubten Dokumententyp der Transaktion (805), (b) einer erlaubten Lokation, an der die Transaktion gebildet werden kann (906), (c) einer erlaubten Zeit, zu der die Transaktion gebildet werden kann (906), (d) einer Zeitspanne, in der die Signatur gültig ist (108), (e) einer Rolle, die der Benutzer ausüben kann, (f) einem Empfänger der Transaktion, der als Sponsor für den Benutzer akzeptabel ist oder für die Zertifizierungsautorität (1121, 1123), (g) ein Sponsor für den Benutzer muss über die Transaktion benachrichtigt werden und sie genehmigen (1204), und (h) eine Größe muss über die Transaktion benachrichtigt werden; Empfangen eins digitalen Identifizierungszertifikat (55, 56), das von einer Zertifizierungsautorität (31, 32) ausgegeben wird und dass eine Anzahl von digitalen Feldern hat, von denen mindestens eines den Benutzer identifiziert; Verifizieren der Transaktion basierend auf der Information in dem Identifizierungszertifikat und in der mindestens einen Benutzerregel; und Akzeptieren der Transaktion basierend auf dem Ergebnis der Verifizierung.
Verfahren nach Anspruch 19, wobei mindestens eines der Felder mindestens eine Benutzerregel (58) umfasst, die eine Bedingung festlegt, unter der die digitale Benutzertransaktion (51) gemäß der Zertifizierungsautorität (31, 32) gültig ist, wobei die mindestens eine Benutzerregel, die anzulegen ist, dazu dient, zu bestimmen ob die digitale Benutzertranskation gültig ist.
Verfahren nach Anspruch 19 oder 20, ferner gekennzeichnet durch: Empfangen eines digitalen Autorisierungszertifikats (56) getrennt von dem Identifizierungszertifikat (55) und Ausgegeben von einem Sponsor für den Benutzer sowie Autorisierungstransaktionen durch den Benutzer; und der Verifizierungsschritt umfasst das Verifizieren der Transaktion basierend auf Information in dem Autorisierungszertifikat.
Verfahren nach Anspruch 21, gekennzeichnet durch: das digitale Autorisierungszertifikat (56) umfasst mindestens eine Benutzerregel (58), die Bedingungen identifi ziert, unter denen die digitale Transaktion (51) gültig ist; und der Verifizierungsschritt umfasst das Anlegen von mindestens einer Benutzerregel an die digitale Nachricht, um festzustellen, ob die Transaktion gültig ist.
Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion Attributdaten (57) umfasst; das digitale Autorisierungszertifikat (56) umfasst mindestens eine Benutzerregel (58) umfasst, die Bedingungen identifiziert, unter denen die digitale Transaktion gültig ist; und der Verifizierungsschritt umfasst das Anlegen von mindestens einer Benutzerregel an die Attributdaten, um festzustellen, ob die Transaktion gültig ist.
Verfahren nach einem der Ansprüche 21 bis 23, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel festlegt, dass der Sponsor benachrichtigt und die digitale Benutzertransaktion (1204) gutgeheißen werden muss; der Sponsor von der Transaktion (1214) benachrichtigt wird; und dass auf eine Antwort vom Sponsor gewartet wird.
Verfahren nach Anspruch 24, wobei: der Benachrichtigungsschritt das Senden der Transaktion an den Sponsor umfasst, und wobei der Sponsor die Genehmigung der Transaktion andeutet, indem er an den Empfänger eine Bestätigungstransaktion zurückschickt, die von dem Sponsor gebildet wird, indem die gesendete Transaktion digital signiert wird (1216); und wobei der Verifizierungsschritt ferner das Empfangen einer Antwort von dem Sponsor und das Entscheiden umfasst, ob die Antwort eine Bestätigungstransaktion ist, die von dem Sponsor unterzeichnet ist.
Verfahren nach einem der Ansprüche 19 bis 25, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion eine Zeitmarke (903) umfasst, die angibt, wann die digitale Benutzertransaktion gebildet worden ist; die mindestens eine Benutzerregel eine oder mehrere erlaubte Zeiten angibt, zu denen die Transaktionen gemacht werden könnten (906); und der Verifizierungsschritt das Feststellen umfasst, ob die Zeitmarke darauf hinweist, dass es sich um die festgelegten erlaubten Zeiten (924) handelt.
Verfahren nach Anspruch 26, wobei die eine oder mehreren erlaubten Zeiten einen oder mehrere bestimmte Tage der Woche umfassen und wobei der Verifizierungsschritt das Feststellen umfasst, ob die Zeitmarke darauf hinweist, dass die Transaktion an einem der bestimmten Tage der Woche (924) durchgeführt worden ist.
Verfahren nach Anspruch 26 oder 27, wobei die eine oder mehreren erlaubten Zeiten eine oder mehrere bestimmte Zeiten des Tages umfasst und wobei der Verifizierungsschritt die Entscheidung umfasst, ob die Zeitmarke darauf hinweist, dass die Transaktion zu einer der bestimmten Zeiten des Tages (924) durchgeführt worden ist.
Verfahren nach einem der Ansprüche 19 bis 28, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion (51), die Daten über eine oder mehrere Benutzerrollen enthält, durchgeführt wird, indem die digitale Benutzertransaktion ausgeführt wird; die mindestens eine Benutzerregel eine oder mehrere zulässige Rollen an gibt, die der Benutzer ausüben kann; und der Verifizierungsschritt das Entscheiden umfasst, ob die eine oder mehreren Rollen, die der Benutzer ausübt, eine der festgelegten erlaubten Rollen ist.
Verfahren nach einem der Ansprüche 19 bis 29, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion einen Dokumententyp der Nachricht (802) umfasst; die mindestens eine Benutzerregel eine oder mehrere zulässige Dokumententypen für die Nachricht (805) fest legt; und der Verifizierungsschritt das Ermitteln umfasst, ob der Dokumententyp einer der festgelegten zulässigen Dokumententypen (808) ist.
Verfahren nach einem der Ansprüche 19 bis 30, dadurch gekennzeichnet, dass: die digitale Benutzertransaktion (51) Daten über eine Lokation umfasst, an der die digitale Benutzertransaktion gebildet wurde, die mindestens Benutzerregel eine oder mehrere zulässige Lokationen fest legt, an denen die Transaktionen hergestellt werden können; und der Verifizierungsschritt das Ermitteln umfasst, ob die Lokation eine der festgelegten zulässigen Lokationen ist.
Verfahren nach einem der Ansprüche 19 bis 31, dadurch gekennzeichnet, dass: die Transaktion eine Zeitmarke (103) umfasst, die angibt, wann die Transaktion gemacht wurde; mindestens eine Benutzerregel eine Zeitspanne an gibt, in der die Signatur gültig ist (108); und der Verifizierungsschritt das Verifizieren der Signatur und das Ermitteln umfasst, ob die Verifizierung der Signatur innerhalb oder nach der vorgegebenen Zeitspanne (123) erfolgt ist.
Verfahren nach Anspruch 32, wobei die festgelegte Zeitspanne ein maximal zulässiges Alter der Signatur (108) festlegt, und wobei die digitale Benutzertransaktion ungültig ist, wenn die Signatur nicht verifiziert wurde, bevor die Signatur ihr maximal zulässiges Alter (123) erreicht hat.
Verfahren nach einem der Ansprüche 19 bis 33, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel festlegt, dass eine bestimmte Größe von der Transaktion (1214) unterrichtet werden muss; die bestimmte Größe von der Transaktion (1216) benachrichtigt wird, und eine Antwort von der bestimmten Größe erwartet wird.
Verfahren nach Anspruch 34, wobei der Benachrichtigungsschritt das Senden der Benutzertransaktion an die festgelegte Größe umfasst, und wobei die festgelegte Größe eine Zustimmung zu der Transaktion angibt, indem an den Empfänger eine Bestätigungstransaktion zurückgesendet wird, die von der festgelegten Größe gebildet wird, indem die gesendete Benutzertransaktion (1216) digital signiert wird; wobei der Verifizierungsschritt ferner das Empfangen einer Antwort von der festgelegten Größe und das Feststellen umfasst, ob die Antwort eine Bestätigungstransaktion ist, die von der festgelegten Größe (1217) signiert wurde.
Verfahren nach einem der Ansprüche 19 bis 35, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel (58) mindestens einen Empfänger für die digitale Benutzertransaktion festlegt, die von der Zertifizierungsautorität als akzeptabel angesehen wurde; und der Verifizierungsschritt die Entscheidung umfasst, ob ein Empfänger der mindestens eine Empfänger ist und die digitale Benutzertransaktion ungültig ist, wenn sie von einem Empfänger bearbeitet wird, der nicht in der Liste (1122, 1123) steht.
Verfahren nach einem der Ansprüche 21 bis 35, dadurch gekennzeichnet, dass: die mindestens eine Benutzerregel (58) einen oder mehrere Empfänger festlegt, für die Transaktion von dem Sponsor als akzeptabel angesehen wurde; der Verifizierungsschritt durch einen Empfänger das Entscheiden umfasst, ob der Empfänger einer der festgelegten Empfänger ist; und nach dem Verifizierungsschritt, wird eine digitale Empfängersignatur basierend auf der Benutzertransaktion und auf einem privaten Schlüssel des Empfängers (1116) gebildet, die digitale Empfängersignatur und die Benutzertransaktion werden kombiniert, um eine verifizierte Transaktion (1114) zu bilden, und die verifizierte Transaktion wird an den Sponsor geliefert.
Verfahren nach Anspruch 19, gekennzeichnet durch: Empfangen der digitalen Benutzertransaktion einschließlich der digitalen Nachricht (1506), der mindestens einen Benutzerregel (1504) und einer digitalen Benutzersignatur (1510) basierend auf der digitalen Nachricht, der mindestens einen Benutzerregel und des privaten Schlüssels des Benutzers.
Verfahren nach einem der Ansprüche 1 bis 38, dadurch gekennzeichnet, dass die Politik das Überprüfen des Zugangs zu einem öffentlichen Schlüssel erfordert und das Verfahren umfasst: Verweigern des Zugangs zu dem öffentlichen Schlüssel (1402); Versehen des Benutzers mit einer Nachricht, die Regeln des kryptographischen Kommunikationssystems (1426) enthält, wobei die Regeln zumindest eine Regel umfassen, die die Geheimhaltung des öffentlichen Schlüssels betrifft; durch den Benutzer wird die Nachricht digital signiert, indem der Benutzer den Regeln zustimmt (1430); und in Abhängigkeit von dem digitalen Signieren wird es dem Benutzer erlaubt, den öffentlichen Schlüssel zu benutzen.
Verfahren nach einem der Ansprüche 1 bis 38, dadurch gekennzeichnet, dass die Politik das Überprüfen des Zugangs zu einem öffentlichen Schlüssel erfordert und das Verfahren umfasst: Versehen des Benutzers mit einem Dokument, das Regeln des kryptographischen Kommunikationssystems (1426) enthält, und mit einer sicheren Einrichtung (1436), die eine inaktive Form des öffentlichen Schlüssels enthält, wobei der öffentliche Schlüssel nicht von der Einrichtung entnehmbar ist; durch den Benutzer wird das Dokument (1430) digital signiert; und in Abhängigkeit von dem digitalen Signieren wird der öffentliche Schlüssel in der sicheren Einrichtung aktiviert.
Verfahren nach einem der Ansprüche 1 bis 38, dadurch gekennzeichnet, dass die Politik das Überprüfen des Zugans zu einem öffentlichen Schlüssel von einer Zertifizierungsautorität erfordert und das Verfahren umfasst: die Zertifizierungsautorität versieht den Benutzer mit einer Nachricht, welche Regeln für das kryptographische Kommunikationssystem (1426) enthält, und mit einer sicheren Einrichtung (1436), die in inaktiver Form den öffentlichen Schlüssel aufweist, wobei der öffentliche Schlüssel nicht von der Einrichtung entnehmbar ist; der Benutzer zeigt seine Absicht an, den Regeln zu entsprechen, wobei die Anzeige umfasst: Zerstückeln der Nachricht, um ein zerstückeltes Dokument (1428) zu erhalten, digitales Signieren des zerstückelten Dokuments, um eine digitale Zustimmung (1430) zu bilden, und Zurücksenden der digitalen Zustimmung an die Zertifizierungsautoritä; und in Abhängigkeit von der Absichtserklärung durch den Benutzer wird der öffentliche Schlüssel in der sicheren Einrichtung von der Zertifizierungsautorität aktiviert.
Verfahren nach einem der Ansprüche 39 bis 41, wobei der Benutzer einen privaten Schlüssel hat, und wobei die Regeln mindestens eine der Folgenden umfassen: Regeln, die eine Zahlung an eine dritte Partei nach jeder Benutzung des öffentlichen Schlüssels erfordern; Regeln, die eine Zahlung an eine dritte Partei bei jeder Benutzung des privaten Benutzerschlüssels erfordern; Regeln, die eine Zahlung an eine dritte Partei nach jeder Bestätigung eines Zertifikatsstatus erfordern; und Regeln, die eine Zahlung an eine dritte Partei nach jeder Transaktionsbestätigung durch einen Benutzer erfordern.
Verfahren nach einem der Ansprüche 39 bis 41, wobei die Benutzertransaktion ungültig ist, bis das digitale Signieren erfolgt ist.